Help talk:Notifications/New message indicator

What's the rush?

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)

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)

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)

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)

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)

Update: Alert box near name (E) is persistent

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)

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)

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)

• Thanks, Fabrice. I've updated my thoughts accordingly. Whee, this ability to ping each other by linking usernames is sort of fun, iin't it... A fluffernutter is a sandwich! (talk) 18:19, 6 May 2013 (UTC)
  • Fun? You could say that. Writ Keeper ⚇♔ 18:21, 6 May 2013 (UTC)
• Thanks for updating your comments on Option E, Fluffernutter and Risker! Our goal is to provide user scripts for the most promising options tomorrow, so we can try them out for ourselves without being forced to deploy just one idea. Oliver will post an update about this plan shortly. And yeah, I too love this ability to mention each other by linking usernames -- it seems really effective for supporting collaborations of all sorts on Wikipedia, and is bringing us closer to each other in a really productive way :) Onward! Fabrice Florin (WMF) (talk) 20:56, 6 May 2013 (UTC)

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

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)

• 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)
• 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)
• +1 to Andy. There appears to be a reality distortion field in play here. -Pete (talk) 22:50, 6 May 2013 (UTC)
• This reminds me of a White House press conference... MBisanz ^talk 23:04, 6 May 2013 (UTC)
• 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)

• 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)
  • 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)
    • 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)
      • 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)
        • 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)
          • 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)
            • 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)
              • 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)
                • It's not being rushed: the team has spent pretty much the last week doing nothing but working on this issue. - Facepalm Rd232 ^talk 00:42, 7 May 2013 (UTC)
        • 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)
          • • 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)
            • (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)
              • 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)
                • 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)
                  • 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)
                    • 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 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)

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)

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)

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)

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)

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)

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

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)

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)

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)

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)

Conflicting messages

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)

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)

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

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)

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)

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

+1 Rd232 ^talk 09:16, 7 May 2013 (UTC)

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)

• 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)
  • "Forever" is a long time... I see no reason to think the Orange Bar can't be improved upon. Rd232 ^talk 09:16, 7 May 2013 (UTC)

I'm guessing its sarcasm, right? TheOriginalSoni (talk) 09:33, 7 May 2013 (UTC)

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)

I'm enabling the popup

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)

• Go for it. Ignatzmice•talk 00:30, 7 May 2013 (UTC)

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)

Browser and OS info? It works for me... Ignatzmice•talk 01:22, 7 May 2013 (UTC)

It should clear once you click on the badge next to your username. — Edokter (talk) — 01:25, 7 May 2013 (UTC)

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)

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)

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)

it's the first gadget in the Appearance section at Special:Preferences#mw-prefsection-gadgets. Rd232 ^talk 09:13, 7 May 2013 (UTC)

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)

• Um, now it says "How disable this popup?" - presumably should be "How do I..."? or "How to..." Black Kite (talk) 13:22, 7 May 2013 (UTC)

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

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

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

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)

The bigger issue here: Javascript

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)

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

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)

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)

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)

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)

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)

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)

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)

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)

Prototypes released

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');)

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)

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)

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)

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)

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

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)

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

  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)

  Kaldari napping? That's a critical bug right there! ;) Rd232 ^talk 14:35, 7 May 2013 (UTC)