Long-story short: Buy a new printer if you have this error.
My mother-in-law has an older color printer that she got with her iMac in 2009.
HP Photosmart C4480 says “incompatible print cartridge” on its screen and will not do anything at all. Nothing will resolve this problem permanently so don’t bother buying new cartridges (waste of $50) nor cleaning the printer contacts.
Here are some steps to force the printer out of that mode.
Press X power at the same time
Press BLUE, GREEN, GRAY
Press BLUE until you see “INFORMATION MENU”
Press OK
Press Blue until you see “CHECKSUM FOR RELOCK DATA INPUT” (about 10 times)
OK
Press X until you exit all menus
When prompted for aliement cancel it with X. It should bypass the error
This works for our printer for only as long as the printer is On. If you power the printer off you will have to follow the procedure again. At this point that means that this printer is worthless and we will need to buy a new one.
A few months ago the company I work for released, a search experienced tailored for tablet use. After the tablet version’s successful release I had the good fortune to be asked to create the mobile phone experience.
As a web developer accustomed to using server side templates and “traditional” web development (i.e. web MVC frameworks), this was my first foray into building a pure JavaScript single-page app. It turned out to be a long a hard-earned learning experience.
Luckily, the JavaScript web app development space has been exploding for the past few years. I think the rise of smartphones and native apps have been particularly powerful in driving the development of client-side web apps because users have come to expect more app-like experience. IMO it’s difficult to produce that feel with traditional web page-based navigation because of load times and page refreshes.
The project
It took an embarrassing amount of time to make the phone portion of the app — almost 5 months. I started work on the first prototype (first of three) in the middle of January 2013 and the app has just been released to iTunes and Google Play as of mid-June 2013. I would attribute about 6 weeks of throwaway work, 8 weeks full-time product development and another 6 weeks of part-time development for handling scope creep, bugs fixes, and native integration.
Prototype 1
The first prototype was difficult. We wanted to have a “card-like” experience where you would do a search and your results would be a series of decks of cards. Each category was a deck and each search result was a card. On your search you would see a single result (the top card of the first category). You would then swipe horizontally to change categories or vertically to see cards below.
Prototype 1
The first prototype probably took almost 1 month to build and when I was done with it, it sucked. People didn’t really understand how to use it and the in-office response was luke warm. Problem was, it had no resemblance to the tablet app. The user experience wasn’t cohesive in tablet vs phone. We scrapped the whole thing. Looking back, we probably should have done more Photoshop prototyping for that one.
It sucked from a code perspective as well. I was working off a copy of existing code from the tablet version. The tablet code itself was fine but I was trying to jerry-rig Backbone.js into the existing code because I wanted to learn Backbone. The result was a pile of puke.
Additionally, CSS animations became the bane of my existence. I had no idea how hard it would be to coerce a web page into behaving similar to a native mobile app through CSS animations. CSS animations are a real brain drain and I still don’t fully understand how to use them. It’s still difficult and a hat-tip to the guy at forecast.io who appears to have a very good understanding of touch-handling and CSS transforms.
Prototype 2
After the luke warm response from Prototype 1 we went back to the drawing board and aimed for something that looked more like the tablet. The first iteration took maybe 2 days to slap together in a very basic way. We liked the results and moved forward.
Prototype 2
Marionette re-write
After suffering through trying to jam Backbone into some existing JavaScript I came to the realization that, although the system was working it would be increasingly difficult to add new features. I was running into problems with my scattered code base and I really wanted to create nested views for my Backbone app but I couldn’t devise a reasonable way to manage subviews — Marionette stepped in to save the day. Marionette provided the framework I needed to reasonably manage nested views without killing myself. It took a couple days of looking at Marionette tutorials until it finally clicked. Once I understood the framework I decided that the only reasonable thing for me to do would be a complete code rewrite. I threw out about 85% of the old code and started my Marionette app fresh. The few pieces I kept were a Backbone view that I knew would integrate well with Marionette and some convenience functions from the tablet code. After one full week of intense Marionette action I had full blow web app. Thankfully the time horizons for product were pretty loose while I was working on this app, it gave me a lot of time to learn some pretty important fundamentals to a client side MVC.
After the Marionette re-write everything fell in place afterwards. We did a few user testing sessions with people at Starbucks and around town. We got a lot of good honest feedback that changed the app UI considerably. We tacked on Local search, maps, news, and a bunch of other goodies.
iOS and Android Wrappers
To get a truly native feel on the tablet we had hired contractors to make us a native wrapper that would allow the app to slide in new windows and share pages via social media. They also did the phone version of the native wrapper. Let it be known that the browsers within a wrapper report all kinds of different numbers with regard to viewport size and ability to scroll smoothly. It took a while to nail the bugs but I think we got the app into a state where it looks pretty consistent across Web-iOS-Android.
With the help of some of our superstar build engineers at the company I had an auto-compiling script that would roll up all of the assets into one huge file that included HTML, CSS, JS, and even images (base64-encoded). All of the minified assets cram into about 600kB minified = 175kB gzipped. After the initial startup all network I/O is related to API calls and images. Pretty cool! The benefits of this build system can be similarly achieved with the bootstrap tools that I identified in a previous article.
jQuery Mobile: a minor mis-step
I initially used jQuery Mobile to organize my HTML into pages and use its CSS+animation routines to mimic smartphone styling. However, as the prototype grew and matured jQuery Mobile didn’t quite fit the needs of this project. jQuery Mobile didn’t fit for these reasons:
The goal was to support some pretty low-end Android devices I had to ditch the nice sliding animations.
I ended up styling 90% of the app with my own styles because we didn’t want to look too iPhone-y in the Android experience. (The app still has remnants of the iOS styling)
Given that I’m probably using about 10% of the library’s features it may not warrant its size of 140kB minimized + image sprites. Granted, I could use its package builder tool but then I’d have to figure out each feature that I’m using and test & test. blah.
Assuming I had more time I feel like I should have built something myself to copy the features that I’m using. The app looks and functions differently from the standard jQuery Mobile experience.
Alternatives to jQuery Mobile: I considered using jQT (formerly jQuery Touch) for its animations but it seems like the project has gone stale and development and maintenance trailed off. Besides that, I couldn’t really figure out how to use it. Ratchet looks really sexy but it falls into the same problem as jQuery Mobile in that it looks too much like iOS.
Backbone.js + Marionette
I wrote a previous post a while ago about using Marionette & Backbone to lay the foundation for the Web App. All in all I am very satisfied with the combination and feel compelled to do another project with these libraries/frameworks.
Somebody left me a Facebook comment asking why I chose Marionette over the other popular JS frameworks like Angular or Ember. In a nutshell, I chose Marionette because I already learned a little bit about Backbone and Marionette solved a lot of the problems I had with Backbone.
SwipeView + iScroll 4
SwipeView and iScroll 4 were essential in the app’s development. Although these libraries took some time for me to understand and wrestle with a few bugs the result is quite smooth. The code is easy-to-read so I was able to fix & tailor it to my needs readily. I donated $10 euros to thank the author of these libraries because there is no way I would have figured out any of this stuff so elegantly.
CoffeeScript
CoffeeScript made JavaScript feel more like Python which was fantastic for me. It took a while to get used to the lack of curly braces and semi-colons but once I figured out the CoffeeScript syntax everything has been smooth. It has been difficult writing vanilla JavaScript lately because of my numerous syntax errors.
Jade template language
Jade javascript templates have a kind of peculiar whitespace-dependent syntax but turns out to be pretty good. I guess it’s HAML for node? I like that I can use vanilla JS within the templates without much hassle. I find that the Jade templates are much easier to write than underscore.js templates (which are pretty difficult to write) or handlebars.js templates. Handlebars has kind of a quirky syntax and I like that when using Jade I don’t have to worry about balancing my HTML tags.
Stylus CSS
Not much to say about Stylus. It’s like LESS or SASS and gets installed through npm packages.
