Why Do We Need Navigation At All?

In Designing Web Navigation, James Kalbach starts out by asking why we need navigation at all. Technically, it’s possible to put all the content on the same page. You can show and hide the content through Javascript or other techniques. Although he doesn’t mention it, technical writers are probably familiar with twisties, or drop-down hotspots. You click the link and a lot of text expands below it. You could essentially do this with your entire help system, putting all the content on one page.

Kalbach points out that Alan Cooper, a long-time usability expert, says websites might be better without any navigation at all. Cooper writes,

The artless web sites created during the Web’s infancy were of necessity built only with simple HTML tags, and were forced to divide up their functionality and content into a maze (a web?) of separate pages. This made a navigation scheme an unavoidable component of any web site design, and of course, a clear, visually arresting navigation scheme was better than an obscure or hidden one. But many web designers have incorrectly deduced from this that users want navigation schemes. Actually, they’d be happy if there were no navigation at all.

…Skilled web developers using modern browsers and site construction tools such as ActiveX and JavaScript can create easier to use single-screen interactions that don’t require jumping around from page to page. Yet many web designers continue to divide, and divide again, their sites into many fractured pages. These hierarchical arrangements of screens force them to impose a navigational burden on their users. (“Navigating isn’t fun,” Cooper Interaction Design Newsletter (October 2001), qtd. in Designing Web Navigation, by James Kalbach, p.5)

The source of Cooper’s quote is from a 2001 newsletter article, “Navigating isn’t fun,” and since I could not find the original source, I assumed Cooper had since changed his mind about navigation. But quickly visit cooper.com and you’ll see that although a navigation menu appears at the top, all the content is on the same page, so by clicking a navigation option, the page content slides around to put new content in view.

Cooper.com homepage

Here’s the same page but zoomed out a bit so you can see all the content on it.

Zoomed out view of the cooper site, showing multiple sections on the same page.

(His site kind of reminds me of Prezi, if you’ve seen that. With Prezi, all your slides are on one canvas and you slide around from one section to another rather than flipping from one slide/screen to another.)

You could conceivably construct help in the same way, putting all the content on a single page. Rather than presenting a table of contents on the left in a sidebar, you could insert all the content on the same page, collapsed in various headings and nested like a Russian doll set, or more artistically sectioned off into various quadrants like Cooper does. Would this make it easier for users to find the content they’re looking for? Does anyone really use a table of contents to navigate anyway?

Here Kalbach presents one of the most convincing arguments in favor of web navigation. The problem with removing navigation is that “people wouldn’t have a sense of beginning or end in their search for information, and orientation would be difficult” (p.6). Without the hierarchy of a table of contents, users would lack a sense of the whole, the beginning to end structure of the content. Kalbach then says, “Navigation provides a narrative for people to follow on the Web. It tells a story–the story of your site. In this respect, there is something both familiar and comforting about web navigation. The widespread, seemingly natural use of navigation to access content on the Web reflects its strength as a narrative device” (p.10).

In other words, your navigation, which presents a hierarchy of information to the reader, gives users clues about the meaning of the content by mere fact of its organization. For example, when you can navigate deeper into the site, you aren’t simply moving to a page, you’re unconsciously comprehending the relationship of one piece of information to another. The deeper you go, the more granular and specific the information, Kalbach says. The organization of the content tells a story that the individual topics don’t reveal alone.

Kalbach says, “In general, navigation offers visitors a semantic peripheral vision of a site’s content. This provides cues for its relevance to your information needs. It reveals what’s available and what’s not, and lets you know you’re exploring the right topic” (p.13).

The table of contents provides the context for information that proves to be invaluable for assessing and understanding what you’re reading. When you can see that one topic is nested below another, or that it’s grouped with another on the same level, this hierarchical relationship provides a context that means something. It’s the semantic peripheral vision, as Kalbach says.

Coming back to Cooper.com, to be fair, he does provide a navigation menu, with two levels of hierarchy. Whether that conveys the semantic understanding of a more traditional web navigation system, I’m not entirely sure. (Mostly to me it seems odd/novel/weird.)

Regardless of how you organize the content, the larger point is this: giving users a table of contents does much more than simply provide users with a means of navigating the content. The table of contents expresses the hierarchical relationships of your content, and by so doing gives users a sense of your content’s overall story and structure. Even if users can’t find the answer to their question by navigating the table of contents, they can find other meaning in browsing and perusing the structure of your content.

In fact, Kalbach says that when people browse the table of contents, they are much more likely to read topics they didn’t initially set out to find. In that sense, the information the navigation communicates motivates the user to learn more.

Adobe RobohelpMadcap Flare

This entry was posted in findability, general on by .

By Tom Johnson

I'm a technical writer working for The 41st Parameter in San Jose, California. I'm primarily interested in topics related to technical writing, such as visual communication (video tutorials, illustrations), findability (organization, information architecture), API documentation (code examples, programming), and web publishing (web platforms, interactivity) -- pretty much everything related to technical writing. If you're trying to keep up to date about the field of technical communication, subscribe to my blog either by RSS or by email. To learn more about me, see my About page. You can also contact me if you have questions.

48 thoughts on “Why Do We Need Navigation At All?

  1. Grace Strother

    As a visually impaired user and web designer, I’m wary of anything involving Active X or Javascript. They’re notoriously inaccessible to people who use screen readers or people with any disability requiring keyboard-only access. Maybe that’s why Cooper has a nav menu at the top of his site. :)

  2. Mark Baker

    Tom, It seems to me that hierarchy and navigation are two quite different concepts. A hierarchy is a way of expressing a single static relationship between pieces of site content. Insofar as this is useful (not very, in my view) it is also useful to provide navigation from the pages mentioned in the hierarchy to the pages themselves.

    But navigation is about the ability to traverse any relationship between pieces of content, and a hierarchy is one of the most limited and artificial expressions of the relationship between topics. Topics are actually related to each other in multiple and diverse ways, based on the the subjects, tasks, and concepts they mention and discuss. The ability to navigate all such relationships is immensely valuable, but it has nothing to do with any artificial hierarchy imposed by the site designer.

    Site organization and site navigation are separate concepts with only an incidental intersection. If we think of site navigation only as a way of implementing a site map, we are missing the point of what hypertext is.

    1. Tom Johnson

      Mark, thanks for sharing your insight. You’re right that hierarchy is just one way that a topic may be related to another. There are a lot of other ways to describe the relationships — such as a relationship by role, location, function, department, etc. A map of topics might be grouped in a lot of different ways, not just in hierarchical arrangements. Hierarchy does play a role in helping us understand the meaning of content, but hierarchy is just one aspect.

      You said hierarchy isn’t very useful. On a related note, I’m curious about your work with taxonomies. Do you typically create a taxonomy for your help content?

      1. Mark Baker

        Tom, I think the idea of creating a taxonomy for a help systems involves a misunderstanding of what a taxonomy is.

        A true taxonomy is an agreed formal naming scheme for real world objects which allows various parties to name things consistently and thus to understand each other better. It works only when all parties involved know the taxonomy.

        A good example of a true taxonomy is found in the formal naming of plants. Every plant species has an official name in the plant taxonomy (generally in Latin) as well as one or (usually) more folk names. The same species may have different folk names in different regions, and different species may have the same folk name in different regions. A species may also have multiple folk names in the same region.

        Botanists name plants using the formal taxonomy when talking to other Botanists, and using the local folk names when talking to everybody else. Using the formal name makes it much easier for other botanists to know what they are talking about, and much harder for ordinary people to know what they are talking about.

        Taxonomies, therefore, define language for expert to expert communication, and are not useful for expert to lay or lay to lay communication. I use them accordingly.

        Another use of taxonomies is to provide unambiguous keys on which queries can be made reliably. In SPFE, we make extensive use of taxonomies to classify topics and references to objects for purposes of topic organization and linking.

        But taxonomies made up solely for the purposes of documentation are not really useful. Taxonomies only work when both parties to a conversation agree on the taxonomy. The right place to find taxonomies is in the real world. In the real world, all sorts of objects have unique reliable names within specific limited domains.

        In SPFE, we use markup to specify the domain within which a set of terms acts as an effective taxonomy. The real key is not inventing taxonomies, but defining the domain within which the ordinary names of things are used consistently enough to function as a taxonomy for all required purposes.

        Inventing a true taxonomy, and having it accepted by all parties to a conversation, is generally an enormous and costly exercise. Making one up by individual fiat is generally pointless, since no one else recognizes the special meanings of the terms you use. Generally you want to find taxonomies, not invent them.

        When people talk about creating taxonomies for their help system, all they really seem to mean is defining a hierarchy for help topics and giving names to the nodes of the hierarchy. That is not really a taxonomy, because the terms assigned don’t have precise unambiguous real-world denotations according to a defined naming scheme.

        Using the word “taxonomy” in this way strikes me as a particularly ironic bit of linguistic inflation, since it uses a term for the precise naming of things in a highly imprecise way.

        Taxonomies are naming schemes for real world objects, not organizational categories for content.

        1. Tom Johnson

          Thanks Mark. I think you are spot on with this comment. Honestly, I’ve been struggling to figure out exactly how to incorporate a taxonomy into help authoring, and from what I can discern from your comment, taxonomies don’t seem all that helpful. The closest practice to taxonomy seems to be dividing and grouping large numbers of information objects according to similarity, arranging them into a structure that reflects their meaning. That grouping exercise isn’t really taxonomy, but if you define taxonomy as classification rather than term identification and agreement, then it seems to be somewhat related. Maybe there’s misunderstanding of taxonomy because the term itself is slippery.

  3. Larry Kunz

    As a site user I like to have navigation when it’s organized according to my information needs. Too often the organization reflects the corporation’s viewpoint and not the customer’s. In those cases, I don’t need to see any navigation. It won’t encourage me to browse and peruse other content. The only reason a “navigation free” page looks odd to me, I think, is its novelty. Not its lack of usability.

    1. Tom Johnson

      Larry, good point about organizing navigation based on the user’s information needs. Can you expand on how you personally do that? Do you do card sorting, create personas, or do other user research to gather this information? Also, how do you respond to the age-old problem that one user’s needs differ from another? An advanced user, a beginning user, a tech savvy but non-initiated user, a non-tech savvy but business sharp user — how do you accommodate all of these different information needs with one navigation menu?

    1. Tom Johnson

      Tarun, thanks for linking to your thoughtful post. You bring up a lot of good points about structuring content. Database-driven queries, scrolling from left to right, paging down, accessing on mobile devices and other touch screens — your analysis is sharp. I think that database driven queries probably would provide for the most flexible, dynamic kind of content display. I can’t see how cooper’s content is pulled from a database, but who knows.

      On another note, what platform are you using for your blog? I noticed it didn’t include comments, and you were able to link the title to another website.

      1. Tom Johnson

        Also, I like the point you make about navigation being a requirement to access each of those sections. You’re right that Cooper doesn’t discard navigation as a means to navigate to content.

  4. Jen

    I find the cooper.com website impossible to use and irritating. I doubt many people would enjoy “exploring” our documentation like that. There are lots of downsides to the way we currently organize our online help, but this solution is the last one I would choose if we had to change our design.

    1. Tom Johnson

      Jen, thanks for commenting. I agree that an organization like cooper’s definitely would not work for help, which often has hundreds of topics.

      1. Jen

        In my opinion, cooper.com does not work for.. anything. It drove me off in under 1 minute due to the clunky navigation. I think sometimes keeping it simple is best…

        1. Mark Baker

          It has long seemed to me that the most celebrated design gurus — Cooper, Nielsen, Horton, et al, largely produce terrible unusable designs.

          This reinforces my belief that great design is not arrived at by the action of great designers, but by a simple Darwinian weeding out of designs that suck, due to the success of well designed products and the failure of poorly designed ones.

          There are certainly many ares in which the best minds, equipped with the best scientific data, perform no better than a psychic octopus: movie, TV, and publishing executives, and stock brokers spring immediately to mind as experts who can’t beat random chance.

          1. Tom Johnson

            I think there’s a principle to describe what you say — about random chance being about the same as a careful, strategic decision. I can’t exactly remember it, though. Mainly, I think people who position themselves as usability experts receive much more scrutiny than those who do not. Also, I know it’s hard to live up to everything one writes about.

    2. Melanie Blank

      Jen – I’m with you on this one. I went to the Cooper site and found it very awkward to use. Too much distracting information in front of me; hard to focus. I don’t like all that scrolling. I have no issue with the page set-up.

      Interesting post and responses, Tom – thanks!

      Melanie

  5. Jonatan Lundin

    As I understand it, the information science research field has for a long time ignored the table of content as a principle to build SUI (search User Interfaces). My interpretation is that navigating in a static arbitrary hierarchical structure is not an effective way of finding information.

    Instead, information scientists are talking about an Intermediary which is a mechanism placed physically between the content and the actual user with the purpose to transform interactively requests for information into query formulations that suit the retrieval components of one or several information retrieval systems. In that sense, we do not need navigation at all (see for example the book Information retrieval interaction by Peter Ingwersen – many statements still apply even though it was some time ago he wrote the book.)

    1. Tom Johnson

      Jonatan, are you referring to search facets that appear as filters to narrow the results when someone searches for a keyword? If not, I’m not really sure what you mean by the mechanism placed physically between the content and the actual user. If you could maybe give me an example, it would probably help.

      Re faceted filtering, I agree that such navigation is a step forward. However, implementing it is a challenge.

      1. Jonatan Lundin

        An intermediary has several purposes. First, we know that humans have problems in expressing an information need. Humans can perceive a lack of knowledge, but they are generally not good at expressing what type of information they need to bridge the knowledge gap. Researchers has initially asked people to vocalize their need (as the keywords they would use, look for or ask for) and then the researchers has in detail investigate the true gap of knowledge (by interviewing the searcher). The results show that the keywords people use do not reflect the real need; most users do simply not know what to search for. That is why it is problematic to navigate in a static hierarchy or formulate keywords to search for.

        An intermediary serves as an agent to help the user in formulating the real need when stuck in product usage. This can be done by a series of questions where the user has a number of options to select from; what is your goal? What type of problems, need or requirements are you trying to solve? In which operating environments are you using the product? etc etc

        An intermediary can be compared to the initial stages in a computer game (for example WII sport). When playing, you traverse through a series of steps where you do a selection in each step: Number of players, Type of game, etc etc. The intermediary has many purposes, finding out the real information need is one.

        Here taxonomies play a central role. I agree with Mark that the table of content is not a taxonomy. But taxonomies can be used when building an intermediary. Remember that users are searching and asking questions. Technical communicators are providing answers. Each answer can be classified from a facet value in various taxonomies. At some point when the user has traversed through the questions in the intermediary, the answers (topics) that match the selections are presented. A faceted search environment is a kind of a light version of an intermediary (?). To me, each collection of facets are a taxonomy (list of controlled vocabulary). I disagree with Mark that taxonomies are only for expert to expert communication.

        I will send a link to an simple mock up intermediary I made based on the SeSAM search situation facet taxonomies.

        1. Mark Baker

          Jonatan, can you suggest a case in which a taxonomy is useful for expert to lay communication? I assume you are not suggesting that a flower shop should start advertising “Dianthus caryophyllus 9.99 a dozen”?

          It is a long standing general principle of technical communication, and indeed communication generally, that you should speak to the reader in their own language. Under what circumstances are you suggesting we should violate this principle?

          1. Jonatan Lundin

            I do not mean that the prime purpose of a taxonomy is expert to lay communication.

            Humans agree on names (as an arbitrary convention) on things, artifacts, entities souruonding us in a social context. Often this is an exercise of so called experts, but I argue that anyone can create a taxonomy (even laymen or technical communicators!). So the definition of a taxonomy is not that it must contain expert vocabulary used in expert to expert communication. The fact that we as humans put labels on things and categorise things for the purpose of recognition and identification, is fundameental to human communication. As a fact, there are many types of taxonomy schemes, folk, scientific, economic taxonomies etc.

            Technical communicators are creating taxonomies, identifying for example, user goals, tasks, product components etc etc. These taxonomies must then of course be created using the vocabulary of the intended users (tasks are not named in latin). Taxonomies are and should be used to for example help users find information. The facets in a taxonomy then appears in a SUI.

          2. Mark Baker

            Jonatan,

            You say,

            “anyone can create a taxonomy (even laymen or technical communicators!)”

            and

            “The fact that we as humans put labels on things and categorise things for the purpose of recognition and identification, is fundameental to human communication.”

            Lewis Carroll wrote:

            “When I use a word,” Humpty Dumpty said, in rather a scornful tone, “it means just what I choose it to mean—neither more nor less.”
            “The question is,” said Alice, “whether you can make words mean so many different things.”
            “The question is,” said Humpty Dumpty, “which is to be master that’s all.”

            One of the categories on my blog is “Writer vs Reader”, and I return frequently to the theme of the writer attempting to be the master of the reader. True, anyone can make a list of words and call it a taxonomy, can declare, with Humpty Dumpty, that words mean what they choose them to mean, neither more nor less.

            The reader, alas, like Alice, may be “too much puzzled to say anything”.

            Language is an agreement about the denotation of signs. One person cannot make up language. Signs only become language when others agree to recognize the denotation. A taxonomy, therefore, is an agreement about the meanings of words. You can’t make one up by yourself; you must have agreement from the community with whom you communicate, or it is not a taxonomy in any useful sense.

            But taxonomy, properly, means something more specific than an agreement to let a particular sign denote a particular thing (that is simply language). It is a further agreement that a particular sign shall denote one thing and one thing only, and that a particular thing shall be denoted by one sign and one sign only.

            For certain classes of discourse, a true taxonomy is enormously valuable — it banished ambiguity. It is also valuable for many kinds of information processing, including the automated creation, organization, and discovery of content. This is why I think it is a serious issue that people are confusing the role of taxonomy in information development by using it in the Humpty Dumpty sense.

            A so called “folk taxonomy” is the exact opposite of this: a collection of all the different signs that people have used to denote an object, and all the objects that a particular sign has been used to denote. This is precisely why in botany we recognize both the taxonomic names for plants and their folk names.

            For someone seeking to understand how people might search for content on a subject for which they provide information, understanding the folk names for things is valuable, as it allows them to tag their content appropriately (or inappropriately, as is too often the case).

            But using your own made up “taxonomy” that no one else uses or recognizes is no way to organize content or to design the navigation of a website. It is an attempt to master the complexity of content and language by a personal fiat that only leaves the reader, with Alice, “too much puzzled to say anything”.

          3. Jonatan Lundin

            Mark, I do believe we agree on what a taxonomy is. A certain social community having a shared interest in clarifying the view on the world – as all botanist in the world or all SME and technical communicators in a company – may have a need to agree on names for things beyond what is provided in a certain language to decrease ambiguity. So the creation of a taxonomy is intentional, starts off from a need to unify and clarify how things are denoted, requires a lot of effort, must occur and be agreed upon in a social community. There is no point in developing a taxonomy on your own and not communicating it to others.

            But, the definition of what is a taxonomy is sometimes blurred. Is the terminology punk rockers are using to denote things in their context a taxonomy? Well some say it is a folk taxonomy (I’m not sure it is a taxonomy). Then I guess you agree that a taxonomy is not restricted to only expert to expert communication and that participants in any social community can take on the work to create a taxonomy (not only expert communities). I argue that anyone can start the work to develop a taxonomy given that the taxonomy is communicated and agreed upon in a certain social community consisting of at least two humans. All employees including technical communicator in a company developing a product can agree to create a taxonomy about for example the components their product is built up from.

            You say that “A taxonomy, therefore, is an agreement about the meanings of words.” And “It is a further agreement that a particular sign shall denote one thing and one thing only, and that a particular thing shall be denoted by one sign and one sign only.” But the work of creating a taxonomy is much greater than just agreeing that a particular sign shall denote one thing and one thing only in a social community. When doing a taxonomy, you are categorizing, classifying and organizing certain things, entities, artifacts (or whatever) according to a certain schema. Each group of things (a taxa) is given a label which is defined in your taxonomy. ‘All living things in the world are divided into two groups: one called “animals” and one called “plants”’ – or are you dividing all living things into three, four or more groups? Thus you are exposing your view on the world, establishing relationships between categorized things etc.

            Another interesting issue is the difference between a taxonomy and facets. In a faceted classification approach you develop different facets for your things, entities, artifacts (subjects). If you consider the work of S. R. Ranganathan and others, a facet is not a taxonomy in a strict sense. Consider the facets (http://orange.sims.berkeley.edu/cgi-bin/flamenco.cgi/nobel/Flamenco) for Nobel Prize winners in the flamenco faceted search browser: can the different facets be considered taxonomies? I have heard some people say that facets are taxonomies. Or that a facet can be built upon existing taxonomies.

            Yet another interesting issue is how taxonomies (or facets if you equal the two) can be used to build SUI (Search User Interfaces). Some argue that taxonomies shall not be exposed in the front end view in a SUI. The navigation, sitemap etc shall allow the user to find information. But in a faceted search environment, the facets (or taxonomies?) are the fundamental part of the SUI.

            I have been arguing for the last couple of years that taxonomies (or facets) play an important role for technical communicators and for end users. Not in a sense where you write *something* and then start to classify and organize written content to come up with a taxonomy. The SeSAM approach to user documentation means that your company start to develop different taxonomies (facets – I call then search situation facet taxonomies) before any technical communicator writes anything. The facet taxonomies are then communicated and agreed upon within the organization developing a technical product. The topics to write, where each topic answers a predicted user question, are then derived from the taxonomies in what is called the MRS matrix. The facets can be seen as the “grid” from which the topics you need to write are identified. This is a “reversed taxonomical approach”.

            Let’s say your company can agree on a set of search situation facet taxonomies for a specific product and that content topics can be written and classified accordingly. What about the user? The user is not part of developing the taxonomies and this is a problem. If we where to develop a taxonomy in a strict scientific sense, also the user would need to be part of the development and agree on the taxonomy (very difficult to achieve).

            So there is a consequence of developing taxonomies. Any social community that develops a taxonomy must probably at some point communicate and explain the taxonomy to others not part of the original community that once developed the taxonomy. If I were a botanist, I would need to learn the Carl von Linne taxonomy scheme. I was not part of developing it and I do not understand it just by looking at it.

            If you use the facet taxonomies in a user manual SUI, then the user must somehow get to understand the facets when searching. Here, the intermediary plays an important role. The intermediary must include a possibility to explain the facets to allow the user to learn and understand them, even though the primary target of users in not to learn the ranks and taxons in a taxonomy.

          4. Mark Baker

            “If you use the facet taxonomies in a user manual SUI, then the user must somehow get to understand the facets when searching.”

            And this is something the vast majority of users have absolutely no interest in doing. If I have to learn your organizational scheme before I can navigate your content — well, I’m just not going to, that’s all. I will either Google for the information using my own terms, or I will go somewhere else.

            This is why I don’t believe made-up taxonomies are of much use for navigating help systems. They impose author’s order; not reader’s order. In the age of the web, the power to organize content has passed from the writer to the reader. Our task is not to impose order but to facilitate ordering at the fiat of the user.

            As I said to Tom, you should seek to discover taxonomies and classification schemes rather than creating them. Here is great example of this at work: http://autocatch.com. This site allows used car buyers to create and organize a list of used cars pretty much anyway they want using categories drawn from the real world with which the user will already be thoroughly familiar. Taxonomy discovered, not made.

  6. Michael Shmilov

    I think it is much less important whether the content is on the same page or not.

    The chosen layout of your UI affects how users navigate your app and the main question should be how to organize the content in the chosen layout so that users can navigate easily and intuitively.

    I really like the ‘no menus’ navigation solutions in the Metro UI (Win 8).

    1. Tom Johnson

      Michael, I’ll be interested to see how Win 8′s UI is received. My colleague played around with that briefly last week and noted how different it is. He said most people will probably hate it. Can you share more about why you like it? Why is a menu-less navigation better?

      1. Michael Shmilov

        I would not necessarily say that it is better.

        With Metro UI Microsoft made a statement – “Content not Chrome” – putting the focus on the content is the key and they went all the way with that. The idea is to limit the number of controls on screen (such as tabs) and let people focus on the content.

        They guide and provide a hierarchical system and few advanced features to make it easier to navigate. e.g. consistent ‘back’ button, the App bar, semantic zoom and etc.

        It does works, but it has disadvantages; users are used to clear menus and as you mentioned in the article; “adding a table of contents does much more and users are much more likely to read topics they didn’t initially set out to find.”

        This is a great resource: “Navigation design for Metro style apps”
        http://msdn.microsoft.com/en-us/library/windows/apps/hh761500.aspx

        Thanks for the great post and reply. Michael

        1. Tom Johnson

          Interesting. I always want to champion content, but not at the cost of hiding or discarding clear navigational controls to move around the content. I’ll check out the reference link you included. Thanks.

  7. Alessandro Piana Bianco

    Cooper’s a good (with room for improvement) example of what looks to be the next trend in UIs, ZUI (Zoomable User Interfaces).

    ZUIs with responsiveness and (semantic) text only (aural CSS full compliant for use with screen readers but also SIRI-like devices) are an exciting new direction in web design (in the broader sense of the term).

    May I suggest the interesting: “Prophets of zoom” > http://www.economist.com/node/21556097

    1. Tom Johnson

      Alessandro, thank you for giving me some vocabulary to talk about this type of interface. I had no idea there was already a term name for it, Zoomable User Interfaces. Thanks for the article link as well.

  8. James Kalbach

    Hi Thomas,

    thanks for the careful review of my thoughts on navigation from my book. It’s good to know people are actually reading the text in such detail!

    It seems Cooper changed the URL structure of their site since my book published. I was able to dig up the original text here: http://www.cooper.com/journal/2008/05/navigating_isnt_fun.html/

    Cooper himself is an interaction designer, so his perspective is no surprise. And I do agree with his conclusion: “If you want to design simpler, better Websites for business or commerce, try putting more interaction into fewer screens so your users don’t have to navigate so much.” (In fact, I’m involved in a working on the interaction between texts and users. See: http://fitlab.eu/euroHCIR2012/)

    Navigating isn’t fun, indeed, particularly when there’s tens or even hundreds of thousands of pages in a site. But these are the types of problems information architects are confronted with in the real world. It’s not always practical or desirable to have “fewer screens with more interaction.” So we have navigation. And rather than avoid it, we should understand its role and its positive sides, like the points you make above.

    Nielsen has successfully avoided a main navigation of any kind for about 17 years now: http://www.useit.com/. But to be honest, I often have problems findings things on his site!

    Cheers,
    Jim

    1. Tom Johnson

      James, thanks for the comment. I always appreciate it when authors follow-up and interact with others discussing their work. I appreciate your clarification that Cooper’s conclusion is “try putting more interaction into fewer screens so your users don’t have to navigate so much.”

      I’m wondering if you could comment more directly on the help situation. Take a look at a sample help file here. Are you saying that it would be better to compress the information into fewer topics (using show/hide techniques that would collapse/expand the content) rather than providing so much navigation on the left in a table of contents?

      By the way, I’m finding your book much better written than Peter Morville’s books. You are simply more insightful.

      1. Andrew

        To an extent fewer topic areas would help. Troubleshooting and FAQ is a category that annoys me, the information can normally be directly next to the topic area it relates, error messages should be received in the context of an action, the error message should be descriptive of the nature of the problem and offer advise on achieving a solution.

        A FAQ should not exist, the application should be altered to avoid frequent questions and it will normally be better to offer minor in line assistance to avoid the need for any form of FAQ.

        The biggest improvement to the Help would be an improved search facility, and I believe a chunk of the text could be removed by offering a more “wizard” style approach to topics such as Initial setup.

        The popup “See also” feels like a waste, I would prefer the related item links to appear as a sub heading rather than a popup menu, it also has a minor technical flaw in that the options can appear off the screen which I have seen can confuse users.

  9. Rachael Sarah Williams

    Great post, Tom, and great comments from readers! Giving me lots to consider.

    Navigation is something most people don’t think about until they can’t find the info they need on a website. Cooper’s system would drive me bonkers very quickly. I love how Kalbach explains web nav as the narrative behind a web page. That’s an excellent metaphor to explain why navigation is crucial. Designing Web Navigation has been on my wish list for about a year. Having read the excerpt along with your post, I think it’s time I moved it to the Buy List.

    I also agree with Kalbach’s comment above re: Jakob Nielsen’s UseIt website. Love Nielsen’s work, but his site frustrates me to no end. The colors are awful and jarring to the eyes; I too have trouble finding the articles I need. One of my tech comm professors told me that Nielsen’s rationale for the 1995 Netscape refugee look is to make it accessible for any browser or device. All right, I guess I could understand that. Still, it’s ironic that a well-known usability expert’s website borders on unusable.

    1. Tom Johnson

      Thanks, Rachel. I haven’t finished Kalbach’s book yet, but what I’ve read so far I like. I agree about the usability of Nielsen’s site. I think people who position themselves as usability experts have a high standard to live up to. On a similar note, I know each of Grammar Girl’s articles is highly scrutinized for correctness. As a result, her writing seems a bit stiff and self-conscious to me.

  10. Aliya

    Uber-relevant justification of the need of hierarchical navigation.

    The use of ActiveX controls and stuff like that doesn’t only require more from the writer/developer in terms of effort and imagination but is also a little less adaptable for few users (like those accessing your content from the handheld devices).

    Really liked the post Johnson. And quite agree with Kalback’s views.

    1. Tom Johnson

      Aliya, thanks for the note about the impact on accessibility when using these javascript and activex controls. I think you’re dead on there.

  11. Vinish Garg

    Tom, excellent insights on navigation in the post as well as in readers’ comments.

    There are different aspects to it. As a user if I am looking for White Papers on the site, the menu dedicated to White Papers makes it easy for me to click directly on that link. No looking around on stuff where I don’t need to. On the contrary as a webmaster, I might want that the users who are looking for White Papers should look around for a few moments and they may be interested in services also.

    Consider a real-life scenario.

    A library of books has multiple racks of books for different categories to help students find books of their interest. This is to ensure that a literature student may not get miffed up to see many piles of Chemistry or Botany books before finding Literature books. So even if the library is meant for student of all departments, the objective is to help students find books of their interest easily.

    On the contrary, a bookstore manager may be interested to sell as many books as possible to all customers. A traditional bookstore so organizes the books that the customer who is interested in literature books gets a chance to see books in other categories as well.

    So it all boils down to how we orient users’ needs.

  12. Jen

    It still seems to me that site organization and site navigation are intrinsically linked in spite of the commentary above to the contrary. Because they are intertwined together in the implementation of a site design, they are both extremely subjective and a great insight into the site owner’s priorities. We as users can undoubtedly create our own pathway through the materials presented, but, initially, a website is usually organized and structured so that a user can navigate their way through an information hierarchy easily and intuitively.

    Also, I believe that many websites designed by great designers are those that demonstrate the concept of a separation between organization and navigation. The designer organizes their information in a means generally unaffiliated with any navigation in mind to communicate information in context or an easily navigable path. They often consider content first and navigation as an after thought. We can see this because users are confused by these designer websites. But visual design is also a language all it’s own that takes some education to understand.

  13. Pingback: Navigation is meaningful « rastplatznotizen.

  14. KarlM

    For small sites, perhaps. But mainly this article is nonsense.

    Imagine Wikipedia all on one page, with javascript. Register? This blog?

    My ancient little Blackberry would die on me. In fact, classification of data is how we take it in. Why not call all mammals “mammal”? For the same reason. Everything requires clear definition or we don’t take it in.

    People need menus, clear choice, and intelligently divided information. I wouldn’t wander into a restaurant kitchen, look in cupboards and ask “what you got?” Same with the web, and anything!

  15. Ben

    I’m surprised that only the last comment on here is the first to mention mobile usability. What about bandwidth and load time? On a high traffic site you’re forcing each user to download your entire site, whether or not the content is relevant. All that bandwidth usage adds up and could potentially increase operating costs.

    For mobile devices, you’re impairing the ability to render the page quickly on browsers that are already slow to begin with.

    I think this, along with everything else, is a good idea but has to be applied in moderation and to situations that make sense. Small, low bandwidth sites are perfect for single page architecture. But something like Wikipedia obviously would never work.

    In terms of a help system, what about breaking the help topics up and making them contextually: putting them on individual pages but only the topics that are relevant to that page. If the goal is to reduce navigation elements then sticking help topics where they’re needed (and toggling their visibility with JavaScript) would make finding that help easier as well as simplify the site structure yet retain a traditional navigation tree for core sections of the site.

  16. Jason Zhang

    The fact that it takes usability gurus years to work out a concept and years more for engineers to realize it seems to indicate that the not-so-obvious idea can often translate into a not-so-obvious, anti-primitive design.

    Whatever I design for a navigational (though not necessarily hierarchical) mechanism, there will always be someone who complains. It is well and easy to conclude the site is fine if the client likes it. However, the complaints may very well have come from someone with a very different mind or (I’m sorry to say) much less brain capacity than the designer. A mildly sophisticated tool according to the designer can equally be a massively unusable obstruction for someone else.

    That said, notwithstanding Cooper’s particular interpretation, “Navigating isn’t fun” is a valid principle. The design strategy is to use it as a PRINCIPLE, not to affix specific definitions for navigation (read: hierarchy) and fun (read: fancy widgets) and then substitute a hierarchical menu with the designer’s favorite toy.

    From a technical perspective, Cooper presents the other extreme across from a basic, strictly hierarchical site. The point is to find several middle points to blend so that you are reaching your highest-value audience groups.

  17. Teiosanu George

    Reasons we need navigation, due to curent tech limitations and standards:

    1.Website load speed
    Why in god’s name would anyone want to load your entire site?

    2.SEO-oriented websites (all should be accesible and indexable but…)
    Try optimizing a one page website for thousands of keywords…

    3.Usability
    Even if you load the WHOLE website in the page you still need some sort of navigation. The fact that it is in-page navigation is ironic. You still would have navigation.

    I’m sorry to be so cynical, but with the state of technology and design these days the “clasic” navigation is bound to be a standard for quite a few decades.

  18. Pingback: A New Way to Navigate Web Pages (Maybe) - DesignNewz

Comments are closed.