Testing search

My sense is that information architects generally have less influence over the core experience of search than they do over other aspects of a website’s interface, and I think that’s a bit of a shame since it’s such a critical resource for so many users. Sometimes a website’s search engine will be a user’s primary experience of the site’s architecture, but here we are on the sidelines watching as the implementation teams wield control over the search experience.

In our work on Vanguard’s search engine, we developed a collection of methods for testing the quality of the results it was bringing back. These became critical tools underlying optimization efforts and functional design strategy, and ingrained the IA’s deeply in the quality of search. I think that these testing methods can bring a lot of value to the user experience community, so I’ve proposed a pair of articles for Boxes and Arrows explaining them.

Both tests are premised on the idea that the search engine should return the best matches available for a user’s expressed interest at the top of the results page. That sounds really simple, but there are a lot of complicating factors that weigh into it:

  • How closely does any of the available content actually match the user’s real interest?
  • Has the user done a good enough job describing what he or she wants?
  • How does the search engine parse the user’s input?
  • What standards does the search engine use to determine what constitutes a best match?

As a result of these kinks in the system, search is inevitably much more hit-or-miss than we’d like it to be. So from the user experience perspective, the first questions we should ask are how often does the engine return the very best matches at the top of the results list, and how good are the matches it does return?

Well it turns out we can measure those things, and it’s not especially hard to do. You can put a number to it, then set objectives for how much you’ll improve over time. (The critical resource here is search logs — which is why I’m psyched that Lou Rosenfeld has a book coming out on just that.) In the process, the strategy shakes out too. You’ll find exactly which searches are underperforming, which among those are the most important to people, and the best ways to fix the system. That puts IA’s right back in the center of the search experience.

Those evaluation methods are what I’ll cover in the articles. I’d greatly appreciate any feedback submitted on the B&A site, and incorporate any input into the text when writing them.

The amazing WiiMote even makes julienne fries

Johnny Lee is a researcher at Carnegie Mellon who has been working on ways that you can use the Wii’s controller to create interfaces for PC’s.  If you haven’t seen his demonstration videos before, they’re definitely worth viewing.  Trust me, you’ll be blown away.

You can connect the WiiMote to any PC with a bluetooth receiver; the software you create from that point is bounded only by your imagination.  The results here are pretty remarkable.  This is a perfect, and particularly literal example of a game innovation extended to conventional UI’s.

Video game presentation uploaded!

I’ve updloaded a PDF version of my presentation from the 2008 IA Summit,  Extending the Gaming Experience to Conventional UI’s (6mb).  It’s shown in notes view, since much of the content was conveyed through speech with the slides serving as visual aids.

Also, once I receive the audio file I’ll set up a slidecast that will allow the presentation to run automatically with the actual recording from the live session (fun!).  That’s really going to be the ideal way to view it, but it may take a little while.  I will post it here once it’s ready.

Game UI design discussion group

I’ve set up a discussion group for game user interfaces on Yahoo.  For those of you who’ve expressed interest in continuing the conversation on extending the game interface to conventional UI’s, this forum will give us a way to share in it collectively.

I’ll also be starting a game UI pattern library on Flickr.  More to come on that soon.

IA Summit ‘08: Day 1

Today I attended the session on design patterns presented by Christian Crumlish, Erin Malone, and Lucas Pettinati of Yahoo.  The topic was directly relevant to my work.  They’ve done the UX community a tremendous service by sharing their work so publicly.  Today they even provided all of the attendees with thumbdrives preloaded with templates and stencils of the various patterns from their library.

I took particular interest in these points:

  • I had a question about whether there’s a useful distinction between patterns and standards.  Livia Lebate had an interesting perspective, suggesting that patterns are not sensitive to context.  A pattern is natively abstracted from any usage; once you apply it to particular context, it becomes an instance of that pattern.  It might not be a standard, but all standards are specific to some context.
  • Granularity was another important issue.  For example, you could say that something like a logon is a pattern. Or instead, you could break logons down into smaller patterns like username and password fields, “remember me” cookies, and password reclamation functions.  The presenters suggested that such pieces only rise to the level of a pattern when they might occur in contexts separate from the parent pattern.
  • Christian said that Yahoo’s pattern library started by focusing on atomic page elements, rather that patterns that occur across multiple pages.  This was because they were easier to write and provided immediate value to Yahoo’s developers.
  • Providing wireframes and code samples in a package with patterns strongly encourages their adoption, because it makes other people’s jobs easier.
  • Designers may find it difficult to browse a pattern library by its titles.  Images are really important to them… perhaps having an option to browse patterns by thumbnails?
  • I noted that it might be useful to document patterns in their simplest possible state, then describe the variations that can be applied to it.  So a slider only absolutely needs to have a track, slide control, and a display of the current value.  To that, you can add tick marks, midpoints, additional slide controls, etc.

IA Summit ‘08: Day 0

Arrived in Miami today, and got together with the rest of the Vanguard team.  The preconference starts tomorrow, so this posting is dedicated to pure fluff.

We went to the Mambo Cafe, a Cuban restaurant in Riverside Park.  It was very good and I’d recommend it to anyone attending the conference, but I’ve been told of even better Cuban places nearby.  Guess I’ll have to try those too to make a fair comparison.

Miami Preview

The IA Summit starts next week in Miami, and yesterday I got a sneak preview of two of the sessions being presented by my colleagues. (Don’t worry, no spoilers.)

Michael Magoolaghan is relating his experiences participating in the renovation of a local public library and its website. If you’ve ever complained about having insufficient funds for a project, you have nothing to complain about. It’s remarkable how, with no budget to speak of, they applied creative thinking to achieve research objectives in excess of what you see on many funded projects.

I also saw about 85% of Andrew Hinton’s closing plenary. He’s gone a long way toward clarifying how we should conceive of information architecture’s locus in the broader space of user experience. It’s a really great presentation, and I’m sure it’s going to make a big splash.

My own presentation on extending the gaming experience to conventional UI’s is scheduled for 9am on Sunday the 13th (though there’s a possibility that logistical concerns may push it back to 9am on Saturday). I’m really very excited about it, and I think attendees will find it to be interesting and fun.

Looks like we’re heading into a really great conference!

Whose experience is it, anyway?

The question of ownership of the user experience has been coming up quite a bit in my work recently. I haven’t seen a lot written about this (references would be welcome), but it strikes me as being a fairly important subject with tangible implications for UI design.

I’m inclined to say that under most circumstances, the experience is best understood as being owned by the user.  But designs will often box people in, limiting their freedom to do as they like.

Comparison interfaces are a good example.  Cars.com has what I think is a remarkably well-conceived tool for comparing any make and model of car across various criteria.  I’ll write a bit more about why I think it’s so great in a future posting, but the glaring error is that it sets a hard limit on how many cars you can view at one time.  If I wanted to look at more than four cars at once, shouldn’t I be able to?  Yes, it’ll result in horizontal scrolling, but wasn’t it my choice to allow that by adding so many cars in the first place?  The website’s limitation seem to intrude on my ownership of the experience.

Compare this with BlueNile’s interface, which I think is even more brilliant (ha!) , and another subject for that forthcoming post.  Here, I can add all of the criteria I want to the table: polish, symmetry, depth %, table %, and so on.  The table  just scales right off the edge on the screen.  And there’s a secondary (nearly redundant) comparison interface where I can add just as many diamonds as I please.  Sure, it scrolls and you lose the row headings, but I understood the implications of what I was doing and chose to do it anyway.  Why shouldn’t I have that ability, and judge for myself whether or not it’s the best way of working?  BlueNile’s philosophy is, properly, “You asked for it, here it is.”

This is what I mean when I talk about ownership.  I think that at various times, designers can take too much control of the user experience.  This is good only insofar as it helps me to do what I want; the hard limits set by Cars.com and many other comparison engines reduce that capacity.  I think that sometimes it’s best for the designers to let go a bit, and acknowledge that in the end the experience just doesn’t belong to them.

Flash Design Heuristics

Flash presents a unique subset of design challenges and opportunities, many of which may be unfamiliar to a person who’s long worked in conventional Web UI’s.

I believe that design heuristics work better when they’re more focused to your design medium.  So I’ve put together a set of guidelines, below, to assist designers working with Flash-based applications.  I’ve done a fair amount of Flash design, and these are the principles that have helped me in the past.

Mirror well-established conventions
Avoid presenting interface elements in new ways when established conventions are available.  Rely most strongly on the conventions common to the web, followed by those common to desktop software.  Controls should support all the same behaviors in a Flash interface as they do elsewhere.

Allow user control over progress
The rate of progress should be controllable by the user at any point (outside of loading times).  Provide next and back buttons for serial progression.  Provide a timeline slider and other playback controls for video and audio.  Allow users to cancel self-running interface elements.

Error prevention
Minimize opportunities for the user to make an error.  Eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Readability
Ensure that onscreen text is adequately readable.  Do not anti-alias small fonts.  Bring animated text to a stop to allow users to read it.  Maximize the contrast between text and background.  Avoid overlaying text on busy images that can interfere with the appearance of lettering.

Passive comprehensibility
Users should be able to anticipate an object’s function simply by looking at it.  Users should not have to actively move the mouse cursor over a control to reveal its function.

Avoid downtime
Users have minimal tolerance for unproductive time when using the web.  Do not use splash animations.  Allow users to accomplish something while an application loads. 

Minimal requirement of mouse skill
Assume coarse mouse movement.  Do not punish users for using the mouse as they are accustomed in software.  Observe Fitts’ law.  Support keyboard input.

Provide actionable next steps
Don’t let the application come to a dead end.  If there is an end state, invite users to take next steps.  Allow them to review what they have already seen, modify parameters, provide feedback, link to related information, or access similar applications.  Keep the interaction alive.

Controlled use of animation
Use animation as primary content or to draw the eye to important elements of the interface, but avoid superfluous animations that are peripheral to the user experience.  Do not loop animations indefinitely.  Avoid using animations in a way that may make the interface resemble an advertisement.

Support accessibility
Ensure that users with disabilities can perform the same functions as those without.  Keep download times and processor-intensive operations within reasonable limits.  Computer speakers are often turned off or absent, so don’t rely strictly upon the audio channel to convey information.

Worst Design, Ever

In commemoration of the election season, I’ve recreated the infamous Palm Beach Butterfly Ballot from the 2000 election in a format that’s ready for printing. Regardless of your political affiliation, it’s clear that this is a perfect example of the import of usability in interface design, as Bruce Tognazzini explained in 2001. Is there another usability problem that’s had effects quite so far-reaching?

Something that’s always bothered me about the whole Florida debacle was the general public disdain for the Gore voters who mistakenly cast ballots for Pat Buchanan. In his book “The Nine” about the modern Supreme Court, Jeffrey Toobin writes of Sandra Day O’Connor’s thinking when considering the matter in Bush v. Gore:

She had convinced herself that the root of the issue in Florida was simply that some voters hadn’t figured out how to cast their ballots the right way. In her view, it wasn’t the job of election officials — or the courts — to puzzle over the true meaning of ambiguously marked ballots. If the voters didn’t bother to learn how to vote correctly, the state shouldn’t try to figure out what these hapless souls meant to do.

I think that people in my line of work instinctively cringe at this sort of sentiment because it’s antithetical to our worldview. O’Connor assumes that the user is at fault; our perspective is always that blame rests with the designer for leaving the interface open to misinterpretation.

I’m very heartened that there’s so much enthusiasm among voters this year (interesting times indeed). But the Butterfly Ballot is a cogent reminder that democracy comprises people, processes, and technologies that can break down when we don’t bother to pay sufficient attention to them.

Next Page »