Adaptive Path Blog

Michael “Rands” Lopp, a senior engineering manager at Apple and the author of the great book Managing Humans, let slip in a talk at SxSW a little about Apple’s design process. Since, up until now, their design process has mostly been such a black box, even this tiny view (as reported by BusinessWeek) is pretty interesting.

What struck me most was this:

10 to 3 to 1
Apple designers come up with 10 entirely different mock ups of any new feature. Not, Lopp said, “seven in order to make three look good,” which seems to be a fairly standard practice elsewhere. They’ll take ten, and give themselves room to design without restriction. Later they whittle that number to three, spend more months on those three and then finally end up with one strong decision.

While it is standard practice in visual design to come up with three strong concepts to present and choose from, I’ve found that it is rare to do so in interaction design. And especially to the level that Apple seems to do it, down to pixel perfect mockups. For months. This also echos what both Alan Cooper and especially Bill Buxton had to say at Interaction08, with both urging interaction designers to plan to throw several designs away. Obviously, if Apple is any indication, this is sound advice.

Share This

At UX Week 2007 and UXI Vancouver 2007, I did a presentation on where to look for ideas when designing. I finally got around to posting the slides. Unfortunately, you won’t be able to see the video clips here, but I urge you to track them down if you can.

| View | Upload your own

Share This

There isn’t a conversation in our studio that doesn’t take place using a whiteboard. While the reasons for that are fodder for another post, or perhaps a group therapy session, this new interactive whiteboard concept certainly caught my eye.

Johnny Chung Lee, an HCI Researcher at Carnegie Mellon, recently posted some information on a low-cost, multi-point interactive whiteboard that he created using the Wiimote.

His system used the Wiimote to capture movement of an IR-emitting pen device. The Wiimote tracks and relays the information back to a PC. Any surface can be used, including a wall, table top or even your laptop screen. If you use two IR pens, you can even do multipoint manipulation. The video shows it all and you can download the software free from his site.

You may recall that Johnny is the one who wowed us with his hack to utilize the Wiimote to track your finger movements, al la “Minority Report” interaction.

Check it out here.

Share This

Leopard never ceases to surprise me with all the little enhancements to the OS. Today, I was using an app (Panic’s new CandyBar) and wanted some help on the new Dock changing feature. I went to the Help menu item and entered “dock”.

I noticed a new category in the Help results called “Menu Items”. When I moused over these results, a blue arrow appeared showing me the location of these items in the Menu.

I’m not going to over analyze this, I just thought it was cool. It brings some context to help items right when you need it and is not overly obnoxious if you select it by accident. Good work, Apple.

Share This

The Legend of Zelda: Phantom Hourglass, is a action-adventure game for the Nintendo DS in which you control a blond adventurer with a pajama cap and sword (pictured below) using a touch-screen stylus. I was playing it the other day when…

My fairy sidekick told me that I should try “pressing” the seal from a map I just had discovered in a dungeon (displayed on the top screen) to my map (displayed on the bottom screen).

I remembered that several hours ago, I had to scratch a secret spot on the map to reveal another seal. So I spent five minutes aligning the two maps, then scratching and tapping on the touch-screen with my stylus. Unfortunately, this did not “press” the seal onto my screen.

Next I tried drawing the seal onto my own map complete with meticulous shading. Still no reaction. Frustrated, I tried to direct my character out of the map room. But my sidekick fairy barred my exit, turned me around and repeated that all I needed to do was “press” the seal onto my map.

Ten minutes of scratching and tapping later, I was about to give up: I imagined the triumphant feeling of closing shut my DS and tossing it into a corner. Then I realized, “Wait a second, if I close my DS then the two screens (or maps) will touch!”

Scared that it might power off my game, I carefully closed the lid of my DS.

I waited.

The green power light winked. My heart fluttered. I opened it back up — puzzle solved.

.

Looking for interaction design inspiration? Forget the iPhone. Get a Nintendo DS.

(Tom Armitage alluded to this interaction in his comment to my last post.)

Share This

Tons of press and posts, including some from my colleagues here at Adaptive Path, have touted the iPod/iPhone and iTunes ecosystem as a great model for how product systems should be. But it is my contention that at least one of those products–iTunes–is not really a very great application, especially now that Apple is making it the core of a suite of devices.

I’ve always thought iTunes was hard to use, and it has only grown worse over the years, as we now don’t have hundreds of songs, we now have thousands–in some cases tens of thousands–of songs, podcasts, movies, TV shows, radio, ringtones all in one long, long list. Working with iTunes has become as pleasurable as working with a spreadsheet. It needs a complete overhaul.

I will grant that iTunes is the Little App That Could, taking on way more than it was ever supposed to. It was never designed to be a digital hub. Or if it was, it was never designed well. How it handles different media is klugy. Playlists are, at their heart, just folders. The new iPhone addition to iTunes had to add tabs into the center pane. TV shows are clustered one way, movies another. It’s become a dog’s breakfast, and frankly, iTunes was never that pretty or engaging application to begin with. Winamp is aesthetically far more pleasing.

While Apple’s devices keep getting iteration after iteration, core apps–iTunes, Mail, iCal–languish or are given band-aid solutions to core issues. It looks like Mail, iChat, and iCal are getting some attention in Leopard, but meanwhile iTunes works and feels like an application from seven years ago, and the digital world–thanks in no small measure to Apple itself–has changed. iTunes, the ugly hub in the center of Apple’s media wheel, needs some serious interaction and visual attention. I hope Apple gives it some.

Share This

I was at Rich Web Experience last week and Yahoo’s Bill Scott presented a session on his recently unveiled prototyping library. It’s called Protoscript and he’s written a blog post as well. Both of these sources get technical fairly quickly so the implications may not be immediately obvious to non-programmers. Even though Protoscript is still very much a work in progress and there’s some distance between its current state and Bill’s vision for its future, the opportunities it opens up are are exciting.

The driving force behind this library is Bill’s opinion that “Prototyping is too hard for non-techies”. I wouldn’t make quite the same blanket statement, but I do agree that some of the most useful, effective prototyping approaches do require developer resources or developer assistance. These technical resources are not always readily available. Protoscript shifts the requirements and ultimately will allow designers with little or no actual coding expertise to rapidly prototype in an interesting way.

The Protoscript bookmarklet allows you ‘inject’ Ajax behaviors into existing web pages. That means you can start with an html mockup or a client’s existing site as a starting point and try all sorts of different approaches. Do you have a list of items somewhere on a web page? Want to see what it would be like if they were drag and drop elements? Want to see what it would look like if you could delete list elements and have them fade and disappear? Somebody asks to see what they would look like in some sort of accordion layout? Imagine being able to run through those three iterations in the space of 10 minutes. Now imagine being able to do that as a designer without a developer to help you.

Being able to get by without development resources will require the completion of the GUI interface Bill envisions but even in its current state, Protoscript could fundamentally change work flows. A designer and a developer can sit together over a common screen run through ideas in a much more lightweight way than they currently can. Or, in other words, Protoscript shifts this type of prototyping from a multi-day email interchange with the IT department to something that feels more like sketching quickly on whiteboard.

Share This

The next challenge after concepting was to prove that this concept could actually work by fleshing out the essential screen flows.

The displays on leading insulin pumps today are the size of PDA screens and use a number of hard keys for navigation. Was it even realistic to create an adequate, easy-to-understand interface using a 2 x .75 inch touch-screen half the size of my Nokia N73’s screen?

Dan Saffer and I began the interaction design process by examining the options and screen content in existing devices. Identifying what our participants actually used, we sought out the “essence” of the insulin pump.

The “Ah-ha!” moment for me was recognizing that the interface that most type 1 diabetics today are interacting with is nothing more than a simple syringe.

All there is to this “interface” is:

1. A way to select the amount of insulin you need (either by dialing it in or by withdrawing the appropriate amount from a vial), and
2. A way to deliver the insulin (which provides clear feedback that it’s working: seeing the insulin disappearing into your body and the feeling of pressing the plunger makes you feel in control).

The rest of the details are dealt with in the mind.

As one of the barriers to adopting pumps today is perceived complexity, our goal became to create an interface that is no more intimidating than dialing in your insulin needs on a pen. Additionally, the device needed to provide just enough “smarts” to take away true mental burdens (like calculating your insulin dosage using your carb-insulin ratio), while keeping the user in control.

With these principles guiding us, we delved into the interaction design details: What features should the Charmr have? What feature will be used the most (dosing)? Which buttons would be soft (most of them) and which hard buttons we would need (a back button)? What is the minimum button size for a hand-held touch-screen device (many kiosks use 16mm square, whereas the iPhone uses considerably smaller, 9mm square buttons)? Which information should be shown on which screens to support particular tasks?

We also spent a bit of time discussing what kind of imagery would make the best ambient display of status (the mood ring screen). Amy Tenderich told us that one of diabetics’ greatest struggles is with guilt. They look at the numbers and feel guilty all the time. Thus, the ambient display needs to visually represent your status without assigning “moral value” to high or low blood sugar — the way a thermometer might show blue or red; neither is inherently bad.

We considered virtual pets, lava lamps, color abstracts, weather, and simply a personal/family photos theme (because it’s family or a particular goal that often motivates people), and finally concluded that the device should offer multiple themes and allow the user to choose what motivates them.

Finally, I developed a skin for the interaction design, striving to make it compelling and modern, while avoiding both “medical device blue” and the iPhone look and feel. The user could customize both the themes and the skins to their tastes, and perhaps even download more skins and themes online.

With the screen designs as well as a rudimentary industrial design concept completed, we put together an Experience Blueprint (4mb pdf), then it was time to tell the story of the product.

Share This

Lisa Strausfeld, Pentagram, with the UI design team
Christian Schmidt, Takaaki Okada, Eben Eliason

First ever UI demo of the OLPC.

Mission is no less ambitious than to educate every child in the developing world.

Based on work of Seymour Papert’s constructionalist theories of learning–children encouraged to make things. “Find ways in which the technology enables children to use knowledge.”

Announced a little over two years ago. Final round of beta machines are right here. First large-scale distribution is happening in September.

Durable, low-power computer. New display technology–both full color and black and white. Works in direct sunlight. Long life battery that can be hand-powered. Peer-to-peer mesh network. Dedicated processor that handles mesh networks.

OS based on RedHat Linux “Sugar”

Sugar is: a tool for learning, for children without prior experience with computers, in multiple languages.

UI is based on abstraction. Less is more. It’s an ethic as well as an aesthetic. Worked well crossing cultural boundaries. Computers had a lot to do without rendering graphics.

UI Building Blocks

XO: an avatar of the self. Can be personalized.

Sugar is based on people, activities, and objects. Color indicates ownership. Activities produce objects.

Field is a type of desktop with multiple views.

Community forms the real conceptual paradigm for Sugar.

“Home Sphere” is a place for myself and my things. “Friends Sphere” is a shared space. “Neighborhood Sphere” is a larger community like a school. Zoom based interaction model–4 levels of zooming between spheres. Fourth sphere is “Activity Sphere” where shared activities are done.

All activities are recorded in the journal: record of all the things you do. Time based and non-heirarchical. Automatic, no saving required. Keeps track of all activities over time. Search and filters help find entries.

Lots of UI and usability issues when users start sharing activities that we’re just now discovering now that the devices are in the field.

2000 developers around the world developing activities. Hope is that it will be like Mozilla add-ons.

Started working on the UI last summer–incredibly rapid. UI is constantly iterated. Constant builds of the OS.

Basic UI features were established before Pentagram got started–things like journal. Pentagram established model, framework, visual language. Making it more of a continuous space. Extension of the best features of current desktop space.

Screen is relatively small so needs all the screen space to do activities, but when you “step back and look up” you are surrounded by friends.

It’s a non-profit effort. “No one is doing this for the money.”

When we started, we just had to work and make a lot of assumptions. Testing cycle is to come. When the feedback comes in, the bugs haven’t been the problem. Kids are still doing amazing things in the field.

Debate about the frame and its discoverability. But in a classroom, if one kid can find the frame, the kid conveys it to others. Kids share the UI with others. Helped the usability quite a bit.

Most challenging view is the neighborhood (”mesh”) view. What should the view be? The scalability is a challenge: how do you represent 200+ people in the neighborhood view? It can be overwhelming.

Share This

I did my Master’s thesis project (play with the prototype) on creating digital piles and piling as an alternative to folders and messy desktops. It’s interesting to see that Apple, who did work in this area about 15 years ago, is finally incorporating them into the Leopard version of OSX, albeit in a way I didn’t expect, making the piles spring out of the Dock, not on the desktop. It was rumored to be added in earlier versions but nothing ever appeared. Now it seems it has. Nifty.

I wonder, however, if putting these stacks in the Dock loses some of the readiness at hand and visibility that make our physical piles so useful. When I researched how and why people pile papers on their physical desks, I found some really interesting things about the anatomy of piles and how they get used that I then tried to build into my piling system. Based on my research, I came up with a set of design principles for piles:

• Items on the top of piles should be visible.

• As files get accessed less frequently, they should drift deeper into the pile.
• Piles should be easy to file when done.
• Users need to be able to browse through the piles to find things not at the top.
• Pile visualization should reflect the amount of items in the pile.
• Pile visualization should reflect the last time accessed.
• It should be easy to re-sort the pile (to move files back to the top or down to the bottom).
• It should be easy to discard things from the pile.
• It should be easy to pile things as they are received or created.

Looking over the new Stacks feature, I find few of these design principles being used. Granted, no one at Apple asked me, but I have to wonder how much the designers looked at physical piling behavior before creating Stacks. Most of my principles are fairly obvious with even a brief study of piling behavior. I didn’t spend overlong researching my piling system, but the time I spent in the field was invaluable to understanding what seems to be obvious, but definitely has some nuances that could be reflected in any digital re-creation.

I also can’t help but wonder whether having Stacks on the desktop instead of in the Dock wouldn’t have been a better design choice, so that some of the usefulness of analog piles could be recreated and reimagined more broadly. This doesn’t mean that Stacks won’t be useful, but possibly not as useful as they could be. Imagine physically being able to “scatter” stacks by holding down your mouse button and wiggling it over a pile. Or simply being able to see at a glance what the top three items you last touched in a pile were.

Apple, I think, did the same thing with Widgets — marginalized a powerful tool. By pushing widgets too much off to the side (effectively creating a widget mode) instead of incorporating them onto the desktop itself, they rendered widgets a lot less useful. I fear that’s the fate of Stacks as well. We shall see.

Share This