615315 - Add a small close button to all doorhanger notifications

Status: VERIFIED FIXED

(Toolkit :: General, defect)

Description

[Alex Faaborg [:faaborg] (Firefox UX)]

A lot of feedback is coming in that users don't like that they are being forced to select the action button in notification doorhangers.  While these are click outside to indicate "not now," some users don't seem to be picking that up fast enough.  We are still looking into a few additional ways to make these notifications feel ephemeral (more transparent, fade in animation, fade and scale dismissal animation).  However, even with those changes we may not be able to overcome the strong user expectation of forced choice modal dialog boxes.  This is unfortunate, because modal forced choice interfaces treat users like they are a function that returns a bool.  They block the user's cognitive flow and don't support undo.  Also, as we are leaning from our tab modal prompts, if the user thinks that something is modal and foced choice, they end up treating it that way (even if it isn't).  So simply making something non-modal doesn't actually by itself solve the problem.

Nonetheless, it looks like we will need to introduce close buttons to mitigate initial confusion.

The cost of this is that users may end up treating the interface as modal forced choice (even though it is in reality non-modal and ignorable).

Unfortunately the introduction of a close button also very significantly reduces the efficiency of interacting with these dialogs, since users may now feel compelled to mouse across the entire screen to hit a small target (when all they otherwise had to do is ignore the message).

However, since some of these dialogs are asking for privacy sensitive information (passwords, user's physical location), there may be a few times when users want to very intentionally and specifically indicate "not now," even if it means extra mouse movement and more precise targeting.

Comment 1

[Alex Faaborg [:faaborg] (Firefox UX)]

From discussion in the UX meeting, we are going to hold off on this change and move forward with bug 615318 to see if that causes a change with the feedback we are receiving (also, users will have had a little bit of time to adjust to the change).

Comment 2

[Dave Garrett]

If the goal is to train users to understand the "click outside to ignore" concept, which is quite alien to most people, we're still going to need a close button. One idea might be to have a "Just click outside to close and ignore this" tooltip for a simple 'x' close button and force the tooltip to show immediately instead after a delay to make sure those who would use it will see the message and instead learn that they don't need to click the 'x'.

Comment 3

[Alex Faaborg [:faaborg] (Firefox UX)]

We'll probably end up looking at the feedback and taking the conservative approach to have both.

But I want us to try the split menu approach over in bug 615318 first (as well as giving our beta users some more time) to see what happens.  Designing for the first run is important, but at some point it's more worthwhile to consider every future interaction with the interface, even if users start from an initial position of total confusion.

Comment 4

[Dave Garrett]

(In reply to comment #3)
> But I want us to try the split menu approach over in bug 615318 first (as well
> as giving our beta users some more time) to see what happens.

Well, beta testers are not representative of the larger user base, unfortunately. The least technically skilled beta tester is probably more computer savvy then the vast bulk of normal stable version users. (most people don't know what a beta is) We'll only truly understand the scope of how the "average user" interacts with this after the final version is released. (which is annoying, but true)

> consider every future interaction with the interface, even if users start
> from an initial position of total confusion.

If you make the close button just a very simple faint 'x' in the lower right corner, then it would be something useful to train new users but easily out of the way for future users who don't need it.

One other point I'd like to make: some people don't learn. Not just the cliché "my grandparent" example, but there are plenty of people who just have no desire to learn anything new when they use the computer and will in fact get mad at you for trying to teach them. I'm sure SUMO will have its share of complaints and confusion no matter what is done here. I think the best we can hope for is something that has both what people are used to and the new route together in a way that makes an attempt to teach, but doesn't rely on it.

Comment 5

[Ian Pottinger]

If this option is eventually implemented, it might be better to have the stop button fade into view only when the mouse is within the doorhanger. That way if someone has already made the effort to mouse over the doorhanger looking for a way to close it then they will be presented with a means to do so. 

Hopefully the lack of a visible close button will encourage the desired behaviour of just ignoring the doorhanger altogether.

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

I'm pretty sure that I've encountered enough confusion to warrant adding this close control, even though it's unfortunate that users who mouse all the way to this small target won't pick up the efficiency win of clicking outside to close.  In addition to the feedback coming in, today I also ran into someone at Mozilla who thought they had to click the action button.  I'm ready to declare the (forced) streamlined interaction to be idealistic.  Nominating for blocking.

Comment 7

[:Margaret Leibovic]

I can update my patch from bug 613563 to do this.

Comment 8

[:Margaret Leibovic]

Attachment: patch

This adds a close button to popup notifications. I didn't add gnomestripe changes because until bug 604257 is fixed, it's hard to tell how the close button should be aligned in the panel (and the alignment seems to be decent as is right now).

Alex, the bug summary also talks about adding close buttons to panels. I don't know if we can/should add the close buttons to the arrow panel widget, since that seems to make too broad an impact. We could add the close button to the content of other panels in the browser, but it seems unnecessary for the panels appear as the direct result of a user action, such as the identity and bookmark star panels. In either case, adding close buttons to panels would make this patch more complicated, so it might be best to push that work to another bug for the sake of landing this.

Comment 9

[:Gavin Sharp [email: [e-mail]]]

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

Looks good, couple of minor things:
-test can use synthesizeMouseAtCenter
-need to also update addon-progress-notification's <content>

Comment 10

[:Margaret Leibovic]

Attachment: patch v2

Comment 11

[Alex Faaborg [:faaborg] (Firefox UX)]

>Alex, the bug summary also talks about adding close buttons to panels. I don't
>know if we can/should add the close buttons to the arrow panel widget, since
>that seems to make too broad an impact. We could add the close button to the
>content of other panels in the browser, but it seems unnecessary for the panels
>appear as the direct result of a user action, such as the identity and bookmark
>star panels. In either case, adding close buttons to panels would make this
>patch more complicated, so it might be best to push that work to another bug
>for the sake of landing this.

Yeah, we need to make the interaction consistent (our occasional lack of consistency due to when we land certain things was brought up as a concern at the last monday Firefox team meeting).  I don't really care if we split it into a separate patch, just that we eventually have the same behavior across all arrow panels.

Comment 12

[:Margaret Leibovic]

http://hg.mozilla.org/mozilla-central/rev/bdadb18a5adf

I filed bug 625626 as a follow-up for other arrow panels.

Comment 13

[[e-mail]]

(From update of attachment 503598 [details] [diff] [review])
[pack="start" is the default]

Comment 15

[Steve Scott (pxbugz)]

Verified fixed on Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre