28 December 2012
I was very fortunate to have standards expert Aaron Gustafson as a techical reviewer of my book, Designing Web Navigation. He recently ran a piece in .NET magazine called “Master Mobile Navigation,” and he asked me to contribute a sidebar to that article.
Below is the short text I wrote focusing on the position of navigation menus.
Position Is Everything
The position of navigation menus is an important decision screen designers have to make.
In desktop applications, main navigation options are typically located horizontal along the top. This convention is nearly universal, but with exceptions. An advantage is that the functionality and tools of the program are given the full screen width.
The first websites with static navigation menus positioned them vertically on the left. For a hierarchical, content-based website, this shows the structure of the pages well. The menu is also always visible when the page loads, even if there is horizontal scrolling. But web navigation is not as standards as desktop applications: menus also appear along the top and even on the right side.
With the design of mobile applications we see a different set of conventions emerging. On smartphones, menus are often horizontal along the bottom of the screen. This provides easy access with the thumb when holding the phone in the palm of the hand. It also avoids having to reach across the screen to touch an option, as happens with a top aligned menu.
What’s more, hidden menu options are common with mobile devices. These can either be accessed by swiping a small tab to open a “drawer” on screen or via a hard key on the device itself. Discoverability and memorability of these options is lower since they are out of sight, but this tactic saves valuable screen real estate.
Tablets frequently have menu bars at the bottom of the screen, but also along the vertically along the left side. Their slightly larger screens allow for this. A left-hand position also mirrors how people hold tablets on the sides on the device. Overall, we find even more variation in location of navigation menus with mobile devices than with websites.
So what’s the best screen location for mobile navigation? The situation, not some arbitrary guideline, should ultimately drive your decision. There are potentially many viable options. For designers, these means it’s imperative to thoroughly understand user behavior, the context of use, and the limitations of the device to make informed decisions.
Text by James Kalbach as appeared in “Master Mobile Navigation by Aaron Gustafson, .NET, Sept 2012.
12 March 2011
I a previous post I pointed to a recent trend of having a static navigation bar at the bottom of the page–the static footer bar. This navigation mechanism is usually a type of utility navigation or tool bar of sorts.
A conversation over on the IxDA discussion board highlights a similar technique that locks a navigation at the top of the screen. I call these docking navigation bars. One example discussed comes from GamePro.com. Here’s how it works:
A normal main navigation bar is presented towards the top of the page inline below the site logo, as shown in the image below:
Figure 1: GamePro.com homepage, at the very top of page.
Then, as you scroll down the page, there will be a point where this main navigation bar is no longer visible. At this moment the bar docks to the top of page, allowing the content to scroll behind it. The docked navigation then stays visible and accessible as you scroll the entire page, which on GamePro.com is fairly long. Figure 2 shows the docked main navigation bar as I scrolled about half way down the page.
Figure 2: GamePro.com homepage with a docked navigation bar
Comparing the two figures above, you may also notice that the logo is re-positioned from the top left to the right, and it is smaller as well. So the docked navigation bar is a slight variation of the main navigation bar, but consistent enough to be predictable.
Overall, docking navigation bars are a clever use of real estate: instead of the main navigation scrolling away completely, or instead of having a large fixed non-scrolling header area, the docked navigation bar provides ready access to the main areas of the site without intruding on the content too much. And if the docking doesn’t work on a specific browser or device (e.g., it didn’t seem to work on Safari on an iTouch), there’s not much of a disadvantage: the page still works as expected.
I also previously posted about scroll-activated dynamic menus. The docked navigation bar is also scroll-activated and fits in that category. But it’s more static and generally serves a different function than the examples I pointed to in that previous post.
My UX team tried docking navigation bars in the past–perhaps 5 years ago. So it’s not really new. But at that time, it was difficult to get the navigation bar to dock smoothly and consistently on all browsers. Back then, it tended to flicker as you continued to scroll. These days it seems much more feasible and very smooth. On GamePro.com there’s even a subtle animation as the navigation bar docks.
You can find other examples of this on the web, for sure, and I suspect we’ll see more of it as well as variations of docking navigation bars.
I don’t know of any usability studies around this technique, so if you have anything on it let me know. Overall, I personally don’t have an issue with the approach. But it would seem to make more sense with functional options that work together with the page content somehow. For instance, for a web app if you had options to print, copy to clipboard, and the ability to navigation from search term to search term in a docked navigation bar, that would make sense. For a fairly flat, static navigation like on GamePro I’m not sure of it’s real value.
There may be disadvantages with docking navigation bars, as well. For one, it’s an extra cost to program and maintain. But there might also be accessibility issues with it. (Of course, it could also be an advantage for accessibility). If you have insight into the accessibility of docking navigation bars let me know that as well.
Let me know your thoughts on the pros and cons of docking navigation bars.
To learn more about web navigation and IA in general, come to one of my workshops this year. I have two coming up–one in German in Hamburg and one in English in Sydney:
16 February 2011
“Also known as fly-out menus, pull-down menus, or pop-up menus, dynamic menus provide quick access to navigation options. They are considered “dynamic” because visitors must interact with them before they display. After the visitor selects a navigation option with a mouse rollover or click, the site presents a menu window similar to choosing a menu in a software application.”
That’s how I define dynamic menus in Designing Web Navigation. They’re pretty much mainstream these days, and we’ve seen lots of variations, including mega-menus and more.
Recently, I’ve noticed another type of dynamic menu that’s scroll activated. By that I mean that the menus–sometimes just an option or two–appear when the user scrolls to a certain point on page. This is usually at the end of a text towards the bottom of the page.
Below is an example from Harvard Business Review Blogs (Figure 1). See the small box in the lower right corner with the header “More from Scott Anthony.” The menu is animated and slides in from the right side gently.
Figure 1: Scoll-activated menu on Harvard Business Review Blog
This menu option is a related content link to other stories. For news sites, it seems like a good way to lead users to other content. The animation is quite eye catching, but not intrusive or disturbing if done tactfully.
The Economist.com site uses two scroll activated menus (Figure 2). First, there is one at the top that appears fairly quickly as you scroll down–see the red bar across the page. This has some social media options and a helpful search feature.
Unfortunately, when you continue scrolling to the bottom of the page, a large advertisement slides into view from the bottom of the screen. This is intrusive, and it doesn’t bring the user any direct value and tries to steer them towards a subscription.
Figure 2: Scoll-activated menus on Economist.com
I suspect we’ll start seeing more and more of this. Hopefully it won’t get out of control and abused. When done subtly, it can be useful.
Learn about these and other trends, as well as principles of IA and web navigation design, in my upcoming workshops this year:
11 February 2011
Are you in OZ and want to learn about faceted search, strategic alignment diagrams, IA, navigation and more this April? I’m delighted to announce that I’ll be giving 2 workshops in Sydney on April 28-29, 2011!
Here are some highlights:
WORKSHOP 1: Information Architecture for Strategic Web Design
Thursday 28 April 2011, 9:30-17:00 – This workshop focuses on the conceptual and strategic side of information architecture (IA). Topics include: alignment diagrams, mental models, concept maps, Cores and Paths, information structures and facets.
WORKSHOP 2: Web Navigation Design
Friday 29 April 2011, 9:30-17:00 – This workshop focuses on the nuts and bolts of good navigation design. Topics include principles of web navigation, navigation mechanisms, types of navigation, the scent of information, and faceted navigation.
- Earlybird (to April 2): AUD 660
- Regular Price: AUD 759
Beginner to intermediate web designers, interaction designers and IAs; usability experts looking to improve web design skills; and project managers, product mangers, and others seeking to better understand web navigation design.
See the registration details page for more information and to sign up.
Filed in Customer Journeys, Designing Web Navigation, Facets, Information Architecture, Information Experience, Information Interaction, Information Seeking, Navigation, Search, Usability, User-Centered Design, Workshops
Tags: Faceted classification, faceted navigation, Faceted search, Information Architecture, Navigation, Sydney, Usability, Web design, Workshop
17 August 2010
In Chapter 1 of Design Web Navigation, I consider the fundamental need for web navigation. I question:
People don’t particularly want to navigate and risk getting lost. They come to a site to get answers or accomplish a task. As such, web navigation can be considered a means to an end. But is it a necessary evil? If navigating isn’t fun, why impose a burden on people with something that could potentially confuse them?
One fairly obvious reason we need it: navigation provides access to information. (No duh, Kalbach). That’s stating the obvious, for sure, but it’s how you provide access that makes a difference. I then present different models for accessing content. In additional to traditional hierarchical style web navigation schemes, there’s also hypertext content linking, keyword searching, filtering, and something called “liquid information, ” the subject of this post.
He’s how I describe liquid information navigation:
“…there are no links. Instead, each and every word is interactive for all texts. There is no distinction between text and hypertext, or between content and navigation. All texts are links, and all links are texts. … From a single word on a given page any number of navigation actions as possible, leading to new content pages.”
I didn’t invent the term. It comes from the University College of London Interaction Centre (UCLIC), which hosts a research project that can make all online texts interactive—right down to the individual words. See the liquid information project and hyperwords. I describe their model as follows in my book:
Instead of hypertext, the researchers refer to this as “Hyperwords.” The basic idea is that when a word is clicked, a menu of options appears. You could then conduct a search, link to related documents, define the term, translate it, and so on. As they put it, the goal is to put an “end to the tyranny of links.” This would also mean an end to navigation design.
Hyperwords is a browser plugin that gives access to a range of options from any word on the web. The image below is the one I used in Designing Web Navigation (Figure 1).
Figure 1: Example of the Hyperwords menu (from Designing Web Navigation)
I presented this model without judgment in my book, more or less: it’s just another possibility for accessing content. At the time, I actually didn’t think much of Hyperwords. The need to install a plugin, for one, seemed like a barrier to adoption and use in general. It also seemed like there were almost too many options for any highlighted word. In the image above, each of the top-level options also has a range of sub-options, such as which search engine to search.
Recently, however, I’ve been seeing other examples of liquid information navigation on the open web. And they’ve taken a slightly different approach. Below is an example from Read Write Web. Here’s how it works:
Step 1: Select a word or phrase anywhere on the page. “SPARQLZ” is selected shown in the image below (Figure 2).
Figure 2: Steps 1 and 2 using liquid information navigation on RWW
Step 2: When you release the mouse, you get a search option, shown in Figure 2, just above the highlighted term.
Step 3: Click the “Search” option that appears, and wait until the results appear in a dialog, shown below (Figure 3).
Figure 3: Liquid information navigation search results on RWW
The first part of the results list in this dialog comes from the ReadWriteWeb website. Google results also presented after you scroll down a bit. There are also options for videos and images.
I couldn’t find any information about the technology used for the example of liquid information navigation on RWW, so I don’t know if it’s off-the-shelf or home-grown. (If you know, please comment on this post).
Zoomino is the technology used in my next example from the website All About Jazz.One major difference to the RWW example is that Zoomino also recognizes names in a text and presents them as links, inline in the text. Otherwise, the flow of interaction is similar:
Step 1: Select a word or phrase anywhere on the page. (This is not necessary to do for names already linked).
Step 2: When you release the mouse, you get the Zoomino icon right where your cursor is. (This icon doesn’t appear when interacting with a linked name). In the image below I’ve selected Dave Holland’s name in the page title, above the image of him. You can see the “Z” icon above where my mouse stopped.
Figure 4: Steps 1 and 2 on All About Jazz with Zoomino
Step 3: Rollover the icon OR directly roll over a linked name to get an information dialog
Figure 5: The contextual information dialog with Zoomino
It’s not as comprehensive as the RWW example or Hyperwords: with Zoomino, sometimes there isn’t any information for the terms you select. So, in that sense, it’s really not “liquid”–more like Jello, I’d said.
Here’s the marketing text from the Zoomino website describing their service.
Zoomino provides contextual applications that automatically integrate into a web content page. Zoomino enables web publishers and bloggers to effortlessly pair internal and external videos to content pages, add other contextual apps such as articles and keyword summaries, and increase revenues through monetization opportunities.
You’ll notice the advertisements integrated into the dialog in the above image. They seem to take up a heck of a lot of real estate for such a limited space. You could argue it’s more seductable moment for the ads, but I suspect they’ll suffer from banner blindness all the same.
The final example is ClearForest’s Gnosis browser plugin. See a full description on their website. In the image below you can see the underlined terms in the text (Figure 6). These were automatically recognized by the system. Clicking on one yields a small dialog of options, similar to Hyperwords.
Figure 6: ClearForest’s Gnosis entity recognition plugin
Gnosis isn’t really liquid information navigation because only recognized named entities are clickable. Note that the type of entity recognized is also indicated. In Figure 6, the system knows that Swisspatat is an organization. Overall, however, the interaction and style of navigation is similar. So I’ll put it in the liquid information navigation model for now.
In total, we’re seeing some practical examples of liquid information navigation emerge on the web. There are still some improvements that need to happen with the interaction design. For one, it’s not obvious that the feature is even there. (How many of you who read RWW knew about and used the liquid navigation there?). Still, I suspect we’ll see more and more of this type of mechanism.
Will liquid information navigation ever completely replace normal navigation? Is this really a new paradigm for web navigation? No, I don’t think so. But it can supplement other navigation mechanisms and schemes to better support information seeking on websites. We’ll still need “normal” navigation, as well as search and filtering and other mechanisms. It’s not an either-or question at all: in striving to design web navigation that brings value to your customers and to your business, multiple approaches are needed.
By all means, consider adding liquid information navigation to your repertoire. Let me know if you do or if you know of other examples.
28 November 2009
I recently posted about breadcrumb trails. In a nutshell, breadcrumb trails have gotten a bad rap because, as navigation mechanisms, they aren’t really used that much. At least that’s what some studies have shown.
But we’re starting to see a new type of breadcrumb trail emerging, one that integrates with the main navigation of the site. I point to a couple of examples in that post (above).
The main navigation changes with your first selection, so you only get a Home tab plus the option(s) you picked. The home tab then provides access to all the top-level categories via a dynamic menu (fly-out menu). The selected node of the breadcrumb (one level down from the homepage) then has a static horiztonal local navigation beneath it.
The screen above shows how it works three levels down with the fly-out menu for the Home tab open. This provides a pretty extensible navigation scheme and can handle a deep IA. Overall, this provides a great deal of focus on the level and topic your are currently viewing, but also allows quick access to all other topics quickly without cluttering the page.
The only thing I was missing was a dynamic menu for all levels (i.e., for the second node in the above screen shot) so you can get to sub-options there too, not just for the Home tab.
3 September 2009
(via Usability News): Neil Walker has a brief article over at Net Imperative called The Seven Sins of Usability. The number 1 sin:
Inconsistent and confusing site navigation
Effective site navigation is important from the outset of a visitor’s journey so relevant links should be included to take visitors directly to related landing pages from search engines. Marketers need to remember that search is closely linked with the way their site works. Once on a site, visitors do not want to waste time clicking around to find what they want and will leave if they cannot locate the necessary navigation buttons. Do not rely on visitors to use forward and back arrows to navigate their way around as many people prefer to click directly through to the next page so clear signposting is essential for users to find what they are looking for. The key is to have a strong structure that is simple, effective and consistent throughout.
I agree that you shouldn’t rely on the back and forward buttons of the browsers, but I’m not sure about the blanket statement that people “prefer to click directly through to the next page.” Maybe, maybe not. Really, you’re navigation should supporting the optimal movement through your site without relying solely on the back button, but you should also account for the back button in your scheme.
Clear signposts–yes. Strong structure–sure. Consistent, effective navigation–of course. But it’s not that easy to achieve. Designing good navigation remains one of the thorniest parts of web design.
#4 refers to an overuse of industry jargon. This is also something I cover in Designing Web Navigation in Chapter 5, “Labeling Navigation.” Here an excerpt from that chapter:
Speak the Language of the User
The site should speak in terms visitors can understand naturally. It’s easy, however, for site designers to assume that others know the same terms and abbreviations they do. This may not always be the case. There are several aspects of labeling that potentially cause a mismatch in understanding. You should avoid company lingo, technical terminology, clever labels, and abbreviations while using the appropriate tone of voice.
Avoid Company Lingo
Company lingo creeps into web sites all too easily and all too often. Such jargon confuses more than it helps. In rare circumstances, where a brand name has become a household word, for instance, marketing-speak might be acceptable. But if you are inventing new products and words, chances are the “outside world” won’t understand them. And people don’t click on what they don’t understand.
Realistically, however, some products and services have trademarked names. There may even be business requirements to have a term appear in its trademarked form. In these cases, qualifying and enhancing a label with explanatory text would be helpful. Include the jargon if you have to, but explain it for better understanding.
Avoid Technical Terminology
Most visitors to a given site are not as web savvy as those who created it. Not everyone knows what a plug-in is, what a secure server refers to, or even what they can do with a sitemap. If visitors have to choose a bandwidth to view a video clip, will they know how many megabits their Internet connection is? Perhaps not. It’s best to use everyday language for clarity.
Be sure to consider the subject knowledge of your site’s target visitors; technical terminology can be precise and specific to those who do understand it.
For example, internal intranets or B2B sites may assume prerequisite knowledge of the domain, therefore technical terms will not cause problems. Or, a web site for programmers to share and exchange knowledge may require a deep understanding of the subject. On general web sites, however, subject-specific language and technical terminology may confuse, be sure to clarify any uses with simple text as well.
Avoid Clever Labels
Clever, cool, or cute labels are usually self-defeating. It may be more interesting to come up with labels that play on words while designing a site, but it’s not fun for people trying to navigate by them later.
If you feel compelled to use a witty or playful label, be sure to explain it such a way that it is understandable. Provide context or other cues as to what the label should convey. Don’t assume that people will be curious or will explore the category to figure out what a label means.
Both clever labels and abbreviations present particular problems for non-native speakers of the site’s language. Labels that play on words, use slang, or refer to idioms may be completely meaningless to a non-native speaker. Abbreviations may also require prior knowledge that can confuse. If your site has an international reach, be particular careful about the labels you choose in these respects.
Abbreviations save space, but can prevent people from scanning for the right keywords quickly. Some visitors may not even understand certain abbreviations at all. Not everyone knows what FAQ, PDF, or RSS mean, for instance.
If you use abbreviations, be sure that visitors will understand them. Intranets and business-to-business sites may be able to use abbreviations without problem if users are domain experts. But on the open Web, abbreviations can stop people in their tracks.
Even so, there may be situations where common abbreviations are OK. The abbreviation “IRS,” the Internal Revenue Service in the U.S., is so pervasive in America that it would be difficult to find an American visiting the site who doesn’t know what IRS stands for. There is a clear shared reference amongst American taxpayers. Links such as Contact IRS and About IRS are fine in this situation. Even the URL uses the abbreviation: http://www.irs.gov.
Note that screen readers often have a hard time with abbreviations. The vocalization software tries to make words out abbreviations. Abbreviations for U.S. state names, for example, may sound like ahhk for AK (Alaska) or wah for WA (Washington). You can use an abbreviation tag to correlate abbreviations with their full meaning.
Use Appropriate Tone of Voice
Labels on an investment banking site generally have a different tone of voice than those on a teen music site. The one is formal and business-like; the other young and modern. It’s important to understand the appropriate tone a certain target audience expects.
Tone of voice also supports brand. Whether or not slang or popular terms are used, for instance, can reflect the values of the organization. How visitors are addressed is also important. Whether you call personal profile My Stuff or Your Personal Information makes a difference. A mismatch in tone of voice to brand may negatively affect credibility as well.