Overview
by Bill Shadish

This article is for those who are Buying Handheld PalmOS applications. The intent is to give you some things to think about when building new applications today. While our focus in this article is on Palm device user interface issues, much the same is true in the PocketPC world, due to the relative size of the interfaces involved.

When presented with a new hardware or software platform, it is quite common to find that developers tend to use every bell and whistle available to them.

You may have seen this when Windows was introduced. Screens with every font and color combination possible scared users from America to Japan.

Later, when multimedia applications came into vogue; there were more things beeping, tweeting, whirling or whistling at you from your screen, than were actually available to do your work.

Can you say "I hate the pop-up Microsoft Office Paperclip character?"

Thankfully(?), there are not that many user interface bells and whistles available to Palm OS developers to get into trouble with. However they still can do so ... by using too many fonts, packing too many things onto a screen or, more recently, by using too many colors. What follows are some guidelines that you can use when deciding how your new handheld applications should look.



In the Beginning

Long ago -- IBM defined common user access (CUA) guidelines to provide a standard for developers to follow when designing screens. Long since co-opted into Microsoft products, many of the good points of CUA can assist us today. For example, one of the CUA standards requires a developer to pop-up a Dialog Box (confirming the user's intentions), whenever the user tried to delete a record. There are thousands of users over the years who were Quite Happy to have had a second chance to change their minds as a result of this standard.

This is a suggested starter set of guidelines to use when designing Palm Pilot applications. The list is Not exhaustive. In fact, there is an opportunity below for anyone reading this to provide additional thoughts on this topic.

May nothing but highly usable handheld applications be the result!



1. Thou Shalt use only a Couple of Fonts.

Ah, this is the first place that developers head for, when playing with a new environment. You'll see italics; 3 or more sizes of fonts; bold fonts; normal fonts; humorous fonts -- more fonts than you can shake a stylus at. A good rule of thumb is to use no more than 2 font sizes on screen and preferably only one; using bolding to differentiate between types of fields. It is also fine to have one separate very small font for things like copyrights, at the bottom of the pages as well. Note: If your developers come to you and suggest using the 3rd Party add-in fonts that are becoming available (which means your having to install and support them on the eventual downstream users' handhelds ... among other issues), trust me; and just say No. Go with what the platform supports directly.

2. Thou Shalt (at least consider) using A Couple Colors.

Let's face it -- the "Green Screen" is almost dead. Customers desire color Palm Pilots and as the prices come down on them, more and more will be purchased. It is relatively easy to code applications to work on both color and monochrome Palm units and doing so will make your applications easier to sell. Take a look at figure 1's two Palm III interfaces. Which application would you think was done before the "Naughties"? Which one would new users of (the more expensive) color Palm units appreciate more? Figure 1 - B&W vs. Color Which application would prospective buyers think to be "old fashioned" and therefore less likely to purchase? Customers will be trying your applications on color devices -- and they Will know whether you have gone the extra mile to consider the way your application will look in color.

3. Thou Shalt use Only a Couple 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 applications. More than 2-3 colors of text on any screen (including black), tends to confuse users more than helping them. The very same limit (of the same exact two to three colors) should be enforced across your entire application -- and possibly across your entire line of products. Tip: Remember that there are color blind customers in the real world. Color blind customers would also like to be able to use (as well as to purchase) your Palm Pilot applications from you. If you count on colors 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 Palm Pilot. This allows you to click on a relatively small area of the Palm interface. This fact has given many developers an unwritten go-ahead to jam and pack as much as possible onto a given screen. Beyond creating an unwieldy looking screen that can send folks into a cross-eyed fit, it also prohibits users from doing the unmentionable (that is, to use their fingertip to select things on the interface). Yes Virginia, humans do sometimes wish to enter in a few quick PDA thoughts, without having to struggle with getting out the stylus to do so. Besides, this allows for one handed operation so that you can also do other things, like holding a phone. Consider this in your design, possibly by running through a version of the screens using only your finger. The Palm interface is fairly forgiving in this regard and you really can get at fairly close objects individually with a finger tip. So it IS possible to accomplish this and you will get an uncluttered feeling set of screens along the way.

5. If Thy Interface is Boring Add SMALL Graphics to Help.

Yes, it IS a little bit harder for a developer to use graphics on a Palm Pilot than simple text. Yes, your developer Will have to work a bit harder to do so. And of course you will want to control the size of the graphics added, because a Goal to keep in sight is to have small (that is SMALL) sized apps. But sometimes a small graphic here and there can really give your interface the edge over others. Consider these two sets of buttons. The left two buttons are stock Palm buttons. The right two are graphic buttons which do not add that much in "size cost" to use. Which set of buttons would you rather have your sales staff present to prospective customers?

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 3 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 if there are a large number of entries to pick from.

7. Thou Shalt Check before Deleting.

Prompt users of your application, after they've chosen to delete a record, and 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 identifier here]? (Yes) (No)" prompt, gives the user a second chance. This also produces the happy byproduct of reducing the number of frantic "HOW Do I undelete a Record?!?!?" support calls to your office.

8. Thou Shalt Check before Overwriting.

It is quite possible to beam something to another Palm Pilot without asking the recipient if they want to actually receive it. But it is a very good practice to allow the receiver to "Just Say No" if they want to -- and by prompting them, you provide them with that option. So it is not a good idea to sneak your apps onto another Palm without checking with the owner first. What IS a good idea, is to package things together that you want your application to beam to others. If your app will send itself, a table (PDB) or two, possibly extensions (separate .PRC files) or other things; it would be wonderful if your application bundled all of these things together into one file to send to the receiving Palm. The person getting your files will be happy to only have to reply once when receiving. Also, this allows you to start beaming and to do something else while that process is going on.

9. Thou Shalt be Wary of the other Devices before Ye.

Yes, Palm does have 87% of the handheld market today [reference: The Gartner Group]. However, Microsoft has had (cough, Lotus 1-2-3) a history of (cough, cough, WordPerfect) turning the tables on competitors (choke, dBASE) who seemingly "owned the market". It would be prudent for those who are developing applications today to be very mindful of this. One thing that you can do to protect yourself, is to have your developers understand Both the PocketPC and the PalmOS platforms. It is not outlandish to have them create small example applications that demonstrate their ability to write code, that is at least possibly portable to other platforms. This is not an unreasonable thing to ask for when building new handheld products today. Ask your developers to create very small code modules to handle individual functions. The smaller the modules, the more easily that they can be ported if it becomes necessary to do so later on.

10. Thou Shalt (at least) Consider Foreign Language Support.

If dictionary applications taught us anything ;-), it was that by providing support for multiple languages, that you Can increase your market. This does not mean that you Have to include German/French/Spanish/etc support today. But, know that there are ways to construct applications, that do allow you to more readily add support for other languages in the future. Make sure to ask your developers what their plan is to handle this down the road. Verstehen Sie?

Submit-a-Tip

If you are designing an app which you particularly expect will be
used in an airplane make it forgiving of shaking hands. 
(an old tip from Apple HI people for laptop design).

   This may imply:

    a) larger target areas,

    b) extra Undo or more acknowledgement dialogs,

    c) more tolerance of sudden jerks of the stylus if there 
       is a drawing aspect, effectively running a smoothing 
       algorithm.

       Maybe even a special "in air" mode is needed?

Seconding the tip about using thumbs - remember the poor soul
who just dropped their stylus and don't trap them without being
at least able to finish an operation without one
(ie: if there are important buttons to press make them fingerable).

Tip #1 applies even more so if your target audience is
aging or people with illness affecting motor control.

Bio

Bill Shadish is a principal of Fundamental Objects, Inc.; where he works on client partnerships and handheld technology. Bill writes for a number of industry trade journals; including Energy User News, Home Energy Magazine, Inside Visual Basic and Visual Basic Developer. Bill has co-authored several books, including the most recent one from Wiley Publishing called 10 Projects you can do with SQL Server. He can be contacted at foAudits.com.