Drill-Down Navigation

After a user launches and logs into a responsive application, the buttons in the application’s navigation bar and header allow the user to navigate to the primary functionality offered by the application.

Many applications also offer secondary functionality that can only be accessed after the user has specified a data context for that functionality.

For example, say the user wants to view an inquiry on a customer. The user must first specify which customer they want to view an inquiry for. The selected customer is the data context that must be provided before the application can display the secondary functionality, a customer inquiry in this case.

And it doesn’t stop there. An application could provide third level functionality and beyond, with each level requiring the user to specify an additional data context.

Let’s say after selecting a customer, the user needs to view transaction history for a specific account owned by that customer. The user must now specify which of the customer’s accounts they wish to view transaction history for. The selected account is the data context that must be provided before the application can display the third-level functionality, transaction history in this case.

We use the term hub to describe a subset of an application’s functionality that requires a specific data context (primary, secondary, or higher), the term spoke to describe each navigation option available from a hub, and the term data context to describe the data selection the user makes for a hub. The hub and spoke terms come from the concept of a bicycle wheel, where each spoke radiates outward from a central hub.

We use the term navigation tree to describe the entire path the user has taken all the way from the primary navigation down to the current spoke.

Example

Let’s look at an example. Say the user needs to view transaction history for John Smith’s Savings account.

After logging in, the user sees the application’s navigation bar on the left and header up top, which present the primary functionality options for this logged in user. Let’s say the navigation bar includes options for Dashboard, Customers, and About and the header includes an option for Settings. The diagram above illustrates the primary functionality in the application, regardless of whether these options are presented in the navigation bar or in the header.

To access the transaction history for John Smith’s savings account, the user first navigates to the Customers function. The Customers function is a hub. The user must select a specific customer (the data context) before accessing the functions (spokes) within this hub.

Let’s say the user enters search criteria, then selects “John Smith” from the search results. The user is then presented with options (spokes) for John Smith; this is a secondary level of functionality. The secondary functionality offered within the Customers hub includes Customer Inquiry, Accounts, and Edit Customer functions.

After selecting John Smith as the customer context, let’s say the user navigates down into the Accounts function. The data context for this navigation is the selected customer, John Smith.

The Accounts function is a spoke within the Customers hub, but also acts as a separate hub itself.

Let’s say the Accounts function presents the user with a list of John Smith’s accounts. The user selects the Savings account and is presented with options (spokes) for the Savings account; this is a 3rd level of functionality.

The user navigates to the Transaction History function. The data context for this navigation is the Savings account.

At this point, the user can view transaction history for John Smith’s Savings account.

The navigation tree for this example could be represented as:

Customers > John Smith > Accounts > Savings > Transaction History

If you think about it, the application itself acts as a kind of hub: the primary navigation options are the spokes and the user typically has to specify login credentials as the data context before accessing the primary navigation spokes.

Navigating hub and spoke

Next, let’s talk about how users can navigate between hubs and spokes.

There are 3 types of navigation within a hub and spoke navigation tree: down, up, and over…

Navigating from a hub down into a spoke

Once the user has made a data context selection, they can navigate down to the next level of functionality. Using our example, once the user has selected a customer, they can then navigate down into the functions available for a customer: Customer Inquiry, Accounts, and Edit Customer.

There are 3 options for presenting the navigation from a hub down into one of its spokes: automatic navigation, intermediate menu navigation, and direct navigation.

Navigating down option 1: Automatic navigation

If your user research shows that your users typically use one of the spoke functions much more than other spokes within the same hub, you can choose to have your application automatically navigate the user down to the popular function.

Using our example, let’s say that our users almost always navigate to the Customer Inquiry view after selecting a customer in the Customers view. We can automatically take the user to the Customer Inquiry view after they select a customer.

This approach presents a challenge though… if we automatically navigate the user down into a spoke function, how does the user navigate to the other spoke functions in this hub? We explore options for navigating directly from spoke to spoke in the “Navigating from a Spoke Over to a Sibling Spoke” section.

The other 2 options for navigating down assume that there is not one popular spoke function that you automatically navigate to, and that the user must explicitly select which function to navigate to within the hub.

Navigating down option 2: Intermediate menu navigation

One approach for presenting the spoke options that are available after the user selects the data context for a hub is to take the user to a separate view that displays the navigation options at that level. An intermediate menu view may display other data in addition to the spoke options, or it may just display the spoke options themselves. Either way, it acts as an intermediate menu.

Using our example, say the user is in the Customers view. They enter search criteria and select “John Smith” from the search results. With the intermediate menu approach, the application would then take the user to a separate view that displays the navigation options available for the selected customer: Customer Inquiry, Accounts, and Edit Customer. The user selects the Accounts option and is taken to the Accounts view.

This approach is scalable and intuitive. The downside to this approach is that the application displays a separate, standalone, intermediate menu view that the user has to navigate down through. Even though there may only be one additional mouse click required (at most), this process can still feel a little tedious to users as they navigate down through each of these intermediate menu views.

Navigating down option 3: Direct navigation

A third approach is to collapse the context selection and the next navigation into one step.

Using our example, let’s say the Customers view displays customer search results in a grid.

With direct navigation, each row in the grid would either

1. Display a separate grid button for each of the spokes for that customer, or
2. Include one grid “more” button (the “…” button) that displays all spokes for the customer in a dropdown menu.

Let’s take a closer look at each of these approaches.

Grid buttons

The view below displays a list of objects in a grid, with three grid buttons shown for each item in the grid. By clicking the Edit or Delete option in a row, the user is both selecting a context (a specific Customer in this case) and a navigation option (Customer Inquiry, Accounts, or Edit Customer).

The grid button approach works best when:

• There are around 5 or fewer options
• There are intuitive icons that work well for each of these options

In this example there are only 3 options, which works well with the grid button approach.

The Edit icon is intuitive for the Edit Customer option, but the other two icons are only somewhat universally understandable for the Customer Inquiry and Accounts options. Finding intuitive icons for application functions can be challenging.

Grid “more” button

The view below displays a list of items in a grid, with one grid “more” button (…) shown for each item in the grid. The grid button’s dropdown menu displays a list of all spokes available for the item. By clicking an option in the dropdown menu, the user is both selecting a context (a specific Customer in this case) and a spoke navigation option.

A benefit to this approach is that it does not require you to search for an icon for each navigation option.

Comparing grid buttons and grid “more” buttons

There are pros and cons to the approaches above.

The grid button approach:

• Allows the user to both select the context and navigate to a function within that context with 1 click.
• Is less scalable: if you need to add additional grid buttons over time for new navigation options at this level, you may start running out of horizontal space to display them.
• Requires you to search for a clearly understood icon for each navigation option. This can often be difficult since many functions do not easily map to an icon.

The grid “more” button approach:

• Is arguably more scalable since it takes minimal horizontal space.
• Does not require an icon for each navigation option.
• Requires 2 clicks to navigate: one to display the dropdown menu and a second to select an option from that menu.

Navigating from a spoke back up to a hub

After the user navigates down to a spoke, they may need to navigate back up the navigation tree later.

There are two options for navigating from a spoke back up to a hub: the back button and breadcrumbs.

Navigating up option 1: Back button

The simplest way to go back within any web application is to use the back button. This is one of the most fundamental actions in any browser and is always a valid approach. But there are challenges with only relying on the back button to return up the navigation tree.

Some function interactions store multiple steps in the browser history. Search-based functions may also post back to themselves for every user interaction within the function, a best practice that allows the user to return to a previous set of search results.

But the back button only takes the user back one physical step at a time in their browser history, while the user may actually want to move one or more logical steps back up the navigation tree. This can be especially troublesome if pressing the back button takes the user back through a multi-step process that has posted changes to the database.

However, we do have another mechanism that allows the user to navigate back up to a previous level of the navigation tree without having to press back repeatedly to move through all the individual browser history steps, and that is breadcrumbs.

Navigating up option 2: Breadcrumbs

Breadcrumbs are a compact, efficient way to accomplish two goals:

• Show the user where they are in the navigation tree
• Help the user immediately navigate to a higher level in the navigation tree

Using our direct navigation example, breadcrumbs for the Transaction History view could look like this:

The breadcrumbs help the user see where they are in the navigation tree: they’re currently in the Transaction History view via the Customers and Accounts views. Breadcrumbs also allow the user to immediately navigate up to the either the Accounts view or the Customers view.

Notice that the contextual information in the screenshot above – the selected customer and selected customer account – displays in the function subtitle. Because we used direct navigation to navigate from the hub to the spoke; there are only 2 levels above the current spoke in the navigation tree: Accounts and Customers.

If we had instead used intermediate menus for navigating from a hub to a spoke, we would include breadcrumbs for those additional menu steps, displaying the context for each level (selected customer and selected account) as the breadcrumb text.

You can see how using the intermediate menu approach in this case adds 2 extra levels to the breadcrumbs. In the next section we’ll talk about a technique that allows us to trim down the breadcrumb list.

Navigating from a spoke over to a sibling spoke

We discussed options for navigating down from a hub to a spoke and navigating up from a spoke to a hub. But what about navigating over from one spoke to another spoke within the same hub?

In the simplest hub/spoke scenarios, the user must navigate back up to the hub, then navigate down to the other spoke. This is intuitive, but it requires two navigations: one up to the hub and another down to the other spoke.

In an ideal scenario, we would:

• Use breadcrumbs to compactly show the navigation tree and allow the user to navigate up that tree.
• Use direct navigation to avoid extra intermediate menus.
• Allow spoke-to-spoke navigation with just one navigation.

To accomplish this, we use breadcrumb dropdowns. A typical breadcrumb is a simple link that allows the user to navigate up to a specific point in the navigation tree. A breadcrumb dropdown is similar, but displays a dropdown menu when clicked that includes links to all spokes in this hub.

Using our example, we can mix breadcrumbs and breadcrumb dropdowns as follows:

• Use a simple breadcrumb for navigating to the top of the navigation tree, which is the Customers view in our case.
• Use a breadcrumb dropdown with the customer context (“000121923 John Smith”) to navigate to the secondary functionality, for the selected customer.
• Use a breadcrumb dropdown with the customer account context (“010 Savings”) to navigate to the third-level functionality, for the selected customer account.

Let’s talk about each of these, from right to left.

If the user clicks the third breadcrumb (“010 Savings”), they see a dropdown menu with a list of all spoke functions for the selected customer account: Account Inquiry, Edit Account, and Transaction History. The user is currently in the Transaction History spoke view and can click any of the other two options in this dropdown menu (Account Inquiry or Edit Account) to immediately navigate over to that sibling spoke without having to first return to the hub.

Similarly, if the user clicks the second breadcrumb (“000121923 John Smith”), they see a dropdown menu with a list of all functions for the selected customer. The user can click any of the options in this dropdown menu to immediately navigate up and over to that second level spoke with just 1 click.

If the user clicks the first breadcrumb (“Customers”), they’ll navigate back to the Customers view and can search for and select a different customer to work with. This first breadcrumb could technically be left out since the user can navigate directly to the Customers view from the primary navigation in the navigation bar, but it also helps the user visually understand that they’re in a navigation tree rooted in the Customers view, so it’s generally nice to include this level if there is room for it.

Breadcrumb dropdowns replace intermediate menus

If you think about it, the breadcrumb dropdown acts as an intermediate menu on demand, without requiring the user to have to navigate through a separate, standalone view dedicated to each intermediate menu.

This approach gives us the best of all worlds: we can quickly navigate down while selecting a context, quickly navigate back up to any level of the navigation tree, and quickly navigate over to sibling spokes, all without requiring standalone intermediate menu views.

Displaying context data within the breadcrumbs

Another benefit to the mixed breadcrumb approach is that it allows us to display the context data in the breadcrumbs, helping the user see the details of the navigation tree more efficiently.

The user can see all information related to the navigation tree in one compact location.

Contrast this with the approach shown earlier, where the context data is split out to the function subtitle at the far right. The user has to look in two separate locations to find the navigation tree and context data, then has to mentally stitch the two sets of data together. This is less efficient for the user.

Another approach to avoid is displaying the data context in the function title. While this does bring the context data over into the breadcrumb area, it can also significantly clutter the function title, making it more difficult for the user to visually parse the navigation tree.

We recommend using the mixed breadcrumb / breadcrumb dropdown approach. This solves the challenges mentioned above, helping the user quickly see and understand where they are in the navigation tree, while allowing them to navigate up the navigation tree or over to a sibling function, without requiring standalone intermediate menu views.

Primary hub navigation

Some of these concepts also apply to your primary navigation too, which is available to the user after they’ve logged in. If you think about it, your primary navigation is a kind of hub: the user must first specify a context – their login credentials – then they’re presented with a list of spoke options within the primary navigation.

• Navigating down using automatic navigation: For some applications, there is one function that most users typically start with, say a dashboard or a home view, so you can automatically navigate users to that function after they log in.
• Navigating down using an intermediate menu: Other times, no primary function has a higher usage weight than the others. You have to take the user somewhere after they log in, so in this case, you can start the user at a dummy Home page that provides links to the most popular primary functions. Primary hub navigation
• Navigating over to a sibling spoke: The user can navigate to primary functions at any time by using the application navigation bar and header. Other concepts like navigating up and navigating down using direct or flat navigation don’t apply to primary navigation.