This is the first of a series of articles that shows you how to build a fuel tracking application using Microsoft Expression Blend for Windows Phone.
You can download the sample files for the Fuel Tracker application to use as you follow along with the procedures in this series.
This series is based on “Developing a Windows Phone Application from Start to Finish,” a tutorial for creating a Windows Phone app using Visual Studio 2010 Express for Windows Phone.
Where appropriate, links to related resources from the Windows Phone Design Guide will be available to give you more information about certification requirements, design tips, and best practice guideline.
Defining your application
You have an idea for a Windows Phone app? Great! Now, where to begin?
While it may be a cliché, the best place to start is at the beginning.
Think about your app idea, and what you want people to be able to accomplish using your app. Think about the tasks that your user will need to be able complete in order to successfully use your app.
Brainstorming is a great way to get started. Lists, sticky notes, sketches on paper or on a whiteboard, are all great ways to begin. After you have created the list, you can start prioritizing and grouping the tasks so you have a better idea of what is essential to your app, and which tasks are related to one another.
After you have a solid idea of the types of tasks you’ll need to include and how they might relate to one another, you can start to outline some simple navigation that describes how a user might move from one task to the next.
After you have a good idea of how you think users might be able to navigate your app, you can design the visual details of the app so your app is as nice to look at as it is to use.
The following sections will describe the process of defining the idea for a fuel tracking application.
Making the list
When thinking about an app that tracks fuel consumption and mileage, there are a variety of tasks that you might want to include. For example:
- Enter fill-up information
- Calculate miles per gallon (MPG)
- Include support for multiple vehicles
- Track gas station locations
- Track price per gallon (PPG)
- Support both imperial and metric units of measure
- Enter detailed car information (make, model, year, etc.)
- Map of nearby gas stations
- View fill-up history
While there may be additional tasks that may come to mind, this list accounts for most of the tasks the average user will want to be able to accomplish with a fuel tracking app.
Prioritizing the list
While the list of tasks may be a useful place to begin, it is worth revisiting the list and determining what the priorities are for the app that you want to create. You may not want to eliminate any of the tasks. However, you may want to consider which tasks are the highest priority tasks, and use those tasks as the foundation of the first version of your app. Additional tasks that are not
essential, but “nice to have” can be given a lower priority and then implemented as enhancements to your existing app at a later date.
For example, if you were to assign values of 1 through 3 (1 being the most important, 3 being the least important) to the tasks in the list, you might find that some of the tasks are absolutely essential, and that other tasks can wait for future versions of your application.
After assigning values to the task list above, you might have a list that looks more like this:
- Priority 1
- Enter fill-up information
- Enter car information
- View fill-up history
- View MPG report
- Priority 2
- Enter information for multiple cars
- Track gas station locations
- View a map of gas station locations
- Priority 3
- Switch from imperial to metric
- View PPG report
Grouping the tasks and defining the pages
Now that you’ve prioritized the tasks, you can consider the details for each task. Those details will help you group the tasks and define the pages that will help complete those tasks.
For example, “enter fill-up information” is a high priority task. What information is included in “fill-up information”? Typically, fill-up information includes the date of the fill up, the odometer reading, the number of gallons purchased, and the price per gallon.
Similarly, think about what information is included in “car information.” You will want to include the make, the model, and the year. In addition, you may want to add the ability to include a photograph of the car.
In addition to the technical aspects cited above, you might have realized that fill-up, fill-up history, and summary are all interrelated pieces of information, and might be appropriately grouped on one page. It is worth noting that is a lot of information for a very small screen, an issue we will return to in the next section.
You might have also noticed that many of the other pages are only needed rarely, and for very specific circumstances. For example, you might only add a photo once, so the photo chooser page really doesn’t need navigation to all of the other pages. Similarly, you might review the car information very rarely, and again you probably don’t need navigation to all of the other pages.
Taking all of this into consideration, a final list of high priority app pages and the associated information might look like this:
- Main Information about the most recent fill-up, a history of previous
fill-ups and snapshot summarizing the overall MPG statistics for the car. - About More information about the app, including copyright and author(s).
- Fill-up Input for current fill-up, including date, gallons, price, and
odometer reading. - Car details More information about the car, including make, model, year, and
photo. - Photo chooser A page for selecting the photo that you want to use.
Navigation models and navigation flow
Now that you have more details about the five individual pages and what kind of information each page will contain, it’s time to start thinking about navigation models and how to navigate between the pages. You do this by creating a navigation prototype.
While you might want to think about how the pages might look, you do not need specific visual design information or controls at this point. Your focus is to create a navigation model that is maximizes the ease of use.
The following steps describe one way to create a prototype.
- Create sketches that represent the pages of your application. You can use
stick notes, drawings on a white board, pieces of paper, or other quick and easy
tools. If you have Microsoft Expression Blend + SketchFlow, you can use
SketchFlow to create the sketches.
Note: Part 2 of this series will show you how to create your prototype using
SketchFlow. - Using your tool of choice, add models of navigation aids, such as hyperlinks,
buttons or Application Bar buttons, to your sketches. Again, you can draw these
aids, or use sticky notes to represent the controls. - You can begin to test the navigation through your pages by thinking through
how these aids might facilitate navigation, and what, if any, additional
navigation aids might be helpful or where information from two pages might be
made available on one page to minimize clicks.
In beginning the process of designing the navigation flow, you might think that
you want to include links on every page to every other page of your app.
However, when you get to the real-time testing of this navigation model for the
app, you are likely to encounter the following issues:
- When you navigate to a Windows Phone page by clicking a navigation button (as
opposed to the Back button), a new instance of the page is created, even if you
have previously visited that page. Although this isn’t an issue for read-only
pages that only convey information, it is a problem for data-entry pages,
because if a user navigates away from a page, and then returns to it, any
partially-entered data will be gone when the user returns. - When you navigate to a page and then press the Back button, you may expect to
go to the previous page. However, clicking the Back button from the main page of
the app should, by design, close the application. This may become awkward if the
user can navigate directly to the main page from any other page, including the
photo chooser.
Tip: Information regarding Back button certification requirements for Windows
Phone app is available in Section 5.2 in the Technical Certification
Requirements.
To address these issues, the fuel tracker was modified 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 addition to the navigation challenges described above, there is also the problem of how to easily convey a great deal of information on the main page despite having such a small space in which to present the information.
You can use a Pivot or Panorama control for the main page, which provides easily accessible space for additional information without having to create separate pages. You navigate a Pivot control by using tabs. To navigate through a page built using a Panorama control, all you have to do is swipe the screen with your fingertip to access the additional information.
By creating a central hub (the Pivot or Panorama control) that links to additional information, you can create a wheel and spoke style navigation (a central point with navigation “spokes” out from the center). The Windows Phone User Experience Design Guidelines describe this navigation model as a central application hub.
For more information on the central application hub navigation model, see Central Application Hub with Home Page Menu (Panorama or Pivot Control) for Windows Phone on MSDN.
For more information on designing a navigation model, see Introduction to Application Structure and Navigation Models for Windows Phone on MSDN.
In this model, the main page (App hub) and the About page are reused (a single instance of the same page), while the other pages are newly created each time they are visited.
The Fill-up, Car details, and Photo chooser pages are data-entry pages. Because they are not reused, they are treated like modal dialog boxes. Users can either
tap a save button to save any changes and then navigate back to the first page, or they can tap the Back button to discard any changes and navigate back to the
main page.
Data
Now that the navigation model has been chosen, it’s time to think about the data your application will use and how to organize it.
Start by making a list of the data that is essential to your app and logically grouping it. Understanding what data you need will help you determine the controls that you will use in the application and how to pass the 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.
The following list includes some of the data required by the fuel tracker application.
- Car
- Name
- Photo
- Initial odometer reading
- Fill-up history
- Fill-up
- Date
- Odometer reading
- Quantity of fuel
- Price of the fuel
Conclusion
Now that you have a plan, you can build a functioning prototype of your plan by using Expression Blend + SketchFlow. Part 2 will show you how to use the Windows Phone templates to create an interactive SketchFlow prototype of the fuel tracker app.