UIEtips: Browse vs. Search in Application Navigation

Jared Spool

February 22nd, 2010

When our applications grow large and complex, how do we help users find the right commands and functions? If we were talking about large data sets, we’d build in a search capability. Would search also work for finding commands?

Our good friend, Hagan Rivers, explores that question in this issue of UIEtips. Inspired by our recent UIE Virtual Seminar on Search & Discovery Patterns with Peter Morville and Mark Burrell, Hagan started thinking about her own area of expertise: making complex navigation simple. That’s when her article, Browse vs. Search in Application Navigation, was born. We know you’ll enjoy it.

Read today’s UIEtips article.

At our upcoming UIE Web App Masters Tour, Hagan will be sharing with us her secrets for dealing with gnarly, complex web app navigation issues. She’s just one of the great designers we’re featuring in this four city tour, which starts in San Diego next month. Details for the tour are at www.UIEtour.com.

Are you building large applications where users need help finding commands? What techniques have you tried? We’d love to hear your experiences below.

One Response to “UIEtips: Browse vs. Search in Application Navigation”

  1. Michael Zuschlag Says:

    A quick GOMS-KLM suggests searching for a command by typing 5 letters takes about 7.5 seconds. GOMS-KLM also suggests 2.5 second per menu selection. This implies that even for users familiar with the app, Search performance will be about equal to menus for menu hierarchies that are three deep. Allowing for habit-formation and “muscle memory” in both cases yields the same results. A three-deep menu implies about 500-4000 of commands, so it makes sense for apps that Rivers designs to have Search to supplement the menus. Search is superior when the hierarchy is four deep or more, but now you’re talking tens of thousands of commands; I shudder to contemplate such an app.

Add a Comment