Usability Review of OpenMoko GTK+ Applications

Kevin Dean kevin at foreverdean.info
Tue Mar 11 18:37:57 CET 2008


Having poked around with lots and lots of features doing my reviews
I've got a "feel" for what works and what doesn't, based on MY usage.
So I thought I'd chime in here. :) Understand that I'm not much of a
developer so some of my suggestions may be nightmares to impliment in
code. :)

>
>
>  Regards,
>
>  Thomas
>
>  --
>  OpenedHand Ltd.
>
>  Unit


>  > Isn't the power button enough for quitting running apps? I wouldn't add
>  > anything to the app list - to fiddely. KISS...

I have to agree here that the hardware buttons are crap as a solution
to killing running applications. The way I use the device I have to
re-position in order to press that button. Also, I've got rather large
hands (to the point where when many remark about the Neo being "too
big" I find it a nice fit) and I end up pushing the edge of the button
more than the button itself with no response. While driving, I find it
is safer and easier to just leave applications running and let the
phone lock than to kill the applications because to close it would
require two hands. Luckily dialer kills itself when calls end.



>  > The toolbar button on the top give quick access to the most wanted
>  > functions: "send sms", "call", "add new contact" - I use them a lot and
>  > think they are very useful.
>
>  I would suggest moving them to the details page. As long as the
>  switching between list and details is quick enough, I think this
>  wouldn't be a problem.

I agree that having quick access to the major functionality of the
device is important, but I think it MUST be on the front screen. In
fact, my complaint with the top menu bar is the opposite of what you
two have mentioned. I believe that each "function" of the phone should
be represented here. For instance, dialer should have a quick launch
feature here but so should media player, since it's one of the
"primary" device features. The device's selling point also comes from
being GPS enabled, so a button for that should be there too, IMO.

At current there is a LOT of unused space on the screen. Do we really
need the clock taking up the vast majority of the usable space? By
moving or replacing the clock it would be possible to make thumb
navigation much easier as well as enabling more consistant access to
the features of the Neo device. Qtopia and iPhone both have interfaces
more akin to what I consider to be usable, but on both cases I think
they become overwhelmingly cluttered too. If OM could strike that
balance it would be quite a dramatic impact.


>  I think this is a good point. Perhaps the main problem I have is that
>  new users find it very difficult to locate the details button. Perhaps
>  we need to make it more obvious. How about replacing the new button with
>  edit, and moving new into a menu? Presumable Edit will be used much more
>  often than New.

Rather than fixing the list/select method, can we really think for the
moment if the list paradigm works for a device like the Neo? It's
quite clear that users have issues selecting the correct item on the
list. Rather than making them fumble with the list twice, thrice or
more times and then confirm their selection, I think it would be MUCH
better and appealing to a consumer to eliminate the fumbling rather
than by compensating for it.


>  > > * Remove communication history page(?)
>  >
>  > So far everyone told me that this is a cool feature missing on all other
>  > phones. I love it ;-)
>
>  Interesting, I guess I rarely look at my call history anyway. You can't
>  do any thing with it, so I don't really see what it's usefulness is.

I think that is a problem of missing functionality, not undesired
functionality. On every other device I've used, the call history
served two functions. 1.) To make corresponding one-touch simple. I
could open the call list, highlight a number I called earlier and
click "Dial".

In specific, when I use this feature the most is when I have a one-off
issue. Having bought a car recently, I made a LOT of calls to dealers.
I don't have these numbers in my phone book because I don't need them
there permanently but during that call-around phase I played a LOT of
phone tag with people, not having to manually enter in their number
each time, having it on hand and easily usable is a massive time
saver.

The second purpose of the call history is actually it's purpose,
having a call history. Often times this comes back to the one-off
thing. Being married, my wife and I often tag-team places. We'll
alternate calls when attempting to resolve bank issues or make bill
payments or whatever. Being able to hand my phone over to her to grab
the number and dial on her phone is MUCH easier than having to go back
online and pull up the business profile, find the number and enter it
manually.

>  > What I mostly miss:
>  > - a category "mobile" for the type of phone number
>
>  Probably a one line patch.
>
>  > - more contact details
>
>  Such as? I didn't want to make it too complicated here. Phone, E-mail
>  and Address and Company seemed the most likely used fields to me.

Why can't this be user configurable? Personally, I couldn't care less
about someone's address because if I need it frequently, I know how to
drive there. I don't send snailmail. I also couldn't care less about
what company someone works for. If it's a business contact, I already
know who they work for since they have something I need. If it's a
personal contact it doesn't matter because their company doesn't
matter in my dealings with them.

What would be quite useful for ME, however, is a birthday field.

I'm not advocating that birthday be put in or that others be removed,
but assuming that we know what kind of information a user considers
important about their contacts is wrong. Furthermore, with a phone
focused on "Freeing your phone" and appealing to mass market consumers
we need to make it flexible enough to feel "tailored" to them and
simple enough that it doesn't require patches and recompiles. In
advocating GNU/Linux in general, people don't care about the
flexibility of the code since they're not coders so the benefit is
moot to them. Advertising a flexible, free platform is all well and
good for hackers, but users will see that as a false claim unless you
make it easy.


>  > - a remarks field
>
>  Personally, I can't really see how this makes sense in a contacts
>  application. Keeping it simple as possible was my main goal.

Many people (such as my wife) literally attach three fields to her
contacts - name, phone number and ringtone. As I see it, giving the
user that control is more important than keeping things simple.
Envision as "basic mode" where a user can select an icon, ringtone,
input a name and number and press "Save". If you want to add a company
name, e-mail address, secondary phone number, spouse's name, favorite
color, favorite beer, blood type and MSN address, cool. In displaying
the contact to the user, silently drop the empty fields. Qtopia
displays "Company" even if the field is empty and it looks cluttered.
If OM kept it VERY simple, allowed advanced fields and dropped empty
sets the user would ALWAYS see ONLY the fields they consider
important.

>  > > The icons in the bar at the top of the screen should not be interactive,
>  > > as they are too small to use with a finger. This means all the top icons
>  > > should not respond to clicks and it should be used for displaying status
>  > > only.
>  >
>  > Not everything needs to be finger usable - actually I wouldn't give up
>  > on the icon responses, I use them a lot and would even extend them. When
>  > I have a stylus then I can gain quick access, when I don't then I go
>  > through the Today Application.
>  >
>  > Especially as we have such a high resolution screen which is just fun to
>  > use with a stylus too, not just with the fingers.
>
>  I can't see the link between high resolution and stylus usability.
>  Surely higher resolution makes it even more difficult to be accurate!
>
>  Anyway, as the Neo does not have a stylus holder, it'd be really nice if
>  the interface was fully usable without a stylus. This includes not
>  accidentally clicking status icons with your thumb.

My stylus has been relegated to a cat toy, frankly. Because the Neo
doesn't NEATLY hide the stylus it's "one more thing" I have to pack.
Since I'm not used to packing it, I've frequently forgotten it. If the
stylus isn't empowering the user it's merely a burden. For me, it was
a burden.

There's a caveat there - I use my car key as a stylus. My car key is
about half the size of my pinky finger and I think it works well
enouhg for MOST things but the things that do not work never get used.
This means that almost all of the games shipped on a default image do
not get used because they REQUIRE a stylus.

Add me FIRMLY to the "if it can't be finger controlled, it doesn't work" camp.

Re: Status bar. I beleive that the status bar should be just that,
indicators. The "click to power on Bluetooth" should either be
relegated to a settings panel (if it's considered a minor features,
which I'd agree with) OR made as prominent as dialer if it's
considered a major feature. Likewise, the GPS menu is what I'd
consider a "major" feature, and consider relegating control of it to a
small applet to be a critical mistake.

What I'd like to see in the status bar is essentially a battery life
indicator, GSM signal meter (this is even debatable. AT&T in the USA
likes to advertise "More bars in more places" which is a massive
gimmick since a "bar" doesn't mean the same thing from phone to phone.
Either you can make calls or not. :) ) and clock. None of those would
be interactive.

I should also note there that I love out current notification method
though (like when you have a missed call or SMS messgage) and would
hate to see those relegated to a status icon like on many Motorola
phones. :(


>  > > Application menus could be made accessible by either the left of the top
>  > > status bar (with appropriate indicator next to the application name), or
>  > > from an extra button in the bottom bar.
>  >
>  > IMHO menues should be up to the applications - for the window manager
>  > the mantra should be: KISS, keep it simple, stupid.
>  >
>  > Plus: many apps don't need an application menu bar - think of the dialer
>  > and the calculator. Menu bars are an old relict from the 80ies - if
>  > there is a good thing about Web2.0 then it is the death of menu bars :)
>
>
>  I definitely don't want to see menubars! Also, I want a "application
>  menu" button to appear only if the application has a menu. The fact is,
>  some applications are bound to require menus to keep their main
>  interface clear, so we should provide a convenient place for the menu to
>  appear from, rather than having a menubar take up more space in the UI.

I agree here. A truely "open" phone needs to be able to handle menus
so that user-added apps will work. At the same time, I think menus are
a HORRID choice inside OM apps. My second complaint with the games
shipped with OM would be the use of menus (with #1 being requirement
of a stylus). Icons work better for naviagation on small screens and
consistancy provides polish to a device and makes it easier to "get a
hang of".

> > > If it is not possible to bring up the keyboard on entry tap, then it
>  > > should be enabled and disabled by a button in the bottom bar.
>  >
>  > A bottom bar is the wrong solution for the problem (of only two hardware
>  > buttons). Again this could be done with the second hardware button,
>  > adding a button to the aux menu. The bottom button bar will most of the
>  > time eat valuable screen estate.
>
>  Again, personally I don't see any of the hardware buttons on the Neo as
>  usable, except for turning on and off the phone and perhaps unlocking
>  it.


I again agree with the "don't use the hardware" sentiment. I also
agree that not being able to call up the keyboard on demand is a
drawback. That said, the current keyboard is being redone, there's a
TON of input (no pun intended) that has already gone into it. Raster
is implimenting something that should be more suited to OM, hopefully
will be tied to an on-demand input control and will be predictive to
reduce the number of redundant keypresses per word/statement.

IIRC he is also planning on making it "QWERTY like". One complaint I
have with the multi-tap is that it can't "tell" what the field is -
entering a phone number requires two key presses simply to make the
device display numbers. In a QWERTY style keyboard, numbers and
characters are both there so the "type" of input field is irrelevant.
In a limited set keyboard, it WOULD be quite handy if fields could
specify their main type so the keyboard could select it's default
display mode.

But I think it's hard to speculate here since we know something is
coming and that change might render a lot of input discussion moot.

-Kevin Dean



More information about the openmoko-devel mailing list