Born: June 9, 1972
« Odd watch, new eyes? | Home | Tiny Tiny RSS... »
August 24, 2007 at 3:37 pm
Maemo UI design...
Over the past couple of weeks, I’ve been spending some time writing a document called, “An Unofficial Guide to Creating a Most Excellent maemo User Interface.” Maemo, if you don’t know, is the open-source development platform that applications are created under for the Nokia Internet Tablets (currently, the 770 and the N800). The document has just gone to beta, so I thought it would be a good time to mention something about it publicly.
The guide has turned out to be around 25-pages, complete with case studies, graphical examples, etc. In fact, here is the description that I entered when creating a project page at the maemo Garage:
“An Unofficial Guide to Creating a Most Excellent Maemo User Interface” is a hands-on description of concepts that developers should consider while creating user interfaces for their applications. It is written by a designer, not a developer, and stresses the importance of user-centered UI design. The document integrates high-level concepts with two case studies of fictitious applications. Each example includes screen shots of the UI concepts being discussed. Other topics include the overall layout of a UI within the maemo application environment, the proper uses of Dialog boxes, Notifications, Progress indicators, buttons, etc. Also provided are links to many useful maemo-related web pages, UI reference documentation, sample applications, etc.
This document is “unofficial” in that the author is not employed by Nokia or the maemo development team. The information contained within is primarily a well-educated opinion that relies on current maemo documentation and feedback provided by official maemo developers. All UI elements match current maemo literature and an attempt has been made to follow the current SDK (Bora 3.x) guidlines, as well as the one to follow (Chinook 4.x).
This project is pretty exciting for several reasons.
First, as far as I know, there is nothing like it available to maemo application developers. There is an “official” maemo UI guide (here), but it is pretty basic and it doesn’t actually delve into the process of integrating UI concepts into application development. In any case, even if a document like this already exsists, one of the reason why I feel that this one will be valuable is because it is written by a designer who has worked with programmers for a very long time — not the other way around.
Second, I have been able to connect with a few “official” maemo developers (i.e., Nokia employees) and they have been helping me with a little feedback and direction while trying to assemble my thoughts.
Third, because it has given me a good chance to try out Google Docs for the first time. Google Docs is very cool in a lot of ways (for one, I was able to import my original Open Document Format with ease) and not so cool in others (the HTML that Google Docs generates is far from clean). Over all, Google Docs not only lets one write and format douments online, but those documents can be shared with other contributors and viewers as well (almost like a wiki).
If you’d like to take a look at what I’ve been working on, please click here. Keep in mind that the Google Docs version of this guide is a living version and is likely to change over the course of time.
Digg This Story | 
Save This Page
No Trackbacks
Trackback Link:
Comments (11)
As far as Confirmations on Quit… I see your point. But, with Closing applications being so easy (to do by mistake) on a mobile device, I tend to disagree. Of course, thiss may change as time goes on.
However, I strongly disagree with “If an application does not require any settings, the Settings option should still trigger a window to open. This window should contain a message akin to “This application does not require any settings.””.
The point of a contextually aware UI is that it adapts to the user’s input, not being able to adjust itself to a build-time decision to have no settings means that Tools > Settings should not be present. (It shouldn’t be greyed out as there is no action the user can take to enable it).
Yes, having “Tools” being consistent is important, but any user exploring the application for this first time will be turned off by a blind alley that tells them “this application has no settings”.
I also agree with the above comment, if there’s no unsaved data and/or restarting the application will bring it back in the same state, there should be no quit confirmation – starting applications is a practically zero-cost operation; but confirming dialogues disrupts users’ patterns of work.
I like the “grayed-out Settings” idea. I will think more about it.
Re: Close Confirmations… I’m really thinking consistency in this case. Not all apps that don’t have save states should Close without Confirmation notes. Consider apps that can have multiple windows open aat one time (Claws-Mail and Pidgin, to name a couple) In these cases, open windows should Close without Confirmation, but the app should have one — so that tap-happy users don’t accidentally Close the main window of the app.
- I agree with Aflegg/Tuukka: Confirmations should be displayed only in the cases if the action is non-reversible without losing something. So that if you have a modified and unsaved document open and you try to close the app, it should ask. If it is stored and everything is fine, closing should be possible without a confirmation. We aren’t fully following this rule ourselves even, but we will certainly improve on this. Also in the future, the more undo/revert capabilities there will be, the less confirmations we will need to show. – For application menus: If there are no Settings, there is no need to show a settings command. Dimming isn’t also ideal: Dimming in menus should be used in the cases where in some modes of the application the command can function, but at this particular moment not. Suppose there is a calling application and a “Disconnect” menu option, it is dimmed if there is no call running.
I’m thinking my Menu description needs some reworking as well. Something needs to be done about instituting more rigorous standards in this area, though… More to come.
I just had a very quick look at the doc and I have a suggestion.
- On the About box, the return button is on the left.
- On the login dialog, the Ok is on the right.
- On the FaceBook status updater, it is in the center.
- On the FaceBook Status Updated Message box, the ok is on the Left.
- On the FaceBook connection lost massage box, ok is on the left.
- On the quit confirmation, Cancel in on the left.
Well you get the idea. I think it could be enhanced by putting the Ok always at the same place. On my gnome desktop, most of the OK buttons are on the lower right corner (I read somewhere that it is a sound choice). I have not read it, but I know that there is a gnome manual for user interface design and I believe that there are some explanations for this choice (as well as many more quidelines).
I read also a good document criticizing the maemo user interface and comparing the N800 with Apple Newton. A very interesting read from user interface standpoint: http://cs.gmu.edu/%7Esean/stuff/n800/
Guillaume.
Yes, there still are a few things to “tighten” up. This is still currently a working document and I will look into the issues that you brought up.
Also, I’ve read Sean Luke’s write-up — before I bought my N800, in fact — it is very good. I’ll take another look. But, I’m not here to criticise, just to help people work within the existing environment.
Antoine ~ Thanks. I hope it does too!