[Scummvm-devel] Options dialog design (long!)

[Georg Wedemeyer]

hi,

A second try, since this mail accidentally was just send to Max.
I'll take the opportunity and add comments, where Max had already cared 
to give his opinion.
Here are some thoughts on the design document, which I scribbled the 
other day, resend to the list. my idea was to give a little user-side 
view, since I have no idea about the actual innards of scummvm.
Most of the comments were the paragraphs from the design document, 
unless otherwise noted.

-----
[snip]
> selected. Now, press one of the Ctrl-Alt-<NUMkey combos (assuming you
> are using the SDL backend). This will cause the active graphics dialog
> to be changed. However, the visible dialog will still show the old
[snip]

True. If I change the settings via key shortcut, while the options 
dialog is open, the option dialog should reflect these changes.
other possibility: disallow key shortcut changes while dialog is open.
This seems like a descision that just has to be made.

> A second problem is the discrepancy between permanent settings (i.e.
> settings as given in the config file, and edited via one of the current
> options dialogs), and temporary settings: When you use the options
> dialog to switch the graphics mode, this becomes permanent. But when 
> you
> use a backend hotkey, the change is only temporary. Clearly, this is
> once again an inconsistency, and will lead to unexpected results.

This is not so much an inconsistency, since I sometimes like to swich 
to one kind of rendering, then reverse the setting.
key combos and mouse driven interfaces are just different enough to be 
perceived as acting different. that said it would of course be nice to 
make GUI and key combos alternatives instead of complementary, but that 
again is just a descision that has to be made.

A solution could be to leave the key-shortcut changes temporary, then 
when scummvm is quit make a dialog appear that says something like:
----------------------------------
This game used your chosen graphic
settings (2xA), whereas your current
set is (3xB) (changed with key shortcuts).

-(Save current settings)-
-(Reset to old settings)-
-(Cancel Quit)-
----------------------------------
one could of course display a similar dialog before calling the ingame 
options dialog.

> Another Problem... ------------------
>
> [snip]
> Question: Which graphics mode should Monkey Island use now? 2xSAI or
> AdvMame3x ?

this will be no problem if one doesn't have global prefs - (see last 
paragraph)

> [snip]
> The first problem ("inconsistency") can be solved by updating the 
> dialog
> contents on the fly whenever settings get modified (e.g. via a hotkey).
> [snip]

[snipped my comment on naming conventions, since it was kinda lame.]

I was then going to propose a better differentiation between the 
graphic appearance ("texture" of the game's window) and resolution 
("shape" of the game window). I've appended the text for historical 
reasons as 1).

  Max noted:
> Also, what you say about "shape" vs "texture" changes is not an 
> option. Those two things are not separable from an implementation 
> point of view unless we sacrifice some portability.

hmmm. well I didn't suggest implementing different, just make the ui 
realize when different changes happen. but then again I don't have 
insight into the inner workings of scummvm.


as for:
 > (a) Delayed activation (only after "OK") makes it very easy to 
implement
 > [snip]
 > (b) Immediate activation: IMO this is more consistent overall: With
 > [snip]

I'm not really sure what you mean later in these paragraphs, since 
activation != saving.

> Max comments were:
> Yes. I stated that inequality in my design document. I also explained 
> what I meant with the above distinction: you can either make a change 
> *immediately* when the UI control gets clicked (e.g.: when you click 
> on the fullscreen checkbox, toggle fullscreen mode *immediately*); or 
> you can do it delayed: when the OK/Apply/Whatever button is clicked.

Ok, If one just has to choose between these two options, then it's a 
different situation than what I was assuming. I thought one could 
differentiate between clicked UI controls and therefore sketched the 
different behaviour for "shape" and "texture" controls.

Then I went on:
>> A thing I noticed, that I always ended up tweaking the options for 
>> each game individually, so I'd say get rid of the global options,
>
And Max answered:
> So based on your personal usage pattern you suggest we should get 
> completely rid of a feature? That's kinda lame :-).
>  At least first conduct a test with what other people are doing... 
> your suggested alternative didn't seem any easier to me. I want to be 
> able to easily change the volume settings for all of my games. Clearly 
> I could do it in another way. But I think this quite clearly 
> demonstrates how risky it is to argue on personal preferences... one 
> of the main reasons I tried to argue mostly in terms of consistency, 
> and "least surprising behavior"... what you are suggesting here, in my 
> eyes, is not dictated by any greater need, and as such, isn't in the 
> scope of what I am working on.

  I admit I completely oversaw the possibility somebody might want to 
change the overall sound setting of all the games. For this an 
amplifier attached to the sound output of a computer is so much easier 
to use, I couldn't imagine anyone doing it different. ;-)

I then went on: [snipped and edited for shortness]
> make a custom set that gets loaded as a default into the local 
> settings, then the user does customize these game prefs.
> So I do propose to morph the global/local metapher to a default/custom 
> one, making the default less visible.
to make it a little more clear:
At the current situation there are two buttons presented on the same 
screen ("Edit game" and "options") that are a subset of one another. 
("Options" in terms of features, "edit game" in terms of hierarchy). My 
point was that by putting these two together the interface may become 
more clear.
and an additional "make default for new games/all games/-of same 
version" button would take care of the need for global settings in the 
graphics mode.
So a reworked setting would look like:
"Game Options..." game specific settings screen with tabs:
	Game (same as before)
	Graphics (same + additional "default for new games/all games" button)
	Volume (where one can set volume relative to the global settings)
"Audio & Misc" global settings screen with tabs:
	Audio (same as before)
	Volume (same)
	Misc (same)

the main reason that I see for the current existence of a global 
settings dialog for graphics is that you are currently hiding away the 
engine version details, so if one plays a certain range of engine 
versions there is a possibility one chooses the same settings for every 
game. That's why I argued that abandoning global settings might be a 
good idea.

Speaking of "least surprising behaviour": After editing the game 
options of a game, then closing the dialog by pressing OK, the game 
isn't selected any more, so one cannot press "start" right away -nor 
has feedback which game was edited.


Oh, one more thing, I like to take the opportunity to thank everyone 
involved in making scummvm. your work is much appreciated.


Regards,
	Georg





---
1) ----------------------------------------------------------
-------------------------------------------------------------
I think when addressing the resolution issue you mixed two
themes. One affects the graphic enhancer (let's call it
"texture" of the game window) the other the resolution (I'll
call it "shape" of the game window). Changes in "texture"
are non-interrupting, whereas changes in "shape" suspends
the process of setup for a little while. the user has to
adapt to the new position of the window on the screen and
resolution switching itself needs a little time (at least on
my monitor). Therefore I'd say - when in the same resolution
(change in "texture") switch immediately to make it the
seamless process it is.

I would rule out switching resolutions in a later state than
when closing the dialog, because there is no immediate
context in which this change happens. if there is a context
where one can change resolutions, make it happen there. Now
one has three possibilities: change resolution immediately,
change it on keypress or change it when the dialog closes.

when a change in resolution occurs immediately, the
tolerance for misclicks is very low. so this option would
seem more appropriate if the changing of "shape" and
"texture" would get divided into two different areas on
screen, to reduce accidential clicks.

A change in resolution after clicking a button (before
closing the dialog) would allow the user to undo accidential
resolution changes very quickly. the interrupt associated
with "shape" change could be steered and set towards a
minimum (when it's wanted).

Change the "OK" caption (& behaviour) to "Apply, Contuinue",
when the user switches resolutions (that includes switching
from/to fullscreen). Grey out the preview pane (ha! another
reason for a preview pane) to make it clear to the user that
a resolution change is immanent and graphics for that
resolution are not shown. (So the user first clicks "Apply,
Continue", after having chosen the desired resolution. If he
does it the first time, one could warn him what the program
is about to do and provide him with the appropriate
keypresses to abort the process. Additional security measure
can be implemented here.)