When making changes to XBMC settings, it's not always obvious when that setting takes effect - there's no OK or CANCEL option.
For example, in the case of changing screen resolution, a user has to flick through the options then wait for a second or two for it to take. If this value is wrong, there's no way of returning back to the original value (no CANCEL option).
I don't expect every config options to have "OK" and "CANCEL" options - just selectable buttons at the bottom, similar to other dialogue boxes (like adding in a media source). It would also be nice to show what has changed in a different style, for example: change the background colour/shade of that menu option to show the value differs from the original (i.e.: identify what you could have potentially buggered up).
It's only a minor thing, but as a new user I was confused when changing menu options - I didn't know when they would take. In trying to diagnose sound issues, I tried cycling through different options but it wasn't obvious to me what the last setting was.
The screen resolution setting is probably a bad example as it's one of the view settings where you actually get a dialog asking you whether you would like to keep the changed resolution or not (with a default fallback after a specific timeout).
yeah, figured that was a poor choice!
It just seems a bit inconsistent in places - some screens have OK/CANCEL options to finalise the decision, others don't.
Personally I think that back out should make the settings take. Possibly with the sole exception of resolution.
The other option would be to have save, revert and apply on every view. With pressing back possibly highlight that row. IMO the back out to save is the nicer interaction.
And what do you do if the user changes multiple settings (to something that doesn't work, e.g. bad port for webserver) and then he backs out and there will be multiple dialogs popping up on the screen informing the user that something went wrong?
IMO every spinner that currently uses a delay until the change takes effect (e.g. the screen resolution setting) should be turned into a list. For text input settings this is a bit more difficult.
Spinners into lists? That's not a bad idea.. it provides the opportunity to view all available options in one go rather than spinning through them.. and could also mean specific values in the list could be identified in some way (current, default, selected).
I'm not sure how difficult it would be to achieve. I'm presuming there's some API that constructs the dialogue screens so it would probably only need to be modified into one place but given all the other work it's probably not a high priority right now: things work without this change, just that this enhancement would provide useful feedback when things aren't working and people are struggling with changing settings.
Changing from a spinner to a list is as easy as changing an XML attribute from "spinner" to "list" for the specific settings. It doesn't even require a code change.
A cosmetic problem is our list dialog which is very inflexible so if you only have 3 options in a list you will still see a huge dialog which lots of wasted space which IMO looks very ugly.
(2013-12-30, 01:12)Montellese Wrote: [ -> ]And what do you do if the user changes multiple settings (to something that doesn't work, e.g. bad port for webserver) and then he backs out and there will be multiple dialogs popping up on the screen informing the user that something went wrong?
IMO every spinner that currently uses a delay until the change takes effect (e.g. the screen resolution setting) should be turned into a list. For text input settings this is a bit more difficult.
Good point! Agreed!
Why not a combination of spinner AND list?
I was playing UT99 last night: next to the map name there's: | V | < | > | - the down-arrow drops down a list, the left/right just jump to the next/previous entry in that list (cycling around where necessary). It offers the user both choices.
Or is that an overkill? I'm hoping it's just an API for an enumerated control that can display/scroll through the selections in a different manner. It won't be needed for boolean choices (that can stay as the lamp radio button), so should narrow down code impact.