Jump to content

Help talk:Notifications/New message indicator

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

What's the rush?

[edit]

Just prior to the release of Echo here, there was a big rush to have this tool ready by Tuesday, April 30. And now there still feels like there's a lot of pressure to act quickly and move forward as soon as possible. I don't understand what the rush is. If people are unhappy with the current implementation of Echo, it can always be disabled (it takes a matter of a minute or two to turn it off). I don't think it's fair to the editors here to make them feel as though they need to feel pressured to act simply because the Wikimedia Foundation has erected arbitrary and artificial deadlines. --MZMcBride (talk) 14:52, 6 May 2013 (UTC)[reply]

The main pressure point seems to be that "new editors do not know they have new messages" because the red badge is too obscure, and that the Orange Bar Of Doom needs to be re-enabled as soon as humanly possible. Dispite the fact there is a solution available (my gadget), people just don't want to let go of the OBOD in the believe that this is the only option that new editors will notice. — Edokter (talk) — 15:02, 6 May 2013 (UTC)[reply]
I haven't seen anyone say that; but it does seem to be the only option presented so far that new editors will notice. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:09, 6 May 2013 (UTC)[reply]
For new editors, the orange banner is the most obvious to the eye that I've seen so far - and it should be able to be turned off by non-new editors now that the red thingy is up and running. I'm not suggesting that we have it as the sole indicator. Based on what I've seen of Edoktor's gadget, it would be fine for those more experienced editors who have trouble seeing the red spot, but that it isn't in your face enough for beginners. Believe me, it's not easy getting through to them at times, even when you know they've seen a message. When you don't know if they're ignoring you deliberately or just not knowing, it's nigh impossible. Peridon (talk) 18:15, 6 May 2013 (UTC)[reply]
Well said, MZMcBride. This entire rollout appears to be dominated by a sense of urgency that, as far as I can tell, is wholly arbitrary. A process based in the broad consensus that notifications need improving would (will?) likely be successful; one that starts off by dividing users into "pro" and "con" and leverages the WMF's unique ability to turn things on and off at its discretion has, predictably, resulted in forest fire. -Pete (talk) 15:20, 6 May 2013 (UTC)[reply]

Update: Alert box near name (E) is persistent

[edit]

I would like to make a correction about the earlier statement that the alert box near name (E) 'goes away after a few seconds'. That error has now been struck out - this option would be persistent, and stay on-screen until clicked (or until the user visits the talk page).

Risker, Peridon, SabreBD, MER-C and A fluffernutter is a sandwich!, would you like to revise your comments accordingly? Sorry for this late-night error. :(

I also really appreciate your overall recommendations to not rush this process, and work deliberately to find the right design, while restoring the orange bar of doom temporarily, until we have a better solution. We are taking that advice very seriously and will post an update soon on our next steps. Thanks again for all your constructive guidance! Fabrice Florin (WMF) (talk) 17:14, 6 May 2013 (UTC)[reply]

Could you clarify 'persistent' and 'goes away'? I take it that 'goes away' means evaporates whether you do anything to it or not - but I'm not certain whether it reappears on a subsequent page and evaporates there (like the morning dew each day...). Does persistent mean that it stays on that page, or that it follows the user to subsequently opened pages (until it is dealt with)? Peridon (talk) 18:02, 6 May 2013 (UTC)[reply]
The former, although we're experimenting with the latter (about to post an update on the matter!) Okeyes (WMF) (talk) 21:36, 6 May 2013 (UTC)[reply]

Update: prototypes to be released on Tuesday 7 May (hopefully!)

[edit]

Hey all :). Quick update; so, we spent this morning looking at the various options open to us, and processing your feedback.

When we look at non-OBOD options, people seem fairly equally divided; each option has its disadvantages and advantages. If we go with C or D, which are fairly similar in design, we have an issue with persistence - it fades out quickly and so will quite probably get missed. E is persistent, but a non-noticeable colour (and has some additional disadvantages; it's probably not the sort of thing we want to go with long-term, for example, and I don't want to waste everyone's time by having this conversation now only to have to have it in ~3 months again). F is persistent, but not particularly noticeable.

What we've decided is this; the developers (specifically User:Kaldari; big hat-tip to him) are spending today coding several different options; D, in two forms, one which is persistent and one which is not, E, and F. Hopefully we'll have these for release tomorrow as user scripts; people will have the opportunity to play around with them and use them in practise, which I've often found is far more useful for identifying kinks in the workflow or how noticeable they are than simply presenting people with static, contextless mockups. I'll drop everyone a note with the relevant user JS scripts tomorrow, if they get done, I can't think of any reason why they wouldn't, but. and you can pick and match which ones you want to try out.

A couple of things I would like to raise, both before and after that conversation, as discussion points:

  1. One of the issues with options C and D is persistence; they fade out after a few seconds. What would people think of them if they needed to be actively closed, either by clicking on them or going to your talkpage?
  2. Another thing people have brought up as an advantage/disadvantage of various options is whether or not they obscure or interrupt article content - "does obscure article content" being the thing some people aren't a fan of. I'd like to make the argument that, actually, we probably want whatever form of notification we settle on to interrupt users' workflows; we want them to have to stop paying attention to something because, oh! They have a talkpage message. They should check that out. In that regard, interrupting could arguably be a benefit, not a cost. Thoughts?

I'll cross-post to the main notifications talkpage; comments, replies to my discussion points, requests for ponies welcome :). Okeyes (WMF) (talk) 22:10, 6 May 2013 (UTC)[reply]

  • I would like a pony, please! BUT. I see nothing in the above notice about restoring the orange bar temporarily, only opt-in scripts of the various options. You say "when we look at non-OBOD options", as if it doesn't matter that the orange bar got the most support. Do we seriously have to have this whole argument over again, or can you just turn it back on for the meantime? Ignatzmice•talk 22:19, 6 May 2013 (UTC)[reply]
  • There is overwhelming support for returning the orange bar, at least temporarily, if not as a permanent, opt-out, device. Please do so, ASAP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:32, 6 May 2013 (UTC)[reply]
  • +1 to Andy. There appears to be a reality distortion field in play here. -Pete (talk) 22:50, 6 May 2013 (UTC)[reply]
  • This reminds me of a White House press conference... MBisanz talk 23:04, 6 May 2013 (UTC)[reply]
  • To address the OBOD issue: there are a few reasons why the team is not redeploying it; they are first, that they can't just declare a time period to be a deployment window and throw something live on the site: Engineering has controls around what gets deployed and when to ensure that things are possibly tied up. Realistically, the earliest deployment time they could probably get is Thursday, which isn't that far off when they hope to have an enhanced talkpage notifications bar deployed (if it's far off at all - depending on how things go they may deploy on Thursday). At the same time, for the vast majority of users (who are not going to be plugged into this discussion) it will be confusing at best - something being switched off, and then switched on again a week later, and then switched off a few days after that. There are additional reasons why the team considers the OBOD a sub-optimal solution (its positioning, its lack of efficacy, etc) but those are somewhat secondary when it comes to the conversation about turning it on again temporarily.
When it comes to turning it on again permanently, as an opt-in, those concerns have primacy; they are that the design itself violates UI guidelines, that the team has no grounds to believe it's particularly effective (as previously said, it occupies the same space on Wikipedia that 'punch the monkey' ads do on every other site, and internet users tend to be conditioned to ignore things like that), and that the very nature of having it as an opt-in thing causes problems; it's going to be yet another possible interface permutation that has to be taken into account in future design work and products.
I appreciate that a lot of people feel strongly that the OBOD should return, either temporarily or permanently - as I hope I've explained (although you may not agree with me) Product are fairly fixed in their position that this will not be happening. My attitude to this is that if the OBOD isn't coming back (regardless of my personal feelings on the design) it's probably most efficient to engage in the conversation about what will replace it, and test the different designs. Okeyes (WMF) (talk) 23:36, 6 May 2013 (UTC)[reply]
  • This is probably the single most annoying thing I've read from anyone at the Foundation, in ten years of editing. If you have already made up your mind not to return it, why was the orange bar in the options presented for consultation on this project page? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:45, 6 May 2013 (UTC)[reply]
    • Agree. Fabrice, why in the name of any deity or devil you care to name did you include the orange bar in the page you created last night if there was no chance of it coming back? That's not just annoying, that's downright mean. Ignatzmice•talk 23:49, 6 May 2013 (UTC)[reply]
      • Agree, this does not strike me as hyperbole. This is a very serious issue, and most WMF staff commenting on these pages are consistently missing the point -- which leads to the rather obvious conclusion that they are listening to each other, and not paying attention to the very basic things being said here. There is an egregious example of this in Oliver's message above -- the phrase "… and then switched off a few days after that." That is precisely the part of the scenario that is within the control of all involved in the discussion -- WMF and concerned volunteers alike -- and presupposing a boneheaded, second sudden switching-off is completely ludicrous. The whole point is to come up with a smooth transition, the likes of which could and should have been easily planned by WMF from the beginning. The sudden shutoff is precisely the problem we must, can, and will address. -Pete (talk) 00:10, 7 May 2013 (UTC)[reply]
        • Can you give an example then, of how we could smoothly transition between two interface elements in this case? Note, of course, that temporarily re-enabling the OBOD would itself be a transition now. Okeyes (WMF) (talk) 00:14, 7 May 2013 (UTC)[reply]
          • Sure. While there's no non-jarring way to turn it back on (the WMF team axed that possibility a few days ago by not doing it), we can have a little bit of text in the orange bar for a week or so saying it'll be leaving soon. See User:Ignatzmice/sandbox for an example of how it could look. The orange bar would co-exist with whatever new system the team comes up with for a week or two (or until dismissed by the user), advertising Echo the whole time (or until dismissed by the user). Then it would go away, except for those of us who'd keep Writ Keeper's script. Ignatzmice•talk 00:19, 7 May 2013 (UTC)[reply]
            • Except, again, there isn't (assuming things don't go terribly wrong) going to be a week-or-two period. Okeyes (WMF) (talk) 00:21, 7 May 2013 (UTC)[reply]
              • Well thank God the design of this key interface element isn't being rushed or anything, in what is at this point clearly a face-saving "we said we wouldn't go back!" exercise. Rd232 talk 00:29, 7 May 2013 (UTC)[reply]
                • As someone who was in the meeting where the team discussed this, the primary rationale would be that it would create an additional period of inconsistency and uncertainty. It's not being rushed: the team has spent pretty much the last week doing nothing but working on this issue. Okeyes (WMF) (talk) 00:34, 7 May 2013 (UTC)[reply]
          • You can transition most obviously by using new interface elements for new features, so people get used to them, and then eventually get rid of the old interface element for existing features (migrating to the new) some time later, when people are already well used to it. See also Wikipedia:Interface changes. Rd232 talk 00:28, 7 May 2013 (UTC)[reply]
              • Also a good suggestion, for products generally, but I'm not seeing how we can apply it here. The change has already been made; reversing it would effectively be precisely the same problem (although I note that's now what Edokter is doing, for perfectly understandable reasons). Okeyes (WMF) (talk) 00:34, 7 May 2013 (UTC)[reply]
              • (edit conflict) Why can't there be a week-or-two period in which they co-exist, for ease of transition? Ignatzmice•talk 00:30, 7 May 2013 (UTC)[reply]
                • Because from the point of view of most users - I think it's worth remembering that we are not the stereotypical user - that's not aiding ease of transition. First they had A. Then B. Then, very quickly, A and B. Then just B. That's complicating the process even more. At the same time, if what we're looking for is to overwrite muscle memory and have people learn to look to the top right for incoming messages, this doesn't solve for that at all; in fact, it means they don't have to adapt. Okeyes (WMF) (talk) 00:34, 7 May 2013 (UTC)[reply]
                  • the stereotypical user ... First they had A. Then B. Then, very quickly, A and B. Then just B. - give it a rest. The stereotypical user is blissfully unaware of all this, because they've either yet to create an account, or yet to log in again with their existing one. Rd232 talk 00:36, 7 May 2013 (UTC)[reply]
                    • I should clarify; by 'user' I meant 'editor'. Frankly, Rd, your commentary here ("give it a rest") smacks of bad faith. While I understand that there are heightened tensions (trust me, when you spend 10 hours a day working on this problem you get to know there's stress involved) it doesn't aid your argument to make your comments unnecessarily caustic. Okeyes (WMF) (talk) 00:39, 7 May 2013 (UTC)[reply]
                      • There is neither bad faith nor accusation of bad faith against you personally - but your individual efforts to defend an untenable collective decision (i.e. refusal to reinstate OB temporarily) are at times sounding quite desperate. Rd232 talk 00:48, 7 May 2013 (UTC)[reply]

Reply to User:Okeyes (WMF) Indeed. We have been disrupted for several days, and from what it sounds like now it's likely we will be disrupted for several more due to engineering concerns beyond the control of this team. This is all a big deal, and yes, it would have been much better if WMF had done a better job of predicting where this discussion would go and made a move to reinstate the orange bar right away. But relative to 8 or 9 years of the orange bar, it is still the norm that needs to be returned to while we sort out a transition. Even if the engineering concerns do mean it has to be another couple days.

Let me give you an example -- an anecdote. I recently finished teaching a 6 week class on Wikipedia. My most productive student had edited Wikipedia a handful of times over the last 6 or 7 years, with a couple different accounts; but by her self description and anybody else's, she was an almost complete newbie when she started the class. She had a general inkling of how things fit together, but this was her first time adopting the mantle of "Wikipedian" and putting a solid effort into learning something about the site. At times she encountered things that are familiar, at times she encountered things that were not familiar. And her learning process accelerated in the former cases, and slowed in the latter.

Is that hard statistical data? Of course not. But it is genuine experience, it is consistent with common sense, and it is consistent with my experience with countless other students in both online and offline scenarios. Moreover, I would hasten to point out to you that there are very few people on the planet as well qualified to comment on newbies' experience editing Wikipedia than David Goodman and Andy Mabbett. The fact that they are (with no offline coordination, at least that I'm aware of) saying things that exactly mirror my views is not something you should dismiss lightly. Go ahead and keep reading all the WP:IDONTLIKEIT votes against Echo if you find it entertaining, but please spare us the repeated responses to those bad arguments. Please remember that in evaluating consensus, a closing Wikipedian's job is todisregard such arguments and focus on the best arguments. When highly experienced Wikipedia instructors speak with a unified voice, you should be listening.

As for how it may be accomplished, honestly, it is not rocket science, and there are multiple paths to doing it. If your team can genuinely focus on finding a solution, as opposed to defending itself or worrying about whether the criticism is hurting your feelings, you will figure out a way to do it pretty quickly. If not -- hire somebody with expertise in the field. I will be happy to give you a general plan of attack, but really, you should not be looking to someone like me. You should also be paying somebody to do it. Every software maker in history has wrestled with this question as they seek to guide users towards new, different, and better features; there's no point in asking somebody like me, with little experience in software development, to reinvent the wheel. -Pete (talk) 00:38, 7 May 2013 (UTC)[reply]

Pete, I am listening to you. You seem to be confusing "not doing what you want and being persuaded by your arguments" with "not listening". While I appreciate the anecdata provided by you, Andy and DGG, it's just that - anecdata. Anecdata based on a very small number of samples. Your relative experience as instructors is irrelevant, unless you can use that to state with certainty how newcomers generally are likely to approach Echo. I would argue that, in fact, data from instructors is less likely to be helpful than data from actual use, be it quantitative or qualitative: you're trying to generalise what people are paying attention to in a driven, scoped session with a leader figure to what people pay attention to browsing on their own recognizance.
I agree that this situation is a big deal; do not doubt that. I have several regrets about the development and deployment process for Echo, and this is one of them - the team should have done a far better job socialising the more prominent changes, and the most prominent of those more prominent changes is the departure of the orange bar. That it didn't is something that frustrates me, with this frustration being directed at both my bosses for not attaching me more closely to the team, and at myself for not spotting what is, in hindsight, a fairly serious issue in the small amount of time I was given.
The team is focused on finding a solution; you'll note that the person defending the team is primarily me. When I'm not doing that, I'm in meetings with the designers, the developers, the product managers trying to work out the fastest way to get something deployed that does the job (is prominent, is persistent, is unambiguous) that both sides can be, if not happy with, at least not actively infuriated by. Everyone else is focused on that goal for a far greater proportion of their time. I'd join them, but the primary purpose of my job happens to be listening to and interacting with the community.
In doing so, in these discussions in particular, I've noted myself becoming more and more aggrieved by the discussion. Perhaps it's just because I've been spending such a large proportion of my workday (and it's a long workday) dealing with this issue, combined with the justifiable anger from the community, but I've noticed more and more that the focus a lot of people are bringing seems to be less on finding a solution the team will implement and more about venting their outrage at the nearest person (which happens to be me) in the hope that if they just hurl invective fast enough, the Head of the entire Engineering department will change his mind. They may be right; I don't live inside his head. But whether they're right or wrong, I am frustrated to hear you belittle the experience of participating in this conversation, full-time, every single day, and indeed the work I have done to run between the two sides and find a solution that works for everyone, as "worrying about whether the criticism is hurting [my] feelings" - and that you would characterise this as counter to actually finding a solution. That you would do so while simultaneously describing yourself as a highly experienced Wikipedia instructor - someone whose role is, similarly, to provide a shield for people from the less sanitary parts of the community I've been a part of since 2006 - leaves me frankly speechless. Although, evidently, not textless.
Dismiss this as "me worrying about your feelings" if you wish; that is your prerogative. But, here's the rub: when you, and other users, use those developers and product people who choose to interact with the community (which isn't all of them) as anger outlets, and flay them for being fallible, you do not become more likely to get you way in the long term. What becomes more likely is that those people will become even fewer and further between, will consult you less, and will listen to you less, because every legitimate criticism and suggestion is surrounded by a dozen comments assuming bad faith.
This post will undoubtedly provoke strong responses; have fun making them. It's 2am (or, to put it another way, I've been consistently part of this conversation for 12 hours). I'm going to sleep. Those users who have, throughout this, remained positive or posted critiques that avoid ABF and belittlement, thank you for your submissions. Okeyes (WMF) (talk) 00:57, 7 May 2013 (UTC)[reply]
Oliver, I accept that this is all emotionally challenging for you, and I respect it, and I do not want it to be that way. My very simple request is that we (all) keep the very strong focus on what is best for the stakeholders -- the editors and readers of Wikipedia -- not the feelings of the people involved in these discussions (you, or me, or any of us). -Pete (talk) 01:04, 7 May 2013 (UTC)[reply]
I'm confused. A second ago you were arguing that it was essentially black and white; that the heat around this discussion could be addressed or a solution could be achieved. Your attitude is now that you 'respect' how 'emotionally challenging' this conversation is for me. Does that translate to seeking to alter your behaviour to take into account its impact on other people? Okeyes (WMF) (talk) 01:11, 7 May 2013 (UTC)[reply]
I'm going to disengage with the emotional aspect of this. I don't understand this last question, and I'm not sure where it's going. I am genuinely sorry if I have hurt your feelings, that is not the intent of anything I've said. -Pete (talk) 01:20, 7 May 2013 (UTC)[reply]
That it is not the direct intent, I accept, but oblique intent is a worthwhile concept; from my perspective, a lot of your commentary has been very helpful. Some of it has been merely hurtful. That some of it would be hurtful may not have been your core motivation for posting it, but it was so obviously going to be the case that that's hardly a defence. In any case, back to the actual issue we go. Okeyes (WMF) (talk) 01:28, 7 May 2013 (UTC)[reply]
@Okeyes (WMF): I (guiltily) realize I haven't been the coolest regarding this issue, and I apologize. I realize you personally have had little to do with the mess it became. Ignatzmice•talk 01:08, 7 May 2013 (UTC)[reply]
That's fine; apology gratefully accepted :). I of all people understand how frustrating interface changes can be (I'm still on Monobook) particularly when they're not very well socialised. Okeyes (WMF) (talk) 01:11, 7 May 2013 (UTC)[reply]
re: "not listening" -- the thing that leads me to that conclusion is not the outcome, but the fact that numerous WMF staff have repeatedly addressed the worst arguments for reinstating the orange bar instead of the best arguments. The fact that you are now asking me for a software transition plan, as though such a thing were an impossibility, is further evidence. You guys are simply not thinking clearly. It happens to everyone, it does not make you bad people, but in this case the impacts are very broad, and I am eager for you to snap out of your collective reverie. -Pete (talk) 01:20, 7 May 2013 (UTC)[reply]
Not in the slightest; I was looking for ideas I hadn't thought of. Finding a software transition plan is easy; finding one that does not, even temporarily, exacerbate the very problems it's meant to solve for is a harder proposition. I accept the (not insignificant) possibility that we may not be thinking clearly. I would point out that, again, the attitude people bring to these discussions has an impact on the efficacy of people working to solve for the problems. 'you should be focused on solving the problem, not pointing out we're hurting your feelings' is only valid if you assume that people do not become more fallible as a result of assumptions of bad faith and relentless attempts to steamroll the outcome of the discussion. On the 'not listening' - point me to what you see as the best arguments for temporarily restoring the orange bar that I, at least, have not replied to. I will try to address them if I can (although obviously, if I find one that totally stymies me I can't promise that will change the outcome from the team's point of view). Okeyes (WMF) (talk) 01:28, 7 May 2013 (UTC)[reply]
I am not confident that me repeating myself will lead to an outcome that is better by anyone's measure. My suggestion would be to ask an uninvolved administrator to assess and summarize the discussion on Wikipedia talk:Notifications and on Wikipedia:Notifications/New message indicator, and summarize what has been said, where consensus has been reached, and where it hasn't, in a short piece of text that we can all review. The forest fire makes it difficult for any of us to look at outside the lens our own personal biases. -Pete (talk) 01:46, 7 May 2013 (UTC)[reply]
Update: On review, after some rest, I agree that after the decision to not restore the orange bar was revealed, I went a little off the rails. I've struck a phrase I definitely should not have included, above; and in general, I probably should have taken a little more time to respond.
I do still feel WMF is making the wrong decision, both in terms of what is best for Wikipedia editor recruitment and retention, and in terms of evaluating the consensus of people who have participated in this discussion. -Pete (talk) 15:48, 7 May 2013 (UTC)[reply]

Conflicting messages

[edit]

What on Earth is going in here?

  1. "We will either re-deploy the old OBOD to complement the current tool -- or..." - Fabrice Florin (WMF) 21:10, 5 May 2013
  2. "We are aware that the most expedient option would be to re-enable the OBOD, and we are seriously considering that option" - Fabrice Florin (WMF) 21:10, 5 May 2013 (UTC)
  3. "I also really appreciate your overall recommendations to... restor[e] the orange bar of doom temporarily, until we have a better solution. We are taking that advice very seriously" - Fabrice Florin (WMF) 17:14, 6 May 2013
  4. "the team is not redeploying [the orange bar]... Product are fairly fixed in their position that this will not be happening" - Okeyes (WMF) 23:36, 6 May 2013 (UTC)

Please explain. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:20, 7 May 2013 (UTC)[reply]

Further to this point, temporarily restoring the orange bar was also identified as a legitimate option by Erik Möller]; in the intervening time, a poll has been launched, and the results of the poll have strongly supported that as the better outcome. -Pete (talk) 00:57, 7 May 2013 (UTC)[reply]
  • Hi folks, I would like to clarify any confusion about our earlier statements regarding the new message indicators and OBOD. For the past couple days, we have indeed been considering all options listed in this special discussion page, including a possible 'temporary' re-deployment of the the OBOD. This morning, we met as a team to review our options and your feedback. After careful deliberation, we decided that going back to OBOD would be counter-productive, because it would unnecessarily confuse users by re-enabling it as a temporary solution, only to replace it a few days later with something else. We expect to have a better solution in coming days, based on your feedback and on our evaluation of tomorrow's user scripts -- which will let us all respond to interactive prototypes rather than static mockups. As many of you have pointed out, the OBOD option provides an inferior user experience, which will need to be replaced by a better option -- one that can provide similar functionality without violating design conventions and turning off users. We aim to identify this better option in collaboration with the community -- and plan to deploy it as soon as practical. I hope this answers your questions, and look forward to reviewing our new options with you tomorrow, once the user scripts are ready. Thanks for your understanding. Fabrice Florin (WMF) (talk) 01:58, 7 May 2013 (UTC)[reply]
Sorry to hear this, Fabrice. I think the Wikipedians here were being very truthful when they said "take a couple of weeks, get it right and then come back". We meant it. I like the underlying concept here. But even putting in Kaldari's potentially okay solution (which might or might not be workable) still does not solve the really huge issue of diffs, which are present in the OBOD. I've actually stopped looking at the little red number, because it's usually wrong, and it doesn't take me anywhere - and I'm a supporter. The OBOD is not the only problem. You should take two weeks and return with at least the functionality we had a week ago. Risker (talk) 03:06, 7 May 2013 (UTC)[reply]
Risker, while there are certainly some who oppose the new notification framework outright, I think it's safe to say that most people in this discussion are "supporters" of an improved notification system leveraging what has been built. I certainly am. The challenge is not whether or not we forward, but moving forward in a way that works for everybody. -Pete (talk) 16:06, 8 May 2013 (UTC)[reply]
The boat on "unnecessarily confus[ing] users" has sailed. Further confusion will be caused not by going back to the status quo ante (which is familiar, and many users who don't log in regularly won't even have noticed the OB absence yet), but by trying to do new things quickly and quite possibly having to change them repeatedly because they're still not right. I don't know if this is sophistry or groupthink, but this argument of causing confusion by temporary reversion just doesn't wash. Rd232 talk 09:28, 7 May 2013 (UTC)[reply]
  • Okeyes, as one of the editors involved in escalating this issue, I would like to provide my perpective on this issue
  • The first problem we have is the distinct lack of planning from the designing team, both in preparing a viable alternative, as welll as to notify other users of this change. Nothing can be done about it now, so its best to leave this point aside.
  • The primary reason for everyone's urgency is the fact that We need to have an alternative for new users FAST. Its terribly hard right now to communicate with them, and removing OBOD unleashes a plethora of problems for the ones trying to talk to them. Every day wasted in discussions like these without having an interim alternative is a very dear cost for us, especially since a solution does not seem likely in less than a few days.
  • What the general editors do not like or understand at all is why those involved in finding the solution are unwilling to understand the urgency and importance of the above point. You don't want the OBOD at all - Point noted. But why don't you understand that we REQUIRE OBOD or better as a suitable interim alternative IMMEDIATELY?
  • Finally, I agree that pressurizing you guys to work 12-hour days to find a solution is not at all conducive to actually getting close to one. Finding a good solution requires time, patience and lack of pressure. But unfortunately, that seems to be the only working way to make WMF aware of the urgency of our requirements. From a clear cut denial of almost every other statement critical of Echo, we are at the current status quo of trying to find an alternative to the OBOD quickly. We wanted this discussion quick, and the only way you were ready to have them was with guns on you. I'll be ready to accept any other way, provided it works.
TheOriginalSoni (talk) 05:23, 7 May 2013 (UTC)[reply]
+1 Rd232 talk 09:16, 7 May 2013 (UTC)[reply]
That's not my understanding of the situation at all. Let me be clear; I've been working long hours on this since issues were raised. It is not something that requires "guns on me". It is not something that is "the only working way to make the WMF aware of the urgency of our requirements". I've been a volunteer for six years; you're genuinely telling me that you don't think anyone would be listening if people didn't shout and scream? Okeyes (WMF) (talk) 13:42, 7 May 2013 (UTC)[reply]
@Okeyes (WMF):I'm simply looking at the facts, and reading them. On the day Echo was released, there was not a single statement from any of the developers barely hinting there would be any change, forget re-instating the OBoD. Any and every statement we said were simply dismissed as workflow problems and fringe viewpoints. Now we're seeing marginal improvements in what your responses are, and other options are being discussed.
Also, you fail to look into my other points. I've tried to make sure you got our viewpoint that re-instating OBoD or equivalent alternative for the interim is an IMMEDIATE and IMPORTANT priority for us. You don't get it. TheOriginalSoni (talk) 04:37, 8 May 2013 (UTC)[reply]
  • Here is my recommended transition plan. 1. Restore the Orange Bar. 2. The people who took away the Orange Bar learn from their mistake and realize that they shouldn't take away or hide important functions of the site. 3. The rest of us forgive the people who took away the Orange Bar and agree to treat this situation as a learning experience. 4. The Orange Bar gets left in place forever and is never removed again. This avoids any future confusion. --Metropolitan90 (talk) 06:42, 7 May 2013 (UTC)[reply]
I'm guessing its sarcasm, right? TheOriginalSoni (talk) 09:33, 7 May 2013 (UTC)[reply]
No, actually I was being sincere. I was alluding to Fabrice's comment earlier in this thread that "going back to OBOD would be counter-productive, because it would unnecessarily confuse users by re-enabling it as a temporary solution, only to replace it a few days later with something else". I'm one of the users who thinks that the Orange Bar should be re-enabled and kept in place, not replaced a few days later with something else. Yes, forever is a long time, and maybe in the long run there will be something better than the Orange Bar. But in the short run, the Orange Bar is the best solution. --Metropolitan90 (talk) 14:37, 7 May 2013 (UTC)[reply]
I agree, the "…only to replace it a few days later with something else" part of Fabrice's statement is hugely problematic, because it presupposes that the same mistake would be made the second time through that was made the first time. -Pete (talk) 15:58, 8 May 2013 (UTC)[reply]

I'm enabling the popup

[edit]

It is better then nothing. Note that I am not 'siding' with anyone, but I cannot stand by and do nothing. The major concern is noticability of notification for new editors, in whatever shape or form. I do believe that is a valid concern. But while the community and the WMF continue to battle, the problem persists.

This will be a temporary measure until a final solution has been decided on. There should be no interference with testing the WMF prototypes, as the gadget is easily turned off. — Edokter (talk) — 00:36, 7 May 2013 (UTC)[reply]

Well, it's not dismissing even after I've cleared the number, so I'm not sure it's better than nothing. Risker (talk) 01:20, 7 May 2013 (UTC)[reply]
Browser and OS info? It works for me... Ignatzmice•talk 01:22, 7 May 2013 (UTC)[reply]
It should clear once you click on the badge next to your username. — Edokter (talk) — 01:25, 7 May 2013 (UTC)[reply]
I clicked the badge, got the dropdown, went to another page and it came up again. Windows 7, Firefox 20.0.1. Risker (talk) 01:39, 7 May 2013 (UTC)[reply]
Sorry for the late response; I am not getting that problem on with FF 20.0.1 on XP (VMware). Ignatzmice•talk 02:24, 7 May 2013 (UTC)[reply]

Edoktor, thank you for your very timely efforts; I know many people really appreciate it. Unfortunately, I'm not finding this is working for me, and wonder if there is an opt-out. I don't want to sound ungrateful, and I really do appreciate that you've taken the bull by the horns here. Risker (talk) 03:45, 7 May 2013 (UTC)[reply]

it's the first gadget in the Appearance section at Special:Preferences#mw-prefsection-gadgets. Rd232 talk 09:13, 7 May 2013 (UTC)[reply]
But perhaps the wording linking to the documentation does need to be changed. If anyone can come up with something better (like, "Don't want to keep seeing this?" maybe?) an admin can edit MediaWiki:Gadget-Notification.js. Change ONLY the text way over on the right that currently says "Why do I see this pop-up?"—no other code or text surrounding it. Ignatzmice•talk 11:25, 7 May 2013 (UTC)[reply]
  • ... and, sorry, but I'm having the same problem as Risker - it won't dismiss. It works on my laptop (FF19) but not on my work desktop (IE9). (Yeah, I know the fix, just move to FF - except we're locked into IE on our work machines :-/) Black Kite (talk) 13:30, 7 May 2013 (UTC)[reply]
  • To be clear, it does dismiss itself after a short time - then when I navigate to a new page - any page - it appears again. Actually, the red "1" comes back as well - so is this an Echo glitch? Black Kite (talk) 13:32, 7 May 2013 (UTC)[reply]
  • The gadget determines whether or not to show the popup based on whether the element/variable notifyCount is 0 or not-0, and that variable is determined by Echo. So I'm thinking it's an Echo problem. Probably. Does it still happen if you turn off the gadget? Ignatzmice•talk 13:36, 7 May 2013 (UTC)[reply]
That's what I just came back to say - yes, it does. So this is an Echo glitch. I can't dismiss the red "1" by any means (well, I can, by clicking it, but it merely comes back as soon as I change pages). Black Kite (talk) 13:38, 7 May 2013 (UTC)[reply]
  • Hi folks, we'd like to make you aware of some usability tests conducted by our E3 team on the popup gadget which Edokter turned on by default on May 7 (referred to here as the 'Red Badge of Doom' (RBOD). Steven Walling (WMF) ran two initial tests, which are included in video format below. They suggest that users are confused by this gadget, which is disconnected from the red badge and doesn't appear to add much value to their user experience.
  • Clip A
  • Clip B

As Steven points out, the popup helped our two testers see that they had notifications, but they were both were confused by the red in the popup, and thought it indicated there was an error or problem, rather than a neutral notification. Going forward, we would recommend replacing this gadget with a solution that better accomplishes our objectives (prominence, persistence, clarity, consistency and compatibility). We believe that some of the options below could better serve these goals and add more value to the user experience. Therefore, we would recommend that once we replace RBOD with that solution, as soon as we select an option that is generally acceptable to stakeholders. Repectfully Fabrice Florin (WMF) (talk) 19:15, 8 May 2013 (UTC)[reply]

It has always been the intention to remove the popup the instance a suitable replacement has been deployed. — Edokter (talk) — 19:19, 8 May 2013 (UTC)[reply]
Two testers? Steven claimed just a couple of days ago that my experience with two groups of trainees, the smaller of which was double the size of that sample, was too few from which to draw a conclusion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:32, 8 May 2013 (UTC)[reply]
These two testers only commented on the red popup. They are not associated with any other test group that is testing any MWF-sponsored solution. — Edokter (talk) — 19:36, 8 May 2013 (UTC)[reply]
Still, this might (might) be a reason to consider making the popup persistent, though that would be a very heavy-handed solution. You said you could make it persistent, but you couldn't change the time until it vanishes? Seems to me ~15-20 seconds might be better than the ~6 it is now. Ignatzmice•talk 19:43, 8 May 2013 (UTC)[reply]
mw.notify is very limited; the only option available is {autoHide:false}, which makes it persistent (but dimissable by clicking on it), otherwise it will disappear in five seconds. — Edokter (talk) — 19:59, 8 May 2013 (UTC)[reply]
Y'know, if it was dismissible by clicking that might be okay. Though like someone said a while ago (forget where) it's useful to have an X or something so they know they can... Ignatzmice•talk 20:04, 8 May 2013 (UTC)[reply]

The bigger issue here: Javascript

[edit]

I know - I really do know - that all of the folks at the WMF are really trying to make the user experience better by creating a lot of these changes. However, they're developing for Western users with big, fast, expensive computers and excellent internet connections. All this javascript is ruining the user experience for people with old slow computers and slow, expensive internet connections. Pages are taking longer and longer to load (I'm even having trouble on large pages with a lot of .js on them when I'm editing from an older, slower computer), and time is money for our colleagues in the less developed world or who can't afford the latest technology or the high-speed connections that are common in North America and Europe.

It's time to stop and really rethink all of this. Making things pretty for us here on Enwiki is probably not worth the longterm harm that is starting to show in projects from smaller language groups and the less developed world. I really would like to see our developers focusing on building in ways that will minimize the time that it takes to load pages, and with an eye to expecting that, outside of a few "big" projects, most editors will be using technology that is at least 5 years old. Editing Wikipedia shouldn't be the bailiwick of the rich. Risker (talk) 23:15, 6 May 2013 (UTC)[reply]

+1 (which I'm typing on my 15-inch MBP with Retina. It was a gift from the grandparents, okay?). Ignatzmice•talk 23:36, 6 May 2013 (UTC)[reply]
Totally agreed; I think it's a conversation that needs to be had (about how we go about providing our editing experience). Having said that, I'd note that enwiki itself is not representative of MediaWiki, and that a lot of the damage is likely to be caused not by Foundation changes but by user changes. I think we all have our common.js or [skin].js pages, which adds to loading time, and this is true of not just us as individuals but the site as a whole - user contributions to the javascript load for enwiki currently total 17kb for common.js, plus more for individual subelements (although to be fair, it's worth noting that (1) kb is a poor way of measuring performance and (2) some of those scripts do include contributions from WMF devs, albeit, I think, in their personal capacity). Okeyes (WMF) (talk) 23:40, 6 May 2013 (UTC)[reply]
All of the Javascript for Echo is bottom-loading. It has virtually no effect on the render speed of pages (for rendering the actual page content). And the JS that loads the red badge (after the page content has loaded) is absolutely tiny. It's 511 bytes. Not kilobytes, bytes. Javascript has been a standard technology of web browsers since 1996. I'm not sure I understand how Westerners are more likely to have JavaScript than non-Westerners. Indeed, I strongly suspect the opposite is true since there are far more old computers in the West. Kaldari (talk) 23:46, 6 May 2013 (UTC)[reply]
It's a fair issue to raise, but this isn't the place for it, especially as Kaldari has now pointed out the low impact of Echo. Unfortunately, there's no obvious good alternative location - which is really part of this problem, isn't it? Rd232 talk 00:05, 7 May 2013 (UTC)[reply]
Kaldari and Okeyes, you're missing my point. I have completely empty .js and .css pages, and one of the reasons I wiped out all the scripts is the noticeable effect on load times. (The other being how they tend not to work properly with each other.) Yes, I can tell the difference. It's also the reason I don't use Vector on this project, because it's loaded with javascript, and when I'm on a slow computer I regularly crash out on it whenever I load a big page. Now that I'm spending more time at Meta, and editing bigger pages there, I'm probably going to have to move to monobook there too, just to avoid the same problem. And that's here in North America, with fast internet. Sure Echo only uses a little bit, and another UI element is a bit more, and a third adds more, and someone keeps using those funny little elements on a page that crank it up a bit more each time. It all adds up. Sometimes I think you guys should all be required to write your code on 5 year old computers using dial-up, then you'll be darn sure to make the minimal impact on load times.

Growth areas for Wikimedia projects are outside of the western world where we have top technology and excellent internet. If the WMF is to continue to grow, you need to be building in a way that makes the interface work well in the absence of the latest technology. Risker (talk) 00:13, 7 May 2013 (UTC)[reply]

I'm not entirely sure how your argument addresses what I said at all. My argument was not, primarily, that your common.js page was the issue; it was that site JS was a substantial issue (although you may want to make sure that you've actually wiped out your JS.
I totally agree that it adds up; I get that. I'm not, to be honest, entirely sure how we're going to address it, although it's something I've been thinking hard about for a couple of weeks now - I can't promise a solution right now. But I'd argue we ultimately have to balance the need to maintain a broad base with the need to utilise that base properly; one requires instantaneous load times ideally, the other requires the neatest and most perfectly calibrated features possible. There's a middle ground we have to find: I'm not disputing that. If you read what I wrote, you'll note I never denied you were bringing up an important issue. Okeyes (WMF) (talk) 00:37, 7 May 2013 (UTC)[reply]
Good grief, more bloody pages where .js and .css hide? I thought I'd got them all eons ago. Thanks for the pointers, Okeyes.

I think the problem is that this website has two possibly quite conflicting goals: it wants to look good for readers, and it wants to be easy to edit. Over the last few years, the focus has been on making things look good, which has cost a significant amount on making it easy to edit. When new editors click the "edit" button, they're pretty unlikely to stick around for 5-10 second load times for pages with lots of code and templates. We don't lack for readers. We need editors, in every language. VisualEditor is a step in that direction, but it's still pretty slow in my experience. I suppose rewriting Vector is out of the question? Risker (talk) 01:29, 7 May 2013 (UTC)[reply]

The VisualEditor itself uses substantial amounts of JS; it's very difficult to efficiently implement some of the things we need in any other way. I'd argue that, actually, a lot of our changes have been focused around editing: Notifications is intended to provide additional functionality for editors, for example, not a prettier way of doing things that can already be done. Okeyes (WMF) (talk) 01:30, 7 May 2013 (UTC)[reply]
I'm vaguely aware of all kinds of tech efforts to get things loaded only when needed by the user, and as late as possible (after page content). That's probably the only way to square the circle. Suggestions for where to move this discussion to ....? Rd232 talk 00:51, 7 May 2013 (UTC)[reply]
Reliance on JavaScript also has other issues: What you end up with is almost always usable by fewer people. Web developers need to think more carefully about how blind users will use the site when using JavaScript, else the page becomes hard or impossible to use with screen reader software. You are far more likely to run into browser compatibility issues when using JavaScript (and it is impossible to test with every browser out there). On Wikipedia we often have problems where scripts stop working for some users due to glitches in user scripts, gadgets and old scripts stuck in browser caches. Hence, core functionality such as talk page notifications should not rely on JavaScript.
Personally, I browse with JavaScript disabled because there are so many websites out there that use JavaScript in annoying ways (I include Wikipedia in that category). Furthermore, there is a security advantage to disabling JavaScript since many browser security vulnerabilities involve JS. (On server editions of Windows, Microsoft disable JavaScript by default in Internet Explorer for security reasons [1].) – PartTimeGnome (talk | contribs) 22:21, 7 May 2013 (UTC)[reply]
I've said much of the same in other threads, but PartTimeGnome summarizes most of my concerns succinctly and eloquently in their first paragraph. Sophus Bie (talk) 07:01, 8 May 2013 (UTC)[reply]
+ 1, every developer should read unobtrusive JavaScript first before going on with developing anything else anymore which always relys on JS. There’s so much on Wikipedia, that can’t be used anymore with old browsers and old JavaScripts (because it’s just not compatible anymore with newer JS versions).
  1. No notification bars anymore (you don’t see new messages, if you don’t go and look for them yourself or regularly look at the blue number on top)
  2. There’s no way at all to add, change or remove interwikis at Wikidata except for removing the revert button (if anyone has added the interwiki before that you want to remove), because it isn’t possible to edit the pages directly there and there’s also no special page for adding/removing/changing interwikis. It is the same as if the pages were protected, you always have to ask another editor to change or remove interwikis. Or if you want to add any, you put them into a related article in another language version and let the bots add the interwiki (or ask another user to do so). But you haven’t any chance to change any interwiki yourself at all. You would have to revert an interwiki that was added before (to remove it) and then add another interwiki in a related language version.
  3. You can’t use at all the new translation interface, so you have to go round and look for the right translation message with Special:PrefixIndex and edit it directly which is more difficult and time comsuming, and you also have to know this way first which is described and explained nowhere. There’s no way to edit easily anymore, so you won’t do translation edits normally very much, cause it’s just too difficult.
  4. If you press the watch button, then the whole page disappears and a text appears instead that the page has been added to the watchlist. Then you have to load the page again. That’s not very comfortable, but at least you can add something to your watchlist (so better than Wikidata interwikis). But if you turn an old JS version on, then you even can’t add anything to or remove anything from your watchlist, then you can only do this, if you edit the page and press the button „Watch this page“ or vice versa. --Geitost 23:28, 18 May 2013 (UTC)[reply]
  • Comment - I'm late to this debate, but it's not only developing countries that are adversely affected. Many of the more remote parts of the UK (which includes where I live) have either unreliable or inconsistent connections/connection speeds, or barely have broadband at all. And I'd imagine that a similar issue exists for some parts of the USA and most other developed countries as well. Lukeno94 (tell Luke off here) 08:52, 19 May 2013 (UTC)[reply]

Prototypes released

[edit]
NOTE: The red popup (see Wikipedia:Notifications/Popup documentation) is not part of this test.
NOTE: Some of these prototypes may not yet work well in skins other than Vector.

We've now got the user scripts that prototype various replacements/enhancement for the OBOD and the Echo flyout finished (credit to User:Kaldari. Add the lines of code in brackets to your common.js files, try them out!

Those available:

  1. Option D, fading out: importScript('User:Kaldari/bluealertfade.js');
  2. Option D, no fade: importScript('User:Kaldari/bluealertdismiss.js');
  3. Option E, not animated: importScript('User:Kaldari/topalert.js');
  4. Option E, animated: importScript('User:Kaldari/topalert2.js');
  5. Option F: importScript('User:Kaldari/toolbaralert2.js');
NOTE: these prototypes are now available in your Gadgets preferences, down at the bottom.


Please test them and give any feedback you have; as said, I'm particularly interested to see the reaction to option D when it has persistence (option 2 above). I'll be honest with you and point out that direct user feedback from you, while an important factor in the teams considerations, is not going to be the only data point. It's plausible that users could come out in favour of one particular option and not get it. Okeyes (WMF) (talk) 14:06, 7 May 2013 (UTC)[reply]

Just to illustrate the "why are we rushing forward instead of taking a step back and surveying the path ahead" issue: are we even sure that red is the best colour for the Echo number badge? Red (particularly that sort of shade) indicates a sort of urgent! danger! message, which is not really appropriate. Once we have a way of getting people's attention for things that are likely to need rapid action (esp talkpage messages, which need reading), is that colour actually appropriate for the range of other notifications? Pagelink notifications are nice, but hardly critical. We could have different colours or different "ooh, look here" stylings (icons?) for different kinds of notification. If we weren't rushing to fix the talkpage message problem (which we could so easily do by bringing back OB for a month or two max), we could explore ideas more broadly that might be better for the system overall. Even if that exploration led to the exact same outcome, we'd collectively be surer we had a good outcome. Rd232 talk 14:28, 7 May 2013 (UTC)[reply]
I'm not sure how any of that relates to the thread, but: we do have different iconography within Echo, certainly, for different kinds of notifications. In terms of showing different icons in the general UI when different kinds of messages have appeared, User:Vibhabamba (pinging) is the person to talk to. I would note that it risks creating endless permutations - there will, in the long term, be a lot of different kinds of notifications - and the headache of 'what to do when someone has multiple kinds of notifications waiting for them' is one I'm glad won't be my responsibility if this idea is explored. Okeyes (WMF) (talk) 14:32, 7 May 2013 (UTC)[reply]
HI Rd232! Red in small quantities is a color that is known to trigger activity. Danger is probably a strong word in the web world, red is more suggestive of something that needs attention and hence should be used in small quantities only. It is also a spot color that is effective in your peripheral vision. There is a solid amount of color theory and research to back us up here. This is also evident from the usage of red in other systems such as IOS and other web applications. I'm not sure I understand the iconography comments and their relationship to the red, we have also not heard concerns in this vein from any other user. Vibhabamba (talk) 07:35, 8 May 2013 (UTC)[reply]
Well these kind of issues of how to get the best out of the new notifications system is why I was so totally taken aback that the talkpage messages (the only old notification, if you see what I mean) was put in there as well at this fairly early development stage. Instead of delight with new toys that need improving but are already useful, we've much pain (for users and developers!) about the issues of replacing the old toy. Rd232 talk 14:38, 7 May 2013 (UTC)[reply]
Indeed. Okeyes (WMF) (talk) 14:41, 7 May 2013 (UTC)[reply]
(ec) Purely on a colour scheme level, orange is more complementary to blue than red... And keeping the colour of the Orange Bar at least would support continuity. Rd232 talk 14:34, 7 May 2013 (UTC)[reply]
Rd232, I agree with you here in terms of continuity. I even proposed the orange, but the context and space available must be taken into account. The issue here is two fold. ( First lets note that on a color spectrum orange lies between red and yellow )

Issue 1 is the state of the navigation, the text is really small and hence the badge cannot be much larger than the type size of the links. I would love to make these larger, but that is a separate micro design project 2. Orange is small chunks is less saturated than red and is far less prominent. 3. Even if we were to make the element larger, we dont have any space on top. Margins in the top right nav are tight if not non-existent. We will have more people missing the badge with a color that doesn't work in spot amounts for your peripheral vision. This has been adequately tested and unless we have a huge visual element, both an orange and a yellow will not work. Vibhabamba (talk) 07:45, 8 May 2013 (UTC)[reply]

Oh, totally, on the complementary front. On continuity, I'm not sure what the point of that would be from a UI perspective - unless we're taking the attitude that people are more likely to associate orange with messages - in which case that's perfectly correct, but people will eventually have to learn to pay attention to notifications (and it sort of undermines the "this is necessary for newbies" argument - which is a good argument, but one that speaks more towards building something prominent, I think, than anything else). Okeyes (WMF) (talk) 14:38, 7 May 2013 (UTC)[reply]
  • I think this is probably the same "doesn't dismiss" bug you're already working on, but just in case it's not: using no-fade Opt D, my red speck doesn't go away even after I click on the blue bar and land on my talk page (using firefox, fwiw). Also, someone get Kaldari a beer and a long nap for hacking these all together so quickly! A fluffernutter is a sandwich! (talk) 14:33, 7 May 2013 (UTC)[reply]
    I think he may already be taking the nap, at least ;p. Yep: known bug, hopefully to be fixed soon :/. Okeyes (WMF) (talk) 14:34, 7 May 2013 (UTC)[reply]
    Kaldari napping? That's a critical bug right there! ;) Rd232 talk 14:35, 7 May 2013 (UTC)[reply]
    Ok, having played around with these, I'm officially a big fan of option 3 (aka Option E, no animation). D is sort of awkward the way it covers tabs, and F is just godawful (its animation deployed at glacial speed across my top bar. 'Ne *pause* New *pause* New m *pause*"...). A fluffernutter is a sandwich! (talk) 14:47, 7 May 2013 (UTC)[reply]
  • Is it possible to develop this so it actually has the links it's notifying us about? See, here's my thing - the OBOD was a one-step process to accessing the talk page. The red pipe took it to a two-step process. Adding this nifty new notification now makes it a three- or four-step process. I click the new notification, and all it does it tell me to go over and look at the red pipe notification. It doesn't even tell me what kind of notification this is - talk page, or something else. There's no link therein to click. Then I click the new notification to make it go away (maybe some offered above automatically dissolve on their own). Then I go over to the red pipe and click it to find out I have a talk page message, and have to click again to get to the talk page. So, at minimum, that 1-step process has become a 3-step process, and maybe a 4-step process, just to know I have new messages and to access them. Appreciate what you're trying to do, but please simplify. — Maile (talk) 15:15, 7 May 2013 (UTC)[reply]
    Can you clarify what you mean here? I'm using option E (on vector), and when a notification comes through that, it includes (inside the notification) a link to my talk page and a link to the diff of the change. If I recall, if you're using option D, clicking the blue bar will take you to your talk page. No diff on that one, though. Same for clicking the words in option F. So I'm not sure what you mean when you say that there's no link or way to get to your talk page in these. A fluffernutter is a sandwich! (talk) 15:29, 7 May 2013 (UTC)[reply]
  • I tried E and F, and just now tried it again to make sure I wasn't imagining this. I'm in Modern Skin. Maybe it's how it reacts with Modern??? There is absolutely nothing in the message except that it tells me I have a notification.— Maile (talk) 15:32, 7 May 2013 (UTC)[reply]
  • That's very strange. And clicking on it doesn't take you through to anything? Okeyes (WMF) (talk) 15:35, 7 May 2013 (UTC)[reply]
  • Well...everything is working fine now. The short of it - I prefer F. The reason nothing was happening, is that the alert wasn't showing up. I was just looking at the default now in play. Don't know why. But I just tried again, and everything is fine. Yes, it was very strange. — Maile (talk) 17:46, 7 May 2013 (UTC)[reply]
  • Just received my first talk page notification via the new script and, for my own use, I have no problems with it. If IP and new user notifications are being discussed elsewhere then disregard the following; talk page notifications for IPs and new users need to be much more conspicuous and the notification needs to stay on the user's screen until they visit their talk page. If there is discussion regarding notifications for IPs and new users is taking place in another location, could someone please direct me? Thanks. Tiderolls 15:28, 7 May 2013 (UTC)[reply]
    Which script? Okeyes (WMF) (talk) 15:35, 7 May 2013 (UTC)[reply]
Options. Goody. When I get home from work I'll get back to ya. Tiderolls 15:37, 7 May 2013 (UTC)[reply]
Cool :). Yep, we wanted to get feedback on as many options as possible before settling on one, to make sure we weren't missing anything. One possible conflict is that people are now getting the honking red gadget by default :/. Okeyes (WMF) (talk) 15:42, 7 May 2013 (UTC)[reply]
I thought that might be a small problem. I'll add a note at the top here. — Edokter (talk) — 15:55, 7 May 2013 (UTC)[reply]
I am getting that conflict, so at the moment I cannot really judge the different versions. Actually I am fine with the honking red gadget, but I can see experienced users would not want something so loud and for new users it needs greater persistence that I am seeing at the moment.--SabreBD (talk) 15:56, 7 May 2013 (UTC)[reply]
You can turn of the honking red popup in Preferences > Gadets. They should not conflict in functionality; you only run the risk of getting two popups. — Edokter (talk) — 16:12, 7 May 2013 (UTC)[reply]
Extended content
*I've got absolutely nothing from any of these. I'm normally in modern but went to vector and monobook to test 'em so there'd be no other scripts imported, and nothing in either skin. Will it only work for new notifications? Or maybe some other pref I have set?

{ "query": { "userinfo": { "id": 141948, "name": "Amorymeltzer", "options": { "ccmeonemails": 0, "cols": 80, "date": "mdy", "diffonly": 0, "disablemail": 0, "disablesuggest": 0, "editfont": "default", "editondblclick": 0, "editsection": 1, "editsectiononrightclick": 0, "enotifminoredits": 0, "enotifrevealaddr": 0, "enotifusertalkpages": 1, "enotifwatchlistpages": 0, "extendwatchlist": "1", "fancysig": "1", "forceeditsummary": "1", "gender": "unknown", "hideminor": 0, "hidepatrolled": 0, "imagesize": "0", "justify": 0, "math": 0, "minordefault": 0, "newpageshidepatrolled": 0, "nocache": 0, "noconvertlink": 0, "norollbackdiff": 0, "numberheadings": "1", "previewonfirst": 0, "previewontop": 1, "rcdays": 7, "rclimit": "100", "rememberpassword": 0, "rows": 25, "searchlimit": "30", "showhiddencats": "1", "showjumplinks": 1, "shownumberswatching": 1, "showtoc": 1, "showtoolbar": 1, "skin": "vector", "stubthreshold": 0, "thumbsize": "0", "underline": "1", "uselivepreview": 0, "usenewrc": "1", "watchcreations": 1, "watchdefault": "1", "watchdeletion": 0, "watchlistdays": "7", "watchlisthideanons": 0, "watchlisthidebots": 0, "watchlisthideliu": 0, "watchlisthideminor": 0, "watchlisthideown": 0, "watchlisthidepatrolled": 0, "watchmoves": "1", "wllimit": "500", "useeditwarning": "", "flaggedrevssimpleui": 1, "flaggedrevsstable": "2", "flaggedrevseditdiffs": true, "flaggedrevsviewdiffs": "1", "vector-simplesearch": 1, "vector-collapsiblenav": 1, "usebetatoolbar": "", "usebetatoolbar-cgd": "", "aftv5-last-filter": null, "wikilove-enabled": "", "echo-subscriptions-web-page-review": true, "echo-subscriptions-email-page-review": "1", "ep_showtoplink": false, "ep_bulkdelorgs": "1", "ep_bulkdelcourses": true, "ep_showdyk": true, "echo-notify-show-link": true, "echo-email-frequency": 0, "echo-subscriptions-email-system": true, "echo-subscriptions-web-system": true, "echo-subscriptions-email-other": false, "echo-subscriptions-web-other": true, "echo-subscriptions-email-edit-user-talk": true, "echo-subscriptions-web-edit-user-talk": true, "echo-subscriptions-email-reverted": "1", "echo-subscriptions-web-reverted": true, "echo-subscriptions-email-article-linked": "1", "echo-subscriptions-web-article-linked": "1", "echo-subscriptions-email-mention": "1", "echo-subscriptions-web-mention": true, "variant": "en", "language": "en", "searchNs0": true, "searchNs1": "1", "searchNs2": "1", "searchNs3": "1", "searchNs4": "1", "searchNs5": "1", "searchNs6": false, "searchNs7": false, "searchNs8": "1", "searchNs9": "1", "searchNs10": "1", "searchNs11": "1", "searchNs12": "1", "searchNs13": "1", "searchNs14": "1", "searchNs15": "1", "searchNs100": false, "searchNs101": false, "searchNs108": false, "searchNs109": false, "searchNs446": false, "searchNs447": false, "searchNs710": false, "searchNs711": false, "searchNs828": false, "searchNs829": false, "gadget-teahouse": 1, "gadget-ReferenceTooltips": 1, "gadget-HotCat": 1, "gadget-DRN-wizard": 1, "gadget-charinsert": 1, "gadget-Notification": "", "gadget-mySandbox": "", "gadget-CommentsInLocalTime": "1", "gadget-PrettyLog": "1", "gadget-RegexMenuFramework": "1", "gadget-ShowMessageNames": "1", "gadget-Twinkle": "1", "gadget-addsection-plus": "1", "gadget-contribsrange": "1", "gadget-metadata": "1", "gadget-modrollback": "1", "gadget-revisionjumper": "1", "nickname": "~ <font color=\"#F09\">Amory</font><font color=\"#555\"><small> ''([[User:Amorymeltzer|u]] \u2022 [[User talk:Amorymeltzer|t]] \u2022 [[Special:Contributions/Amorymeltzer|c]])''</small></font>", "pagetriage-lastuse": "20130314032414", "userjs-curationtoolbar": "hidden", } } } }

  • Hi folks, thanks for taking the time to test some of these user scripts, we really appreciate it! Based on overall feedback, we would like to develop one of these scripts as part of the Echo extension, and aim to deploy a first version by the end of the week (or early next week), if possible. Your comments are most helpful today, so we can start development in a timely manner, at least for the basic feature set. The objectives remain prominence, persistence, clarity (disimbiguate messages from other notifications) and consistency (with our UI goals and best practices). If you haven't already, we recommend that you turn off the 'Red Badge of Doom' gadget during testing, so it doesn't confuse your user experience with two similar gadgets appearing at the same time. To do this, simply go to Preferences > Gagdets… and uncheck this first preference for RBOD in the Appearance section: '[ ] Display a popup when you receive a notification. (Documentation)'. Click 'Save' to disable RBOD. Note that whatever version we select, there will be opportunities to tweak it in coming weeks. Also, this is intended to be a 'temporary' solution, until we have time to develop a longer-term solution, such as Option H: Separate badges, which would provide separate flyouts for notifications and messages. Thanks again for getting back to us so promptly with your thoughts on these options! Fabrice Florin (WMF) (talk) 16:33, 7 May 2013 (UTC)[reply]
    • Also, this is intended to be a 'temporary' solution, until we have time to develop a longer-term solution... - anyone who's followed these discussions is likely to find that assertion mindboggling. Tell me again why going back to OBOD was and is not a viable temporary solution, allowing more time to get the long-term solution right without interim skips and jumps, more time now to fix bugs with other aspects, and not working developers to death? On the upside, the "separate badges" idea looks promising. Rd232 talk 16:46, 7 May 2013 (UTC)[reply]
      • Because, if they switch back, people might decide they actually prefer the old feature, and then how will the Foundation employees look good on their performance reviews if they don't have any highly visible changes to point to? --108.38.191.162 (talk) 21:24, 7 May 2013 (UTC)[reply]
  • Okay, my observations:
D: does not work in Monobook. It puts my username and talk links on a new line above all the other links, and I can barely see the tip of the blue triangle.
Is pretty easy to overlook in Modern, as it's similar in color to the two sections directly above it.
Does not work in Cologne Blue. Because the links are on the side, all I see is "new talk page" and then half an "s".
E: Is very noticeable in Cologne Blue (especially, because of the contrast) and Vector
Is smaller in Monobook and Modern, and in addition the X-circle is covers up part of the "last changes"
F: barely works in Modern. It splits into three lines as it spools out, then eventually settles on two. In addition, there isn't enough contrast between the dark and light blue.
Does not work in Cologne Blue. It ends up being on four lines, and the next line's highlighting covers up half of all but the last one.
Is kinda jerky to animate in all skins, but especially Monobook.
Keep in mind these are prototypes. They work best in Vector for testing purposes. I'm sorry I didn't have time to debug in the other skins yet :( Whatever we end up implementing, I'll make sure it is usable in all the skins. Kaldari (talk) 18:33, 7 May 2013 (UTC)[reply]
My favorite is E (not animated), provided the font size can get beefed up in Modern and Monobook. I especially like that it follows you down the page, can be dismissed, and then comes back on next load. And that it shows up even if you load halfway down the page! E is definitely The One for me. Ignatzmice•talk 17:42, 7 May 2013 (UTC)[reply]
Thanks for the feedback. Sorry I hadn't checked the font size in the other skins! Kaldari (talk) 18:36, 7 May 2013 (UTC)[reply]
Understood they're prototypes, but I still think E (animated or not, doesn't particularly matter) has the most promise. Ignatzmice•talk 18:38, 7 May 2013 (UTC)[reply]
  • Just for fun: importScript('User:Kaldari/nerdalert.js'); Kaldari (talk) 18:36, 7 May 2013 (UTC)[reply]
  • I share Rd232's puzzlement that you are bothering to spend time and effort developing a temporary fix when reverting to OBOD until you had a permanent solution seems a simpler way to avoid all this fuss; but I can tell that we can ask for that until we are blue (or orange) in the face without result, and from Okeyes' " It's plausible that users could come out in favour of one particular option and not get it" I get the vibe that minds have already been made up on this one, too. However, you did ask us, so I've tried them all (even NerdAlert), using Vector.
Definite first preference: D, no fade. If the D-fade option is chosen, the delay should be slightly longer, 8 - 10 sec vs. the present 5 or so. I don't like the colour and would much prefer the same orange as the late lamented OBOD, as both more conspicuous (I think the people who complain of it being "obtrusive" are missing the point of a warning template: it's meant to be conspicuous!) and providing continuity of user experience from OBOD. I don't like E or F, and I didn't observe any animation about E-animated except that it was rather slow to arrive. JohnCD (talk) 22:19, 7 May 2013 (UTC)[reply]
  • After further tests I hold the same opinion as before. Any will work for me but IPs and new users should have something much more conspicuous and no "How to disable this popup" option. Before I block someone that could possibly be informed and helped, I would like them to have a chance to understand that communication is imperative. Tiderolls 23:01, 7 May 2013 (UTC)[reply]
    Er. What disable option? Are you using the user gadget? Okeyes (WMF) (talk) 23:03, 7 May 2013 (UTC)[reply]
The notification messages I received contained a link with that message. I did not click on it to see where it led. Tiderolls 23:09, 7 May 2013 (UTC)[reply]
That link leads to Wikipedia:Notifications/Popup documentation. It was turned on for all users (though IPs don't see it) to make sure they REALLY notice the Notifications system. Ignatzmice•talk 23:11, 7 May 2013 (UTC)[reply]
Yeah. It's not, however, part of the test. Okeyes (WMF) (talk) 23:12, 7 May 2013 (UTC)[reply]
I suppose my vector.js history is visible to you. Maybe I borked copy and paste. Pray for me if that's the case. Tiderolls 23:14, 7 May 2013 (UTC)[reply]
No need to wikilink! That'd probably do it, though I'm not sure. Ignatzmice•talk 23:16, 7 May 2013 (UTC)[reply]
  • Just posting here 'cause there's an ongoing conversation involving admins: If someone could update the MediaWiki:Gadgets-definition file by adding |rights=minoredit immediately after "default" and before the closing bracket in the popup's line (first under Appearance), that would keep it from loading for IPs, who wouldn't see it anyway. Quicken up their load times just a little tiny bit. Keep it all on one line! Ignatzmice•talk 23:21, 7 May 2013 (UTC)[reply]
  • This is a useless experiment, and arguing about the details is not constructive. There was unambiguous consensus about what to do, which is to revert to the RBOD, and then run some tests and see what the community thinks. I could explain why all over again, but if what has already been said multiple times by multiple people has not convinced those responsible for this fiasco I think we will have to discuss how to get the community decision to be effectual. I made some comments last week about doing it, but people kept assuring us that it would be fixed by Tuesday... DGG ( talk ) 06:04, 8 May 2013 (UTC)[reply]
hi DGG, What do you think the RBOD solves for? Its got two critical issues. 1) red in such large amounts makes is look like an error. 2) It disappears before anyone can read it. If it persists it obfuscates content. Can you outline the merits of the RBOD? Thanks Vibhabamba (talk) 07:51, 8 May 2013 (UTC)[reply]
I gather most people see it as orange; so do I, but I seem to think of it as red. We mean the same thing. It has at least the one virtue that it is thought by everyone here to be noticeable. the stridency has in fact often annoyed me, & I agree we can do better. (and I think fwiw that we overdo the use of garish color throughout WP, but that's another discussion.) I'm talking about a temporary fix--certainly once it's returned we can properly consider alternatives that will have the same key virtue, and improve on it.The error was in implementing one without testing or consensus. The reason to return it immediately rather than discussing alternatives first is that its virtue of noticeability was so critical, that we should take our time to evaluate others. Having made the error of removing it, it may not have been wrong to discuss others for a day or two just in case everyone did like something suggested, but as this is about to enter the second week, it's clear we have no immediate alternative agreed solution and we need one, while we discuss it. DGG ( talk ) 19:11, 8 May 2013 (UTC)[reply]
A humble opinion: From reading this thread, I feel like we have lost objectivity on the user experience problem here. What are the core issues that we want to fix? Do we really need to be so attached to an existing solution or a new one? Do we feel like this is the best use of so many people's time? Interface elements need to do their job and get out of the way. We removed the orange bar because we want to build a more cohesive system, where the orange bar or something like it was connected to the 'Talk' link in the top right nav. Why? Because thats the right thing way to design and build. We lost prominence of the talk notices because of this and we are trying to fix it, but we want to make sure that it is still a hollistic solution.Vibhabamba (talk) 08:03, 8 May 2013 (UTC)[reply]
I'd like to suggest that someone be selected to review and summarize the discussion on these various pages about notifications, to help us all develop a shared view of what has been said, and where there has or has not been consensus. This conversation was unmanageable and difficult to follow several days ago, and it's only gotten worse. I'd suggest picking somebody with the following qualities:
  • Familiar with English Wikipedia's past implementation of the orange bar
  • Familiar with English Wikipedia's policies and decision-making processes
  • Has not followed this topic previously
  • Active Wikimedian whose primary focus is on a project other than English Wikipedia
  • Does not and has not worked for the Wikimedia Foundation
  • Known and respected by several active participants in this discussion, including both WMF staff and non WMF staff
I believe this step will help bring a discussion that has become scattered and heated back in a direction that is useful, and to a point where those whose wishes are not reflected in the final outcome will respect the decision nonetheless. This is something we all have experience with as wiki users, and it's important that we have an outcome like that here. If anybody knows a different path to it than reflection on the merits of what has been said to date, I'm all ears. -Pete (talk) 15:24, 8 May 2013 (UTC)[reply]
  • While serious in my choice, I thought I was being silly. Now I see that There is an option G listed on the page, and it is the OBOD. Why wasn't that option listed? When was it added? --Onorem♠Dil 16:32, 8 May 2013 (UTC)[reply]
  • As you can see from the discussion further up, there was an option G on the last page; like at the RfC, it was the overwhelming favorite; like at the RfC, that made no difference to the WMF team (despite their having said that it would). This section is for testing and discussing further options, like it or lump it; and having decided not to lump it, I am liking it. Ignatzmice•talk 16:44, 8 May 2013 (UTC)[reply]

Prototypes are now gadgets

[edit]

You can now try out the prototypes without having to install any user scripts. Just go to Special:Preferences#mw-prefsection-gadgets and scroll down to the "Testing and development" section. Be sure to uninstall any of the prototype user scripts first :) Kaldari (talk) 18:00, 8 May 2013 (UTC)[reply]

Thanks, Kaldari! For those of you who want to test these, be sure to clear your caches after you install a gadget. You will also need to send yourself a message from a separate account. As long as you don't click on the message indicator, you can switch between different gadgets and still see the new indicator.
Here are the options that Kaldari has posted so far:
  • Talk page alert prototype D1 - blue tooltip, fades out
  • Talk page alert prototype D2 - blue tooltip, dismissible
  • Talk page alert prototype E1 - orange bar, floating
  • Talk page alert prototype E2 - orange bar, docked to top
  • Talk page alert prototype E3 - orange bar, docked to bottom
  • Talk page alert prototype F2 - inline toolbar message, animated, blue highlight
Let's all evaluate their respective merits against these goals:
  • Prominence (users should be able to notice they have new messages)
  • Persistence (users should be reminded if they do not check messages)
  • Clarity (disimbiguate from other notifications)
  • Consistency (with our UI design goals and best practices)
  • Compatibility (with popular browser and skins)
We will aim to summarize our options in the next few hours, and propose some steps towards resolving this issue together in coming days. I also think that Pete's idea of getting an uninvolved and experienced community member to do the same would be helpful, towards a shared assessment of the current situation and our next steps. We also invite you to join today's IRC office hours chat at 20:00 UTC, where we can have a live discussion about our next steps.
Discussion topics will include:
  • Overall impressions about notifications tool
  • Message indicator to replace Orange Bar of Death (review different options)
We will post another update soon. Thanks for your patience throughout this process! Fabrice Florin (WMF) (talk) 18:20, 8 May 2013 (UTC)[reply]
Thanks for addressing my suggestion, Fabrice. Are there any steps you can take to reach out to somebody to review the discussion here?
At the moment I don't feel comfortable participating in the IRC discussion or evaluation of the options presented. Judging from their sharply reduced participation, I think that several other previously active participants feel the same. I believe that Oliver may not be the only one taking some kind of break from addressing the specifics, as it has been a rather tense experience. I still believe it is important to get the site back to a point where it functions in a way that is familiar to tens of thousands of users, while those few of us in this discussion get our story straight and take whatever time is needed to agree on an acceptable path forward. -Pete (talk) 18:37, 8 May 2013 (UTC)[reply]
Hi Pete, thanks for your response. I have reached out to Philippe Beaudette to get his advice on your proposal. I appreciate that we are all feeling a bit burned out by this long discussion, and understand your reasons for not participating in the IRC chat. We will aim to structure the next round of wiki discussions a bit more, to focus more on the general goals we seem to agree on (prominence, persistence, clarity, consistency and compatibility), and see if we can arrive at a solution that addresses these goals more effectively. Look forward to continuing this next discussion after we receive more guidance from neutral but experienced observers. I want to re-iterate that we are not married to any specific solution now, and want to find the solution that best meets our shared goals, regardless of our individual views. Fabrice Florin (WMF) (talk) 18:56, 8 May 2013 (UTC)[reply]
The refusal to restore the orange bar, as a temporary measure, while we calmly discuss alternatives, with no time pressure, is the worst case of clear consensus being ignored that I have seen in ten years as an editor. It shouldn't need an independent reviewer to point that consensus out. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:11, 8 May 2013 (UTC)[reply]
I endorse what Andy said. I'm curious--presumably any dev could restore it if they wanted it, and not all of them work for the foundation. DGG ( talk ) 19:15, 8 May 2013 (UTC)[reply]
I agree, it shouldn't need anything special to establish this basic point. But the fact remains that nobody from the Editor Engagement Team has acknowledged/asserted that there was a decision to ignore clear consensus. As long as there's disagreement on that point, we're going to have a really hard time doing anything about improving the software without getting a lot of people upset. I think it's important to have a clear agreement from all sides on what has happened, including why the EE Team considers itself empowered to make that decision. Do you have any suggestions about how to get there? I'd be willing to read the analysis of a qualified and independent Wikipedian, which might help my own understanding of what has happened; and it sounds like Fabrice is willing to, as well. To me, that seems like a strong step in the right direction. -Pete (talk) 20:44, 8 May 2013 (UTC)[reply]

Alright, having tried them again my money's still on E; specifically, in order, E3, E1, E2 (though the text for the "docked" versions should be black, not white). E1 is too messy/hidden up there with the logo and stuff. D and F aren't noticeable enough. And, again, I am concerned about the JavaScript aspect—but I'll limit my comments to the options provided. Ignatzmice•talk 19:00, 8 May 2013 (UTC)[reply]

I have not gone away, but I am not going to comment on options until we reverse the basic error, because to do so gives some degree of legitimacy to the procedure. Possibly others feel similarly & have stopped commenting--or perhaps they have stopped in disgust at the unresponsiveness of the people who made the change. DGG ( talk ) 23:08, 8 May 2013 (UTC)[reply]
+1. (a) this whole thing has become just too depressing that I want to be involved any further right now and (b) I've no idea to what extent my input to this process would be valued and (c) the discussion has become a bit messy and unstructured. The initial page laying out the prototypes was very well laid out, but now it's wandered off into IRC and messy free-flowing comments and I don't know what. Mostly (a) though.Rd232 talk 23:31, 8 May 2013 (UTC)[reply]
Once again, G is left out. If G is not an option, take it off the fucking page. --Onorem♠Dil 23:13, 8 May 2013 (UTC)[reply]

Quick update

[edit]

I'm happy to report that we had a very productive conversation in today's office hours chat on IRC about the new message indicator. Many thanks to community members who joined this discussion -- especially Edokter and Ignatz, who made some invaluable contributions to move this project forward (see this more complete update).

Together, we reviewed proposed designs for message indicators, and discussed how each option serves our goals (prominence, persistency, clarity, consistency and compatibility). We then brainstormed a new version 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).

Notifications-Message-Indicator-OptionF2-Toolbar-Alert-Orange-Screenshot-Closeup-05-08-2013

In collaboration with community members, our developer Ryan Kaldari and designer Vibha Bamba made live changes to our prototype gadget for Option F2. After testing that revised gadget, 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. 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.

We encourage you to try out this new solution for yourself: go to Preferences > Gadgets and scroll down to the "Testing and development" section, then select 'Talk page alert prototype F2'. Be sure to clear your cache after you save your preferences (and uninstall any of the earlier user scripts from your '<username>/vector.js' file). You may also need to post a message on your talk page from a separate account to test it.

Please let us know what you think. 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 would like to move on to other important tasks, such as supporting HTML email notifications. Thanks again to Edokter, Ignatz and other community members for their creative suggestions -- and for helping reach a compromise that meets our shared objectives. Tomorrow, I will update the new message indicator page to better reflect where we are in this development. Fabrice Florin (WMF) (talk) 01:12, 9 May 2013 (UTC)[reply]

Fabrice also posted the above to Wikipedia talk:Notifications#IRC chat update. I've already replied there. To avoid this discussion becoming further fragmented, I suggest responses to Fabrice's update go there. Thanks. – PartTimeGnome (talk | contribs) 01:22, 9 May 2013 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Notifications/New_message_indicator&oldid=1099641319"