Bugzilla – Bug 5930
Saving Player Settings menus option changes
Last modified: 2009-09-08 09:18:14 UTC
When I am making edits to the menus, the changes seem to have an immediate effect, but there's still a "Save Settings" button for the page. Are the edits meant to be immediate, or should they only be committed when the save button is pressed? Also, there are two methods for removing menus from the player UI menus - the delete icon on each row, or tick the checkbox and then hit delete. Doesn't seem a lot of a need for the latter - deleting one at a time is fine.
checkboxes were a request (removing the delete icons was to be reviewed, but no one bothered). 'save settings' for this page case serves no purpose.
Brian to review.
Yes I see the problem with the save settings page. Most UIs will close settings panes once the save buttons is clicked. If we can have this behavior that would be best. I think we designed it the way it currently is so that users can save settings for different tabs. But the more I test it, the more confusing the way it is. I talked to a user researcher friend over at Google who worked on Gmail. They also auto-close the settings once the save button is clicked one. This is because they found most users only changed ONE setting at a time. Although this isn't a web-based email client, I would guess our users would be the same. What do you guys think?
We should then at least add a "Apply" button, as having to open it for every setting is a pain.
I'd prefer to have auto-save on close (or auto-close on save) and remove the second button altogether. Problem is that we'd need to auto-save on moving to other tabs too. Call the button "Done". Users could cancel by closing the window instead of clicking on "Done".
Jeezus, people. Keep it simple. What's the benefit using AJAX in these pages to update individual settings one by one? Put a freaking 'Save' button on the page or the surrounding frame and be done with it. If you want to get intelligent about it, then note when a change of values has taken place within the form and warn the user to save before moving off or closing the page. Please do not close the settings when saved (I'm sure I must be misunderstanding this take on things, because something like that would drive many people to violence).
Jim - you're accurately describing the status quo. Dean - I have to agree with Jim: trying to imitate OSX' preference pane's behaviour in a browser independant way is no mean feat. And I'd expect support not to like it either, as a vast majority of the users is still using some other OS, which isn't behaving that way at all. I recently read a comparison between Leopard and Vista, and they wrote that one of the most confusing behaviours for those willing to move to OSX was exactly this unexpected auto saving changes.
Ok, I propose we have an "Apply" button and a "Close" button. Apply should be understood that it makes the changes happen and close closes the windows. Is everybody good with this?
Is "Apply" much better than "Save settings"? - we'd have to have it translated, too. I doubt that minor change in wording does justify the effort?
Apply is commonly used in dialog boxes, etc to imply "change but don't close". Please use that at least for english and leave the other translations. If/when they get updated, they'll get fixed. How's that sound?
Ok, change 15125 adds "Apply" in EN, DE, FR. Other languages TBD.
Localized strings have been checked in at change 15449.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.