Microsoft has pushed an idea it calls “three screens and a cloud”1
since the earliest announcements of Windows Phone (and possibly
before). Essentially this is the idea that an application or service
should support three fundamental user experiences: computer, TV, and
phone. While this idea of three screens that are all supported by a
common infrastructure has evolved (e.g., are tablets considered phones
or computers?), it still represents a strong story for you to determine
what your phone applications should allow the user to do.
Your job in designing the experience for the phone involves more than
fitting your Web/desktop experience onto the small screen; it really
involves crafting what a user will want to do on the device. For
example, let’s assume you work for a bank. Should the phone experience
include doing things like downloading bank statements? Probably not. But
users will want to be able to check balances and perhaps see
several days’ worth of transactions. The Web story for your application
may be very feature-driven, whereas the phone version should pick and
choose the right experience for the form factor and use cases.
But the experiences you think about are not just a subset of Web
experiences; they might be very different. Consider the Foursquare
website (http://foursquare.com) shown in Figure 1.
Figure 1. Foursquare.com
The user experience on the website is more heavily geared toward
seeing the status of a user; seeing the mayorships, history, and badges
is a common task on the website. As a user, I might also be interested
in some of the additional data presented to me in this larger format. In
fact, there is quite a lot of functionality here that I may be
interested in. But just how much of this is interesting on a smaller
device? The user’s attention span is hampered on a smaller device, so
deciding what a user will do (and how long the user is expected to stay
in your application) becomes crucial to a successful third screen for
your offering. Let’s take that site and see how the phone screen might
help us pick some functionality (as shown in Figure 2).
Figure 2. Phone-sized app
The problem with this approach is that it’s unlikely that picking a
phone-sized part of the app would make much sense. Your next thought may
be to try to pack all that functionality in with a panorama application
(as shown in Figure 3).
Figure 3. Panorama application
While Windows Phone would allow this, it’s important for you to look
at what your third screen will be used for. How long do you expect users
to work with the application? Even if users want all that
functionality, is a large scrollable app the right idea? When I look at
Foursquare, I am most interested in check-in (something that is an
uncommon task on the website) and seeing where my friends are checked
in; the rest of the functionality is purely “nice to have.” In fact, the
official Foursquare application for Windows Phone2 decided
on this mix of this a standard Windows Phone paradigm by going with a
Panorama application but focusing exclusively on the places you visit
instead of an all-in one approach (as shown in Figure 4).
Figure 4. A sample Foursquare on Windows Phone
Determining the right experience for your users is your first
challenge. Once you have a sense of what you should accomplish, the next
challenge is to create an application that works well on a device.
It Is a Phone, Right?
Developing the right strategy for determining what your application
does is only half the battle. The other half is to understand that you
are working with a phone. Why does it matter that you’re writing for a
phone? It matters because the hardware, performance characteristics, and
usability are completely different from a desktop or website. For
example, the Application Certification Requirements for the Windows
Phone4 has limitations about consuming memory.
Memory Consumption
The Application Certification Requirements
specifically say “The application must not exceed 90MB of RAM usage,
except on devices that have more than 256 MB of memory.” Since you can’t
dictate what devices it’s available on, you must be ready to test for
the memory in you’re app. The DeviceExtendedProperties
class can be used to query the amount of memory on the device and modify
the application behavior at runtime to take advantage of additional
memory. For more information, see the DeviceExtendedProperties class in MSDN.
Memory Consumption
The application must not exceed 90MB of RAM
usage. However, on devices that have more than 256MB of memory, an
application can exceed 90MB of RAM usage. The DeviceExtendedProperties
class can be used to query the amount of memory on the device and
modify the application behavior at runtime to take advantage of
additional memory. For more information, see the DeviceExtendedProperties class in MSDN.
Therefore, you will need to design your application to work well within limitations on a number of fronts:
• Limited screen real estate
• Limited CPU speeds
• Limited battery life
• Limited memory
• Completely different input mechanism (e.g., touch versus mouse)
If you’re a seasoned mobile developer, none of this is new to you.
But if you’re a developer who is coming from the Web or desktop world,
you have to change your thinking substantially to fit your applications
onto the phone. You will need to start with a clean slate and think
about resources in a whole new way.
In addition, on the phone users run apps for very different
reasons and expect very different experiences. Typically an application
(not necessarily games) is run frequently, but for very short periods of
time. And the user experience is very touch-driven instead of keyboard-
and mouse-driven. Designing an application to meet this different set
of requirements means you really need to dig in to how you expect the
application will be used.
