| Designing Windows Mobile 5.0 application UIs |
by Mauricio I. Perez (Jan. 31, 2006)
Foreword -- This techical whitepaper by a Microsoft Technical Account Manager discusses the considerations, guidelines, and standards that software designers and developers should take into account when designing software for Windows Mobile 5.0 Pocket PCs and Smartphones.
The author begins with a review of how the user interface (UI) of Windows CE-based devices has evolved since the first Pocket PC device was introduced in 1998. He points out the distinction between a "Pocket PC," which is intended to be used with two hands, and the "Smartphone," intended for single-handed use. This necessitates a different approach to UI design.
Following a summary of the new UI features in Windows Mobile 5.0, the article launches into the heart of the issue -- suggested design rules and guidelines. The proper use of soft keys, dialog boxes, and notification bubbles is covered in detail. Finally, screen orientation and the problems of multiple resolutions are covered.
Designing user interfaces for Windows Mobile 5.0-based applications
Recommendations and guidelines for software developers and UI designers
by Mauricio I. Perez, MCAD
Microsoft Corporation
Introduction
The user interface of Windows CE based devices has evolved over time. 1998 was the year when Microsoft introduced the first device with the form factor of the Pocket PC we all know: the Palm-Size PC. This first UI (user interface) was characterized by its abundant heavy borders. Text presented in the screens did not have hyperlinks, and in this first approach, designers tried to cram the desktop UI into the small screen of the device. In 1999, the second version of the Palm-Size PC introduced hyperlinks in its text.
Figure 1. The 1998 Palm-Size PC UI
After realizing that a device that would fit in a pocket was not the same as a desktop computer, the UI was redesigned. In 2000, the device now called Pocket PC added color, but the UI didn’t suffer a relevant change yet. In 2001, the UI presented a background that could be customized by the user.
In 2002, the first version of Smartphone was introduced, with a new UI designed for a device that would be operated with a single hand, as opposed to the Pocket PC that is designed to be used with both hands.
The UI continued evolving in Windows Mobile 2003, and in Windows Mobile 2003 Second Edition, it introduced the square screen and the landscape mode.
Figure 2. The Windows Mobile 2005 Pocket PC UI
The UI of Windows Mobile based devices continue to evolve in a convergent fashion. The addition of keyboards to both the Pocket PC and the Smartphone provide similar and friendlier user experiences in two devices that were intended originally to be used in a different way, as we explained before, the Pocket PC with two hands, and the Smartphone with one hand. As we will see in the next section, the Pocket PC has now one of the features that were unique to the Smartphone: the Soft keys. This convergence of user experiences should not be ignored by designers. One of the goals of the software industry, especially software targeted to vertical markets, is to build applications with an extended life cycle. Designers must think in the future, and at this point, the rule of thumb to keep in mind by all designers and developers is to think of their designs with the two platforms in mind. In a word: design software for both the Pocket PC and the Smartphone.
The Pocket PC and Smartphone UIs
Before entering the discussion of the new features in the Windows Mobile 5.0 UI and the design guidelines and recommendations, let’s review the characteristics of each of the two Windows Mobile devices.
 | The Pocket PC - Touch screen
- Larger display
- 2D layout
- Software Input Panel
- 96 and 192 DPI support
- Multiple connectivity configurations
- The device sleeps
|  | The Smartphone - No touch screen
- Smaller display
- Vertical list UI
- The UI is optimized for single handed use
- Numeric pad input
- 96 and 131 DPI support
- Always on
- Slower storage
- Slower CPU
|
The Windows Mobile 5.0 User Interface
We have reviewed the history of the Windows Mobile UI and the main characteristics of the Pocket PC and the Smartphone. Let’s describe now the new features presented by Windows Mobile 5.0
Extensible title bar icons
Pocket PC and Smartphone
Title bar icons are used to show critical information to users at all times, such as new messages, battery level, and signal strength. In the event that an operator requires an icon to represent, for example a network service or device state, an OEM (original equipment manufacturer) will be able to add that icon to the system in an architected way and have it show up on the title bar in conjunction with priority logic for that spot in the user interface. This is how OEMs have been able to add 3G icons for connectivity to 3G networks.
State management and notifications
Pocket PC and Smartphone
Developers have now a simple, lightweight system to read system information (for example, "in phone call") and read or store their own status. In addition, this feature allows notifications on status changes. This was difficult to do in Windows Mobile 2003. The new system has been unified across the Pocket PC and the Smartphone.
Open appointment from reminder
Pocket PC and Smartphone
Windows Mobile-based Pocket PC reminders UI has been completely updated to be better aligned with the look and feel of the device. The reminder shows now more information (including meeting location) and is hardware navigable. Few minor UI fixes were made to the Smartphone as well. When a reminder goes off, the user will be able to open the appointment directly from the reminder. One of the main scenarios for this is looking for some "location" when a reminder goes off. Until now, and for security reasons, the reminder does not show the location, so it is very common to navigate to the appointment just after a reminder goes off. Also, the reminder must be dismissed and then the user has to navigate to the Calendar using some other mechanism.
Title bar and soft keys visual refresh
Pocket PC and Smartphone
Users will see a softer and friendlier user interface that better aligns with the Windows Mobile branding. Personalization will allow the color hue to change, but the not the Windows Mobile hue pattern.
"Hue shifting" color definition
Pocket PC and Smartphone
This work will change the underlying architecture for how colors are defined allowing for more flexibility in color usage.
Pinnable home screen plugins
Pocket PC and Smartphone
OEMs are able to create one or two Home screen plugins that will not scroll off the screen and cannot be removed by the user.
OMA DRM v1 for Pocket PC
Pocket PC
Pocket PCs can use OMA DRM v1 protected images on the Home screen and all device sounds, for example ring tones for incoming phone calls.
Improved low-memory algorithm
Pocket PC
The algorithm that handles low memory condition has been optimized to account for newer memory boundaries and has been modified to work properly on persistent store devices.
More icons on Phone/Today screen status bar
Pocket PC
Windows Mobile 5.0 comes with more status icons on the Phone and Today screens of the Pocket PC, such as: call forwarding, roaming, and GPRS attached.
Soft keys
Pocket PC
From a UI standpoint, this is one of the major changes in Windows Mobile 5.0. Imitating the Smartphone UI, the Pocket PC presents now two soft keys at the bottom of the screen. There are two main scenarios where information input with the stylus is not ideal. The first main scenario is "basic phone usage" such as dialing contacts and incoming phone calls. The second is "maintaining a keyboard posture" on keyboarded devices. In the second case, the keyboards are designed to be thumb driven, so the Soft keys allow most device functionality to be accessed from the keyboard posture.
Full navigation from keyboard posture
Pocket PC
The goal of this work is to ensure that the entire Windows Mobile-based Pocket PC user interface can be operated (navigation and input) from a keyboard posture without having to use a stylus. This work has been done in key places on Windows Mobile-based Pocket PC, such as: Inbox, Contacts, and Calendar. However, there are still many applications, like the Pocket IE, and many control panels, like in Settings, where navigation and input require the use of the stylus. Nothing has been done specifically for Internet Explorer. Navigation to the title bar is available for notifications via Soft keys, and to the Start menu via a dedicated button on keyboarded devices.
Improved Smartdial User Experience
Smartphone
Until now, in order to figure out the Smartdial filtering method, new Smartphone users tend to tap three times over the name of a contact. For example, to search for Mr. Smith, users type 2,2,6,6,6,2,2 instead of 2,6,2. As a result they see a confusing error message saying the contact couldn't be found. The Smartdial experience has been improved in Windows Mobile 5.0 to make this scenario simpler and to give better information to the users to learn how Smartdial works.
Start menu grid view
Smartphone
Users can access programs on the Smartphone through a grid user interface. When changing focus from one icon to another, the icon that gets the focus will be able to show a new icon and the icon losing focus will revert to its default icon.
Segoe system font
Smartphone
Change the Smartphone font to "Segoe" which is used in Windows. Smartphone will continue to use Nina font for East Asia languages.
Startup and shutdown animation
Smartphone
When turning a Smartphone on or off, the user will now be able to see an animated operator and a Microsoft graphic.
Optimized Smartphone setting
Smartphone
It is now easier to find commonly used settings, for example, access to the alarm clock, security, and connections settings. Less frequently used settings have been moved to the second screen.
Align screen unlock with Nokia standard
Smartphone
Users will be able to unlock Smartphone by pressing the left soft key and then the * key, similar to the way Nokia phones are unlocked.
Fix Back navigation in Smartphone Start menu
Smartphone
When users go into a folder on Smartphone and then press Back, they are returned up one level rather than back to the first page of Programs.
"More" on left soft key in Smartphone Start menu
Smartphone
When in either list or grid view of the Start Menu, the option for "more" will be on the soft key.
Customizable Start menu watermarks
Smartphone
OEMs and operators can now customize watermarks in the Smartphone Start menu. Watermarks can be chosen for each subfolder. For example, the Games folder can have a different watermark from other folders, such as Accessories. Watermarks can also be customized as part of Themes.
Basic Design Rules
Developing an application for a mobile device is very similar to developing an application for the desktop. For this reason, the concepts are pretty much the same: the mouse is equivalent to the stylus, and the keyboard is equivalent to the hardware buttons, for example. Yet, there are some differences that a designer needs to consider.
First of all, when designing an application for a mobile device, the designer must consider what exactly makes the application mobile. The concepts identified must be present along the design process. A good starting point is to think of the importance of mobility. Users want to have access to information from everywhere: in cars, waiting for an airplane to take off, while waiting in a line. They don’t need to have the same user experience they do when working on a desktop. A good design must not try to replicate a desktop environment in a tiny device, but should focus on providing the user with the means to get and provide the information they need from a mobile environment.
Some general rules to consider when designing a user interface for Windows Mobile 5.0 are: - Follow the 80/20 rule -- You cannot please 100% of the users of your application, so stick with a design that will benefit 80% of them.
- 5 minutes of activity -- Think of tasks that can be accomplished in bursts of activity of 5 minutes. This is normally the way mobile users work with their mobile devices, as opposed to the desktop, where users spend several hours working on a single task.
- Avoid Options -- UI navigation should be as simple as possible in Windows Mobile. The use of dialogs and text input should be limited as possible. If we think of the Options menu in a desktop application, we will realize that many of those options do not make sense in a Windows Mobile application. It is better to spend some time figuring out what default options will suit the majority of the users. Don't try to make everything an option.
- Leverage desktop affinity where applicable -- Users know the desktop, so it is good to have the same experience, but don’t make the mistake of trying to implement a desktop UI in a mobile device. The user interaction with a mobile device is different than with a PC.
- Leverage synchronization -- to keep the application always on and always updated. One of the biggest advantages of mobile devices nowadays is their capability to keep the user updated.
- Minimize stylus and thumb movement -- It is important to keep in mind that entering information in a mobile device, due to its reduced size, is normally a complex task. It is definitely not as easy as it is in the desktop. Stylus and thumb movement, and also data input, should be minimized as much as possible. This is a very important general rule that should not be disregarded.
- Emphasize data content over graphic elements -- In a mobile device, the screen size is reduced. It is better to give priority to the presentation of information than to the surrounding graphics. Most applications don’t have status bars, because the users are most concerned about the data.
- Make the UI predictable -- Users should focus on their task instead of having to stop and figure out how to perform such task.
Windows Mobile UI Design Guidelines
To ensure that our UI looks clean, consistent, and professional, the following guidelines should be observed.
Pocket PC
Controls should be 20 pixels high and should be snapped to a 4 x 4 pixel grid. This will ensure a clean separation preventing controls to look cluttered. This will also help to ensure balance and symmetry.
Figure 3. Controls should be snapped to a 4 x 4 pixel grid and be 20 pixels high
8 pixel borders should be left blank around the screen, as the picture illustrates.
Figure 4. An 8 pixel frame should be left blank around the screen.
In the case of Options|Settings dialogs, ideally they should not have any menus. Scrolling should be prevented, and no more than three tabs should be presented to the user. This requires a careful design, but investing time in it will have the fruit of a UI simple to navigate. As it was mentioned before, controls should be snapped to the 4 x 4 pixel grid, and an 8 pixel frame should be left in blank around the screen.
In general, in a Pocket PC UI all editable controls should be placed in the top region of the screen so that they are not covered by the SIP when it appears. Otherwise their visibility will be blocked and will force the user to hide and show the SIP to edit and correct his input.
Finally, controls that are intended to be tapped with the stylus or with the finger should be big enough to make them easy to target.
- Finger accessible controls should measure 9.12 mm or 38 x 38 pixels.
- Stylus accessible controls should measure 5 mm or 21 x 21 pixels.
Smartphone
When designing for the Smartphone, we have to think even smaller than in the case of a Pocket PC. We should always keep in mind that a Smartphone has a slower processor than a Pocket PC, and that preserving battery life can be a bigger issue. For this reason, unnecessary animations should be avoided.
Lists
The UI of the Smartphone is basically formed by vertically scrolled lists. The rule is to have one item per line, and one line per item. In the Smartphone, the UI normally presents the user with a single line of information, and if needed, the user will drill down to get more details.
Soft Keys
Soft keys are a central component of the Smartphone UI. Soft keys are included in the Pocket PC UI in Windows Mobile 2005. For design guidelines for the soft keys, please read the following section of this document.
The Back Button
Another element of the Smartphone UI is the Back button, which allows the user to return to the previous screen from the current screen at any time. For the most part, the Back button works as designed without any assistance from the foreground application. There are, however, times when the Back button needs to act differently, and that's when the application has to do a bit of work.
The rules for the operation of the Back button are: - If the current window is not a dialog box and does not have an edit box, the Back button activates the window that was displayed before the current window was activated. The current window isn't destroyed, it's simply covered by the previous window, which now becomes the active window.
- If the current window is a message box or a modal dialog box without an edit control, the Back button dismisses the message box or dialog box and returns the cancel return code. For message boxes, this value is either IDNO, IDCANCEL, or IDOK for message boxes with only an OK button. For dialog boxes, a WM_COMMAND message is sent to the dialog window with the command ID IDCANCEL.
- If the window currently displayed contains an edit control, the Back button erases the last character in the control and moves the entry cursor one character to the left.
In the case of the first two rules, the system will provide the default action for the Back button. For the final rule, concerning edit boxes, the application must override the default action and forward the key to the appropriate child control in the window.
In edit controls, the Back button should be used as the Space bar. In dialogs, it should be used as a Cancel button.
Soft Keys
Until now, soft keys have been the central component of the Smartphone UI. Windows Mobile 2005 introduces the soft keys in the Pocket PC UI as well. Soft keys are located in a soft key bar located at the bottom of the screen. There are some guidelines to consider when designing the behavior of the soft keys.
Left Soft Key
This should be the most popular button for the user, the one he will use the most. It should also be used for any "Done" command.
Right Soft Key
Menus should contain no more than 11 entries in the Pocket PC, and nine in the Smartphone. The use of scrolling menus should be avoided, but if this is impossible, the total number of entries would be 15 for the Pocket PC and 10 for the Smartphone. If needed, submenus can be implemented, but they should try to be avoided. However, a submenu of a submenu should definitely be avoided.
Dialog Boxes
Dialog boxes in Windows Mobile are full screen.
Pocket PC
A well designed dialog box in a Pocket PC should prevent the use of scrolling bars.
Smartphone
In the Smartphone though, with the small size of its screen, scrolling dialogs are a necessity in some occasions. All that is needed is that the dialog box template has the WS_VSCROLL style flag set. When the user changes focus from control to control, if the next control is below the visible part of the screen, the shell scrolls the dialog automatically. If the focus is at the bottom most control and the user presses the Down cursor key, the Smartphone switches the focus back to the first control and scrolls the dialog back to the top.
If the application repositions any of the controls on a scrolling dialog, it needs to tell the dialog manager about the new positions. This is done with the Smartphone unique message, DM_RESETSCROLL. If the controls are repositioned in the WM_INITDIALOG message or in any message before WM_INITDIALOG, sending DM_RESETSCROLL isn't required.
Input Dialogs
Pocket PC
In general, it is helpful to divide dialogs into informational dialogs and input dialogs. Information dialogs are used to show information, and require a few, if any, text input from the user. In the case of Input dialogs, they are intended to gather information from the user. In this case, controls should be placed in the top two thirds of the dialog, so that they are not covered by the SIP when the user is entering information.
Smartphone
The dialogs in the Smartphone use a multi-line edit control. This control has a zoom that allows the user to edit the text in the control in the full screen.
In the Smartphone, we do not have option buttons, combo boxes, or list boxes. Instead, we have spin boxes that allow the user to cycle through different options and select the best.
Property Sheets
Pocket PC
This is a feature that differs in its layout from Windows CE. In Windows Mobile, property sheets are full screen, and tabs are located at the bottom of the sheet, as opposed to the top as it is the case in Windows CE.
Keeping in mind the ease of use of a UI as one of its primary goals, property sheets that are well designed should not have more than three tabs each.
Smartphone
The Smartphone UI does not have property sheets. If you are designing a UI for an application intended to be used in each of the Windows Mobile devices, you should add one menu item to the right soft key that corresponds to each tab in a property sheet of a dialog for the Pocket PC.
Notification Bubbles
The Pocket PC notifications can display an icon on the navigation bar at the top of the screen, optionally display an information bubble with HTML text, and even beep the user as necessary. The user can respond by tapping on hyperlinks or buttons within the bubble. These responses are then sent back to the originating application. Unlike the standard Windows CE notifications, the Pocket PC notifications require the application to be running and manually set the notification as needed. Once the notification is set, the application can stay running and receive feedback from the notification via window messages or terminate and specify that a COM in-proc server receives the feedback.
The bubble is anchored to the application-defined icon on the navigation bar. Notification bubbles have a title and a text body. The bubble window is automatically sized to fit the text.
Notification bubbles tend to be annoying to the user, so their use should be minimized, for instance, by preventing the use of notifications to communicate things that are obvious.
Designers must keep in mind that a bubble is not a substitute for a Message Box.
Screen Orientation
Windows Mobile 5.0, as its predecessor Windows Mobile 2003 Second Edition, enables devices with landscape and square screen displays. This is an addition to the traditional portrait-only displays that have been on earlier Pocket PCs.
When an application designed for portrait displays is run on a square or landscape display, the operating system will automatically add a vertical scroll bar to the form which enables the user to view the entire form. This happens only when there is a control which would be hidden from the user because of the move to landscape. In most scenarios, this is not the ideal way for a user interface to appear on a landscape display. The two alternatives are to either create a single interface layout that works well under both orientations or to create a separate interface layout for each one.
Software developers can ensure that an application works in both modes by always checking the screen size with the GetSystemMetrics() function. Once the screen size has been determined, the application should be resized to fit the screen.
There are three approaches for designing applications that will run in both landscape and portrait modes: - Design for the box
- Change the control layout
- Change the content
1. Designing for the box
The first approach consists of placing all the controls in the upper left of the screen. This is the easiest and requires less work. The look and feel will not be that professional, mainly because wide blank areas will be displayed in the portrait and landscape modes, but this is an easy way to ensure compatibility between the three display modes.
Figure 5. Designing for the box
2. Changing the controls layout
Another way is to change the control layout in order to fit each of the two modes. For dialog boxes, you can create two different resource DLLs that contain the landscape and portrait versions of the same dialog box. After you check the screen size, you can load the appropriate DLL.
OEMs can create a custom build flag that includes the appropriate DLL for the size of the screen included in a platform. In previous versions, Windows CE used the CPLMAIN_LP environment variable in this manner to determine whether to include landscape or portrait versions of Control Panel applications. As of Windows CE .NET 4.2, a custom build flag enables you to select resources for portrait views on quarter VGA (QVGA) displays. This feature is selectable from the Catalog at Shell and User Interface\User Interface\Quarter VGA Resources – Portrait Mode.
3. Presenting different content
Lastly the different display modes can be used to present different content on each. This approach can be used to modify or increase the functionality of an application to the benefit of the user, by adding controls in one of the view, for instance.
One example of this approach would be a calendar. The contents could be modified in such a way that a 12 month calendar is presented in portrait mode, while landscape mode presents an eight month calendar, and the square mode presents six months at a time.
This is a difficult technique and requires a very careful design, but it can bring very useful features to the user if a good design is made.
Landscape mode and left handed users
A good UI design must consider left handed users, particularly in landscape mode. As opposed to right handed users, a lefty would be more comfortable holding the device on his right hand while grabbing the stylus on the left. The DevMod structure makes it easy to provide usability to both kinds of users. - For right handed users: Set dmDisplayOrientation to DMO_0
- For left handed users: Set dmDisplayOrientation to DMO_90
Design issues related to screen orientation
An important recommendation for the design of screen orientation aware applications, is to prevent overcrowding the UI. A good design principle is to break the information into multiple screens, instead of trying to present and get as much information as possible in a single shot.
Also, it is important to remember the SIP when designing a screen. Controls that require user input by means of the SIP should be placed in the upper region of the screen, to prevent being blocked by the SIP, blocking the view of the user of the text he is entering, as figure 17 shows. In fact, we recommend that all controls are left out of the SIP region as much as possible.
Designing for Multiple Resolutions
Windows Mobile 2003 Second Edition introduced higher resolutions. In Windows Mobile 2005, we have three resolutions to consider: 96, 131 and 192 DPI. The higher the number of DPI, the more pixels a screen has.
Resolution in a Windows Mobile device is different than resolution in a PC. In a desktop application, when we have a higher DPI our designs are made to present more information or to have more controls. But in a mobile device the screen size does not change, it remains the same with any DPI. So if we added information and controls our UI would not be readable. For this reason, we must design to present the same information, but with better clarity and readability.
Design considerations
When designing for multiple resolutions, we should always keep in mind that the physical size of the screen doesn’t change, but the pixels size gets smaller with more DPI. A good principle is to keep the text big and readable. Tap targets should be large enough to be hit easily.
When designing bitmaps and icons, one version of each should be built for each resolution. If they are designed for only one resolution, they might look different with a different DPI. Scaling up bitmaps makes them look clunky, while scaling them down is even worse, for pixels will drop out.
Not all applications contain graphics, but all of them do have icons. Correct icon dimensions per resolution are shown in the table.
DPI |
Pocket PC |
Smartphone |
Icons |
96 |
240 x 320 |
176 x 220 |
Large: 32 x 32
Small: 16 x 16 |
131 |
Not supported |
240 x 320 |
Large: 44 x 44
Small: 22 x 22 |
192 |
480 x 640 |
Not supported |
Large: 64 x 64
Small: 32 x 32 |
Pocket PC Emulation Layer
With Windows Mobile 5.0 in the Pocket PC, the emulation layer technology allows everything to be translated to 96 DPI automatically. This technology is not available in the Smartphone, but in the Pocket PC is very useful. However, this does not work well for a very advanced graphic UI.
If a developer wants to take advantage of the screen resolution for a specific use, the emulation layer needs to be disabled:
HI_RES_AWARE CEUX {1}
turns off the emulator layer. Starting in Visual Studio 2005, applications as marked by default to be resolution-aware, so the emulation layer is turned off.
In applications written in native code, dialogs are resolution-aware by default. For this reason, font sizes must be scaled by means of MulDiv().
-MulDiv (PointSize, DRA::LogPixelsY(), 72)
Pixels must be scaled manually, using SCALEX(), and SCALEY():
MoveWindow (hwnd,
SCALEX(7),SCALEY(7), //coordinates
SCALEX(150),SCALEY(13), //width and height
TRUE)
Please refer to the Windows Mobile 2005 SDK documentation for information on: MulDiv(), SCALEX(), and SCALEY():
In managed code, forms are not resolution-aware by default. The emulation layer should be used when it is applicable. It is better to design for specific resolutions, and pixel values need to be scaled manually as in native code.
Text Considerations
The text of a mobile application must be helpful to people on the move. In addition, the reduced screen size does not permit the use of very descriptive text. It is better to use a less formal tone. Superfluous text and descriptors should be removed. For example: - In a Windows Mobile device: "Cannot connect."
- In the desktop: "Your device cannot connect. Please try again later."
In on line help, it is better to use symbols. For example: - In a Windows Mobile device: "File > Open"
- In the desktop: "On the File menu, select Open"
A very well known UI design principle is to ensure consistency across the application. Texts are not an exception and the following formatting should be observed consistently: - Bold text should be used for headers exclusively. Never to emphasize a word.
- Italics must never be used in a Pocket PC or a Smartphone.
- Colons must be used only at the end of labels. Never at the end of headers.
One of the most important things to consider when designing a UI for Windows Mobile, especially when deciding what texts will be used, is the impact a text will have when the UI is localized to a different language. Some short words in English can be very long in a different language, and enough room should be left for them to fit. As an example, we can think of the word slide, which in Spanish is translated as Resbaladilla. Or a more technical word, prompt, in German would be translated as Eingabeaufforderung. Designing texts to allow localization is certainly challenging, but should not be overlooked. As a general rule, allow room for 30 percent of text expansion.
Another good practice is to avoid multiple buttons on a single line. Otherwise, when the UI is localized the text inside the buttons has to be abbreviated in order to fit. This does not look professional.
Conclusions
As we have seen, the UI of Windows Mobile based devices has evolved over the time. However, the same challenge has remained: dealing with a very small screen compared to a desktop PC. We should always remember that Mobile devices are not substitutes of a desktop PC, and their utilization scenarios are normally mobile. They in fact can be considered mobile extensions of a desktop PC, which users will use to have access to relevant information. In mobile scenarios, users need these devices more for viewing information than for editing it.
Mobile UIs are more data oriented than graphic oriented. There is not enough room for everything, so we have to stick with what is more important for the user.
Following rules and standards ensures consistency across the application, increasing its usability.
UIs should be designed to be used both in landscape and portrait mode, and left handed users should not be forgotten.
Design for the future
Many developers are concerned with ensuring a long life to their applications. This is particularly true in the case of those who write applications to run on mobile devices designed for specific vertical markets.
A good principle to consider in order to designing mobile software that will last is to allow for localization when designing its UI. Even if there are no specific plans to localize an application in the near present, it is better to consider the recommendations mentioned in this document so if the software is eventually translated to a different language, the UI design will not be dramatically affected.
Applications should be designed to run in any of the resolutions supported by Windows Mobile.
Finally, paying attention to the industry convergent trend, the best consideration when designing Windows Mobile based applications for the present and the future, is to design for both the Pocket PC and the Smartphone at the same time.
Copyright © 2005 Microsoft Corp. All rights reserved. Reproduced by WindowsForDevices.com with permission.
Related stories:
(Click here for further information)
|
|
|
news feed