Bug 1752013 Comment 23 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Henry Wilkes [:henry] from comment #20)
> I'll take this and put a patch together.

That's awesome, thank you for being the hero who restores ux-efficiency of editing contacts, avoiding needless floods of bad feedback from users as we've seen it in similar ux-efficiency Bug 1685007.

> Out of curiosity, to wayne and thomas: have you been using the "Edit" option in the context menu since it landed? Has that helped alleviate your problems?

Having the `Edit` action in context menu is mostly a logical necessity - skipping the default action in the list of actions would be weird. In fact, it's good practice to **show the default action at the very *top* of the context menu**, even in **bold** (cf. Windows explorer file context) - can we do that please?

For mouse users, contextual `Edit` may be somewhat better than status quo e.g. for contacts far down the list, as it avoids navigating to the distant `Edit` button on top. However, contextual `Edit` is still way too clumsy and error-prone for regular usage: Nothing beats the no-brainer simplicity and efficiency of just double-clicking to edit.

(In reply to Wayne Mery (:wsmwk) from comment #22)
> p.s. I'm sure I have also used <enter> to invoke edit, probably when using arrow keys (rather than mouse) to go through contacts.

**`Enter` on selected item is the keyboard equivalent for `double-click` item**, both are required to restore the *default action* status of `Edit`.
Without `Enter`, the keyboard-only workflow (e.g. for the blind) would remain pretty cumbersome: who wants 4 or 5 different keypresses which needs a lot of attention, when the item is already selected and a simple `Enter` can do?

Restoring `Enter` forms part of the minimal acceptance criteria for this bug, and I'm confident that Henry will be able to fix that, too.
(In reply to Henry Wilkes [:henry] from comment #20)
> I'll take this and put a patch together.

That's awesome, thank you for being the hero who restores ux-efficiency of editing contacts, avoiding needless floods of bad feedback from users as we've seen it in similar ux-efficiency Bug 1685007.

> Out of curiosity, to wayne and thomas: have you been using the "Edit" option in the context menu since it landed? Has that helped alleviate your problems?

Having the `Edit` action in context menu is mostly a logical necessity - skipping the default action in the list of actions would be weird. It's also good for exploration and discovery. In fact, it's good practice to **show the default action at the very *top* of the context menu**, even in **bold** (cf. Windows explorer file context) - can we do that please?

For mouse users, contextual `Edit` may be somewhat better than status quo e.g. for contacts far down the list, as it avoids navigating to the distant `Edit` button on top. However, contextual `Edit` is still way too clumsy and error-prone for regular usage: Nothing beats the no-brainer simplicity and efficiency of just double-clicking to edit.

(In reply to Wayne Mery (:wsmwk) from comment #22)
> p.s. I'm sure I have also used <enter> to invoke edit, probably when using arrow keys (rather than mouse) to go through contacts.

**`Enter` on selected item is the keyboard equivalent for `double-click` item**, both are required to restore the *default action* status of `Edit`.
Without `Enter`, the keyboard-only workflow (e.g. for the blind) would remain pretty cumbersome: who wants 4 or 5 different keypresses which needs a lot of attention, when the item is already selected and a simple `Enter` can do?

Restoring `Enter` forms part of the minimal acceptance criteria for this bug, and I'm confident that Henry will be able to fix that, too.
(In reply to Henry Wilkes [:henry] from comment #20)
> I'll take this and put a patch together.

That's awesome, thank you for being the hero who restores ux-efficiency of editing contacts, avoiding needless floods of bad feedback from users as we've seen it in similar ux-efficiency Bug 1685007.

> Out of curiosity, to wayne and thomas: have you been using the "Edit" option in the context menu since it landed? Has that helped alleviate your problems?

Having the `Edit` action in context menu is mostly a logical necessity - skipping the default action in the list of actions would be weird. It's also good for exploration and discovery. In fact, it's good practice to **show the default action at the very *top* of the context menu**, even in **bold** (cf. Windows explorer file context) - can we do that please?

For mouse users, contextual `Edit` may be somewhat better than status quo e.g. for contacts far down the list, as it avoids navigating to the distant `Edit` button on top. However, contextual `Edit` is still way too clumsy and error-prone for regular usage: Nothing beats the no-brainer simplicity and efficiency of just double-clicking to edit.

(In reply to Wayne Mery (:wsmwk) from comment #22)
> p.s. I'm sure I have also used <enter> to invoke edit, probably when using arrow keys (rather than mouse) to go through contacts.

**`Enter` on selected item is the keyboard equivalent for `double-click` item**, both are required to restore the *default action* status of `Edit`.
Without `Enter`, the keyboard-only workflow (e.g. for the blind) would remain pretty cumbersome: who wants 4 or 5 different keypresses which needs a lot of attention when the item is already selected and a simple `Enter` can do?

Restoring `Enter` forms part of the minimal acceptance criteria for this bug, and I'm confident that Henry will be able to fix that, too.

Back to Bug 1752013 Comment 23