The Windows Phone style (i.e., Metro) makes some specific
recommendations about several styles of applications that look like the
rest of the phone. When you design your application you will have to
look at these styles and determine if any of them make sense with your
application. Alternatively, you can just start from scratch and create a
new workflow for your application without regard for Metro. While these
application styles are typical, it is not a requirement that your
application follow any of these usability paradigms. In fact, some of
the built-in apps already do this (e.g., Music and Video).
Much more typical than having a single paradigm for your application
is to determine the right mix of these UI metaphors to use in your
applications. All Windows Phone applications use a navigation pattern in
which you can have multiple pages that support the Back button on the
phone. This pattern should match users’ expectations as it is borrowed
from the Web pattern. A simple app may be made up of several different
pages that can be navigated to and from. For example, Figure 1 shows a simple blood sugar monitoring app that mixes the different paradigms.
Figure 1. Sample application navigation
When you look at the design of your application you will need to
consider the different ways to create individual pages using the
different styles of control, but you should never get away from the idea
that Windows Phone revolves around page navigation. Of course, you can
build your application as a single page, but that would likely be a very
simple application, such as the Moon Phaser app shown in Figure 2.
Figure 2. Single-page Windows Phone application
Let’s look at some of the page design styles.
Panorama
The basic construction of the panorama page is an endless canvas of
several panes. For example, let’s take a simple application with a
couple of different parts of the application, as shown in Figure 3.
Figure 3. Sample panorama application
This page will have two pieces of functionality (“first item” and
“second item”). The panorama will show the first pane and hint at the
second pane. So, this application in the emulator will look like Figure 4.
Figure 4. Panorama in the emulator
In the emulator you can see that the first pane is shown, but it also
hints that there is more to be seen. If the user swipes to the left (to
move to the right), the second piece of functionality appears. While
the user is on the second pane, the first pane is shown again as a
preview on the right. This is the magic of the panorama in that it
implies an infinite canvas for the different parts of the application.
This avoids the typical problem you would have with applications
composed of several parts (or panes), and having to develop a way to
navigate to them. The background image also is stretched over the panes
and slides along with the panes (though at a different speed to give a
parallax look to the control). Although this example shows two panes, it
is common for a panorama to have more panes. The general rule of thumb
is that you should use no more than five panes for a panorama.
Many of the built-in applications use the panorama style to enable
different parts of their functionality (e.g., People, Images, Music, and
Video). It may be seductive to try to make your application use a
panorama since other parts of the phone use that style, but you should
only pick this type of application when you really do have multiple
pieces of separate functionality. Each pane of the panorama is not meant
to be a master-detail type of page.
Pivot
Originally designed for Zune (the software and the device), the
pivot-style page is a key style that you will see on Windows Phone. It
is used in the Music picker (in the Music and Video section) and is a
common way to think of displaying the same information in different
“views” (i.e., by artist, by album, etc.).
The pivot is similar to the panorama, but use of the pivot is more
straightforward. The pivot is also based on the idea of an infinite
canvas, but unlike the panorama, the pivot is made of individual tabs
and does not require that the next pane shows as a preview. The user can
either swipe or click on the headings (the next heading is previewed)
to move to that pane. Figure 5 shows a typical pivot application.
Figure 5. Pivot example
With the pivot, each pane takes up an entire page. The pivot works in
a lot of places where a panorama would be too large and cumbersome. The
biggest difference between a panorama and a pivot is that the pivot can
handle a larger number of panes. As stated earlier, a panorama
application really should be no more than five panes. You can use more
than five panes in a pivot, but you cannot use an unlimited number of
them; in addition, you should have a very good use case to use a lot of
pivot panels.
The pivot style of application is a good choice when you have the
same or similar data that needs to be displayed in different views. For
example, in the blood monitoring app, where there is a pivot each page
shows the data from the first page in different ways (different graphs
or just a list of the data), as shown in Figure 6.
Figure 6. Pivot pages
While the basic metaphor is about showing the same information in
different ways on the pivot, you are ultimately in control and could
have different functionality on each pivot page. What is important is to
not surprise your users.
Common Mistake
You should never use the Panorama and Pivot
controls for master-detail interfaces (e.g., one pane used for
selection and the rest of the panes used for details of the selected
item)
Common Mistake
You should never use the Panorama and Pivot
controls for master-detail interfaces (e.g., one pane used for
selection and the rest of the panes used for details of the selected
item).
Simple Pages
Sometimes the different page styles just get in the way.
That’s where typical pages come in. While Microsoft is encouraging some
design paradigms with the Metro style, it is not required that you pick
one of them. Whether you’re building a news application, a casual game,
or even a custom video player, you can build it the way you want. The
Metro design language should be your guide and should not deter you from
creating the application that users will love.
