UI Patterns and Techniques

Hub and Spoke

From http://hellocode.com
Use when:	You are designing a UI that contains several discrete tasks or content elements: forms, demos, games, articles, transactions, entire applications, etc. All are reachable from one central page or window. But you don't want to link all the sections or "spokes" to every other one, for several possible reasons: space constraints, absence of visual and/or cognitive clutter, restricted workflow to force the completion (or explicit cancellation) of a task.
Why:	Primarily, you are using navigation to structure the user experience into something different from the free-form hypertext browsing offered by the Web. You are asking the user to focus on one section at a time, then go back to the hub and navigate to another section. This certainly reduces clutter on the "spoke" pages -- the user has less to look at, and less to think about. But by restricting the available navigation paths through interactive pages, you can also prevent errors -- users can't shoot themselves in the foot so easily. With no navigation buttons, they can't leave a Web form half-finished by jumping to a different page (the "abandoned edits" problem); with a modal window in a desktop app, they can't "lose" the dialog on the screen; in general, they have less opportunity to get the UI into a self-inconsistent or confusing state. Furthermore, restricted navigation means you have much tighter control over what circumstances the UI needs to handle -- this often results in simpler (and thus cheaper) implementation. The architecture scales well, too; as more functionality comes on line, it's easy for you to add more spoke links to the hub page. Finally, you may simply want to design the user's experience of the "spokes" as simple, self-contained UIs. This isn't always appropriate -- in fact, it can be downright annoying! -- but the choice is yours. An advantage is that the user will find it very clear what to do; the hub-and-spoke structure is intuitively obvious in many contexts. You click on a spoke, you do your thing, and you go back to the hub when you're done.
How:	On the hub page, arrange links to the spokes. On each spoke page (and each spoke may have several pages, such as with a wizard), remove all navigation links that distract from the main task flow. Leave only pertinent actions -- Back and Next buttons, Cancel, Done, etc. -- and perhaps those that won't interfere with the workflow, such as help windows and email links. When the user has reached the end of whatever they're doing on the spoke, provide a way for the user to say they're finished, such as Prominent Done and Prominent Cancel. Both of these should ultimately take the user back to the hub. A nice description of a specific use of the hub-and-spoke architecture can be found in Bob Baxley's article Views and Forms: Principles of Task Flow for Web Applications, Part 1. His first main point is that viewable information in HTML-based Web apps should be separated from editable forms, but his second point is that a hub-and-spoke approach prevents errors and abandoned edits. The article was part of the inspiration for this pattern.
Examples:
From http://mailblocks.com This is another suite of Web applications presented using a hub-and-spoke architecture, similar to the example at the top of this page. Both of them present a small handful of toplevel choices, and each self-contained mini-application or function presents a very limited number of things the user can do -- Submit, Cancel and Log Out in this case, and Start (the hub) in the case of Hellocode.com. The Mailblocks application was designed this way explicitly to prevent errors and inconsistencies.
From http://iht.com News sites such as IHT usually use a hub-and-spoke architecture. The main page has links to all the top articles; the article pages link only to the main page, related stories, and various pieces of article-related functionality. Users will generally start at the main page, read an article, and jump back to the main page to read another.