[UX-WEEK 1] Preferences dialogs (should be: "Settings")
 

Welcome to the first iteration (a test drive so to speak) of the Maemo User Experience Week! We want to concentrate on one part of our apps' UIs every week, and we start out with preferences dialogs. See the original idea post for background information.

The vote is closed now (after just one day, but a trial run should be done as early as possible, and it's Sunday already).

This means that we are concentrating on preferences dialogs this week:

• Post screenshots of the preferences dialogs of all apps and widgets you have installed
• Describe the behaviour of the dialog, especially unclear elements
• Show the UI to your friends and tell them to interact with it and note any questions or errors
• Also note things and settings there were well implemented and work well.

Based on this, we can then work on improvement concepts. Please also contact the developers of affected applications so they can chime in in the discussion :)

What do we expect as a result of this week?

• A list of best practices for preferences dialog design on Maemo 5
• Example screenshots of good dialogs (and why they are good)
• Example screenshots of bad dialogs (and why they are bad + improvement suggestions)
• Developers of affected apps contacted and provided with mock-ups, patches, .ui files, etc..

(We will probably create a Wiki page for the results at some point, but until we have figured out exactly how the process works, just start getting productive in this thread! :))

Re: [UX-WEEK 1] Preferences dialogs
 

Well I don't know if it qualifies as a "preferences dialog" but there is one glaring example of poor ui design that's annoyed me repeatedly, and that's in use in several places in the standard ui. This is a case of "looks good but gets in the way of getting the job done"

I'm talking about the time picker. Quick way to see this is to add a new alarm, and set the time. Do this and you're presented with two lists one with 24 and one with 60 items. Yes it looks good, but it's nowhere near as effficient as an numeric keypad and a text field would be.

Further problems with the time picker:
- There is also no wraparound in the list so you can't go from 00 minutes to 59. Meaning when it suggests x:00 but I want x:50 i'll have to scroll past 50 entries in a list.
- No keyboard input.

Lesson learned:
When making the user pick from a list, if the list is long then consider alternatives.

Re: [UX-WEEK 1] Preferences dialogs
 

I personally love the time picker and think it is one of the better examples of maemo ux.

a form box would be annoying... first i have to open they keyboard, then activate function lock then type it all in. the current set-up is fluid and fits in with my previous interactions with the device until that point (touch to navigate to the option from menu)

As for OP. I'll think more on it and post when I get home from work

Agreed though that keyboard shortcuts inbuilt could be useful because it increases the way people can interact with the menu...

Re: [UX-WEEK 1] Preferences dialogs
 

Let me kick this off with easyplayer - a very nice file-based music player that I have installed recently. Attached you will find two screenshots of the preferences window. Some remarks (please feel free to comment on these):

• "Preferences" here is a window, not a dialog (should be a dialog to fit with the rest of Maemo?)
• "Use big buttons" does nothing or at least nothing obvious - maybe change the text to better describe what it does
• The "Stop playing after:" and "Display remaining time until timeout" belong together somehow - they should be grouped visually (e.g. a header "Timeout" for both buttons and remove the "until timeout" from the "Display remaining time" button)
• The buttons are thumb sized - i know of other preferences dialogs that have finger-sized buttons; ideally, to create a "balanced look", preferences dialog should have the same button sizes (exceptions should be justified)
• Is it really necessary to have a text input field for the "Stop playing after" selector? There are 6 elements in this list (5 min, 10 min, 20 min, 30 min, 60 min and never) and the list displays 4 elements at the moment, without the entry field 5 elements are visible
• Often there are choices where the user can select some interval or "never" - should this "never be placed at the beginning or the end of the list? Here, "never" is the last element, other apps place "never" where 0 would be placed (I personally prefer to have "never" sit where 0 would be placed. i.e. *before* all other items)

Re: [UX-WEEK 1] Preferences dialogs
 

Thank you! Since I'm the developer of EasyPlayer I'll have to say that EasyPlayer is WIP and ideas for improvements are very welcome. I'll mostly concentrate on the program code itself, and so there is of course room for usability improvements. I have to admit that my time is limited (job and family, an old house in need of repair :), so don't expect that everything will happen quick.

Well, I am used to C and embedded development, so Python and gtk+ are just things I am learning. So I did the preferences dialog the first way I found. I just didn't notice that most other programs do this in an dialog. I'll put this on the ToDo list - if this is really that important...[1]

and

belong together. If you set "use big buttons", the buttens are thumb sized after an restart. Try it! But I want to remove that entry anyway and replace it with a switch to choose a more simpler UI - just three big buttons (Prev, Play/Pause, Next), a big progress bar and maybe a smaller TreeView widget containing the audio files.

This could be done easily.

Same here as for [1]. Did it the first way I found...

Well, I think that's very personal. I really don't care about that and changing this would be very easy, but will make old preferences entries faulty. Indeed, you can get around this by manipulating the code...

Besides that I recommend to send me an email if you have some kind of improvements - I really don't read everything at talk.maemo.org - I normally prefer the mailing list. I wouldn't have seen this threat if Thomas haven't send me an email.

Yours, -Klaus

Re: [UX-WEEK 1] Preferences dialogs
 

I wanted to post this up from nclock as I struggled with many hours to make it look nice. In the end I decided to use radio buttons inside a GroupBox with custom graphics that keeps the N900 black bue and white look.

I think devs also need help on making the most of Qt as some of the clever things are not always obvious.

I'm not very happy with the stock Qt File Dialog, which a lot of people will use, and would like thoughts on that.

I am very happy to take thoughts and improvements.

http://farm5.static.flickr.com/4015/...e5aa5f82_o.png

Re: [UX-WEEK 1] Preferences dialogs
 

I agree with most of what you (thp) said, apart from this last item. In this instance, when defining a timeout, I think Never fits more logically at the bottom of the list, as it is "further away" than 60 minutes.

I attach a screenshot from the Gnome Power Management preferences, where you'll see that they also put Never at the end on a similar thing that is defining a timeout.

Incidentally, from that Gnome screenshot, it would be nice to see text like that appear in easyplayer too, i.e. "20 minutes" instead of "20 min" and "1 hour" instead of "60 min".

Re: [UX-WEEK 1] Preferences dialogs
 

Some general comments:

Most built-in Nokia apps, if they have such a menu item, use the word "Settings" in their menu, apart from Web which uses "Options" (although that has a "Settings" item within it!). None of the built-in apps use the word "Preferences".

It is worth reading the style guide documents: Fremantle Master Layout Guide, Hildon 2.2 UI Style Guide and Hildon 2.2 Widget UI Specification, as they mention some useful things.

For example, dialogues containing one item should have a "Done" button. Dialogues containing multiple items should have a "Save" button. "OK" and "Cancel" should not be used. Clicking outside the dialogue should be used to cancel (i.e. not save) changes.

Re: [UX-WEEK 1] Preferences dialogs
 

Ok, that makes sense. I don't really care at which position it is, but it should be the same across the platform. That's one "rule" we want to find out that we can then put on a Wiki page for developers to follow, which hopefully results in a more consistent and usable UI :)

I'll have to fix this in the gPodder preferences dialog then, attached a screenshot of the current selector dialog - the "never" in this case is called "manually", as checking for new episodes can be done manually (by clicking a button) or at a selected interval. Question: Should this be named "never", too? ("Check for new episodes - never" does not really sound good to me, as it's not "never" but "only when I click the button").

Very well spotted! I haven't thought about that. I guess we should add this as "best practice" too ("If time amounts are to be selected, use '1 minute', '2 minutes' and '1 hour', etc.. as wording" or something like that).

Re: [UX-WEEK 1] Preferences dialogs
 

Conboy
Please see attached screenshot of Settings dialogue from Conboy 0.6.3.

My opinions:

• No Save button - tapping above the dialogue saves, which is incorrect Maemo 5 style
• Instead of a tickbox for "Use automatic portrait mode", it would be nice to see a choice of Landscape, Portrait, Automatic, as some other apps offer.
• Instead of the "Use custom colors" tickbox and the colours below being ungreyed out when ticking the box, maybe the tickbox should be a button instead (called just "Colors") which brings up a further dialogue to select the colours. The greyed-out colours look a bit messy at the moment.
• The list of backends (just one item at the moment, XML Storage Backend) could be hidden behind a "Backends" button or similar. At the moment, it is not obvious that the bottom-right spanner and (i) icons refer to the XML Storage Backend as opposed to the entire app.