ux.artu.tv » Blog Archive » 24 Weeks of Windows Phone Metro Design | #4 Hub & Spoke Navigation Model

24 Weeks of Windows Phone Metro Design | #4 Hub & Spoke Navigation Model

24 Weeks of Windows Phone Design Index



Today we begin our preparation to get ourselves ready to define the Information Architecture (IA) for our app. We will discuss Information Architecture more in depth in a future (not too far away post) but first I want to touch on a couple concepts that I think are critical for us to be able to visualize in our mind how a Windows Phone app is structured. With this knowledge in mind plus the IA for your app we should be in a good place to move forward in the design process. The first concept I want to talk about is Hub & Spoke Navigation Model and the second one is Choosing Between Pivots, Panoramas and Pages. This week we will cover Hub & Spoke and next week we’ll go into the choosing the right screen patterns for your apps.

The Hub & Spoke navigation model or “distribution paradigm” is not exclusive to Windows Phone. It is a widely known model used on website navigation and structure as well as in other digital interaction mediums. The Hub & Spoke model is particularly popular outside the digital realm and widely used in transportation, telecommunications and urban design. One of the best examples are airline route maps.

Airline Routes

Wikipedia defines the Hub & Spoke Distribution Paradigm as “a system of connections arranged like a chariot wheel, in which all traffic moves along spokes connected to the hub at the center.”

Hub & Spokes

While working on this post I came across Paul Laberge’s Going with the Flow… Using Metro to Control the Experience article and I must say he covers almost everything I wanted to cover here :) . Paul does a great job of highlighting the top concepts related to Hub & Spoke navigation in Windows Phone. To avoid duplication I will refer you to his article and instead will spend some more time here covering examples and other in depth guidance on Hub & Spoke. Make sure you read Paul’s article.

The reason Hub & Spoke is important in Windows Phone is because it helps you define the flow of the application, or the flow of the experience as Paul describes. When working on a Windows Phone app the flow is the first thing to nail down - not the visual design.

Windows Phone Hub & Spoke

The Hub & Spoke navigation model is ideal for small digital devices, like phones, where screen resolution is limited and small but where content is still a lot to deal with. Here is a typical side to side scenario between Windows Phone Hub & Spoke and iPhone/Android non-hub and spoke models.

Windows Phone compared to Android

The Backstack

A fundamental concept in the Hub & Spoke model in Windows Phone is the “Backstack”. The best way to describe it is with breadcrumbs. As in Hansel & Gretel breadcrumbs J Once upon a time Hansel & Gretel where navigating happily through a dark dark Windows phone app (with black background). Every time they went to a new screen they’d drop a breadcrumb there so they knew the list of screens they’ve been to. They went on and on until they found a little house where an old lady invited them in offering ice cream sandwiches and apples. Luckily in this version of the story Hansel & Gretel were smarter and they decided to go back home. The list of breadcrumbs they dropped helped them return back where they came from.

In a nutshell, in Windows Phone the user taps objects, buttons, list items, icon buttons in the app bar or other user interface controls to move forward in the app structure. Basically, the user moves forward by making decisions.

The user moves backward in the app structure by using the back button… the user moves backwards by instinct and memory. The back button is used “blindly” by the user and the user learns to trust the back button. From this point of view the breadcrumbs analogy actually works only for the developer of the app. The user doesn’t have a visual map that tells her where she is going to - she just knows she is going back where she came from.

This is the reason why handling the Backstack correctly is so important, because the user will use the back button with only her memory as a guide. It is also the reason why starting to define the right app structure early in the design process is fundamental for the long term success of the project.

Hub & Spoke Sample

Removing Steps in the Backstack

Sacrilege!? No, not really… in fact, you as the developer or designer are responsible for removing steps from the backstack if needed and whenever it makes sense. I was first introduced to this concept by Corrina during the Windows Phone Design Day tour last Fall. In her REFINE session she provides some really good example of when it makes to remove steps in the backstack.  At first I would have though the backstack is untouchable since we want to respect a user’s path but there are different scenarios when it is convenient to remove items from it. In this example Corrina explains that it obviously doesn’t make sense to have users return to the credit and billing screens once the purchase transaction has been completed. Instead when pressing the back button on the last screen the app would take the users back to the wish list.

Billing and Credit

In this other example we can see an opposite scenario where removing search and results from the backstack could cause confusion for the user. The user is in a wish list, searches for products, finds some products and adds one to the wishlist. From this last screen it makes sense to send the user to the search results screen (the previous one) since she might be interested in adding more items from the same results instead of going all the way back to the wishlist and having to perform perhaps the same search again. So you can see how in different scenarios, it makes sense or not to remove screens from the backstack.

Search Results in Backstack

Here are some additional tips that Corrina shared with us during the tour:

“Remember, back means back; not forward, not sideways, but back.”

“Ensure application state is persisted appropriately.” 

“Ensure transient interface elements do not appear in the back stack.”

Transient UIs

Diagraming the Hub & Spoke Navigation Model for your App

Here are a couple methods to diagram the flow of your app and how the Hub & Spoke model will get to manifest in it. Please note these are techniques for illustrating diagrams and not methods for defining your app flow. Your application flow can only be defined later in the design process when you start exploring and maturing the Information Architecture.

Abbreviated Nomenclature

This method is quick. It’s great when quickly wanting to convey an idea of flow to your peers - other designers or engineers. You can use this by sketching it with pen or pencil or using some of the visual assets in this Expression Design file or Adobe Illustrator file. It consists of drawing circles with abbreviations as follow:

Start - Windows Phone Start Screen

Pv - Pivot

Pa - Panorama

Pg - Page

Abbreviated Nomenclature

Visual Nomenclature

This is a more detailed nomenclature that allows you to convey visually the key elements or screens in your application flow. I’ve created some Expression Design and Illustrator templates for this nomenclature if you want to use it with your favorite visual design tool. You can also sketch this out. Here is a way I do it that uses just a few strokes making it as easy and quick as possible.

Visual Nomenclature

Visual Nomenclature with Backstack

Learn More about Hub & Spoke Navigation Model in User Interfaces

This is Paul Laberge’s article on Hub & Spoke model in Windows Phone. Also, here is the Navigation section in the Windows Phone UX Guidelines which describe Hub & Spoke in more detail as well as explains some other concepts like Tombstoning.

A good way to understand Hub & Spoke is to explore alternative navigation and information architecture models. Also, Tombstoning is an important component of the Hub & Spoke navigation model as it allows application to persist their state even when users have moved beyond our outside of it. Escaping Navigation Hell by Like W is a great article that describes specific techniques to craft experiences where content is a lot and complex - while this usually drives for an also complex navigation mechanism, Luke provides shares some tips to tackle down navigation (or not to at all! J).

Finally if here is the obvious Wikipedia page for Hub & Spoke as well as the Infragistics Quice Design Pattern page for Hub & Spoke (worth studying for other common navigation design patterns).

Next Post | #5 Choosing Between Panoramas, Pivots or Pages

In our next post we will review the criteria to decide when to use Panoramas, or Pivots or Pages. We’ll demystify the use of some of these screen patterns.

7 Responses to “24 Weeks of Windows Phone Metro Design | #4 Hub & Spoke Navigation Model”

  1. ux.artu.tv » Blog Archive » 31 Weeks of Windows Phone Metro Design | #3 Ideation and Concept Says:

    […] 31 Weeks of Windows Phone Metro Design | #2 The Design Process of a Windows Phone App 31 Weeks of Windows Phone Metro Design | #4 Hub & Spoke Navigation Model […]

  2. Matthieu Narcisi Says:

    Great article as usual! Each monday I am eagerly looking for the next article in this serie!

    Only just one thing though, you say: “Your application flow can only be defined later in the design process when you start exploring and maturing the Information Architecture.”

    But how are you supposed to define the navigation without defining the flow at the same time? How are the tow different?

    Just one other thing, you mention to files, but there is no link for them. (”this Expression Design file or Adobe Illustrator file.”)

  3. WindowsDevNews.com Says:

    […] 31 Weeks of Windows Phone Metro Design | #4 Hub & Spoke Navigation Model […]

  4. ArturoT Says:

    Hello Matthieu! I just fixed the links to the .design and Illustrator file :) thank you for the catch.

    To your question - I’m referring to defining Navigation “mechanisms” - you can define the flow of your app without necessarily knowing exactly what type of nav mechanisms you will use - will you use an app bar? a mini app bar? will you have 3 or 4 or more buttons in your app bar? will you use a main menu in one or more of your panoramas? will you create a custom navigation control?… all these details are hard to know at this point - so IMO flow does not equal navigation. Hope this helps!

  5. Rowland Says:

    The links to the .design file seems to 404 at the moment, which a shame, as work really well for getting design ideas across.

  6. Matthieu Narcisi Says:

    Ok, so at this point, I just define the main principle I will use in my app. Like, I will use a button in the top of my pano (like the contact hub), but an app bar button in the pivot page.

    But the transition, and which page lead to which page is defined later; with the Information Architecture, later.

    PS: just a little note: the design file, seems to lead to a 404 error.

  7. Antoni Dol Says:

    I once wrote a column called “The BreadCrumb Paradox” that contains this passage:

    The biggest paradox with breadcrumbs comes from its origin: The Hansel and Gretel fairytale. From my history as an illustrator I happen to have several thick volumes with fairytales. One of those contains the original text from which the term breamcrumbs originated:

    Hans comforted his sister and said: “just wait until the moon rises, Grethel. Then we will see the pieces of bread, which I’ve sprinkled. That will point us the way Home.” When the moon rose, they went on the road, but they found no more pieces of bread. The thousands of birds that fly around in the woods and across the field they had picked up. Hans said to Gretel: “We will find the way Home.”

    But they never did.

Leave a Reply