TamsPalm - the Palm OS Blog

Today I’m pleased to announce that I am able to release Version 1 of my OpenMoko Theme Project based on the look of the Open Source OpenMoko Project. As some of you may know by reading this post here at TamsPalm or by following my threads at both 1src and Brighthand, I’ve been working on this project for over three months. There may well be bugs/glitches, as this is my first project of this magnitude, but I can assure you all the skins/themes are working perfectly on my Palm TX. Included in this package are skins for:

• AppIcon
• AppShelf
• IconPlus
• MySkin/Kbd
• PalmRevolt
• PictureLogin

This theme is 100% free to use, distribute and modify. Looking back this was a huge project which entailed a great deal of work, but in the end was a labor of love. If you enjoy using this theme package and wish to make a small donation to offset its development costs, please refer to the ReadMe! document contained within the ZIP archive for more information. You can download the package either at 1src’s Freeware Section or via this direct link!

Thank you.

__________________

Best Regards,

Brent Chiodo

A TamsPalm reader recently brought up an interesting point to me:

“As for VersaMail, well I think this unresponsive cancel button is going to put me over the top.”

Why is it that in many applications cancel buttons JUST DON’T WORK? Contrary to popular belief, this is not the fault of the developer. It is actually one of the side effects of event driven programming. Consider the following diagram as that of a typical application. (simplified of course):

In this application a cancel button would be pointless. When a user presses the cancel button an event is placed in a queue. All of the events in the queue before it must be processed before the application realises that the cancel button has been pressed. By then it is too late and the action the user wanted cancel has already been completed.

A complex application like VersaMail adds a bit to this design:

In this application we hit a problem: We are out of the event loop! So what? Well, hitting the cancel button queues an event, but the event queue is not been processed in the send mail loop. So, the loop will not terminate until all of the mails are sent!

How Can I Create a Working Cancel Button?

There are a few ways that I can reason.

1) Process nilEvents

Most developers don’t realize how helpful nilEvents really are. By using nilEvent to handle repitive tasks (such as sending or recieving multiple emails) you can keep your UI active.

The first thing that you have to do is make sure that you are actually getting nilEvent. Most applications use EvtGetEvent(&event, evtWaitForever); but this will keep you from getting nilEvent. You must change the second parameter to a suitable number, say, EvtGetEvent(&event, SysTicksPerSecond()); which is saying if there are no events after one second, send me a nilEvent.

Once this is done, add nilEvent handling to your form’s event handler so that it does one piece of your repetive task, and you are set!

2) Create a background thread
Contrary to popular belief, there is at least one (:-)) public API for multithreading: the sound stream API allows you to create a secondary thread. IMHO, you cannot call any UI functions in the thread, but you CAN place you sendmail routine into this seperate thread and use feature memory for the two threads to communicate.
While creating a background thread may seem a bit hackish, it works well for large tasks.

So, if your application has a large or repitive set of tasks that keeps the cancel button from working, consider implementing one of the above options. It will make for a better user experience in the end.

The user interface of an application is one of the most important selling factors - the default UI sets the first impression; and the first impression decides if the program gets booted off the handheld or not. I dare to say that my Daily Quote product has a decent UI - but anyways, a few analysts sent me suggestions for further improvement.

Improving UI is great, wohoo, throw away the old, here we go - but is this the right way? IMHO, it isnt - as you alienate your core user base when changing UI.

Microsoft radically changed the UI of its Office family - for the first time ever in the company’s history. When Windows 95 arrived, you could disable the Explorer shell and stay with Windows 3.x program manager - in fact, even my Windows XP box still has that archaic tool installed. The reason why Microsoft could afford the radical change is simple - they lead the market, and thus can squeeze down out throats whatever they want to. If I don’t upgrade, eventually, I wont be able to communicate with my partners at various ESDs and companies. Do or die…

On the other hand, for a Palm OS house, existing customers are a very precious resource as they can(and will) move away from your company if annoyed. Changing the UI of a product is a huge annoyance - so keep the improvements in check. Adding small and unobtrusive dialogs, etc is not the killer here - the problem starts when you revamp large areas of user interaction. For example, if users always had to use the menu and now get a toolbar button - eeker squeek!

DataViz had a great idea when they released DocumentsToGo 7 - but the toolbars were completely redundant and could be disabled. Essentially, I can have DocumentsToGo 9 look like v6 or v4 - and this is what keeps users loyal…

What do you think?

While betatesting one of the various programs that pass by my hands, I stumbled across this truly unique gem of madness:

Clicking on Font pops up the font selection dialog(there’s FontBucket behind that btw - TamsPalm’s tutorials really do work):

So far so good - but figuring this out took me(as a longterm user) ages - in fact, I filed a bug report because of the three points after font. I simply didn’t realize that we were dealing with a command button here - the design/interaction pattern was broken.

Today’s hint is simple - when you need a command button(one that toggles an action), use just that. Don’t abuse any of the other system-provided widgets…your users will love you for it!

Microsoft Office 2007 has recently been released to manufacturing - so we will all get an opportunity to play with the new, much-ridiculed user interface. Anyways, one of the Office Developers maintains a very active blog explaining many of the UI decisions:

http://blogs.msdn.com/jensenh/default.aspx

As you may probably know, I beta-test for a few programs. One of the developers recently forwarded me this:

Hi,

> It seems there is no way to exit foobar.prc on a Treo.

What should we do? Give him a menu button or an icon?

PalmSource states that Palm OS applications usually don’t need an exit menu button or command. The home key aka launcher is the standard way to exit a Palm OS program, and this should stay this way.

DocumentsToGo’s doc list view has no dedicated exit button; the exit button is only in the document editors as those need it. I state this just in case anyone wonders…

More information is available here:
http://www.palmos.com/dev/support/docs/ui/UI_FittingIn.html#971334

The camera application of my Palm Treo 600 annoys me so much that I will eventually create a replacement one…if just to implement a few common sense features(if someone would send me the datasheet).

One of the worst nuisances is this ‘name change’ text box in the top left. It is too short for just about every sensible name for an image(except maybe a$$ or Treo)…and there is loads of whitespace to the right.

When designing UI, please(!!!) try to make your fields long enough for sensible data entry. Scrolling vertically with a scrollbar is a reality for Palm OS users…but please save us the horizontal ‘blind-flight’!

Beeing in a vacation house can be a very satisfying experience - especially if you take a 5 minute break from your work and install Firefox 2.0 on the machine there(that you never really use, thus no risk).

The installation was a simple and fast process - it took about 30 seconds on the AMD Athlon 2300+ CPU. After that, the browser immediately started up - and left me wondering about WTF this was:

Firefox 2.0 looks totally different from 1.0 - in fact, it is so different that it confused me quite a bit on the first glance. Also, the tab close buttons were rearranged - this reduces mouse movement from 1.x(it always had the tab closer in the top right), but also required me to rethink my ways:

The important lesson learned here is that improving UI can(and will) confuse users. so, try to get your UI right the first time and make small step upgrades - and please,. please, please don’t force a look-and-feel upgrade onto your users!

People who read TamsPalm for quite some time know that I hate annoying alert dialogs. Anyways, Michael L Perry posted an interesting post about how iTunes has a very annoying alert dialog.

The problem with the alert dialog is that it pops up in the middle of a long process where the user usually is not close to the machine. So, it has the potential to cost the user loads and loads of time…but enough said, visit him here:
http://www.adventuresinsoftware.com/blog/?p=39

When betatesting applications, many UI quirks tend to repeat themselves over and over again - it looks like Marx was right after all(history repeats itself). Anyways, look at the screenshot below:

The texts in the red circle(I drew that in btw) are clickable in order to change options - if you can find them.

Every platform has established “platform UI guidelines” - those become patterns and burn into user’s minds. Palm OS users assume that things with a frame around them are clickable - and since these labels dont have a frame, their chance on getting a click is low. One could say that they don’t afford clicking.

Today’s UI hint is short and sweet: If you want users to click on something, make it look clickable. Ah, and I cant repeat it often enough - keep to the platform standards!

Sometimes, I wonder why PalmSource had to make FrmAlert and FrmCustomAlert so easy to use and call - if they wouldnt be so easy to do, the Palm OS world could just be a better place.

Deleting a file in a popular PalmOS image viewer first pops up this(useful) conformation dialog:

When the delete process is completed, however, the program proceeds to tell me how it just deleted x images successfully from my handheld:

When doing alerts, you should be very careful not to slow users down. If you feel that a dialog could be annoying, either leave it out or add a ‘Don’t show again checkbox’. Your users will love you for it!

Jeff Atwoods of CodingHorror recently wrote about IDE color schemes. He looked at black background-white text schemes - and IMHO forgot one of the biggest problems: reflections.

Both CRT monitors(I love my Siemens tube…its my central heating) and consumer notebooks(Acer Aspire 5622 WLMI) have reflective screens - and the blacker the background becomes, the more reflections you see.

Here are a few comparison shots(at the same ambient and screen brightness levels):

How is your UI set up?

I recently changed my office suite as I swapped over to the Treo 600. The new office suite has a funky spellcheck - funky until you try to get suggestions:

Most people(including me) assume that one can click into rectangles to execute the action contained within. But not so in this example - you need to click onto the words…

Once a user has understood and accepted a pattern, unlearning it is very hard. Forcing your user to unlearn makes the UI less usable - if there is no real speed benefit, it usually isn’t worth it!

I use foo for sorting/renaming photos in ‘bulk’ on my Palm Tungsten T3 after loading them off my digital camera. One of the things that make this process annoying and slow is this dialog:

After an image has been renamed successfully(!!!), this dialog pops up. This is annoying and takes an extra tap to dismiss - but it gets even better.

When renaming fails, a dialog that looks very similar to this one pops up. But since users are trained to dismiss all foo dialogs automatically, they will probably ignore it and wonder about what happened.

The moral of today’s story is simple: users don’t like reading - so keep the hard work for the times its really needed!

BTW, on futile prohibitions covered a similar problem… . Ah, and there is another example right here.

Technorati tags:
GUI design
UI design