I’ve been doing Windows Phone development on and off for the past couple of years. In fact, I recently published the first version of my application “Snap Receipt” to the Windows Phone Marketplace. It’s an easy way to get receipts from your phone into Concur’s expense reporting system. You can check it out here. During my experiences with Windows Phone development I’ve identified 10 essential things developers need to know if they’re going to starting writing code against the platform. I thought I’d take some time to share them with you over a series of posts. Please note, these posts refer to Windows Phone 7.0/7.1. I have yet to see any developer bits for Windows Phone 8, but it is my hope that many of the principles I discuss in this series apply to the new platform as well.
In my last post in this series I discussed the Windows Phone navigation model. In this post I’ll take a look at the Windows Phone Application Bar.
What is the Application Bar?
Let’s start by answering the question, “What is the Application Bar?”
The ApplicationBar is a built in toolbar for your Windows phone applications. It’s displayed as a row of icon buttons along the bottom of the phone’s screen. The goal is that the buttons are to provide users with quick access to your application’s most common tasks – for example, save, edit, and delete.
In addition to the row of buttons, you can also expose additional actions to the Application Bar by text-based menu items. These items are displayed in a list that slides up from below icon buttons when the ellipsis to the right of the buttons or the empty space to the left of the buttons is pressed. It’s not hierarchical, in that the menu item list is not considered to be a submenu of any of the icon. Instead, the menu items are used for application actions that are less frequently used and for actions that are difficult to convey with an icon and therefore require a textual representation – for example, maybe you want the use to be able to adjust the space between the lines in text they may be entering. The animations used by the application bar for displaying and hiding menu items is built in.
One other thing to note is that the Application Bar automatically adjusts when the phone changes orientation. When the phone is rotated from portrait orientation to landscape orientation, the Icon Buttons are displayed vertically in a bar on the side of the screen.
It is important to know that the ApplicationBar is not a Silverlight control. Which means you can’t perform some of the common control features, such as databinding, when working with the Application Bar in xaml. This happens implications for localization which I’ll touch on a little later.
Why Should You Use It?
Now that you have an idea, you may be asking yourself, “OK, but why should I use it?”
While you could create your own toolbar and menuing system, one of the goals of the Windows Phone platform is provide a consistent user experience across ALL applications on the device. The application bar enables you to do just that while also providing the necessary animations and rotation support so you don’t have to do a lot of heavy lifting.
Considerations
When it comes to using the application bar there are some things you need to take into consideration before implementation. These considerations can be grouped into three main categories
- General – considerations that apply to the Application Bar as a whole
- Color – Unless you have a very compelling reason for NOT DOING SO, you should use the default system theme colors for the Application Bar. Using custom colors for the can affect display quality of the button icons, and can cause unusual visual effects in menu animations.
- Opacity – You can be very granular when controlling the opacity of the application bar, but it is recommended that you only use opacity values of 0, .5, and 1. Using values other than these may result in less than desirable affects in terms of display quality.
- Navigation – You should not use an icon button or a menu item for navigates backward in your application’s page stack. All Windows Phones are required to have a dedicated hardware Back button. Providing your own mechanism for navigating back is unnecessary and could result in confusion, providing a less than desirable user experience.
- Buttons – considerations that apply to the icon buttons
- Color – When it comes to icon buttons, the image used for the icon should have a white foreground on a transparent background. This will enable the application bar to colorize the icon according to the user’s currently selected theme. Using images that deviate from this guidance, specifically colored icons, can result in poor and unpredictable display quality .
- No Circle – When you see sample applications, or applications running on your actual device that make use of the application bar, you’ll notice that each icon button has a circle around the icon. This circle is drawn by the application bar and should not be included in your image.
- Size – The image should be 48 by 48 pixels in size, with the white foreground image fitting in a 26 by 26 pixel area square in the center of the image. This will ensure that it does not overlap with the circle that is drawn by the application bar.
- Meaning – Most importantly, make sure you choose images that have a clear meaning to the users of your application. You’ll also want to ensure that if your application is supporting multiple cultures that you choose images that convey the appropriate meaning in a given culture.
- Menus – considerations that apply to menu items
- Number of items – You’ll want to try not to have more than five items in your menu. If you have more than five items the user will have to scroll, which will lessen the user experience.
- Casing – Regardless of the casing you specify for your menu items, it will be converted to all lower case at run time. This is done to provide a consistent user experience across the device and platform as a whole.
- Length – Finally, you’ll want to make sure that the text is not so long that it will run off the screen. Typically, if you keep your text limited to between 14 and 20 characters you should be ok.
Localization
There’s one additional consideration I want to touch on when it comes to the Application Bar, and that is localization Localization is the process in which you translate your application’s UI (i.e. textblocks, messages, etc.) to make it suitable for another region. In a typically xaml based (i.e. WPF or Silverlight application) you would accomplish this by using databinding in your xaml to bind to a resource file that contains the appropriate translations. However, as I mentioned, earlier, the application bar is not a Silverlight control, and as a result, cannot participate in data-binding. As a result, in order to localize the application bar, you’ll need to construct it in code as opposed to xaml.
That’s it for the Windows Phone Application Bar. Next up we’ll look at how to work with isolated storage.
Previous posts in this series
Hey there! My name is Adam, and I'm a Technical Evangelist at Microsoft where I spend time focusing on Windows, Windows Phone, and Windows Azure.