Archives

Building software people love involves learning to read minds – or at least learning to think like your users. In the world of free, web-based software, there will always be 10 versions of every application: 10 different to-do lists, 10 different dictionaries, 10 different bookmark organizers. It’s not enough to meet users’ expectations about features; you’ve also got to delight them if you want to win market share. If you don’t think through every interaction and use case, you’re probably annoying the hell out of people without even knowing it.

That’s why it’s important to actually watch users in action with your application. It’s a maxim in user experience design circles that you, the programmer, are not the user. Sure, you should eat your own dog food, but remember that the experience of using software that you wrote – and whose every shortcoming and compromise you understand from the inside – isn’t the same as chancing upon that software in the wild and giving it a shot. Look at your software through the fresh eyes of users who didn’t write a single line of the code. That’s when you’ll actually learn what you’ve created and how to improve it.

… all of which proselytizing serves only to introduce one rant and one rave about free software I use every day. Neither of these are web applications, but both of them are tied directly to the ‘net.

Ionut Alex Chitu of Google Operating System posted yesterday about Gmail’s evolution from internal beta to public beta to today’s constantly-evolving-but-still-beta version. Gmail’s Humble Beginning never uses the phrases “agile software development” or “user experience design.” (Nor, for that matter, does the original post, by Gmailer-turned-FriendFeeder Paul Buchheit, from which Chitu liberally quotes.) Regardless, the evolution of Gmail provides a case study in the combination of agility and UxD.

Sample quote from Chitu’s post:

Gmail got a delete button after many months of requests from users, even if Gmail’s philosophy was “archive, don’t delete”. Gmail will also add some functionality from folders to its labels, most likely drag and drop.

The key step is to build a product that’s interesting enough to a attract an audience and learn from people who use the product. “The sooner you can start testing your ideas, the sooner you can start fixing them,” explains Paul.

In many development processes, team members are organized by functional group. A project might have a team of developers building the code, and then down the hall or across the globe, a separate team of designers working on the visual and usability aspects of the application. The two sub-teams are walled off in their own silos, and communication between the two sides is minimal.

This structure is not compatible with an Agile software process — it’s too hard to get rapid feedback between the teams that make a process truly Agile. Worse, if the two teams are separated, the odds that they will have a common conception of the project, or even a common set of terms for discussing the project.

The most important step in tearing down the silos in your project is just switching your mindset from function-based teams to project-based teams. Continuous integration spreads from being just something the developers do to a way of making sure that all aspects of the project are in synch.

At the most basic logistical point, the designers and developers should share a common code repository. There’s a certain amount of overlap in the tools used for web applications on both sides. If designers can see the latest version of the application when making CSS or HTML changes, then developers can see those changes and work with the most current design as quickly as possible.

In order for this structure to work well, each side needs to move out of its silo and toward the other. Developers need to have an awareness of usability and design issues, and be able to discuss potential problems with the designers. Developers also need to be willing to do any rework that will be needed as the design changes.

Designers need to be willing to work at least some of the time in the developer toolkit, working with source control, able to make CSS or HTML changes directly in the code files (even better if the designers and developers can make it easy to make tweaks at the JSP or ERB level). Not everything that a designer does can be captured this way, but using common tools and files where available increases the team’s ability to work together. Sharing knowledge makes the team more able to notice potential problems, and makes teams more stable over time.

Last week, I wrote about how a user proxy can help integrate Agile and User Experience Design.

Once again, let me mention the upcoming book Professional Ruby on Rails. Available mid-February.

Many large ecommerce sites work beautifully as long as users do what they’re supposed to. The minute users make mistakes, however, the UxD falls apart completely. Case in point: Amtrak‘s online checkout process, in which poor choices about error handling can make it a real hassle to check out successfully.

Amtrak’s first mistake was to create an email address verification field. Plenty of usability experts have decried this silly device for encouraging error-free user input. The annoyance would be minor, however, if Amtrak at least autofilled the email verification field for returning visitors. It doesn’t. When you log into an existing Amtrak account and try to purchase, your address is autofilled in the main email field, but it’s not autofilled in the verification field. Because there’s only one field in the entire "Contact Information" section of the page that doesn’t get autofilled, it’s easy to breeze past and not realize that input is required. You go on to enter your credit card information and click "purchase," only to end up with an error. Until recently, that error wasn’t caught by any client-side validation, so you had to wait for a round trip to the server before being notified. Recently, though, the interface has been updated so that you get a 1999-era JavaScript popup telling you to fill in all required fields. It’s nice that Amtrak at least reduced the annoyance of this bug, but why not just fix the root problem by either getting rid of the email verification field altogether or autofilling it for returning customers?

I simply love finding these little gems on my weekly web excursions.  This time it’s a fascinating new piece of software out there called Dasher, and it allows you to write without typing or scripting.  What’s that you say?  How else can you write?  Well…The basic idea is that current methods of typing are inefficient, because they don’t learn.  Let me explain.  Although there are x number of letters in the alphabet, every pressed key reduces the number of available choices for the next key press, and increases the odds that other specific keys are pressed next.  For instance, ‘E’ is much more likely to be pressed after ‘H’ than ‘B’ is, and ‘O’ more likely after ‘G’ than ‘C’.  On current writing technologies it’s up to the user to learn to be more efficient at writing He than Hb or Go than Gc.  But that doesn’t need to be the case.  By taking advantage of the learning and memorization power of the computer, it’s possible to create writing interfaces that guide you through the process rather than just recording what you type.  If you’ll indulge me in some metaphor, imagine rowing down a river.  Dasher is the river with a strong current to wherever your going, and existing typewriting technology is the river with no current whatsoever.   

What Dasher does is use language patterns to present likely letters and words to the user based on the letters or words they have already written.  The goal is to make writing more efficient by reducing work.  There are no keys to press using dasher.  In fact the mouse is never clicked.  The interface allows one to write by simply navigating the mouse down a path–or tree–through the alphabet.  The start screen displays all 26 letters of the English alphabet.  You select a letter by moving your mouse next to it.  As letters are selected, Dasher displays all available letters again, but this time those more likely to be chosen are larger and therefore easier to select.  As you write, you move forward through the tree, and entire words and phrases are displayed in order of likeliness.   

Dasher needs some work before I start using it instead of my keypad, but the idea has real merit, and it deserves to be explored more.  As an interface designer I see at this tool as a great example of how simple interactions, when thought about creatively, with nothing held sacred, can have potentially revolutionary effects on the way we interact with technology.
 
 

Powered by ScribeFire.

I took time out this Christmas season to reformat my hard drive. Yes, it seems pitiful when you work with these machines all day, and have a chance to spend quality time with loved ones how machine maintenance would top the list of things to do. However, it did give me a chance to mull over a bit of design mystery which seemed a decent enough present to share with you all. Cozy up to the fire and let me tell thee about Windows Vista.
Being a Mac user, I do have a generally favorable impression of the Redmond efforts, I have a healthy background in their CMS system Sharepoint, and felt as long as you keep up to date on their latest and greatest (read beta) releases, you can almost forgive them for not being more mac-like. So armed with my copy of parallels, I installed versions of XP and Vista, and when my hard drive went belly up I decided to keep just the Vista version. Vista has a great deal of interesting abilities. I am a big fan of the voice dictation software/interface. In a quiet room, it is almost faster than typing. I think the paradigm of the ‘explorer bar’ is pretty well conceived mashup of a breadcrumb menu plus drop-downs. I’m surprised not to see a web version of this, since it really does have a fairly good affordance to the user of traversing a deep directory structure.

What really bothers me about the switch is the overall ‘blueness’ of the interface. It’s relentless, and of course being good web 2.0 citizens, they got their gradient on, so its basically blue gradients for miles. Now, giving them credit, aqua (mac os x’s first scheme) had the same problem, blue gradients for days, and the extraneous grey pinstripe thing, but yet it didn’t seem as gratuitous as Vista. This is coupled with the inability to ‘go grey’ as XP used to allow. So, by redecorating, vista has ‘painted’ itself into a corner, unless users are expected to select their own gradient mixes (yellow to orange, puce to purple) they are somewhat stuck with blue. Also knowing microsoft, these are just bitmaps, so no redecorating is possible without replacing a bunch of .BMP’s someplace deep in the WIN32 folder.

At the same time, Apple’s Leopard has removed all hints of ever styling the chrome of their windows, even the pinstripe thing is removed and has gone all grey. They have also been having some fun with drop shadows (the ‘other’ gradient), in early beta’s, and in Steve’s intro speech, they spoke of how active windows really stand out. That was because active windows had about 100 pixels of drop shadow built in – which they wisely dumped. Overall, no color seems the best choice, in a black text on grey world, it tends to de-emphasize things well enough to let the user focus on the content at hand, photos, and clickable things (hopefully blue).

So, overall, why blue? If we look to web design, its pretty much the default color. It is hard to find a site that does not use blue as a background or decorative accent. Of course it is the ‘real’ clickable link color, and it is the color of azure sky in deepest summer, which is not a bad thing at all. In fact, since red is out, and yellow is kind of tricky, you pretty much have blue as your only possible primary color choice. However, color wheel not withstanding, it is hard to understand why blue has so much power over our virtual lives. About.com claims it’s the color most preferred by men. It is also peaceful, tranquil, and productive. It is the least appetizing color- perhaps why foodtv chose green?

Perhaps web 2.0 has brought a reaction to this overall blueness, noting ebay has gone with yellow, but there will still be a strong reason to pick blue, it’s like choosing IBM (pun intended) or the reason Microsoft is still the best choice for many reasons, nobody got fired choosing blue. Every other color has strong emotions tied to it, and neutrality (read grey) while being most suited to ‘new’ web design tends not to excite people too much. I actually have a difficult time finding a site where blue is not the predominant non-meaningful color. So, while I’m scouring google scholar for some actual research statistics on this phenomenon, please leave your comments on what interfaces sucessfully break this blue flu, and have a happy 2008!

I’ve been looking around for some data on the life/death cycle of browsers to append to my earlier post. In my early days, there was much drama about the rise and fall of browsers, and the great capabilities these new browsers would bring to the user experience. And when I say drama, I mean it was deadly dull, waiting years for certain ‘problem’ browsers to die out, or for less savvy computer users to get a new computer and finally update that clunker and get a ‘real’ browser. This seemed always to be whatever the latest, greatest beta version by the established titan, or sometimes the crafty underdog. When HTML 5.0 gets integrated into a browser, it will be years for that browser to be adopted, and further years for site developers to take advantage of whatever innovations it offers safely. The days of code bifurcation and browser sniffing are not dead by any means, but they are as usual being ‘phased out’. If you were writing the script for the hollywood version of "Browser Wars" here’s a possible plot outline (If Michael Bey is involved please give me a cut)

1. 1996 Exposition - the masses seem to discover the Internet and Netscape makes it all possible thanks to Netscape 3.0. The world rejoices and refuses to dump this browser for at least 10 years (it may still be in use today ?!)
2. 1997 Rising action - Internet Explorer 4 introduces a whole new world, special effects, DHTML, proprietary image filters and other goodies that take the world by storm, also, they explicitly link their browser with the operating system, so you can’t remove it, and its hell to install a different one (bye bye Netscape). This also starts the nasty reality that windows can only have one instance of IE at a time, so developers rarely have the same browser version as their users, bringing up the popular ‘it works on my machine’ excuse.
3. 2000 – IE 5 for the mac comes out and makes mac users feel cool, superior, and since it diverges from the inexplicable release that was IE 5.0 (for xp?) it becomes the browser of the hip. Cool innovations include somehow integrating ebay bidding someplace.
4. 2001 - IE 5.5 for windows/mac and the last gasp of Netscape Navigator (7?) all come out in one big dump. Browsers seem to have become massive piles of auxiliary interfaces (email, auctions, unknown amounts of crap). I suppose writing a browser means you should do something with all those eyeballs to make money? The box model is broken, web standards seem shaky. The future doesn’t look too bright, users despair.
5. 2003 Climax!- IE 6 comes out to wipe everyone off the map, all those custom hacks for IE have paid off as it destroys all other browsers (mac users need not apply) and the dynasty is secure. It has enough to make web 2.0 happen, but not enough to appease the web standard crowd coming into being. People think about using div’s for layout! Since old windows machines all succumb to whatever that horrible virus was, people upgrade their computers and IE 6 gets you about 80% of browser traffic, so microsoft goes off do do something else for about 5 years.
6. 2004 The rebels attack! Mac Safari and OS X comes in to challenge the dominant browser, and on a good day, when the wind is right they can get about 1% of browser versions.
7. 2005 Denoument – The flaws in the reactor are finally uncovered and the plans to the rebel base are brought to Mozilla which takes on the Windows empire with Firefox. Even average users tired of endless security attacks flee to embrace the upstart. On a good day, mozilla gets a 10% share of the browsing pie. WIndows tries to release service pack 2 to win back their imprisoned users, tempers flare!
8. 2006 Ending: The empire strikes back with IE 7, a fully realized, standards compliant docile friendly beast that plays with others and is generally cute and cuddly. However, it breaks all the hacked up IE 6 sp2-only sites and thus people don’t accept the peaceful, easygoing IE, and reinstall the evil 6 version, making it the browser we will have to live with for the next 10 years or so.

   Or will we?

In designing user interfaces, it’s often the tiny details that can drive your users batty or earn their loyalty. Case in point: Apple’s latest iTunes update. iTunes 7.4.2 received plenty of attention for wiping out the black market in iPhone ringtones. I was more interested, however, in a couple of subtle but long-overdue improvements in the iPod syncing interface:

• If you try to sync more data than your iPod can hold, iTunes now tells you, in megabytes, how much you’re trying to sync vs. how much room you have. As the owner of a 4 GB nano and 450 GB of music, I’ve always struggled to finesse as much data into my nano as possible without getting that annoying "not enough room" error message. The process used to be:
  1. Try to sync.
  2. Receive annoying error message.
  3. Agonize over which playlist to uncheck to free up some space.
  4. Repeat ad nauseam, or at least until I stop receiving the error message.

  Now, finally, I have enough information to uncheck the correct number of playlists to achieve a successful sync in one or two tries instead of seven or eight.

• When you sync specific playlists with your iPod, iTunes now retains your playlist folder structure on the sync screen instead of flattening all playlists into one alphabetized list. The consistency of the redesigned interface is a huge improvement if, like me, you have entire directories of archived playlists and no interest in paging through them every time you sync. Even cooler, you can sync an entire folder of playlists with one click.

These little improvements may not seem like much, but they add up over time. The mental cost of switching to different software can be high, but users are more than willing to jump ship if your UI accumulates as many petty annoyances and lingering bugs as it does new features. That’s even more true when your software is free and lives in the browser.

As Ajax applications get more complex and desktop-y, users are going to demand the same level of polish and sophistication they expect from traditional software***. Agile development helps us get hot new features into users’ hands at regular intervals, but it shouldn’t lead us to settle for feature-rich, UI-challenged applications. Iterative development works best when subsequent releases add polish to existing functionality. For every feature release, product managers should schedule a separate maintenance one.

Of course, maintenance doesn’t mean just fixing things that are broken; it also means taking things that work pretty well and making them work better. As developers, we should apply the same level of scrutiny to the apps we develop as we do to the ones we use. I learn a lot about UI development by analyzing what I love about the software I use. But I learn more by analyzing what I hate.

Take Zimbra, the powerful Outlook clone. The Ajax version totally rocks except for one glaring problem: its appalling lack of graceful field focus. For instance, when I click the icon to compose a new mail message, the "to" field doesn’t automatically receive focus. The result is an app that demands either constant use of the mouse or frequent wild goose chases with the tab key. Other annoyances include the JavaScript confirmation box that pops up every time I try to navigate away from the application. By the time I received this warning for the third time, I was done with Zimbra. I clicked "OK" and hightailed it to the Thunderbird download page. (Not that Mozilla’s mail client is free of exasperation.)

Ajax increases the number of UI blunders you can commmit, but some of the most common annoyances date back to Web 1.0. Since the Mosaic days, many sites have suffered from a lack of granular error messaging. Take login pages. They often provide a single error message for a bad login, such as "Invalid username or password. Please try again." The user has no idea whether the username or the password caused the error, so she’s left to try random combinations. Often, she’ll give up and use the retrieve/reset password dialogue. The result is five minutes of frustration and a trip to her mail client just to get past your front door. If your application let her know the specific problem – "That username does not exist" or "That password doesn’t match that username" – then she’d have a lot more luck.

In some cases, field labels are just as much to blame. If usernames on your site are always email addresses, then label the field "email address." Users have to juggle dozens of usernames on hundreds of sites. Give them as many clues as possible about how things work on your site.

Of course, not all user gripes stem from bugs. Often, they stem from lack of configurability. I jumped for joy when Google Notebook finally offered me the option to sort my notebooks alphabetically rather than by date. But I still have to click the "A-Z" link every time I visit the app. The interface defaults to sort-by-date, doesn’t store the current sort method in a cookie, and doesn’t expose a user preference to set it permanently. Thus a welcome interface improvement leaves its own nitpicky new annoyance.

The same thing happened with the iTunes update I mentioned. As much as I love the retention of my playlist folder structure on the sync screen, I can’t believe that the folders are all expanded by default – let alone that they re-expand themselves every time I navigate away from the sync screen and then come back. God truly is in the details.

*** That was meant to be only semi-humorous. Users do expect polish from shrinkwrapped software. Whether they receive it is another story….

Technorati Tags

• usability
• user interface
• user experience

The folks from A List Apart rolled into town yesterday for An Event Apart Chicago 2007, a two-day web-development conference. Around 500 programmers, designers and information architects flocked to the seventh floor of the downtown Mariott for a varied slate of talks by some of the biggest names in the industry. Today and tomorrow I’ll give high-level overviews of each day’s sessions. On Friday, I’ll provide some color commentary.

Stylesheet guru Eric Meyer‘s “Secrets of the CSS Jedi” kicked things off with an in-depth case study in which pure CSS 1 and 2 transformed tabular data into an Excel-style bar graph. Meyer’s presentation was interesting not only for what his techniques could accomplish, but also for what they couldn’t. It was inspiring to see that plain-vanilla data could be given a powerful visual makeover, yet still remain completely semantic and accessible to handicapped users. But it was disheartening to see that the simple addition of tick marks within the graph demanded the addition of hard-coded percentage values to a number of CSS classes. The lack of simple computational ability within CSS declarations has long been a drawback of the “not a programming language” language. CSS remains a powerful and flexible technology, but, as I discussed at length a few days ago, it’s got a lot of room for growth. For those who were already conversant with Meyer’s techniques, perhaps the most interesting digression in his talk was the chance to tear through Firefox’s built-in browser stylesheets and see how even the most fundamental rules of HTML presentation – such as the invisibility of meta tags and the entire <head> block – are controlled by CSS behind the scenes. Meyer also went over the basic building blocks of the kind “reset” stylesheet most jedis use.

Up next was Jeffrey Zeldman, publisher of A List Apart and therefore another another rock star to this crowd. A lot of recent ALA content has focused on the overlooked art of writing for the web, so it was no surprise that Zeldman tackled the topic “Writing the User Interface,” which packed in plenty of practical advice for writers and non-writers alike. His central thesis was that copy was the cheapest and easiest thing to improve on most sites. Using lots of witty real-world examples, he provided a useful paradigm for breaking textual content into discrete components – guide copy (a.k.a. instructional text), brand copy (taglines and other branding assets), copy copy (a.k.a. real content), labels and URLs – and applying different editing criteria to each. As befits the author of “Designing With Web Standards,” Zeldman was careful to demonstrate that the rules of good web writing and the rules of semantic markup are often one and the same. As with most of Zeldman’s advice over the years, he started with a compelling philosophy, then showed how to break it down into small, actionable steps.

Happy Cog designer Jason Santa Maria finished off the morning block with “Design Your Way Out of a Paper Bag,” a look at the process of rebranding and redesigning an existing site. An illustrated tour of Santa Maria’s own iterative design process, the presentation was, like the earlier sessions, a case study in how a series of small steps can have a big impact on the usefulness of a site. Using an amusing Flickr tour of real-life signage and the abuse and misuse of the poor apostrophe therein, the designer drove home his biggest advice: “Sweat the small stuff.” Along the way, he touched on typography, branding, logo development, grid-based layout, whitespace and other design concerns. As befits a designer, Santa Maria’s session was probably the most visual and the least easily captured in the PDF slides distributed to attendees. He did, however, suggest some excellent further reading, most notably “The Elements of Typographic Style,” “Thinking With Type,” “Grid Systems” and “Making and Breaking the Grid.”

After lunch, Lou Rosenfeld led with “Search Analytics For Fun and Profit.” In a series of painstaking real-world case studies – most notably of my alma mater Michigan State University – Rosenfeld explained how server logs and especially search engine logs offer the keys to a successful site redesign. It’s a simple idea that may seem elementary to many developers, but given how infrequently web-development teams actually use this feedback loop effectively, Rosenfeld’s techniques struck me as really powerful. You would expect a session like this to show you how users’ most popular search terms could serve as the springboard to an overhaul of your navigational systems. But Rosenfeld also delved several levels deeper, showing how much powerful business intelligence can be obtained from inexpensive tools with little or no custom code to support them. Site indices, metadata, search algorithms and the search interface itself – all can be tweaked based the subtle metrics that emerge from careful, detailed session analysis.

Perhaps the most inspiring session was Liz Danzico‘s “The Seven Lies of Information Architecture,” in which the Happy Cog information architect recast the high commandments of IA as guidelines rather than rules. Danzico used copious examples to demonstrate how the most successful sites often bend or break the supposedly unwavering rules of IA. The idea of the magic number – most users can only remember 7 +/- 2 items in their short-term memory at any given time – was the first concept to show cracks under Danzico’s microscope. She went on to debunk the holy status of such maxims as “consistency is good,” “navigation is necessary,” “the shortest path is the best path,” “experience must be seamless” and “users should always know where they are.” Sometimes, the idiosyncratic nature of her examples suggested that certain guidelines work for most sites and are best broken only for a specific purpose. Other times, especially in her examination of Amazon‘s and Apple‘s navigational systems, her case studies suggested that even mainstream sites do and should break the rules. It was Danzico’s last rule – the idea that only IAs should do IA work – that she most thoroughly debunked by the end of her session. She argued passionately that site owners, designers, programmers and end users can and should understand the guidelines of information architecture – but, like IAs themselves, they should apply those guidelines judiciously rather than rigidly.

Last up was designer Dan Cederholm, founder of SimpleBits and Cork’d. He constructed an elaborate site prototype, ToupeePal, to demonstrate “Interface Design Juggling,” his thesis that great design involves keeping lots of balls in the air at the same time. Delving deeply into typography, microformats and the development of favicons, Cederholm demonstrated that beautiful and useful interfaces can be constructed using the supposedly unsophisticated visual and informational tools already at our disposal. Cederholm cried foul on the idea that web typography sucks because too few cross-platform fonts are available. He argued that the single-font typography of the Itallian Renaissance is some of the most beautiful ever created, then he demonstrated practical techniques for getting similar mileage out of limited existing web fonts. Word-spacing, letter-spacing, line-spacing, color, weight, italicization and other simple tools can all elevate even the most familiar typefaces into the design stratosphere. Likewise, even a tiny 16×16-pixel favicon can provide a powerful branding tool when designed correctly. Cederholm closed with an in-depth look at the “accidental API” of microformats, demonstrating that a even a grassroots open-source movement can add power and value to the web without the support of standards bodies and browser vendors.

Check back tomorrow for coverage of today’s sessions, from Eric Meyer’s look at the post-IE7 world to Derek Featherstone’s talk on accessibility.

Noovo has a preview of their new Ajax home page editor available. From their blog:

Noovo is an Ajax-based web application for homepage editing and we will also provide hosted homepage service as well. During the demo phase, only main features of editor are available. You may get a hint as to what kind of service we have in product plan if you look at the top menu. Those features for hosted homepage service will be introduced here before long.

The fact that there are no user interface or usability guidelines in the Ajax world is apparent from the claustrophobic toolbar and somewhat unusual behavior of some of the controls. So, powerful but clunky.

Technorati : ajax, application, home page editor