UXD - User eXperience Design

Worst user experience ever....

We were in a meeting talking about possible ways to showcase user experience design when I brought up statistics or quantifiable metrics. Everyone groaned, as they do when I bring things up, but mainly because it tends to be a bit of a sore spot in the world of usability, It seems obvious that good user experiences lead to more popularity, sales and general peace and happiness. However, percentage gains and metrics are suspect since there is no way to have a double blind scientific study of 'usable' vs 'unusable'. Thus, the practice of reviewing and refining the user experience can often be considered optional or put off till after release or just too hard to 'bake in' to the process because it doesn't produce hard numbers. In my defense I did come up with a situation where hard numbers and user behavior told a very interesting story.

The 'worst experience ever' in the title came to mind as an illustration of the confusion and opportunities that surround metrics and usability design. I speak of last months release of Radioheads "In rainbows" (since decommissioned). If you haven't downloaded the music yet, or heard the story umpteen times, it happens that Radiohead created a sanctioned way to pre-offer their new record it for download as mp3. Radically, customers could pay what they wished for it, including nothing. The real story as I saw it came from the way they managed this transaction - in the most confusing, user unfriendly way possible. The site is garish and difficult to comprehend, even though the download to the music is the only goal. You are asked to pay before even sampling the album. When purchasing, the amount is left blank, and in pounds, so no translation of other currency, no 'suggested' price. If you enter an amount below 1 pound you are greeted with errors, any questions or advice explaining the process all appear in popup windows, its a mess. When the user is finally able to complete the transaction, they receive nothing, but wait for an email with download instructions.

With all these hurdles, it only seemed natural to pay nothing, which I did, since it all seemed like some kind of con, as trustful as I am of their brand. After a few days (I did it before 'release'), an email arrives with a download link. Then you can finally sample what you (didn't) pay for. It was my intention to check out the record (which was quite good, actually), then return to offer a few buck donation to the cause. However, you have to essentially re-purchase the record as another 'person' so it seemed as though I would be guilty of 'stealing' it the first time, and I got busy and...well...

Even though it has been a kept secret of the band, news stories came out speculating that as many as 60% of people did not pay. Many commentators used this metric as somehow holding some significance of why and how people think of paying for music. No one mentioned the horrible shopping experience, outside of a few blogs like this one. In all, it should be noted that every person using the site did complete the task successfully, and no animals were harmed in the 'stealing' of the music. The only casualty was the business model. If the goal was to monetize the download, it failed in every respect by making it difficult and unwieldy for the user to pay a fair amount. However, the user was satisfied by getting the music they wanted. So perhaps usability is better defined as aligning business strategy with user goals? I know the statistics on the user behavior was much reported, so perhaps it's time for a double blind study for their next record - with a better user experience will people pay more? Can't wait.

DUX2007 - Simplicity

Too often, the overarching requirement we hear from clients is that the product must be simple to use. As designers, we nod our heads and agree that yes indeed, simplicity is a worthy goal for this project, without ever defining what is meant by simplicity.

At the opening night of the DUX07 conference, B. J. Fogg, from Stanford University's Persuasive Technology Lab, talked to us for a bit via video about his recent explorations into simplicity. What exactly does simplicity mean? What are the determining factors of simplicity, i.e., what am I looking at in order to rate whether or not a product is simple to use?

To Dr. Fogg, simplicity is not a characteristic of the product but rather a perception of the experience. From his studies and research, he's determined there are six elements of simplicity:

• time - can I spend the time learning to use a new product? no? then it's not simple
• money - can I spend money on a new product?
• physical effort - does it require exertion beyond my usual effort?
• brain cycles - do I have to think for a long time?
• social deviance - does it go against the social norm?
• non-routine - does it break my routine?

These six elements vary by individual and by context and there are trade-offs. For example, if I'm a college student who has time but not a lot of money, I might be more willing to invest my time in learning a new product than, say, a business executive who doesn't have the time but would be more willing to spend a little more money on a product that doesn't require a lot of time.

Simplicity, therefore, is a function of the user's scarcest resource at the time. To state it another way: a product, task, etc., is truly simple until it requires a resources that's not available. But remember, Dr. Fogg said that simplicity is determined by the perception of the experience. Which means a task can be perceived as simple if it uses less resources than expected.

Now I'm not saying that from now on we market our products by setting the expectations high to guarantee the perception of simple .... but it sure is tempting.

Technorati Tags: Design, Information Architecture, Usability

Design? Meet Research.

A running discussions I have with my mom revolves around a cellphone: I think she should have one; she disagrees. I say it makes sense to carry one in case of emergencies; she says her regular phone is good enough for her. I say her regular phone doesn’t work in the car; she states that you shouldn’t talk and drive. Her logic defies a response.

But what I think she really dislikes about cell phones is that they’re just too complicated to use. When my mom looks at my phone, her first question is, well how would I know how to use it?  A valid point. She is accustomed to a landline -- you pick up the handset and there’s a dial tone (no, don’t even start -- she has no cordless phones). Her phone has raised buttons, not a flat touchpad, and these buttons contain numbers, not icons. (I have to admit, I don’t blame her about the icons. I couldn’t even begin to describe the icon on my phone to pick up a call -- it has no name. You have to train yourself as to its meaning.) What she really needs is a phone designed just for her.

#*&)#*$)# Software.

Nothing is more frustrating than having your software beep at you when you’re trying to do something you *know* it can do, and you’re flummoxed as to why it’s resisting your every effort to continue on with your work. All attempts are met with the same impersonal beep, whereupon you conclude that (a) the software hates you and (b) your only recourse is to begin swearing with enough proficiency and creativity to make a sailor blush. You just might be the victim of a mode error.

Oops! Our Bad.

There are two ways of producing error-free software. But only the third will work.
~ anonymous

There comes a time in the life of any application when an error occurs. Ideally, the software should be written in such a way to gracefully handle the exception and, if necessary, let the user know how to proceed. However, some development teams seem to focus solely on system errors and their output, which makes sense since they’re deep in the writing of the system code, but it generally leaves the user out in the cold.

Writing error messages using language the user understands is an essential element of user-centric design. A stack trace is not written in a way the user will understand. A database connection error holds no meaning for the user. Do not display these at the presentation layer. Exceptions such as these need to be handled behind-the-scenes, and if the application cannot gracefully recover, only then display a message to the user and explain what they need to do in order to resume their task. In other words, use the language of the user and not the system to explain the error and supply them with an escape route.

Whenever possible, the system should display the error message on the page where corrections need to be made in order for the user to continue on with his task. However, this isn’t always possible. Some errors will require the user to return to the beginning of the task flow and start over. In either case, preserve the user’s work as much as possible so they don’t have to enter everything all over again. (They will really appreciate it.) And if appropriate, highlight any data that caused an error to be thrown and advise the user to double-check their entry.

Regardless of which page they’re displayed on, error messages needs to be both visible and highly noticeable. Don’t hide them below the fold and don’t have them blend in nicely with the visual elements. They need to prominently stand out so the user knows the next steps to take. If the next steps are on the same page, i.e., missing data, highlight the fields the user needs to update. If the next steps require the user to return to a previous page, provide a link within the error message so the user can easily access that page. Tell the user there was an error and give them an escape route.

Of course, every effort should be made to develop a graceful way to handle exceptions, but occasionally messages need to bubble back up to the presentation layer. Letting the user know what happened and what they need to do using language they’ll understand goes a long way to creating a good user experience.

Wait, how did I get here?

The importance of navigation is a given when designing a site. Design it poorly and it’ll have the same effect as having no navigation, i.e., leaving your users lost and confused and rendering your site useless. Taking the time to create a well-designed, well thought-out navigation is worthwhile because good navigation is a critical component in convincing a user to come back to your site. After all, if the user feels they’ve done nothing but encounter obstacles and roadblocks while attempting to attain their goal, where is their motivation to return?

Hey! you protest. I’ve already clearly defined the Global and Local navigation and the taxonomy is spot on. What’s next? O.k., here are two other ideas that can be brought into play to assist the user in getting around your site.

You Are Here. It used to be a standard navigational guide to unlink and visually highlight the navigational element for a section when the user was on the main page for that section.  The majority of large sites, however, now use one global navigation template for ease in maintaining their code. And more often than not, most teams can’t or won’t take the time to build in multiple if/then statements to change the look of the navigational element based on context. But it’s so worth it. Highlighting and unlinking a global navigation item when the user’s on that page comes with two benefits: it gives the user the visual recognition of their present place, and prevents them from clicking a link that sends them to the page they’re already on.

Differentiate Your Links. Not all links are created equal. Some go to other pages, some expand areas on a page, some download documents, etc., etc. So if these links all behave differently, shouldn’t they be displayed differently as well? Handle off-site links by letting the user know they’re leaving your site (see the external  links section on any wikipedia page for an example). Or consider changing the cursor from a hand to a pointer when a link is no longer active (sometimes you don’t want a link to be active in the hover state, e.g., when the link is used to display a dropdown menu on mouseover and not to link to another page). Combining CSS with your creativity, itemize the various types of links you have on your site and come up with ways to differentiate their visual display to clue the user in to to the link's behavior *before* they click on it.

Navigation, in all of its forms, is key to giving the user a good experience. If they’re lost and confused, chances are you’ve lost them as a site visitor. Keep them happy, and they just might visit again and again and again.

Do you know your SiteKey?

SiteKey is a system some sites (notably banking sites) use to prevent customers from logging into fraudulent sites dummied up to look like the actual sites. During registration (or updating an account if it was created pre-SiteKey), the user is asked to select an image they would like to associate with their account. Thereafter, the SiteKey image is displayed when the user logs into the site, reassuring them that they’re logging into the actual site. In theory, displaying the image instills trust and confidence in the user.

The reality, according to a joint study conducted by Harvard and M.I.T., is that users tended to enter their password regardless of whether or not the image is displayed. Only a few refused to enter their password citing security concerns. Not good.

Now, keep in mind that the test was done in a controlled environment with the users being asked to conduct routine online banking activities. They may have felt secure in their surroundings (an official test, Harvard, M.I.T., etc.), and it may not have bothered them to find no image being displayed (if they even noticed). Plus, typing the url directly into the browser vs. clicking a link from an email generates different levels of security which may have caused them to go directly to the input boxes for login.

But perhaps the images (or lack thereof) were ignored for other reasons. For those of us who only rarely login to SiteKey sites, it’s next to impossible to remember the image that we’ve selected. Face it, I can barely remember my passwords. So even if I see an image, I have no level of assurance that the site is legitimate since my recollection of whether or not the proper image is being displayed is spotty at best.

However, there is one exception -- a site that allowed me to upload my own image and associate it with my account. Because I could use an image that is meaningful to me, the SiteKey implementation thereby became a much more effective tool in alerting me to the site's legitimacy. Amazing how things improve once you involve the user.

Ajax and Design

Some random thoughts on Ajax and design.

Don’t design your page around Ajax. Armed with the same user-centric methodology you’re (hopefully) using today, you’ll first design the page and then see where Ajax can be added to enhance the interaction behavior. Start with the wireframes, which detail the page structure and content layout. Detail the wireframes by adding in the page and/or element behavior as you’ve always done. From there, evaluate the design and determine where Ajax can be used on the page to enhance the user experience.

One thing to keep in mind is that Ajax is best leveraged as an enhancement that gracefully degrades whenever possible. First defining the behavior of a page and then adding in the enhancement is one way to ensure it'll work in user agents that don’t accept client-side scripting, such as some mobile devices.

So why use it? Well, one nice thing about Ajax is that it gives the illusion of speed. It allows the browser to display information onscreen while continuing to query and receive data in the background. The user doesn’t have to wait for a page refresh before seeing new information. Because the browser didn’t have to wait for the entire results set before rendering data, the users perceives the site as being quick.

This illusion of speed, however, can backfire by confusing the user since they might not realize anything actually happened. Here’s where some basic usability needs to be tied into Ajax. Let the user know when something changes on the screen. Display a success message, highlight the new information, change from form elements to text, etc. What you do, of course, depends on the widget involved, page design, etc. My point is that you need to visibly indicate to the user that their action was received and acted upon.

The Iphone, why.

Years ago I would go to conferences and people would hold up their Palm and lecture us on why it worked, the economy of means, the elegance. Time passed and the same people - usually people who had not actually participated in the design process of the particular device - would hold up an Ipod and preach the wonders of the clickwheel and how it had revolutionized design on the order of bread slicers or fishnet hose.

That they usually missed the point was irrelevant. The value of the Palm was that it was much smaller than a Newton, and much faster because Palm asked people what they actually used. And both of them had coherent software interfaces that easily synced the stuff on your desktop machine. That the Ipod made having many gigabytes of purloined music sort of marginally legitimate was not trivial, either.

So I wanted to get in on the ground floor of helping Apple hype the Ipod phone, because I am predicting that this will save me a significant amount in conference fees over the next two years.

Why does this phone elicit responses like Alice’s, a post or two back? Which I fully admit I shared as all the Mac addicts read the real time blogs from Macworld while jobs was unveiling it. Oh yeah, it is cool!

But what it makes such a big splash is a study in contrasts, and how the competition failed to develop and market something that people can feel affection for.

The current crop of cellphones are junk. There are so many difficult to use features that the cellphone companies market a special line of simple phones for the very young, very old or especially annoyed.

And the phone companies are completely oblivious to this resistance. Because of the way that cell phones are sold, really as a token of the extortionist contract with the service provider, there is a critical reduction that occurs to the feedback from the user. The design of the phones is passed on as a feature list and separated from everything else in the users existence. An elaborate, undoubtably extensively discussed system to create a broken wheel.

The worst thing about the current phones - and don’t get me wrong, Razors look cool and have great ads - is that if you lose it your numbers and all of the phone specific programming is gone. Unless you have a Trio or a Blackberry, you are just out of luck. But even Trio’s and Blackberries don’t have a good mp3/mp4 implementation. Much less the overwhelming cultural currency [read: cool] of the Ipod.

The Ipod advantage in both cases is it’s connection to the desktop.

For phone numbers, it leverages a much more powerful interface; your desktop through any Vcard compliant program. So you have all of your email addresses on the phone; and backed up. Think weeks of texting saved. Imagine what you will do with that time.

In terms of features, the new phone is configurable. Which means, to a luddite like me, that you can turn most of them off. Thankyouverymuch!

Not having to carry around my Ipod and my phone is probably the least of the advantages. Waiting until all the early adopters buy it and the price falls will be the hard part.

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.

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

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 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   

Rethinking the Help System in an Ajax World

In desktop applications and the new genre of Ajax applications it's possible to provide contextual information to the user. This is typically done one of two ways. Either real estate is devoted up front to the display of this information, or a pop-up (or slide-in) of some kind emerges.

The ability to contextualize information physically suggests the necessity to rethink the creation of the help system. Not only must we consider what the information must be, but also when and where it will likely be accessed. The help system truly must be a system, not just an encyclopedia of the features of the tool (that is still a good thing to have, nonetheless).

The down side of a highly contextual help system is cost. Someone has to design it, not just write it (you have to do that too). There may be a good middle ground, though. Consider providing specific help access points contextually in your application for the things users are most likely to get stuck on. Provide opportunities for assistance, advice or suggestions in context where the benefits are significant to the task at hand. Let the user easily get the information, and get rid of it when their needs have been met. This approach can deliver value to your users, while keeping the creation and maintenance costs reasonable.

Technorati : ajax, design, help system, usability

If the hat fits--do you wear it?

I've just completed the first of three days of usability testing for a new educational online subscription product.  The multiple sessions are stacked consecutively; the 45-minute breaks I thought were ample in theory seemed to last as long as a single gasp today, as our team fought--not always successfully--an unfolding series of unfortunate technology events.

Still, I love the opportunity to do usability testing. I've been very fortunate in my career in UXD to have always worked in environments that did not create an unscalable wall between Information Architects and Usability Specialists. 

If research, including usability testing, can be defined as "diagnosis," and creation, including wireframes, site maps, taskflows, and the like, comprise "design," these two complementary, yin-yang aspects support, validate and enrich each other. I love the opportunity to play both of these roles, to wear both hats. I think it's made me better in each, and takes me back to my early education in arithmetic, where we "proved" the accuracy of any single answer through the complementary operation--the division problem was proved through multiplication, the subtraction problem through addition.

Usability testing diagnoses design. It's the analysis of user reaction as opposed to the creation of user action. Diagnosis looks outward to the users, acting upon the design; design looks inward, to the designers acting in lieu of the users.

EU Committed to Accessibility

 

The European Union has called committed itself to providing Internet access to all it's citizens by the year 2010. This is more evidence of the importance of providing quality content which is accessible. You can read the full article here. The decision comes as a result of a few disheartening reports about web accessibility for the disabled. From the CNET news article: "According to recent research, 81 percent of Web sites in the United Kingdom are inaccessible to disabled people, while a separate report found that only 3 percent of European public-sector Web sites met W3C accessibility guidelines." As we as a population grow more dependent on the web, it becomes ever more important to ensure that no one is left behind.

The EU's own site on accessibility policy has a sub area on web accessibility. They mention an initiative known as the European Internet Accessibility Observatory or EIAO. This organization's job is to crawl the web looking for scofflaws -- big brother is crawling.

 

Resolution Past by a Majority

Qualified member of an elite class that includes the eternally regifted fruitcake of Christmases past, the Star Wars movie franchise, and the fervent hopes of the diehard Cubs fan for a Series sweep, the 800x600 resolution is truly one of those Things That Will Not Die.

We presume a dismissive, somewhat disparaging persona for the user with yesterday's browser:  either very young, undeveloped in either manual dexterity or a sharpened sense of aesthetics, or, god forbid, over 45, eyesight failing, faltering in the doddering twilight of the wired lifespan.  Conveniently, these two groups are usually of secondary importance--if at all--to the marketing folks targeting the high-profile general demographics.

Nevertheless, this user, who today represents barely 5 - 10% of all users (and dwindling all the time), maintains an extraordinary grip on website design even today. Our own website is currently optimized for 800x600, and I regularly design to these standards, often on projects that are likely to be of little interest to second-graders or their grandparents.

Of course, there's a catch. Designing for 800x600 in a world of 1024x768 and beyond is still a good practice. Indeed, with screen monitors achieving larger and larger footprints, a good many users have accustomed themselves to multiple, partially minimized windows, as Jennifer Kyrnin's ad hoc user research suggests.  Also, widgets and navigation add-ons can subtract signficant real estate from even a fully maximized, higher-resolution browser. Finally, as several designers have observed, if a layout doesn't work for 800x600, it probably won't improve at double the resolution.

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. 

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.

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.