UI design Q -- do people like "sticky" settings?


Subject: UI design Q -- do people like "sticky" settings?
From: Paul Rohr (paul@abisource.com)
Date: Mon Feb 28 2000 - 20:50:26 CST


I never heard anything back on this thread, which should help establish a
precedent about the scope of direct-manipulation changes to the UI.

I can think of three reasons why:

1. Everyone agrees with me. (Yeah, right.)

2. Nobody cares about toggling input modes. Anyone who uses VI or emacs
keybindings hardwired their prefs long ago and wouldn't *dream* of touching
that F12 key.

3. People care fervently and passionately about this issue, but the
original question got lost in the barrage of email this month.

Just in case it's #3, I figured I'd ask again. Otherwise, I'll assume it
was #1 all along. ;-)

Paul

>Date: Tue, 15 Feb 2000 15:36:45 -0800
>To: abiword-dev
>From: Paul Rohr <paul@abisource.com>
>Subject: UI design Q -- do people like "sticky" settings?
>
>The following design issue came up in a private discussion with Alexey
>Sinutin, who's implementing overwrite mode, and I thought it'd be worth
>coming up with some more opinions.
>
>Essentially, we currently have two sets of functionality in the UI which
>allow users to directly change settings on a per-frame basis. However,
>there's a discrepancy in how persistent that change is.
>
>1. The most recent case is View/Ruler. There, any time you change the
>state of a single frame (via the menu), it *also* updates the underlying
>option, so that any new windows "look like" the last one opened. However,
>it does not affect the state of any previously-opened windows.
>
>(This "sticky" behavior -- change it once and it keeps applying until you
>change it again -- is analogous to toolbar, etc. settings in Web browser
>windows.)
>
>2. By contrast, the F12 key, which is used to cycle between input modes
>(from default to emacs to vi and then back again) does *not* update the
>underlying option.
>
>the question
>------------
>I personally happen to like behavior #1, so I'm tempted to suggest that #2
>should be changed to work the same way. However, I almost never change
>keybindings, so I'd like to hear from folks who do.
>
>What do you think?
>
>Paul
>
>PS: Note that to get the full effect of #1 above, we'll need to fix another
>bug as follows:
>
> - If you're using a custom scheme *and* you have autosave prefs turned on,
> then the "sticky" change will persist to future sessions.
>
> - However, if you're still using the builtin scheme, the "sticky" change
> gets lost between sessions even if you have autosave prefs set.
>
>The reason this happens is because the app doesn't know to change schemes,
>and the _builtin_ set never gets saved. To fix this, we'd need to move some
>of the existing scheme-swapping logic out of the options dialog and into the
>prefs or app class (I'm not sure which), which'd be a good idea anyhow.
>



This archive was generated by hypermail 2b25 : Mon Feb 28 2000 - 20:44:55 CST