Closed Bug 1493158 Opened 1 year ago Closed 1 year ago

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

Categories

(Thunderbird :: Message Compose Window, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 67.0

People

(Reporter: xracoonx, Assigned: bugzilla2007)

References

(Depends on 1 open bug)

Details

(Keywords: ux-discovery, ux-error-prevention, ux-minimalism)

Attachments

(4 files, 4 obsolete files)

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.
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.
I don't recal
Component: Mail Window Front End → Message Compose Window
(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
Severity: normal → minor
Status: UNCONFIRMED → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
See Also: → 1100103
(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
(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
(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.
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?
Flags: needinfo?(richard.marti)
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.
Flags: needinfo?(richard.marti)
Should we do that? Thomas, what do you think?
Flags: needinfo?(bugzilla2007)
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.
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.
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.
(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.
See Also: → 1504511
(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.
Flags: needinfo?(bugzilla2007)
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?
(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.
Duplicate of this bug: 1510395
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.
(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.

(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

Flags: needinfo?(richard.marti)
Duplicate of this bug: 1522121

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"?

Assignee: nobody → richard.marti
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(richard.marti)
Attachment #9040960 - Flags: review?(jorgk)
Resolution: WONTFIX → ---
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?
Attachment #9040960 - Flags: ui-review?(mkmelin+mozilla)
Attachment #9040960 - Flags: ui-review?(acelists)
Attachment #9040960 - Flags: review?(jorgk)

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

Attached image close-on-right.png (obsolete) —

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

Attachment #9040960 - Attachment is obsolete: true
Attachment #9040960 - Flags: ui-review?(mkmelin+mozilla)
Attachment #9040960 - Flags: ui-review?(acelists)
Attachment #9040999 - Flags: feedback?(jorgk)

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

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)

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

What do you think about this?

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

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

Attachment #9041004 - Flags: review?(jorgk)
Attachment #9040999 - Flags: feedback?(jorgk)
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.
Attachment #9041004 - Flags: review?(jorgk)

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

Severity: minor → normal
Summary: To/Cc/Bcc selector delete button should always show → When fast-clicking To/Cc/Bcc selector dropdown arrow, easy to accidentally delete recipient because delete button unexpectedly appears

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.

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)
  1. 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).
Attachment #9041093 - Attachment description: 1493158_screenshot01 recipient hover-focus.png → Proposal - Screenshot 01: Recipient type selector and delete button appear when recipient input box is hovered or focused

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.

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.

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

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]

Keywords: ux-minimalism
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.
Attachment #9040960 - Attachment is obsolete: false
Attachment #9041004 - Attachment is obsolete: true
Attachment #9040999 - Attachment is obsolete: true

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

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.

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?

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

Status: REOPENED → NEW

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?

Attachment #9040960 - Attachment is obsolete: true
Attachment #9042686 - Flags: feedback?(richard.marti)
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.
Attachment #9042686 - Flags: feedback+

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>

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 editing and Markdown styling are AWESOME :-))

Duplicate of this bug: 1526545

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.

Attachment #9042686 - Attachment is obsolete: true
Attachment #9042686 - Flags: feedback?(richard.marti)
Attachment #9042825 - Flags: ui-review+
Attachment #9042825 - Flags: review?(jorgk)
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.
Attachment #9042825 - Flags: review?(jorgk) → review+

Pushed by mozilla@jorgk.com:
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

Status: NEW → RESOLVED
Closed: 1 year ago1 year ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 67.0
Blocks: 1504511
See Also: 1504511

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.

Assignee: richard.marti → bugzilla2007
Depends on: 1527547
Duplicate of this bug: 1531036
Duplicate of this bug: 1531375
Depends on: 1540386
Duplicate of this bug: 1564067

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

Adding search words to summary.

Summary: When fast-clicking To/Cc/Bcc selector dropdown arrow, easy to accidentally delete recipient because delete button unexpectedly appears → When fast-clicking To/Cc/Bcc recipient type selector dropdown arrow, easy to accidentally remove recipient because delete button unexpectedly appears
You need to log in before you can comment on or make changes to this bug.