Last modified: 2014-09-08 20:23:30 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T42307, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 40307 - mw.notification Usability Improvements
mw.notification Usability Improvements
Status: NEW
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: Future release
Assigned To: Nobody - You can work on this!
:
: 70548 (view as bug list)
Depends on: 40322
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-17 20:24 UTC by Munaf Assaf
Modified: 2014-09-08 20:23 UTC (History)
15 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Munaf Assaf 2012-09-17 20:24:28 UTC
The latest changes to mw.notification are here:

https://www.mediawiki.org/wiki/File:Mw-notification.ogv
https://gerrit.wikimedia.org/r/#/c/19199/


It's a step in the right direction; however, some changes would definitely improve usability, as well as consistency with other notifications that users are accustomed to [1][2]. E3 implemented a notification that addresses some of the concerns below [3] and measured positive results, but it's better to merge these ideas into the current mw.notification, which is more comprehensive. 

1. Positioning flexibility. Currently, the position might be obtrusive to the reader since the notification lays over the text. Adding some flexibility would let us test out different positions to measure which is least obtrusive to the reading experience while still being noticeable. 

2. Affordance improvement. Clicking an entire notification to close it is not a typical pattern for notifications; usually you click the entire message if it is actionable (e.g. it leads you to another screen). The entire message should only be clickable if it's actionable, otherwise there should be a dismissal affordance/icon visible to the user (http://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Agora_Icon_Set#Existing_icons). Plenty of examples of this out there; see [2].

3. Icon support. Icons improve the scan-ability of a notification and let you know where it's coming from, whether or not you can safely ignore it, or just give fast visual feedback to a user without forcing them to read a small message. They can be especially helpful for anyone with vision issues. Again, lots of precedents on this. See [1].

[1] http://dribbble.com/search?q=growl
[2] http://twitter.github.com/bootstrap/components.html#alerts
[3] http://www.mediawiki.org/wiki/Post-edit_feedback

-------------
Proposal: 

1. Make the position of the notification configurable. The definite desired positions are North ('N'), North East ('NE'), South East ('SE') and South West ('SW'), relative to the entire viewport. 

2. Remove the "click entire message to close" functionality and provide a "close icon" option.

3. Make the inclusion of a fixed-size icon configurable (defaults to false). 
-------------

Thoughts?

Cheers,
Munaf
Comment 1 Steven Walling 2012-09-17 20:33:57 UTC
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.
Comment 2 Daniel Friesen 2012-09-17 23:23:50 UTC
#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.
Comment 3 Krinkle 2012-09-17 23:55:45 UTC
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.
Comment 4 Munaf Assaf 2012-09-18 00:13:13 UTC
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
Comment 5 MZMcBride 2012-09-18 03:38:53 UTC
(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.
Comment 6 Krinkle 2012-09-18 04:04:36 UTC
(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.
Comment 7 Steven Walling 2012-09-18 04:09:00 UTC
> 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.
Comment 8 TMg 2012-10-19 23:10:08 UTC
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".

+---------+-------+
|         |       |
| Message |  [x]  |
|         |       |
+---------+-------+

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

The "x" may stay as a hint that the user can click the popup to make it go away.
Comment 9 Krinkle 2012-12-16 20:17:31 UTC
(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.
Comment 10 TMg 2012-12-18 01:05:11 UTC
(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.
Comment 11 Ryan Kaldari 2013-04-11 20:57:16 UTC
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.
Comment 12 Dennis C. During 2013-07-02 20:59:18 UTC
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.
Comment 13 Alex Monk 2013-07-02 21:02:50 UTC
(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.
Comment 14 Ori Livneh 2013-07-02 21:16:42 UTC
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.
Comment 15 Dennis C. During 2013-07-02 21:47:31 UTC
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?
Comment 16 Daniel Friesen 2013-07-02 22:14:59 UTC
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.
Comment 17 Dennis C. During 2013-07-02 22:51:53 UTC
I see your point. But the negative reaction to the postedit notice seems to be relevant by analogy to what you ARE discussing.
Comment 18 MZMcBride 2013-07-03 06:44:11 UTC
(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.
Comment 19 Andre Klapper 2014-08-14 14:23:31 UTC
Wondering if this ticket should be moved to the "Echo" component nowadays?
Comment 20 Alex Monk 2014-08-14 15:23:18 UTC
No, mw.notification is in core.
Comment 21 James Forrester 2014-09-08 20:23:30 UTC
*** Bug 70548 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links