Implementing Windows Phone Application Design

In this section, you’ll learn how to create mockups of your application.

The first stage of prototyping your design should start with pencil and paper, and move quickly to sketching on a PC. Sketching out an application for a mobile device is different than doing so for desktop software. Here, storyboards are less useful, since these applications have shallower navigation hierarchies and narrower scope. The challenge with mobile UI is presenting operations and data in an intuitive and dynamic way.

Wireframe sketch

If your application involves expert tasks, storyboard those individually to ensure they take place in as few (and as simple) steps as possible. The following is a series of prototype sketches of a generic streaming radio application.

1. Sketch the static screens that users will see or use the most. For example, the following figure shows preliminary drawings of the streaming radio application below. You’ll see mockups of the home screen, categories, the artist information view, and a list of favorite stations.

   

   Main screens

2. If your application will show certain transitory states to the user, sketch how these will look. In our example, if you are building a music player application, draw a view of the settings and splash screens.

   

   A few states

3. Sketch any important controls that you may customize. Think about how custom controls can be used to simplify your taxonomy of screens. This mockup shows detailed controls for playback, and a special landscape view with controls.

   

   Important controls

4. Now you can put together some of the screens as a sequence of steps to accomplish a task. Plan the steps that users will need to complete important tasks or operations. Draw in order the static screens that will be involved in each step of a task. The following figure shows a mockup that maps the flow of a search operation all the way through to the viewing of artist information.

   

   Common search task

   To accomplish this step, you need to first list all of the tasks that a user would accomplish with your application: for example, searching for a genre of music or adding a new station to your favorites list. You then draw a map for each of your identified tasks. These maps show the paths through the screens to accomplish a given task.

5. Try to sketch out the full relationship between static screens in all parts of your application. Strive to make related screens look and function in a way that creates a sense of progress as the user moves through a task. The following figure shows a full information architecture map of a simple streaming radio application.

   

   Master Map

   The master map is different than the task map. On the static master map, you are not showing the flow to accomplish a given task, but are simply showing every screen and the hierarchical relationship between them. In the preceding example, you can see that from the home screen you can get to the favorites, categories and search results screens.

   Once you’ve pinned some drawings to the wall, begin prototyping by opening a new project in Expression Blend. This document won’t cover how to operate Expression Blend, but you’ll want to create a new window (or page, for Microsoft® Silverlight®) to begin drawing.

   Note:
   When you prototype with Expression Blend, the attendant XAML code is written for you behind the scenes. This allows you to create working controls and styles as you iterate, and you can be sure compatibility won’t be a problem down the road. Prototyping inside Expression Blend also ensures that the best features of your mockups are fully reproducible in the final designs.

Mobile applications can be prototyped rapidly by selecting specific areas of focus. It’s not generally necessary to prototype every aspect of your application to a high level of detail. Choose what is most important or most challenging and focus your prototyping there. Typically, a designer should prioritize new technologies or functions, or anything that departs from the usual expertise of the development team.

For most applications, this means mocking up tasks or operations that present value to the user. Consider the statements of purpose you envisioned for your application. Prototype them as you imagine them happening, step by step, and note where custom controls can reduce steps or otherwise speed things up.

In general, bringing an application from the web or another platform to Windows Phone requires application screens to present fewer controls and graphics and cut clutter. It also may be necessary to distribute tasks throughout several screens in a taxonomy that makes sense, whereas on the web, controls are more likely to be nestled together in large groups. Be sure you are aware of whether you need to scale up graphics, content, or photographs that your application will feature. Be sure to prototype with native controls, and as few WebBrowser controls as possible.

Decide ahead of time how many iterations are practical.

Generally, creating more than a few iterations of a prototype only brings diminishing returns. Prototype just a few times. Building a testable version of your application is a far more effective way to identify areas in need of improvement.

In order to prototype rapidly and move on to building, decide which elements of your application deserve top priority as you iterate. This involves deciding how deeply you will prototype the following parts of your application:

• Level of Visual Detail

  If art and appearance are top priority to the stakeholders of this application, then be sure to create a highly detailed series of drawings of features, functions, screens, or states. You should also mock up custom controls and their states.

  Note:
  Mocking up custom controls in Expression Blend will ensure that they function in XAML.

  Visual detail mockups should include:

  1. Styles and Themes

  2. Splash Screen

  3. Application Tile

• Level of Functional Detail

  Are functions or features the centerpiece of your application? If so, you may want to build a prototype that is interactive and semi-functional. Start with a static screen, or group of static screens, and build interactions between them, one by one. Consider how to streamline functions and reduce controls or the necessity for input.

• Level of Content Detail

  If the stakeholders of your application are primarily concerned with presenting content, you may want to decide how to create the most accurate placeholders possible while you build your UI. If your content is text, mock up your designs with serious attention to typography and use filler text, not blocks or other abstractions, to represent where content will go.

  If your application is going to present visual media, you may want to add paper and pencil back into the prototyping process. Draw detailed sketches of your application’s content as it would look during playback, and include both landscape and portrait orientation in your drawings. Remember to consider customizing your controls or changing their layout when orientation changes.

  If you are planning to localize your application, then this is where you would want to make sure to allow adequate room for languages that require it and also to prepare for globalization issues. There are other references you can read to understand localization and globalization issues.

• Level of Branding Detail

  If you are building your application for commercial purposes and branding is managed, make comprehensive, branded visual prototypes with granular attention to detail. This ensures that your final product will not diverge from the company’s standard colors, layouts, and logos.

Custom visual elements can impart a quality, originality, or branding in an application. Decide ahead of time how much of your application’s visual design will be customized, and plan those elements accordingly. It can be difficult to introduce custom art and branding later in the application design process.

Some elements you should customize are themes, templates, controls, and styles.

Whenever customizing visual elements in Windows Phone, use the following guidelines:

Favor Practical Operation over Realism

Generally speaking, applications should not have custom controls that seek to mimic real life. For example, the FM Radio feature in the preloaded Zune application does not use a dial, knob, or series of buttons to control the choice of station. Instead, it uses a slider control to adjust the frequency, a Play/Pause button to toggle the radio on and off, and a Favorites button to save preset stations.

FM Radio in Windows Phone

In the interest of practical use, it’s also wise to fade out or remove some or all controls, the Application Bar, and the Status Bar when your application is displaying content or gameplay in full-screen mode.

Plan Interaction of Custom Controls in Groups

To achieve consistency and reliability in an application with custom controls, take care to ensure that your application contains an underlying design style where symbols, shapes, words, and colors have consistent meanings.

If you plan on presenting groups of interrelated custom controls that affect one another, take care to ensure that all possible combinations of controls make sense and operate in the intended way.

If practical, draw out possible interactions between custom controls to ensure that all the possible operations are reasonable. If some combinations force confusing scenarios upon the user, use an alternative design.

• Does your application design make it obvious how it employs Windows Phone hardware?

• Are your application’s tasks going to be comfortable to operate?

• Will your application present too much information or functionality? Too little?

• Does your application allow the user to perform tasks or operations that they would find valuable?

• Are you coming from another mobile platform? Windows Phone users will expect fewer taps, clearer views, large typography, and the use of contrast and color.

• Are you using both axes of scrolling (that is, the X and Y axes) and orientation (that is, Portrait and Landscape)? Depending on the purpose of your application, users may expect both.

• Can fingertips easily operate controls? Is control text legible?

• Does your UI give feedback on touch and progress?

• Have you accounted for use of the hardware Back button?

• Do you use embedded web content (and the WebBrowser control) sparingly?

• Does your application fade out the Status Bar, Controls, and Application Bar when in full-screen content playback?

• Do you use Pivot and Panorama controls effectively and correctly?

Once you have mocked up custom UI elements, be sure to test them yourself. If you’re working in Expression Blend, you can actually verify that your controls are working in XAML, using the code that the application writes for you in the background as you design

As soon as you begin prototyping, find a small group of trusted people in your application’s target audience. As soon as you are comfortable, begin showing prototypes to your trusted users. Don’t explain how they are supposed to work; merely wait and see how easily the user understands what your application does, and how it operates.

Note:
In general, use mockups with visual detail for early user testing, instead of wireframe drawings. Wireframe drawings do not create an accurate simulation of user experience.

If you are designing an application for business, be sure to test the needs and priorities of managers and non-experts in addition to your target users. For example, project management software should be useful to the people working on a project, as well as by their superiors who may want to use your application to check the progress of a project.

Note:
Don’t fall prey to users’ requests for more and more features. While some user feedback may alert you to severe UI problems, most user feedback should generally be absorbed holistically. Keep your application focused and minimal. Remember that users are often better at articulating their goals within an application than making specific suggestions about UI or interaction.