Help:Notifications/New message indicator

New Message Indicator Screenshot - Selected Option F2

This is a discussion page for a new message indicator for notifications.

We are no longer asking for comments on this page. Instead, you are invited to join our discussion on the talk page.

Background

A new notifications tool was released on the English Wikipedia on April 30, 2013, to help better inform users of activity that affects them (related announcement). The introduction of this new notifications system included the removal of the orange notifications bar (often referred to as the "orange bar of doom/death" or OBOD). Many community members have sharply criticized the removal of the orange bar.

Concerns about the removal of the orange bar include:

• the suddenness of the removal of orange bar;
• the new message indicator is not prominent enough in the new version of the tool;
• that some users may not notice the red badge (which lights up next to your user name when you have new notifications); and
• the messages previously handled by OBOD (e.g. warnings) are more critical than others, and should not be mixed together in a way that does not emphasize their significance.

Many people asked that the orange bar be restored for registered users (note that the OBOD has already been restored for all logged-out or anonymous users). Many others expressed a preference for some of the solutions described below.

To address these concerns, we would like to deploy a temporary solution as soon as possible, based on your feedback. The purpose of this solution is to better inform people who might have missed the red badge that now lights up when you have new notifications. The idea is that this solution would only display an indicator for talkpage messages, and in that way make sure that notifications about talkpage messages don't get mixed up with everything else and missed.

Based on community and team feedback, we recommend that this new message indicator be:

• prominent: easy to see
• clear: disambiguate messages from other notifications
• persistent: stays on until you click -- or easy to find
• consistent: with best UI practices
• compatibility: with popular browsers and skins

(These criteria are further elucidated in this presentation.)

Resolution

From May 2 to May 9, 2013, community and foundation members engaged in extensive discussions about a wide range of solutions on our main Notifications talk page, on this special discussion page, on its secondary talk page and on a special IRC office hours chat. Together, we reviewed over a dozen different designs for message indicators, and discussed how each option could serve our goals (prominence, persistency, clarity, consistency and compatibility). To see all the designs we have considered so far, check out these slides.

After weeklong discussions of the various solutions, remaining participants resolved to develop a new solution combining the best of options E and F -- using the orange background from E and the navbar integration from F, as shown below (see this full screenshot).

In collaboration with community members including Edokter and Ignatz, WMF developer Ryan Kaldari and designer Vibha Bamba created a prototype gadget for Option F2 to bring together most desired features into a single solution. After testing that gadget and revising based on other community requests, we reached consensus that this would be a reasonable solution to integrate in the Echo extension -- which we aim to do next Tuesday, May 14, 2013, if feasible technically.

We think this solution meets all of our goals:

• it is prominent: the orange background makes it stand out on its own, and the animation further draws your eye to it;
• it is persistent: it shows up each time you load a page, and stays on until you click on it (or go to your talk page);
• it is clear: it differentiates messages from other notifications, and is combined with the 'Talk' link so you know what it's about;
• it is consistent: it integrates with the main nav bar and 'talk' link, and conforms with user interface guidelines and best practices;
• it is compatible: it seems to work on most popular browser platforms we tested, and we will further tweak for the most popular skins.

This new solution is now enabled as a JavaScript gadget by default for now, for final testing purposes. If you would like to turn it off, simply go to Preferences > Gadgets and scroll down to the "Appearances" section, then uncheck 'Alert me when I receive messages on my talk page. (new)'. Next week, we plan to make it part of the Echo extension and offer a preference for it as well, as described in this feature requirement.

We hope that this temporary solution will work for most of you -- so we can get it deployed and resume work on the next features for Notifications. Rest assured that we will continue to improve the user interface based on community feedback, but we need to move on to other important tasks, such as supporting HTML email notifications. Thanks again to all community and team members for your creative suggestions and hard work this week. By putting our heads together in a constructive way, we were able to find a reasonable solution to this issue in a timely manner. Onward! Fabrice Florin (WMF) (talk) 00:03, 10 May 2013 (UTC)

Discussion

This discussion page features five different options which we invited community members to comment on. Each option includes a design mockup, key features, as well as pros and cons. These options showed potential to provide the same benefits as the old orange bar, without many of its drawbacks.

We are no longer requesting comments for these features. Instead, you are invited to join our discussion on the talk page. We are grateful to everyone who took the time to comment on each of these options below, so that we could collaboratively identify the most practical solution.

Tooltip over badge (C)

Mockup of Option C: Tooltip over badge

Description

Features:

• tooltip connects to the red badge
• click opens the notifications flyout
• shows up on each page load
• goes away after a few seconds
• hides after you visit the talk page

Pros:

• Prominent
• Clear
• Invites you to use new tool
• Easy to develop
• Can adapt OBOD code

Cons:

• Not persistent
• Obscures critical tools below it
• Messages may not be in flyout, could be buried in archive
• Two numbers are confusing
• Can be annoying to some users
• Needs a dismiss function?

Comments

What do you think of this option?

• If it goes away after a few seconds, it's not going to be noticed if it happens in the middle of an edit. And if you're in the middle of something that needs access to the critical tools, it will be frustrating. Risker (talk) 06:13, 6 May 2013 (UTC)
• Make the message box hover at the top of your page when you scroll down (this is basically how Notifications work on Wikia) then you've got yourself a deal. FallingGravity (talk) 08:07, 6 May 2013 (UTC)
• I am not sure that this is, as the pros suggest, prominent. It is hard to judge without working with it, but it looks pretty easy to miss or ignore to me. The idea of pointing to the tool is a good one in this system, but that will probably be of most use to new users who are unfamiliar with the notifications system and that is not much use if they do not spot it in the first place.--SabreBD (talk) 09:37, 6 May 2013 (UTC)
• "Goes away after a few seconds" = strong oppose. Not as prominent as the OBOD, by a significant margin. MER-C 10:36, 6 May 2013 (UTC)
• Pretty OK, but D is better. The orange bar behaves very much like a ringing telephone. This is good in so far as it makes IPs and new editors aware that they have a talk page and that they got a message. It is also good in so far as it facilitates quick communication between experienced editors: Even when they are concentrated on something else, they will still notice when they get a message. But it is bad in so far as editors feel under pressure to react even when a message is not urgent and does not affect what they are doing right now. (Just like a ringing phone call tends to make people working in offices interrupt their dealings with the person in front of them and deal with the caller right away.) This is the part where the "OBOD" frustration comes from. A temporary notification would likely tend to exacerbate this sense of urgency, though the fact that it occurs on further page loads could mitigate this. Hans Adler 12:16, 6 May 2013 (UTC)
• Non-persistence is a big problem to me. I do like the solidness of the color bar here - it's better than a speck-sized square - but the blue sort of blends in (why not an attention-getting color?) and the top right of my screen is pretty much the last place I ever look. A more effective notification would be a brighter-colored bar at the (top) center or left of my screen. A fluffernutter is a sandwich! (talk) 14:00, 6 May 2013 (UTC)
• Not being persistent is a serious problem. Blue isn't a terribly good colour as it's the dominant colour on the page anyway. Obscuring important tools would be annoying for anyone who has to use them. Hut 8.5 18:47, 6 May 2013 (UTC)
• Between C and D, D wins. But G is my choice for new editors. Peridon (talk) 19:23, 6 May 2013 (UTC)
• Overall, the going away (I assume a fade animation) will probably draw the eye to the top if they don't scroll down too quick). @Risker Right now, notifications don't push to the user so I think it'd occur on all subsequent page loads (after edit) until you visit your talk page. @FallingGravity I think other options could be made that way, but this option is supposed to be attached to notification elem. @Sabrebd If it animates when showing, it's not likely to be missed, but I don't know if this option has that since it probably has a disappearing animation. @MER-C It will stick between page loads until their talk is visited (like OBOD), a receding link is an animation that draws the eye. -- tychay (tchay@wikimedia) (talk) 23:54, 6 May 2013 (UTC)
• No. See my comments on D, which I prefer. Espresso Addict (talk) 02:52, 7 May 2013 (UTC)
• IFF this is persistent --Guerillero | My Talk 00:24, 8 May 2013 (UTC)
• No. being persistent is a absolute requirement that can not be dispensed with. Even if it were, the notice must be designed to give the impression of being preemptory--the point of this particular notice is not just to get noticed, but to be acted on. The user must be strongly led to the talk p. We can change the wording, but a color associated with a demand is better. DGG ( talk ) 05:50, 9 May 2013 (UTC)

Tooltip over talk link (D)

Mockup of Option D: Tooltip over talk link

Description

Features:

• tooltip connects to the talk link
• click opens the talk page
• shows up on each page load
• goes away after a few seconds
• hides after you visit the talk page

Pros:

• Prominent
• Clear
• Matches expectations
• Easy to develop
• Can adapt OBOD code

Cons:

• Not persistent
• Obscures critical tools below it
• Inconsistent number treatment
• Discourages use of new tool
• Can be annoying to some users
• Needs a dismiss function?

Comments

What do you think of this option?

• What if the "new message" isn't a talk page message? (Comments above also apply.) Risker (talk) 06:14, 6 May 2013 (UTC)

  This would exclusively (and explicitly) be for talkpage messages - I'll update the schpiel above to reflect that. Okeyes (WMF) (talk) 16:42, 6 May 2013 (UTC)

• Of the first few options, I quite like this with the pointer to the talk page, but... It isn't bright enough, and per Risker. Also, 'Goes away after a few seconds"? No way. I suppose it only appears once - that isn't made clear, unless that's what 'persistent' means here. The idea for new editors is to get them to GO to the talk page. The only way to do sure of that is to make it sticky and reappearing on each fresh page. Once they get the hang of Notifications, they'll know what to do. Till then, they need something in the face. Peridon (talk) 08:37, 6 May 2013 (UTC)
• The same issue about prominence applies to this as to the version immediately above. On first look it does not appear that prominent. I like the idea of pointing to the talkpage tab, which sort of acts a bit like a tutorial, as long as all the notifications are on the users talkpage of course and not some other sort of notification.--SabreBD (talk) 09:37, 6 May 2013 (UTC)
• "Goes away after a few seconds" = strong oppose. Not as prominent as the OBOD, by a significant margin. MER-C 10:34, 6 May 2013 (UTC)
• If this accurately reflects the number of changes to the talk page (separate from the number of total Notifications), I support it as the second-best option after the orange bar. I agree that it should stay until dismissed, not float away after a while. Ignatzmice•talk 11:35, 6 May 2013 (UTC)
• I think this is the most promising of the new design ideas, but per others' comments, it's not good enough as is. Additionally, obscuring other tools is bad - it needs to be done in a way that this doesn't happen. If the tooltip is persistent (as it should be for talkpage messages), it can bump content down the page without needing to reflow it again when it disappears, so those two issues can actually be solved together. Rd232 ^talk 11:40, 6 May 2013 (UTC)
• I like it. Certainly much better than C. I guess it can become annoying if it repeatedly obscures the page history link, for example, but a dismiss link could take care of that. "Discourages use of new tool" - that's a feature, not a bug. As great as the new tool may be, it adds to new editors' learning curve. Ideally, they should learn about the notification tool when they are ready for it, not after fixing a few typos here or there and getting a welcome message. "Can be annoying to some users" - a problem, but one that seems to be an inevitable consequence of a feature. Everything that is sufficiently noticeable for most people will create a sense of urgency in many people and annoy some people. (I myself can feel my pulse going up when I see an orange bar. That's not because of any implementation details, it's because I know I have a message.) And we need the noticeability, or else the plausible deniability will completely disrupt our process of warnings before blocks and ultimately lead to more blocks and less editors. Hans Adler 12:27, 6 May 2013 (UTC)
• I haven't had my coffee yet, so maybe this is just a comprehension fail, but is the only real visual difference between this and (C) that the "pointy" part of the bar is moved over a few pixels to point to the talk link instead of the red box? If so, my issues with C would appear to be duplicated here - notification needs to be persistent, more screen-central, and brighter-colored. As far as click going straight to the talk page, I may be strange in this, but I prefer having the flyout to show me the edit summary before I decide whether to dash off to read immediately. A fluffernutter is a sandwich! (talk) 14:04, 6 May 2013 (UTC)
• As above: not being persistent is a serious problem. Blue isn't a terribly good colour as it's the dominant colour on the page anyway. Obscuring important tools would be annoying for anyone who has to use them. Hut 8.5 18:47, 6 May 2013 (UTC)
• @Fulffernutter The difference between this a C is this clearly associates itself with talk and the way to permanently dismiss it (click on user talk). OTOH it clearly disassociates itself from notifications so it may be too much too soon (two numbers pointing to two different places). My guess is "not sticking" part is designed to both prevent permanently obscuring UI and drawing attention to it as it recedes. There are more ways to draw the eye than visual treatment. If it sticks until dismissed then it needs to animate or something to draw the eye and avoid being missed (or extreme visual treatment like colors, size, etc). -- tychay (tchay@wikimedia) (talk) 00:01, 7 May 2013 (UTC)
• I like the way this links itself to the talk page, and the prominence is better. I like the dark blue, but I'm not sure whether it's sufficiently attention grabbing to ensure new users see it. It would have to be permanent to get sufficient attention. It would then work ok for me as I'm still using Monobook, so it wouldn't cover the tabs; however it is an enormous negative that it covers the tabs in the default skin. Unless the skin can be redesigned to prevent this (which might be a good option), then no. Espresso Addict (talk) 02:50, 7 May 2013 (UTC)

• Again, No. Being persistent is a absolute requirement that can not be dispensed with. And the notice must be designed to give the impression of being preemptory--the point of this particular notice is not just to get noticed, but to be acted on. The user must be strongly led to the talk p. We can change the wording, but a color associated with a demand is better. (and a placement on the bar conflicts with everything else there, as others have mentioned) DGG ( talk ) 05:51, 9 May 2013 (UTC)

Alert box near name (E)

Mockup of Option E: Alert box near name (follows page scrolling)

Description

Features:

• one-line box next to your name
• click opens the talk page
• shows up on each page load
• goes away after a few seconds
• hides after you visit the talk page

Pros:

• Prominent
• Persistent
• Clear
• Doesn't obscure content
• Can adapt OBOD code

Cons:

• Disconnected from talk link
• Doesn't invite use of new tool
• Can be annoying to some users
• Needs a dismiss function?
• Interferes with confirmations which will behave differently
• If the top right navigation becomes persistent having a yellow bar following you as you scroll vertically will be annoying
• Not persistent

Note: The 'goes away after a few seconds' was an error, which has now been struck out - this option would be persistent, and stay on-screen until clicked (or until the user visits the talk page). Sorry for this late-night error. Fabrice Florin (WMF) (talk) 16:23, 6 May 2013 (UTC)

Comments

What do you think of this option?

• Once again, disappearing after a few seconds isn't persistent, and can easily be missed. Otherwise, this is better than C or D. Risker (talk) 12:57, 6 May 2013 (UTC) signing late
  • Noting Fabrice's correction, that this is indeed persistent. This makes it better than others; however, I do agree with the point about the colour being too washed out. An in-your-face colour is what's needed, and is why the old orange was good. Red doesn't actually stand out all that well, given how much red is used in so many parts of the UI. I'd suggest a darker or more orange colour, but I could /probably/ live with this - IF it leads to diffs. (I'm actually having a hard time understanding why including the diff link seems to be a real challenge, since it's been easily available using the OBOD code for eons.) Risker (talk) 17:22, 6 May 2013 (UTC)
• (That's not me at the above post...) No. Wishy-washy and too easy to ignore. See my comment at D about going away. No good. Peridon (talk) 08:39, 6 May 2013 (UTC)

It is now said to be persistent (and I'll believe them). Still too wish-washy. Peridon (talk) 19:21, 6 May 2013 (UTC)

• Really not prominent enough for me in the dull yellow. I cannot help wondering if this is just a matter of colour, and what it would look like in orange.--SabreBD (talk) 09:37, 6 May 2013 (UTC)
• "Goes away after a few seconds" = strong oppose. It might be worth considering if the background was red, but it's still significantly smaller than the OBOD. MER-C 10:44, 6 May 2013 (UTC)

• Better, but still too small and not noticable. MER-C 00:48, 7 May 2013 (UTC)

• Probably too inconspicuous (no signal colour). Otherwise, my comments on D apply.— Preceding unsigned comment added by Hans Adler (talk • contribs) 12:32, 6 May 2013 (UTC)
• The yellow isn't noticeable enough, and something that automatically disappears after a few seconds is useless as far as my workflow - it needs to hang out there until I see it, which could be anywhere from immediately to a few minutes later. I like the center-of-the-screen placement of this, however. Make it a brighter color and not auto-hiding, and this would be my favorite. A fluffernutter is a sandwich! (talk) 13:56, 6 May 2013 (UTC)
  • In response Fabrice's correction, I'm basically with Risker: this could definitely work now that we know it's persistent, but I'd still like to see a more attention-grabbing color for it than pale yellow. Ryan Norton's idea below, about having the bar subsume the "blank" space between the logo and the userpage link is also a good one. A fluffernutter is a sandwich! (talk) 18:15, 6 May 2013 (UTC)
  • Oh, and also: In response to the "con" of "If the top right navigation becomes persistent having a yellow bar following you as you scroll vertically will be annoying" - I habitually reload pages while scrolled down, and Firefox very kindly keeps me where I've scrolled to when I do that, which means I very often don't see the "top" bar when I load a page and that no matter how eye-grabbing a notification I get, I might not see it until I scroll up. Having a notification that will show up at the top of my screen (wherever on a page that happens to be) when I load a page is actually a plus in my mind. Having the whole menu bar follow me might be annoying, but I'd prefer the notification, alone, did follow me. A fluffernutter is a sandwich! (talk) 18:23, 6 May 2013 (UTC)
    • Yeah, that would be useful for me too. (Yay bloated JavaScript!) Ignatzmice•talk 18:57, 6 May 2013 (UTC)
• Just a brainstorm, but I'm sort of thinking of it being the dark blue colors of C&D and it taking up most of the space between the wikipedia logo and user link rather than what appears to be a static size. This also seems like the best option for screen readers provided it is done server side and client side script can be axed. Ryan Norton 17:40, 6 May 2013 (UTC)
• This is my favorite right now, but I'd suggest to make it orange (the same color scheme as the OBoD IPs get). Later we can add opt-in tweaks for users who found out they have preferences (like picking a less orange color, adding a diff link, adding a mouseover tooltip with the last edit summary, removing the whole bar, etc.).

For making absolutely sure new users will get their messages, and still not adding too much annoyance for everybody, one could introduce a second line of defense: if a user tries to save an edit while having unread changes on their talk page, they get an interstitial asking (or even forcing) them to go to their talk page first. It could offer to open the talk page in a new window/tab, so the unsaved edit is not lost. Details to be discussed, of course. — HHHIPPO 18:33, 6 May 2013 (UTC)

• Might work if the colour was changed to something more striking. Hut 8.5 18:47, 6 May 2013 (UTC)
• This is the second best option after G because it's persistent, but it's still too similar to the background that it'll blend into the various bars that form the top of most browsers. MBisanz ^talk 22:09, 6 May 2013 (UTC)
• Don't see this as an improvement on the orange bar. It neither grabs the attention nor links with either the talk page or the new notifications number. Espresso Addict (talk) 02:41, 7 May 2013 (UTC)

• The revised brighter-coloured version is an improvement. For clarity, the substitution should be noted; this is not E. Espresso Addict (talk) 08:00, 8 May 2013 (UTC)

• After testing the different prototypes (this one is orange not yellow, by the way), I like this one the best because 1) it's the most noticeable 2) it has a link to the diffs (non of the others do, which may just be the prototype design) 3) unlike OBOD, it's slightly less obtrusive and looks more graphically appealing. The Anonymouse (talk | contribs) 16:15, 7 May 2013 (UTC)
• Having tried the prototypes, I now favor this one. It is, in fact, actually an improvement over the orange bar, because it follows you down the page and yet is locally dismissible (it returns on next page load). It only shows up for new messages, not all notifications, which is very good. The only way it isn't better than the orange bar is for people with screen readers (I imagine) and people with JavaScript disabled. Ignatzmice•talk 18:59, 7 May 2013 (UTC)

• Probably the best option - I like the idea that it is smaller than the OBOD and that it floats. It should be more boldly colored, though, as others have suggested. – Philosopher ^{Let us reason together.} 05:21, 8 May 2013 (UTC)
• It's the best option of those presented here, but hopefully only a temporary solution. A permanent solution needs to make it clear that the messages are on the user talk page... otherwise users may not realise that their user talk page is where they need to go if they want to read the messages again. Once Flow comes to life, perhaps we can kill that. — This, that and the other (talk) 09:45, 8 May 2013 (UTC)
• Better, but not an improvement. Following you down the page is really annoying. The balance is to have it stay on top until it is acted on--the point is to get it acted on. DGG ( talk ) 05:53, 9 May 2013 (UTC)

Inline text after badge (F)

New Message Indicator Screenshot - Selected Option F2

Mockup of Option F: Inline text after badge

Note: This option was since updated in collaboration with community members into this option F2 below, which was developed after this discussion ended on this page.

See also: this animated mockup

Description

Features:

• inline text after the red badge
• click opens the notifications flyout
• animation makes it more prominent
• shows up on each page load
• hides after you visit the talk page

Pros:

• Prominent
• Persistent
• Clear
• Doesn't obscure content
• Easy to develop
• Can adapt OBOD code

Cons:

• Messages may not be in flyout, could be buried in archive
• Long text makes navbar hard to read
• Inconsistent with links near it
• Does not stand out in static view
• Animation could get annoying

Comments

What do you think of this option?

• Good persistence, but no more obvious than the red number. Good that it doesn't disappear until clicked. How will it work on smaller screens like netbooks and tablets? Risker (talk) 06:18, 6 May 2013 (UTC)
• Looks just like part of the scenery. Doesn't grab the attention, and like all the above options, it goes away. Peridon (talk) 08:41, 6 May 2013 (UTC)

Apparently, it doesn't go away. Trying to decide if that really is animation. Can't see the point, when it's going to hide in a line of little text things anyway. Peridon (talk) 13:31, 6 May 2013 (UTC)

• It really is too easy to ignore. My least favourite option. I actually missed it as an option while scanning down the page (although that is without animation).--SabreBD (talk) 09:37, 6 May 2013 (UTC)
• Too small, too easy to ignore. MER-C 10:44, 6 May 2013 (UTC)
• The animation seems a bit childish (reminds me of the early HTML blink tags) and probably requires a relatively wide screen for reasonable results. Might still be too inconspicuous. Hans Adler 12:36, 6 May 2013 (UTC)
• As the others say, this is no more attention-grabbing to my eyes than the red number is, and as I've said above, top-right of the screen is a losing prospect in my eyes. The animation is cute, I guess, but why spend the resources to animate something when we could just make a static notification that would work way better anyway? A fluffernutter is a sandwich! (talk) 14:07, 6 May 2013 (UTC)
• No. Too small, doesn't stand out, blends in with the text next to it. No better than the red number, as Fluffernutter said above. Hut 8.5 18:47, 6 May 2013 (UTC)
• No. Not prominent and blends in with the permanent text links in a confusing way. I haven't checked the animation but I detest animations, so that would probably be even worse. Espresso Addict (talk) 02:44, 7 May 2013 (UTC)

• I kind of like this, although there might be some advantage to having it in red text rather than in blue. The animation is unimportant; it just seems to hide the notice text when you click on it to open the notifications. WhatamIdoing (talk) 14:21, 7 May 2013 (UTC)
• Absolutely not - per Expresso Addict and Hut 8.5. It needs to be a "slam you in the face" experience, at least for the first few times it appears. Remember that not all Wikipedians are web experts! – Philosopher ^{Let us reason together.} 05:12, 8 May 2013 (UTC)
• Invisible. DGG ( talk ) 05:54, 9 May 2013 (UTC)

Orange bar in article (G)

Mockup of Option G: Orange bar in article (OBOD)

Description

Features:

• big orange bar inside article area
• click opens the talk page
• shows up on each page load
• hides after you visit the talk page

Pros:

• Very prominent
• Clear
• Persistent
• Expected feature for current users
• Easy to re-enable (as add-on to Notifications)
• Consistent with interface for anonymous users

Cons:

• Too prominent/overwhelming
• Bad UI / visual design
• Does not belong in article content
• Annoys many users
• Discourages use of new tool

Comments

What do you think of this option?

• Anthonyhcole (talk · contribs · email) I, and everyone commenting here, will quickly learn to check for the little red tab; I'm sure of that. The people who need a big and noticeable "new talk page message" notification are the new editors. For them, the orange bar is the best of these options. It doesn't matter that it is jarring and inconsistent because I hope you'll include a tooltip that explains they can dismiss it permanently, and that the little red tab performs the same function. 06:16, 6 May 2013 (UTC)
• I think Anthonyhcole is mostly right here, although until there are diffs in the little red tab, I'm pretty sure any experienced user will simply add the script or start ignoring the red tab, which is infinitely easier to ignore than the OBOD. Risker (talk) 06:22, 6 May 2013 (UTC)
• Must be the default Messages are for communication, not decoration. The notification for an IP or new user must pointedly tell them that something unusual has happened. Those of us who are used to these things have no idea how mysterious a new system can be—flyouts and what have you are just background noise to a new user. If the devs are offended by the OBOD that much, perhaps they could code it to be the be default for the first five messages. After that, the next five messages would include an extra link to tell the user that if they want the OBOD forever, they need to go to their preferences because it will automatically change to something cooler after ten messages. Johnuniq (talk) 06:24, 6 May 2013 (UTC)
• Sorry, but it's the one for my money. In the face and doesn't go away. Needs to be default, but rather than an automatic change, I'd prefer a note to explain how to get rid after five of however many messages. Might encourage newbies to actually look at their preferences and not just stick to Vector and whatever else is default. When people know how to make something look like their own, they look after it better. "Doesn't belong in article content" - yes. That's the idea, isn't it? Get it out of the scenery and to the front of the stage. This is why they don't stick parking tickets to the nearside rear window. Peridon (talk) 08:51, 6 May 2013 (UTC)
• I really tied to give the other options a fair appraisal, but perhaps it is because I am programmed to look for it, but this is the only one that made me stop and think that I perhaps had to do something. In the end this one works, the others are likely to be ignored. However, perhaps they could be modified in colour and size to work as well as this.--SabreBD (talk) 09:37, 6 May 2013 (UTC)
• "Discourages use of new tool" - Is this why WMF staff have been so vehemently opposed to reintroducing the orange bar? Regardless, this should be the default. Add a user preference for experienced users to turn it of. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:06, 6 May 2013 (UTC)
• Kill it. Finding a good solution to this problem is not going to happen if we hold on to the past. It will only serve as argument not to solve this with new and potentially better solutions. Mixing the old with the new will only confuse new editors... "Why the hell does Wikipedia have a dozen different means of communicating?" — Edokter (talk) — 10:30, 6 May 2013 (UTC)
• Big and ugly is part of the reason why it works. Any alternative to the OBOD needs to be comparably prominent and persistent. Neither of the above satisfies this criterion. They appear to be merely window-dressing, so that the WMF can pretend that they are responding to community concerns. I'm willing to consider other options, but none come close at the moment. MER-C 10:40, 6 May 2013 (UTC)
• Best of the options so far. As others have commented, the other options are essentially not attention-grabbing enough. The Orange Bar is ugly, but it works. One good point is that it doesn't belong in the article area - which is actually the first reason I've seen to get rid of it that rises above "it's ugly" or "it's old-fashioned"! So if it can be moved above the tab bar, and shown only for talkpage messages, then this would be a good-enough short-term solution. Longer term, design tweaks can go from there - linking visually with the "my talk" link in the way Option D does is an excellent idea, for instance. Rd232 ^talk 11:37, 6 May 2013 (UTC)
• This is the best one. It gets your attention and holds it, which is what we want. I like Peridon's idea of letting them know after five changes to their talk page that they can get rid of the old bar if they want. Maybe you could sent them a Notification describing how to do that; if they can figure out how to read that, we can trust them to notice the new system. Ignatzmice•talk 11:40, 6 May 2013 (UTC)
• No, no, no. Kill it with fire! Changes are not always good, but refusing to change because it's not what the old timers are used to are just as bad if not worse. Die!! -- KTC (talk) 12:05, 6 May 2013 (UTC)
  • Nobody is "refusing to change because it's not what the old timers are used to"; we're concerned about the effect on new editors. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:02, 6 May 2013 (UTC)
    • Except that the sole basis for all of us old editors asserting that the OBOD is good for new users, and that the others are not, is the fact that OBOD is how all of us managed to find our first talkpage messages, sometime in the previous decade or so. Our arguments amount to "ain't (very) broke/don't fix", with little willingness to even test the various options. WhatamIdoing (talk) 14:02, 7 May 2013 (UTC)
      • [Belated response; having missed this]. No. My comments are based on extensive experience training new users; and the fact that none on my first two such sessions after the change, noticed their new massages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:45, 15 May 2013 (UTC)
        • As said, I have serious problems with treating that as a valid demonstration of new users, for several reasons. The first is it's a very small number of samples; two sessions does not a full usability study make. The second is that it's a totally artificial environment. Most new editors do not become new editors in a room with an experienced contributor teaching them, with multiple participants, with a set timetable or structure to the learning process. We shouldn't draw from such an environment conclusions about new editors overall. I will be very interested to see the outcome of the A/B testing we'll be doing in the coming weeks. Okeyes (WMF) (talk) 21:13, 15 May 2013 (UTC)
          • Oliver, it doesn't make a lot of sense to dismiss this experience. You seem to be repeatedly responding as though Andy is claiming it to be statistically significant. But that is your framework, not his. Since there is no other statistical data for us to look at, why do you continue to badger Andy about the lack of scientific perfection of his data? Why do you continue to ignore his asserted status as an expert -- a different form of authority than data? Nobody has claimed that this small sample is scientifically significant; you are attacking a straw man, and because of that, you are missing what he is saying. -Pete (talk) 22:25, 15 May 2013 (UTC)
            • Quite. Oliver is also making assumptions "set timetable or structure", etc., about how the training was delivered; and my prior reference to User testing#How many users to test?. Meanwhile, his colleagues a cite test with just two individuals in support of their assertions. He doesn't say whether his A/B testing will include the old orange bar, but that testing should; and should clearly have been done before that was removed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:47, 15 May 2013 (UTC)
              • What test with two participants did we cite? :/. (not sarky; I want to know so I can give a grumpy look to the people involved). Pete: I'm sorry if I came off as suggesting that Andy was claiming it to be quantitative; I appreciate that he's not. But what we're talking about with system-wide changes is ultimately primarily quantitative, not qualitative; it is highly dangerous to rely on individual use cases and user stories. Andy; I'm not sure, I'd advise you to poke Fabrice on his talkpage for more details. Okeyes (WMF) (talk) 18:29, 16 May 2013 (UTC)
                • See Wikipedia talk:Notifications/New message indicator#I'm enabling the popup. You're still ignoring my reference to User testing#How many users to test?, I note. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:20, 16 May 2013 (UTC)
                  • I didn't see that reference (indeed, I can't find that link except in the context of you telling me I haven't addressed it). I agree that individual user tests are problematic for anything more than generating testable hypotheses. Okeyes (WMF) (talk) 19:37, 16 May 2013 (UTC)
• There is no technical reason not to move this to a more appropriate place further up. Editors who hate the orange bar do so primarily because it keeps reminding them they have new messages and creates a sense of urgency. Given that the new message could well be a warning to immediately stop a certain type of edits, that's a feature, not a bug. Hans Adler 12:44, 6 May 2013 (UTC)
• I personally hate the orange bar and welcome the new system but IMHO new users need to continue seeing that monstrosity until they turn it off. This makes it all but clear to them that it's humans who are trying to talk to them. For those who don't know otherwise, the word "notifications" might not indicate anything serious requiring one's immediate attention. This is especially true for for Facebook users. Facebook has a similar "notifications" tab that shows you a list of who commented on what and who has liked what. Not something that a typical facebook user (aside from "likeaholics") has to check as soon as it lights up. If a new user is doing something inadvertently destructive but he thinks is innocent and multiple editors are screaming at him to stop, then it needs to be made crystal clear to him that he needs to check his talk page !!!NOW!!!. A little red box with a number in it might not indicate that urgency. Another problem is that if someone spends some time editing as an ip and gets use to seeing orange bars when he has messages but stops seeing them when he creates an account, he might miss the fact that he has messages. --Ron Ritzman (talk) 13:21, 6 May 2013 (UTC)
• I do not like the orange bar, and am confident there are many better options available along the lines of those laid out above. But restoring the orange bar as it used to work is the only viable option at this point, as a temporary measure. This will create the space for productive discussion about a better long-term solution, without rushing the decision, and without having negative impacts on use cases not considered thoroughly enough. We should get back to the orange bar as soon as possible. -Pete (talk) 13:56, 6 May 2013 (UTC)
• I really dislike the orange bar. It's garish and overly intrusive. That said, however, if the options presented on this page are our only options, I'd have to hold my nose and vote "orange bar" because it's the only one of that has a good chance of me (or a newbie) noticing it. I like Rd232's suggestion that you transplant the orange bar to above the tab bar - sort of hybridizing this and option (E). I know you guys feel rushed by the pressure the community is putting on you about this, but I'd really encourage you to take some of the comments you're being given on these options and iterate again on possible designs before settling on something - at a glance, for example, there seems to be very strong support for any solution to be persistent, and slightly less marked support for it to be more brightly colored. You can do those things! They're not hard, because they're mostly things you've addressed here and there in these suggestions anyway. Just take the best of each, see what that gives you, and then come back to us for opinions.

  I've commented previously that I trust you guys to give us something better than the orange bar, and that I don't think the orange bar should remain a legacy feature - but it seems this redesign is going to take at least another week, and probably more, before you've got an acceptable finished product, and I'd therefore encourage you to do everything you can to fill the gap right now by temporarily bringing back the orange bar. It doesn't have to stay once we have the new design implemented (please make it go away then!), but being stuck with no good default option right now isn't really a viable solution if "right now" is going to be more than a few days. A fluffernutter is a sandwich! (talk) 14:17, 6 May 2013 (UTC)

• By default, this is the only option that has my support, because it's the only option that will work for people with screen readers, and people who have Javascript disabled. Sophus Bie ^(talk) 16:59, 6 May 2013 (UTC)
  • I concur with Sophus Bie. Prominent talk page notifications are needed by all editors; they aren't just some nice-to-have gadget. JavaScript should never be needed for core functionality. And we don't want people to be able to give "I had JS disabled" as an excuse for not seeing talk page warnings. Also see Risker's concerns on the talk page. – PartTimeGnome (talk | contribs) 21:19, 7 May 2013 (UTC)
    • I'll just add: The orange bar is the only option presented that has the "last changes" link to a diff. Since the other options are in practice inferior to the orange bar in multiple ways, I can only support the orange bar. If you want to replace it, make sure the replacement does everything the orange bar did before working to make it pretty. – PartTimeGnome (talk | contribs) 21:33, 7 May 2013 (UTC)
      • Note that option E, which you can test by adding importScript('User:Kaldari/topalert.js'); to your common.js, now includes "last change". But the JavaScript is an issue. Ignatzmice•talk 21:40, 7 May 2013 (UTC)
        • Ah, thanks for that. That comment is based on the mock-up images, which don't show this on E. – PartTimeGnome (talk | contribs) 22:42, 7 May 2013 (UTC)
• I'm not particularly wedded to the orange bar, but it is still much better than any of the other options. It stands out, is persistent, and gets the reader's attention. "Discourages use of new tool" isn't a drawback. Hut 8.5 18:47, 6 May 2013 (UTC)
• I'd be happier with a persistent version of C or D, but in the interest of picking something, to fill the need, this is the best option. MBisanz ^talk 22:11, 6 May 2013 (UTC)
• OBOD has only a 50% clickthrough rate based on the Huggle research, so I'm not convinced that, while annoying to us who have been trained to notice it, it's actually that noticeable to new users. I bet animation (either in/or fade out) will be more noticeable, or position:fixed in the case of E. Since all of these seem to reuse existing OBOD code, I would like it if this was coded in for some users and one of the others were tested against this. -- tychay (tchay@wikimedia) (talk) 00:11, 7 May 2013 (UTC)
  • If there is any evidence that the current tool has click-though rate higher than 50%, it has yet to be presented to us. Have you seen it? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:33, 7 May 2013 (UTC)
  • Does click-through rate account for users clicking on "my talk" in response to the Orange Bar instead of clicking on the Orange Bar link? I personally always do that. Maybe it's just me. Rd232 ^talk 09:21, 7 May 2013 (UTC)
    • As do I (usually "right-click; open-in-new-tab"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:46, 7 May 2013 (UTC)
• I'm sorry, but this is the best of the options presented, in terms of prominence, permanence until acted on, and usability with the default skin. Espresso Addict (talk) 02:56, 7 May 2013 (UTC)
• This is the least intrusive and most useful (it has direct link to message, or space for two links). C, D, E are likely to overlap with something and F is useless, hidden with the rest in personal tools. --Nemo 12:47, 7 May 2013 (UTC)
• Still the best option around, still should be in use. Make this default, give all other variations as options. That way, everyone (bar the devs who have more work than they bargained for) is happy. Lukeno94 (tell Luke off here) 14:56, 7 May 2013 (UTC)
• I don't even understand why this was changed. Can I restore this in settings, CSS, or javascript??? πr² (t • c) 18:41, 7 May 2013 (UTC)
  • See User:Writ Keeper/Scripts/orangeBar. Ignatzmice•talk 18:56, 7 May 2013 (UTC)
• <naivete> Since G is the only one that works with screen readers, I would assume this is the only option. </naivete> Black Kite (talk) 21:27, 7 May 2013 (UTC)
• Ugly as sin --Guerillero | My Talk 00:21, 8 May 2013 (UTC)
• Enable for users who are not yet autoconfirmed only. The iea is to say "hey, you have a talk page - pay attention because the info there is important (esp. if warnings)". Once they know they have a talk page there is no need for this any more. – Philosopher ^{Let us reason together.} 05:19, 8 May 2013 (UTC)
• Still the best. Like others, I'm not absolutely insisting on orange. Personally, I think the bright blue color used for some of the others would work well also, as long as it was big enough. And could it go over the article title, instead of under? DGG ( talk ) 05:56, 9 May 2013 (UTC)
• Support Best possible. Consider: what do you want when you want a notification for talk pages, something very important? You want something persistent (it won't go away unless you check it!), clear (no confusion), and very prominent (harder to make up an excuse that you didn't see it). Also, you want IPs and registered users to have the same system. This way new users will be much less confused. Finally, you want it very accessible for such an important warning, so everything else is out (per others' comments). Which one of these has all these properties? Why, G, of course, our great Orange Bar.
  Now, what about the cons? Going through them, one by one:
  • (1) Too prominent/overwhelming Please correct me if I am wrong, but I think that is the point. If it isn't prominent enough, people will overlook it. Talk page messages are important. If they are overwhelming, at least everyone will see them, as much as they might complain about its overwhelmingness, and isn't that the point of a talk page notification? If they are not overwhelming enough, some will overlook it, and that is bad.
  • (2) Bad UI / visual design Maybe so if it were not for something this important, but its colour and size make it obvious. I would submit that the obviousness must be retained.
  • (3) Does not belong in article content So? It's not intrusive. The title is bolded in the lead, after all! If you are that interested in the article, "Open in new window / tab" and the back button exist for a reason.
  • (4) Annoys many users See (1). It's the point. Perhaps it is annoying, but ask yourself: would you reply to your talk page messages if it were not? Consider: which are you more likely to respond to, a message posted on your talk page (and on several other fellow WikiProject members), or one posted on a WikiProject page? Granted that you probably watch the latter, but which will you notice first? And will you not feel it as more personalized?
  • (5) Discourages use of new tool Not a bad thing IMHO, if the new tool is not as good as the old one. As to why I feel that is the case, see above.
• Oh, and since some have mentioned this: I would prefer keeping it orange. Warning colour do wonders in getting people to pay attention – but only if the area of warning colour is large and prominent enough (in response to those who would otherwise respond that the notifications have a red square). Double sharp (talk) 14:51, 11 May 2013 (UTC)
  • One thing I neglected to mention: this is the only one that gives a link to the diff, which is great if the new response is buried early in a subsection, with what it is replying to, but nearly completely undetectable by a quick scan of your talkpage. Double sharp (talk) 14:54, 11 May 2013 (UTC)
• This one: Best option! --Tito Dutta (contact) 16:04, 11 May 2013 (UTC)

• Absolutely not. The conservatism of users here can be rather disconcerting at times, and this is one of those times. It seems that editors here spend all day on the site, and fail to realise that the whole world uses more advanced and unobtrusive types of notification, and that users are capable of adapting. I don't just find the bar annoying, they way I use the site means I often get one in the tens of browser windows I have open, and it makes me seriously want to consider giving up editing here. What's more, with the defaulting of OBOD for IP users, the most serious and urgent of concerns appear to have been answered. Bringing back OBOD cannot possibly be treated as a viable option as much as the archaic practise of fagging should be brought back in education circles. -- Ohconfucius ^{ping / poke} 06:11, 13 May 2013 (UTC)

Final comments

New message indicators for notifications tool

Please post any final comments and suggestions about next steps for this proposed feature.

(For a quick overview of our options, check out this matrix of options by criteria.)

• Why not have the "flyout" fly out automatically when there is an unread user talk page message? It's big and obvious and compatible and already there. --Anthonyhcole (talk · contribs · email) 06:31, 6 May 2013 (UTC)
• Is there any more options besides these? In my opinion: C&D are worse UI-wise than OBOD, E isn't prominent enough, and F is the worst of the bunch, so it seems G is still the best for the short-term for new users unfortunately. There has to be a better solution, even in the short-term. Ryan Norton 07:10, 6 May 2013 (UTC)
  • There are more at the Google presentation, but these seem to be our options for now. Ignatzmice•talk 11:42, 6 May 2013 (UTC)
    • Just wanted to say thank you for the link, and I see it below as well. Maybe it should be mentioned in the opening... or something. After reading that, I think rather than this format we should go more for a brainstorming approach at this point, but that's just my 2c. Ryan Norton 14:49, 6 May 2013 (UTC)
• In my opinion, G should be killed off; not suprisingly, it serves only existing editors that basically do not want change and have no regard for new editors. We must stop to try and force the old ways on new editors just because we are used to it. The OBOD is a dinosaur. BTW. Were there any optiona A and B? And why is there no option to use the existing notification bubble (like my gadget does)? — Edokter (talk) — 09:23, 6 May 2013 (UTC)
  • No - most of us that are campaigning for it are concerned about the difficulty of communicating with new editors, and getting advice and warnings through to them before they get blocked. I have decided that the little red pimple suits me, having quickly got used to it. I've been here five years and it took several hours before I noticed it first. We're not trying to force OBOD on regular editors. It's the newbies we're bothered about. OK, some older editors may want to keep it for themselves - but as an option not as an imposition. Peridon (talk) 09:46, 6 May 2013 (UTC)
    • "...it took several hours before I noticed it first." Is that good? If it were an OBOD, how many seconds would it take for you to notice? (I'm guessing less than one.) Double sharp (talk) 14:53, 11 May 2013 (UTC)
• Tooltips require people to already know that there's a message; the problem is that the new feature does not make that readily apparent to novice users. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:10, 6 May 2013 (UTC)
• We need to get back to the kind of site behavior expected by tens of thousands (including many who would certainly be classified as "newbies" who have made occasional edits over the years). Discussion of specifics is becoming a time-consuming distraction. This page illustrates that there are many good ideas to discuss; let's please get to a point where we can all feel good about participating in that discussion. -Pete (talk) 14:29, 6 May 2013 (UTC)
• Can someone elaborate as to how each of these are coded? Currently, I would support option G, but mainly because it's the only one I know will work for people with screen readers and people with Javascript disabled. Sophus Bie ^(talk) 15:11, 6 May 2013 (UTC)
  • I'm not official, but I strongly suspect that they're all JavaScript. Certainly the popups would be. Ignatzmice•talk 15:17, 6 May 2013 (UTC)
    • All except F and G require JavaScript. F may may require JavaScript, but I'm not sure. — Edokter (talk) — 15:21, 6 May 2013 (UTC)
      • Well, humbug. I'm guessing none of the others solve the screen reader problem either. I guess G gets my support by default then. Oh well. Sophus Bie ^(talk) 16:57, 6 May 2013 (UTC)
• In my opinion, the ideal place would be between the [Talk] and the [Read] tabs just above the article title. This won't interfere with the text of the article, but is more prominent than the upper right corner. -- Ypnypn (talk) 15:51, 6 May 2013 (UTC)
  • Note that those tabs aren't consistent among the skins—but yes, that's actually a very good place to put it. Ignatzmice•talk 15:56, 6 May 2013 (UTC)
• This might not be possible for the temporary release, but for the permanent release, can we get a third option in our notification preferences (something like quiet/loud/email)? That is, any notification marked "quiet" would be indicated by just the notification number, anything marked "loud" would get whichever of these options we decide on (or whatever replaces it permanently), and email sending the notification email? (These three need not be mutually exclusive, I suppose; "loud" and "email" would certainly imply "quiet", but "email" need not imply "loud"; either way.) I myself would like my attention drawn to a talk-page post, but don't find the others to be as necessary for immediate attention, and I think configuring this for ourselves would be the best way to go. (Presumably, talk page would be locked to a minimum of "loud", and the others would have full configuration across the options.) Writ Keeper ⚇♔ 17:06, 6 May 2013 (UTC)
  • Interesting idea, makes sense, and would be useful to some. Risk of bamboozling new users with too many options though, so would need to be presented carefully. Rd232 ^talk 21:26, 6 May 2013 (UTC)
  • More bloat! Hurray hurray! But that's actually a very neat idea. I support it as well. Ignatzmice•talk 21:33, 6 May 2013 (UTC)
  • I would use this. --Anthonyhcole (talk · contribs · email) 22:13, 6 May 2013 (UTC)
  • Fourthing. Espresso Addict (talk) 03:38, 7 May 2013 (UTC)
• Whatever you end up going with, can you make an easy way for those of us who mostly like the current implementation to do away with it? Echo is pretty much great I have no desire for a random bar to flit around, unless you make it like Nyan Cat. ~ Amory (u • t • c) 03:00, 7 May 2013 (UTC)
• Having looked at the Google docs presentation, H (the little green box next to talk) seems like an interesting option to explore for experienced users who choose to have a less-prominent talk page notification. However, it certainly doesn't meet the prominence requirement, especially for new users. Espresso Addict (talk) 03:47, 7 May 2013 (UTC)
  • I think H is a good target to go for. It may not solve the concerns now, but for a future release to include whatever solution is arrived out while including H as less urgent would be glorious. ~ Amory (u • t • c) 02:17, 8 May 2013 (UTC)
    • H would be good for (some) experienced users in the future (I personally would keep either E or Writ's orange bar), but think of all the newbiez! It would be good to have something prominent that can be opted out of. Ignatzmice•talk 02:32, 8 May 2013 (UTC)
• I'm struck by the conservative attitude, which must disappoint the WMF's engineers. Yes, the orange strip is kind of aesthetically nice, and we've become very used to it over the years. But that doesn't mean we should stand in the way of change. I support the more discreet little red box at the top, but if people really want their orange stripe back, could we please make it less disruptive. Someone above said it's like the phone ringing ... more like a fire alarm jangling. Why not make it thinner (vertically and horizontally) with a smaller font-size? Tony (talk) 06:37, 13 May 2013 (UTC)
• I find options C through E all acceptable, provided they are capable of being disabled. 'F' looks weird with the new passive expression in active voice, and I don't much care for that. 'G' must be avoided at all costs, and I would rather they brought back hanging and drawing first. -- Ohconfucius ^{ping / poke} 06:38, 13 May 2013 (UTC)
  

• OhC, we must have had an e.c. ... just read your comment. F is not in the passive! I largely agree with your other points. Tony (talk) 06:42, 13 May 2013 (UTC)

• I stand corrected. I just meant to say it looked weird. Perhaps it's the effect of having been accustomed to years of abuse ;-) -- Ohconfucius ^{ping / poke} 06:56, 13 May 2013 (UTC)

How do we control max number of items shown

If this has been mentioned here, I've missed it. The little red box shows "X" amount of notifications with a "More" option at the bottom. Will we be able to control that maximum number (days) we want shown, like our watchlists, or will "More" be a continual feed that runs to infinity? Seems there should be an option to control how much we want on that history. — Maile (talk) 12:19, 13 May 2013 (UTC)

It scrolls infinitely, but only loads ten at a time :). In practise, it means you can load as many or as few as you want (as long as "few" isn't less than 10, I guess). Okeyes (WMF) (talk) 19:56, 13 May 2013 (UTC)

Next steps

Thanks for your feedback!

Based on your responses and our development team's recommendations, we plan to develop and release the solution described in the 'Resolution' section at the top of this page, and detailed in more depth in this feature requirement. In coming weeks, we plan to collect data on how that new solution is being used after its release, in order to determine its effectiveness. This will help us all make more informed decisions for our next steps, based on actual data rather than subjective impressions.

For the long term, we are particularly interested in Option H: Separate badges, which would provide separate flyouts for notifications and messages. However, that option would require several weeks of development, and cannot be implemented right away. It will also require more research to validate that it would provide a better user experience.

To learn more about Notifications, visit the project page or check this FAQ page. You are also invited to join our discussion on the talk page.