Bugzilla

(In reply to Henry Wilkes [:henry] from comment #3)
> @thomas8 I'm finding it difficult to navigate all your separate bugs about a specific keyboard shortcut or controls. It makes it hard to discuss what keyboard behaviour to implement and they probably need to be considered as a collection rather than simply copying each individual old addressbook feature.

Hi Henry, thank you for your feedback!

Here's a more visual way of navigating the associated bugs in the depency tree (linked under `Blocks` field):
https://bugzilla.mozilla.org/showdependencytree.cgi?id=1705276&hide_resolved=1

If you look at many of these bugs, we don't have much of a choice - you have already pointed to some of the ARIA requirements yourself. Enter must press the default button in a dialog, and ESC must cancel. Ctrl+Space must (de-)select items. Alt+Enter can only be used for item properties (on Windows). Ctrl+N can only be used for creating new items - typically the most useful item in the current context (perhaps that's one of the few with a bit of room for debate). Many of these affect different layers of the UX and applicability, so I would be surprised if they can all be implemented in the same way. Filing apples and pears in the same bug can easily end up in confusion, and has a high risk of omitting stuff. Also, from many years of bug management experience especially when it comes to shortcuts, it's probably easier to discuss each shortcut on its own merits (of course, with consideration for the shortcut environment as you say). Trust me, it's unlikely that we are going to reinvent the wheel for an UI which hasn't changed much conceptually.

I think it's important to file each keyboard UX issue separately because they represent different use cases / workflows of importance - we must ensure to discuss and re-enable keyboard efficiency for most if not all of these workflows. These shortcuts have existed for a reason: UX-efficiency! Also, we should avoid breaking the muscle memory of existing users whereever possible. We'll still get enough rumblings for changing /flattening the entire contact editing UX...

I suggest that we use my bugs to discuss and greenlight each keyboard issue in terms of UX and then to track if we've actually implemented it - of course if you find that you need some shared technical bugs for implementation, feel free to open them and make my bugs depend on yours. My focus is on UX, not implementation.

> Could you accumulate the shortcut requests into a single "addressbook keyboard controls" enhancement.
> Also note, there is an existing bug 1717632 for accessibility problems.

I had a look at your bug 1717632 before I started filing the bugs and figured that an all-in-one conglomerate bug will get very confusing very fast, even for implementation. And in the long run, it's not sustainable, because we want to avoid duplicates and we also don't want users to file more and more stuff and discussion into one mega bug. The other problem is that everyone will need to read the entire bug and patches to find out if a certain keyboard scenario is covered or not (as in bug 1729608) - I don't think we have that time. Ymmv.

That said, and starting out from your proposal, having a dedicated  "New addressbook keyboard UX" meta bug which parents all the keyboard bugs on their own merit will be a good idea to disentangle them from other types of AB bugs. I have filed a dedicated Meta bug for that:

Bug 1753093 - [meta] Keyboard UX in the New Address Book (shortcuts, accessibility and ux-efficiency workflows)

(In reply to Henry Wilkes [:henry] from comment #3)
> @thomas8 I'm finding it difficult to navigate all your separate bugs about a specific keyboard shortcut or controls. It makes it hard to discuss what keyboard behaviour to implement and they probably need to be considered as a collection rather than simply copying each individual old addressbook feature.

Hi Henry, thank you for your feedback!

Here's a more visual way of navigating the associated bugs in the depency tree (linked under `Blocks` field):
https://bugzilla.mozilla.org/showdependencytree.cgi?id=1705276&hide_resolved=1

If you look at many of these bugs, we don't have much of a choice - you have already pointed to some of the ARIA requirements yourself. Enter must press the default button in a dialog, and ESC must cancel. Ctrl+Space must (de-)select items. Alt+Enter can only be used for item properties (on Windows). Ctrl+N can only be used for creating new items - typically the most useful item in the current context (perhaps that's one of the few with a bit of room for debate). Many of these affect different layers of the UX and applicability, so I would be surprised if they can all be implemented in the same way. Filing apples and pears in the same bug can easily end up in confusion, and has a high risk of omitting stuff. Also, from many years of bug management experience especially when it comes to shortcuts, it's probably easier to discuss each shortcut on its own merit (of course, with consideration for the shortcut environment as you say). Trust me, it's unlikely that we are going to reinvent the wheel for an UI which hasn't changed much conceptually.

I think it's important to file each keyboard UX issue separately because they represent different use cases / workflows of importance - we must ensure to discuss and re-enable keyboard efficiency for most if not all of these workflows. These shortcuts have existed for a reason: UX-efficiency! Also, we should avoid breaking the muscle memory of existing users whereever possible. We'll still get enough rumblings for changing /flattening the entire contact editing UX...

I suggest that we use my bugs to discuss and greenlight each keyboard issue in terms of UX and then to track if we've actually implemented it - of course if you find that you need some shared technical bugs for implementation, feel free to open them and make my bugs depend on yours. My focus is on UX, not implementation.

> Could you accumulate the shortcut requests into a single "addressbook keyboard controls" enhancement.
> Also note, there is an existing bug 1717632 for accessibility problems.

I had a look at your bug 1717632 before I started filing the bugs and figured that an all-in-one conglomerate bug will get very confusing very fast, even for implementation. And in the long run, it's not sustainable, because we want to avoid duplicates and we also don't want users to file more and more stuff and discussion into one mega bug. The other problem is that everyone will need to read the entire bug and patches to find out if a certain keyboard scenario is covered or not (as in bug 1729608) - I don't think we have that time. Ymmv.

That said, and starting out from your proposal, having a dedicated  "New addressbook keyboard UX" meta bug which parents all the keyboard bugs on their own merit will be a good idea to disentangle them from other types of AB bugs. I have filed a dedicated Meta bug for that:

Bug 1753093 - [meta] Keyboard UX in the New Address Book (shortcuts, accessibility and ux-efficiency workflows)