UXD - User eXperience Design: User Experience

Top 5 Iphone styled websites

Reader In the oxymoron that was mobile web design for many years we struggled to try our HTML pages out on different mobile devices only to have to resort to stripping out anything resembling good design or usabilty. On my trusty RAZR phone, I was content with using java apps to display things in a meaningful way, but having to learn the arcane hotkeys for each app became a chore, and they went little used. With the iphone, the promise was that regular sites look like their BS (big screen) brethren, where users can not have to learn new interaction conventions for their favorite sites outside of zooming and moving around to fit the screen. However, there is a second wave of web apps that optimize their site for the iphone. Using conventional xhtml, css, and some javascript, with a few unordered lists you can distill most complex sites into something new, and in many cases are easier, faster, and better user experiences than the 'real' sites! I hope this gives notice to web designers to pare down things that users rarely need and keep things simple. You may have your favorites, please add them to the comments, and non-iphoners can usen this emulator to try out the alternate sites:

5. iPhlickr - http://www.chandlerkent.com/iphlickr/
What sets this apart is a seeming blur between the iphone features and the browsing world, when you select a photo, you can then share it, send it, or view it within the flickr world, unfortunately when iphone apps become available next month, flickr will probably become an 'app', but until then, this is a very ingenious and useful approximation.

4. Wikipedia

Iphones aren't fast in downloading data (yet) so when I want some info, I don't want a huge load time with lots of info that isn't getting me to my goal, this interface is very fast, and also does a great job in reformatting wikipedia content to take advantage of show/hide heading behaviors, which is a new iphone 'standard', and one that helps parse long documents quickly.

3. Amazon

A old-time favorite (was iphonized pretty much right away), but Amazon should be applauded by honing down their value propositions to fit on this screen, that is product, price, ratings. Thats it, and thats what In need when I'm thinking about picking up that camera in Circuit City, i want to swoop in and Amazon it for comparison and this does the job.

2. Reqall - www.reqall.com

I mentioned how much I liked this the other day, a technologically amazing mashup of voice/text note taking, plus some nice keyword recognition make a pretty darn useful to-do list! Add on the iphone interface, with good integration of thick finger style tabs, gets a reasonable amount of navigation in a small place to seal the deal. Bummer is that it makes you login every time, but I am lobbying for that to be fixed ;-)

1. Google reader - www.google.com/reader/i

I could say the google iphone interface, but the reason for this post is a huge shout out to Google for their revamping of the RSS interface for the iphone. I am super picky about RSS readers, my copy of NewsFire broke the other day in an update and I was in a panic to find a replacement, to no avail (I fixed it by installing a previous version). The thing I dislike most about other RSS readers is using the metaphor of email. I think we all get too much email, and RSS is not email, its more like a very personalized newspaper. The google reader nails this, and has kept me busy on train trips really enjoying reading stories, with excellent ajax integration, which really shines on the iphone since refreshing the page can take 20+ seconds, keeping info inline is imperative.

I also want to give credit to the password filler-inner 1password for their iphone interface, and twistori that shows that the same design works on both BS and little if the concept and interaction are clear. If I had a wishlist for sites I wish worked on the iphone it would be cellartracker (their regular site is not too great either, but the content is invaluable on mobile) and chase - if you are really embracing mobile users, let me really bank online.

The environment will change in the next month with the introduction of iPhone apps, but the resourcefulness of these developers to take 'plain ol' HTML and make a good user experience in a very constrained environment shouldn't be lost. Give your comments and contribute your favorites I may have missed.

Dasher - A new way to write

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.

Blue Christmas

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.
vista menubar 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.

vista is blue 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).

vista menubar 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!

Browser Wars : Part IV a new hope?

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)

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 ?!)

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.

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.

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.

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.

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.

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!

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?

On the Benefits and Pitfalls of Competitive Research

Competitive research is part of the design process at Pathfinder. By competitive research, I mean spending time getting to know how others have solved the problems you are confronted with. We do this type of research separately to start both the Information Architecture and the Visual Design phases of our process.

Recently, though, I’ve been thinking about the net effect of the importance that it plays in the Visual Design process. Specifically, to what extent does it help, and when does it hinder.

One the one hand, it can be really dumb to start designing something without knowing what has already been done in that space. Starting from scratch can be a real time waster. It pays to take advantage of other’s successful design thinking as it relates to the problems you have to solve, because they might have been solved already.

However the more immersed one becomes in a particular domain--the more exposure one has to the state of the art--the more boxed in one can get. You become accustomed to seeing problems not as challenges in need of creative thinking, but as patterns that conform to some already defined problem/solution set. Then all you have to do as a designer is simply find that matching set. It may sometimes be easy, even more often than not, and there may be projects when doing this is the best you can hope for under the current constraints, but eventually it’ll hurt you as a designer, because you can get to used to searching for patterns. Cliché as it may be, your creativity is like a muscle. You have to exercise it daily for it to grow. And not all problems have a matching solution yet. There will always be unique problems that will require you to solve them on your own, and you’ll be caught off guard if you haven’t practiced using your own design skills.

I would say that for competitive research to be an effective, and positive experience in the long run, it has to be balanced with a healthy dose of skepticism. As a designer you should open yourself up to what others have done, and in fact realize that it’s very important not to design in a vacuum. But as you explore those designs that came before you, keep in mind that it’s up to you to use your creative skills to come up with a solution. You can’t let your skills sit in the dark, while you let others do the hard work. Eventually it’ll come back to bit you. Take what works. There’s no reason not to. But even then, don’t just consume it, deconstruct it. Take a designers critical eye to it, so you can learn from it and grow as a designer.

DUX2007 - Ubiquitous Computing

Adam Greenfield of NYU’s Interactive Telecommunications Program gave a great keynote presentation at DUX07 on ubiquitous computing -- embedded devices that are wirelessly networked, imperceptible, mobile and post-gui. Devices that are not perceived as computers by the people who use them, but rather as a facet of their lives. An example he cited is the Nike+ product for runners, which pairs with an iPod to give you feedback on how you’re running while you’re running and records info such as distance, time, etc. You can then sync your workout data to either iTunes or the Nike site, where you can then become part of the Nike+ community. It is a computer, but to most people it's just a piece of plastic you put on your shoe.

Ubiquitous computing. Existing or being everyware. Perceived as a facet of the user’s life. Eroding the distinction between product and service

Consider the automobile. When the first Model-Ts rolled off the assembly line, the car was a product. You drove it here and there and that was basically it. With the addition of On-Star, the car’s autonomy eroded as it was now networked with a diagnostic tool, roadside service, emergency contact, etc. The perception of a car as only a product began to erode as well; the car began to evolve to a platform. Fast forward a decade or so and we now have car as a service -- the Zip car. Glimpsing into MIT’s Smart Cities project, we begin to see the car as an interface to the city and not the engine.

As designers, then, our challenge is to design for these product/service ecologies.

Back to the Nike+: although the device is basically a pedometer it only works for runners, not walkers. In addition, participation in the Nike+ community requires Flash because that's what the Nike site uses. This is a closed ecology and by their very nature, closed ecologies are brittle. Greenfield, therefore, advocates designing these products/services to use open frameworks because of their openness, their ability to be flexible and extensible. The downside of an open framework is a loss of control and for companies heavily vested in controlling their brand, this option may not even be considered. His argument, however, is that open frameworks aid in a product’s long-term viability.

Some final thoughts from Greenfield:

As designers, we can no longer assume that the product we design will be a standalone product.
Everything that can be networked, will be.

A final thought from me: it's an exciting time to be designing.

Technorati Tags: Design, User Experience, Usability, DUX07

What is UxD?

A couple of weeks ago a sales presentation was being prepared in our New York office; it was primarily focussed on the problem at hand, but the presenter wanted to include a single slide as a cue to talk about User Experience Design [UxD]. He emailed me and a couple of the principles asking for a description in a single frame.

I wrote something, designed two slides because I could not shoehorn it into one, various documents were thrown into the air, then we were all consumed by other work as the train moved on.

Now I am rethinking it. UxD is a fairly complex set of activities to describe, and there is no shortage of areas claimed by related disciplines. All of them are occurring in an area of rapid market development that happens to be highly valued by the societies we are in. Which is a recipe to attract passionate debate driven by financial rewards.

So is there a good way to describe it, or state it's value to a potential client in a single powerpoint slide? Assuming that no fly-ins, starbursts or windowshade rolls may be used in place of meaning, we will start with those old standbys - words:
________________________________________

Concise version:
User Experience Designers create structures for understanding and manipulating information, designing consistent contexts which encourage cumulative learning. In doing so they raise the bar from "being able to do something" to "being able to do something easily".

Their solutions go beyond code to model the most efficient and pleasing conceptual space that can be created within the constraints of time, budget & resources.
________________________________________

Verbose version:
User Experience Designers are typically employed on applications or sites with large amounts of features, complexity or information.

They create structures for understanding and manipulating information or parameters, designing consistent contexts which encourage cumulative learning.

They raise the bar from "being able to do something" to "being able to do something easily". As a starting point they conduct research to find:
_Who are the users?
_What are their goals?
_In what context will they use the product?

Then they use any modeling technique available to propose solutions that go beyond code to model the most most efficient and pleasing conceptual space that can be created within the constraints of time, budget & resources.
________________________________________

And this is just a starting point for discussion, and the slide itself is TBD. The concise version is hardly meant to be all encompassing, but it focuses on Pathfinders particular business goals. These are concentrated in application work, either in or out of a browser, and our communications tend to be directed toward fairly tech savvy folks. Interested in your comments.

Charles

Color for Developers, part 3

Through a glass badly

"This is not a pipe." R. Magritte

You are reading this on screen. It is not what I expected.

One of the biggest problems for any on-screen designer is the weird backlit medium we fish swim in. This is true if you are creating interfaces for browsers or desktop applications.

By now you are asking why, why does he continue to torture us with these vague allusions and puzzling suppositions. Well it is just my sick idea of fun, really, but here is a simple test. Make a pdf of your favorite picture of a human. Put it on a flash drive and walk around to a few of your colleagues computers and compare the different displays. Extra points can be scored in two ways:

1] try a PC and any other platform, Mac, SGI, Treo

2] try laptop, lcd and CRT screens. If you can still find a CRT screen, they are fading into the dust of time or the junkyards of third world countries as we speak.

Of course you will find that the image of Britney Spears moments after the haircut discloses an array of skull colors limited only by the number of screens it is displayed on.

Individual hairs may or may not resolve, and the level of contrast will have a happy variety as well. This is where you work. Every one of your users sees this differently.

So great, isn't that a big mess, can we please just ignore it? Well no, that isn't really playing well with others. What we need is a basic strategy for accommodating this tragic reality.

There are commercial solutions to calibration available, or most Adobe programs ship with basic calibration tools. These will help... but only you. There is no way of knowing if your users ever did this, and we know that asking is not a scalable strategy.

Unless you are in a highly controlled situation, in an industry where there is a financial benefit directly tied to color fidelity, you can bet that no one really cares.

So what is the solution?

1] Design it a bit crude. Don't expect someone's screen to display a reliable difference between zero, 10 and 20 percent black, that is too subtle. Try 0, 15 and 30

2] Test it. Test it some more. Don't beat it to death, but it can definitely be too subtle.

There we go. In a few short blogs the secrets of your universe revealed. You have grasped the remote from my hand, grasshopper, do not watch Jerry Springer with the powerful tools you have been given.

Color for Developers, part 2

Color in context Many moons have swung by since our last talk, grasshopper, and by now you have had those tattoos revised and replaced more times than Angelina Jolie. I can only hope you have been as politically corrupt and personally shocking, really, she is a role model to so many.

Today we will talk about color and perception, then later we will do the sacrifice part... Right, let's start with Kasimir Malevich, who had strong opinions about color or the lack thereof and put his money, [or the people's money] where his brush was. Painted such fashion nuggets as "White on white" and "Black square". If you imagine what they look like in your mind, you will be darn close.

So what was on his mind? Why bother? There are a couple of reasons:

1] Cultural He was a Supremacist in Russia in the early part of the last century and thought that painting couches and side-tables was hopelessly bourgeois.

2] Psychological He wanted to defeat his own preconceptions and create something new; a kind of meta painting that was both free of objects and depicting pure emotion.

Well can color or it's absence do that? What strange and magical powers does it have? Vassily Kandinsky, one of Kasimirs drinking buddies, associated some very specific things with color - he claimed that certain colors elicited thoughts/memories/feelings of particular sounds and feelings and made them into a handy grid.

Most people make some basic and reliable associations with colors; black associates with night, death and designers clothing. Red means fire engines and radio flyer wagons. These are cultural associations, that effect how we perceive and interpret our world. A blue light on your dashboard is understood as a fairly passive status light. A yellow light, blinking rapidly, means the engine is probably about to seize.

When we use these colors in an interface, all of those associations are carried along with it. A complicating factor is the cultural context it is being read in. Many cultures have very different tolerances and preferences for color that western europeans; any short description of these differences will be reductive, but think of these references: Jamaican villages houses, Bollywood movies, Japanese packaging... Would those local tastes effect the design of an interface for those groups? I look forward to your comments. Leave a donation for the gods by the planter.

Que Multimedia, Part 3, Beyond Typography

As you might expect, I have a suggestion or two. Firstly, I would confirm my standing as a heretic by questioning the hegemony of typography. Put five designers in front of lattes and the one thing they will all agree on with mumbled nods is the importance of Typography. Of course I would too, but this reflexive assent masks a larger problem in how design is practiced and taught. The design profession has been so deeply fractured in the last 15 years typography has remained one of the few common links between this new multiplicity of practitioners. Well, for better or worse, the aesthetics of desktop and browser based applications use type in extremely limited ways that are an intersection between common system installed fonts and informative hierarchies. And common system fonts, consider Arial, Impact and Papyrus for a moment, leave much to be desired. However this is the palette of many desktop and browser based applications. Often the more complex issues in these engagements are how to assemble, change and order vast amounts of information. Designers bring a vastly different focus to these activities than most developers. The developer concentrates on a micro level of specific code interactions to construct a working system while a user experience designer connects the user to a much more general picture. Factors that might be involved include business problems, a users cognitive interest/abilities and the the capabilities of the developers systems. There are user research activity models, interface and task modeling considerations that have little to do with what anyone would describe as sophisticated print typography. Yet notions of hierarchy and the effect of symbols and composition are elemental to forming easily navigated tasks. So mere type skills will not be adequate; understanding interaction from a standpoint of task and capability is the core activity. This means that the designer must have a comprehension of the basics of digital design history as well as what is current, and this is equally as trend driven as any part of print culture, in development terms. I see this as the formation of the question, not an answer. What we do know is that the answer is a moving target, obfuscated by the claims of those who market digital culture. But the challenge to answer it is as real as any aspirations we have as providers of both sensible and innovative solutions.

Don’t Confuse the User

You’re the team lead for developing the next killer app, and word is passed along that the marketing campaign is being built around the user-centric design of your new app. Unfortunately, no budget has been allocated to hire someone with the desired skill set to achieve this lofty goal. Your developers are heads down into the code and have neither the time nor interest to become user experience gurus. What to do?

Establish a set of guidelines for your developers to follow. It won’t cover every scenario but it will encompass the basic rule of usable interfaces, to wit: don’t confuse the user. Such things as deciding on and applying a consistent terminology (e.g., section names matching up with navigation names), using expected widgets (checkboxes v. radio buttons), and applying consistent behavior (too numerous to mention) are the backbone to creating usable software. If there’s time, add in messaging for the user -- success messages and waiting messages (such as ‘retrieving data, please hold’) are vital to assuring your user they didn’t make a mistake and a good way to prevent double clicks on submit buttons.

Listen, the reality is that most projects are not fortunate enough to have a separate user interface design team. Anything that can help your developers to at least start thinking about issues regarding user interaction is a good thing. Creating a set of user guidelines is a good way to begin.

What's on my Bookshelf

Having recently been asked to review a book on CSS (which at first glance looks good but I'll go into details in a later post), it caused me to take a look at the crop of knowledge currently gracing my bookshelves. Hmmm, I thought. If I wanted to recommend two of those books, which two would I recommend? A nice little challenge. Deciding to keep the choices within the realm of the practical, rather than the theoretical, here's what I came up with.

First up is Designing Visual Interfaces, Communication Oriented Techniques by Kevin Mullet and Darrell Sano. The book begins with explaining the principles and elements of design and how they can be applied to user interface. There is no "one size fits all" solution but rather a discussion about techniques such as hierarchy, relationship, balance, etc., how they are used and why they're important in software design. The author also gets into module, programs and how structure, predictability and efficiency apply. Further chapters explain establishing modular units or using a grid layout. In other words, the book gives a great explanation of what design theory is and how it's the structure for well-designed user interfaces.

Next up, Designing from Both Sides of the Screen, How Designers and Engineers and Collaborate to Build Cooperative Technology, by Ellen Isaacs (interaction designer) and Alan Walendowski (software engineer). The book is divided into two parts: The Goal and The Process. The first part takes you through designing software with user centric design principles followed by the second section, which walks you through the process of building a software application illustrating what the authors did and, more importantly, why they did it. It's a good case study in creating technology that cooperates with people, shows how good designs help the user flow into their tasks instead of fighting them, and shows how design and engineering goals need not oppose each other. An good description of a theory and the application of same.

So there you have it, two recommendations off my bookshelf. The first promoting design principles and the second advocating user centric design. What's on your bookshelf?

Wheels on a boat

A couple of days ago someone sent me a link to a flash catalog piece...

I have seen these kinds of things before.

And I always wonder why the idea gets repeated. I suspect it is because catalog based retailers see the Book as some kind of golden calf which is due irrational worship. The downfall is in the data-density difference between print and screen is the culprit; print holds so much more that the on screen imitation is irrelevant. The magnifying glass shows a smaller width than a column of type; not being able to read a full line makes multiple lines an instantly rejected experience, fomenting shockingly derisive thoughts on the part of a user.

I have seen this done better, maybe it was a Lands End version... It popped up a new window which was larger and had better controls.

The next question is what would make it work? Is there value to this format that drives otherwise knowledgeable adults to keep trying this metaphor?

If you assumed a 1024 x 768 user base, you would have a larger beginning state. A very large magnifying glass, or better yet- zoom capabilities, would allow you to move into the page. Which returns us to the question of value.

What is it that retailers are seeking here? I think it is the experience of browsing in a lateral fashion and focussing in on some desirable or intriguing item... A simple but durable pleasure. And the notion of lateral non-hierarchical browsing is certainly a mainstay of the web.

As well, they are looking to leverage the page layout techniques that they find successful in print. This is where things break down; cluttered web pages, whether imitating print or not don’t tend to function very well for impulse surfing. If the page design were less dense with more whitespace you might be able to leverage one medium against the other. However this becomes a series of decisions as to how your product offering combine with the semantic codes connoted by the design choices this would require.

Que Multimedia?

A local school recently asked me to teach a course in Multimedia. It is a first year grad course for people with little design context. Ordinarily I would have been interested in the school and it’s excellent program, yet I stumbled when I heard the term. Living in our Ajax enriched environment it struck me as an old school term, and wondered why it had faded from use.

After a bit of pondering, I came to the conclusion that it is a bit like carving trees out of wood. The metaphor is reversed. The soul in what we do is the interaction; multimedia is occaisionally part of the vessel.

Multimedia means Flash, cheesy little director games, tiny choppy video. Think of children’s CD-roms where low rent repitition is sort of a crash test stand-in for learning cognition. Multimedia means things that are difficult to sell and typically bring dissappointing responses when you do. And not usually worth producing except for massive media clients as they are expensive and cumbersome to update. These are not positive associations.

What is interesting is interaction design and the ability to synthesize actions and events into tighter groupings, both conceptually & physically - ideas like direct manipulation, contextual logic and coherent paths have utility; making it blink is just not that important.

I thought about for a bit, and realized that the suit didn’t fit. Back on the rack.

Reconciling the Powers of Less and More in Product Design

In his book The Art of Innovation (a highly recommended read), Tom Kelley (of IDEO) speaks of “Feature Creep” as the enemy of innovation. We have all used products that try to be so much they become a burden instead of a helpful tool. But how as practitioners do we fight the feature creep tendency and keep products and business processes customer-focused?

Kelley advocates two approaches. First, in a version 2.0 of a product, streamline. Resist the temptation to overcrowd the product and emphasize “integration and simplicity.” Second, you should “spend the most design attention at the place where you touch the product the most.” I would hold this especially true in physical and mobile devices, but would also emphasize this principle in process design. If everyone encounters the front door of a process, make sure that part or the process is very well thought out and efficient for the users.

Toolbars: An Interface Designer's opinion

As a designer, it is very important to me that the software I use provides me access to the functions I need without interfering with the creative process. Since I use a 15” monitor at work, screen space is always at a premium, which makes it even more critical that the tools in the applications I use are in there when I need them, and gone when I don’t.

Toolbars, Pallets, Panels, whatever they’re called, they are the entities—stationary or floating, separated or attached, minimized or maximized--that give me the access to application functions and object properties that I need to do my job. So I spent some time in the apps I most frequently use at work-- Microsoft office, Photoshop CS, Illustrator CS, GoLive CS, Flash Mx2004—moving, attaching, snapping, connecting, splitting, minimizing, scaling, customizing, the hell out of these things, to try and get a good idea of how effective each is at making my life as a designer as stress free as possible. Here’s what I’ve found…

Microsoft Word
The good
The application does a good job of knowing what I need when I need it. For instance, the formatting toolbar, which appears above the document window by default, contains all the necessary tools I need about 80% of the time. And the picture toolbar opens when I’ve selected a picture, disappearing when it is deselected. The object specific toolbars, such as Table, and Picture provide an easy way to edit specific objects quickly without running through menus and submenus repeatedly.

Toolbar icons are self-explanatory. I almost never need to think very long before I understand which button I need to press to perform a specific action.

The arrows to the right of toolbars with extra functionality present less often used, but still important features in an easy to get to manner.

The customize dialog box allows me to completely reconfigure my toolbars by adding and removing tools. It even lets me create new toolbars to support my workflow.

The not so good
Word_1 Each individual toolbar is its own mini window, and the screen can get cluttered if I need many features for a specific task. The lack of ability to quickly collapse or snap toolbars together is a major limiting factor in the usability of the application.

There are no tool presets—which are saved workspace layouts, so toolbars that have been opened or shifted for one purpose will have to be re-shifted or closed manually, one at a time, to support another task.

Since toolbars are mini windows, I would think to look for them in the ‘Window’ menu. However they are located in the ‘View’ menu, alongside options for viewing the current document such as rulers and guides. I’ve been using word for over a decade, and I still trip up on that one.

The verdict
Nice tool set, conceptuality works well, but the screen can get cluttered, and finding some tools is counterintuitive.

Total Score: 5

Photoshop CS
The good
The contextual toolbar docked at the top—added to the interface in version 6.0—makes fine tuning the your selected tool quick and easy. The palette well can be used to station any number of toolbars in it, so you can move about freely without shoving windows around to make space available.
Individual toolbars, called palettes in Photoshop, can be detached and inserted into any of the toolbar mini windows. This effortless customizability is a real plus.

Saving and opening toolbar presets, called Workspaces in Photoshop is also a breeze. Rather than constantly shifting palettes around, you can save separate workspaces for individual tasks, so, for example, If I’m color correcting, I can save and use a ‘Color Correcting’ workspace, which contains the histogram, color palette, channels and layers opened in separate mini-windows for one click access. Hen when I need my original workspace I can call it back with one click from the ‘Window’ drop down menu.

The not so good
The palette well does not allow docked pallets to be opened, so access to any of their tools requires an extra click…not a big usability loss, but when you’re involved in a repetitive task, it adds up.
Although mini-windows snap to each other, they cannot be connected; so quickly nudging your entire toolset to grab an errant object on the canvas is not possible.

Mini-windows can and frequently do get hidden behind other mini-windows. I’ve wasted way too much time looking for the Character palette, which the ‘Window’ menu item says is opened, but I can’t find it, because it’s hiding behind another palette.

The ‘Tools’ palette for some reason refuses to get with the program and become a dockable, attachable, closeable mini-window just like its siblings. I’m not sure why this is, perhaps Adobe’s user research suggests it works there, but I would rather the enhanced control and customization of the ‘Tools’ palette.

The Verdict
Big strides every release, but there’s still a ways to go.

Total Score: 6.5

Illustrator CS
Insofar as the display and behavior of toolbars are concerned, there are few significant differences between Illustrator and Photoshop, so most of the advantages and disadvantages of the latter apply to the former.

The good
Ilustrator One small difference between the two apps is the ability to separate tools from the ‘Tools’ palette in illustrator. This nice little feature enables easier access to all the sub-tools in the palette.

The not so good
However there are two significant features missing from the app. Neither the Palette well, nor the ability to save workspaces appear in Illustrator. What the reason is for this, who knows, but at least as of CS 1 Illustrator lags behind Photoshop in this category.

The verdict
Why the difference between Illustrator and Photoshop? There’s too much of a lag between the two apps to be acceptable.

Total Score: 4

GoLive CS 2
Although an Adobe product, GoLive’s toolbar look and feel departs quite substantially from that of Photoshop and Illustrator.

The good
There is a tremendous amount of flexibility, and customization capability in this interface. Almost everything can be moved, removed, attached, docked, resized or closed.

I like the idea that every palette can detach to become its own window, including the tabs that reside in the main site window by default.

The ‘Tools’ palette can be resized (but only because the palette is now contextual to the editing mode you’re in—itself a useful feature to deal with the complexity inherent in an application of this capacity).

The toolbar at the top of the interface displays different tool sets for view modes. For instance, when in site view mode, the toolbar will show site-specific tools. Opening an html file will cause the toolbar to display a new set of tools related to document editing.

Golive The major departure from Photoshop and Illustrator is that floating mini-windows can be attached by stacking one on top of the other. Thus allowing all attached palettes to be manipulated at once. Each individual palette can also be minimized using a small min-max triangle at the left of the palette, an elegant solution to the problem of screen real estate that maintains palette grouping, allows quick access to functions, and drastically increases the available space.

The bad
The sheer number of things you can do in Adobe GoLive CS2 makes it difficult to find the function you need at the time you need it. The application has a very high learning curve for precisely this reason.
Although you can take apart the site window palette by palette, you cannot attach those palettes to the toolbars. The interface doesn’t make the distinction between the two types of palettes very clear.

Stacking toolbars is not a very intuitive action in GoLive. There isn’t enough of a visual queue to let you know that they can be stacked. You sort of have to discover it by accident.

The verdict
Lots of features, not enough flow. I still don’t know where to find most tools, and I’ve been working with the application for a year now.

Total Score: 4.5

Flash MX 2004
When working in 4 dimensions, it is critical to be able to view your canvas, as well as have unfettered access to you timeline and key framing functions, so animation workspaces need to be even more sensitive to the screen real estate issue.

The Good
Flash Flash does a very good job of utilizing the space your monitor provides it with.
The position of the timeline is extensively customizable. It can be placed alongside the top, left or right of the canvas, and it can be removed as well, becoming a floating mini-window along with the other toolbars. This configurability keeps me from getting lost in the timeline no matter what type of project I’m working on.

Another useful feature of the interface is that most toolbars can be stacked, minimizing the screen space occupied by tools not in use at the moment.

It is also possible to save workspaces as in Photoshop, making it simple and quick to move between workflows

The not so good
It would be nice to be able to dock the timeline underneath the canvas, but the UI allows docking on only 3 sides-strange, since the timeline in adobe’s other animation application, After Effects, defaults to underneath the canvas.

The verdict
Overall, the Flash toolbars do a great job of giving me what I need when I need it, and getting out of the way otherwise.

Total Score: 7.5

The Buck Stops Here

Sometimes, it seems that the role of User Experience Architect is 90% management and 10% actual design.

And there's lots to manage: user requirements, development schedules, business requirements, stakeholder expectations, schedules, timelines, and overall expectations. It's been frequently observed that the UXD is the liaison among all project participants. Truly, all roads to a given project lead through the focus of the user.

As a consequence, we mediators often become bargainers. I'm sure all of us have had to negotiate our design to conform with the myriad demands of the community of project stakeholders. We've given up the fight for a slick, appealing rich interaction for the sake of an overstressed timeline; have gone for the low-hanging, quick design hits in lieu of a more holistic and integrated design approach whose benefits may be more of an investment than an immediate showcase.

But some design recommendations are non-negotiable. Budget be spent, timelines be extended--we fail to justify our worth (and collaborate in our lack of ready acceptance) if we compromise on some critical practices.

Here are some of mine--I'm sure all of you can add to the list.

1. Coherent navigation: An astronomical percentage rate of abandonment is associated with poor navigation on a website. This directly, and concretely, correlates to lost revenue on an e-commerce site, and only inversely impacts response rates on lead generation sites (i.e., improve the nav, improve the response rate). With applications, though, where users are often captive users, the erosion of usability is less direct, but nonetheless actual. It's almost a karma thing: what goes around (or fails to), comes around (or fails to).

2. Knee-jerk rebellion. As designers, we shouldn't adopt the personas of sulky fifteen-year-olds. Conventions endure for a reason. Especially on sites and apps. They cut through clutter and noise, and allow users to focus in on the heart of their tasks. Sure, we could all make our buttons into links, and links into drop-downs, and display diagonal navigation, but that's design that serves the designer--not the users. An electric light switch is dowdy and plain, but I can rely on what it will look like and what it will do, from sea to shining sea.

Of course, if I'm in Vienna or Tokyo or Rio, that switch is likely to look very different (although it serves the same function), which leads me to. . .

3. Xenophobia and the Ugly American Compulsion. Face it, we're good at thinking we set the standards for the world, and the statistics regarding internet usage bear out--at least for now--US influence and dominance. But that's changing--quickly. China will soon ascend as the country with the largest percentage of the population online. But it's not a simple case of "majority rules." Cultural differences are sometimes subtle, sometimes glaring, but always meaningful. In designing a website or application nowadays, it's best to assume global, rather than local, standards. This filters down to the smallest IA aspects, such as forms: most of the world doesn't conform to the US convention of <city>, <state>, <ZIP>.

Breaking the First Commandment

The practice of user experience design frequently involves the invocation of rules, guidelines, tenets, and not a touch of folk wisdom. There are several plausible reasons for this. UXD derives from the cultures of many previous disciplines: architecture, physical ergonomics, psychology, to name a few--and each discipline comes equipped with its own doctrines. More importantly, we strive to focus on the science as well as the art of UXD, and as practitioners, I think we often bend over backwards to position our findings as objective and standards-based, and not as a collection of personal opinions emanating from a range of individual perspectives (not that there's necessarily anything too much wrong with that--after all, user experience is our expertise. Do we ask for a heuristic review of the beef brisket from our butchers?)

If any commandment is central to the spirit and philosophy of UXD, arguably it's Arnie Lund's enduring admonition--heck, it's even framed Biblically:

Know thy users, and thy users are not thyself

It's a good guideline, of course: as user experience designers, we often know far too much about design, and far too little about actual user experience. But I've often found that sufficient user research is the ideal rather than the reality, for numerous and varied reasons. Sometimes, stakeholders see user research as the one point of resistance in an otherwise acceptable project plan--they simply can't see the value. Or, potential users are unavailable. I've encountered two common reasons for this--confidentiality of the project prevents the inclusion of users in research because of speed-to-market or the need to keep aspects of the site or application completely confidential. Or, the product is being designed for a foreign or distant market, and the logistics (and budget) simply can't support field studies or task analyses.

But we've discovered workarounds for obtaining information in the absence of "warm bodies." Proxy users--often project stakeholders--can be successfully separated from their personal points-of-view, and their domain knowledge can be leveraged. Friends-and-family research is also a rewarding path--as a group of designers, one of us usually knows someone (who knows someone?) who can fill in to help supply the user persona.

And the idea of personas and scenarios is key in reinterpreting Arnie Lund's directive: after all, simple knowledge of the users is not sufficient--it's how you apply this information to the design strategy that's the important application.

To paraphrase Walt Kelly's Pogo, sometimes we've met the users and they are us.

The Zeigarnik Effect in GUI Design

The Zeigarnik effect suggests people remember incomplete or interrupted things better than completed things. It’s human nature to want to complete a task or hear the end of a story, and when we don’t a psychological tension results until the item is completed.

The effect has an interesting implication for digital interfaces. When a user involved in a long task encounters an interruption or an opportunity to complete a quick task, there’s a good chance the interruption or new task will get acted on. This can leave a lineage of uncompleted tasks and non-linear navigation trails.

One way to combat this that we have used in a variety of applications is to dynamically create a task queue. The queue stacks up incomplete tasks in one place so the user can get back to these tasks when he or she is ready. In a restricted domain, it’s usually possible to apply some intelligence as to how the queue is built so it reads fluidly and clearly.

Leveraging the User’s Experience: Insights on Designing for AJAX

When the first GUIs were created they leveraged perhaps the most ubiquitous items people experienced in an office environment: a desktop with folders and documents.

As we move into the world of AJAX and rich interactions, the principle of leveraging experience can be extended not just to objects but how we interact with those objects. Google maps provide a familiar example. Using rich interactions, we are able to interact with the map almost as if it were a physical object (without having to figure out how to fold it – a benefit to be sure). Another form of interaction being seen more and more is the concept of a sliding drawer. Objects we may need are closely available, but are not consuming precious screen real estate until needed.

As rich interaction and AJAX technologies mature, they present endless possibilities for the designer to create something that is innovative through its familiarity.

An example of Ajax providing a good user experience

A little while back I commented on the need for designers to use new technologies not for their own sake, but as a means to an end (on the web, that end being a good user experience). Here's a perfect example of what I meant.
Duo consulting has done some really nice work for the Chicago Parks District. The web site takes advantage of 'web 2.0' features to maximize the user experience, and as a result, a highly successful site that among other things, greatly increased online registration for park district classes, and decreased cart abandonment by 80%.
Here's the Ajax enabled online registration app. that they built...
And here's the original post on the Duo Consulting blog.

¡Needlepoint, no--PowerPoint, si!

I confess to being an amateur quote-collector. While I don't immortalize these succinct and sage sayings on pillows or wall hangings, I find them useful and thought-stimulating appetizers in telling the story of user experience design. They can surprise us with their obvious common sense ("Easy is hard"), delight us with their elegance ("why couldn't I express it like that?") or reaffirm our own realities.

Here are some of my favorites. First, a pair of thoughts from Don Norman:

I prefer design by experts - by people who know what they are doing

The people who use your product are not usually amateur designers

Treasonous words from a recognized advocate of user-centered design? I don't think so, recalling a former client who punted signoff on several critical design issues by saying "Let's wait until user testing to make a decision." Design should be user-centered, not necessarily user-created. For as Margaret Meade, among others, has observed:

What people say, what people do, and what people say they do are entirely different things.

Or, John Meades:

You need to "listen deeply" - listen past what people say they want to hear what they need.

As designers, we must translate our perceptions of user requirements into efficient design and not merely act as clairvoyants for messages from the world of the users. That is the skill, the value we bring to user research.

To end this post, a quote I introduce into as many presentations as I can, because it's simultaneously a threat and a home truth of the olden days of design:

We will go into your houses and redesign them the same way your web sites are designed. The basement will be the first thing you see, the kitchen will be unreachable except through the bedroom and both bathrooms, the bedroom will be on six different floors, and the dog will be in every room at once. - Ann Feeny, Information Architect's Manifesto

What are your favorite words of wisdom?

Continue reading "¡Needlepoint, no--PowerPoint, si!" »

Biting the hand that feeds us

Talk about poor design! The Typepad 'Post' page--the page I’m on right now-- is a great example of a poor interface. What do I mean by this?
Well, lets take a look at it. Now in my opinion, when we get right down to the heart of it, the object of an interface is to help the user accomplish a task. Weather the you want to obtain the latest baseball scores on espn.com or to configure an electronic substation monitoring system, the interface you use is designed (hopefully) to help you accomplish what it is you set out to do.
When building a web site, designers usually have to deal with the uncertainty of potentially large numbers of visitors (or 'users' for consistency) and associated tasks. However, there are pages like this one here were all users are performing the same task.
The object of the design here should be pretty straightforward, and that it to make writing and posting a blog as painless and efficient as possible. The buttons that perform functions associated with posting (such as adding pictures or links) should be easy to understand, and most importantly, the act of posting the blog shouldn't cause lots of confusion.
Here are some examples of the poor design of the Typepad 'Post' page...The "Insert Image" and "Insert File" buttons are icons with no accompanying text despite the fact that there is plenty of room.
The button that adds white space for larger posts is confusing, again, despite the fact that there is plenty of room for a more descriptive button. Keep in mind that users, afraid of losing the post they are writing, will be hesitant to click on any links, so it becomes even more important to make button actions clear.
The design blunder that causes the most confusion is the positioning and terminology of the button that does the posting. When the ultimate object on a screen is always the same, and the completion of the task is accomplished with the click of one button, that button should be named for the verb phrase of the task being accomplished. In this case I am posting a blog entry. The button is called "Save", which is not what I think of doing when I want to post what I've just written. More confusing still, the proper term for the button, which of course is 'Post', is the name of the prominently placed clickable link that erases what you were writing and starts over.

User Experience in Sovereign vs. Transitory Applications

The characteristics of what makes a quality user experience can vary dramatically when talking about a sovereign application vs. a transitory one. Sovereign applications, like Microsoft Word, draw in and maintain our attention for a length of time. Transitory applications, like Google, serve us for a short term need and then we move on.

Walk Up and Use
A transitory application should have a walk up and use quality. Even the slightest extra need for time to figure something out can dissuade users. In addition, these applications benefit from a comfort factor. If the software seems comfortable, I’m more likely to not mind spending a few moments with it. Finally, good error recovery is essential. The software should instruct the user as to how to recover and provide an easy way to do so, or start over.

Extend My Abilities
Sovereign applications should enable us to extend our abilities to get something done which may be complex or require some time. Making the correct design trade offs and arriving at a quality experience depends on characterizing how the tool extends the user’s abilities. Does the tool allow for faster performance of a repetitive task? Does the tool enable completion of a task not possible without the tool? Does the tool aggregate tasks into one place? The key to creating an effective design (and measure of success) is determining the ways in which the tool extends the users abilities and which are most important.

It Just Keeps on Flowing

Our Elyse Sanchez has just authored an article entitled "Features into Flow: Techniques for Optimizing User Interactions." It distills some of our experiences designing software for educational reform in an Arabic gulf state. Some choice excerpts:

The success of our design methodology is dependent in a large part on user research and the creation of personas and task-based scenarios. Our principle Enumeration persona, Ahmad, spends a few weeks each autumn traveling through the desert from school to school, generally spending about a week at each location, where he has to manage with makeshift accommodations and associated distractions. A thorough and competent data collector, he dislikes making errors. Using his laptop computer, he enters his data very quickly but often struggles to meet his deadlines.

We were able to incorporate several strategies for optimizing flow and offering Ahmad the benefits of a “smart” application. First, we designed a linear, tabbed structure that guided the information-collecting process and ensured that all dependencies were correctly met (for example, information on teachers had to be obtained and completed before student information could be gathered). For selected subtasks, information had to be moved from one area of the display to another. To enable this in as few keystrokes as possible, we implemented a drag-and-drop function that greatly simplified what could have been monotonous, time-consuming data-recording tasks.

You can read the article here (pdf).

Types of Flow - A Quick Reference

How does the concept of flow manifest in an application? We usually look at three different aspects of flow during the design process.

The first is efficiency. Often we are seeking the use of an application to save us time in accomplishing what we have to do. In the user’s eyes, efficiency gains are often tied to satisfaction and are frequently where flow starts.

The second aspect of flow is hybrid navigation. Most applications of moderate or greater complexity will require a combination of linear and non-linear activities. It is important that the designer be able to empower each activity while keeping the overall scheme consistent and intuitive.

The third aspect of flow is comfort. When the interaction with a product is comfortable and natural, the product starts working at an emotional level. In technology-based products, accomplishing comfort in the design can be a significant differentiator in the marketplace.

Towards a concept of flow--UXD perspectives

"Flow" is an attribute we're talking about--and, hopefully, designing towards--here at Pathfinder. As application designers, we've been captive eyewitnesses to the proliferation of contradictory and unrelated features that consititues progress in IA and development.

Design theories of flow are derived, directly or indirectly, from the work of psychology professor Mihaly Csikszentmihalyi, who has dedicated over two decades to developing a theory of "optimal experience."

We've recently shared some of our thoughts on flow at the IA Summit and World Usability Day. Other perspectives include those of Kathy Sierra, the academically focused ACM, and designer/blogger Scott Berkun.

Plus, an interview with The Man Himself in Wired, titled (you guessed it) "Go with the Flow."

Usability Roundup - The Back Button

An oldie but a goodie -- the back button. The bain of designers, developers and usability experts everywhere. Some love it, some hate it. Here is a roundup of some of the best resources on this topic.

Web Navigation - a treasure trove of web usability research by Professor Andy Cockburn of the University of Canterbury, Christchurch, NZ. If you are after some hard data rather than speculation, this is a very good place to start.
Navigation Blindness - Why users ignore navigation and what to do about it.
Flash Back Button Fix - Robert Penner came up with this back button/bookmark fix for flash a while back.
Attack of the Back Button - Some words of warning from John Rhodes. While some of the techniques on this page may be a little worn, the sentiments are not.
dojo.io.bind() Intro - A discussion of the usability issues around Ajax/XHR breaking the back button and a possible solution to the problem within the Dojo toolkit.
Fixing the back button that AJAX broke - An excellent analysis of the problems of the back button, and the related problem of bookmarks, and a lengthy rumination on some possible solutions.
Flash Usability - The flash folks have been wrestling with the back button for a bit longer than the Ajax folks. This is a long article with just a little bit on the back button, but some of their suggestions are quite useful.
Breadcrumb Navigation - With breadcrumbs, users used the back button less frequently, but overall task efficiency was no better.
Exploring User Mental Models of Breadcrumbs in Web Navigation - Another study on bread crumbs as a solution to back button issues.
SmartBack: Supporting Users in Back Navigation - excellent overview of research in navigation and some tested ideas on how to inprove back navigation. Could be very interesting for those implementing their own "undo" functions in Ajax.
Fixing the Back Button and Enabling Bookmarking for AJAX Apps - Mike Stenhouse's crack at fixing this problem.

The Experience behind User Experience Design

Back in the days of rigid gender stereotyping, Lily Tomlin observed that if we all grew up to be what we wanted to be, the world would be full of firemen and ballerinas.

I don’t recall aspiring to either of these vocations (too timid for the first, too tall for the other). More to the point, I never thought I’d eventually evolve into. . .ummm. . . whatever we’re being called today. Being WOTTI (Way Older Than The Internet), my education and professional expectations were defined in areas that seemed remote from technology, interface design, or usability. With degrees in English Literature and a late-blooming resistance to a life in academia, I began to accumulate the quixotic resume of the Liberal Arts graduate.

Eventually, I spent several years as an Instructional Designer (ID). As the internet boom gained increasing momentum, the small technology consulting company where I worked was acquired by a large technology consulting company, and our quirky New Media group was reinvented as the firm’s semi-quirky User Experience practice. Then, as now, we sought to crystallize our identity—and affirm our corporate value—by creating a clear, hopefully self-explanatory job title. I wince to remember that in the mid-90s we called ourselves (without irony) “Cognitive Engineers.” Now, “Information Architect” has gained currency, a title that retains the methodical and craft-like aspects of the role, while successfully distancing practitioners from the inevitably Devoesque connotations of spiky, mass-produced cogs and hand tools. To stay billable, “cognition” and “engineering” are two concepts that should not be paired on the same business card.

Actually, a background in ID is great preparation for a career in UXD. Both disciplines are solidly user-centric and require creativity as well as technique in planning and development. The two key goals of the Instructional Designer are to optimize content for organization and understanding and to determine learning goals and appropriate success metrics—both of which are important but often overlooked strategies in designing websites and applications.

The successful Instructional Designer has the ability to quickly understand and then effectively communicate information from complex knowledge domains. Although I’ve designed web-based training for neurosurgeons, you probably wouldn’t want me brandishing a scalpel in your OR. I may not be able to do—but I can teach. Our firm specializes in the design and development of complex applications, requiring a learning curve that approaches the perpendicular. This skill is valuable to me as a consultant as well as a designer.

I respect my colleagues who have had the benefit of formal training in HCI. I’ve had to create my own curriculum through reading, workshops, and work experience, and I wish I’d had the opportunity to study and experiment in a more cohesive and less project-driven way. But I admire—and have learned from—my peers who have come to UXD from more scenic routes. Certain disciplines have obvious synergies and commonalities—architecture, visual design, marketing, computer studies. But I know fantastic UXD practitioners from other backgrounds: quantum physics, music, healthcare. UXD is not an easy-entry profession, but it is one that welcomes the experienced traveler. I recently met an Information Architect with background and training in theatre, who feels that the persistent thread in her experience is the love of narrative—whether storytelling takes place on the stage or on the (computer) screen.

Maybe my friend and former colleague Jason lives in the best of all possible worlds: his undergraduate degree is in English, he has deep experience in development, and he’s recently completed his Master’s in HCI at DePaul. But who’s to say which of these experiences makes him an excellent User Experience Designer?

Designers on Joel

Apparently we weren't the only ones to notice Joel Spolsky's rather empty observation on usability. John S. Rhodes over at WebWord also takes issue. He puts it very succinctly:

If a software product is meant for thousands of users, exactly who is expecting exactly what?

Indeed. I'd go a step further and say that what even one user expects from an application may change over time. For one, they may appreciate an application that provides training wheels early on and prefer one that lets them get down and dirty as they become experienced in the application's domain.

Maybe it's easy writing usable software if, like Joel, you stick to bug tracking software and the like. Come out into the real world and deal with non-technologists and you may get a rude reception.

Not-So-Great Expectations

Joel Spolsky, at Joel on Software, had a provocative post earlier this month, entitled "Usability in One Easy Step (First Draft)."

Here's an extract:

So, usability. That's really at the heart of good design, and I'm going to spend a lot of time on it.

The good news is that I can teach you everything I know about usability while standing on one foot. Ready? Here we go:

Something is usable if it behaves exactly as expected.

That's it! That's the whole story! As Hillel said, all the rest is commentary.

One foot, ladies and gentleman! The other, we presume, is aimed squarely at the collective posteriors of UXD practitioners everywhere, with their techniques and theories and methodologies and other varieties of snake oil.

It's a truism that "making things easy is hard." Spolsky's Principle (First Draft) strikes me as being simultaneously concise, self-evident and facile. His use of the passive voice is revealing:

". . . if it behaves exactly as expected."

Expected by whom? Under which conditions? Spolsky makes an easy argument by dividing the world into two groups (Mac and PC users), whose expectations have been created and honed by software developers with extreme--documentable--precision. But how many real-world cases are this clear-cut? User expectations often come in more than two flavors.

User-centered design has developed various methods for discovering and confirming user expectations throughout the design process, from research on best practices through full-blown usability testing. Indeed, a classic probe incorporated into usability walkthroughs (and one I use heavily) is the repeated question "Is this what you expected to see/happen?"

It can take a lot of skill, time, and effort to gather and synthesize user data, and then determine the most effective way to apply the knowledge to the design. And what happens in the (all-too-frequent) instances in which there are no expectations?

Looking forward to Spolsky's Second Draft. Hopefully, he'll have both feet on the ground next time.

Thoughtful gesture? Peter Coffee’s column misses the point.

As I leafed through my ever growing stack of tech magazines yesterday, a column in eWeek by Peter Coffee, entitled Thoughtful gestures – don’t make complexity elegant; make it disappear caught my eye.

Mr. Coffee was writing about a patent application from Apple for processing multipoint gestures on a touch input device. The language of patent applications is notoriously dense and jargon laden, so in laymans terms, this is about making it easier to interpret what a user wants when they touch a screen or touch pad at multiple points at the same time. Some simple examples of multipoint gestures include squeezing, stretching or twisting motions while touching a screen with your finger tips.

Mr. Coffee's contention is that this invention is a way of making more complex tasks easier to perform, that it has no real-world, practical application, and that this is the wrong problem for inventors to tackle. He states that “I’d rather see interface efforts based on watching what users do, understanding common needs and designing systems in which those actions are simple. Making complexity elegant is an achievement, but I'd rather just make that complexity invisible.”

This is a fine sentiment, and a good one-sentence description of user experience design, but he really misses the point of how new input device inventions relate to user-experience design.

He illustrates the uselessness of gestural interfaces by describing two ways of saving a users work – one using a whole series of convoluted gestures that makes the user look like she’s doing the Macarena, and a simple, elegant way of using keyboard strokes. Boy, based on that example, gestural interface sure sounds like a bad idea, and inventors should stick to improving how to use existing input devices.

The trouble with this example is that the same argument was made about the mouse when it joined the keyboard as an interface device. There were (and are) many things that are easier to do with a keyboard than with a mouse – saving a file using shortcuts, typing a letter, entering data in a spreadsheet, just to name a few. Does that make the mouse useless? Why use something as complicated as a mouse?

Let’s take the case of a user putting together a process diagram in Visio. Using a keyboard interface, a user can perform a lot of complicated keyboard strokes to generate, place, link and annotate the diagram elements. Meanwhile, back in the real world (as Mr. Coffee would say) the user simply drags and drops the elements in place using his mouse, touch pad or pointer.

Clearly, different interfaces are good for different types of actions, and it’s up to the user experience designer to apply the appropriate combination of available interfaces in a way that lets the user simplify and streamline their interactions.

So where might using a multipoint gesture interface simplify a current, real world interaction? How about Google Maps: Multipoint gestures such as squeezing, stretching or turning, combined with single point gestures like dragging, could make navigation significantly simpler and faster than the current mouse-based approach.

The point of inventions like this is not to make more complex acts achievable, but what things can be simplified using these inventions. Almost all ways in which we interface with computers are pretty complex. For example, learning to use a keyboard is a lot more complex and time consuming than learning to use a mouse, and learning to navigate using keyboard shortcuts requires much more familiarity with an application than using a mouse. Gestural interfaces need be no more complex than keyboard or mouse interfaces.

So inventors, keep inventing! Between user experience designers, developers and usere, we'll take the best inventions to make things genuinely simple.