735658 - Improve appearance and discoverability of the status selector of the chat toolbar

Status: RESOLVED FIXED

(Thunderbird :: Instant Messaging, defect)

Description

[Florian Quèze [:florian]]

Its not easy enough to discover how to use it.

I think we need:
- a down arrow next to the icon, so that users can discover that there's a dropdown menu popup there.
- a background on the status text area, so that it's easy to discover that this part isn't the label of the button on the left. I think just marking that area a little bit darker than the rest of the toolbar would do, so I would try a black but mostly transparent background.
- some padding/margin fixes so that clicking in the textbox to start editing the status doesn't change the size of the status selector.

Comment 1

[Florian Quèze [:florian]]

I also think that we should replace the spacer between "Join Chat" and the status selector by a separator, that would look better. Not sure if Blake agrees :).

Comment 2

[Florian Quèze [:florian]]

We should also disable this status selector when no account is configured.
This means we need to:
- give the status selector a different appearance when no account is configured (gray text + gray icon?)
- prevent the mouse cursors from changing when hovering the disabled status selector
- make the onclick handlers do nothing when the status selector is disabled

Comment 3

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I don't know how this behaves when there is an account (I can't add one), but if the textbox stays empty until you set a specific status message, I think you should add an emptytext so that its more obvious what the textbox does.

Comment 4

[Florian Quèze [:florian]]

(In reply to Philipp Kewisch [:Fallen] from comment #3)
> I don't know how this behaves when there is an account (I can't add one),
> but if the textbox stays empty until you set a specific status message, I
> think you should add an emptytext so that its more obvious what the textbox
> does.

When no status message is set, the textbox contains by default the string representation of the status type icon ("Available", "Unavailable", "Offline")

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

(In reply to Florian Quèze from comment #4)
> When no status message is set, the textbox contains by default the string
> representation of the status type icon ("Available", "Unavailable",
> "Offline")

For me the textbox remained empty. I'll make a screenshot when I get back to the windows machine. Maybe related to all the acount-cannot-be-created badness I was having there.

Comment 6

[Andreas Nilsson (:andreasn)]

Attachment: mockup

something like this?

Comment 7

[Andreas Nilsson (:andreasn)]

also, would it be odd to always show the text part as a text field?

Comment 8

[Florian Quèze [:florian]]

(In reply to Andreas Nilsson (:andreasn) from comment #7)
> also, would it be odd to always show the text part as a text field?

I'm not sure. Currently when it's displayed as a text field, the displayed value is only local, and when it's not a text field, the value matches what contacts see.

Comment 9

[Thomas D. (:thomas8)]

(In reply to Andreas Nilsson (:andreasn) from comment #6)
> Created attachment 617944 [details]
> mockup
> something like this?

Andreas, that looks great, a lot more discoverable and less confusing than what we have!
I like the clear separation of the dropdown button and the status text field.
The text should not technically be part of the button, because it makes the text jump around when you click the button, falsely creating the impression that it's part of the button and you can click the text to press the button.

(In reply to Philipp Kewisch [:Fallen] from comment #5)
> (In reply to Florian Quèze from comment #4)
> > When no status message is set, the textbox contains by default the string
> > representation of the status type icon ("Available", "Unavailable",
> > "Offline")
> For me the textbox remained empty.

I see this, too, temporarily after switching status.
- without customized status text
- toggle status from available to unavailable
Actual: -> status text turns blank waiting for user input, then after some seconds, defaults to "Unavailable"
Expected: -> status text should show default text "Unavailable" as highlighted emptytext while waiting for user input

iow, the status text should never be empty, even while editing, unless user deletes or overwrites it.

Comment 10

[Thomas D. (:thomas8)]

Another issue:

While editing the status text, clicking *anywhere* outside the status text field should exit editing mode and accept the current text. It's confusing that currently clicking on an online contact in left pane will exit status editing, but clicking on most other spots will not (e.g. huge grey background of right pane when nothing is displayed).

Comment 11

[Florian Quèze [:florian]]

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

> (In reply to Philipp Kewisch [:Fallen] from comment #5)
> > (In reply to Florian Quèze from comment #4)
> > > When no status message is set, the textbox contains by default the string
> > > representation of the status type icon ("Available", "Unavailable",
> > > "Offline")
> > For me the textbox remained empty.
> 
> I see this, too, temporarily after switching status.
> - without customized status text
> - toggle status from available to unavailable
> Actual: -> status text turns blank waiting for user input, then after some
> seconds, defaults to "Unavailable"
> Expected: -> status text should show default text "Unavailable" as
> highlighted emptytext while waiting for user input

This is the expected behavior, to give the user an opportunity to edit the status text before the new status type is sent, to avoid sending 2 status changes in a row. If this is what Philipp was talking about, then I misunderstood his comment.

Comment 12

[Thomas D. (:thomas8)]

(In reply to Florian Quèze from comment #11)
> > Actual: -> status text turns blank waiting for user input, then after some
> > seconds, defaults to "Unavailable"
> > Expected: -> status text should show default text "Unavailable" as
> > highlighted emptytext while waiting for user input
>
> This is the expected behavior, to give the user an opportunity to edit the
> status text before the new status type is sent, to avoid sending 2 status
> changes in a row. If this is what Philipp was talking about, then I
> misunderstood his comment.

Well, no, but perhaps there's more misunderstanding. According to your own comment 8:
> when it's displayed as a text field, the displayed value is only local,
> and when it's not a text field, the value matches what contacts see.

What I asked for is this:

STR
- Do not define a custom status text
- Your status (and status text) is "Available"
- Click on status dropdown button and change your status to "Unavailable"

Actual result
- Status text suddenly disappears, and user starts with an empty text input
- After about 10 seconds, if you don't change anything, status text input reverts to "Unvailable"

Expected result
- Instead of presenting an empty text input field, pre-populate the input with the new default status text (as we do for custom status text! - ux-consistency):
Show the text input with the following highlighted text: "Unavailable"
- according to comment 8, since we are in editing mode, this will not yet send a status text change yet as we're just editing the string locally
- If user does nothing, status text remains "Unavailable" and will be auto-applied after the waiting time (as we do now, but more transparently and elegantly after this proposed improvement)
- If user wants to customize the status text, he can just start typing to overwrite the suggested default "Unavailable" (and the emptytext will give a good hint what kind of status text makes sense for the (new) current status) - no extra clicks compared to status quo, just benefits only.

For the same reasons, we should also show the default status text as highlighted emptytext suggestion (Available/Unavaible/Offline) when user just clicks to edit the current default status text directly without a custom status text defined.
Thus the behaviour would be consistent with custom status text editing, where we also suggest the current status text.

Comment 13

[Florian Quèze [:florian]]

(In reply to Thomas D. from comment #12)
"Unavailable" isn't a default status text, as I said in comment 4 (although the word 'textbox' could be a bit misleading in that comment).

Comment 14

[Mike Conley (:mconley) (:⚙️)]

Attachment: WIP patch 1

Comment 15

[Richard Marti (:Paenglab)]

Attachment: WIP patch 2

WIP patch for Windows like on IRC discussed. Some changes are in common CSS file and could fit also on Linux and OSX but not tested.

Comment 16

[Richard Marti (:Paenglab)]

Attachment: screenshot of WIP patch 2 with hovering the button on the left

Comment 17

[Mike Conley (:mconley) (:⚙️)]

(In reply to Richard Marti [:paenglab] from comment #16)
> Created attachment 643537 [details]
> screenshot of WIP patch 2 with hovering the button on the left

Paenglab:

This looks *awesome*, thanks so much!

A few requests:

1) Can the status message input be snugged up against the status indicator dropdown?
2) Can the status indicator dropdown button also have a border around it when the chat-status-selector is hovered?
3) When the status message input is editable (but not selected), the text is offset by 1 pixel in comparison to when it is not editable.  Can this offset be eliminated?

Let me know. Thanks so much!

-Mike

Comment 18

[Richard Marti (:Paenglab)]

Attachment: WIP patch 3

Now tested on all systems.

(In reply to Mike Conley (:mconley) from comment #17)
> A few requests:
> 
> 1) Can the status message input be snugged up against the status indicator
> dropdown?

Done, is it what you thought?

> 2) Can the status indicator dropdown button also have a border around it
> when the chat-status-selector is hovered?

I see no working solution except for Win7 with the self- styled buttons. On XP and Linux TB uses system buttons and I see no solution how to inform to use the hovered button. OSX has no hovered style.

I also don't see a solution with putting the textarea into the button. With only left-margin:... the whole button would be wider and the textarea is still in the button. I tried also with position: relative but the textarea jumped back on hover. I think also, if it works, this would disconnect the textarea to hover the button.
Maybe someone has a solution.

> 3) When the status message input is editable (but not selected), the text is
> offset by 1 pixel in comparison to when it is not editable.  Can this offset
> be eliminated?

Fixed

Comment 19

[Florian Quèze [:florian]]

At least on Mac, the label tag has several pixels of margin around it. Shouldn't we hide the empty label of the toolbarbutton to have the dropmarker closer to the icon?
Something like:
#statusTypeIcon > .toolbarbutton-text {
  display: none;
}

We may also want to reduce a bit the space between the dropmarker and the #statusMessage label.

By the way, thanks for working on this, applying your patch is already a great improvement! :)

Comment 20

[Richard Marti (:Paenglab)]

Attachment: WIP patch 4

Implemented Florian's proposal. I also added a rule to show the status icon also in text only mode.

Comment 21

[Mike Conley (:mconley) (:⚙️)]

(In reply to Richard Marti [:paenglab] from comment #20)
> Created attachment 644388 [details] [diff] [review]
> WIP patch 4
> 
> Implemented Florian's proposal. I also added a rule to show the status icon
> also in text only mode.

Cool - is this ready for review?

Comment 22

[Richard Marti (:Paenglab)]

Attachment: patch

(In reply to Mike Conley (:mconley) from comment #21)
> Cool - is this ready for review?

If you think it's complete, I'll ask for review.

Comment 23

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 644445 [details] [diff] [review]
patch

Looks good on Mac.  I think there's still some polishing that needs to be done (like not forcing the user to type stuff in when they set their status to Available/Unavailable), but the new style (on Mac) gets a big thumbs up from me.

ui-r=me!

(I'll be checking it on Windows as soon as I can, but Mike should feel free to start the review while I'm doing that.)

Thanks,
Blake.

Comment 24

[Blake Winton (:bwinton) (:☕️)]

(And for the record, I like how it looks in Aero, too.  :)

Comment 25

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 644445 [details] [diff] [review]
patch

I like it. Thanks Paenglab!

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/comm-central/rev/3b29e269e62e

Comment 27

[Blake Winton (:bwinton) (:☕️)]

Comment on attachment 644445 [details] [diff] [review]
patch

This seems like something we want for the initial IM release.

Comment 28

[Mike Conley (:mconley) (:⚙️)]

comm-aurora: https://bugzilla.mozilla.org/show_bug.cgi?id=735658
comm-beta: https://hg.mozilla.org/releases/comm-beta/rev/684391101117