1493158 - When fast-clicking To/Cc/Bcc recipient type selector dropdown arrow, easy to accidentally remove recipient because delete button unexpectedly appears

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[xracoonx]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180830143136

Steps to reproduce:

Click on the left side of a To/Cc/Bcc selector to change it.


Actual results:

The recipient got deleted because the delete button appeared.


Expected results:

The recipient should not have been deleted and the delete button should be visible all the time rather than suddenly appear.

Comment 1

[xracoonx]

There is also another problem with the current delete button showing on hover: It does not work at all with touch devices since they don't support hover.

Comment 2

[Wayne Mery (:wsmwk)]

I don't recal

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to xracoonx from comment #0)
> Click on the left side of a To/Cc/Bcc selector to change it.
> ... 
> The recipient got deleted because the delete button appeared.

As you point out, this only happens when clicking near the far left.  Perhaps not the average use case.

> delete button should be visible all the time rather than suddenly appear.

bug 1100103 comment 19 argues the opposite. So the design choice is intentional and not likely to be reconsidered

Comment 4

[Wayne Mery (:wsmwk)]

(In reply to xracoonx from comment #1)
> It does not work at all with touch devices since they don't support hover.

bug 1100103 doesn't mention touch, so your observation deserves a separate bug

Comment 5

[xracoonx]

(In reply to Wayne Mery (:wsmwk) from comment #3)
> (In reply to xracoonx from comment #0)
> > Click on the left side of a To/Cc/Bcc selector to change it.
> > ... 
> > The recipient got deleted because the delete button appeared.
> 
> As you point out, this only happens when clicking near the far left. 
> Perhaps not the average use case.

I don't think it not being average doesn't make this a good ux choice.

> > delete button should be visible all the time rather than suddenly appear.
> 
> bug 1100103 comment 19 argues the opposite. So the design choice is
> intentional and not likely to be reconsidered

There is an alternative to having it visible at all times:

- Show the delete button only when the cursor is in the address field
- Then when the delete button is pressed, move the cursor to the next address field

Comment 6

[xracoonx]

(In reply to xracoonx from comment #5)
> I don't think it not being average doesn't make this a good ux choice.

Too many negations... should be:

I think it not being being average doesn't make this a good ux choice.

Comment 7

[Jorg K (CEST = GMT+2)]

Agreed, it's not a good UX choice, it was a quick fix for the long-standing problem of not being able to delete addresses quickly. One day we might change the addressing widget as requested in bug 440377.

Richard, how about a preference to permanently show the [x], is that possible?

Comment 8

[Richard Marti (:Paenglab)]

Now it's done through simple CSS. With a pref we could set an attribute to the window or better the addressingWidget that can be used for a second CSS selector to show always the button.

Comment 9

[Jorg K (CEST = GMT+2)]

Should we do that? Thomas, what do you think?

Comment 10

[Wayne Mery (:wsmwk)]

I don't think this is in the territory of being important enough to offer a hidden pref. 

And we went through an entire release cycle with no complaints (this is the first bug report and I don't think there have been any complaints in support) which should count for something.  But if it functions poorly then we should just fix it without a pref.

Comment 11

[Jorg K (CEST = GMT+2)]

I'm not sure about which release cycle you're taking. This is new in TB 60 and that version hasn't even been shipped to all TB52 users.

Don't let perfect be enemy of better ;-) - Ideally we'd implement bug 440377 one day. What we have now is a good solution, but it doesn't work (well?) for touch devices (although I wonder whether they don't implement hover via "touch once"). So we could try to detect this with a lot of effort, or simply add a preference.

Comment 12

[Wayne Mery (:wsmwk)]

Ha, quite right. I forget I've used this going on a year only from running development builds.  


Touch devices is a whole territory unto itself, which we have largely ignored throughout the product.  But that isn't the reporter's original premise in comment 0.

Comment 13

[xracoonx]

(In reply to Wayne Mery (:wsmwk) from comment #12)
> Touch devices is a whole territory unto itself, which we have largely
> ignored throughout the product.  But that isn't the reporter's original
> premise in comment 0.

Surely not en explicit premise. Here is the explicit one: bug 1504511.

Comment 14

[Thomas D. (:thomas8)]

(In reply to Jorg K (GMT+1) from comment #9)
> Should we do that? Thomas, what do you think?

I don't know what's the best way forward here, but the current UX is clearly just a stop gap measure / hot fix and was implemented as such.

The pref does not sound like the best solution, as Wayne said, maybe better to fix it properly for everyone rather than adding more complexity.

Implementation idea:
* Maybe we could just permanently show a very faint version of the [x] delete button, which then gets more pronounced when hovered.

Problems of current UX:
- The current delete button is very hard to discover, as it needs hovering another unrelated UI element (recipient type selector).
- As reporter correctly argues in comment 0, it violates UX error prevention that when user targets the dropdown, we suddenly change things under the mouse and when he clicks, it's now unexpectedly deleting before you even know it (especially when clicking fast).

(In reply to Wayne Mery (:wsmwk) from comment #3)
> (In reply to xracoonx from comment #0)
> As you point out, this only happens when clicking near the far left. 
> Perhaps not the average use case.

Hmmm, I think clicking on the far left is actually a very likely use case because that's where the dropdown arrow is, so there's nothing unlikely about clicking that arrow to get the dropdown.

> > delete button should be visible all the time rather than suddenly appear.
> bug 1100103 comment 19 argues the opposite. So the design choice is
> intentional and not likely to be reconsidered

That's my comment but I don't recall suggesting to let the delete button appear from behind some other rather unrelated UI element and suddenly reducing the size of that element in the process. Let's face it, as reporter say, this is pretty much non-standard UX and quite odd. We only did it as a hot fix, needs a better solution even before we redesign the whole thing.

I suggest reopening this bug to find something better here.

Comment 15

[Wayne Mery (:wsmwk)]

minor points...

(In reply to Thomas D. (currently busy elsewhere) from comment #14)
> (In reply to Jorg K (GMT+1) from comment #9)
> > Should we do that? Thomas, what do you think?
> 
> I don't know what's the best way forward here, but the current UX is clearly
> just a stop gap measure / hot fix and was implemented as such.
> 
> The pref does not sound like the best solution, as Wayne said, maybe better
> to fix it properly for everyone rather than adding more complexity.
> 
> Implementation idea:
> * Maybe we could just permanently show a very faint version of the [x]
> delete button, which then gets more pronounced when hovered.

I like faint. 

> Problems of current UX:
> - The current delete button is very hard to discover, as it needs hovering
> another unrelated UI element (recipient type selector).

This is the worst part of the bug. But IMO the only users that won't discover are those who never click or hover in that part of the UI - seriously, that's got to be a minority of users.

> - As reporter correctly argues in comment 0, it violates UX error prevention
> that when user targets the dropdown, we suddenly change things under the
> mouse and when he clicks, it's now unexpectedly deleting before you even
> know it (especially when clicking fast).

OTOH it will only happen once to a user, and then they won't do it again. :)

Alternative, put the X in the middle?

Comment 16

[jmkristian]

(In reply to Wayne Mery (:wsmwk) from comment #15)
> > - As reporter correctly argues in comment 0, it violates UX error prevention
> > that when user targets the dropdown, we suddenly change things under the
> > mouse and when he clicks, it's now unexpectedly deleting before you even
> > know it (especially when clicking fast).
> 
> OTOH it will only happen once to a user, and then they won't do it again. :)

It happened several times to this user, and I cursed it every time. I had developed an unconscious habit using previous versions of Thunderbird, and it takes time and repetition to form a new habit.

Comment 18

[mpstryker]

When I try to change recipient type (to To:, cc:, bcc:, or Reply-To:) I almost always end up deleting the recipient in Thunderbird since verion 60.3.3 because the delete button appears to the left.  This is a terrible UI.  Please fix to include the delete button along with To/cc/bcc/Reply-To in a single drop-down list, with delete at the BOTTOM.  It is easy enough to delete a recipient the old way, by deleting the address itself from the box to the right.  Making DELETE the first choice was a mistake.

Comment 19

[xracoonx]

(In reply to mpstryker from comment #18)
> When I try to change recipient type (to To:, cc:, bcc:, or Reply-To:) I
> almost always end up deleting the recipient in Thunderbird since verion
> 60.3.3 because the delete button appears to the left.  This is a terrible
> UI.  Please fix to include the delete button along with To/cc/bcc/Reply-To
> in a single drop-down list, with delete at the BOTTOM.  It is easy enough to
> delete a recipient the old way, by deleting the address itself from the box
> to the right.  Making DELETE the first choice was a mistake.

While I agree that the delete button is currently not well placed, I disagree that it should just be added to the drop down list. Take a use case where you want to delete most a larger number of recipients. You don't want to do this via a drop down list. Rather the button could be placed on the right of the address field or so.

Also, it would be great if one could easily delete context with the keyboard> This would work better if, for example, pressing backspace on an empty address field would not only move the cursor to the previous address field but also select its whole text.

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to Thomas D. (currently busy elsewhere) from comment #14)

...
I suggest reopening this bug to find something better here.

I defer to UX

Comment 22

[Richard Marti (:Paenglab)]

Attachment: 1493158-fixed-deleteAddress.patch

Yes, showing the button always doesn't take much space.
Jörg, this patch shows the delete button allways. What do you think?

One question, is there a better solution than "this.parentNode.nextSibling.nextSibling"?

Comment 23

[Jorg K (CEST = GMT+2)]

Comment on attachment 9040960 [details] [diff] [review]
1493158-fixed-deleteAddress.patch

Hmm, this was discussed far and wide in bug 1100103. We opted for the "not permanently on" option. So I don't really like this.

Maybe this can be driven by some option? Or we can detect touch users?

Comment 24

[xracoonx]

(In reply to Jorg K (GMT+1) from comment #23)

Comment on attachment 9040960 [details] [diff] [review]
1493158-fixed-deleteAddress.patch

Hmm, this was discussed far and wide in bug 1100103. We opted for the "not
permanently on" option. So I don't really like this.

Maybe this can be driven by some option? Or we can detect touch users?

I tried to follow the discussion there. Was the upshot of the discussion there to have a delete button appear on hover where the to/cc/bcc button is? If so that seems like a strange UI. This is not only a touch interface problem. The sudden appearance of a delete button in place of another button on hover is the problem as well.

Comment 25

[Richard Marti (:Paenglab)]

Attachment: close-on-right.png

(In reply to Jorg K (GMT+1) from comment #23)

Maybe this can be driven by some option? Or we can detect touch users?

This isn't simply doable. Only show the delete button would narrow the menulist which can hide the content in it. FX has a detection for touch devices but we not.

My screenshot shows the delete button is moved to the right when hovering the menulist. The pro of this solution is, the button is not on the dropmarker position and is nearer to the address which makes it clearer for what it is.

What do you think about this?

Comment 26

[xracoonx]

(In reply to Richard Marti (:Paenglab) from comment #25)

My screenshot shows the delete button is moved to the right when hovering the menulist. The pro of this solution is, the button is not on the dropmarker position and is nearer to the address which makes it clearer for what it is.

What do you think about this?

If I understood it correctly, then this solution still suffers from the original problem: Moving/resizing button when hovered. I have never seen this in a UI.

Comment 27

[Wayne Mery (:wsmwk)]

xracoonx, you missed this part "this patch shows the delete button allways."

Richard, FWIW I like this last solution. (as much as dislike making the UI more busy)

Comment 28

[Jorg K (CEST = GMT+2)]

(In reply to Richard Marti (:Paenglab) from comment #25)

What do you think about this?

Maybe ;-) - I'd have to play with it.

Comment 29

[Richard Marti (:Paenglab)]

Attachment: 1493158-deleteAddress-on-right.patch

Okay, here you can play with it. :-)

Comment 30

[Jorg K (CEST = GMT+2)]

Comment on attachment 9041004 [details] [diff] [review]
1493158-deleteAddress-on-right.patch

Actually, I don't like it. I select To/CC/BCC on the right side of the field, close to where the actual address is. A little [x] popping up there is very annoying. It's far less annoying where it is now, on the left edge, far away from the action.

I'd return this whole bug to WONTFIX. We have the best of what we can do right now. One day we might reword the widget in Outlook style like you can already do with this add-on:
https://addons.thunderbird.net/en-GB/thunderbird/addon/mrc-compose/

Or you do a "touch-only" implementation.

Comment 31

[xracoonx]

(In reply to Wayne Mery (:wsmwk) from comment #27)

xracoonx, you missed this part "this patch shows the delete button allways."

I think I did not. That was in an earlier comment. The later one suggestion showing on hover just with another position.

"MRC Compose" seems like a nice extension. I guess personally I can live with using that instead of the (faulty) Thunderbird default.

Comment 32

[Thomas D. (:thomas8)]

I'll present a new proposal in my next comment.

I think we can't just ignore the UX problem pointed out by reporter of this bug and duplicates. They click on recipient type selector dropdown arrow (surely a legitimate click target!) and suddenly find their recipient deleted. Jörg's comment 30 actually confirms that problem: he doesn't want to end up deleting when clicking on the right side of recipient selector, which is same scenario as reporter's.

• ux-error-prevention: users should not end up deleting recipients when they only want to change the recipient type

• ux-discovery: our delete button isn't very easy nor intuitive to discover, as it only appears when hovering recipient type selector (which has no obvious logical relation to deleting recipient). Certain users might never change or touch the recipient type selector but they might still want to delete recipients efficiently.

I've adjusted the summary to describe the problem without favoring one specific solution.

Comment 33

[Thomas D. (:thomas8)]

Attachment: Proposal - Screenshot 01: Recipient type selector and delete button appear when recipient input box is hovered or focused

Here's my new proposal (Screenshot 1 out of 3).

Jörg and reporter are right, recpient delete button shouldn't appear out of nowhere from underneath when clicking recipient type selector, which is undiscoverable, unexpected, and error-prone.

As discussed in bug 1100103, we also don't want to clutter the entire recipient area with dozens of permanent delete buttons. In fact, even the permanent recipient type selectors are pretty noisy (over-salient) considering that users will typically use them maximally once per each recipient, and after changing the type, the dropdown then becomes irrelevant. There's absolutely no point of permanently having multiple dropdown markers for each recipient on screen.

This is 2019 and ux-minimalism has long been part of best practice on any type of application or online presentation. Users know (not least from their Android phones) that they have to touch (tap/hover/focus) any element on the screen first in order to get at contextual actions, and that non-contextual/inapplicable actions are typically hidden to avoid clutter.

PROPOSAL

So I suggest to radically simplify/de-clutter both the recipient type selectors and the delete buttons by making them contextual, i.e. showing them only and exactly when they are needed. Ironically, this actually makes both of them MORE discoverable.

1. show recipient type selector and delete button only when applicable

• when editing a recipient (this is a great way of assisting ux-discovery)
• when hovering / focusing any part of a recipient row (name/type/delete)

2. hide all recipient type selector stylings (dropdown arrow, border box) and delete button when they are not applicable (i.e. when recipient is neither being edited nor hovered nor focused).

Comment 34

[Thomas D. (:thomas8)]

Attachment: Proposal - Screenshot 02: Recipient type selector and delete button appear when either of them is hovered

Proposal - Screenshot 2 of 3

Obviously recipient type selector will re-materialize when hovered, and also when the delete button or recipient name is hovered. In fact, hovering any part of a recipient row will show those contextual actions.

Comment 35

[Thomas D. (:thomas8)]

Attachment: Proposal - Screenshot 03: All recipient type selector stylings and delete buttons hidden when not applicable

Proposal - Screenshot 3 of 3:

This is the nicest part: When you are done with recipient editing, e.g. when typing body text, all the operational clutter of recipient type selectors or delete buttons just elegantly disappears, leaving a clean and informative recipient area.

Comment 36

[Thomas D. (:thomas8)]

(In reply to Thomas D. (currently busy elsewhere) from comment #33)

Created attachment 9041093 [details]
PROPOSAL
So I suggest to radically simplify/de-clutter both the recipient type selectors and the delete buttons by making them contextual, i.e. showing them only and exactly when they are needed. Ironically, this actually makes both of them MORE discoverable.

1. show recipient type selector and delete button only when applicable

• when editing a recipient (this is a great way of assisting ux-discovery)

Note that both delete button and recipient type selector are visually de-emphasized when recipient input has focus:

• X and dropdown arrow more slim and lighter color
• dropdown box background color same as recipient area background color, i.e. only the border makes it stand out.

When hovering the delete button, the X buttonizes as it does now, and the recipient type selector should be shown but de-emphasized as in Screenshot 1, attachment 9041093 [details].

Comment 37

[Thomas D. (:thomas8)]

Feedback on my proposal as described in comment 33, comment 34, and comment 35 will be welcome.
Screenshot 1: attachment 9041093 [details]
Screenshot 2: attachment 9041094 [details]
Screenshot 3: attachment 9041095 [details]

Comment 38

[Richard Marti (:Paenglab)]

Comment on attachment 9040960 [details] [diff] [review]
1493158-fixed-deleteAddress.patch

Thomas, when you want to play with your proposal, take this patch as it moves the delete button in front of the menulist. Now you can do the the hiding when not active logic.

Comment 39

[Thomas D. (:thomas8)]

(In reply to Richard Marti (:Paenglab) from comment #38)

Comment on attachment 9040960 [details] [diff] [review]
1493158-fixed-deleteAddress.patch

Thomas, when you want to play with your proposal, take this patch as it
moves the delete button in front of the menulist. Now you can do the the
hiding when not active logic.

Thanks. Unfortunately, I don't have time for playing with patches atm and it's unlikely to change soon. I was hoping it could be realized mostly using CSS on which you're the expert...
The screenshots were mockups produced with MS Paint.

Comment 40

[Richard Marti (:Paenglab)]

Unfortunately CSS can't style things which depends on subsequent siblings. I'd need a selector if the row is active, then it would work.

Comment 41

[Jorg K (CEST = GMT+2)]

I like Thomas' idea.

"Focused" isn't enough for "active"? So which element needs to be marked active? The richlistitem, which contains the delete button, the To/Cc/Bcc and the address?

Comment 42

[Richard Marti (:Paenglab)]

(In reply to Jorg K (GMT+1) from comment #41)

I like Thomas' idea.

"Focused" isn't enough for "active"? So which element needs to be marked active? The richlistitem, which contains the delete button, the To/Cc/Bcc and the address?

I need the "active" attribute, or every attribute name you want, on the richlistitem (.addressingWidgetItem) when the aw-menulist or the textbox-addressingWidget has the "focused" attribute. When hovering the whole richlistitem to show the delete button and the menulist it's enough when I use the .addressingWidgetItem:hover selector.

Comment 43

[Thomas D. (:thomas8)]

Attachment: Patch V. 1: Recipient delete button and type selector combo "on demand"

Here's a proof of concept / WIP patch which realizes my proposal of comment 33 ff, much like in the screenshots 1-3 of attachment 9041093 [details] ff.

Please ignore bug 1525828 of duplicate type selector (menulist), which is not caused by my patch.

Otherwise this works very well for me.
:focus-within works perfectly to mimic not-yet existing parent or previous sibling selector, pure CSS without any javascript workarounds.
(One would wish for :hover-within which would allow us to style the entire recipient row somehow when the delete button is hovered...)

1. delete button and type selector dropdown styling only shown when recipient or any part of the recipient row is hovered or has focus.
2. Otherwise both hidden which does a great job to declutter the entire recipient area from dozens of useless type selector dropdowns.
3. aw-menulist has finally returned to a "normal" dropdown styling with white background: feels much lighter, less awkward, consistent with the "From" dropdown, and more like an actual editable windows-style dropdown. Editable? Yes, you can actually type "BCC" when the dropdown has focus and it'll work if your typing speed is fast enough.

WIP:

• No guarantees for selectors to be in the right file or in the right sections - essentially I tried to make it work for Windows 10 but there seem to be dozens of scattered files, sections and rules which define this. Richard will be able to look into the details...
• Linux / OSX styles not yet included.
• Richard, could you make the recipient type selector to have same height as recipient input, so that the border boxes will match, which looks neater.

If Paenglab agrees, I'd like to take this bug if my proposal is accepted, assuming that we'll be done here with few iterations. Btw, does HG accept two patch authors for one patch?

Comment 44

[Jorg K (CEST = GMT+2)]

Comment on attachment 9042686 [details] [diff] [review]
Patch V. 1: Recipient delete button and type selector combo "on demand"

Works for me. Even better with the patch from bug 1525828 applied.

Comment 45

[Thomas D. (:thomas8)]

Btw, do we still need this? Do we still have a tree here? Or maybe this does nothing...

            <treecols hidden="true">
              <treecol id="firstcol-addressingWidget" style="width: 18px;"/>
              <treecol id="typecol-addressingWidget" style="&headersSpace.style;"/>
              <treecol id="textcol-addressingWidget" flex="1"/>
            </treecols>

Comment 46

[Thomas D. (:thomas8)]

Nits:

• Recipient type selector dropdown arrow is a bit squeezed on the left, needs some px more padding.
• Delete button is too close to recipient type selector, again needs just a few px of distance.

Comment 47

[Thomas D. (:thomas8)]

Comment editing and Markdown styling are AWESOME :-))

Comment 49

[Richard Marti (:Paenglab)]

Attachment: 1493158_compDelRecipientInPlaceNEW.patch

Didn't knew the focus-within. Like this it's easy to do. Thanks, Thomas.

I changed the code a bit and added the needed code to Linux and Mac.

I'll let Jörg review, as it's not good when I review it when I also provide some code.

Comment 50

[Jorg K (CEST = GMT+2)]

Comment on attachment 9042825 [details] [diff] [review]
1493158_compDelRecipientInPlaceNEW.patch

This works as well as the first version I checked. I can't say much about the CSS, especially not for Linux and macOS.

Comment 51

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4831d30eb0f8
Declutter addressing widget: Hide recipient delete button & type selector when they are not relevant. r=Paenglab,jorgk

Comment 52

[Thomas D. (:thomas8)]

Thanks xracoonx (reporter) and the reporters of duplicates for raising this usability issue, which has been fixed now (see comment 43), which also includes making the delete button available on touch devices which don't have hover event (bug 1504511).

Thanks everyone, nice teamwork from wontfix to smart fix.

FTR: My original patch attachment 9042686 [details] [diff] [review] also made the aw-menu box styling much lighter and blend in even more with the flat styling of the header brackground, but unfortunately that change got lost. Imho that should be tried again in a followup bug which should also normalize the design of paragraph format and font selector.

Comment 56

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #43)

Created attachment 9042686 [details] [diff] [review] ...
:focus-within works perfectly to mimic not-yet existing parent or previous sibling selector, pure CSS without any javascript workarounds.
(One would wish for :hover-within which would allow us to style the entire recipient row somehow when the delete button is hovered...)

For applying styles (e.g. red border/shading) on entire recipient row when delete button is hovered, maybe something like this:
https://css-tricks.com/hover-on-everything-but/

Comment 57

[Thomas D. (:thomas8)]

Adding search words to summary.