Proposed drawing conventions for depicting a web site for designers, developers, and clients.
When working with web sites, I have often found it difficult to visualize the overall structure of the site, whether to further my own understanding or to communicate it to others. A basic node-link map is a great start, but if you intend to show every direct navigation pathway between every page, then with sites of even moderate complexity, the node-link map quickly becomes a confusing plate of linguine with clams.
So I’ve developed some diagramming conventions to better illustrate the possible navigation paths among content in a site. I call the resulting diagram of the navigation structure a “Navigation Structure Diagram,” or NSD. It’s not a very imaginative name. Sort of like TTA, the transit authority in Huntington WV. “TTA” stands for “The Transit Authority.” I expect “NSD” won’t be confused with a Nassi-Shneiderman Diagram, because, well, I don’t think anyone uses Nassi-Shneiderman Diagrams.
My goals in developing NSD conventions were to have diagrams that are:
- Consistent with current knowledge and experience, namely, node-link maps. I’d like an untutored audience to at least be able to get the gist of the navigation structure by looking at the diagram.
- Easy to learn, having only few powerful symbols. The easier it is to learn, the more it can be used with more designers. If I can keep basic training to a minute here or there as needed, it could even be used for clients.
- Sketch-friendly with no dependence on color or complex hard-to-hand-draw symbology. I want something you can scribble on a whiteboard or napkin quickly to facilitate consideration of different structure designs during the design process.
- Computer-friendly, using a few basic symbols that can be copied and modified repeatedly, such as in MS Visio or CorelDraw.
- Scalable, able to show both simple and complex sites, and able to show structures at varying levels of abstraction, from a quick overview early in design to a full specification. When represented in software, it ideally would allow “drill down” to greater details, as may be possible with Visio.
- Able to highlight problems in the structure, making missing or unnecessary pathways easy to find. If you know the task, looking at the diagram should make it easy to count the number of clicks to complete the task and get the needed information. An internally consistent and symmetrical navigation structure should look consistent and symmetrical. An ugly bag hung on the side should look ugly.
NSDs in Five Easy Lessons
Lesson 1: Links
Content units, typically pages, are represented in an NSD by text labels and links are represented by lines between them.
|Lines are drawn between content unit names to indicate that pages link to each other||Page A has a link to Page B and Page B has a link to Page A.|
|An arrow head is used to indicate a one-way link||Page A has a link to Page B, but Page B does not have a link to Page A.|
|Optionally, the link name or label is written above or to the right of the link. By default, it’s taken from the content unit names||Clicking the “Next” link takes the user from Page A to Page B.|
Lesson 2: Collections
A bracket around page names denotes a collection of pages which all receive the same treatment in the NSD.
|Links and other symbols attached to the bracket apply to each content unit in the collection.||Page B, C, and D, are all linked with Page A.|
|All content unit names that overlap with the area enclosed by a bracket are part of the same collection.||A, B and E each link to A, B, C, and D, but C and D do not link to A, B, or E, and A and B do not link to E.|
Lesson 3: Multiples
A solid box indicates there are more than one of whatever it encloses.
|A box around a content unit means there’re multiple content units.||There’s a separate page for each Chapter.|
|A box around a piece of structure means that there are multiple instances of that piece of structure.||Each Chapter links with its own respective Questions page.|
|Links and other symbols attached to the box apply to each instance in the multiple.||The Contents page links with each Chapter.|
|A dashed line implies a link to or from a subset of the multiple.||
|Some of the chapters have a link to the tutorial.|
You should avoid the subset symbol if at all possible since it is open to multiple interpretations.
Lesson 4: Standard Substructures
Common types of substructures or relations among pages have their own symbols.
|A linear substructure, such as a guided tour, is shown with an arrowhead on the collection or multiple.||Chapter 1 links to Chapter 2, which links to Chapter 3.|
|The arrowhead indicates the direction the user navigates the pages. Two arrowheads are needed if the user can go both forward and backwards||Chapter 1 links to 2, 2 links to 1 and 3, 3 links with 2.|
|A matrix (or “grid”) substructure is shown with arrowheads on two sides, indicating linearity on two dimensions.||The user can go up and down and sideways among map quads.|
|A ring substructure is shown the same way as a linear substructure, only using circles rather than arrowheads||Chapter 1 links to 2, which links to 3, which links back to 1.|
|An interconnected substructure is indicated with an “X”||Every chapter links to other chapters.|
|An isolated arrowhead means universal linking –all content units in the diagram link to the indicated content unit, collection, or multiple.||Every page has a link to Home, Contents, and Search.|
Lesson 5: Types of Links
Unless indicated otherwise, a link replaces the content currently shown in the browser window with the content indicated. Furthermore, the content is determined by the tags of the anchor (i.e., href for ordinary links), not by other input by the user.
|Content units shown together in the same page or window are surrounded by parentheses. Such linking may be implemented through “#” anchor links or loading content to part of a page.||Links in FAQ List show FAQ 1, 2, and 3 all in the same page as the FAQ List.|
|Separate parentheses around each content unit indicate they are shown mutually exclusively.||Links in Photo List replace Photo 1 with 2 and vice versa.|
|Content units shown in separate windows are surrounded by braces. This may be separate browser windows or include the window of another app.||Link in Contact Us page opens Email Compose window|
|Like parentheses, separate braces indicate mutually exclusive content.||Links in Photo List replace Photo 1 with 2 and vice versa.|
|Parameterized navigation (e.g., search and queries) is represented by writing the parameters or contingencies under or left of the link.||User provides search string to go to Search Results Page.|
Bonus: More on Parentheses and Braces
Rationale for Use
It may seem odd that content units in the same page are enclosed in parentheses and content units in different windows are enclosed in braces, while content shown on different pages in the same window are enclosed in nothing. One might expect content shown in different windows to appear “more separate” than content in the same window. Partly I use these conventions so the most common situation (content in same window on different pages) is default to minimize clutter.
More significantly, I want the diagram to represent the user’s navigation experience, not the technical underpinnings. When two content units are shown on the same page, the user can in principle (given a possibly theoretical monitor of adequate size) see both units at the same time. That’s what the parentheses represent: whatever is inside can be seen without navigation (scrolling doesn’t count as navigation).
The same is true for two content units shown in different windows. With an adequately sized monitor the user can see simultaneously whatever is together in braces, the user can access both without navigation (I don’t count window management as navigation either). From the user’s perspective, showing two separate things in two separate windows is more like showing two separate things on the same page than two separate things on two separate pages. I use braces for content in separate windows rather than parentheses because they’re harder for me to draw than parentheses, and I don’t see separate windows used much anymore.
Do Not Separate Navigation Controls from Content
Generally, a content unit is a page within a site. However, the parentheses convention makes it possible to break content into units smaller than a page. To keep the NSD as focused on its purpose as much as possible, you only want to do this to the degree it helps show possible navigation paths to content. By “content,” I mean in this context the actual stuff intended to fulfill the users’ goals (usually the information they seek), not the stuff used to navigate to other stuff (generally, the links and other controls used for navigation).
There’s nothing wrong with the same content being part of two different contents units, so don’t break up pages into unique pieces of text and pictures and then try to glue it back together with parentheses. For example, the NSD for this web site (at least as of this posting date) looks like this, at a relatively abstract level.
The content units in the downward-pointing bracket are pages with the side bar links. Content units in the right-pointing bracket are pages that the side bar links take you to. As shown in the NSD above, the same posts are considered to be different content units, one set for the general archive (”All Posts”) and one for the categories (”Posts in Category”). All Posts are linked in a linear substructure (ordered by date). Within each category, posts are again linked in a linear substructure ordered by date but only including posts of the same category. The content may the same, but the available navigation paths are different: the sidebar and its links (About, FAQ, etc.) are present for Posts in Category but not All Posts. Thus, All Posts is shown as separate content units from Post by Category, the better to show possible navigation paths.
I think it’s actually helpful to have the NSD show content redundantly as two alternative sets of content units. It allows designers to appraise the navigation structure’s compatibility with alternative user tasks (one substructure for reading chronologically, another for reading by category). It can also point out potential usability problems. In this case, users might get confused if they are in category archive but think they’re in the general archive. Unless the location is made clear, some users may wonder why they can’t get to very many posts.
It’s difficult to even diagram this site where every piece of content appears in exactly one content unit. It would mean having the posts as one set of content units, alterative combinations of available links as another set of content units, and members of these sets sharing the same page (as indicated by parentheses). Assembling pages from pieces of content of course is exactly how the site software Wordpress uses its database for this site, but an NSD is supposed to represent the experience of the navigating user, not the implementation details. For a user trying to navigate, different links make for a different “place” even if the other content is the same as found elsewhere.
It is important elsewhere to avoid implementation details from sneaking into an NSD. For example, suppose you have five pages of content and a menu of five links to navigate to them. Suppose further that you implement a left-side frame for a menu and a right frame for the content pages. I would not represent that as a Menu content unit which links to 5 page contents (enclosed in parentheses since they’re all in the same window). I would instead show it as 5 interconnected pages, as if each page had the (same) menu on it. From the user’s perspective of navigation, it’s the same thing.
The same applies to tabs: consider each content unit to have its own set of identical tabs. For dropdown menus, do not represent the appearance of the menu as navigation to new content. Treat it as part of the content already on the page.
And a Couple More Conventions
Annotations can be very helpful to cover anything about the navigation structure not represented in the diagram, or to “override” of strict interpretation of the diagram. For example, you may need to say that a page of search results only links to the matching subset of all pages. Annotation can also be used to note the sort order of a linear substructure or to note what is shown by default for mutually exclusive content for a given page. However such details are extra to showing navigation paths, so I’d minimize them, maybe just including footnotes or references to other documents. Annotations are distinguished from content units by delimiting with “comment” characters, either “//…” or “/*…*/.”
Underlining a content unit means “more linking from here not shown.” This is useful if the content unit represents a different web site (and you don’t want to show its navigation structure) or to refer the reader to a separate document for more navigation structure that won’t fit in the current document.
Getting Rich Quick
I made up NSDs in 2002 when web sites were mostly large sets of linked pages of static content. It was not really intended for database apps with web fronts ends or the new rich apps using AJAX or FLEX that are rapidly becoming common. For example, parentheses work fine in traditional websites where it was rare to link within a page. I wonder whether or not the parentheses convention would work as web apps gets more complex with large numbers of potential content units sharing a page, perhaps with complicated dependencies.
When used to depict a traditional web site, an NSD pretty much shows all the user can do, which is just navigate. That isn’t true as we move into rich apps, as users are given much greater interactive abilities, able to make commands that alter the content or underlying data objects (e.g., by posting new content). That’s just something an NSD doesn’t do. Use some other form of documentation to list available commands or show the processing a user can do. Maybe a flow diagram. Or a Nassi-Shneiderman Diagram. No wait, not that.
The purpose of an NSD is to show the possible paths through content the user may take. While I expect developers to refer to an NSD, it does not provide a complete spec for each page. For example, it may not be immediately apparent that a line between pages implies, if there’s no arrow head, at least two anchor elements, one on each page (use of the browser’s Back button does not count). Furthermore, the link in the diagram does not indicate how the content is linked; it may be by anchor element, command button, dropdown list, or by sending out a Labrador retriever. Also, Page A may have more than one link to Page B (e.g., one through graphics and one by text for accessibility reasons), but only one line is drawn. It’s even possible, through parameterized links, to have two lines drawn from one page to two different ones, but have these links implemented with a single control on the first page (e.g., a query which takes the user directly to the specified content if there’s an exact match, but takes the user to a Search Results page if there’s only approximate matches).
Don’t bother to show links on a page that go to that same page even if they exist. It adds clutter to the diagram, making it harder to visualize paths through content. Also don’t worry about real or implied self linking indicated in the NSD. For example, drawing [A B]-[B C] implies B links to self (as well as to A and C). Well, in actual implementation B may or may not have a link to itself. These things are not represented one way or the other in an NSD.
There is a difference between drawing a link to the bracket of a collection and to a content unit in the collection
The first implies the Intro links to all three chapters, while the latter implies the Intro only links to Chapter 1. If you can, avoid crossing a bracket to prevent such confusion.
A similar distinction applies to multiples. Drawing a line to a multiple indicates all content units within are linked, as shown in the first row of the table below: the Intro links to all chapters and question sets. If you want to show the Intro just linking to the chapters, draw it like the bottom row.
Standard substructure symbols also need to be drawn in proper relation to the content units that apply. For example, in the following, users can navigate linearly through all posts in a category, but not among categories.
If users could navigate linearly through all posts across all categories, it would look like this:
There’s a similar distinction between placing parentheses inside multiple versus outside. Inside implies the content in the multiples are mutually exclusive. Outside implies they can all be shown together. If that seems confusing, try to interpret multiples by mentally expanding them into a collection
The Art of NSDs
Finally, some tips to help make diagrams more understandable.
- Avoid crossing lines when drawing links.
- Align content units in neat blocks
- Group related pages together.
- Break complex sites into separate diagrams at structurally significant points.
- Use spatial position to suggest structure and task flow.
- Place Home in the upper left and main section pages down along the left margin to indicate the first level of the hierarchy.
- Use indenting to the right to imply deeper hierarchies
- Arrange content units so paths for the most common tasks into site go from top to bottom and left to right
- Use looping arrows to the left and up for secondary paths.
- Place content with few links off to the side.
- Otherwise use spatial proximity to suggest groupings and order on the page. For example show content that shares a page close to each other (this also makes it easy to pair parentheses). Show main content in the same order as it appears in the menu. Indicating spatial arrangement is not what an NSD is intended for, but chances are if your viewers see the Contact Us content unit at the end of collection, they’ll probably assume it’s the last item on the menu anyway.
- While NSDs are designed to work with monochrome reproduction tools, if you are using a graphics package, exploit its abilities. You can use:
- Font size and weight to suggest the hierarchy, with larger font for higher sections in the hierarchy.
- Line weight or shade to suggest the importance of links, collections, or multiples.
- Color to help distinguish links, collections, and multiples in a particularly dense NSD. Alternately, you can use color to indicate tasks that certain content and links support.
- Background shade to distinguish content units in tightly pack diagram
One of my goals is to make potential usability problems more evident by the geometry in the diagram. While a neat diagram doesn’t necessarily mean an optimal navigation structure, inconsistent structures, where, for example, the main menu appears on arbitrary pages, tend to make ugly complicated NSDs, mirroring the confusion a user may experience. This is illustrated in the NSD for this site. It would be simpler if the sidebar were either on every page:
Or only on the home page:
Simpler, consistent navigation structures tend to make for simpler NSDs.
Problem: Visually presenting navigation structures in a concise, easy-to-make, readable, and scalable, and in a manner that highlights possible navigation problems.
Potential Solution: Use Navigation Structure Diagrams, which make more compact presentations than ordinary node-link maps because of the addition of
- One-way and two-way links
- Special symbols for standard substructures, including:
Use bars through links to indicate separate window
Here’s a bonus to the bonus. Did you find the use of braces confusing? I did, and I invented that use. Since I’ve posted this article, I’ve abandoned the braces and now use a crossbar through the link to indicate spawning a new window. Here, for example, is how you can show a pdf that opens in its own window.
All content units with links that share a crossbar open their content in a shared window. For example, in this case:
The content for Sys A and Sys B appear in separate windows when the user selects the Sys A and Sys B links respectively on the Dash page. On the other hand:
The display of Sys B content replaces Sys A content in the “Sys” window when the user selects the Sys B link on the Dash page.
For collections, use a double crossbar to mean each page opens in it’s own window. So here the Dash page opens Sys A and Sys B in separate windows:
While here the Dlg page replaces Sys A with Sys B and vice-versa:
You can use the double crossbar for multiples too.
In essence, you can think of the crossbar as dividing the site into two navigation subsites each appearing in its own window. Here for example, selecting the Careers link on the home page for consumers opens in a separate window a subsite for employment.
Here’s the updated TTA NSD (click for full size).
Except that TTA updated their site since I posted the original article (I believe they’ve long been aware that their site needed work), so here’s the current TTA navigation structure using crossbars (click for full size).
The TTA site is no longer such a good demonstration of the NSD symbols, but, as you can see when comparing the old and new NSD, TTA now has a much neater information architecture. I expect that translates into a better UX, which is what NSDs are supposed to be able to tell you.
TTA has also decided that “TTA” stands for “Tristate Transit Authority.” Actually, I think they reverted to that interpretation from earlier times. Not that West Virginians are particularly known for imaginative naming. Wheeling, 1861: “Well, we’re a new state made up of counties from west Virginia. What should we call ourselves?”