ux.artu.tv » Blog Archive » 24 Weeks of Windows Phone Metro Design | #14 Using the Windows Phone App Bar

24 Weeks of Windows Phone Metro Design | #14 Using the Windows Phone App Bar

24 Weeks of Windows Phone Design Index

Twitter   

To give continuity to the previous post on iconography, let’s talk about App Bar this week. I apologize for the “organic” approach to tackling down the blog post schedule :) In this post we will discuss the Windows Phone App Bar. The reality is there’s already plenty of good information about the App Bar out there so I’ll see this post more as an aggregation of what I’ve found out there plus some other tips I’ve learned along the way.

The App Bar in Windows Phone is one of the controls with more personality in Windows Phone. It is usually seen as a navigation bar but what I’ve found consistently is it’s more like an “action bar”. The reason I say this is because if you look at the out-of-box experience in Windows Phone you will find most of the Icon Button or Menu Items are more like actions or ‘verbs’ than pointers to other portions of the app. This might sound like semantics but I think it’s actually something stronger than just that.

The most important navigation mechanism in Windows Phone is content itself. Our instinct when creating an app tends to be solving navigation by adding as many buttons or UI controls as we think we need. In iPhone you will find developers enable users to go to other sections or even content views using the tab bar. In Windows Phone these views would be part of a Pivot control (Featured and Most Recent). Categories will most possibly have been located in a previous Page, Pivot or Panorama. If the user wanted to go to Categories in Windows Phone they would hit the back button. The Search button would be in the App Bar and the “More” would remain there as our Ellipsis Expander.

iPhone Tab Bar

Windows Phone App Bar

So, in Windows Phone the App Bar is usually not used for navigation per se but for “actions”. I don’t think this is written in stone though - for example you will find Settings available in many apps in Windows Phone (in the App Bar). Settings is clearly navigating the user to another section of the app - it doesn’t sound like a verb. In Windows Phone if you wanted to have two Icon Buttons in the App Bar called Theaters and Movies, then instead of navigating the user outside of their current context, these buttons would act more like “view switches” so the user stays in context, but the view changes to show movies or theaters. This is what happens in the Calendar - you have a Month Icon Button - you hit it and the view changes to Month view but the user is still within the same context aka Calendar.

Windows Phone Calendar

So they key takeaway is to always try to enable navigation through your application using content first - not UI controls. Use the App Bar mainly for hosting actions, not navigation (again, there’s always navigation occurring as you will be taken to another screen but within the same context).

Also a common approach coming from iPhone/Android worlds is to locate navigation buttons within content on the main page. In Windows Phone we usually avoid mixing UI elements like buttons with content. So if you have an email items list we would never place a button next each item for say “Deleting”. Instead we would recur to the use of tap and hold to bring out the Context Menu for the item, then hit Delete. In the case of the App Bar we could also have a Delete button in there, hit it and that switches the List View to multi-selection along with changing the App Bar to display new icon buttons relevant in this multi-selection mode, the user multi-selects items and hits the trash can button in the app bar.

The App Bar can either be collapsed or expanded (up or down). In both cases there are different states the App Bar can adopt.

Windows Phone Using App Bar Modes

App Bar

The Application Bar is one of our core navigation mechanisms in Windows Phone. It is a flexible control that lives on the bottom of the screen or on the sides if on landscape mode. The App Bar is 72 pixels high. The Application Bar always stays on the same edge of the display as the hardware buttons (Back, Start, and Search). Up to 4 icon buttons can be displayed in the App Bar but you could display down to 0 (zero) buttons if needed. If you don’t have icon buttons to display it’s better to switch to the Mini App Bar.

Windows Phone Page Structure
The App Bar is made out of the following elements:

Windows Phone App Bar Parts

Mini App Bar

In Mango, the Windows Phone team released a new mode for the app bar called Mini App Bar. The Mini App Bar is 29 pixels high. The goal was for this mode to release more pixels for developers/designers to use in their application when in many cases icon buttons were not needed and it was possible to condense required functions within the app bar menu space. This Mini App Bar would also enable us to use an App Bar in a Panorama, something that on the first release of Windows Phone wasn’t officially allowed. An option is to make Mini App Bar semitransparent (just the way you can do with a standard App Bar) if you want to let the content be visible. You can apply a 65% transparency to the Mini App Bar.

Windows Phone Mini App Bar

The App Bar is Flexible

Not every Panorama  (or Pivot or Pages for that matter) will require an App Bar. It will depend on your Information Architecture and content.  You can go from standard to minimized App Bar modes when going from Panorama panel to Panorama panel which means the user will see the bar rise or fall depending on the App Bar mode needed in that particular panel.

Windows Phone People Hub

Icon Buttons as well as sub menu options in the App Bar may change across different panels to accommodate the right functions needed for each panel.

Windows Phone Calendar App

Multistate Buttons in App Bars

A common question we hear is if we can host two or even three state icon buttons in the App Bar and the answer is yes. Two states could be enabled/disable and three states could be state 1/state 2/disabled. In all these cases it is important to portray the icon button state using the right icons. In general we want to preserve the same icon throughout the different states although in some cases when it makes sense you can slightly alter the icon to represent the new state or even change it completely. For example in the case of the Favorite icon (I don’t believe we actually use this example in Phone but totally valid).

Favorite Icons 3 States

Another example is for instance the SMS (Text Messages app) in Windows Phone - you will notice that if you press the + to send a new message the “send” Icon Button in the App Bar is disabled (because you have not yet typed anything). As soon as you type one character, the Icon Button goes from disabled to enabled state and you can now hit it. These are the subtle details that can really make you app nice and polished.

Windows Phone Enabled/Disable Icon Button App Bar States

App Bar Menu Items

Menu Items live in the App Bar and they are only visible when the App Bar is open or extended. Menu Items present tier 2 or second priority functions in your app.

It is important to consider that Icon Buttons and Menu Items should be seen as two different groups of functions. You have 4 open seats for Icon Buttons in the App Bar and in theory an unlimited number of Menu Items… although it is good to keep this from zero (0) to 10 items.

At the same time, note that you do not have to necessarily fill up the 4 seats you have available for Icon Buttons. You could decide to have only one Icon Button. You also could decide you do not need any Menu Items… zero. That’s just fine too.

One question/myth I’ve heard a few times is that you forcefully fill up the 4 seats available for Icon Buttons pushing the 5th function and beyond as Menu Items but as mentioned previously, Icons Buttons and Menu Items should be seen as two different function groups (not necessarily with continuity). So  if you realize you need two Icon buttons, and three Menu Items… that’s just fine.

Any Number of States in Windows Phone App Bar

Custom Usage of App Bar

Throughout the out-of-box experience in Windows Phone you will find some instances where the App Bar seems to be designed and working in a non-conventional way. The reality is you can define custom setups for App Bars as long as they help you address your particular user experience. An example of this is the Photo Camera which when expanded will show the Menu Items for camera settings on top and display the icon buttons for picking the camera flash mode on the bottom.

Windows Phone Camera App Bar

App Bar Colors

The out-of-box color in app bars is dark gray. This color remains while in a Light or Dark themes. This color is neutral and reliable for a number of scenarios. You don’t have to use that color all the time though. There are a couple other ways to setting the color for your App Bar. You can set these colors on the background color of the App Bar or in the foreground color of the App Bar (the Icon Buttons and Menu Items).

1 - Using the user accent color in the phone

2 - Using a custom color based on your brand

While all these are possible, freedom means responsibility J Remember we are talking about Metro here so we want to keep design clean. Usually you will find black and white color (defaults) for icon buttons work the best. For the app bar background itself the default gray will always be a safe bet but if you need to color the app bar for branding reasons, just make sure this color doesn’t make the white/black icon button invisible or hard to see (like making the app bar yellow will make the icon buttons hard to see).

Any Number of States in Windows Phone App Bar    Bad use of colors in Windows Phone App Bar

More Resources

In this section you will find some useful links to learn more about App Bar. There’s really good info about this control out there. Please drop me a comment if you have specific questions or scenarios and I’ll be happy to ask the team to give me ideas for me to share with you.

Page Structure - App Bar

App Bar on Orientation

App Bar Overview for Windows Phone

App Bar Design Guidelines

App Bar Icon Buttons

Jeff Blankenburg on App Bar



Next Post | #15 Designing Windows Phone Icons. In the next post we’ll cover Windows Phones icons in depth.

3 Responses to “24 Weeks of Windows Phone Metro Design | #14 Using the Windows Phone App Bar”

  1. Matthieu Narcisi Says:

    Another great article!

    I especially like your point of view and insight about the presence of the application bar inside a panorama.

    One thing is that when you say that we can customize the application bar for like a camera application; it is quite complicate to reproduce the whole control to create this effect. The existing control is not silverlight and is very optimized this way. I don’t now if it would be a good thing to create a new from scratch.

    There is also a functionnality that I saw only once with the application bar that I find nice, it is the effect produced in the mail app when you tap the answer button. There is a mini menu that is displayed (answer, answer all, forward) with a nice overlay on the rest of the screen. It really feels like an extention of the app bar. Like a sub menu of the button.

  2. WindowsDevNews.com Says:

    […] 31 Weeks of Windows Phone Metro Design | 14 Using the Windows Phone App Bar […]

  3. Windows8 Metro Design UI ref | IMAGINE_IDEA_& Says:

    […] Link: http://ux.artu.tv/?p=236 […]

Leave a Reply