So far, no collection of design patterns for mobile applications has been published in book form. However, the design4mobile wiki is a more than adequate replacement:

Hit the link below to find out more:
http://patterns.design4mobile.com/index.php/Main_Page

Alice started out by presenting a few cases of extremely bad design:

According to her, catastrophes like the ones above are caused by a wrong approach to design – it does not consider the user:

The solution is called user-centric design…which means putting the user at the center of the development process:

Understanding users can be difficult – the slide below presents an overview of users needs:

Prototypes are very useful when it comes to figuring out how users “tick”:

Unfortunately, user tests are not easy. Their experience showed them that users should not be given too many tasks at a time (among other things):

Users must be monitored discreetly, as their behavior changes the moment they feel monitored:

Point-of-view cameras can be useful:

Alternatively, a screencast solution can be used:

When it comes to determining the users, a surprising thing pops up: 5 users are usually enough to find 85% of all eekers; whereas 15 are likely to find all of them according to J Nielsen:

The next surprise: advanced users loathed their simple application. Some missed core features, while others felt that the program was “too lowly” for their taste:

The texter refers to “Yes” and “No”, but the UI designer decided to deploy graphical widgets which don’t wear these labels. While we (aka the readers of TamsPalm) should be able to figure it out quickly, other users may take a few seconds (and will be frustrated if their machine reboots due to them making a wrong choice).

When it comes to alerts (deciding about very important things), definitely stick to your system’s UI conventions at all cost. Not doing so will probably land you on TamsPalm, and will get you a bunch of unhappy users…

What do you think?

The two images above show an application by an apprentice developer of mine who didn’t quite learn the lesson yet. They were both made on a Treo 680 with the backlight turned off – while the high-key theme remains viewable, the content on the low-key theme is very hard to see.

Today’s “lesson” is short and sweet: while low-key themes may look lovely indoors, customers using their devices outdoors will have huge issues seeing them. Even though it sounds unlogical (the contrast stays the same): the proof is above…

Any ideas, anyone?

• 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

“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.

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?

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!

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

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