Subject: Re: Commit: A boat load of things
From: Paul Rohr (paul@abisource.com)
Date: Wed Mar 07 2001 - 16:52:36 CST
At 10:35 AM 3/7/01 -0800, WJCarpenter wrote:
>paul> On the GUI issues -- is it ever useful to unignore only a single
>paul> instance? I think that the usual UI stance on this is to just
>paul> blow 'em all away and do a fresh spell-check pass.
>
>I don't know about you, but I make the occaisional mistake (see,
>there's one right back there :-). After I've accidentally "ignored" a
>word, I'd like to be able to undo my ignore. (I know what you're
>thinking ... Undo should undo the ignore, but I still claim there is
>gross unawareness of the use of Undo for other than plain typing.)
To be clear -- the scenario you have in mind is:
1. You mispelled a word
2. It got squiggled
3. You pulled up the context menu on that squiggle to ignore it
4. It got unsquiggled
5. You immediately realized that #3 was a mistake
In other words, you know which word you want to *re*squiggle. There's no
reasonable way to put a positive UI indicator on that word, but you know it
used to be there.
>Re-bulk checking the document to fix a single problem is extremely
>irritating (I can provide emacs examples of this irritation). By all
>means, contemplate ways to use bulk checking to globally sweep and
>re-consider decisions, but don't force it as the only way to correct
>isolated indiscretions.
Two reactions.
1. (Serious) Uh, the re-bulk check should only force you to recheck your
ignored words, which should go pretty fast, right?
2. (Joshing) Some things should be irritating. ;-)
>If the context menu can have check marks,
Anything is possible. It just depends on how hard you want to work. For
example, to make the spell context menus look right, I added EV_MIS_Bold
support to the general menu mechanism (on Win32 at least):
http://www.abisource.com/mailinglists/abiword-dev/99/October/0125.html
The framework already allows any menu to have check marks. The trick is to
be able to get the state info to know whether to use them. This may require
widening the existing context APIs.
>probably the right feel for
>this it to have a toggleable "Ignored" state rather than a pair of
>"Ignore" and "unIgnore" actions.
OK. I think I understand the scenario. If a squiggle exists but has been
ignored, then you want to add an item to the context menu associated with
that "missing squiggle" which allows you to undo that change. (Presumably,
this would be yet another popup context, since the spelling context menu is
inappropriate, and the regular context menu doesn't have an ignored state.)
My initial reaction is that this is a pretty obscure screw case, and not
worth bothering with. Yes, you could do it, but the effective transparency
of the GUI just feels broken.
It's easy to explain when & how every item on the current context menus
work.
- If a word is misspelled, you can remove the squiggle in several ways
- Otherwise, you can do clipboard or format operations
In both cases, there's a clear 1-1 mapping between:
what you see what you get
------------ ------------
squiggled text a menu of ways to get rid of it
text, no squiggle a menu of ways to copy or format it
What you're proposing is to add popup functionality based on something that's
otherwise totally hidden. I just don't like what that does to the usual
experience of discoverability in good GUI experiences.
Paul,
minimalist
This archive was generated by hypermail 2b25 : Thu Mar 08 2001 - 13:54:05 CST