issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Martin Hollmichel-2
Hi UX Team,

is it somehow possible that we come for the above issue finally to a
conclusion.

There seems to be some demand for that issue (24 votes) has a proposed
fix and is now open for years.

It would be nice if we can do a decision for 3.1 and I'd appreciate if
this would be the final say then for the issue,

sorry for being inpatient,

Martin


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Clément Pillias
Hi Martin,

The first rule of Auto-completion is that the consequences of input  
should always be the same, whether it auto-completion is turned on or  
off (the rationale being that user do not always look at the screen  
when (s)he uses the keyboard, and that (s)he should not have to think  
about the input method to use).

A consequence of this rule is that the proposition of auto-completion  
has to be explicitly validated by the user. Another consequence is  
that the usual exit modalities of the input should discard the  
suggested auto-completion and have the same effect than when no auto-
completion suggestion has been done.

So: TAB, ENTER, SHIFT TAB, SHIFT ENTER, ARROW KEYS, BEGIN, END, etc.  
should all discard the suggestion and change the active cell  
according to their usual behavior.

This may need to change the way auto-completion is actually  
implemented, since it seems to be managed as some automatically  
inserted and selected text. But this will be your work ;)

If you have enough time to work on this issue, you would also be  
welcome to change the look of the completion text so that it does not  
look like a selection anymore, because it is confusing for the user.  
A current solution is to simply use a lighter text color: often grey  
or blue, but there might be some system preference making sense, here.

OK, now that this important point is clear, we can discuss what key  
combination should be used to cycle thru the suggestion list, and  
what key combination should be used to accept the suggestion.

I have no objection against Ctr+TAB to cycle thru the suggestion  
list, since it is coherent with Writer and this combination seems to  
be unused in Calc.

But what should we use to accept the suggestion? And what behavior  
should have that key: accept suggestion and stay in input mode so  
that TAB or ENTER or any other navigation key can be used? Or accept  
the suggestion AND validate the input, keeping the edited cell  
active? Or the same thing but changing the active cell (in what  
direction?) ?

To be honest, I do not know what is best (it is getting to late to  
think.) And there are other solutions such as showing the suggestion  
list in a menu (if it contains less than, say, 10 items), using the  
arrow keys (or Ctrl+TAB) to select the right completion and enter/
exit the menu, and any navigation key to validate the suggestion  
(with the usual action of the navigation key.) But then, where to  
place the menu so that it is always visible and do not mask some  
important content?

Regards,

Clément.

Le 27 janv. 09 à 22:03, Martin Hollmichel a écrit :

> is it somehow possible that we come for the above issue finally to  
> a conclusion.
>
> There seems to be some demand for that issue (24 votes) has a  
> proposed fix and is now open for years.
>
> It would be nice if we can do a decision for 3.1 and I'd appreciate  
> if this would be the final say then for the issue,
>
> sorry for being inpatient,

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Jaron Kuppers
Hi,


On Tue, Jan 27, 2009 at 6:17 PM, Clément Pillias <[hidden email]>wrote:

> So: TAB, ENTER, SHIFT TAB, SHIFT ENTER, ARROW KEYS, BEGIN, END, etc. should
> all discard the suggestion and change the active cell according to their
> usual behavior.

Agreed.


If you have enough time to work on this issue, you would also be welcome to
> change the look of the completion text so that it does not look like a
> selection anymore, because it is confusing for the user. A current solution
> is to simply use a lighter text color: often grey or blue, but there might
> be some system preference making sense, here.
>
For the sake of expediting the implementation of a solution for the next
release, I would advocate skipping this detail for the time being.  My fear
is we will lose focus from the main issue, which is how the AutoCompletion
works.  Additionally, since Excel behaves the same way as Calc, I don't
think users are as concerned about the look.  Also, there are more issues
associated with the AutoComplete look that need to be addressed (such as
providing visual indication of changes in character case when
AutoCorrecting, "pi" may AutoCorrect to "Pizza" but does not indicate a
change to capital P).


I have no objection against Ctr+TAB to cycle thru the suggestion list, since
> it is coherent with Writer and this combination seems to be unused in Calc.

Agreed.


But what should we use to accept the suggestion? And what behavior should
> have that key: accept suggestion and stay in input mode so that TAB or ENTER
> or any other navigation key can be used? Or accept the suggestion AND
> validate the input, keeping the edited cell active? Or the same thing but
> changing the active cell (in what direction?) ?

The enter key will be consistent with Writer, and the most intuitive
choice.  I advocate its behavior being as follows: User enters "Pi" into the
cell; AutoCompletion suggests "Pizza"; user ctrl-tabs to choose "Pizzas";
user presses enter to select "Pizzas"; cursor remains active within the cell
and is after the s.

This method assumes nothing about the users' behavior after the
AutoCompletion event.  If enter completes the word and goes to the next cell
we are then assuming that the user was done editing the cell which may not
be the case (and personally drives me friggin crazy).



> And there are other solutions such as showing the suggestion list in a menu
> (if it contains less than, say, 10 items)...

Benefits: Menus advocate user discovery of the ctrl-tab feature (which may
carry over into writer).  Greater AutoCompletion word choice transparency
(so user doesn't have to ctrl-tab through available choices)

Drawbacks: Inconsistent with AutoCompletion in Writer.  Blocks adjacent
cells, presumably below the current cell, (though potentially above if the
cell is the last visible cell in the workspace) and it may block additional
columns if the AutoCompletion words are long.

Conclusion: I see the major benefit of menus being the discovery of the
ctrl-tab feature.  However, blocking adjacent cells seems too much of an
inconvenience for most users, especially since it may block neighboring
columns.  In the future, it may be worthwhile to pursue menu dropdowns for
AutoCorrect in Writer and in Calc with an options menu option that dictates
menu control.  For now I don't see menus as a good solution.

Though someone else may have a different solution, I vote we proceed with
ctrl-tab/enter as a consistent intuitive solution.

Cheers,
Jaron
Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Clément Pillias
Hi Jaron,

Le 28 janv. 09 à 01:21, Jaron Kuppers a écrit :

>> If you have enough time to work on this issue, you would also be  
>> welcome to change the look of the completion text so that it does  
>> not look like a selection anymore […]

> For the sake of expediting the implementation of a solution for the  
> next release, I would advocate skipping this detail for the time  
> being.

I said "If you have enough time" ;) When is the feature freeze for  
3.2 planed?

> My fear is we will lose focus from the main issue, which is how the  
> AutoCompletion works.

Actually, you will see in my new proposition that it is related ;)  
See below.

> Additionally, since Excel behaves the same way as Calc, I don't
> think users are as concerned about the look.

I don't know which version of Excel behaved the same way as Calc, but  
Excel 2008 surely does not: it uses a menu to suggests auto-completions.

> Also, there are more issues associated with the AutoComplete look  
> that need to be addressed (such as providing visual indication of  
> changes in character case when AutoCorrecting, "pi" may AutoCorrect  
> to "Pizza" but does not indicate a change to capital P).

+1

>> But what should we use to accept the suggestion? And what behavior  
>> should have that key: accept suggestion and stay in input mode so  
>> that TAB or ENTER or any other navigation key can be used? Or  
>> accept the suggestion AND validate the input, keeping the edited  
>> cell active? Or the same thing but changing the active cell (in  
>> what direction?) ?
>
>
> The enter key will be consistent with Writer, and the most  
> intuitive choice.  I advocate its behavior being as follows: User  
> enters "Pi" into the cell; AutoCompletion suggests "Pizza"; user  
> ctrl-tabs to choose "Pizzas"; user presses enter to select  
> "Pizzas"; cursor remains active within the cell and is after the s.

And what if the user wants to input "Pizza", the first suggested auto-
completion? (S)he does not need to use Ctrl+TAB, so what should be  
the effect of Enter?

> This method assumes nothing about the users' behavior after the
> AutoCompletion event.  If enter completes the word and goes to the  
> next cell we are then assuming that the user was done editing the  
> cell which may not be the case (and personally drives me friggin  
> crazy).

Actually, auto-completion in Calc differs from auto-completion in  
Writer in that in does not work at the word level, but at full cell  
level (and only suggests content from a cell in the same column.)

Yes, sometime the user may want to add text after the auto-
completion, but I suspect that this will not be the most frequent use  
of auto-completion. So I don't have much objections against a  
validation key that both accept the auto-completion and change the  
active cell.

In Excel 2008, the auto-completion menu appears (if possible) below  
the cell and is accessible via the down arrow key. Once a suggestion  
is selected, Enter and TAB accept the suggestion and jump to the cell  
below or on the right (but other arrow keys have a different behavior.)

>> And there are other solutions such as showing the suggestion list  
>> in a menu (if it contains less than, say, 10 items)...
>
> […]
> Drawbacks: Inconsistent with AutoCompletion in Writer.

But maybe we should change Writer behavior too :)

> Blocks adjacent cells, presumably below the current cell, (though  
> potentially above if the cell is the last visible cell in the  
> workspace) and it may block additional columns if the  
> AutoCompletion words are long.

Which is unlikely since only the content from cells in the same  
content is suggested for auto-completion. So, if a proposition is  
bigger than the column width, it means that the column width is not  
adapted to its content.

> Conclusion: I see the major benefit of menus being the discovery of  
> the ctrl-tab feature.  However, blocking adjacent cells seems too  
> much of an inconvenience for most users, especially since it may  
> block neighboring columns.  In the future, it may be worthwhile to  
> pursue menu dropdowns for AutoCorrect in Writer and in Calc with an  
> options menu option that dictates menu control.  For now I don't  
> see menus as a good solution.

Please see my proposition below.

> Though someone else may have a different solution, I vote we  
> proceed with ctrl-tab/enter as a consistent intuitive solution.

OK here is the alternative solution:

If the user write "pi" and Calc find that it could be completed in  
"Pizza", "Pizzas" and "Pie".

1. Calc adds the completion for the most probable word (such as  
"zza") after the cursor in a lighter color.

2. Any interaction acts as if there was no auto-completion, except:

3. A tooltip may appear if the user make no input for, says, 3  
seconds. That tooltip suggests to use "Ctrl+Tab" to cycle thru auto-
completion list.

4. When the user presses "Ctrl+Tab", the most probable auto-
completion is added to the input, selected, and the cursor jump after  
it. Here, the cell would contain the word "Pizza" (capitalized), with  
"zza" selected (reverse video) and the cursor after the letter "a".  
"Ctrl+Tab" thus enters a "completion mode" as a consequence of an  
explicit action of the user.

5. If the user presses "Ctrl+Tab" another time, the next auto-
completion is used. Here, "Pizzas" would be used with "zzas" selected  
and the cursor after the "s" letter.

6. If the user presses "Backspace" (or "Delete"), go back to point 1  
(leaves the completion mode).

7. Entering text leaves the "completion mode", accepting the  
completion, adds the entered text after it, and stay in input mode.

8. In completion mode, Enter, Tab, the arrow keys, Begin/End, etc…  
all accept the completion, validate the input (leaving input mode)  
and additionally have their usual effect (change the active cell.)

9. In completion mode, "Escape" leaves both the completion mode and  
the input mode, rejecting the input. The active cell is still the same.

The advantages of this solution are:
* We can later use a menu without changing the behavior (only the  
display)
* This is more similar to the "Excel way" than other solutions
* Once the user has entered "completion mode" with "Ctrl+Tab", the  
behavior of the navigation keys is the same as currently (but  
behavior differs in text input)
* There is a tooltip for the discoverability of the "Ctrl+Tab" key  
combination which is already used in Writer.


OK, now there is still an issue: until now, we have considered auto-
completion in "input mode" (that is, when a cell is active and text  
is written), but not in "edition mode" (entered by double-clicking on  
the cell, pressing F2 or clicking in the input line of the Formula  
Bar). The edition mode differs from input mode in the behavior of the  
arrow keys and delete/backspace keys. I have to think a little more  
to verify that my proposed solution is compatible with edition mode.

Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Philip Ganchev
Hi Clemen, Jaron and all

On the whole, I like Clement's latest solution, with several
reservations. How about a compromise between in-place completions and
showing the whole list. Show a tool tip (or minimal menu) right away
under the cell (where Excel would show a completion menu):

Edit mode (Design 1 - "^" indicates the position of the cursor)

+=========+
| Pi[zza] |
+===^=====+----------------+
|Show completions  Ctrl+Tab|
+--------------------------+


Edit mode (Design 2)

+=========+
| pi      |
+===^=====+--------+
|Pizza  Ctrl+Tab   |
|(More completions)|
+------------------+


Edit mode (Design 3)

+=========+
| pi      |
+===^=====+--------+
|Pizza  Ctrl+Tab   |
|...               |
+------------------+


Completion mode:

+=========+
| Pi[zza] |
+========^+--------+
|Pi  Ctrl+Shift+Tab|
|Pizza             |
|Pizzas    Ctrl+Tab|
|Pie               |
+------------------+


Features:
- Keys work as usual unless user explicitly enters completion mode
- Completion navigation is immediately discoverable, including
backward navigation
- List of completions is visible if the user is interested
- Menu is minimal unless the user asks to see more completions.
- Shows changes in case
- Can get back original contents
- Exiting completion mode works like exiting edit mode

There is one drawback to using Ctrl+Tab: it is commonly used in
applications to navigate between tabs. But I don't have a better
solution.

Writer completion should work the same way (but for individual words).
Maybe even auto-correct should work like that?

Maybe Down and Up should work in addition to Ctrl+Tab and
Ctrl+Shift+Tab in completion mode? If so, what do Right and Left do?

Maybe all menus in OOo should be translucent, to avoid obscuring the
content under them.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Clément Pillias

Le 2 févr. 09 à 00:28, Philip Ganchev a écrit :

> Hi Clement, Jaron and all
>
> On the whole, I like Clement's latest solution, with several
> reservations. How about a compromise between in-place completions  
> and showing the whole list.
> Show a tool tip (or minimal menu) right away under the cell (where  
> Excel would show a completion menu):
>
> Edit mode (Design 1 - "^" indicates the position of the cursor)
>
> +=========+
> | Pi[zza] |
> +===^=====+----------------+
> |Show completions  Ctrl+Tab|
> +--------------------------+

As I have already said, I do not like completion suggestion being  
presented as a selection in Edit Mode… But otherwise this is what I  
suggested in my previous mail.

I think that having the shortcut right-aligned risks confusion with  
menus. I would prefer something like "Cycle thru completions with Ctrl
+Tab" (but it mixes localized text and shortcuts: this can be an  
issue regarding translation.)

> Edit mode (Design 2)
>
> +=========+
> | pi      |
> +===^=====+--------+
> |Pizza  Ctrl+Tab   |
> |(More completions)|
> +------------------+

Is it a menu or a tooltip? Seems that (More completions) is  
clickable? I am afraid that this design confuse the user.

More over, what happens when the user presses Ctrl+Tab or add chars?  
Is the menu/tooltip closed and reopened with a new suggestion? We  
should try not to have flickering menus…

> Edit mode (Design 3)
>
> +=========+
> | pi      |
> +===^=====+--------+
> |Pizza  Ctrl+Tab   |
> |...               |
> +------------------+

Same thing, even worse because the ellipsis is not understandable.

> Completion mode:
>
> +=========+
> | Pi[zza] |
> +========^+--------+
> |Pi  Ctrl+Shift+Tab|
> |Pizza             |
> |Pizzas    Ctrl+Tab|
> |Pie               |
> +------------------+

This may be a good solution. Does "Shift+Ctrl+Tab" get back to the  
previous suggestion, cycling in reverse order, or does it remove  
suggestion? I believe that "no completion" (here "pi") should not be  
in the suggestion list. Something like that:

+==========+
| Pi[zzas] |
+=========^+-------------+
| Pizza   Shift+Ctrl+Tab |
|*Pizzas                 |
| Pie           Ctrl+Tab |
+ ---------------------- +
| pi              Delete |
+------------------------+

Once again there is the problem of updating the menu when Ctrl+tab is  
pressed.

> Features:
> - Keys work as usual unless user explicitly enters completion mode
> - Completion navigation is immediately discoverable, including
> backward navigation
> - List of completions is visible if the user is interested
> - Menu is minimal unless the user asks to see more completions.
> - Shows changes in case
> - Can get back original contents
> - Exiting completion mode works like exiting edit mode
>
> There is one drawback to using Ctrl+Tab: it is commonly used in
> applications to navigate between tabs. But I don't have a better
> solution.
>
> Writer completion should work the same way (but for individual  
> words). Maybe even auto-correct should work like that?
>
> Maybe Down and Up should work in addition to Ctrl+Tab and
> Ctrl+Shift+Tab in completion mode? If so, what do Right and Left do?

Only if we have a menu displayed ;)
But there is another issue: if the "down" key enters the menu, what  
happens when the menu is displayed above the cell because of a lack  
of screen space?

> Maybe all menus in OOo should be translucent, to avoid obscuring  
> the content under them.

This is out of topic, unfortunately.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Clément Pillias

Le 2 févr. 09 à 13:23, Clément Pillias a écrit :

> +==========+
> | Pi[zzas] |
> +=========^+-------------+
> | Pizza   Shift+Ctrl+Tab |
> |*Pizzas                 |
> | Pie           Ctrl+Tab |
> + ---------------------- +
> | pi              Delete |
> +------------------------+

Correction:

+==========+
| Pi[zzas] |
+=========^+-------------+
| Pizza   Shift+Ctrl+Tab |
|*Pizzas                 |
| Pie           Ctrl+Tab |
+ ---------------------- +
| pi           Backspace |
+------------------------+

Changed key to leave auto-completion mode.

Moreover, if we have that kind of menu, maybe we do not need to  
highlight the suggested completion as a selection anymore…

+==========+
| Pizzas   |
+=======^==+-------------+
| Pizza   Shift+Ctrl+Tab |
|*Pizzas                 |
| Pie           Ctrl+Tab |
+ ---------------------- +
| pi           Backspace |
+------------------------+

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Philip Ganchev
In reply to this post by Clément Pillias
On Mon, Feb 2, 2009 at 7:23 AM, Clément Pillias <[hidden email]> wrote:
>
> Le 2 févr. 09 à 00:28, Philip Ganchev a écrit :
...

>> Edit mode (Design 1 - "^" indicates the position of the cursor)
>>
>> +=========+
>> | Pi[zza] |
>> +===^=====+----------------+
>> |Show completions  Ctrl+Tab|
>> +--------------------------+
>
> As I have already said, I do not like completion suggestion being presented
> as a selection in Edit Mode… But otherwise this is what I suggested in my
> previous mail.

Some possible differences from your proposal are:
1. the tool tip appears only in edit mode. When the user enters
completion mode (i.e. cycles through the completions), the tool tip is
replaced by a menu of completions. (We can use a minimal menu instead
of a tool tip, to make a smoother transition to the bigger menu.)
2. the tool tip pops up after 0.3 to 0.6 seconds, not 3 seconds.
3. this tool tip is clickable

> I think that having the shortcut right-aligned risks confusion with menus. I
> would prefer something like "Cycle thru completions with Ctrl+Tab" (but it
> mixes localized text and shortcuts: this can be an issue regarding
> translation.)

I think something like "Show completions  (Ctrl+Tab)" would be easier
to grasp at a glance, and this is the standard form for showing
shortcuts in a tool tip.

>> Edit mode (Design 2)
>>
>> +=========+
>> | pi      |
>> +===^=====+--------+
>> |Pizza  Ctrl+Tab   |
>> |(More completions)|
>> +------------------+
>
> Is it a menu or a tooltip? Seems that (More completions) is clickable? I am
> afraid that this design confuse the user.

Design 2 has a clickable menu. (In Design 1, a tool tip may be better.)

> More over, what happens when the user presses Ctrl+Tab or add chars? Is the
> menu/tooltip closed and reopened with a new suggestion? We should try not to
> have flickering menus…

If the minimal menu is showing (edit mode) and the user adds
characters and stops for 0.3 seconds, only the first line of the menu
("Pizza") changes. The menu remains. If the user presses Ctrl+Tab,
Calc enters completion mode. The menu expands to show several
completions, and the first entry ("Pizza") is selected.

In completion mode, when the user presses Crtl+Tab, the selection
moves to the next entry ("Pizzas", then "Pie", etc.). If the user
types characters in completion mode,  Calc exits completion mode and
enters edit mode.  Should the completions change, or should the menu
shrink back?

>> Edit mode (Design 3)
>>
>> +=========+
>> | pi      |
>> +===^=====+--------+
>> |Pizza  Ctrl+Tab   |
>> |...               |
>> +------------------+
>
> Same thing, even worse because the ellipsis is not understandable.

That's what I was wondering - Is ellipsis obvious enough that it does
not need explanation? Sometimes, adding words can make things less
immediately obvious.

>> Completion mode:
>>
>> +=========+
>> | Pi[zza] |
>> +========^+--------+
>> |Pi  Ctrl+Shift+Tab|
>> |Pizza             |
>> |Pizzas    Ctrl+Tab|
>> |Pie               |
>> +------------------+
>
> This may be a good solution. Does "Shift+Ctrl+Tab" get back to the previous
> suggestion, cycling in reverse order, or does it remove suggestion?

It cycles in reverse order, and the shortcut hint moves to always be
above and below the currently selected item.

> I believe that "no completion" (here "pi") should not be in the suggestion
> list. Something like that:
>
> +==========+
> | Pi[zzas] |
> +=========^+-------------+
> | Pizza   Shift+Ctrl+Tab |
> |*Pizzas                 |
> | Pie           Ctrl+Tab |
> + ---------------------- +
> | pi              Delete |
> +------------------------+

I like the shortcut hint. Why at the bottom? Does
Ctrl-Tab/Ctrl+Shift+Tab navigate to it eventually? I think yes - in
most menus, you can cycle to all the items by using the same key
combination.

> Once again there is the problem of updating the menu when Ctrl+tab is
> pressed.

What's the problem?

...
>> Writer completion should work the same way (but for individual words).
>> Maybe even auto-correct should work like that?

Comments?

>> Maybe Down and Up should work in addition to Ctrl+Tab and
>> Ctrl+Shift+Tab in completion mode? If so, what do Right and Left do?
>
> Only if we have a menu displayed ;)

Yes, only in completion mode.

> But there is another issue: if the "down" key enters the menu, ...

The Down key will not enter the menu, because Down navigates down one
cell in edit mode. Once you press Ctrl+Tab to enter the menu, then
Down and Up could navigate the menu. But then Down cannot be used to
exit completion mode, unlike Enter, Tab, Escape, Left and Right.

>what happens
> when the menu is displayed above the cell because of a lack of screen space?

What happens the Calc menu for "Sheet 1" pops up above the window
because of lack of screen space - how do you navigate with the
keyboard? Or the Windows start menu?

>> Maybe all menus in OOo should be translucent, to avoid obscuring the
>> content under them.
>
> This is out of topic, unfortunately.

I wanted to say "the completion menu should be transparent", but the
obvious objection is "that would be inconsistent with the other
menus". So it's quite related. And if I say it here, there is more
chance that someone will consider making the menus transparent years
later and I am no longer around :-)


On Mon, Feb 2, 2009 at 7:32 AM, Clément Pillias <[hidden email]> wrote:
...
> | pi           Backspace |
> +------------------------+
>
> Changed key to leave auto-completion mode.

OK, Delete will instead keep the current completion (and exit completion mode).

> Moreover, if we have that kind of menu, maybe we do not need to highlight
> the suggested completion as a selection anymore…

It is still useful to show which part was typed by the user and which
part is a completion/modification. We can do that by bolding the
completed part of each entry in the list, or by showing the completed
part in grey inside the cell.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Philip Ganchev
Here is how it is done in Excel 2008 (MacOS):

http://picasaweb.google.com/phil.ganchev/UI#5298386002394838370

It is modal because Down normally navigates one cell down, but if
there are completions it enters the menu. Yet, it's just so easy to
use the list (don't have to read a tool tip), that I wonder if it is
not worth it.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Graham Perrin
Administrator
Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Clément Pillias
Hi Graham,

Thanks for pointing that - Since Firefox used Ctrl+Tab, I thought it  
was OK to use it too.

According to the accessibility guidelines, Ctrl+Tab "Moves focus to  
the next grouping of controls in a dialog or the next table (when Tab  
moves to next cell)". Since we are not in a dialog, here (never? to  
be confirmed), it means that Ctrl+Tab should "move focus to the next  
table".

But what does it mean in the context of Calc? (and for uniformity of  
interaction, in Writer?). Maybe Ctrl+Tab should move to the next  
sheet (coherent with Firefox behavior, since every sheet is  
associated a tab in Calc).

But there is already a shortcut for this (Ctrl+PageDown) so maybe we  
could swap the two shortcuts (but it may confuse advanced users.)

I tried Ctrl+Tab in Mail, and it does the same thing than Tab alone  
when not in a dialog, with the exception of mail edition: then Ctrl
+Tab gives focus to the "To:" field.

Alternatively, on Mac OS X we could maybe use Option+Tab?

Clément.

Le 3 févr. 09 à 14:18, Graham Perrin a écrit :

>
> Whilst <http://qa.openoffice.org/issues/show_bug.cgi?id=18748>  
> targets all OSes, I must vote an unswerving
>
> -1
>
> to control-tab — or tab key with any modifier — for completion, or  
> for auto-completion.
>
> Guidelines including but not limited to:
> <http://developer.apple.com/documentation/userexperience/Conceptual/ 
> AppleHIGuidelines/XHIGKeyboardShortcuts/
> chapter_950_section_1.html#//apple_ref/doc/uid/TP40002725-CHDHCEBJ>
> <http://developer.apple.com/documentation/userexperience/Conceptual/ 
> AppleHIGuidelines/XHIGUserInput/chapter_12_section_3.html#//
> apple_ref/doc/uid/TP30000361-TPXREF12>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Graham Perrin
Administrator
Clément Pillias wrote
Alternatively, on Mac OS X we could maybe use Option+Tab?
That combination is more often used for navigation, sometimes with selection. If you try it in Safari.app and in Mail.app you'll gain a feel for the behaviour.

AFAIK (I could be wrong):
tab, with or without a modifier, is never (should never be?) used for auto-completion.

I'm conscious of opening comments,

Martin Hollmichel-2 wrote
… There seems to be some demand for that issue (24 votes) has a proposed fix and is now open for years.

It would be nice if we can do a decision for 3.1 …
I wonder: if we suggested a change of <http://qa.openoffice.org/issues/show_bug.cgi?id=18748> to _not_ target Mac OS X (amongst all OSes), would that expedite or delay a decision? Would doing so please or displease the patchers?

Regards
Graham



Side note, defocusing from issue 18748: we (users of all OSes in UX) might benefit from some developer tips on how best to proceed whenever it is not immediately easy to find an accelerator key, or key combination, for an all-OSes issue.
Reply | Threaded
Open this post in threaded view
|

Issue 4756 (Expand shortcut possibilities…) alongside issue 18748 (At autocompletion TAB-key-use no longer leads to cell travel)

Graham Perrin
Administrator
Graham Perrin wrote
Side note, defocusing from issue 18748: we (users of all OSes in UX) might benefit from some developer tips on how best to proceed whenever it is not immediately easy to find an accelerator key, or key combination, for an all-OSes issue.
Afterthought: if <http://www.openoffice.org/issues/show_bug.cgi?id=4756> can gain a milestone, then

> Expand shortcut possibilities (Use of <Alt> key is not offered)

— should allow users of OOo on all OSes to assign any accelerator or key combination that is not pre-configured

— less onus on UX to find the two or more sizes that fit all

— (one size fits all may be rare).
Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Clément Pillias
In reply to this post by Graham Perrin
Hi Graham,

Le 4 févr. 09 à 19:19, Graham Perrin a écrit :

> Clément Pillias wrote:
>>
>> Alternatively, on Mac OS X we could maybe use Option+Tab?
>
> That combination is more often used for navigation, sometimes with
> selection. If you try it in Safari.app and in Mail.app you'll gain  
> a feel for the behaviour.

I have seen no reference to Option+Tab in the accessibility or  
keyboard guidelines (but the usage in Safari is coherent with the  
guidelines for Tab and Option taken separately). I believe that it  
has currently no effect in Calc (I am wrong? I do not have the time  
to test now). So the question is: should we keep that combination for  
other purposes than auto-completion, and if yes, for what purpose? If  
we find that this purpose is less valuable than auto-completion or  
that it can be achieved in other ways, maybe we could consider using  
Option+Tab  for auto-completion on the mac…

Note: in Numbers 2008, Ctrl+Tab has no effect and Option+Tab makes an  
error beep. In auto-completion mode, both Enter and Tab (with any  
modifier other than Shift) accept the suggested completion, staying  
in edition mode.

> AFAIK (I could be wrong):
> tab, with or without a modifier, is never (should never be?) used  
> for auto-completion.

Why? Even Tab's use for navigation is an extension of the key function.

> I wonder: if we suggested a change of
> <http://qa.openoffice.org/issues/show_bug.cgi?id=18748> to _not_  
> target Mac OS X (amongst all OSes), would that expedite or delay a  
> decision? Would doing so please or displease the patchers?

I am not sure if this is possible… maybe we can ask  
[hidden email] ?

> Side note, defocusing from issue 18748: we (users of all OSes in  
> UX) might benefit from some developer tips on how best to proceed  
> whenever it is not immediately easy to find an accelerator key, or  
> key combination, for an all-OSes issue.

I would rather think the opposite: we should be the ones with that  
knowledge ;)

Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Clément Pillias
Some additional comment:

Le 4 févr. 09 à 20:02, Clément Pillias a écrit :

> Le 4 févr. 09 à 19:19, Graham Perrin a écrit :
>
>> Clément Pillias wrote:
>>>
>>> Alternatively, on Mac OS X we could maybe use Option+Tab?
>>
>> That combination is more often used for navigation, sometimes with  
>> selection. If you try it in Safari.app and in Mail.app you'll gain  
>> a feel for the behaviour.
>
>> AFAIK (I could be wrong):
>> tab, with or without a modifier, is never (should never be?) used  
>> for auto-completion.

In Numbers, the auto-completion suggestions menu is automatically  
opened when there are more than one suggestion. Jumping to the first  
element of the menu with Ctrl+Tab would then be a navigation use of  
the Tab key ;) But it is not what Number does…

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Jaron Kuppers
In reply to this post by Clément Pillias
Hi all,

I would have to agree with Clément on this issue.  If the menu is shown
during "editing" it may be confused with (for example) a right click menu
that would make the user believe they could interface with the menu in the
same way as any other OOo dropdown menu.

If we want to proceed with a menu idea, I believe we need to achieve a
different "look and feel" from the traditional menu that can be invoked
using right clicking.

Just to shoot an idea out there, it could be easy to convey a "cycle through
the auto correct options" feel using a gradient color scheme to invoke the
feeling of a 3-D "slots machine wheel."  In this case, the "slots machine
wheel" would turn the options and the shortcuts would stay in the same
place.  Check out this example of the use of a "wheel" system on the iphone
app "around town":
http://www.apple.com/iphone/iphone-your-life/around-town.html

I can create a graphic mock-up if this isn't clear.  There is significant
burden on the graphics to convey how the menu works (despite the fact that
it seems self explanatory).  Also, since slot machines generally rotate down
and into the page
 \
  |
 /
v
and the proposed wheel menu would presumably go the opposite direction to be
consistent with how users progress through most menus:
^
 \
  |
 /
the rotation direction invoked by ctrl-tab would have to be explicitly clear
to the user.  The popularity/best autocorrect options could be ranked
according to accessibility. A rough ASCII sketch would be something like
this:

Pizzaz 4
Pie 3           (Ctrl+shift+tab)
Pi            pi (Backspace)
Pizza 1        (Ctrl+tab)
Pizzas 2

(FYI the numbers are just the rankings, they wouldn't actually appear)

Future thought: If we were to implement the Direct Manipulation Snippets
concept, a modified DMS menu (for calc) would solve some of the "look"
problems.  This DMS menu will presumably have a unique look which the user
will associate with certain control parameters.

I hope this random thought is helpful.

Cheers,
Jaron



On Mon, Feb 2, 2009 at 7:32 AM, Clément Pillias <[hidden email]>wrote:

>
> Le 2 févr. 09 à 13:23, Clément Pillias a écrit :
>
>  +==========+
>> | Pi[zzas] |
>> +=========^+-------------+
>> | Pizza   Shift+Ctrl+Tab |
>> |*Pizzas                 |
>> | Pie           Ctrl+Tab |
>> + ---------------------- +
>> | pi              Delete |
>> +------------------------+
>>
>
> Correction:
>
> +==========+
> | Pi[zzas] |
> +=========^+-------------+
> | Pizza   Shift+Ctrl+Tab |
> |*Pizzas                 |
> | Pie           Ctrl+Tab |
> + ---------------------- +
> | pi           Backspace |
> +------------------------+
>
> Changed key to leave auto-completion mode.
>
> Moreover, if we have that kind of menu, maybe we do not need to highlight
> the suggested completion as a selection anymore…
>
> +==========+
> | Pizzas   |
> +=======^==+-------------+
> | Pizza   Shift+Ctrl+Tab |
> |*Pizzas                 |
> | Pie           Ctrl+Tab |
> + ---------------------- +
> | pi           Backspace |
> +------------------------+
>
> Clément.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Jaron Kuppers
In reply to this post by Clément Pillias
In my previous email (like minutes ago) I hadn't given any thought to the
restriction in using Ctrl+tab, so please keep that in mind. My apologizes
for not catching up on all the emails before responding.

It seems we have hit sort of a wall as far as the available interface
buttons.  It seems the only semi-logical buttons available are the page-up
and page-down buttons.
Hmmm...  I will get back to you on this later.  This problem has become
extremely difficult to solve without the use of Ctrl-tab.

Cheers,
Jaron



On Wed, Feb 4, 2009 at 2:09 PM, Clément Pillias <[hidden email]>wrote:

> Some additional comment:
>
> Le 4 févr. 09 à 20:02, Clément Pillias a écrit :
>
>  Le 4 févr. 09 à 19:19, Graham Perrin a écrit :
>>
>>  Clément Pillias wrote:
>>>
>>>>
>>>> Alternatively, on Mac OS X we could maybe use Option+Tab?
>>>>
>>>
>>> That combination is more often used for navigation, sometimes with
>>> selection. If you try it in Safari.app and in Mail.app you'll gain a feel
>>> for the behaviour.
>>>
>>
>>  AFAIK (I could be wrong):
>>> tab, with or without a modifier, is never (should never be?) used for
>>> auto-completion.
>>>
>>
> In Numbers, the auto-completion suggestions menu is automatically opened
> when there are more than one suggestion. Jumping to the first element of the
> menu with Ctrl+Tab would then be a navigation use of the Tab key ;) But it
> is not what Number does…
>
>
> Clément.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Jaron Kuppers
In reply to this post by Philip Ganchev
Hi Philip and everyone else,

On Tue, Feb 3, 2009 at 2:15 AM, Philip Ganchev <[hidden email]>wrote:

> Here is how it is done in Excel 2008 (MacOS):
>
> http://picasaweb.google.com/phil.ganchev/UI#5298386002394838370
>
> It is modal because Down normally navigates one cell down, but if
> there are completions it enters the menu. Yet, it's just so easy to
> use the list (don't have to read a tool tip), that I wonder if it is
> not worth it.
>


Users can currently use the arrow keys to navigate out of an Autocompletion
(the complaint being that they want to be able to tab out as well).  All
that would be doing is transferring the burden from users who like to use
Tab and Enter to navigate, to user who like to use arrow keys to navigate,
so I don't really see this as being a "solution" per se.  That is not to say
that I don't think its a viable interface method we should consider, it just
means that not all our users will be satisfied with our solution (which
never happens anyways).

On another note:
The "true" solution to this whole problem is to ask the developers to code
in that tab allows users to navigate out of a cell.  The majority of this
discussion has been about adding more UI content in response to a problem
closely identified with the root cause of issue 18748.  Issue 18748 doesn't
ask us to improve the access of Autocompletion options.  I don't want to
diminish our discussions I just want to make sure we stay on track or change
this discussion to a different thread.

Cheers,
Jaron
Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Clément Pillias
Hi Jaron,

I have to disagree with you, here.

Actually, if you also read the issues closed as duplicates of 18748  
such as 7566, you will see that it is the whole behavior of auto-
completion that is questioned.

And 23911 has been marked as duplicate of 1127 which has been marked  
a duplicate of 18748…

Moreover, these duplicate issues show that some users do not think  
about the right arrow key to replace tab. I suppose that in cell  
input mode, the action of arrow keys might seem unpredictable to users…

>

Clément.

Le 4 févr. 09 à 21:39, Jaron Kuppers a écrit :

> Users can currently use the arrow keys to navigate out of an  
> Autocompletion (the complaint being that they want to be able to  
> tab out as well).  All that would be doing is transferring the  
> burden from users who like to use Tab and Enter to navigate, to  
> user who like to use arrow keys to navigate, so I don't really see  
> this as being a "solution" per se.  That is not to say that I don't  
> think its a viable interface method we should consider, it just  
> means that not all our users will be satisfied with our solution  
> (which never happens anyways).

> On another note:
> The "true" solution to this whole problem is to ask the developers  
> to code in that tab allows users to navigate out of a cell.  The  
> majority of this discussion has been about adding more UI content  
> in response to a problem closely identified with the root cause of  
> issue 18748.  Issue 18748 doesn't ask us to improve the access of  
> Autocompletion options.  I don't want to diminish our discussions I  
> just want to make sure we stay on track or change this discussion  
> to a different thread.
>
> Cheers,
> Jaron


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: issue 18748: At autocompletion TAB-key-use no longer leads to cell travel

Graham Perrin
Administrator
Subject: auto-completion in cells in Numbers '08 (1.0.3) on Mac OS X 10.5.6

1. begin with an empty sheet
2. in one cell, type Mary
3. in another cell, type marriage
4. save
5. in another cell type mar
6. observe the menu of matching words


7. arrow down reaches the uppermost option


8. arrow down once more reaches the second option


9. tab or return key accepts the item and positions the i-beam at the tail  of the word


or

7. tab accepts the uppermost option AND selects the tail end of the word (i.e. the part of the word that was not typed by the user)


8. tab once more moves to the cell to the right


or

7. return key accepts the uppermost option AND selects the tail end of the word (i.e. the part of the word that was not typed by the user)

8. return key once more moves to the cell below

or

7. enter key enters the word mar and moves to the cell below

— 

Those are the keys:

• tab
• arrow up
• arrow down
• return
• enter
123