* * *
Jeff Chen is a second-year Electrical Engineering and Computer Science undergraduate student at the University of California, Berkeley. He also plans to study Business Administration and attend business school in the future. He has done research in the past and has won awards including the Siemens Westinghouse and the Undergraduate Research Fellowship at the University of California, Irvine. He is a member of the Sigma Chi Fraternity and enjoys running, surfing and snowboarding in his free time. He’ll visit Bill after he graduates. Jeff Chen can be reached at: [email protected]. His teammates Lin Xu and Casey Ho can be reached at [email protected] and [email protected].
Ten Commandments for Pocket PC User Interfaces (Do’s & Don’ts)
by Bill Shadish
This article is for those managing the development of handheld applications. What follows are some guidelines that you can use when deciding how your new handheld application will look and operate.
When you’re developing an application, a lot of forces influence the decisions you make. The owner of your company (who came to power during the early MS-DOS era) may have strong feelings about what should go where and how it should look. The software programmers will have their own staunch opinions. And finally, the fun-loving "end users"—the people for whom the application is being built—will have very distinctive thoughts about the way things should look and work.
Part of your job is to provide suggestions and standards that everyone will agree upon. You already know the fields that are required, the data rules, and all of the hooks to other applications. Now you are getting ready to lay out the actual screens. Where, oh where, do you start?
In the beginning IBM created CUA
Long ago, IBM defined "common user access" (CUA) guidelines to provide a standard for developers to follow when designing screens. Many of the good points of CUA can assist us today. For example, one of the CUA guidelines suggests that programmers include a pop-up dialog box confirming the user’s intentions whenever the user tries to delete a record. Most of us are quite happy to have had the chance to change our minds about a delete as a result of this guideline.
Below are my user interface (UI) 10 commandments to consider when creating your own application for the Pocket PC.
1 Thou must chooseth between scrolling and paging navigation.
Whether you are buying or building your application, one of the biggest user interface questions that you will need to answer is which page navigation model you want to use.
With the scrolling navigation method, data fields are displayed in a long Web page-like form and you use a scroll bar to navigate up and down through the form. It maps well to Web, Word, or Adobe Acrobat content, but can be annoying to users who are forced to move the visible screen up and down to work with the application. More of a problem is the fact that users tend to forget what they can’t see. Entry fields that are buried down off the screen will likely be skipped by the user—at least until your page-turning logic pops up an error message and sends the (now really annoyed) user back to the fields that were skipped.
The alternative is to use paging navigation, where you divide the information or data fields up into separate screen-sized pages. If there are only a few pages (screens) per record, you can have the user access the different pages using tab controls. If there are more than a few pages, you can place [Prev][Next] buttons at the bottom of the form, which direct the user to the desired page. Using this model, a screen’s worth of information is never longer than the display area provided by the device. These navigation controls only take up a little bit of screen real estate. In addition, they are useful in that they can be disabled until all required information has been entered on a given page. This provides a sure visual sign to the (now less annoyed) user that they have correctly filled out a screen before they try to continue.
Note that one drawback to the Prev | Next approach is that screen size will vary across devices, which generates some extra work for the developer.
(above) Chose the navigation style— scrollbar or Prev I Next.
2 Thou shalt only use one font and only 1 or 2 different font sizes.
Ah, this is the first place that developers head for when playing with a new environment. You will see italic fonts; three or more sizes of fonts; bold fonts; normal fonts; humorous wing-dingy fonts—generally more fonts than you can shake a stylus at.
A good rule of thumb is to use no more than 2 font sizes in your application (but preferably only one) and use bolding to differentiate between types of fields like labels and entry text. It is also fine to have an additional very small font for things like copyright notices.
3 Thou shalt use no more than a couple of colors.
This is the second place developers turn to when tuning up their skills on a new platform. Expect to see colors, colors and more colors in the first iterations of such applications.
More than two or three text colors on any screen (including black), tends to confuse more than help. The same exact two to three colors should be used across your entire application—and possibly across your entire line of products.
Extra credit: Remember that there are colorblind customers in the real world. Color-blind customers would also like to be able to use (Read that: Buy!) your applications. If you count on colors alone to differentiate sections of the screen, you will be disenfranchising the color-blind user.
4 Thou shalt allow chubby fingers to operate a touchscreen.
We know that a stylus can be used to operate a PDA. This allows you to tap on a relatively small area of the interface in order to select something. This fact has given many developers an unwritten go-ahead to pack as much as possible onto a given screen (see below).
Beyond creating an unwieldy looking screen that can send folks into a cross-eyed fit, it also makes it difficult to use a fingertip to select things on the interface. And yes, Virginia, humans sometimes prefer to tap the screen with their fingers instead of struggling to get the stylus out. Even worse, they sometimes lose the stylus! Design your program with this in mind and test it using only your finger. The result? Your program will contain less cluttered screens. In addition, the design will allow for one-handed operation so that users can also do other things, like holding a phone.
(above) Yikes! Try to use this program with one hand.
5 Thou shalt disableth features and controls; not hideth them.
One thing that surely generates a lot of support calls is when an application chooses to hide (remove) a control or a feature from a user’s view, rather than simply disabling it.
Developers often prefer to hide menus, controls, entire screens and so on, when it is not relevant to a user. This tends to cause a lot of user frustration, especially if they have used an item in the past, and now can not find it on the user interface. Your design can opt to disable these elements if they are not context-appropriate, rather than hiding them. This confirms for the user where the element is (so that they don’t continue to waste time searching for it); and it also let’s the user know that, in this context, the element in question is not appropriate. Making things easy for the user, rather than the developer, results in a better overall experience for the users of your application.
6 Thou shalt use the right data selection controls.
One of the things that can be hard to decide when designing a screen, is when to use radio buttons, list boxes, or combo (drop-down list) boxes for your users to make selections from.
The rule of thumb here is that if there are three or less items to select from, use a set of radio buttons to allow the user to make their choice. If there is less than a screens’ worth of information to select from, use a drop-down list instead.
If there are more entries to choose from than can fit on one screen, then use a list box so that the user can scroll back and forth to make their choice. When using a list box, set it up so that the user can enter the first character of an entry to jump to the section that it is in, especially i
f there are a large number of entries to pick from.
Extra credit: Consider adding MRU (Most Recently Used) lists to your application. These keep track of the most frequently chosen selections or entries by individual users and present these in the selection list. Also, allow the user to clear the MRU list if they so desire.
7 Thou shalt check before deleting.
Prompt the users of your application, after they’ve chosen to delete a record, to ask if they are sure that they want to do so.
Providing a "Are you sure you wish to delete [and display the record’s name or other meaningful record identifiers here]?" followed by a "(Yes) (No)" prompt, gives the user a second chance.
You will find that this reduces the number of frantic customer calls to your support line, asking how they undelete an item.
Extra credit: Provide a few levels of "undo" on screens that accept blocks of text entry.
8 Thou shalt let icons be icons.
Webster’s defines "icon" as a graphic symbol that denotes a program, command, data file, or concept in a graphical user interface. The whole purpose of representing a program (and operations within a program) graphically is to make it easier for the user to find, launch, and use the program. However, if the developer keeps changing the icon’s shape, color, or image with different versions of the application, or contextually within the application itself, it defeats the real purpose of an icon; to simplify life for your users. Pick an icon design and stay with it.
9 Thou shalt MARK required fields.
Admit it! You hate it when, after filling out a form or screen and tapping on the submit button, you are thrown back onto the same screen to fill out required fields that you missed. You hate it just a little more when these fields were not marked as being required in the first place.
Make sure you show the user what is required. You can add a small arrow at the end of a required field or add an asterisk in the label name before the field. And for heaven’s sake, don’t prompt the user with each item that they failed to enter, one-dialog-box-at-a-time. Show them everything that they’ve missed in one long message dialog. Then immediately place them into the first required field that they missed as soon as they respond to your warning dialog. This saves the user from having to tap/negotiate their way back to the field.
(above) Clearly Mark Required Fields.
10 Thou shalt recognize that all Windows Mobile devices are not the same
There are Mobile 2003, Smartphone, Pocket PC 2002, Pocket PC 2003 devices, and more. Each has differing screen sizes, methods of input and even different applications loaded into the device by default. And this does not begin to consider previous Windows CE versions, or applications that you may wish to deploy across varying software platforms.
Our world is complex, and becoming more complex. Put a little time into considering how your application will look if it is run on these different versions, as well as how it will work on them. For example, the Smartphone doesn’t have a touch screen. How does that affect your application? You may not care today, but it does not hurt to consider this before building/buying, so that you at least have an answer ready for the user who does try to run your application on a somewhat incompatible device.
Extra credit: The use of sound or voice prompts can be cool, but make sure that all devices that will be running your application support these features.
Submit a commandment!
The list of user interface design do’s and don’ts in this article is not exhaustive. To make this a dynamically increasing set of ideas, e-mail me your own UI design commandments ([email protected]). Submissions will be included in the online version of this article (http://www.fo.com/articles). Please supply your name and email address and they will be included with your commandment.
* * *
Related Links
U.S. Department of Health and Human Services Usability—http://usability.gov
E-mail lists that you can subscribe to for more information or to ask questions—
http://www.uiweb.com/other/chiweb.htm
Wide selection of User Interface (UI) thoughts—http://www.chesco.com/~cmarion/Design/UIDesign.html
Common User Access; A consistent and usable human-computer interface for the SAA environments (History)—
http://domino.research.ibm.com/tchjr/journalindex.nsf/0/7521b9eb651768a185256bfa00685bf2?OpenDocument
http://domino.research.ibm.com/tchjr/journalindex.nsf/0/569afd3b353df16985256bfa00685c8c?OpenDocument
ProContext User Interface Style Guides—http://www.procontext.com/en/guidelines/style-guides.html
* * *
Bill Shadish is a principal of Fundamental Objects, Inc. (http://www.fo.com); where he works on client partnerships and handheld technology. Bill writes for a number of industry trade journals. He can be contacted at [email protected].
Ten Things Every Mobile Developer Needs to Know to Pass the "Logo Certified" Test
by Scott Kovacevich
Now that you’ve developed your Microsoft Windows Mobile application, how do you get it into the hands of the mobile public? The answer: Get "Logo certified" with the Microsoft "Designed for Windows Mobile" program.
But you may wonder: "Why should I get certified?"; "What are the requirements to pass the certification?"; "Will my application pass the testing process?"; and "If I do get certified, what do I do then?" These are common questions the first time you send off an application for certification. Here are the answers.
Why get certified?
Well, for starters, once your application earns the logo, you can submit it to the Microsoft Mobile2Market Catalog (http://www.microsoft.com/windowsmobile/catalog) where it will be promoted and marketed by Microsoft and special retailers. This can provide a big boost to your sales. In addition, having the "Designed for Windows Mobile" logo on your application tells buyers that it is stable which gives them a greater level of confidence.
Finally, you also become eligible to join the Microsoft Partner Program (http://members.microsoft.com/partner/) where you can get technical support, software, the MSDN Kits, and a TechNet subscription—all very useful for any developer. These are just a few of the reasons it pays to get certified.
What is required for testing?
For a quick overview of the program and links to other resources, go to Microsoft’s Mobile2Market Web page (http://www.microsoft.com/windowsmobile/information/devprograms/mobile2market/participatevendors.mspx). The process is described in three simple steps:
Develop the application using the latest tools.
Test and certify and code sign the application (if necessary).
Deploy and market the application.
This Web page also links to documents that lay out the exact certification requirements, plus an in-depth description of the testing process.
Passing the test
The Microsoft pages also list the test labs authorized to do certification testing, and provide instructions on how to get started. My focus here is getting your application certified quickly and painlessly: here’s what you need to know about the testing phase.
Ten things every mobile developer should know:
Read the requirements for the logo certification. Links to PDF versions of the Designed for Windows Mobile Software Application Handbook for the Smartphone and for the Pocket PC are found on the Mobile2Market Web page (http://www.microsoft.com/windowsmobile/information/devprograms/mobile2market/participatevendors.mspx).
Don’t have time to read this entire document? I highly recommend that you do so if you want to maximize your chances of passing. But at least read the section titles, and if you don’t understand a title, read the section that goes with it.
Read the Summary of Updates Since May 2003 Version. This is included in both the Smartphone and Pocket PC handbooks mentioned in point 1. This details what has changed in the current version (August 2003) from the original version. It is on page 4 in both documents.
Later in the document, old requirements that are c
ontradicted by the Summary of Updates may still be listed. For example, the Summary of Updates in the Pocket PC handbook states that the "No User-Exposed Method for Closing the Application" requirement has been removed. But on page 9, the Pocket PC handbook still lists this as a requirement. Things like this can cause confusion, so be sure to read the Updates section and use it as your guide.
Pay attention to the "Special Circumstances and Additional Requirements" section. Located near the end of these documents, this section takes care of the different or non-typical applications, such as those with special input methods, utilities, add-ons and device drivers. This section doesn’t apply to all applications, but take a look anyway—it could mean the difference between passing and failing.
Review the .NET Compact Framework exceptions. If your Pocket PC application uses the .NET Compact Framework, you must look at pages 15 and 16, "Exemptions for Applications Built Using the .NET Compact Framework." If you fall into this category, you are lucky—your application gets a few exemptions that the other applications don’t get. Most of the exemptions deal with Help (you don’t have to integrate your Help with the main Help Table of Contents, and you can have a Help button). Also exempted is ToolTips, which does not work with .NET. Yes, you can quit banging your head against the wall trying to figure out how to get ToolTips to work with .NET—it just doesn’t!
Pocket PC magazine, October/November 2004 Page 12