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.
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.”
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.
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.
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.
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.
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.
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.”
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.
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
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.
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.