GUI: Please clarify expected behaviour of 'Apply' button.

[macca8]

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.

[criezy]

Thank you for your feedback.

It seems to me that "Cancel", "Apply" and "Close" buttons are pretty ubiquitous in desktop applications with a consistent behaviour everywhere. But indeed clarifying there behaviour can only be a positive step, and adding a tooltip should be easy. I have also seen a few applications using "Apply and Close" instead of "OK".

Regarding feedback when applying changes that do not change anything visually, maybe a OSD message could be used (something like "Changes have been applied" that appears for a few second on screen, like what we have for example when pressing Alt+Enter to toggle fullscreen).

The changes you propose to enable and disable buttons would be nice, and I think I have seen it mentioned somewhere else already (or maybe it is on one of my numerous lists of ScummVM-related things to do on my desk). It would however also be more work to implement.

[angstsmurf]

Personally, I've always preferred the classic Mac OS dialog style without an Apply button. If you change a value in a dialog box, the change should be immediately applied. If you click Cancel, all changes should be reverted to what they were before. Much simpler.

[macca8]

Thanks for your response criezy.

A timed OSD message seems a good fit for providing feedback for an option change (assuming it's applied to all changes… not just those that don't otherwise provide a visual change).

However, I'm still keen about the enable/disable button concept as well, since it provides the added bonus of enforcing the correct behaviour for using the Apply & OK buttons. In so doing, it restores a sense of order and control to the GUI.

My motivation for posting this request is to improve the intuitiveness of the GUI, and since changing an option is a fundamental function of the GUI, it's as good a place as any to start.

[sev-]

I ended up adding tooltips to all three buttons. Thank you for your report.