Some years ago, reading emails on mobile devices was an acitivity which was, at minimal, uncommon – today, one can say that a huge amount of emails gets read on the run.

This – coupled with ever-improving HTML rendering on mobile devices – makes taking a look at how people read their email on the run interesting. A mass mailing company named MailChimp has compiled a fascinating report, which makes very good late-night reading.

Find out more via the URL below:
http://mailchimp.com/resources/guides/html/email-on-mobile-devices/

Most usability designers consider teenagers the omnivores of the genus user – common belief is that they will figure out just about anything as long as it is endorsed by the celebrity du jour.

useit.com, a UI and web usability house, has now performed an analysis of “the teenager” – and ended up with the like/dislike table below:
teenager web site design Web design for teenagers

Find out more on the topic via the URL below:
http://www.useit.com/alertbox/teenagers.html

Long-term followers of Tamoggemon know that the products usually have a minimized interface – this is due to fanatic tap counting in the UI design department. However, tap counting is but part of a successful mobile UI – you usually also need to adhere to common design patterns.

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:
mobile design patterns Mobile Design Patterns   the list

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

Don’t ask me why a presentation on user interface design made it into the IEEE proceedings schedule of the FH Hagenberg’s NFC Congress. Nevertheless, being the UI fetishist I am, Alice Moroni’s presentation struck my interest. Enjoy:

Alice started out by presenting a few cases of extremely bad design:
0 On sensible user interface design

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

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

Understanding users can be difficult – the slide below presents an overview of users needs:
3 On sensible user interface design

Prototypes are very useful when it comes to figuring out how users “tick”:
4 On sensible user interface design

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):
5 On sensible user interface design

Users must be monitored discreetly, as their behavior changes the moment they feel monitored:
6 On sensible user interface design

Point-of-view cameras can be useful:
7 On sensible user interface design

Alternatively, a screencast solution can be used:
8 On sensible user interface design

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:
9 On sensible user interface design

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:
10 On sensible user interface design

I have never been too much a friend of so-called graphical buttons – coming from the depths of Windows 3.xx, I am accustomed to having text captions on buttons. While this may look boring, the dialog below shows why it has its merits:
idiotgui Stupid & in love with widgets

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?

Critics frequently accuse me of being a bigot who hates low-key color themes. While the idea of considering competitors bigots may be appealing to some, I bring you yet another proof why black-on-white rocks:
24082008267 On low key color themes 24082008268 On low key color themes

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?

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

Present OpenMoko Theme Project for Palm OS   Released!

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):

Image1
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:

Image2

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!

Image3

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.

Image4Image5

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:
radio0 Using radio buttons as command buttons is a bad idea

Clicking on Font pops up the font selection dialog(there’s FontBucket behind that btw – TamsPalm’s tutorials really do work):
radio1 Using radio buttons as command buttons is a bad idea

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   on changing an applications look and feel

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:
 Firefox 2.0   on changing an applications look and feel

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!

© 2013 TamsPalm - the Palm OS / web OS Blog Suffusion theme by Sayontan Sinha