Monday, September 21, 2009

iFool

My main computing platform, the one I use for all my software development (via VMware which lets me develop for a half dozen variants of Linux), is a top-of-the-line Apple MacBook Pro 13.3". My phone is an iPhone 3G 16GB. Am I an iFool? Have I drank the kool-aid? Shouldn't a hardcore Linux penguin be using an Android phone and running Linux on his laptop?

Well, folks, that would be fine and dandy except for one thing: I want to get things done, I don't want to spend all my time trying to get Linux drivers working on my work laptop. And for my phone, I want it to seamlessly sync music with my laptop, I want it to be able to be plugged into the iPod input of my car stereo and just work, I want it to seamlessly sync the address book and bookmarks and notes from my laptop without having to do anything special. In short, I want it to Just Work.

So for my laptop I bought a MacBook several years ago. It Just Worked. And was Unix to boot, so all my normal tools were available from the command line, and GUI versions of them (like Emacs, The Gimp, etc.) just worked. The entire developer toolkit came for free with the computer, so I could even type './configure ; make' in my project and compile it under MacOS if I wanted to do so. I chose the 13.3" form factor because it fits on an airline tray, where bigger laptops won't. I've upgraded to the latest and greatest where it gives me a real advantage -- most recently to the new aluminum MacBook Pro with the 7-hour battery and Firewire 800 and nVidia graphics chipset -- and whenever I upgrade, the new MacBook sucks in my accumulated years of files, notes, photos, and videos without a problem. It Just Works, meaning I can do my job, instead of fiddle with the technology all day long.

For my phone, I used a Palm Treo running the Palm OS for many years after it was obsolete. Yes, the email and web clients sucked. But it synced my addresses, notes, ToDo lists, and calendars without a problem. The problem came when I was stuck in an airport waiting room needing to check on what was up with my itinerary. The hoary old Palm web browser just completely choked on the airline's web site. So what to do?

Now, I have an HTC Wizard that I used on T-Mobile some years ago. It runs Windows Mobile 5. WM5 will not sync with my Mac without extra-cost software, and my experience with WM5 was that it was technically astute, but had the user interface from hell. The Treo's user interface was simple, plain, and easy to use one-handed, the WM5 user interface really wanted three hands -- one to hold the phone sideways, and two to thumb on the thumb-board.

Then I looked at Android. And Android, alas, reminded me sorely of Windows Mobile 5. It is technically astute, but its user interface was similarly designed by geeks for geeks, rather than designed for simplicity and ease of use. As with WM5, getting anything done requires two hands, and the user interface is complex and, well, ugly.

So I arrived at the iPhone by default. It syncs seamlessly with my MacBook, and the user interface, while more complex than that of my old Treo, is fairly simple to use to do ordinary things. When I plunk it into its WindowSeat in my Jeep I can do the most common operations with one finger of one hand (mostly selecting an iTunes playlist since I'm using it for music while hooked into my car stereo at that point). No fumbling with a stylus, no poking at tiny indecipherable little pictures with the point of said stylus, everything is big and bold and easy to reach out and touch.

So what's the lessons here? First of all, if you're designing a user interface, complexity is the enemy. The iPhone was blasted for its simple -- some say simplistic -- user interface, much as PalmOS was blasted for its user interface. Yet both manage to make a virtue of simplicity to make their device much easier to use. Geeks love adding complexity to products, as do product managers who are looking to satisfy marketing checklists. It is your job as a software development manager to push back on the continual drive for user interface complexity. I once had one of my engineers give me a design proposal that was five web pages worth of highly technical stuff, all of which was useful to geeks but which would simply be gibberish for our user base. I sent it back to him with all five pages X'ed out and, on the launch page which led into that long series, I drew a selection box and a button beside it. The user selected the previously-downloaded configuration to upload, then the program just did what it was supposed to do. We probably missed out on some marketing checkboxes somewhere, but the end product was much more usable, because most users simply do not want, need, or care about all the technical details of what exactly is supposed to happen behind the scenes. They just want the computer to do the right thing. They want it to Just Work.

The second lesson is that lack of a marketing checkbox often means nothing in real life. The iPhone lacked cut-and-paste for the first two years of its life. This was a missing marketing checkbox, but it didn't hurt the iPhone's sales any. The iPhone became the best-selling smartphone in the USA despite not having a feature that everybody claimed was "necessary". The simplicity of use that Apple got from not having that feature was far more attractive to customers than the additional feature would have been, and when Apple finally developed a way to add cut-and-paste that would not impact the simplicity of the product, it was just icing on an already tasty cake as far as most iPhone customers were concerned.

The final lesson is that people just want to get work done. They want to get work done without having to fight the technology all the time, and without having to look at the internals of the technology to figure out what's wrong and how to fix it. I'm very good at debugging our products. When there's a defect that nobody else can figure out, I'm the guy who looks at it, goes and puts a few printf statements in the right place (source code debuggers are for wimps, heh!), says "Ah, I see," and then tells the appropriate programmer what went wrong and why and how to fix it. But while I'm doing that, I don't want to have to be debugging my laptop too. Both Windows and Linux force me to fix OS stuff all the time rather than actually do my work. MacOS just works. And that should be your product too -- the customer should install it, maybe type in a few setup options, and then it Just Works.

So am I an iFool? Well, yes. And you should be too. By which I do not mean that you should go out and buy an iPhone and a Mac (especially with the recent release of the Palm Pre, which appears to have learned some of the lessons of its predecessors), but, rather, that you should embrace the lessons that these products teach -- simplicity as a virtue, simplicity as not being a barrier to sales, and a product that just works, without a constant need to tweak or maintain it in order to keep it working. Do that, and your product has a chance to become the next iFool's purchase. Make it a typical overly complex difficult to manage product, on the other hand... well, then you're just another mess in a large marketplace full of messes, and will stand out about as well as a bowling pin at a bowling alley, just one more indistinguishable product in a marketplace full of indistinguishable products. Which isn't what you were setting out to do, right?

No comments:

Post a Comment

About Me

I am a senior lead engineer and architect who has taken multiple products from concept to market and beyond. I am also one of the original Linux penguins -- my first Linux product hit the market in June 1996 and its latest incarnation is still running to this day.