Creating a great app requires honing in on what makes your app best in its category and making that shine. Windows 8 provides tools like charms and app bars to make it easy to really focus on what makes your app best in class and minimize anything that distracts from it. Learn to use those tools and your app and your users will be able to really enjoy what makes your app great.
Focusing on what your app is best at
When you watch a movie in the theatre, the movie is playing on a huge screen so it’s all you can see. The rest of the theatre is dark. The surround sound is everywhere so the movie is all you can hear. People talk about movies that you need to see in the movie theatre; it isn’t worth it if you don’t get that movie theatre experience where you can be totally immersed in the movie. The dialog is clearer, the picture is more lifelike. You can almost feel like you are there. That is, until the guy next to you gets a call on his cell phone, you get distracted, and are ripped out of the experience. Every distraction pulls you, bit by bit, away from fully enjoying the movie.
Your app is the movie theatre and your app's content is the movie. This idea of creating an environment for users to immerse themselves in your app is core to the new design. In the post on Creating Metro apps that stand out from the crowd, we talked about picking a statement that describes what your app is best at in its category. If you know what you want your app to be best at and stay laser focused on that, then Window 8 provides the tools to let you keep everything else – all of the distractions -- out of the way until the user wants them. We walked through this idea using an example app called Food with Friends.
We designed these pages in Food with Friends:
Figure 1: The Food with Friends hierarchy
Based on what’s already been laid out in Food with Friends, you can respond to friends’ suggestions about what to do tonight, find out which restaurants your friends want to go to, and find restaurants that you want to go to. There are also things you can’t do yet. You can’t add restaurants to your wish list, sort or filter the list of all restaurants, or search for a particular one. That’s ok. All of that functionality is important, but it isn’t what your app is best at. Remember from the last post:
- Food with Friends is the best app in its category at helping users and their friends find a restaurant to eat at tonight.
Sure enough, that is exactly what you can do just by interacting with the app UI that we’ve laid out already. The best at statement is perfectly represented on the canvas. If we were to add buttons and widgets to allow users to add items to your wish list or to sort and filter lists, it would just distract users from the content when those commands aren’t needed. But there are times when the user will need to access these commands. So where do those secondary, but important commands go?
Windows 8 provides standard ways for users to access UI in apps. This UI is made available on-demand, and is hidden until exactly when the user wants it. When commands are available on-demand, you don’t have to distract users by overloading your app’s canvas. On-demand UI lets you focus every pixel of your app on your best at statement. There are two mechanisms that nearly all apps use to expose their on-demand UI: charms and app bars. Since both Charms and app bars will be available across the ecosystem and are always invoked in a standard way, you can count on users bringing them up when they need them, and focusing on your app’s content when they don't.
Charms
Figure 2: The Charms bar
When designing Windows 8 we recognized that there are some features that nearly every app will have and they are features that all users come to expect in a great app. Given their ubiquity, we created a permanent home for these commands, called charms, in every app. Charms provide entry points to searching, sharing, connecting to devices, and settings in every app and in the system itself. You can use them everywhere in the system. So, when designing your app, you don’t need to figure out a clever way for users to share your content with other apps or social networks, or where to put your search box. That isn’t what’s going to differentiate your app from all others. Settings can be important, but they don’t need to distract from the truly cool and interesting features that you’ve built. Charms provide users with a standard way to get to these features. Best of all, they are off-screen unless the user asks for them, so they don’t distract from what truly differentiates your app; the content. Users bring out the charms with a swipe from the right, dragging the mouse into the right corner, or pressing Windows key + C and that works in every part of the system.
App bar and navigation bar
Figure 3: App bar and navigation bar
While charms provide a standard way for users to get to the features of almost every app, the app bar and navigation bars are ways to get to the functionality that is specific to each individual app. The sections of an app that populate a navigation bar are different from app to app. The commands on an app bar are contextual to the app, the page, or even the current selection. Even though app bars and navigation bars are different from app to app, they are powerful tools for every app because it will always be the first place a user looks to see what the app can do because that's how all apps work. Across all apps, users get to your on-demand UI by swiping from the top or bottom of the screen, right clicking anywhere in the app with a mouse, or pressing the Windows key + Z on a keyboard, and those work in every app with app bars or navigation bars.
The standard on-demand UI in Windows 8 is what allows users to spend their time exploring your app’s content and not figuring out the user interface. The reason this works is because it is consistent and predictable across Windows and across apps. In the rest of this post, we talk about how to design and build great app bars. In future posts we’ll go into more detail about some of the other capabilities in the system, like the individual charms, that help you focus your app on what it is best at, while getting the full benefit of the Windows 8 ecosystem of apps.
What goes into an app bar
The first thing to think about when creating an app bar is what goes in it. Like we spoke about before, it’s the features that should be available only on-demand because they aren’t core to the primary scenarios your app is meant to be best at. You can often identify these things by determining if they are going to be used frequently over the lifetime of the app. For an example, take a look at the app bar in the SkyDrive app from the Release Preview:
Figure 4: The SkyDrive app bar
The SkyDrive app is best at giving users access to their vast amount of content from anywhere. So the app’s canvas is focused on browsing that content. Of course, adding files is an important part of the app. After all, how else will you get that vast collection up there? But it isn’t something users will be doing all of the time so the Add button is great to make available on-demand. This way every pixel of the app’s canvas is dedicated to browsing your collection, unless it is one of the times you decide you want to add new files. In those cases, your users will know exactly how to bring up the Add command because it shows up in the same way that app-specific hidden UI is shown across the system.
Creating an app bar
The AppBar control in WinJS and XAML is the best way to create on-demand UI. You can use it to create both an app bar at the bottom of the screen and a navigation bar at the top (though we focus on the former here).
The most important thing about a great app bar is that it brings all available app commands to the user on-demand using the standard gesture (swipe from the top/bottom, right click, or press the Windows key + Z. The app bar control gives you that behavior for free and beyond that, makes it very easy to create a basic app bar that fits into the overall look and feel.
For example, if we were to create an app bar for the hub page of Food with Friends, the only command that is relevant by default is the ability to create a new plan for tonight, so this would be our app bar:
Figure 5: Food with friends app bar
HTML
It’s easy to create a standard app bar in HTML. Just create an AppBar control, and then put AppBarCommand controls inside of it, setting properties on them as appropriate. This is made even easier with the AppBarIcons enumeration, which is a list of icons that are pre-built and ready to use that match the new style.
<div id="foodWithFriendsAppBar" data-win-control="WinJS.UI.AppBar">
<button data-win-control="WinJS.UI.AppBarCommand"
data-win-options="{id:'cmdAdd',
label:'New plan',
icon:'add',
section:'global',
tooltip:'Create a new plan'}">
button>
div>
XAML
To create an AppBar in XAML, you instantiate an AppBar element and set it as the BottomAppBar or TopAppBar property on the Page object depending on where you want the AppBar to appear. You then add buttons to the AppBar using the stock styles that are provided in the default Visual Studio project templates for Windows Store apps. Iin XAML, you decide how you want to lay out the buttons within the AppBar by placing the buttons within the desired layout panels.
<Page.BottomAppBar>
<AppBar>
<Grid>
<StackPanel Orientation="Horizontal" HorizontalAlignment="Right">
<Button Style="{StaticResource AddAppBarButtonStyle}"
AutomationProperites.Name="New plan"/>
StackPanel>
Grid>
AppBar>
Page.BottomAppBar>
Controls that can go in the app bar
We commonly see a few kinds of commands in app bars: buttons, toggle buttons, and in JS, flyouts. For examples of each of these types, take a look at the app bar in the Mail app in the Release Preview:
Figure 6: Mail app bar
The Mail app bar has examples of standard buttons (like Paste), toggle buttons (like Bold, Italic, and Underline), and buttons that launch menus (like More) and custom flyouts (like Font, Font color, and Highlight). To create these button types in JS see AppBarCommand object. In XAML, follow the styles in the project templates and for the flyouts, use the Popup class with light dismiss behavior.
Contextualizing the app bar
Providing UI on-demand works only if users know exactly where to find it. If they need to dig around every corner of your app or try every piece of UI searching for the next hidden command, then they won’t have much of a chance to actually enjoy your app. That’s why a successful app bar, always displays all commands that are available at a given time. The relevant commands might vary based on a few things: the current page, the current selection, or anything else that changes the state of your app. In those cases, show all of the commands that are relevant, those that are available globally (because they still work) and those that are specific to current context. For example, if you right-click the Start screen without a selection, the app bar just has the All apps button:
Figure 7: The Start screen app bar
If you right-click a tile to select it, the app bar has the All apps button in its normal position, but also features tile-specific commands on the left:
Figure 8: The Start screen app bar showing tile-specific commands
When we keep all relevant commands visible, the user can right click anywhere on the screen to get to all of the on-demand UI – they don’t need to watch their step and make sure to right-click, but not accidentally select a tile. By putting the commands that come and go on the left (or on the right in right-to-left languages), you provide a predictable place for users to see what they can do with their selection. Users can have confidence that right-clicking anywhere shows them all available commands, and anything specific to their selection appears on the left.
The reason the contextual commands that come and go are on the left is ergonomic. We found in studies that most users (even lefties!) operate touch devices with their right hand. If selection-based commands were to appear on the right, then as you raise your right arm to select an item you would cover the new commands that just appeared! Similarly, putting commands that are always present on the right allows you to use your right hand to access them, which is ideal because most users interact with touch devices with the right hand. So putting commands that come and go on the left, and commands that are always there for a given screen on the right, makes it more efficient for users to get to with touch.
On the Food with Friends hub page, this is the default app bar when nothing is selected:
Figure 9: Food with Friends app bar on the hub, with no selection
When you select a restaurant, then you have the chance to add or remove it from the wish list. So on
selecting a restaurant, a wish list toggle button appears in the app bar:
Figure 10: Food with Friends app bar on the hub with an event selected
Just like on Start, the commands that come and go based on selection show up on the left to separate themselves from the always-present New plan command.
Here is how you place commands on separate sides of the app bar, and how to make commands come and go.
HTML
To place a command on the left side, you must put it in the selection section. To have it hidden by default, set the hidden property to true. The extraclass property allows you to easily refer to a set of commands in code, so we use that to cluster the commands that should show together on selecting an event.
<div id="foodWithFriendsAppBar" data-win-control="WinJS.UI.AppBar">
<button data-win-control="WinJS.UI.AppBarCommand"
data-win-options="{id:'cmdAdd',
label:'New plan',
icon:'add',
section:'global'">
button>
<button data-win-control="WinJS.UI.AppBarCommand"
data-win-options="{id:'cmdWishlist',
label:'Wishlist',
icon:'favorite',
section:'selection',
hidden:'true',
extraClass:'restaurantSelection'}">
button>
div>
To show and hide commands dynamically on the app bar, simply call:
var restaurantSelectionCommands = document.querySelectorAll(".restaurantSelection");
appbar.showCommands(restaurantSelectionCommands);
To look up all of the icons that are provided for the app bar, check out the AppBarIcon enumeration. For a full list of AppBarCommand properties, see WinJS.UI.AppBarCommand object.
XAML
The XAML AppBar doesn’t manage the layout of the buttons by default, so to follow the prescribed layout using left and right command sections you must provide the necessary layout panels to host the buttons. Here we use a Grid that contains two columns, each occupying half of the AppBar. We then add two StackPanels, one left aligned and one right aligned to contain the buttons.
It is possible to hide/show XAML AppBar buttons by simply setting the Visibility property of each button, but this will not cause the buttons to properly animate in and out. To match the HTML AppBar behavior of animating buttons in and out, you need to add the AddDeleteThemeTransition to the ChildrenTransitions property for each panel that hosts AppBar buttons. Then to fire these transition animations you must actually remove/add the buttons from the AppBar.
<Page.BottomAppBar>
<AppBar x:Name="BottomAppBar1" IsSticky="True">
<Grid>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="50*"/>
<ColumnDefinition Width="50*"/>
Grid.ColumnDefinitions>
<StackPanel x:Name="LeftPanel" Orientation="Horizontal" Grid.Column="0" HorizontalAlignment="Left">
<StackPanel.ChildrenTransitions>
<TransitionCollection>
<AddDeleteThemeTransition/>
TransitionCollection>
StackPanel.ChildrenTransitions>
StackPanel>
<StackPanel x:Name="RightPanel" Orientation="Horizontal" Grid.Column="1" HorizontalAlignment="Right">
<Button x:Name="New" Style="{StaticResource AddAppBarButtonStyle}" AutomationProperties.Name="New" Tag="New"/>
<StackPanel.ChildrenTransitions>
<TransitionCollection>
<AddDeleteThemeTransition/>
TransitionCollection>
StackPanel.ChildrenTransitions>
StackPanel>
Grid>
AppBar>
Page.BottomAppBar>
private void AddEventSelectionCommands(object sender, RoutedEventArgs e)
{
Button inButton = new Button();
Button vetoButton = new Button();
Button mehButton = new Button();
inButton.Style = App.Current.Resources["AcceptAppBarButtonStyle"] as Style;
inButton.AutomationProperties.Name = "In";
vetoButton.Style = App.Current.Resources["CancelAppBarButtonStyle"] as Style;
vetoButton.AutomationProperties.Name = "Veto";
mehButton.Style = App.Current.Resources["HelpAppBarButtonStyle"] as Style;
mehButton.AutomationProperties.Name = "Meh";
// Make it the second item
LeftPanel.Children.Insert(1, inButton);
LeftPanel.Children.Insert(2, vetoButton);
LeftPanel.Children.Insert(3, mehButton);
}
It’s there when you need it
Part of creating a contextual app bar is also showing it just when the user wants it. For example, when you select a tile on the Start screen (swiping the tile down with your finger, right-clicking a tile, or pressing Ctrl + Space with focus on a tile), then the app bar shows automatically as long as you have a selection. If a user selects a tile, it’s because they want to do something with it. The app bar is where you do things, so that’s why you must show it. Similarly, when a user is writing a mail and you select text, the Mail app bar shows with copy/paste and formatting commands. After all, if a user is selecting text, it’s probably because they want to do something with it!
Normally, the app bar is light dismiss. That means that if the user taps outside of the app bar, it goes away. Whenever you bring up the app bar programmatically (as you would on selection), it is important to disable light dismiss by making the app bar sticky. Doing this allows users to change their selection after the fact, or multi-select, without dismissing the app bar. Make sure to re-enable light dismiss when the selection is cleared!
HTML
This is code to handle an object becoming selected:
var restaurantSelectionCommands = document.querySelectorAll(".restaurantSelection");
appbar.showCommands(restaurantSelectionCommands);
appbar.sticky = true;
appbar.show();
When the selection is cleared, you would write the inverse code:
var restaurantSelectionCommands = document.querySelectorAll(".restaurantSelection");
appbar.hideCommands(restaurantSelectionCommands);
appbar.sticky = false;
appbar.hide();
Check out the HTML AppBar control sample for a working example of showing and hiding an app bar with contextual commands based on selection.
XAML
In XAML you have a SelectionChanged handler for your list and in that handler you check to see if an item has been selected or cleared. If an item was selected you call the method to show the commands, set the IsSticky property on the AppBar to true, and then show the AppBar. If a selection was cleared you call the method to hide the commands, restore the IsStricky property back to false, and close the AppBar.
private void RestaurantList_SelectionChanged(object sender, SelectionChangedEventArgs e)
{
ListView lv = sender as ListView;
if (lv.SelectedItem != null)
{
ShowRestaurantCommands();
BottomAppBar.IsSticky = true;
BottomAppBar.IsOpen = true;
}
else
{
HideRestaurantCommands();
BottomAppBar.IsSticky = false;
BottomAppBar.IsOpen = false;
}
}
Command layout
The next step is to determine how to lay out your commands. The best place for commands are on the left and right sides of the screen. For touch, it is because the most common way for a user to hold a tablet device is along the sides and so having commands on the edges allows users to keep their hands where they are and access the commands with their thumbs. For mouse, it is because of Fitts’s Law – users can throw their cursor into the bottom corners more easily and quickly than anywhere else on the screen, so the closer the commands are to the edges, the easier it is to target them.
The only question then is which commands go where, and how to divide commands between the two sides. We go into depth on this in Commanding design for Metro style apps, but in short, like with every element of app bar design, lay out your commands so that their locations are predictable. Start by laying out the commands based on the most common screens, and most common commands – make those great. A good rule of thumb is to put the most commonly used commands closest to the edges, or to follow examples for similar command in other popular apps. This way users can, before even using your app, predict how it will work. Then on every subsequent screen, keep any shared commands in the same spot and place the rest of the commands around those. When a command has a home, don’t move it. This way users can learn where commands belong, and using your app will start to become second nature, continuing to help them focus on the main content of your app.
Often, commands come and go based on selection, or based on the current context of the app. For example, in Food with Friends, on the restaurant listings page, there are some commands that are relevant only when viewing the restaurants in a list (like sort) and there are some commands that are available only in map view (like centering on the current map location). In those cases, place the commands such that the ones that show in both contexts closer to the edges, so they don’t move around when the user switches context.
In Food with Friends, on the All restaurants page, user can toggle between a list view and a map view. The set of available commands changes when the view changes so placement becomes very important:
Figure 11: Food with Friends All restaurants page in a list view
Figure 12: All restaurants page in a map view
Notice how the filter command is to the left of sort in list view, and the map style button in map view? Now, if you switch between those two views, all of the common commands stay in their home and don’t shift around keeping the app bar stable and predictable.
Changing views
Starting by laying out commands for your app’s landscape view is standard, but it is also important to think about what app bars will look like in portrait and when your app is snapped. By default, the WinJS app bar automatically reflows based on the available width, and ensures that up to 10 commands always fit. In portrait, the app bar drops the command labels, and in snapped view the buttons flow to two rows. This is what happens automatically and is great functionality to take advantage of if the content of the app remains consistent between views.
With the XAML app bar, or if you are using the custom layout of the WinJS app bar, you have complete control over the content and layout of your commands. This means that in portrait and snapped views, you must pay extra attention to make sure that all of your commands fit and continue to look great. Strategies you can use in these cases are dropping all of the button labels, grouping commands in menus, or hiding commands that aren’t relevant in those states.
|
Figure 13: Snapped all restaurants map view |
In the Food with Friends app you can see an example of tailoring the app bar to look great in snapped view while maintaining all the relevant commands. In this case, to reduce to 5 buttons (so the buttons can all appear on a single row), the view toggles, list view and map view, are combined into a single menu. |
Making it your own
The AppBar control allows you to easily create a basic app bar. It also makes it easy to customize it to really fit into the style of your app. Common customizations include changing the color, the glyph or the style of the button. Get creative! The app bar should feel like a natural extension of your app and so infuse it with the same personality that the rest of your app has. You can find examples of how to do this in the HTML AppBar control sample and the XAML AppBar control sample.
Depending on the commands that you have, you might even consider showing your on-demand UI in a totally different way than an app bar. That’s great – get creative! If you do go this route, make sure to remember that users will be expecting that hidden UI to show when they use the standard gestures (swipe from the top or bottom, right-click, or press the Windows key + Z), and that you can usually dismiss it by tapping off of the UI. For info on the standard on-demand UI events, see EdgeGesture class.
That’s it
A large part of the new design is about focusing your app on the specific thing that it is best at. Keep what sets your app apart in the forefront and limit anything that distracts from that by making it available on demand. Using the app bar is an easy way to do that, and following the common conventions on command placement and contextualizing the app bar allows your users to dedicate their time to enjoying what truly differentiates your app rather than figuring out the command layout. If you use the tools and conventions that Windows 8 provides to focus your UI on what your app is best at then users will get to appreciate what makes your app great.
For additional info on the patterns around on-demand UI, check out http://design.windows.com and the Guidelines for app bars. For more on the AppBar control in JS, play with the HTML AppBar control sample, the XAML AppBar control sample, and look up the WinJS.UI.AppBar object, and the Windows.UI.Xaml.Controls.AppBar class.
Happy coding!
--Jon Gordner, Lead Program Manager, Windows