swalling wrote:

Just to reiterate Munaf's request: we'd love to build on this standard and use it to incorporate some features that A/B testing has shown to be useful. The proposed changes Munaf suggested should help make this something that not only we can use, but other Wikimedians and third party users.

#1 has no business being done at a per-notification level.

The notification area is done entirely with css so you can do your testing of other positions simply by adding some extra css.

1. Position

I agree with Daniel, changing position of the queue is definitely not something that should be part of the notifications framework. The last thing we want is different scripts popping up messages all over the screen attacking the user from all sides ;-)

2. Closing

Yes and no. I think having a close button appear on-hover is good. Many systems I know do this as well (Growl, Notification Center, Twitter apps). However they may still close regardless of where one clicks. When the message is an alert[1] (as opposed to a banner[1]), in that case the message only closes when clicking on Cancel (or Dismiss, whatever button there may be). Otherwise it depends on what the source of the message has configured on the message-click callback (if it calls this.close() then it hides no matter where the click is), but notifications from Mail often bring the Mail application to the front etc. that action is configurable.

3. Icons

Yes, see also:
http://lists.wikimedia.org/pipermail/wikitech-l/2012-September/063219.html

[1] Banner is a message with autoHide and only text. Alert is a message that doesn't autoHide and typically has two clickable buttons waiting for user response.

massaf wrote:

Should've been clearer about positioning: the top right position might not be the correct one, so we should test out others before standardizing. The goal isn't to provide flexibility forever; just something we can use experimentally until we standardize. You're right that we shouldn't productize that immediately. We can inject our own CSS until then, as long as everyone is OK with the productized-default changing based on future data and design consensus.

As for closing on click: yes, it depends on the context in some other apps. I don't think we should--or need to--follow that model because it requires learning and guesswork on the part of the user with little to no improvement on visual design. Users will learn the feature without confusion if we consistently use our affordances. I don't think I see issues with an affordance appearing on hover, as long as it's present.

Can you cite some clear precedents or design patterns to explain why you said message type icons are bad for notifications?

Munaf

(In reply to comment #4)

As for closing on click: yes, it depends on the context in some other apps. I
don't think we should--or need to--follow that model because it requires
learning and guesswork on the part of the user with little to no improvement on
visual design. Users will learn the feature without confusion if we
consistently use our affordances. I don't think I see issues with an affordance
appearing on hover, as long as it's present.

I think using auto-hide for these kinds of notifications makes for poor site accessibility. There's a lot of text and it's difficult to read it all quickly. The current message displays for five seconds and contains the following text:

The page "Main Page" has been added to your [watchlist]. Future changes to this page and its associated talk page will be listed there, and the page will appear bolded in the [list of recent changes] to make it easier to pick out.

Imagine that a new user, just having registered an account, clicks the star icon. He or she is expected to read (and understand) all of this in five seconds before the message disappears? Plus there are two links in there. But pretty soon the message has disappeared; who knows, you may have been reading another window or tab (bug 40322). This is kind of nasty behavior, in my opinion.

I think the hover trick (where putting your cursor over a message will cause the message to not auto-hide) is non-obvious. Admittedly Microsoft Outlook does something similar with e-mail inbox message previews.

And not everybody has a hover state these days. Are cursor-less users just expected to read everything very quickly?

Maybe it makes sense to not auto-hide for new users only. Or maybe auto-hide isn't as evil as it seems. I think this needs more thought.

(In reply to comment #5)

I think using auto-hide for these kinds of notifications makes for poor site
accessibility. There's a lot of text and it's difficult to read it all quickly.
The current message displays for five seconds and contains the following text:

It depends on the message. For one, that message contains way too much crap. We have a tendency to cover our complicated interface by bombarding the user with loads of text.

A confirmation of an asynchronous event (adding page to watchlist) is in my opinion not the place to explain how it all works and elaborately explain which wire to cut in the event of facing a bomb.

So for the watchlist confirmation a simple hiding is probably OK.

Having said that, there is two other types of messages for the user:

• Messages that have a home:
• Got a new e-mail, preview shown. Clicking opens up the e-mail. Message auto-hides. Users knows where to find e-mails later if they missed the message, clicked too late, or want to check later (e.g. they might have left their screen open and went to the loo, they'll catch up on e-mail later by going to the inbox manually).

• Messages that don't have a home:
• All messages should have a home, but for those that don't yet. If they are important, they should probably not auto-hide. Examples are messages that require user interaction (e.g. clicking one of two buttons). Those would appear until the user either takes or dismisses the call for action.

swalling wrote:

I think using auto-hide for these kinds of notifications makes for poor site
accessibility. There's a lot of text and it's difficult to read it all quickly.
The current message displays for five seconds and contains the following text:

---

The page "Main Page" has been added to your [watchlist]. Future changes to this
page and its associated talk page will be listed there, and the page will

appear bolded in the [list of recent changes] to make it easier to pick out.

Imagine that a new user, just having registered an account, clicks the star
icon. He or she is expected to read (and understand) all of this in five
seconds before the message disappears? Plus there are two links in there. But
pretty soon the message has disappeared; who knows, you may have been reading
another window or tab (bug 40322). This is kind of nasty behavior, in my
opinion.

I think the hover trick (where putting your cursor over a message will cause
the message to not auto-hide) is non-obvious. Admittedly Microsoft Outlook does
something similar with e-mail inbox message previews.

And not everybody has a hover state these days. Are cursor-less users just
expected to read everything very quickly?

Maybe it makes sense to not auto-hide for new users only. Or maybe auto-hide
isn't as evil as it seems. I think this needs more thought.

I don't think we should necessarily optimize for so much text. I think you can basically cut it all down to "The page "Main Page" has been added to your [watchlist]." as long as you have the link.

I think auto-hide is just courtesy for certain kinds of messages, especially confirmation messages. You see this pattern all over. For other kinds of notification, such as things where a response is expected of you and/or it does not cover elements of the page, it's not. I think the hover state is a good idea. Placing a cursor on an element and/or clicking it is obviously indicative of "grabbing" it, and as such is expected behavior.

mr.heat wrote:

I have a strong opinion about the close functionality. The problem is: The current "Your edit was saved." popup goes away very fast. This is good. But it's almost impossible to hit the small "x" in such a short time. Because of these two conditions the "x" is misleading.

In some cases (not for the "Your edit was saved." popup but maybe in other cases) it's possible to remove the first condition. Let's assume a popup stays on screen. In this case I have plenty of time to hit the "x". I may want to select and copy the message first. It should not go away when I start to select the text.

The "Your edit was saved." popup needs to close very fast. Because of this the second condition needs to be changed: Enlarge the onclick area. Either make it possible to click the whole popup or use a big square around the "x".

+---------+-------+

+---------+-------+

  |       |
  +---+---+
      |
onclick area

The "x" may stay as a hint that the user can click the popup to make it go away.

(In reply to comment #8)

The "Your edit was saved." popup [..]

The "Your edit was saved." message is generated by the PostEdit extension. It does not use any core features and is custom-made. Whatever it does is in no way related to this bug.

mr.heat wrote:

(In reply to comment #9)

The "Your edit was saved." message is generated by the PostEdit extension.

I was using that as an example. What I said applies to all kinds of notifications.

I think the PostEdit notification is a good example to emulate. If you make it float (position:fixed) and make it pop-out from the background a bit more, that will solve 90% of the usability issues, IMO.

We have achieved a quick consensus among experienced contributors at Wiktionary that we would like to be able to turn that "Your edit was saved" notification off. I don't know what other kind of notifications you intend, whether we are part of some A/B test, or what, but it is annoying. Similarly the little moving icon that is just like the "floaters" that folks with macular degeneration experience. Both are annoying and distracting, but the "floater" reminds me that I am genetically predisposed to macular degeneration, so it is positively depressing to me. I'd like to turn that off too.

(In reply to comment #12)

We have achieved a quick consensus among experienced contributors at
Wiktionary
that we would like to be able to turn that "Your edit was saved" notification
off. I don't know what other kind of notifications you intend, whether we are
part of some A/B test, or what, but it is annoying. Similarly the little
moving
icon that is just like the "floaters" that folks with macular degeneration
experience. Both are annoying and distracting, but the "floater" reminds me
that I am genetically predisposed to macular degeneration, so it is
positively
depressing to me. I'd like to turn that off too.

Please open a bug in the Site Requests component (under the Wikimedia product). You'll need to specify which Wiktionary and provide a link showing consensus.

You can also disable the feature by adding a single CSS rule, as explained here: https://www.mediawiki.org/wiki/Extension:PostEdit#Disabling

Adding it to MediaWiki:Common.css would effectively disable the feature for all users, though before doing that, I'd appreciate it if you consider disabling it on a per-user basis instead, by adding it to the user CSS.

I now know how those who follow our Grease Pit can turn it off. Eventually it will be a gadget.

What's the evidence that it is good for new users, unregistered users, etc?

For the record, PostEdit doesn't even use mw.notification to do it's notifications. So talking about it on this bug is EXTREMELY off topic.

I see your point. But the negative reaction to the postedit notice seems to be relevant by analogy to what you ARE discussing.

(In reply to comment #16)

For the record, PostEdit doesn't even use mw.notification to do it's
notifications. So talking about it on this bug is EXTREMELY off topic.

I suppose. I've filed bug 50642 about this issue (the discrepancy in post-edit notifications) on Wikimedia wikis.

Wondering if this ticket should be moved to the "Echo" component nowadays?

No, mw.notification is in core.

• Bug 70548 has been marked as a duplicate of this bug. ***

In T42307#448917, @Krinkle wrote:

2. Closing

Yes and no. I think having a close button appear on-hover is good. Many systems I know do this as well (Growl, Notification Center, Twitter apps). However they may still close regardless of where one clicks. When the message is an alert[1] (as opposed to a banner[1]), in that case the message only closes when clicking on Cancel (or Dismiss, whatever button there may be). Otherwise it depends on what the source of the message has configured on the message-click callback (if it calls this.close() then it hides no matter where the click is), but notifications from Mail often bring the Mail application to the front etc. that action is configurable.

At the moment, the current Codex Message has 2 type of dismissability (refer to the Message's guidelines for more info):

1. With close button: in this case the close button is always visible instead showing it just when hover. The close button needs to be accessible for any user and from any device, since the hover will not work the same on mobile devices.
2. Auto-dismiss:the message will automatically disappear after 4 seconds.

I recommend to use any of these solutions and avoid using the close action just when hover.

Regarding the style of the message, it should follow one of the Notice, Success, Error, or Warning styles designed in Message component.

See also T303612: [EPIC] Toast: Add Toast component to Codex which is related.