[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: standardizing modes of text selection
From:       "Jamethiel Knorth" <jamethknorth () hotmail ! com>
Date:       2004-03-20 15:17:01
Message-ID: BAY7-F79QAmPBijd2tW0007977a () hotmail ! com
[Download RAW message or body]

>From: Leo Savernik <l.savernik@aon.at>
>Date: Sat, 20 Mar 2004 14:12:10 +0100
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Am Samstag 20 März 2004 06:36 schrieb Jamethiel Knorth:
> > Okay, I know not everything was agreed on here, but do we all at least
> > agree that the standard for selection in KDE should be:
> >
> > Single-Click - No selection
> >
> > Single-Click & Drag - Select from cursor, by letter
> >
> > Double-Click - Select word
> >
> > Double Click & Drag - Select word and select by word, selecting to the
> > beginning and end of any word the cursor moves onto.
> >
> > Triple -Click - Select row
> >
> > Triple-Click & Drag - Select row and select by row, selecting to
> > (inclusively) any line the cursor is dragged over.
>
>Very concise, well done summary.
> >
> > Reversing Cursor Dragging - Select in the same manner as before, 
>changing
> > the end point but never the start-point of the selection (specifically, 
>not
> > like the keyboard text-selection in apple where it expands in both
> > directions)
>
>Let's make an explicit distinction here: Mouse selection *will* expand to 
>the
>beginning *and* end of the word/line when issued, but keyboard selection 
>will
>*not*.

I think that you misunderstood. Perhaps you have never seen the 
text-selection in BBedit or one of the other old Mac editors:

If I hit shift and the left arrow, the selection will expand left. If, while 
still holding shift, I hit the right arrow, the selection will expand right 
from the right edge. It will not shrink from the left, where my cursor 
currently is.

As an illustration, if my cursor were in the above text, say after the 'd' 
in 'expand', and I were to hold shift and hit left five times, 'xpand' would 
be selected. If I were to then, while holding shift, hit right four times, 
'xpand lef' would be selected, rather than just 'd'. The cursor motion only 
expands the selection, never shrinks it.

What I was saying is that we do not want that behavior.

However, it makes one more question occur to me. If I shift-click, click, 
click, what happens? In Safari (I'm on a Mac right now) if I hit shift, then 
click somewhere, it expands from the current selection to that point. Then, 
if I shift click again, the selection will expand to that point from the end 
nearest to it. This means that holding shift while clicking with the mouse 
will always expand the selection, unless the click occurs inside the current 
selection, in which case the selection will be shortened from the end 
closest to the mouse click.

If this behavior were added, the following would need to be added to my list 
above:

- Shift+Click: Expand selection to click location from point nearest to 
click location, if the click occurs outside the selection area. If click 
occurs inside the selection area, reduce selection to click location from 
the selection endpoint nearest to the click location.

This then poses two new questions:

1) Is the reduction occuring from the end nearest to the click, or does it 
just reset that endpoint in relation to the original start-point of the 
selection, so that the first place you click is always the center of that 
selection?
2) Does the selection expansion with shift+click occur in the same manner as 
original selection did, or does it expand according to its own click-rate 
(single, double, triple)?

To #1 I would say keep the original startpoint for the selection, but I am 
very uncertain. To #2 I would say that it would just expand in the manner 
the original selection did, in which I would need to append, "The selection 
always expands and contracts according to the manner (by letter, word, or 
line) in which it was originally created," to the end of my Shift+Click 
explanation.


This then also means that the text selection expansion with Ctrl+Click 
requires explanation. The standard behavior is to have a new selection be 
started without the removal of the first if Ctrl+Any-Selection-Action is 
hit. The question is, what sort of selection is that new selection?

Does the new selection occur in the same manner as the old one? My answer 
would be no. Then, if you double-click and drag, selecting a bunch of words, 
then ctrl-triple-click and drag somewhere else, that second selection 
selects by lines, not words. That would in this addition to the selection 
recommendation:

- Ctrl+[mouse-action]: Retain old selection(s). Otherwise treat as a normal 
mouse actions. If the mouse action would create a selection, create that 
selection in addition to old selections. In the case of further mouse action 
which would not remove the current selection but do not contain a Ctrl, 
still do not remove the previous selection(s).  In the case of further mouse 
action which would remove the current selection, also remove all old 
selections.

However, it would be reasonable to select in the same manner as the original 
selection. That would mean that double-clicking one word would select that 
word and then ctrl+single-clicking elsewhere would also select a whole word, 
despite only being a ctrl+single-click. That might be described as:

- Ctrl+[mouse-action]: Retain old selection(s). If the mouse-action would 
create a selection, that selection remains of the same expansion-type as the 
original selection. All selections must be of the same expansion-type at all 
times. In the case of further mouse action which would not remove the 
current selection but do not contain a Ctrl, still do not remove the 
previous selection(s).  In the case of further mouse action which would 
remove the current selection, also remove all old selections. Otherwise, 
treat as a normal mouse action.



This then also poses a few other problems. What happens in the case of 
keyboard expansion on mouse-selections? I think that they should 
transparently add to one another. (This only applies in thing that allow 
keyboard-selections, such as editors)

I would say that, whenever the mouse is used to expand a selection, the 
cursor is move to the point at the end of the selection expansion if it was 
expanded from nothing or from the end, or the beginning if expanded from the 
beginning (not always where the click occurs). If a keyboard is used to move 
the cursor while holding shift, this edits the current selection. If it 
moves over an unselected area, that is added to the selection. If it move 
over a selected area, that is removed from the selection.

Also, then, how does the keyboard expand the selection? Does the keyboard 
expand the selection in the form of the selection, or just letter-by-letter? 
I would say letter-by-letter, unless holding ctrl (I think that is the key 
for expanding for word, at least by default). The reason is that doing 
otherwise would make selection extremely irregular when selecting by line 
(If I hit left, it grabs a line upwards?). That would mean adding this 
explanation:

- Keyboard-Input: In an editor, input which adds text of any sort replaces 
the text (with rare exceptions, such as indent by tab in many editor). In a 
view-only application, such input does not affect the selection.

- Keyboard-Motion: Removes the selection and moves the cursor.

- Shift+Keyboard-Motion: The selection expands or contracts to where the 
cursor moves to, moving in the manner that the keyboard dictates the cursor 
move. In simple, anywhere the cursor crosses which is selected becomes 
unselected. Anywhere the cursor crosses which isn't selected become 
selected.

Then comes the question of Ctrl+Keyboard Motion. In a few occurances, 
holding ctrl allows cursor motion without loss of selection (I can't think 
what off-hand, but I have seen it in things which allow 
multiple-selections). Does Ctrl+Keyboard Motion then just allow cursor 
motion without selection loss, and Shift+Keyboard motion just allow 
expansion of the selection? If so, all that needs adding is:

- Ctrl+Keyboard-Motion: Moves the cursor without removing any selections.



This then poses the further question of what happens with generic selection 
overlap. Is the result just always inversion? Consider: I click+drag and 
select thirty words. I Ctrl+click+drag, at the end crossing over part of my 
original selection. The easiest answer to logically reason out is that any 
overlap results in selection inversion. That only needs this comment:

- In the case that this is not covered by any previous rules, if an action 
would cause a selection where there is already another selection, this 
instead results in the overlapping area to be deselected.

This has the nice feature that once could triple-click to select a bunch of 
lines, then ctrl+double-click to remove some words from the middle. However, 
it also causes an interesting problem. It makes it somewhat awkward when 
double-clicking and dragging to select a bunch of words, the ctrl-triple 
clicking below and dragging up. It seems fairly natural to have the larger 
level selection encompass the smaller. However, I do not see a good way to 
make a consistent rule of it, so I would avoid it.

I think that the only remaining issue (yes, there is another issue) is what 
to do with programs which do not support multiple selections. Does 
ctrl+click/mouse-motion result in deselection, or does it allow free mouse 
motion without deselection? I would say that it would allow free cursor 
motion.

As it turns out, I was wrong. There are still more issues to consider. What 
happens with typing to replace when multiple selections are present? What 
happens with typing when the cursor is not at the selection?

I would say that the action of hitting ctrl+[anything-which-causes-motion] 
results in the current selection becoming an old selection, and old 
selections never get replaced by typing. That would need this addition:

- In the result of cursor motion without alteration of the current 
selection, whether it be by creating a separate selection or by moving the 
cursor without creating or destroying any selections, the current selection 
becomes an old selection.

- Old selections are not replaced by typing. In the event of anything which 
would replace or deselect the current selection, old selections are 
deselected without any effect to them. The only instance in which old 
selections are edited is by exterior commands (cut, copy, indent). In the 
case of exterior commands which replace a selection (paste) they only 
replace the current selection, not old selections.

Wow, this gets really damn complex when you try to deal with every 
situation!

Okay, just one more thought. Wouldn't that last behavior I mentioned be 
confusing when two separate selections butt up against one-another 
perfectly? They would appear as one selection, but actually be two. Could 
this be solved by changing the selection color for old selection slightly, 
or would that just be more confusing?

Despite how complex all that seems, I think it is actually fairly 
straightforward.

> >
> > If we are in agreement, why doesn't whoever originally suggested this 
>(was
> > that you Leo?) write it up all pretty-like (with a notice that selection
> > modes for URLs is not yet defined) and send it off to the relevant 
>parties.
> > If we could get this to be the official KDE standard, that'd be great.
>
>Good point.
> >
> > As to who are relevant parties, I don't know. KDE-Policies?
> > FreeDesktop.org? OpenUsability.org?
>
>fdo doesn't seem to be the right place for such submissions. I also think 
>this
>is no usability issue, but a style issue. I consider a place like
>http://developer.kde.org/documentation/standards/kde/style/basics/
>to be most appropriate.

I think this is definitely a usability issue. Usability is screwed over by 
inconsist and unpredictable behaviors, and this is currently such a 
behavior.

> >
>[...]
>
>mfg
>	Leo

_________________________________________________________________
Get tax tips, tools and access to IRS forms – all in one place at MSN Money! 
http://moneycentral.msn.com/tax/home.asp

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]