You are the developer. You want users to want
to use your applications. That means you must deal with the different
ways the phone can accept user input. Developing for the Web or desktop
means you are primarily dealing with designing for the keyboard and
mouse. But when developing for the phone, you have to change the way you
look at input and consider that the user is going to interact with your
application in different ways. Interaction patterns for the phone
include touch, keyboards (hardware and software), hardware buttons, and
sensors.
Designing for Touch
The UX design language for the phone is
specifically constructed to make sure the interface is treating touch as
a first-class citizen and that the interface requires no training
(i.e., is intuitive). By building a design language that defines the
elements of a touch-based interface, Microsoft has made it easier to
build such interfaces. The design language includes guidelines for what
touch gestures are supported, as well as how to space and size elements
for finger-size interactions. Figure 1 shows an example from UX design guide that defines the minimum sizes for touch points and their spacing.
Figure 1. Windows Phone’s interactive element sizes
The Windows Phone also defines the types of
interactions (e.g., touch gestures) the device supports. Most of these
interactions are well-worn gestures that have been the vocabulary of
other touch devices such as the iPhone, Zune HD, and Android. These
interactions include
• Single touch:
• Tap
• Double-Tap
• Pan
• Flick
• Touch and Hold
• Multitouch:
• Pinch/Stretch/Rotate
In addition to specifying the types of
gestures, the Windows Phone specifies the use cases for each
interaction. For example, the Double-Tap interaction is specifically
used to zoom in and zoom out. This use case is explicitly different from
what the typical desktop Windows developer might expect. But for the
sake of consistency, the UX Design Language maps out what the user
should expect with these interactions. While the design language would
not be read by actual users, it would be the basis for the phone’s
built-in application. Interactions of your applications should match the
rest of the phone, therefore adhering to the principle of least
surprise for the user. This also hints at the reality that the phone
design is not supposed to be based on users’ expectations of how Windows
works, but be more obvious than that. The touch interaction is much
different from a mouse, and the overall hope (as far as I can tell) is
to help users get a feel for the right interaction without training
them.
Hardware Buttons
Windows Phone requires that each phone
has three hardware buttons on the front of the device.These three
buttons have discrete actions. The only one you really need to concern
yourself with is the Back button. Not only should the Back button move
the user from your application to the last running application (the
default behavior), it should also allow the user to move from state to
state in your application. As you develop applications for the phone, be
aware of what the user might expect from the Back button. Taking
advantage of this can make your application even more intuitive.
Keyboards
Since not all interactions will be
simple gestures but must be able to support text entry, the UI Design
and Interaction Guide stipulates that a software keyboard (or Soft Input
Panel or SIP) should be available for every text entry (as even in a
keyboarded phone, users should be able to type on the screen). Keyboards
are provided by the operating system by default. As users attempt to
edit text (e.g., the user taps on a text box) the operating system
displays a software keyboard to enable touch-based keyboard entry. Figure 2 shows the default keyboard.
Figure 2. Default keyboard
The style guide also specifies that the
keyboards should be contextually relevant depending on the type of text
to be typed. For example, Figure 3 shows an email keyboard and a phone number keyboard.
Figure 3. Contextual keyboards
While there are a number of layouts, the phone includes some standard layout for specific use cases, as shown in Table 1.
Table 1. Sample Keyboard Layouts
Sensors
You should consider that not all the input to
the phone is typical. It is important that you, the application
developer, open your mind to different types of input. Windows Phone
supports a number of sensors that will allow you to take input in these
different forms (see Table 2).
Table 2. Sensors
