Subject: Re: fields design -- proposed edit/select behaviors
From: Paul Rohr (paul@abisource.com)
Date: Thu Jun 08 2000 - 12:44:43 CDT
Martin,
Thanks for the feedback. Getting these nit-picky details just right is the
kind of hard work that it's difficult to get most people to really think
through up front.
But if we don't come up with something that Just Works, boy do we hear about
it! :-)
At 06:03 PM 6/8/00 +1000, Martin Sevior wrote:
>> display
>> -------
>> Whenever the cursor is inside a field, the background of the entire field
>> toggles, to visually indicate that the user is inside a field. We should
>> choose a background color which is visually distinct from our usual
>> selection color, though.
>
>This is a good idea. My favorite color is light blue but tht might be a
>problem for the blue backgrounds in some documents. Should we woory about
>changing background colours if the document is not white?
The interaction between the colors used for selections, backgrounds, fields,
etc. can get complicated. Often GUI designers use reverse video to avoid
color clashes, but in practice, that's difficult to implement reliably.
(IIRC, earlier versions of the Abi drawing code did a bunch of XOR tricks,
but we eventually settled on the current approach because it was easier to
make it dirt-free.)
At this point, so long as the selection and field colors are visually
distinct, I think we'll be OK for the 1.0 release. I'd hate to see us
revisit the drawing algorithms in the short term if we don't really, really
have to.
>> insert semantics
>> ----------------
>> Insert semantics within an editable field are as usual -- add the text
>> immediately after the insertion point.
>>
>> Insert semantics at field boundaries are as follows:
>>
>> - left: display the field background (so you know it's there), but any
>> inserted text goes before the field
>>
>> - right: don't display the field backgroung (you're past it), and any
>> inserted text goes after the field
>>
>> Thus, you can't insert text at the beginning or end of a field's
contents.
>> Poor baby.
>
>This is different from normal abi behaviour which is that with the cursor
>positioned to left of the format boundary enters text as the rest of the
>text to left of the format boundary.
Yep. As you suggest, the "left" behavior is already consistent with
existing precedent for other formatting. The field does highlight (so you
know you're next to it), but you're definitely "outside" or "before" it, so
all editing operations (especially insert and forward delete) make sense.
However, to implement the rest of the proposed behavior, we will need to
special-case the "right-hand" logic above. Ditto for the matching delete
semantics.
This is a feature, not a bug. ;-)
After having played with editing in and around fields in another word
processor, the described behavior actually "feels" quite nice. When you're
immediately to the right of the field ...
- It doesn't highlight, which is a visual indication that you're "outside"
the field now.
- If you hit backspace, it selects the field, and another backspace will
delete it.
- If you start typing it'll insert after the field.
In short, all of these behaviors together give a consistent impression that
you're just after the field. Moreover, this is exactly symmetric to the
"left-side" behaviors, which are also "outside" the field.
In this case, I think that maintaining a symmetric user experience for
operations "just outside" fields is probably more important than total
consistency with the standard left/right precedent.
>One other feature request :-). A small drag within a field selected the
>entire field.
As with any GUI choice, we have to do the best job we can of matching up
means (double-click, drag, keyboard navigation) with effects (local
selections, extended selections, etc.)
In this case, I'm not sure this change is worth it. Usually, the mouse is
used for fine-grain selections, and I don't think we want to take that away
entirely.
We've already got a quick mouse-driven means for selecting the entire field
(double-click) which overrides the usual word-level double-click semantics.
Do we really want to remove the usual drag semantics for selecting portions
of the field?
That'd leave us with no mouse-driven way to do selections. I suppose it
could be argued that this is a good thing, since it really discourages
editing inside fields. However, that just seems like overkill.
For the first pass, I think I'll implement "normal" drags and then let
people see how they like it. We can always accept patches for
usability-testing other alternatives later on.
Paul
motto -- the devil is in the details
This archive was generated by hypermail 2b25 : Thu Jun 08 2000 - 12:39:06 CDT