Sarah Allen's Weblog

checkboxes: legacy or innovation?

In some ways, I feel strongly that the art of UI design has devolved for me to be even writing this post. If I recall correctly, the checkbox was invented in the 1970s. In the glory days of desktop GUIs of the 90s, it played a fairly minor role next to the direct manipulation of windows, columns, floating panels and multi-dimensional controls. However, in the late 90s, UI design and development shifted dramatically with the dominance of web-based applications. Suddenly the creation of a user interface equated with generating a stream of HTML text.

Webmail was one of the first widely used web applications with a user interface that went beyond links and forms. By the early part of this century, webmail usage surpassed the number of people who read email with a desktop, installed email application. The dominant paradigm for selecting messages was the checkbox. There was really no other choice.

Checkboxes were understood to be a necessary evil. HTML offered a small subset of the traditional graphical user interface. In 2002, Oddpost entered the webmail scene with an Outlook-esque interface. It only worked on IE Windows, but provided a glimpse of things to come....or so we thought. If only we waited till the new generation of browsers gained adoption, web applications could be blessed with drag-and-drop and multiple select using modifier keys CTRL and SHIFT. No need to clutter up the screen with columns of redundant checkboxes.

Yahoo aquired Oddpost and several years later offered a new Yahoo Mail with a similar desktop-like interface, combined with a web "look" and more polished graphics.

Meanwhile, Laszlo was also developing a Webmail application. Like Oddpost, it has a desktop-like UI with drag-and-drop and double-click. Additionally, it provides a cinematic user experience with a login panel that visually transforms into the application and animated details that help novice users learn their way around. We were looking to go beyond the desktop experience, and didn't think twice about leaving behind the bad-old-days of plain old HTML.

Just a few years later, it seemed that Yahoo took a step backwards in their UI by including checkboxes for multiple select.

working at Laszlo, I've learned that when large amounts of people using HTML email were introduced to a desktop-like experience, some of them complained that they couldn't find the features they used to have. People had grown accustomed to the "old" way. They wrote feedback messages asking "how do I delete multiple emails" and "I want to delete the spam that I receive without viewing it." A few even specifically requested "checkboxes."

It makes one wonder: is it just a matter of learning something new or is there something to this checkbox thing? Is this just a legacy UI that we have to accommodate and in the future people will wonder why its there and we can let it fade away? or is it somehow a good thing to provide an affordance for multiple select, so novice users know it is there. Also, in providing an alternate method for selection, there's an option to have the checkbox not display the message, while selecting anywhere else also displays the message. This lets people delete spam without viewing it. It may sound like a sophisticated use case, but there's a significant minority of folks who care enough about this to be vocal about it.

Time will tell. I'd be interested in what other folks think. (If in fact there is anyone amongst my readers who even considers this little backwater of UI design worthy of discussion.) Whether checkboxes are good or evil when applied to this purpose, I predict that within 5 years Outlook will have checkboxes.

application personality

Martijn van Welie has a good perspective on emotional design: the behavior of an application causes us to project a personality onto it. Some examples from his post:

• Applications that throw windows promptly in my face are rough where as windows that fade onto the screen are far more graceful.


• An application that keeps on telling me about things I don't understand such as error codes, format errors, compatibility issues is obviously more busy with itself rather than assisting me. A bit selfish perhaps?


• An application that keeps on telling me irrelevant stuff that don't seem to impede normal usage is nagging.

He equates this with "brand personality." I think we need to careful about changing application behavior to match brand personality -- we need not match rough, whimsical or risk-taking with corresponding behavior, but I do agree that we need to be conscious about supporting the brand where we can and craft the experience of interacting with the application.

The article ends with a nice collection of guidelines for presentation, interaction, functionality and content. These are presented more on the good vs. bad spectrum than with the more human notion that many different types of personalities can be the basis of a supportive and trusting relationship. Nonetheless, its a good read.

design for the expression on someone's face

I'm not much of a gamer. I prefer to find delight in creative projects that feel like play. It might be some remnant puritanical work ethic from my New England roots, or perhaps its just that most games aren't well-suited to my demographic. Nonetheless, I'm intrigued by game design and find that some aspects of game design can be applied generally to software design, as well.

I read today a nice discussion of Wii Fit. Shigeru Miyamoto, famed Nintendo game designer who created Super Mario and the Wii, is known for designing for the expression on someone's face when they play the game -- they should smile and be happy, not frustrated. With the Wii, he designs for everyone in the room, not just the game player. I like the idea of using the Wii for fun fitness training. Taking game elements and applying them to boring or otherwise frustrating activities has potential.

"Ideas make games fun, not graphics" -- Luke Nihlen

simplicity in software design

(via cannel.org)

Simplicity is a tough sell. I can't tell you how many times I have argued against "just one checkbox" or "why can't you just move it to the top?" If all of the options are at the top level, then none of them are.

extreme programming vs. interaction design?

In January 2002, Elden Nelson wrote "Extreme Programming vs. Interaction Design: When two development design visionaries meet, there's room for consensus--but not much (via The Sticky Bit and the Internet Archive). This fabulous interview with Kent Beck and Alan Cooper contrasts two modern methodologies for getting software right. These challenging questions are no less relevant six years later. I believe that we should take guidance from both philosophies, and that they are not mutually exclusive.

Alan is absolutely right that there needs to be up front design. He talks about designing human behaviors before you even consider defining an interface, thinking about what buttons go on the screen. He notes that interaction design focuses on the behavior of complex systems, of humans and of organizations. He comments: "I think XP has some really deep, deep tacit assumptions going on, and I think the deepest tacit assumption is that we have a significant organizational problem, but we can't fix the organization." In my experience, sometimes we can fix the organization and sometimes we can't. Usually we can just nudge it in the right direction, but some of the age old problems will exist. It's easy for a management team to just remove design from the process in the name of XP.

Alan would keep engineers away from customers, fearing that engineers lack insight into human processes and will merely "automate the pain." He draws an analogy with an architect and a builder; however, I believe architects study construction and the engineering principles behind building a lot more than most interaction designers study the technology they work with. After much discussion, Alan agrees that needs to be a back-and-froth and that engineers need to be involved with the design.

The major contention in this article seems to be about whether the engineers start work day 1 or day X, but afterwards both believer they should work together. I'd like to see a project with Alan and Kent both on board where Alan's team was doing interaction design while Kent's team was writing stories. I love Kent's ideal of writing code that is flexible and becomes more resilient over time not less, but it is clear that Alan just doesn't believe it, and I agree that ideal is pretty tough to achieve.

Here are some quotes from the interview which I enjoyed....

Cooper: It's my experience that neither users nor customers can articulate what it is they want, nor can they evaluate it when they see it.

Kent Beck:
One of my goals in XP was creating teams that even in highly constrained and emotionally charged business environments could produce programs that didn't lose their ability over time but, in fact, gained capacity over time. As components are factored out, as configurations emerge from the customer team--which you might call the interaction team--the program is still getting better and better in five years. The team gets the attitude where they go back to the customers and say, "You're giving us easy stuff. Give us a hard one." The customer team is actually challenged, over time, to think bigger and bigger thoughts as development goes on.

And here's my favorite exchange, following where Alan Cooper was talking about how the right design up front keeps the requirements from shifting, since you get them right upfront (which I don't know if I agree with, I suppose it depends on the length of the development cycle):

Beck: Yeah, but I would say exactly the opposite. For all its Dilbertesque qualities--and I'm still proud of having said "Embrace Change" in the title of the first XP book. I've consciously decided to give up the ability to predict the future.

Cooper: I see that in XP. It's an abdication.

Beck: Is Zen an abdication?

meaningful to humans and computers alike

Jon Udell writes “We posted weekly.pdf to the website. Isn’t that good enough?” (via Calendar Swamp). People don't want to and shouldn't have to structure what they write to be legible to a computer. It is hard enough to write prose that people understand, let alone also making it independently understood by a machine. I think the secret is to make software interfaces that allow people to naturally collect information and let the computer sort and publish it to other computers. Calendars are a great example of this, as are blogs.

Weblog software took a common need, periodic publishing , and created a simple interface that provides people with the kind of media they want to generate: front page news, archives by category or date and so forth. With the advent of RSS feeds, people could enable their blogs to be computer-readable without painstaking markup. They had already structured their information in the nature by which it was generated.

Likewise, it is natural to record calendar information overlaid on a timeline with day, week, and month views that mimic traditional paper visualizations of time. This enables the software to generate structured data without people needing to think about it.

Publishing structured data with today's software is evolving to be a fairly natural, low-tech act; however, subscribing still exposes too much of the gears in the machine. Let's take a look at an example of generating and re-using structured calendar data.

Larry Cannell discusses critical mass syndication by applying the technology to the needs of parents. Using Google Calendar, it is quite easy to register and create a calendar with events. The software makes it possible to publish a snippet of html that can be embedded in a website to syndicate the data. This enables a PTA website to publish events in an automatic fashion.

The calendar can be maintained by someone who does not know any details of html or ics, but it still needs to be set up by the technical crew. Likewise in the blog world, you need to be exposed to XML feeds and non-human-readable gobbledygook to connect your feedreader to the right source. The next step in the evolution of the web will be to provide more usable connections between applications.

give them what they need, not what they want

It is a dicey thing saying no to customers, especially when they pay big bucks for not only the software license, but a bus load of consultants that integrate and customize the software for their deployment. However, I believe that the same truths hold as when you hear from 50 customer in 500,000 and you really cannot give each person what they want. You need to listen them, then give them what they need, not necessarily what they are asking for. But they best way to say no is to actually convince someone of a different perspective, that they gain something by the omission of something else.

When old tricks don't work...
People create their own myths about how a feature works. Humans naturally develop a mental model of what's going on, of cause and effect. When an interface is well-crafted and the designers made the correct assumptions, most people will develop a mental model that is close to reality. Sometimes the best of intentions go wrong. For example, many webmail interfaces have a "Block Sender" button on the screen where people read their emails. When someone gets an offensive, unsolicited email, they think "ugh. I don't want to get this junk from some creep," so naturally they click the "Block Sender" button. The problem is that the spammers aren't using their real email address -- they fake something up and rarely do you receive an email twice from the same sender. Nowadays preventing spam needs to be more sophisticated, most webmail systems often offer the option to "Report as Spam" which is much more effective since there is a back-end service that develops heuristics on what is spam and what isn't, so even if the sender doesn't match, the new spam might be recognized and blocked. Not only that, but if people block the sender of every spam message they receive, they quickly develop gigantic blocked senders lists, which many back-end mail systems aren't optimized to handle. So when a customer licensing email says, I want a "Blocked Sender" button on the main screen of the app for a new deployment, I tell them the back story as I understand it and explain that people really want to just prevent junk mail and we should make the options that will help with that first and foremost. So far it has worked out, the insightful product managers agree.

When something better comes along...
Knowing the what people really need is especially tricky when transitioning from an old interface to a new one. Whether upgrading a version or switching vendors, individuals always have a hard time at first adjusting. I keep running into this with the "Nickname" field in email. It's really hard to say no to any feature that exists in Outlook. For better or worse, it is the most popular desktop email program and webmail apps have historically emulated as many features as they could. So, most webmail apps have a nickname field. Now this feature was important in the days before auto-suggest, in the early 90s when we all had 100MHz processors running Windows 3.1 and before Web pages had Javascript. Instead of looking up a contact or typing a long email, you could choose a short nickname for someone.

Ok, maybe it isn't needed any more, but what harm is it? Aw... come on, it's just one more field. One of the huge usability advantages of web applications over desktop applications is that they tend to be simple. This design often emerges from necessity based on technology limitations. As the technology improves to offer a more desktop-like experience, designers and product managers have an opportunity in this new space of moving beyond the cluttered desktop experience to offer a simplified interface that is no less powerful. By offering a nickname field, you are telling people they need to manage their address book, they need to go through and pick their favorite people or people they communicate with frequently and set them up. In this new age of vast information stores, software is becoming more adept and figuring out what you need and giving it to you without requiring a setup process. Auto-suggest is an innovation along these lines. You can just start typing the first few letters of someone's name and their full name and email address pops up. By taking away a feature for some people, we make sure that they know and new people know they don't have to rely on the old way of doing things, and we streamline how they use the application and allow the software to work for them and for them to do less work.

The art of design is making choices. We develop models of how people would be most effective in accomplishing their tasks. We need to be particularly careful when a new option replaces an old one -- sometimes redundancy is a good thing and sometimes too many ways of doing the same thing make an interfaces cluttered and confusing. It is a delicate process to guide people into patterns where they will be most successful.

improving interface design

I didn't see this live, but I enjoyed this presentation by Garret Dimon on slideshare. Lots of compelling words of wisdom on interface design...

| View | Upload your own

origins of the cinematic user experience

I've rallied a few designers at Laszlo to start a new weblog about the Cinematic Interface. The first time I ever heard software described as cinematic was David Temkin who coined the term the "cinematic user experience." Brenda Laurel wrote about computer software as theater, but David took the metaphor one step farther. I cornered him a few weeks ago to ask him about the origins of the term, and posted the interview. Here's a snippet:

We didn’t want to say rich media. Rich media is tainted. It makes you think you are going to get some movies. The word “rich” is also tainted. You say rich and you think you are going to get some chocolately desserts that are heavy and expensive – 5MB downloads of chocolately desserts. Who wants that? I want my application.

Cinematic user experience conveys first of all that you aren’t just watching you are interacting – the “user experience” part of it. We thought cinematic was an intriguing term, that had a non-techie spin to it. It was something that when non-techies saw it, they instantly understood this is a completely different type of product category and yet industry insiders would look at it and say things are moving on the screen, maybe you have a different technical architecture...

emerging trend: offline web applications

Ryan Stewart writes about Adobe AIR's mention in MIT Technology Review's top 10 emerging technology trends for 2008: "Context: Adobe will release AIR early this year; companies such as eBay, AOL, and Anthropologie have built applications using early versions of the software. Google is working on a competing platform called Gears." (via Ron Jeffries)

The trend is what is interesting. I think Gears has a more compelling approach. Adobe is first to market with a fully featured, yet still beta offering. Google Gears just released a .2 release. You have to really dig in the Gears site to get a sense of where they are going. They are in real need of wiki maintainer with a sadly out of date [now updated] roadmap, but lurking on the email lists and getting deeper into the wiki there are some interesting clues that these folks are headed in the right direction.

"The Gears mission is to add new capabilities to web browsers, enabling developers to create better applications."

They have some interesting features in the works:
* Desktop API is in in an "upcoming release." (You have to build from source to try it out.) Instead of actually downloading an executable, this creates a desktop shortcut. You can have an icon that you double-click to go directly to your web application which has the same user experience as when you are online -- bookmark or desktop application are just two ways to navigate to the same thing.
* Notification API is a pretty new proposal, but an indication that the community is starting to plan how to integrate with native OS notifications, a task bar icon, etc.

Of course, Adobe AIR already has those features, plus drag-and-drop from the desktop, which is a feature web applications desperately need. It overcomes a major limitation of Flash by embedding the WebKit browser, which is a smart move by Adobe. However, what most Adobe fans tout as a strength of AIR (that it is actually a desktop application), I see as a weakness. It borrows from the online/offline model that I was working on with Director and Shockwave in the late 90's where the user experience and technical architecture is more like a client-server app than a webapp.

I've observed in focus groups and usability tests that most regular folks don't know the difference between a web page and a desktop application. People are focused on the task at hand, getting the job done and are annoyed by arbitrary changes in how they get to what they need. Of course, they adapt. People don't actually expect software to be particularly helpful or intuitive. Nonetheless, software designers and developers keep trying to get it right.

As people are more often connected, intermittently connected, and more reliant on connected tools for business notifications and communication, there is an increased need for web applications to have a desktop presence. I shouldn't have to go to the ebay website or check my mail to find out whether I've won my latest bid. I want to be able to read my mail on an airplane AND in an internet cafe when I've left my computer at home. The gears approach is attractive because it will enable us to craft an experience which is not arbitrarily different for on- and offline experiences of the same application.

I've been following this tech just by reading for a few months, but this week, I spent a little time getting my feet wet. I installed two applications: Ebay Desktop with AIR and Google Reader with Gears. Please remember, that all of this stuff is pre-release software, so it is still subject to change.

Ebay Desktop and Adobe AIR

Installing Ebay Desktop with Adobe AIR beta 3, the first screens prompting me to install the new version of Flash were really confusing. Even after I installed Flash, it still told me to install Flash, so I still don't know if I really needed that step. Then I had to navigate back to the original page manually after installing Flash and AIR. I expect that the first part of this awkwardness could have been better implemented on the ebay site and may not be a fault of the AIR technology, but the latter series of multiple progress bars and dialog boxes looks unavoidable. All told the install experience was over 10 minutes.

| View | Upload your own

Remember the Milk and Google Gears

Remember the Milk has really done a nice job with this. The installation took just a few minutes. After setting it up initially, I could go back and forth between online and offline without really thinking about it.

| View | Upload your own

The only momentary glitch was with the stupid IE Popup blocker which reloads the page. I wonder if there is anyway around that? I wrote about running into this issue on the gowebtop blog but I wonder in this case if there would be a way to create an in-page install to avoid this hiccup.

Technology Options for Offline Webapps

As a final note, Gears and AIR aren't the only two players here, just the most talked about and seeming front-runners. Of others, I've collected the list below. My friend Max just told me about XULRunner and I haven't had a chance to take a look at that yet.

HTML solutions
* Google Gears (open source, New BSD License, 0.2 release)
* XULRunner (open source, MPL, 1.7)

Flash Wrappers
* Adobe AIR (proprietary, beta)
* Zinc
* SWFStudio
* SWFKit
* Jugglor
* Flash Desktops
* mProjector
* ScreenWeaver (LGPL)
…

touchscreens in taxicabs

Minority Report style ads coming to taxicab near you. Ok, they aren't reading your identity off your retina to display targeted ads, but GPS will display ads based on location. I had heard a few years ago that animated Flash ads were being placed on top of NYC taxis, but I can't find a reference to that now. I did find this story
about taxitechnology.com which is offering ads on touchscreens in 13,000 New York taxicabs.

It's hard to tell from the marketing materials, but it looks like this has been in the works for quite a while. I thought the interface was pretty ho hum for all the hi tech -- shiny buttons, uninspired design. Any New Yorkers tried one yet? Is it cool or lame? helpful or intrusive?

i love comic sans

To say that comic sans is widely disliked may be putting it mildly. However, I'm not afraid to say that I love comic sans. I have fond memories of it from Kindergarten. It is the only font I know that makes the letter "a" in the same way they teach us to write it.

gas station error UI

I'm not sure what a gas station pump should display when it runs into an internal software error, but I certainly wouldn't have expected this:

taken by my friend Scott.

black is for grownups

Armin Vit investigates color trends in popular movie posters (via information aesthetics). When I first skimmed the article (skipping the words to look at the pictures), I assumed the author had written a program to look at each pixel and graph the color frequency; however, upon reading the text, I learned that this intrepid designer had created the frequency graphs by hand based on his impression of dominant colors, which is arguably a more accurate approach. (Is there any truly great designer who is not obsessive?)

"...a movie’s theatrical poster is only a very small part of the larger marketing and hype machine that turns movies into spectacular blockbusters, but as part of a whole, they are fairly representative of the “image” of any given movie. So, as an exercise in color trends, and to see if any significant pattern emerged, I decided to break down the colors of 25 posters — the top 5 of each MPAA category."

"it is nonetheless telling that black is the color of choice in movie posters. Chalk it up to contrast if you want, but also don’t forget how many of our clients are afraid of using black, as they usually deem it scary, gloomy, heavy or depressing — and people that wear black are either mourning or designers caught in a time warp of the 1980s"

smart meet beautiful

This is old news, but I just listened to an interview with Jenny Lam from Jul 6, 2006. It's about her designs for Vista, but she talks a lot about her design philosophy, which she describes as "smart meet beautiful." The interview was quite long, but there are some nice nuggets of truth and a peek at this designer's inspiration.

She talks about creating distinctiveness, emotional connection and a brand. "Branding is not just about putting logos everywhere. Branding is an end-to-end experience... We don't own the brand... Our users own it. They define the perception of it. We can just influence it with the products we build and the service we give them." She describes adding animation, as "adding a nice touch to make it alive."

When asked what inspires her, she speaks of her design heroes, getting together with creative colleagues, and doing design outside of work too. She highlights one of her heroes, Bruce Mau, who she describes as more of a philosopher. She recently saw an exhibit of his in Vancouver called "Massive Change" about how design can change the world, even save lives. I love hearing about how people are inspired.

She's now at Jackson Fish Market, a small design firm in Seattle.

emotional design of the iPhone

Nicole Lazzro, founder of XEODesign, was interviewed by Robert Scoble at iPhoneDevCamp (via David Temkin). She talks about the stroking, bushing and scaling gestures that are part of the iPhone interface as "loving, tender, friendship gestures" instead of poking which is a more aggressive motion that we typically use for interacting with computers and devices. Elements in the design of the iPhone cause specific emotional reactions. XEODesign did a survey of how people described the iPhone and they used words like wonder, curiosity and magic.

Lazzro describes the iPhone as not just easier to use, but that there is "less between me and what I desire," citing the example of sharing, one of many iPhone interactions that seem to have been designed around well thought out use cases. At XEODesign, they catalog and measure emotional reactions when they do usability studies. She notes that f you watch people use technology you can track their emotional reaction to it. In games and interactive technology, you see emtions that happen in sequence. In the iPhone, curiosity leads to surprise leads to wonder.

Lazzro suggests that naming and describing various emotional responses can help inspire design, and you can plan when you want to evoke surprise, amusement, or "easy fun." In several cases she has borrowed words from other languages, since there are a number of emotions that we don't have a word for in English, such as "fiero," which she translates as the feeling of "yes!" when you just won the Grand Prix. She points out that this is not just "eye-candy"; it's adding emotion to the design.

seeking beyond the accountant's truth

I've been struggling with how to express a particular aspect of what we call the cinematic user experience: how film creates an emotional connection with the viewer and how such a connection also enhances software design.

Helena Kimball mentioned to me that she heard something on the radio that seemed connected to this. By the magic of the internet, I was able to translate "I heard it on NPR this morning" into "Fresh Air interviews Werner Herzog on the Story Behind 'Rescue Dawn'" In it he says:

"What constitutes truth? In, for example, a great poem, when you read Robert Frost, and you have some very deep feeling about it, and all of a sudden you have this sensation there is some deep inexplicable and mysterious truth in it; and the same thing happens in movies. And it does not happen strangely enough in most of the documentaries that you would see on television. You would not find it in the so-called cinéma vérité which can only scratch the surface of what is truth: it's the accountant's truth; it's the bookkeeper's truth. And yet I have been for years after the question: how can you dig into a very deep stratum of truth, into something inexplicable, something mysterious? And, of course, you can reach it, and you can find it, but normally through invention, through imagination, through fabrication, sometimes even contorting and stylizing events right out there, and then all of a sudden you will find something strange and deep and elusive and that is a certain truth."

I hesitate to compare the truth of a man's experience of war to the truth of reading your email or filing your taxes. Sometimes the reality of software design seems so mundane as to be almost petty, and yet, I feel it important to honor the people who pay money for and especially those who spend time with the software that I write. These moments of their lives are important and hold their own truth.

Graphical user interfaces have traditionally been so devoid of emotional content as to be dehumanizing. Of course, this lack of emotional content was expressed as a virtue: all Windows applications should look the same lest we confuse the poor users. Who would recognize a button were it not a 20 pixel high embossed rectangle with a text label or a similar square with an icon?

Then along came the web, which broke all tradition. Taking a look at the very basic evolution of the button: the web's original blue underlined links were quickly augmented by graphics that matched the overall personality of the website. Yet despite this altered look, people were still able to recognize a button when they saw one (for the most part). The unique look of each website reinforces a feeling of place, and I believe, the unique look, in context, reinforces a relationship between the viewer and the website, augmenting the experience.

In another interview, Herzog says "You have to invent. You have to stylize. There's absolutely no danger in that. The danger is to stupidly believe that depicting facts gives us much insight."

minority report interface

Minority report is a must-see movie for UI geeks. It seems to have inspired a new generation of UI innovation, or perhaps, a new generation of designers and developers and Stephen Spielberg are all thinking along the same lines.

There are some inventions that use cameras and Pointscreen (video) which works by sensing electric fields (inspired by the Theremin). But, none seem as responsive as the multi-touch interface demonstrated earlier this year by Jeff Han at the TED conference.

(this video via Video Karma via Creating Passionate Users comment)

While everyone is wowed by this technology and wants to play with it, there is still question about how practical is will be in real life. "Ben Shneiderman, a computer science professor at the University of Maryland and a founding director of the Human-Computer Interaction Lab, calls Han a 'great showman' who has 'opened the door to exciting possibilities.' But he doesn't think Han's technology would be suitable for a large-scale consumer product, nor as useful as a mouse on a large display. If you are standing in front of the screen, Shneiderman wonders, how would people behind you be able to see what you're doing?" (via Fast Company via BassicTech) I think the main potential problem is that your arms will get tired; however, the potential risks of RSI didn't stop consumer adoption of Doug Englebart's mouse.

I do think it would be pretty effective for collaboration. I always find it hard to sit back and just watch someone else "drive" when working together on a computer. Of course, we have a long way to go on collaboration software in general, let alone adapting it to this new paradigm. Regardless, I applaud Jeff's innovation and wish him and his colleagues at Perceptive Pixel the best of luck. I wholeheartedly agree with Jeff Han when he says that "interfaces should be conforming to us."

iPhone's cinematic UI

I had the chance to play with an iPhone earlier today. Last week a bunch of us at Laszlo geeked out over lunch and watched the movie, but it is qualitatively different to interact with it for real. Way before I joined the company, the folks at Laszlo coined the term "cinematic user experience" to describe the kind of UI enabled by OpenLaszlo, including animated transitions and other innovative effects that contribute to a more usable, more learnable application. It has been great to see that this seems to be an industry trend with innovations in latest Apple and Window operating systems releases, as well as some desktop apps, and now the iPhone.

iPhone does a nice job with animated transitions: smooth scaling in the web browser, transitions from the menu to specific application, deleting notes, etc. The ability to rotate the phone and see the visual adapt to landscape or portrait is wonderful in the web browser, although it was a little disappointing that the ability to rotate was not consistent across the apps. The calculator felt broken and the music player had a non-transformative snap to a completely different UI, which was a bit disconcerting.

I was very impressed with the responsiveness of the panning and scrolling. I have always felt that performance is a design element. This is dramatic in a device with a touch screen. The fact that the interface is so responsive and the display so crisp removes the need for any additional feedback other than the direct response of the action. There is also a wonderful nuance to how the panning/scrolling is implemented. When you go too far (past the edge of the content) there is a little bounce animation, which tells you that it isn't broken, but that you've just reached the edge. This is especially important in a device with novel interaction to reassure you that you are doing the right thing, but you have just reached the edge of the data. I love the take on this from Creating Passionate Users who describes it as a dog ears experience referring to the fluidity and follow-through of real life, where when the dog shakes, the ears follow the head! I didn't witness it myself, but I was interested to read from Daring Fireball that the iPhone prioritizes feel over look, "if the iPhone can’t keep up and render what you’re dragging in real-time, it won’t even try, and you get a checkerboard pattern reminiscent of a transparent Photoshop layer until it catches up (typically, an instant later)."

For me, a phone has always been for making phone calls. I don't own an iPod and I've always said that I would buy a PDA when they offer one with the resolution and battery life of paper, but I must admit that this latest gadget causes me to reconsider.

I would love to know the people behind the design. This stuff doesn't happen automatically. Are any of the UI design team or engineers who wrote the code blogging about it? Creating great user experiences is all about getting the details right, I'd love to hear some of the stories from the folks who made it happen.

software has a voice

I've always felt that software had a voice, so I was intrigued reading the Voice of Tango about the effort to write a true dialog for H&R Block's new tax preparation package "Tango." This is a heck of a lot more concrete than I had been thinking of, but a fun read.

I always thought of a voice expressed in pixels, buttons, and menu items. Too many options presented at once just makes it hard for people to find anything. As designers, we need to choose what is important and let those actions speak loudest. UI design is editorial. As designers, we are pundits, speech makers, propagandists.

In a recent usability test of a new version of Laszlo Mail, we noticed that people always look at the top of the screen first when they are looking for an action. This led some folks in the audience to argue that pretty much every option that was tested should be moved to the top. We're resisting that urge and keeping the most frequent actions at the top of the screen. So what if it takes an extra 15 sections to find the new folder button the first time you look at it? You use search every day. You create new folders once a month, and then only if you are one of those obsessive filers, like me... kids these days just keep everyting in their inbox.

Laszlo Mail has a voice. While I've influenced and developed that voice, it isn't my personal voice. It speaks to people who don't know the difference between a web application and a desktop application... really, why should they care? We've never developed actual scripted dialog for that voice, like the folks who created Tango. After reading about their process, now I wonder what would it say?

The Line Between the Desktop and the Browser has Blurred

"It's 1984. You turn on your brand new 128K Macintosh and what do you see? A virtual desktop with files, folders and a trash can. The core metaphor is built around applications that edit documents stored locally. After all, the Internet isn't part of the picture. You're a computing island and your new computer isn't intended for communications.

Now, it's 2006. You turn on your brand new wireless laptop (with a gigabyte of memory) running Windows or Mac OS X, and what do you see? A virtual desktop with files, folders and a trash can. Really, nothing significant has changed—even though literally everything has."

The Messaging News article that I wrote last year is now online (see p. 43). In it I talk about Laszlo's new Webtop product, although I couldn't mention it explicitly since it was under development and unannounced at the time.

Also, after reading Martin LaMonica's perspective on the geekiness of WebOS, I wrote yesterday on the Laszlo Mail blog about some of the motivation behind Webtop in the context of Laszlo Mail:

"...I gotta wonder whether the Web 2.0 crowd is missing the point. We’re not creating elements borrowed from a traditional OS desktop on the Web out of sheer technical exuberance. The web has out outgrown its standard page paradigm with simple, serial transactions....The real WebOS work going on supports what regular folk just expect from the web. Why wouldn’t a web application work just like any other software? People are seeing rich, dynamic graphical user interfaces when they use an ATM. They certainly don’t expect any less when they go to their bank’s web site."

parking meter UI

A year or two ago, new parking meters appeared by the train station in San Mateo. I suppose these were someone's bright idea about how to save money by installing on one meter for two spaces:

One can only assume that people were confused about how the meter worked, for not very long after signs appeared under each parking meter:

This is one of my favorite examples of bad UI and a poor attempt to correct for it. Notice that the meter labels the spaces "left" and "right," while the sign refers to "SPACE A" and "SPACE B."

HyperScope release

HyperScope , a modern Ajax-ified version of Doug Engelbart's Augment System, is released as open source (under GPL) in its initial version. There's a demo of the system which presents some of Doug Engelbart's writing and is a good way to get to know the goals of the system. There is a lauch party tonight.

"Man's population and gross product are increasing at a considerable rate, but the complexity of his problems grows still faster, and the urgency with which solutions must be found becomes steadily greater..."
from AUGMENTING HUMAN INTELLECT: A Conceptual Framework. (direct link to quote 1a2)
By Douglas C. Engelbart.

It is so exciting to see this technology which was ground-breaking (and fully functioning!) in the 1960s brought forward as an open source project. Congratulations to everyone who made it happen.

reflections on email

Over the past couple of years as I've been leading the development of Laszlo Mail, I've been spending a lot of time thinking about email UI. I've marked 2004, as the year of webemail innovation. Email user interfaces had appeared to stay relatively the same for decades. While webmail has proliferated in previous years, vendors had accepted the click-whole-page-refresh limitation of the early HTML standard.

In 2004, we started to see changes happening. Oddpost replicated Outlook UI inside Windows IE and then went beyond email to integrate RSS and some innovative calendaring features. Gmail was launched with a very different approach to displaying lists of messages and conversation threads. With wicked fast search, huge amounts of storage and tags instead of foldering, the Gmail developers challeged the traditional model of sorting and filing. At Laszlo Systems, we started prototyping Laszlo Mail, a webmail app with a cinematic user experience, melding the traditional 3-pane display and direct manipulation of a deskop email app with a new design aesthetic. Yahoo acquired Oddpost. In late 2005, Zimbra launched their app borrowing many features from Gmail and Oddpost and adding a new twist where businesses could integrate back-end systems like UPS tracking to provide extra context to email messages.

By Dec 2005, Lee Gomes of the Wall Street Journal wrote The Men Who Came To Dinner, and What They Said About Email. An avid fan of Laszlo Mail suggested that my mission for 2006 was to be invited to dinner by Lee Gomes for the follow-up one year later. At the time I wondered whether the spurt of innovation was over and whether this was just the mainstream media catching up on the technical innovation of the previous years. Did this UI innovation even matter to most folk or do they just flock to Gmail lured by gobs of free space? I'd like to say that by this time the new webmails had been vetted by the masses, but Yahoo was in private beta, Gmail invite-only, and Microsoft's newest forray still under wraps. Laszlo Mail had just launched, lacking the fanfare of the big companies.

Back in 2004, Eudora was my email app of choice. Later that year I moved to Thunderbird, seduced by the quick search/filter feature, plagued as I am by a very large inbox. (It is notable that I stuck with Eudora for so long, despite being frustrated by what I believe was a specific, intermiitent Exchange/Eudora bug that had plagued me across two companies, where every 4-6 weeks my inbox would spontaneously decide it needed to download a new copy of every message on the server. An odd and disturbing behavior that I learned to recognize and workaround when it happened. A personal demonstration of what people will put up with for a UI that they love.)

I grew fond of Thunderbird. It's nuances become integrated into my daily life. I took advantage of its features and worked around its limitations. Thunderbird became my standard for what a good email experience was. On our team, we had strong advocates for Apple Mail, Outlook, and Pine. Freedom of choice in your everyday tools is a strong part of the Laszlo corporate culture and the diversity of personal experience on the mail team had a strong postive influence on our design choices. About a year ago, we deployed Laszlo Mail internally for us all to use for our own company email, but it wasn't until January with the addiiton of filters that I began to use it full time. I must admit, that I missed Thunderbird, but I care about my product and wanted to make sure that we fixed any issues that got in the way of a good experience.

A few weeks ago, I turned a corner. We did not release a new verison of Laszlo Mail -- no new feature development or bug fix caused this change. I opened Thunderbird because I thought a particular task would be faster or easier with that app, and I gave up and I went back to Laszlo Mail. I've realized that there are a collection of features that make the Laszlo Mail experience better for me. In some instances, perhaps the very the limitations of the web have driven us to create alternate, more effective solutions. In other instances, it's just the delightful imagination of our designers and attention to detail by the engineers. In any case, from my personal experience, these are the features that make the difference:

* immediacy: Laszlo Mail starts up faster than Thunderbird, and data is always fresh. I've grown used to the fact that when I look at a folder, it has fresh data in it. Instead of opening my Inbox and first looking at the emails recently received when I last logged in, then being suddenly disrupted by the appearance of new emails, my Inbox always shows the most recently received.

* ever-present search: I really like a search folder that sticks around. I didn't expect that this design would have such an effect, but it's nice to go back and forth between my search results and other folders without having to re-type the search.

* integrated contacts list: In Laszlo Mail, you have to add someone to your address book to get them into the auto-suggest list, so I use it regularly. Since I'm using it anyhow, I tuck other info away in there. I've never used the address books available in other email programs. I tried with Thunderbird for a while, but it just wasn't was convenient for some reason. I'd like to make the collecting of contacts a little more automated -- it'll be interesting to see whether that would cause me to use it more or less.

thoughtless acts?

How does our environment influence our behavior? This lovely book, by Jane Fulton Suri + IDEO, highlights things we do as we interact with the objects in our world and with other people. It challenges us to consider: which of these acts are conscious and which are done without thought? How do we react, respond, co-opt, and confom to our world? How do we create signals to other people about what belongs and what should happen?

Some of my favorites:

"reacting? ...we interact automatically
with objects and spaces that we encounter"

"co-opting? ...we make use of opportunities
present in our immediate surroundings"

"adapting? ...we alter the purpose or context of things
to meet our objectives"

"conforming? ..we learn patterns of behavior from others
in our social and cultural group"

If the book isn't enough, or if you want to participate, there's also a Flickr group on the topic. Here are some highlights:
   

"Problems worth solving... It's a mistake to interpret observations too literally, though: the world doesn't need a uniquq design solution for every creative adaptationwe see (that's the kind of stuff that ends up advertised in in-flight catalogs!)"

The book has a very nice web site, which cycles through a selection of photos from the book when you click on different sections; however, you the object itself is really very wonderful. You should buy it or ask me to show it to you the next time you see me :)

Bruce Sterling on Story Telling and Game Design

I just read Bruce Sterling. The Wonderful Power of Storytelling via Luke W. I believe that storytelling is a powerful element of great software design, and probably game design as well (although I'm no game designer). Despite his contrarian argument, I enjoyed reading his talk. Here are some highlights:

"Don't become a well-rounded person. Well rounded people are smooth and dull. Become a thoroughly spiky person. Grow spikes from every angle. Stick in their throats like a pufferfish."

He paraphrases what he calls the the classic doctrine of Humanist SF as it applies to computer game design:

"Movies and plays get much of their power from the resonances
between the structural layers. The congruence between the theme,
plot, setting and character layouts generates emotional power.
Computer games will never have a significant theme level because
the outcome is variable. The lack of theme alone will limit the
storytelling power of computer games.

"Hard to refute. Impossible to refute. Ladies and gentlemen to
hell with the marvellous power of storytelling. If the audience
for science fiction wanted *storytelling*, they wouldn't read
goddamned *science fiction,* they'd read Harpers and Redbook and
Argosy. The pulp magazine (which is our genre's primary example
of a dead platform) used to carry all kinds of storytelling.
Western stories. Sailor stories. Prizefighting stories. G-8 and
his battle aces. Spicy Garage Tales. Aryan Atrocity Adventures.
These things are dead. Stories didn't save them. Stories won't
save us. Stories won't save *you.*

"This is not the route to follow. We're not into science fiction
because it's *good literature,* we're into it because it's
*weird*. Follow your weird, ladies and gentlemen. Forget trying
to pass for normal. Follow your geekdom. Embrace your nerditude.
In the immortal words of Lafcadio Hearn, a geek of incredible
obscurity whose work is still in print after a hundred years,
"woo the muse of the odd." A good science fiction story is not a
"good story" with a polite whiff of rocket fuel in it. A good
science fiction story is something that knows it is science
fiction and plunges through that and comes roaring out of the
other side. Computer entertainment should not be more like
movies, it shouldn't be more like books, it should be more like
computer entertainment, SO MUCH MORE LIKE COMPUTER ENTERTAINMENT
THAT IT RIPS THROUGH THE LIMITS AND IS SIMPLY IMPOSSIBLE TO
IGNORE!"

puppylike accessibility

I really enjoyed Paul Boutin's article "A Grand Unified Theory of YouTube and MySpace." He suggests that YouTube and MySpace have become smash hits not because of their social networking features, but because they are "easy to use, and they don't tell you what to do." Here are some highlights:

"Given up on BitTorrent because it feels like launching a mission to Mars? If you've sent an e-mail attachment, you've got the tech skills to publish on YouTube."

"I think MySpace's popularity has to do with its puppylike accessibility. A typical page looks like something a Web-enthralled high schooler might have put up in 1996, but with more pics and a soundtrack. I agree with design guru Jesse James Garrett, who says the site's untrained layout sends a "we're just like you" message to newcomers. That encourages them to experiment with content genres the site's designers didn't build into templates."

"The easier it gets to use, the less geeky the Net becomes, and the more it starts to look like real life."

Putting the Fun in Functional

I enjoyed slides from Amy Jo Kim's talk at Etech (via LukeW). I found particularly intriguing her definition of a game.
The formal definition: a system in which players engage in artificial conflict defined by rules, that results in a quantifiable outcome (Rules of Play by Eric Zimmerman and Katie Salen) seems uncontroversial; however, I'm not sure I agree with her informal definition -- a structured experience with rules & goals that's fun.

I've got this project at work. It's a structured experience -- it's work after all. There's a goal. I have a partner and a time limit. There is even a compiler that enforces some of the rules. And it is wildly fun. I put on my headphones and listen to pandora as I tap away at the keyboard. There's a thrill of excitement when things work as planned. There's even a joy to the struggle to discover what's went wrong when they don't. It's the kind of project I might do for fun in my spare time, if I had more of it, and I'm jazzed that I can actuallly get paid to have such fun.

I've written about this before, sometimes work can be play, but I wouldn't characterize it as a game. I think the difference is when the activity is not artifical, when it has a purpose. Nonetheless I applaud Amy Jo Kim's effort to put fun in functional. I absolutely agree that we should all be writing software that helps people acheive their goals while having a good time. Positive feelings and emotional engagement make us more creative, flexible and productive; but even if that were not true, enabling the pursuit of happiness is not just a good idea, it's a constitutional right.

omit needless words

There's been some confusion about what laszlomail.com is for, despite the fact that we have text on the front page that says its for communication service providers. Doh! No one reads text.

Steve Krug suggests we should "omit needles words" in his book Don't Make Me Think, A Common Sense Approach to Web Usability.

Get rid of half the words on each page,
then get rid of what's left
-- Krug's third law of usability

change blindness

"Change blindness is the striking failure to see large changes that normally would be noticed easily."
Daniel J. Simons and Ronald A. Rensink, Change Blindness: Past, Present and Future, Trends in Cognitive Sciences, Vol.9 No.1 January 2005

"...observers often failed to notice large changes to photographs that were made during an eye movement [5]. For example, 50% percent of observers failed to notice when two cowboys sitting on a bench exchanged heads! These shocking results inspired others to examine whether similar failures could happen in other ways, and in the absence of eye movements. In one of these new paradigms – the ‘flicker’ task [1] – an original and modified scene alternate repeatedly, separated a brief blank display, until observers find the change. Observers eventually find most changes, but can take an astonishingly long time to do so, even for large changes."

If you don't believe this, check out Rensink's Java applet that illustrates what he calls the "flicker paradigm". Two images flicker back and forth. With a 250 ms gap between images, I spent minutes looking for the difference. At 150 ms, I saw the difference almost immediately. With no gap, the difference is striking. Here is clear evidence that "no page refresh" apps are not simply less annoying, but clearer to understand.

the value of consistency

David at 37signals writes that the days of consistency are over (via HMK's Spurious Thoughts):

"With the introduction of iTunes 5, Apple removed all and any doubts. The days of consistency for user interfaces in the look and feel department are over. The rise of the web killed it and Apple is riding this new wave with no regards for the old HIC guard."

When Bret Simister and I gave a talk last year at BayCHI about Laszlo's Cinematic User Experience, a member of the audience asked what we could do to ensure consistency in this new space. We held the controversial stance that the genie was already out of the bottle. Since web sites are not consistent in look, web applications need not be. Establishing identity is a crucial part of web design and it is our responsibility to enable web applications to have a unique style.

If you closely compare iTunes 4 vs. iTunes 5 you can see that many of the design details as different, but one could hardly argue that the average human would not be able to understand the interface because of those differences. I would even put forth that the average human would not even notice the visual differences: brushed metal vs. gradient, the corner radius and margin size.

Visual changes themselves do not compromise usability. More significant is consistency in behavior. When we provide rollover feedback on a small square, rectangular or oblong area of the screen, it is readily recognized as a button which may be clicked. Scrollbars are as easily identified, whether the arrows are brief chevrons or filled triangles, despite alternate layout or color. There are a dozen or so familiar knobs and dials easily recognized in your typical application by their general shape or shadow and how they react to you. The exact pixel dimension, color or symbolic representation is less important than the way they feel.

time as a design element

I ran across a reference to Dan Boyarski and his class on "Time, Motion, and Communication" at CMU while reading an interesting thread kicked off by Dan Saffer on the idxg list (via Dani Malik at Laszlo). He questions the role (or lack thereof) of the page in "Web 2.0" . Inspired to learn more, I enjoyed reading Dan Boyarski's keynote speech for Designthinkers 2001.

Dan Boyarski talks about his discovery of teaching motion, rhythm, and time in a typography class. I wish I could see the visual presentations that went along with this talk, and not just a transcript, but I can imagine from his vivid descriptions. He talked about how he invites folks from the drama department to talk to his students. They start using theater words to describe a presentation, like the design students are directors, which of course they are.

It is wonderful to read about his transition from purely print design to motion graphics and interaction. He also talks about about the web:

"The web right now replicates paper. The web replicates books. And that's natural. McCluhan had a wonderful saying about 'driving into the future looking at the rear view mirror' because that's what we know. That's what we've left. That's what we're comfortable with. We're comfortable with books, so we talk about web pages. There's nothing physical on the web and why do we still put pieces of paper on the screen and you click on a button, another piece of paper comes up. Click on another button, another piece of paper comes up. We've forgotten that that screen is simply a window into a space."

What else can we do, but learn from our experiences and apply those experiences to a new medium? Is "a window into a space" any less a view from our rear view mirror than a page in a book? Metaphors are useful. They help us find our way around. Despite their familiarity, actually because of it, they help us discover (or invent) new parts of a working system. We need to start thinking about the web with new metaphors when we want to create things that don't fit the old ones.

The web was created mostly for publishing documents. The page metaphor is unsurprising and has proven useful. Layered on top of that are links, with anchors, and navigation that let us travel from web site to web site. Oddly a set of web pages are not referred to as a book, but rather as a place. These mixed metaphors are not a problem, but rather each has its own domain, and these domains overlap to cover what might otherwise be a disturbing and disorienting venture into cyberspace.

Boyarski points out that we've "forgotten" that we are not restricted to the page metaphor. Software is flexible, and can create an alternate model. In particular, web applications have evolved that don't particularly fit the page metaphor, but changing the metaphor requires both a shift in technology and a different approach to design.

Working at Laszlo, which coined the term Cinematic User Experience, I've enjoyed diving into an alternate, more appropriate metaphor for application design and development. I may be called a "software architect," but we don't create blueprints for an application, we create story boards. We write scripts which drive the development of initial prototypes. The application changes over time in a way that is analogous to film, but the changes are typically triggered by user interaction or changes in data from the network. We borrow other words from film and video production to describe transitions. A new element may slide in or fade out.

The metaphor isn't a perfect fit and it doesn't need to be. Its comfortable, yet can lead me to think in new ways about an old problem. Sometimes watching a film or the evening news can provide an idea to apply to this new medium. Like a student that Dan describes who borrowed the motion of elevator doors opening to pace his animation effectively, sometimes it helps to look in the rear view mirror while we create the future.

subjective performance

We've recently changed bug databases from Bugzilla to JIRA. We made this choice since JIRA allows us to effectively manage multiple projects for multiple customers. I also really like the home portal UI that lets me set up my default view to have custom reports and bug lists. However, I find it hugely frustrating because JRIA feels much, much slower than bugzilla.

It is interesting to note that the perceived slowness is not only due to the speed of fetching each page. (Both systems are pretty standard HTML web applications.) Bugzilla has only one view for bugs, which allows you to view and edit details. When I look at a list of bugs in JIRA, I need to click once to view the bug, then click again to edit it. I didn't mind this too much when I was using JIRA as an engineer on OpenLaszlo, but when we switched to using it internally for a project I'm managing, it is a different story. As an engineer, I look at bugs more often than I edit them, and I frequently make a only single edit per session. When managing a project, I look at overviews of dozens or hundreds of bugs at a time; I know the details of almost every bug, so I rarely need to view the whole bug report, but I often need to change the priority, milestone, or who the bug is assigned to. I often go thru a list of bugs and need to edit each one.

So... the bugzilla workflow is this:
1. find list of bugs that I want to modify
2. click on the first one
3. make my edit, it automatically shows me the next bug, so I can go immediately repeat this step

In JIRA, the workflow is:
1. find list of bugs that I want to modify
2. click on the first one
3. click edit
4. make my edit, OK returns me to the non-editable bug report
5. click next, got to step three

That is 3 more clicks for each bug. So, even though each page request may only be 50% slower than bugzilla, my typical operation is 3x slower than that. This could be easily fixed in the UI by adding an edit link to the bug list and an "edit next" option after editing an item in a search list.

At Laszlo we talk a lot about subjective performance vs. quantitative performance. Sometimes something is the same speed by the stopwatch, but can feel faster or slower depending on user feedback (or lack thereof). It is also important to look at use cases, particularly use cases for repetitive actions.

It is also really interesting to notice how everything feels difficult until I'm used to it. I like to know where I am and how to do what I want. I'm used to that in the interface I'm used to. Even though I hated it when I first learned it. It is the devil I know. Using a new application, I am hugely frustrated when I don't know how to accomplish the task I have in mind. In some cases, I can see that the UI is not actually any worse, only different, and I have to laugh at myself as I grind my teeth and force myself to actually read the screen before knowing what to click.

Geek User Interface

When I started at Laszlo over two years ago, there were two kinds of engineers at the company, those who used emacs and those who used vi -- roughly divided by coasts, with emacs in the east and vi on the left. I had thought that no one would use vi by choice, that it was only used when people were stuck with no other option, remotely logged into a server. I had learned to use vi a bit in college. Just enough to hobble around: dd, d$, cw, :q, :w, :q!. I was horrified. Who thought up these bizarre key bindings? I left college for jobs writing desktop applications, secure in my certainty that this appalling example of software engineering would surely die a quiet death, drifting into historical obscurity.

Lo and behold! vi was alive and well in San Francisco, installed on desktops where a perfectly usable GUI editor might be found. I was in for a bit of culture shock, and it ran in both directions. Adam Wolff asked in my interview what my favorite editor was. I told him I didn't have one. He was taken aback, but I had been working for over ten years in an environment where my choice of compiler dictated the editor I used -- from Think C in 1990 to Visual C++ in 2002. I was impressed with Adam, but I couldn't believe that someone so apparently intelligent and savvy about user interface design and development could possible choose vi as an editor. I took the job, but remained puzzled.

Seeing Adam in action, my perspective on vi was forever changed. At Laszlo, the engineers who give presentations have this knack of illustrating the LZX language by writing an application from scratch starting with a blank page. It is impressive and fun to watch. When Adam does this it is performance art. His hands never leave the keyboard. His attention is focused on the audience and the task at hand. Using vi's folding features, he can keep key parts of the application on screen, even in a small window. Watching him use vi, it looked easy and fun. I saw that there was method behind the madness of the seemingly bizarre key bindings. It is geared to optimizing your finger positions on a good old qwerty keyboard.

Despite these apparent benefits, I opted out of that learning curve. Instead I settled into happy coding for with IDEA from IntelliJ, until a couple of months ago when my world slowed to a crawl. I sadly discovered that my IBM laptop had misplaced half its RAM. I could no longer run tomcat, Firefox, IE, Thunderbird, and IDEA and get anything done. While I awaited a replacement computer, I discovered that if I ran tomcat, Firefox, and vi -- just the bare necessities, I would stay just under 512 MB of RAM. Even though I was more proficient in Notepad and I had deadlines looming, I settled in for a steep learning curve.

I am fortunate to be immersed in a particular flavor of geek culture where people enjoy sharing know-how. In fact, the vi-o-philes in the offices were downright delighted to help me configure my vimrc or teach me new commands while coding together. Scott Evans even bought me my very own vi reference mug.

As it turns out, there are patterns in the key combinations that make it so that once you learn all the variations on one command, you know how to use a whole lot of them. So, with my knowledge of dd (delete line), d$ (delete to the end of line), cw (change word), I learned that dw means delete word. Then when I learned about yy (to 'yank' a line into a buffer to later 'put' with p), I automatically know yw and y$. When I learned how to delete 3 lines with 3D, I also learned what 3Y means. Also, vi has gotten better since I was in school (I use gvim on Windows which has menus and even lets you use the mouse!)

This is Geek User Interface design, as opposed to the "human" interface design of the Graphical User Interface. It rewards people who are pretty good at remembering arbitrary, but useful sequences of letters.

This experience reminds me of Doug Engelbart and his bicycle analogy. "The tricycle may be easier to learn and use, but it is hard work to travel even a short distance. Riding a bicycle calls for considerably more skill, with bumps and bruises expected as one learns, but the effort-to-performance ratio is dramatically higher. The high-performance knowledge workers of the future, as perceived by Engelbart, are expected to be very skillful." (2F1B)

So I've got a new machine, which is has enough RAM for a GUI editor, but I'm still using vi. I don't know whether I'll stick with it, but I'm pleased that the common commands are now etched into my muscle memory. If I decide to leave vi for a while, I can always go back, like riding a bicycle :) Sometimes I miss an interactive tree-view to navigate XML hierarchy. I find that grep is no match for a really nice multi-file search UI, but I would miss the simplicity of '/' for searching within a file. I plan to install Eclipse with the latest version of IDE4Laszlo and give that a whirl. We'll see.

GUI conventions

David Heller questions whether there can be affordance and convention in this digital world (via LukeW).

Dave talks about how we as children learn to mimick the behaviors of the people around us. We need only to look at a phone to know how to use it. Children see others talking on the phone, they hear voices through the phone, they have toy phones and most (at least in the so-called developed world) know how to converse on a phone by the time they are three years old. It is only intuitive after demonstration. It is learned socially, through what Dave calls "passive exhibition."

It reminds me of Vygotsky's theories of social learning. In his book, "Mind in Society" he notes that "human learning presupposes a specific social nature and a process by which children grow into the intellectual life around them."

The example of the phone is interesting, since it is learned by both "passive exhibition" and by explicit instruction. Initiating a phone call requires quite a bit of teaching and some advanced intellectual concepts (a series of numbers associated with a person and a place, a series of steps to make the connection). In addition, the effects of the phone conversation are not intuitive or easily observed. I remember my son at three years old talking on the phone and showing off his new toys without realizing that the person on the other end couldn't actually see him. When everyone else who talks to you can also see you, why should the person on the phone be any different?

David Heller argues that in designing computer software, we cannot take advantage of this social learning. "The computer, the PC more specifically, does not have an analog to that experience. The PC is primarily used as user in front of screen an keyboard. It is an isolating device that you seldom every see others passively exhibit."

While its true that the occasions to learn how to use software through social observation are limited, I have noticed that people learn this way anyhow. How many times have you worked on a project with someone and picked up tips on using software from them? Only the geekiest amongst us learn from the docs, the rest learn from lore that is passed from colleague to colleague, whether verbally in the office or via the communal written work of blogs and forum postings. I believe that we as humans tend to seek a social learning situation even when the medium isolates us. This is why many writers have writing groups -- not where they write together, but where they learn about writing through reading and talking.

"As IT systems finally make their way into the non-info service sector such as health care practices, blue collar e-learning, etc.we are starting to really see that our notions of �conventions� even the most basic are just totally bogus. People can�t even use a mouse, let alone know that a blue under lined piece of text means something that will show me something else."

Here are a few basic conventions of GUI:
* objects that are clickable provide feedback when you roll the mouse over them
* if you see a blinking vertical bar you can type text there
* blank bordered rectangles, often with labels, will show that blinking vertical bar if you click on them or tab to them

None of these conventions have anything to do with the real world, and I would guess that the vast majority of people who use computers learned these conventions from another human being. While its true that these conventions are not intuitive, they are none-the-less real conventions that persist across almost all software today.

Most people learn those basic lessons in their first experience using a computer and all the rest of our sophisticated user interface elements are built on that shared knowlege. As people move between applications, user interface elements that are shared between them are established as conventions. Objects such as scrollbars, radio buttons, and menus become familiar, if not intuitive.

While I would argue that current software UI conventions are valid, I completely agree with Dave that what we've got now is insufficient to make software and web sites approachable for the general population. I also agree that we can do better, that it is possible to create new UIs that feel familar and make sense to folks who are not members of the digital elite.

do what I mean, not what I say

Interesting post on The Old New Thing: "People lie on surveys and focus groups, often unwittingly."

Software engineers, usability reports and marketing groups often interpret what people say too literally. As humans, our words are imperfect approximations of our perceptions of reality. I always try to do what they mean, not what they say. Whether that person is part of a focus group, participating in a usability session, or my boss. Its a tough challenge. It requires developing a mental model of the individual and their perspective.

"Just because people say they would do something doesn't mean they will."

Its a good point that people are quick to say what they want. Its harder to figure out what they need: what they will pay money for or what they will actually spend time on. People can't necessarily imagine what the software will be like when its finished. Sometimes they imagine that you will solve problems you haven't even thought of yet, or they can't see past a temporary flaw or limitation of a prototype. There is a gaping chasm of difference between regular folks and those of us in the software industry. The words we speak between us are founded on unspoken assumptions.

I remember a focus group where the results were reported by a particularly insightful product manager. He said that people at first responded warmly to the demo, but at the end said that they wouldn't use the new software. He remembered that they were a few times during the focus group that the new software failed (it being a prototype, rather than released software). It is likely that what the people were really saying was: the software I use now is reliable; I wouldn't use this new software because it doesn't work.

I find it easiest to find the truth in watching what people do. It hard to do this when developing software, since you have to sit people down in front of something that basically works and carefully watch where they move the mouse and what keys they type. Did they right-click that icon because they really want to control it using a context menu or was it that the interface failed to surface the command a better way? Then you have to be willing to go out on a limb and change things and test again. And at some point, you have to make a call that its good enough, because there is no perfection in human experience.

UI for staying in the flow

Computers should help us concentrate on our work, without concentrating on the computer

Ben Bederson has written an interesting article "Interfaces for Staying in the Flow" (via Surf*Minf*Musings).

Five characteristics of flow (observed by Csikszentmihalyi):
1. Challenge and require skill
2. Concentrate and avoid interruption
3. Maintain control
4. Speed and feedback
5. Transformation of time

I was interested to read the discussion of animation between screen states as a way to reduce the perception of interruption. "While animation in general can be used in ways that are very disruptive, we have found that animation can be helpful if used to help users understand how the interface changes. The potential for this kind of animated transition is that it can reduce the cognitive overhead of understanding of the relationship between two screen sates, thus enabling users to stay focused on the task...Reducing the need for users to consciously make connections between different interface states has the potential for reducing their short-term memory load."

While I have often experienced the transformation of time associated with flow. I never thought to measure it in usability studies. "People regularly report that their perception of time changes when they are in the flow." Bederson reports that Czerwinski, Horvitz and Cutrell "found that the more difficult the task, the longer the participans thought the task took relative to the actual task time."

agile web site development

Jason Fried spoke yesterday at Web 2.0 in a talk titled "Ligtweight Business Models." I might have titled his portion of the talk "Agile Design." It seems like the ideas from Xtreme Programming aka Agile Development are cropping up for non-programmers. This internet savvy generation is not content as a worker bee within out-dated structures that supress creativity. I see more often this relentless pursuit of effectiveness.

I'm diving into yet another exciting project with an insane timeline and a small team. I enjoyed the reminder that those constraints can be a key success factor. Here are some of the highlights from Jason's talk about best practices in designing and building a web site (along with my interpretations):

* Start with the Interface: Design the interface first. Worry about implmentation second. The architecture of the code and the data model needs to support the UI, not the other way round.
* Say no by default: Of course, you don't actaully say no, but don't add a feature just because someone asked for it. Give them what they need, which is often not precisely what they asked for. Often fewer features done better is the right answer.
* Iterate quickly: making it real helps the design process. Jason had this great Christopher Alexander quote that I wish I could find about when designing in a real setting, ideas tend to converge, but when its hypothetical, ideas often diverge.
* Use it while you build it: we all need to use the software we build, during the development process. You are your own best beta tester.
* Iterate in the wild: let real people use the software while you are still working on it. This lets you see real patterns of beahvior and make critical corrections. Its also fun to see your stuff in action.

Working styles can change when the instant comunication of the Internet is asummed. Whether it is the near-instant feedback loop of google's ad sense or the "ability to iterate in the wild," this new working style is affecting engineers, designers and marketing folks alike.

good vs. great UI

I believe any engineer can create good UI. With basic communication skills, anyone can come up with reasonable words to describe user actions. Desktop applications provide numerous example patterns for the use of common UI elements such as radio buttons, checkboxes, toolbars, and palettes.

Anyone can informally watch a new person use the software. There are plenty of candidates: your non-geek friends and loved ones, a product manager or marketing folks. Bad UI is a bug.

Great UI is something else entirely. Great UI requires inspiration. For graphical user interfaces, it requires someone who can do visual problem solving, someone who understands that the design needs to change depending on whether there are 2, 3, 4 or N elements. Visual problem solving requires an understanding of how shading, color, shape and placement affect our perception. Its amazing how a few pixels can dramatically alter the effectiveness of a UI element. It's important to know all of the cookie cutter solutions offered by standard UI toolkits and why they work, when to use them and when not to.

This person is not simply a designer, nor is he or she often a "usability" expert, as our industry commonly defines the role. Usability testing confirms or refines a great UI, but I've never seen it generate one. True usability experts can not only find flaws in a bad UI, but can create great user experiences.