Designing for iPhone

I had a wonderful dinner with a friend and colleague, Scott Sutcliffe. Scott is an all-around engineer, comfortable with both mechanical and software engineering. I apologize if this sounds like mechanical/software are either the entire range of engineering or the limits of his expertise, but those are the two areas he and I most often find at the core of our conversations.

Scott was the engineer who oversaw the development of a lot of the back-office b-to-b tools I designed for the Thomas Register of American Manufacturers. He was the coding genius behind the prototype for a color thesaurus, a screen shot of which can be seen in my portfolio. I also designed a logo for him and put some CSS together for his website.

At dinner, Scott showed me his latest endeavor, an iPhone app called Tippety Split. He constructed the tool as a practical exercise to better understand the iPhone SDK. The application is very simple in its sophistication: Scott managed to pack a lot of clever functionality into what seems like very simple UI. Then, like he was reading my mind, he asked if I would be willing to play around with the UI!

How could I turn down such an opportunity. I won't go into all of the stuff I did to the UI (that would be giving away confidential secrets!) but we came up with some very cool concepts. In order to conceptualize them, I had to overcome some of my web design bias. For instance, the application is essentially an interactive form. On the web, with basic HTML and JavaScript, a product designer would be able to infer from that their design needed to accommodate a small series of fairly well known event states: onFocus, onBlur, onClick, onMouseOver, etc..

These states are all gone or different on the iPhone. There is no happy little pointy cursor, there is in fact no single point of focus. One of the features that makes this UI so slick is the fact that a user can create multiple points of focus, and depending on whether those points move closer together or apart, a control will behave differently. An example of this is when looking at a photo, a user can touch two points on the image and push them apart; the effect of this will be to zoom in on the picture. If the two points converge, the photo zooms out.

Another iPhone behavior that I wanted to capitalize on is the focal deceleration that makes the UI so realistic. When looking at a list of phone numbers, a user can put their finger on a number and nudge it up or down. The list scrolls in that direction, decelerating as it goes, then stopping. I won't give the particulars of how I took advantage of this (hint: it doesn't have anything to do with lists) but suffice it to say that we've come up with some very clever UI constructs. I fully acknowledge that acceleration and deceleration are easy to accomplish in JavaScript in a web browser, but the point is that there are common conventions built into the iPhone GUI that users have come to expect. A once relatively stable and small lexicon of mouse events are replaced by a significantly more elegant vocabulary of interactions: nudging, brushing, pinching, pushing, pulling, flipping, etc.

I understand that the iPhone as a device and it's interface as a GUI have practical limitations and a finite shelf life, but jumping into this venue and playing with these new conventions was like being a kid in the proverbial candy store. What a delightful experience this is!

The triumph of the agnostic

I was recently put through my paces in a three-on-one interview. Among the interviewers was a VP of Product. After a whirlwind demonstration of requirements gathering, I assembled a crude design concept for a product we had just come up with (muffins with "kick"). The challenge was then to come up with a front-end model that would put the website into the history books for its revolutionary design. How would I achieve this?

Tall order, eh? It's funny because I didn't think I would be able to answer the question but I ended up arriving at a decent response. Please forgive my writer's embellishment here, but what I am about to describe (using hyperbole, analogy and movie references) did happen, and my mind did kind of work this way, but I wasn't channeling Neo when I found what I believe to be the right answer.

I was thrown into "bullet time." For those unfamiliar, this is a hyper meditative state that Keanu Reeves's character Neo goes into when the bullets start flying in The Matrix. Time slows down, and the bullets seem to be moving in ultra slow motion. As I watched these "bullets" coming toward me, I immediately understood this was a training simulation and in the balance of my performance a job was hanging on the line.

Believing I would not arrive at a sufficient solution, I deferred the question and described a revolutionary front end model that had made the history books a few years ago. ESPN had completely redone their website and was the first commercial entity to launch a completely tableless wrapper (the structural HTML for the page contained no HTML "Table" tags). Those who know me well understand I am not an avid sports fan, so for ESPN to get me spending the amount of time I did on their website was pretty impressive. "Look ma, no tables!" I was familiar with the concept but at the time this was gutsy--there were still legacy browsers out that would choke on this model.

In my deferral, I described the situation above, and in telling the story I realized what the next revolutionary step would be. If ESPN had launched a site that worked well across all modern browsers and used only "box" containers to deliver the content, then the next evolutionary step would be to transcend the browsers altogether. Whether I am coming at the site with my PS3, my iPhone*, my Kindle*, webTV, an old-fashioned WML phone, or a conventional web browser, the content and functionality would be platform-agnostic. This was my triumph--understanding in bullet time that the next evolutionary step in web construction will be sites that agnostically deliver their payload to ANY platform.

I can't say whether I passed the training simulation (I'll let you know) but I can say I was at once intellectually exhausted and thoroughly exhillerated. My modus operandi is typically to ice up in test conditions. I might get an A+ on the practical, but I typically just squeak by on the final exam. Time will tell if my prognostication was correct. We shall see.

*No, I don't have an iPhone or a Kindle, but will happily accept donations or perform extended field testing on one or both if anyone is interested. :)