(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.
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. 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.