1751290 - Lock the list UI when editing a contact

Status: RESOLVED FIXED

(Thunderbird :: Address Book, enhancement, P1)

Description

[Alessandro Castellani [:aleca]]

Attachment: Address [e-mail]

When the user is editing a contact in the new address book, we allow clicking around in the list.
This is very strange since it doesn't produce any visible result as we keep the editable form visible in the right panel.

I propose to lock the list so it can't be interacted with, as well as visually fade it out and highlighting the currently edited field.

Attaching a quick mock-up.
Ignore the different layout of the right panel since that's gonna happen later, but that's the direction we should go to improve that area.

Comment 1

[Thomas D. (:thomas8)]

I haven't had much time yet to reflect on this, but is there a reason for us to still have Cancel and Save Buttons on the editing panel?
Would it work if the contact editing panel would act like the Preferences, just to save any input when it loses focus?
Also, we should probably enforce entering either an email address or a name for any contact.
Right now, you can even save a contact which is totally empty - not useful.
So if we just had implicit instant saving (e.g. upon blur of each field), maybe we don't need to lock the UI. Not locking the UI would seem preferable.

Comment 2

[Alessandro Castellani [:aleca]]

(In reply to Thomas D. (:thomas8) from comment #1)

I haven't had much time yet to reflect on this, but is there a reason for us to still have Cancel and Save Buttons on the editing panel?
Would it work if the contact editing panel would act like the Preferences, just to save any input when it loses focus?

IIRC we discussed this in the past, or in Matrix or in another bug.
I don't exactly recall, anyway, not a big deal. Here's the explanation why that wouldn't be good nor correct.

The TLDR is: An Address Book Contact is a readable data set that needs to be read more often that written.
A contact needs to have a readable state and a writable state, and those needs to be carefully separated to avoid data-loss or other related accidents.

Contacts information are more delicate than preferences, which if you accidentally change something you can switch it back or restore defaults pretty easily. I would also argue that we inherited the live editing of prefs and account settings from Firefox without carefully questioning if they're good or bad.
For the account settings, that approach is actually pretty bad, as an "edit and then save" state for account information is commonly used in any other application to specifically force the user to confirm the changes, and an handy "cancel" to discard accidents.

Another TLDR is:

• Accidentally changing prefs because live editable is not a big deal.
• Accidentally changing a contact because live editable is a very big deal.

Also, we should probably enforce entering either an email address or a name for any contact.

Indeed we should.

Comment 3

[Magnus Melin [:mkmelin]]

Yep, instant editing would be problematic, and especially for online calendars where you'd send/sync data way more often that you'd like.

Regarding the bug here, there's also the complication of the left-most column (the address book selection), which would also need to be read-only while editing. So overall I'm not sure if it's worth keeping the editing in the right column. Just having it as a modal overlay center of the page could be an alternative worth exploring as well, since basically modality is what we're after here.

Comment 4

[Thomas D. (:thomas8)]

Thank you for the explanation, I see.

(In reply to Magnus Melin [:mkmelin] from comment #3)

Regarding the bug here, there's also the complication of the left-most column (the address book selection), which would also need to be read-only while editing. So overall I'm not sure if it's worth keeping the editing in the right column. Just having it as a modal overlay center of the page could be an alternative worth exploring as well, since basically modality is what we're after here.

Good point! Modal editing dialog might make it clearer to the user that they must choose either Cancel or Save before proceeding with anything else.

Comment 5

[Alessandro Castellani [:aleca]]

Indeed, we would need to lock also the Address Books list, which it's fairly trivial to do.

Just having it as a modal overlay center of the page could be an alternative worth exploring as well, since basically modality is what we're after here.

I'm really not sure about this.
We're trying to remove the use of dialogs as much as possible, and moving these things into HTML dialogs feels like a partial solution.

I'm not against it as a solution, but I see some problems:

• Limited space. Instead of using the whole scrollable page height, we're once again cramping a very long section inside a smaller child element.
• Visual consistency. We still don't have a common reusable HTML dialog style, so more CSS will be needed to properly style this area, adding unnecessary repetition.
• Nested modals. Geoff implemented the photo upload and crop feature, which it correctly lives in a modal dialog. Having a modal opened from another modal should be a strict "no" in terms of solutions.
• Keyboard a11y. It would be harder to control the natural focus ring of the content page. Also we should account for accidental modal closing from an Esc keypress.

All the things I listed above are obviously fixable, but I think we should focus on the current implementation and improve that since it gives us more flexibility, less limitations, and it was specifically built for this purpose.

Also, having the view and editable state in the same panel makes our life way easier when adding the needed responsiveness to support smaller screens.

Comment 6

[Magnus Melin [:mkmelin]]

Good points. I guess what we want is really a modal area. We should figure out how to easiest achieve that so that. Maybe overlaying the left side with some semi-transparent layer with high z-index would work...

Comment 7

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1751290 - Lock the list UI when editing a contact. r=aleca

Comment 8

[Magnus Melin [:mkmelin]]

One of the tests was perma-failing so disabled it for now: https://hg.mozilla.org/comm-central/rev/dc7b69ac8778b8f39bfed3637cd26765516c8cc3

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/78d3ebf4c6fe
Lock the list UI when editing a contact. r=aleca

Comment 10

[Magnus Melin [:mkmelin]]

(Oh, bot was lagging behind.)

Comment 11

[Geoff Lankow (:darktrojan)]

I fixed the broken test in bug 1752042.