Defining Your Application

October 21, 2011

Once you have decided on an idea for a Windows Phone application, you should define the tasks, pages, and navigation flow.

You Will Learn

  • How to define the user tasks for your application.
  • How to define the page and navigation flow.
  • How to start thinking about your data.

Applies To

  • Silverlight for Windows Phone OS 7.1

    Gg680257.17ca0e80-67a6-437b-99d1-5aa69e201a56(en-us,PandP.11).png

User Tasks

By thinking about the tasks the user can complete using your application, you will decide the features of your application. The following are some ways to get started designing your application.

  • Make a list of the tasks that users can complete.
  • Prioritize the list so that you know what you must implement and what you can leave for a later version.
  • If you are working on a team, have each individual list user tasks. Discuss as a team and try to group them.
  • Create sketches of the pages that your application might contain and how a user might navigate through them.
  • Play around with different existing Windows Phone applications to see what you like and don’t like.

Fuel Tracker is a sample application that is a companion for this documentation. Fuel Tracker enables a user to track the fuel consumption of his or her car. The following illustration shows the brainstorming and whiteboard that was done when the Fuel Tracker application was designed.

Gg680257.b48105e4-a88f-4c48-98be-6aadacfadd1b(en-us,PandP.11).png

The following is an example of some of the user tasks that were initially created when designing the Fuel Tracker application.

User Task

Priority

Enter fill-up information

1

Enter car information

1

View fill-up history

1

View miles/gal report

1

Enter data for multiple cars

2

Capture fill-up locations

2

Map of fill-up locations

2

Switch measure units (U.S. vs. metric)

3

View price/gal report

3

Pages and Navigation Flow

To implement your list of user tasks, you need to get more detailed about the pages and navigation flow. You can do this by creating a navigation prototype. You can start to think about how the pages might look, but you do not need to decide specific controls at this point. Your focus should be to create a navigation model that is natural for the user. The following steps describe one way to create a prototype.

  1. Create sketches that represent the pages of your application. Each page should allow the user to accomplish at least one task.
  2. Add navigation aids, such as hyperlinks, buttons or Application Bar buttons, to your sketches.
  3. Test the user navigation through your pages by using the navigation aids and the Back button.
Gg680257.note(en-us,PandP.11).gifCertification Requirement:
The Back button must be used correctly to pass certification. See section 5.2 in the Technical Certification Requirements.

Tip

If you have Expression Studio Ultimate, you can use the SketchFlow feature to create navigation prototypes.

The Fuel Tracker application contains three pages and a photo chooser. The following illustration shows the pages and navigation flow.

Gg680257.fd53a10c-8646-4310-af0b-b0bb9d05aae3(en-us,PandP.11).png

Try to keep your navigation model as simple as possible. Wheel-and-spoke models typically work better than "anything goes." When the Fuel Tracker application was initially designed, every page provided buttons to navigate to every other page. This caused the following problems:

  • When you navigate to a page by clicking a navigation button (as opposed to the Back button), a new page instance is created, even if you have previously visited that page. This is not an issue for read-only pages that convey information, but for data-entry pages, users expect any partially-entered data to still be there when they return.
  • When you navigate to a page and then press the Back button, users expect to go to the previous page. However, clicking the Back button from the first page should close the application. This is a little awkward if the user can navigate directly to the first page from any other page. For details on Back button certification requirements, see Section 5.2 in the Technical Certification Requirements.

To address these issues, Fuel Tracker was changed to use a navigation model where only the first page contains buttons allowing navigation to other pages, and other pages allow navigation only back to the first page.

In this model, the first page is reused, while the other pages are created each time they are visited. The other pages are data-entry pages, but because they are not reused, they are treated like modal dialog boxes. Users can either tap a save button to save any changes and navigate back to the first page, or they can tap the Back button to discard any changes and navigate back.

For more information on designing a navigation model, see Introduction to Application Structure and Navigation Models for Windows Phone.

Data Considerations

You should think about the data your application will use and how to organize it. You can start by making a list of the required data and trying to logically group it. The following table lists some of the data required by the Fuel Tracker application. This will help you determine the controls you need in the application and how you will pass data from the UI to the logic portion of your application. In Displaying Data with Data Binding and Creating Data Classes, you will learn more about how to display the data in the UI and create data classes for your application.

Group

Data

Car

Name

Photo

Initial odometer reading

Fill-up history

Fill-up

Date

Odometer reading

Quantity of fuel

Price of the fuel

Next Topic | Previous Topic | Home