Misplaced Pages

Revision as of 18:33, 6 May 2013

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

Background

A new notifications tool was released on the English Misplaced Pages 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 bar of doom/death (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 have 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).

To address these concerns, we would like to deploy a temporary solution this week, 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 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

(These criteria are further elucidated in this presentation.)

This discussion page features five different options for your review. Each option includes a design mockup, key features, as well as pros and cons. These options can be developed quickly this week, and have the potential to provide the same benefits as the orange bar without some of its drawbacks.

Please comment on each of these options below so that we can collaboratively identify the most practical solution.

Tooltip over badge (C)

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)

Tooltip over talk link (D)

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 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)
• 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)

Alert box near name (E)

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)
• 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)
• 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)
• 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)

Inline text after badge (F)

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)

Orange bar in article (G)

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 Misplaced Pages 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 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)
• 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 16:59, 6 May 2013 (UTC)

Final comments

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)
• 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 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 16:57, 6 May 2013 (UTC)
• In my opinion, the ideal place would be between the and the 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)

Next steps

Thanks for your feedback!

We plan to develop and release one of these new message indicators this week, based on your responses and our development team's recommendations.

We'll also host an IRC office hours chat to discuss these new designs and the new notification tool next Wednesday, May 8th at 20:00 UTC (1pm PT). We hope some of you can join us then for a constructive conversation about our next steps.

Next week, we plan to collect data on how that new solution compares to the current version of the tool, 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.

To see all the designs we have considered so far, check out these slides. We are particularly interested in Option H: Separate badges, for the long-term, to provide separate flyouts for notifications and messages. However, that option would require several weeks of development, and cannot be implemented this week. 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.