Active Topics
-
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 20 hrs, 13 mins ago - more...
| The Following 10 Users Say Thank You to thp For This Useful Post: | ||
|
2010-04-11
, 21:10
|
|
Posts: 86 |
Thanked: 199 times |
Joined on Apr 2010
|
#2
|
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.
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.
 |
|
2010-04-11
, 22:07
|
|
Posts: 57 |
Thanked: 26 times |
Joined on Feb 2010
@ Melbourne, Australia
|
#3
|
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...
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...
 |
|
2010-04-12
, 09:31
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#4
|
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)
|
|
2010-04-12
, 20:28
|
|
Posts: 28 |
Thanked: 28 times |
Joined on Jul 2009
|
#5
|
Originally Posted by thp
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
Let me kick this off with easyplayer - a very nice file-based music player that I have installed recently.
, so don't expect that everything will happen quick."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 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)
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)
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)
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
__________________
Software for handhelds: http://www.rotters.de and https://garage.maemo.org. Developer of EasyPlayer
Software for handhelds: http://www.rotters.de and https://garage.maemo.org. Developer of EasyPlayer
| The Following User Says Thank You to klausr For This Useful Post: | ||
 |
|
2010-04-12
, 20:36
|
|
Posts: 1,366 |
Thanked: 1,185 times |
Joined on Jan 2006
|
#6
|
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.
Last edited by mikec; 2010-04-12 at 20:38.
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.
__________________
N900_Email_Options Wiki Page
N900_Email_Options Wiki Page
Last edited by mikec; 2010-04-12 at 20:38.
 |
|
2010-04-12
, 21:47
|
|
Posts: 2,121 |
Thanked: 1,540 times |
Joined on Mar 2008
@ Oxford, UK
|
#7
|
Originally Posted by thp
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.
- 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)
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".
|
|
2010-04-12
, 21:59
|
|
Posts: 2,121 |
Thanked: 1,540 times |
Joined on Mar 2008
@ Oxford, UK
|
#8
|
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.
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.
| The Following 2 Users Say Thank You to pelago For This Useful Post: | ||
|
|
2010-04-12
, 22:00
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#9
|
Originally Posted by pelago
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 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'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").
Originally Posted by pelago
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).
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".
| The Following User Says Thank You to thp For This Useful Post: | ||
|
|
2010-04-12
, 22:06
|
|
Posts: 2,121 |
Thanked: 1,540 times |
Joined on Mar 2008
@ Oxford, UK
|
#10
|
Conboy
Please see attached screenshot of Settings dialogue from Conboy 0.6.3.
My opinions:
Last edited by pelago; 2010-04-12 at 22:15.
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.
Last edited by pelago; 2010-04-12 at 22:15.
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:
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?
(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!
Last edited by thp; 2010-04-12 at 22:09.