Usability Review of OpenMoko GTK+ Applications

Carsten Haitzler (The Rasterman) raster at openmoko.org
Wed Mar 12 06:26:36 CET 2008


On Mon, 10 Mar 2008 13:27:35 +0000 Thomas Wood <thomas at openedhand.com> babbled:

> 
> I've been thinking about the usability of the GTK+ based OpenMoko
> applications and I have come up with some suggestions I'd like to
> implement.
> 
> We only spent one day in the office designing these applications,
> because at the time they were only going to be proof of concept ideas.
> Therefore, we need to revisit the design, find the mistakes and work on
> improving usability. 

fair enough. no idea how long u spent on them to start with.

> These are just a few ideas I've come up with so far. Some of them are
> more work than others, but I think they would all help improve
> usability.
> 
> 
> Today Application
> -----------------
> 
> The current "today" application has three pages. A summary screen, an
> application list and a running application list.
> 
> My suggestions are:
> 
> * Remove the running application list - this is a desktop paradigm that
> has no place on an embedded device
>
> * Add a running indicator and a close button to items in the application
> list if they are running. This is really a work around  as we do not
> have proper session management yet, but it is nicer than having two
> separate lists for applications.

this sounds nice - though i don't think this is a major issue. i'd put this at
the end of things to do :) i don't think a list of running apps is bad. as such
i would advocate a close button or menu item on the title region. as long as u
can run multiple apps having a quick way to close it is important. the list of
running apps imho is fine. an extra indicator in the apps list as to if its
running is of course very useful

> Contacts Application
> --------------------
> 
> * Remove tabs from bottom and buttons from top of index page

agnostic here but you need a "add new" contact button there somewhere. i'd
leave it down to:

* list of contacts (much bigger font so its hittable with a finger)
* an add button.
* click on any to bring up contact details

> * Switch to a contact details when list item is clicked

absolutely! a must!

> * Add groups button to toolbar in details page

moot really i think. groups are a feature i'd leave out for now.

> * Remove communication history page(?)

probably useless for now - good in principle, but lets get core stuff seamless
first. so agree.

contact details just need a "call", "sms", "edit" and "delete" button. maybe
moving to text labels from icons overall will help a lot. the icons tend to be
very non-intuitive as to what they do. as a quick measure for now - just back
to labels.

> Status bar
> ----------
> 
> 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.

agreed.

> I'd like to suggest adding a bar at the bottom of the screen that is
> divided equally into three or less buttons. One of these buttons would
> be used for taking the user back to the home screen.

ok - other than using more screen space i don't mind the idea. makes sense. as
i mentioned above - a close in the menu would be good

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

sure. along with a close in that menu... always put there by the desktop (NOT
the app. not a voluntary thing).

> Keyboard
> --------
> 
> They keyboard should only pop-up when a user explicitly requests it.
> Usually this is most conveniently done by popping up the keyboard when a
> user taps inside an entry field. Eventually it would also be nice to be
> able to switch between different types of keyboard, but the multi-tap
> should be enough for now.

sure. i agree on this. also somewhere else a button outside an app/widget to
pop it up will be needed for apps that don't send the right messages ported
from other toolkits (eg EFL or SDL - tho EFL does have hildon support now for
this). you will need a way to manually drive it.

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

bingo. agree. maybe the bottom bar should be hidden much like the keyboard...
and pop up when requested from another button at the top? (eg click the
titlebar and up comes our bottom-bar with all the controls)

> Theme
> -----
> 
> The biggest problem with the current theme is performance. The main
> issue here is the use of gradients which requires either stretching
> images or dithering (for 16bit display). Both these are a significant
> performance hit, so I would like to suggest redesigning the theme to be
> faster and more efficient.

yes. just go for a solid color. lets make it simple and decide on fancy later
when glamo accel is more fully done.

> These are just a couple of first thoughts, so I would like to discuss
> them further.
> 
> Regards,
> 
> Thomas
> 
> 
> -- 
> OpenedHand Ltd.
> 
> Unit R Homesdale Business Center / 216-218 Homesdale Road /
> Bromley / BR1 2QZ / UK             Tel: +44 (0)20 8819 6559
> 
> Expert Open Source For Consumer Devices - http://o-hand.com/
> ------------------------------------------------------------
> 
> 


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>



More information about the openmoko-devel mailing list