Jose Manrique Lopez de la Fuente
jsmanrique at gmail.com
Wed Jun 6 14:02:41 CEST 2007
I think somekind of "guidelines" for developers are needed. Perhaps
FIC could release their own ones, and some external read could help:
Nokia usability site:
And perhaps OpenMoko could get some feedback from Maemo or
2007/6/6, Fabien <fleutot+openmoko at gmail.com>:
> On 6/6/07, Casper van Donderen <casper_de_dondergod at hotmail.com> wrote:
> > Can you still edit that main panel [...] because the color of choice at
> the moment is orange [...]
> I think that when we talk about UI, we don't primarily think of skins and
> colors: these rather fall in the "bells & whistle" category. What makes a UI
> good or bad are rather questions like (examples):
> - does it take many clicks to register an unknown caller's number in the
> phonebook? Can I easily extract phone numbers from SMS bodies?
> - is the menu organized in a sensible way, or do I need to know that in
> order to *stop* the system I have to click on the "start" menu button? (a
> favorite of mine on windows pocket: if you click OK after having types a
> SMS/e-mail, it cancels it instead of sending it).
> - there's a limited space for shortcuts. Is the phone configured so that
> default shortcuts actually correspond to the most common actions? How far
> can I customize it, if the default shortcuts don't fit my usage scheme?
> - screen estate is also a valuable asset. Is it attributed wisely, with more
> space devoted to widgets I'm most likely to use, or is there a pointless
> whirling logo that takes half of the screen and forbids me from reading an
> e-mail fullscreen?
> - if I've typed an e-mail, changed my mind and decide to send it as an SMS,
> how easy is it? Conversely, if 99% of what I send are SMS, and only 1%
> e-mail, I won't be happy if I need to answer 5 modal dialogs asking me
> questions which don't make sens for an SMS. Generally speaking, modal
> dialogs are extremely obtrusive, and should only be used when something
> *serious* happened.
> - I don't mind alpha blending effects and stuff like that, *provided that it
> doesn't break responsiveness*. If it takes 3 seconds to open a text composer
> due to an impressive animated logo, by the 3rd time I'll use it I won't
> think "woot, neat animation!" anymore, but rather "stop wasting my time and
> CPU cycles, and bring me my fucking editor RIGHT NOW!"
> - If I'm in front of a building requiring a entrance code, and I know I've
> got that code somewhere in my phone, but I'm not quite sure about the
> reception date, nor whether it was a mail, an SMS or a note I typed myself,
> how tedious will be the search? Will I have to put up with some braindead
> interface inspired by "clippy the MS-Office trombone"? Will there be enough
> search criterions? Conversely, will I have to fill a 3 pages form before
> every trivial search request?
> - will I need to spend 1/2h configuring a PC to talk with my phone, or will
> it simply be seen as a USB thumbdrive?
> Look at Steve Jobs' first presentation, it was straight-to-the-point. What
> iPhone users will love are stuff like:
> - easy, reliable, unobtrusive unlocking mechanism
> - every relevant feature can be reached in 3 or 4 clicks, and these click
> sequences are easy to remember because they follow common sense.
> - no need to navigate through 12 menus to rotate your navigator, so that you
> can read a page not designed for mobile devices (users of winCE know what I
> - you won't accidentally press touches with your cheek when phoning, thanks
> to the cheek-clicking protection mechanism.
> - it's fast and easy to retrieve a contact number, even in real-life
> conditions ( e.g. on a bicycle, with direct sunlight on the screen, and no
> way to hold a stylus)
> All of these stuff aren't impressive because they require l33t coding
> skillz: they're impressive because they correctly anticipate the way real
> users will use the phone in their real lives. That's much more important,
> and much more difficult to get right, than 3D glowing and spinning widgets.
> And I think openmoko can lead to real improvements in this domain, if:
> - the UI is easy to modify, so that experiments aren't too expensive (I'm
> talking about global reorganizations here, not about color schemes tuning)
> - there's an efficient feedback system, typically a set of wiki pages
> dedicated to ergonomics, field usage reports, polls, etc.
> - some people with the right social skills make the UI improvement effort
> run smoothly.
> These are stuff which only open source can do correctly, which is excellent
> news for openmoko.
> OpenMoko community mailing list
> community at lists.openmoko.org
J. Manrique López de la Fuente
msn: jsmanrique at asturlinux.org
jabber: jsmanrique at jabber.org
More information about the community