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
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
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
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
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
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
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.
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
|| 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.
To make this a dynamically increasing set of ideas, I have
provided a place for you to enter your thoughts on user interface
tricks and design. New Ideas that add something to this page will be included
in this section. Please supply your name and email address and they will
be included with your tip.
us a User Interface thought or tip
submitted by: Andy Dent, Australia, April 15, 2003
- 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
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.
Thanks for your time!
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.