Adaptive Path Blog

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.

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.

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.

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.

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.

I missed Stephen Anderson’s talk at this year’s IA Summit. Every time I think about it, I kick myself. Where the heck was I? Wandering lost in the serpentine halls of the Flamingo Hotel, no doubt. Regardless, I hear I missed something special so we booked Stephen for UX Week.

I’ve been wanting to blog about this topic since Christmas — when I was home with my relatives, desperately trying to explain things like…

The concept of opening two windows side by side to move things from one to the other… Look, you can move the window by clicking on the title bar! If the window is covering your whole screen, don’t panic, just use the handles to resize it… Oh, and to move the picture file, don’t drag the preview – drag the icon.

Why a 404 Page Not Found error is not a serious computer problem, it probably just means you typed the URL wrong… (and why I can just blithely ignore about half the errors Windows gives me, when the simplest of error can have my mom writing it out, character for character, to investigate later).

It felt like the popular writing class where you’re trying to describe how to make a peanut butter and jelly sandwich to aliens who have never seen one before. You can’t assume anything.

I vaguely remember playing with an interactive tutorial that came with Windows 3.1 that introduced the brand new “windows” concept and let you practice “minimizing” and “drag and drop.” It’s easy to forget, but there are people today — even our peers, people of the same age (20 and 30-somethings) and demographic as Adaptive Pathers — who haven’t established these basic mental models. And because of this, they’re afraid to experiment or to try things.

What can be done for these people?

Should anything be done?

In school, I suggested to a professor that I do a project focused on these people. But he discouraged it, saying:

“To put it bluntly — these people are dying out. The current generation grew up on computers. Designing for these people won’t be a need for much longer.”

Then the other day, Jared Spool was chatting with us. To make a point, my co-worker, Chiara, cited her brother’s — a 30-something with young kids — recent revelation: “Did you know that you can search for homes on the internet???” She went on to say that her brother doesn’t even use email — he just doesn’t see the value of it. Jared replied:

“But do we need to design for these people? I hate to say it, but your brother will eventually die.”

I’m not sure I agree. Are these really only edge cases that we can dismiss or laugh off? Our 30-something peers are still going to be around for more years than the internet has even been in existence. Chiara’s brother and my in-laws aren’t living out in the wilderness. And surely we designers have something to offer — if we’re in the business of improving the human experience — even to people who ARE living in the wilderness.

Have I been asleep at the wheel and missed the conversation about this? I went to Yahoo’s Home Page yesterday and noticed that the menu bar was starting to indicate, via a larger font, the sections of Yahoo I visit the most. Very nice. (And shades of BBCi’s brilliant Glass Wall project.)

Jeff Veen has posted about the nifty race tracker that Adobe has developed for the Tour of California bicycle race. Its worth a look. Its also worth noting that Quokka Sports tried this kind of stuff back at the height of the boom, and failed spectacularly. We’ll see how it goes this time around.

My family is participating in the Guest at Your Table again this year. It’s a program that collects money for social justice causes. The cardboard box that you put money into sits on your dinner table, and on one side of the box is a panel about people not having access to clean drinking water. As I explained this to my six-year-old daughter, her response was, “Wow, we’re so lucky to have faucets!” For her, the whole system of reservoirs, pipes, plumbing, sewage treatment, etc. was completely summarized by the one visible part of the system: the faucets.

How often this is true, especially with digital products. What users physically experience represents the system to them, and how it works. The interface is the system. You can have the greatest interaction design or information architecture in the world, but wrapped in crappy industrial or visual design with poor affordances, the entire system is perceived to be bad.

If only this worked in reverse! How many nice-looking objects do you own that function terribly?