This is a meta bug for the new Address Book user interface that I am working on.

This bug is currently tracking the development of the new addressbook, whilst it remains only enabled by a preference. Will this bug also track replacing the old addressbook as the default and removing the old addressbook code? (I want to block another bug based on the latter.)

Use this one for now.

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

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

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

Moving keyboard-related bugs into their own meta bug:
Bug 1753093 - [meta] Keyboard UX in the New Address Book (shortcuts, accessibility and ux-efficiency workflows)

Sorry if this has been commented on previously, but bugzilla is difficult to navigate via screen reader.

Hopefully there will be a way to create / modify mailing lists in updated UI.

Using tb100B1 there doesn't seem to be a way of doing this. I remember in previous releases there used to be a file \ new \ createMailingList or similar entry in the file \ new menu when addressbook tab was open. This is not there anymore.

(In reply to Rich Caloggero from comment #6)

Sorry if this has been commented on previously, but bugzilla is difficult to navigate via screen reader.

Hopefully there will be a way to create / modify mailing lists in updated UI.

Using tb100B1 there doesn't seem to be a way of doing this. I remember in previous releases there used to be a file \ new \ createMailingList or similar entry in the file \ new menu when addressbook tab was open. This is not there anymore.

Hey Rich,

thanks for reaching out. I'm really happy that you use beta!

There are two points here:

• Please e-mail me with your troubles and problems navigating bugzilla (nicolai@thunderbird.net).
• We will do an overhaul of the UI starting with Bug 1762126. The stuff from this patch is not ready to land yet. If you'd like me to notify you about changes please reach out to me! (Through Bugzilla and/or an email is both fine for me.)

I'd really like you to give me feedback for the upcoming betas!

(In reply to Rich Caloggero from comment #6)

Sorry if this has been commented on previously, but bugzilla is difficult to navigate via screen reader.

Hopefully there will be a way to create / modify mailing lists in updated UI.

Using tb100B1 there doesn't seem to be a way of doing this. I remember in previous releases there used to be a file \ new \ createMailingList or similar entry in the file \ new menu when addressbook tab was open. This is not there anymore.

For the sake of the longevity of Bugzilla I'll add the Bug number for your request. Bug 1751282

(In reply to Rich Caloggero from comment #6)

bugzilla is difficult to navigate via screen reader.

Hey Rich, as you mentioned screen reader: To get an overview of the planned improvements for keyboard control over the new address book, please check out the Keyboard UX bug which I filed for the new Address Book:

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

For your ease of access, here's a direct link to the bugs listed on the new address book's keyboard UX bug, which we call dependency tree:
https://bugzilla.mozilla.org/showdependencytree.cgi?id=1753093&hide_resolved=1