[Scummvm-tracker] [ScummVM] #10313: GUI: Please clarify expected behaviour of 'Apply' button.
macca8
trac at scummvm.org
Wed Nov 8 02:09:37 CET 2017
#10313: GUI: Please clarify expected behaviour of 'Apply' button.
------------------------+--------------------
Reporter: macca8 | Owner: (none)
Type: enhancement | Status: new
Priority: normal | Component: GUI
Keywords: | Game:
------------------------+--------------------
The **Apply** button provides a very simple feature: change a Global
Option without leaving the Options tab.
Unfortunately, using the button alongside the **OK** button isn't anywhere
near as intuitive as if used alone… it works as expected, but assumes a
user's prior knowledge of its purpose.
Just to be clear, the issue here isn't with the task the **Apply** button
performs, it's with how it's communicated to the user.
The first problem is that the dialog contains two methods for applying a
change, **Apply** & **OK**… an ambiguous situation with no clear
guidelines offered.
This immediately poses two questions to the new user:
- Which button do I use?
- What's the difference between **Apply** & **OK**?
The cleanest solution is to remove the **OK** button (the **Apply** button
virtually makes it redundant in this case), but I'm guessing that most
devs would be reluctant to remove a long standing method, particularly
since it's not actually broken!
Alternatively, I propose the addition of these tooltips to the tab's
buttons:
- **Cancel**: Return to Launcher.
- **Apply**: Change options.
- **OK**: Change options & return to Launcher.
While adding a tooltip to the **Cancel** button isn't really necessary, it
does provide clarity to the relationship between the three buttons
(**Apply** + **Cancel** = **OK**).
The second problem is a lack of feedback when clicking the **Apply**
button to apply a change.
If the selected option changes the overall appearance of the GUI
(language, theme, or screen size), then it's obvious to the user that the
change was effected. However, most options don't, and look the same before
and after the button is clicked, prompting the question:
- Did anything actually happen?
The only way to check is to exit the tab (usually to the Launcher), then
return to confirm the change… defeating the purpose of using the **Apply**
button.
What I propose is that the **Apply** button (and, for consistency, the
**OK** button as well) be disabled by default, and only enabled when the
user selects an option to change. After the user applies the change, both
buttons are again disabled, visually confirming that the change was
effected.
As such, the following behaviours would also need to be addressed:
- if, ''before'' applying a change, the user reconsiders and reverts that
change to its currently applied value, then the button should be
immediately disabled.
- similarly, when changing multiple options simultaneously, if ''all''
changes are reverted, the button should be immediately disabled, otherwise
it should remain enabled while any potential changes still exist.
To be fair, as features go, the **Apply** button is trivial, but
regardless, communicating clearly with the user is essential to using a
GUI effectively.
Thanks for your consideration.
--
Ticket URL: <https://bugs.scummvm.org/ticket/10313>
ScummVM <https://bugs.scummvm.org>
ScummVM
More information about the Scummvm-tracker
mailing list