Subject: Re: UI design Q -- do people like "sticky" settings?
From: Aaron Lehmann (aaronl@vitelus.com)
Date: Mon Feb 28 2000 - 21:03:40 CST
Well, the reason I can't think of anything is that the question is not
very specific. Would this stickiness apply only to bizarre editing modes
that only hackers would ever use, or to paragraph settings, styles, etc. I
am not a fan of stickiness in general, but if it is only for editing modes
I don't have much against it. Right now I can't seem to think of any other
preference item where stickiness would be good.
Aaron Lehmann
On Mon, 28 Feb 2000, Paul Rohr wrote:
> 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 - 21:03:44 CST