Help talk:Notifications/Archive 3

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

→

Archive 8

Don't like the default zero.

I don't like the default zero messages "notification". I would prefer that the notification button didn't show when there is no messages. In addition, when I do get messages I can't read them properly, but this may be because I use the Cologne Blue skin and not the default. Regards, Iselilja (talk) 05:37, 6 May 2013 (UTC)

Hi Iselilja, due to the limited design and development bandwidth we are able to optimize visual design for Vector and perhaps Monobook, a lot of the visual design work for new components will be optimized for these skins and I would encourage use of these for best user experience; Its also not easy to create a clean crisp design for so many skins with the front end limitations of Mediawiki Vibhabamba (talk) 18:20, 6 May 2013 (UTC)

The only reason there is a zero button is in case you want to re-visit any of you recent notifications that you've already seen. Otherwise there would be no way to get to them other than manually going to Special:Notifications. Kaldari (talk) 03:59, 7 May 2013 (UTC)

Does the zero need to be in a grey box? Perhaps that's just the price I pay for using Monobook. HJ Mitchell | Penny for your thoughts? 08:56, 7 May 2013 (UTC)

"Best user experience"? I thought that the reason different skins were chosen was to improve the experience, for that user. Apteva (talk) 13:31, 12 May 2013 (UTC)

Apparently not. They've already got rid of several of the much loved (by some) old skins, and the plans are to get rid of anything that isn't Vector in due course. You have been warned. An optimist on the run!   12:06, 13 May 2013 (UTC)

Given that most power editors use Monobook, I very much doubt it's going anywhere for a very long time. I would consider Vector and Monobook fully supported, as Vibha says. --MZMcBride (talk) 05:28, 19 May 2013 (UTC)

I don't like it either. Nightscream (talk) 00:13, 18 May 2013 (UTC)

Office hours chat on IRC

Hi guys, we invite you to join today's today's IRC office hours chat at 20:00 UTC, when we will be hosting a live discussion about Notifications and our next steps.

We propose to cover these topics during this hour-long IRC chat:

• Project update
  • Key features released last week (badge, flyout, archive, preferences)
  • First notifications (welcome, talk, reverts, reviews, links, mentions)
  • First stats (dashboard and survey)

• New message indicators
  • Background
  • Goals (prominence, persistency, clarity, consistency and compatibility)
  • Possible solutions (options D, E, F -- see note below about prototypes)
  • Orange Bar of Death (OBOM) / Red Badge of Doom (RBOM)

• Next steps
  • Resolving message indicator issue
  • Upcoming features (e.g. HTML Email)

We invite you to try out the prototype gadgets we created for key options. 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 (if you had any), then 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 we have 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)

We will aim to summarize our discussions later today, and propose some steps towards resolving this issue together, based on your feedback.

We will post another update soon. Thanks for your constructive comments for helping improve notifications. We know there are still issues, and are working around the clock to address them as quickly as possible. To be continued ... Fabrice Florin (WMF) (talk) —Preceding undated comment added 19:57, 8 May 2013 (UTC)

IRC chat update

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

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

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 emails. Thanks again to Edokter, Ignatz and other community members for all their creative suggestions -- and for helping reach a compromise that meets our shared objectives. Onward! Fabrice Florin (WMF) (talk) 00:34, 9 May 2013 (UTC)

What happened to your goal of compatibility? It's a bit rich to say this meets all of your goals when you've just changed your goals... Talk page notifications need to work on all browsers regardless of their configuration, to avoid giving people excuses for ignoring talk page warnings. As I understand it, what you're planning will only work if the browser supports JavaScript. As a compromise, could you at least restore the old orange bar for non-JavaScript users and users of screen readers, so everyone will get a talk page notification of some sort? – PartTimeGnome (talk | contribs) 01:08, 9 May 2013 (UTC)

The current prototype uses javascript, but once it is integrated into Echo, there is a good chance the notification will be HTML-only (using javascript only for the animation). The chosen layout allows for this, as it sits inside the document flow and not in some popup. — Edokter (talk) — 01:20, 9 May 2013 (UTC)

That's excellent news, thank you! – PartTimeGnome (talk | contribs) 01:24, 9 May 2013 (UTC)

• I think E1>D1>D2 overall, especially given the concern for (new) editor awareness. E1 really provides that obvious/obnoxious feedback. Any of the Es would be okay, but E1>E3>E2. F2 is, I agree, an elegant solution. The animation makes it abundantly obvious but it's not so annoying as to irritate too many people. I'd sooner see a fade-away on it similar to D1 but it's a very solid framework. ~ Amory (u • t • c) 01:39, 9 May 2013 (UTC)

• I like it, but I cannot stand the animation. Just leave it static like the OBOD. — Ganeshk (talk) 03:51, 9 May 2013 (UTC)
• I too cannot work with animation on any web page. If I cannot immediately turn it off, I must immediately scroll the page to hide it , which is a nuisance, or I cannot read the text or even stay comfortably on the page. This is a question of accessibility. Animation, blinking, and similar visual devices should never be used in the interface to a site. The color is OK-- but restricting it to the navbar makes it too small. It will be noticed better if it were separate, just like the old bar. Some people seem to like animation, I notice, but this is so utterly wrong for a minority that it really shouldn't be considered as the basic way. Whatever we decide, it would be good to have a gadget to personalize it--there is no worry about the inexperienced users, for they never think of adjusting their preferences. (I have the turn off animation button set in my gadgets, but it does not seem to turn off all animations that people use. ) and the comment about js is very much to the point--we don't want a "good chance" we want to avoid js to the degree possible at least for basic features. DGG ( talk ) 06:07, 9 May 2013 (UTC)
  • If you have the 'no animation' gadget enabled, this notification should not animate. (If it does, I need to fix the gadget.) — Edokter (talk) — 09:07, 9 May 2013 (UTC)
  • What does "animation" mean? If it's a blinking orange bar, that's extremely problematic for a subset of users. I won't bother to explain why here. Truthkeeper (talk) 10:38, 9 May 2013 (UTC)
    • "Animation" means that the navbar starts out with just "Username, notificationsbox, sandbox..." and then the orange "talk" thingie scrolls out right-to-left between the notificationsbox and the sandbox links. No blinking or flashing or anything. You can try the gadget if you want (let me know if you need a test on your talk page). Ignatzmice•talk 11:45, 9 May 2013 (UTC)
      • • Thanks, I'll probably ping you later - off to work right now. Blinking would be terrible, movement is an less of an issue but still suboptimal (I always click out of user pages with animation) so would like to see how quickly it moves. Truthkeeper (talk) 11:53, 9 May 2013 (UTC)
• (edit conflict) I think this is a really nice solution, thanks to everybody contributing to it! Regarding the animation: that's pointless for me, since the interface is semi-animated anyway, on the same time scale, due to the loading of the clock gadget and Twinkle. At the moment the 'no animation' gadget doesn't seem to turn the animation off, but I guess that's fixable (and it's not a big deal anyway).

If people think there's still too many new editors who miss their messages, we can think more about a second line of defense similar to the Prompt me when entering a blank edit summary feature. After all, it's not really important that people notice their messages as fast as possible, as long as they notice them before (successfully) submitting another edit. — HHHIPPO 10:42, 9 May 2013 (UTC)

Um ... animation is very much a big deal for some and if the developers aren't aware of this, they should be. Truthkeeper (talk) 10:45, 9 May 2013 (UTC)

Sure, it should be fixed, what I meant by 'no big deal' is 'no reason for a big drama calling for an immediate rollback'. To answer your previous question: it's not blinking, it's just appearing in an animated way, similar to what Libre Office calls 'peek in from left'. — HHHIPPO 11:14, 9 May 2013 (UTC)

• Hi folks, thanks for your constructive feedback about this proposed feature! I'm glad to hear that this new version of F2 seems to be an acceptable solution for you overall, with a few more tweaks. On the issue of animation, I share some of your concerns, largely for compatibility reasons: on slow machines and on tablets like the iPad, the animation is too slow to be practical. So I am going to propose to the team that we try a version of the gadget without animation, so we can all look at it together and determine our next steps. If that new 'static' version seems to work well, we could provide it for slow processors and tablets -- or possibly for all platforms. But let's take it one step at a time. Sound good? Thanks again to everyone who collaborated productively to finding this solution: we couldn't have made this much progress without the active participation of community members like you! Fabrice Florin (WMF) (talk) 16:25, 9 May 2013 (UTC)
• Well, it's better than F, which hides in the scenery of the page like a stick insect in a bush. This is an orange stick insect in a bush. That's my problem with it - it's still in the bush. For newbies, we need something that obviously is not bush. (Not a political comment - note small 'b'...) The colour intensity will be similar to the blue of Modern, but newbies will mostly be on the wishy washy Vector skin, as, by the time they discover skins, they'll either have discovered communication or be blocked anyway. A newbie oriented indicator needs to be where it's not expected. Away from a row of little buttons or words. Peridon (talk) 17:13, 9 May 2013 (UTC)

I hope that whatever choice is made by those making it (seemingly not us...), it will capable of being turned off. I don't want animated orange boxes and definitely not flashing ones. The red pimple is fine when you get used to it. It's not the established editor that needs blatant warning. As to the idea I saw somewhere in one of these threads of having red and green pimples for different types of notification - remember R-G colour blindness. Peridon (talk) 17:20, 9 May 2013 (UTC)

Not focusing on the animation issues, this fits most of my suggestions, so I am pretty happy. My only real issues are that it perhaps not large enough to be prominent for new users and that, as mentioned above, that those that want to can turn it off.--SabreBD (talk) 18:02, 9 May 2013 (UTC)

• Hi DGG, Hhhippo, Ignatz, PartTimeGnome, Peridon, Sabrebd|, Truthkeeper and other contributors to this discussion: I am happy to report that Ryan Kaldari has modified the F2 gadget to turn off the animation, as requested by many users on our talk page -- and to address the compatibility issues with slow platforms and tablets like iPad. What do you think? From our perspective, it appears that the orange bar continues to make this indicator very prominent, even without the animation. So if it works for most of you, we'd like to go ahead with this implementation for now (we can always tweak it later). Special thanks to Edokter, who was kind enough to replace his temporary RBOD gadget with this new F2 gadget, which we we created in collaboration with him and other IRC participants. And thanks to the rest of you for helping us make such rapid progress on this feature! Fabrice Florin (WMF) (talk) 21:50, 9 May 2013 (UTC)

• Orange, good; non-animated, good; still on the small side (and I am still mutterring that people who think it should not be "obtrusive" have forgotten the purpose of a warning sign); but I can live with this one. (My concern all along has not been about noticing warnings myself, but about whether newbies I send messages to will notice them). Thanks. JohnCD (talk) 22:26, 9 May 2013 (UTC)

I pretty much agree with JohnCD. I am happy not to have the animation (which was clunky on my laptop), but it was never really about what I see, but how clearly a warning is communicated to new users.--SabreBD (talk) 22:31, 9 May 2013 (UTC)

Thanks, JohnCD and Sabrebd|. Glad this new version works for you. If anyone doesn't like it and would like to turn it off, simply go to Preferences > Gadgets and scroll down to the "Appearances" section, then uncheck 'Alert me when I receive messages on my talk page. (new)'. Next week, we plan to make it part of the Echo extension and offer a preference for it as well, as described in this feature requirement. I'm happy that by putting our heads together in a constructive way, we were able to find a reasonable solution to this issue that seems to address your concerns. To be continued .... Fabrice Florin (WMF) (talk) 22:47, 9 May 2013 (UTC)

I like the new little orange bar; it seems less ominous than the OBOD. I just have two concerns, one for newbies and one for myself:

• It does need to be more prominent not only for IPs but also for new accounts (and autoconfirmed wouldn't be a high enough threshold, since many users go for hundreds of edits before ever being welcomed, warned, or otherwise engaged with).
• I would very much like the notification to go away after I've opened my talk page. Having to click on the Echo thingy as well is an extra step—not a huge deal but I suspect over time it would become an annoyance, especially on days when there's a lot of traffic on my talk page. Rivertorch (talk) 22:59, 9 May 2013 (UTC)

• Hi Rivertorch, I am glad that you like our new little 'Orange Bar of Love' (OBOL) -- which more and more folks I talk to seem to be growing fond of as well. Regarding your first point, we are now providing welcome and getting started to new users right away, and plan to add more notifications beyond that, so they will quickly learn to use the red badge and message indicator, which they are already accustomed to on all major top sites except Wikipedia; so bear with us for a little while longer, as we unfold our plan for engaging users more effectively from the start. We totally agree with your second point about removing the orange bar of love after you've viewed your talk page -- this is a high priority bug we hope to fix very soon. Now that we have reached a resolution on the message indicator issue, we're getting back to work on all the other issues on our plate, and this one is topmost on our minds. Thanks again, and stay tuned for more ... Fabrice Florin (WMF) (talk)

I too think its an improvement over what you did earlier, though not as good as the original--my own idea of what was needed was to reduce the size a little. The main feature I find lacking is that it does not seem to go directly the difference page that shows all the new messages--sometimes people will send e messages to things a little up on the page, & I have to go into the history to find them. DGG ( talk ) 03:41, 10 May 2013 (UTC)

(@ Fabrice Florin) Glad to hear a fix is in the works. Thank you. I admit to being a little worried when you say "we are now providing welcome and getting started to new users right away". I'm not sure what I may have missed in that regard, but I hope we haven't embarked on a scheme to indiscriminately welcome all new users. One of my pet peeves around here is the use of standard welcome templates for users whose only contributions have been vandalism. I have taken multiple editors (most of them relative newbies themselves) to task for doing that. Rivertorch (talk) 06:21, 10 May 2013 (UTC)

• Still not convinced. It's a massive step ahead of the original Echo solution, but I still see primary consensus for bringing back the OBOD, and still feel it's the best solution. As many said, it didn't have to come back in orange, but it's still by far the best option, and seems to simply be being ditched because it's "old". If it ain't broke, don't fix it - and that wasn't broken. Now, this new solution is fine for me (although not my preferred solution), but for IPs and inexperienced editors, whom don't know what they're looking for, it still isn't enough. Lukeno94 (tell Luke off here) 07:13, 10 May 2013 (UTC)

IPs do get the OBoD. For new editors, we should gather some actual experience on how well the new system works, and then see what to tweak or add. — HHHIPPO 08:22, 10 May 2013 (UTC)

• I find it very nice, enough to catch your attention, but in nice style as well. I think it's better than the original orange bar (which I voted for in the RFC above). Mohamed CJ (talk) 20:02, 10 May 2013 (UTC)

more generally

• 3 questions (I'm addressing it to Fabrice, because he's taking the lead at the moment, but I really am asking this in common to everyone involved in programming the notifications system or the interface in general):

1. Why did you guys not think of doing this sort of inquiry before you introduced the change? Was it because you thought the merits of your first solution so obvious you knew it would be accepted, or that you had tested it yourself as well and as broadly as the community could have done, or you though the details of presentation-- as distinct from the underlying programming -- didn't really matter? Or perhaps that the time saved in getting something to work without further discussion was so important that the extent we liked the actual interface could be ignored?

2 For the other features you are working on, are you going to consult us first with an adequate pilot before introducing it, or are you going to again assume you can do all that is needed just as well yourself, and see what is the feedback later? Are you going to consult broadly, or do it on IRC? Are you going to let the community decide when it has consensus, or decide it yourself?

3 what is the relative importance to your satisfaction with your work: your own pleasure in it, the approval of the officials at the WMF, the approval of the part of the community likely to complain, or the benefit to the makers and users of the encyclopedia?

These questions are really more important than this particular feature; I think much of the outrage wasn't over the deficiencies of the feature itself, but the lack of prior consultation--of indeed of any consultation, had we not forced it on you (at least, that's how it appeared to some of us). I, and I think others, measure the degree to which you have understood by your willingness to address these points. I, and I think others, feel a little distressed you had not addressed them voluntarily much earlier. I'm not one to go by reluctantly extracted confessions of remorse, but I don't know if that is saving face, or the intent to ignore the community as much as we let you. DGG ( talk ) 04:36, 10 May 2013 (UTC)

Yes, good points. Discussions on IRC are all very well, if you use IRC and keep to PST hours... Peridon (talk) 10:15, 10 May 2013 (UTC)

Seconding/thirding these questions! Changes after changes in notification system! The OBOD (Orange Bar of Dignity/Dedication/Demonstration) was really very good! --Tito Dutta (contact) 07:26, 11 May 2013 (UTC)

Yes, these are important questions. -Pete (talk) 19:33, 13 May 2013 (UTC)

• Hi DGG., Peridon, Pete and Tito Dutta. Thanks for asking these questions, which I think can help us establish a better mutual understanding -- and pave the way for more effective software releases in the future. I've answered them briefly below, and I look forward to discussing them in more depth with you by phone tomorrow.
  

Q1. Why did you guys not think of doing this sort of inquiry before you introduced the change?

A: As we do for all of our software tools, we reported regularly about the development of the Notifications tool and its upcoming release on the English Wikipedia, over a wide range of communications channels (e.g.: here on en-wiki, mediawiki.org, blog, on-wiki newsletters, email updates and IRC). We are grateful for all the guidance we've received from community members throughout the past six months, and appreciate their invaluable contributions to the development of this tool. We have also repeatedly invited users to test the product in advance on MediaWiki.org. Since no significant issues were reported during this extensive testing period, we did not expect the removal of the OBOD to cause the strong reaction we have witnessed in recent weeks. At the same time, we had heard numerous concerns from many community members that the so-called 'Orange Bar of Doom' was not the most effective way to inform people of new messages, and our own observations confirmed that this legacy feature was poorly designed and violated widely accepted web conventions. When we reviewed best practices on other top sites (see research slides), it became clear that new design patterns such as the use of a red badge for notifications have now become the norm and match user expectations more closely than OBOD. So it seemed reasonable to deploy this new implementation first, then address any community concerns after everyone had a chance to try out the new tool. There was no malice on our part, it was largely a practical decision.

Q2. For the other features you are working on, are you going to consult us first with an adequate pilot before introducing it?

A: We always strive to get community feedback about features we develop, as we have in the past -- and our pilot for Notifications has been running on MediaWiki.org since December 2012 (though it's worth noting that few of the English community members who have posted on this page took the time to test it on that site and give us advance feedback). In most cases, it is not practical for the WMF to create special pilots for every feature we develop on every site we support -- nor is realistic to get prior community approval before we deploy these features. Instead, we aim for a more agile development approach, where we deploy new beta features quickly to production sites like the English Wikipedia, where users can test them more easily -- we then adjust these features through rapid design iterations based on user feedback, as we did last week with the new message indicator feature. And while we appreciate the consensus principle, it is primarily intended for editorial and social processes -- not for the MediaWiki software platform which powers our sites. In fact, community members explicitly added this exception, which states that 'the community of MediaWiki software developers, including both paid Wikimedia Foundation staff and other volunteers, … [may] operate however they deem necessary or appropriate, such as adding, removing, or changing software features, or accepting or rejecting images, even if their actions are not endorsed by editors here.' This is not a new observation: MediaWiki development has always been a distinct process, and there's always been some amount of (usually constructive) tension between the technical and editorial community, as appears to be the case now.

Q3. What is the relative importance to your satisfaction with your work: your own pleasure in it, the approval of the officials at the WMF, the approval of the part of the community likely to complain, or the benefit to the makers and users of the encyclopedia?

A: Personally, I consider all of the above factors as part of my work, but the most important by far is the overall benefit to all users of MediaWiki projects. In the past year, we have paid particular attention to the needs of new users, to invite productive participation that might offset the active editor decline that is jeopardizing the growth of our movement. In order to better engage these new users, we are now actively modernizing the MediaWiki software platform and user interface, a process that is likely to last several years. To that end, WMF teams are continuously developing and releasing new features and tools, as well as retiring old features which no longer serve their purpose effectively. We realize that this process can seem disruptive for many current users, and we regret this inconvenience. But in today's world, we all need to become more comfortable with change, particularly in the digital space, where user interfaces are constantly being improved at a rapid pace. Rest assured that we will continue to inform the community and invite feedback about upcoming changes -- and we will keep looking for better ways to involve community representatives at key milestones during software development. But the Wikimedia Foundation still needs to reserve the right to make independent decisions about its software releases, because it has to serve many stakeholders beyond the English Wikipedia, and cannot effectively develop different local solutions for every feature it releases on every single site which it supports. With that in mind, we would be very grateful for your cooperation when we make changes which you didn't get a chance to discuss or do not agree with. Thanks for your patience and understanding. Fabrice Florin (WMF) (talk) 20:15, 14 May 2013 (UTC)

• Hi, Fabrice Florin (WMF), thanks for answering these questions! I have started feeling that some editors like User:Double sharp, me are being misunderstood for our negative feedback. But, I want to tell you, though our feedback have been negative, actually we are trying our best to provide constructive opinion on the tool. It is unfortunate that our feedback have been negative. But, believe me, we also care for Wikipedia very much like others here, so, our aim has never been to criticize you/developers without any reason. Next time, you add (some other) new exciting features and you'll definitely find "us" "wholeheartedly" congratulating you and celebrating the feature/tool at first.
  On Q1, do we have an editors' team of "Trusted Testers", please see Suggestion 3 here. If you roll out a critical new feature like this to some trusted editors before making it public, they can give initial reactions.I have been a trusted tester of Google and Gmail for a long time now. I wish I could tell you my experiences there, but, I can't due to the NDA (Non disclosure agreement). Anyway, TT's feedback might be very helpful. --Tito Dutta (contact) 20:39, 14 May 2013 (UTC)
  • That's a good suggestion :). I know that Erik (Eloquence) is very keen on the idea of deploying things in a beta on enwiki, in future, rather than testing elsewhere; hopefully this will allow us to discover problems 'natively' before they become a problem for many users. Okeyes (WMF) (talk) 20:49, 14 May 2013 (UTC)
• It is highly disingenuous to present Wikipedia:Notifications as part of some sort of open and frank consultation on what you were doing, when it did not mention removal of the orange bar until 1 May, and only then after that was added by a member of the community, not WMF staff. Where, if anywhere, else was this loss announced in advance? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:02, 14 May 2013 (UTC)

Unexpected! --Tito Dutta (contact) 23:33, 14 May 2013 (UTC)

Response

Fabrice, I'm not sure you understand the complexity and motivations of the WP editing community. The volunteers are self-selected for eagerness to work in a chaotic setting with unknown colleagues, none of whom can be compelled to work in a predictable way on a predictable project, and who can & do walk away any time they feel unwanted or uninterested. The volunteers have come here very specifically so they can work in that fashion, and will always resent people here trying to tell them how they must do anything, regardless of whether they are reasonable or unreasonable. This poses certain limitations, but its inherent in the existence of WP. Even for those things that we know the staff can do better, & I agree that designing interface is one of them, we want to feel not just that they are acting in our interests, but that they are acting as our agents and subject to our approval--at least in the things that primarily concern us as editors. (I think we know that for aspects primarily concern the readers, we editors in general have no particular expertise other than guesswork.) We are not likely to change: if we were prepared to accept things imposed on us other than by our own choice, we would not be here: we know better than anyone the great inefficiencies of our methods, but are here deliberately to take part in a very large scale effort to see how good an influential a resource we can make using them--and by now we have the reinforcement of having been successful beyond any expectations. I & many of us have worked -- and I hope successfully -- in much more conventional settings. We intend this to be different.

Nor do I think you understand the way to communicate here. Almost all of us do our work on this Wikipedia, not on meta or the mailing lists. Many of us, as you will have seen, resent anything not totally open and widely broadcast, as a potential cabal. There are too many places for announcements for any one person to track, but we have evolved some relatively good methods , such as site notices. It's hard to judge what is worth such broad notice, and I think you did not anticipate this, not realizing the already very weak nature of inter-editor communication.

Relatively few of us are particularly interested in technical or organizational issues. We are, rather, here for either creating content, or dealing with the surrounding functions (screening & evaluating submitted material, guiding new editors, copyediting and reformatting, constructing infoboxes, categories & other structural features, resolving disputes, protecting against disruption). Within the general anarchy, we've evolved patterns of effective work, and we know our patterns are very unstable, and are concerned that the best-intentioned and best-planned alterations will result in destruction. Stability in a tenuous structure like WP is a very delicate balance.

We know there must be improvements in many things; if we did not eagerly seek innovation we would hardly even have thought of coming here. But it is never possible for even the most experienced here to predict what will happen on WP, and what changes will be accepted. the only way of accomplishing things is by trial--and repeated patient trial. We will not accept trials we do not know about imposed from outside, and many trials we do know about will be judged unsuccessful. Some things go much too slowly, but it is impossible to force them. This example proves it: you and your staff have by now spent several times as much effort explaining and modifying after the fact as you would have needed to do had you consulted and trial;ed very widely before it. And the response we have received indicates to me -- and probably many of us -- that you still do not understand: you are looking for ways to do things efficiently, but we regard business-like methods as unfriendly. Nor do I think we will really accept the decisions of an elite group, as some have suggested. It is part of the basic approach here that we think of ourselves as equals, and even the decision-making groups that we ourselves elect formally (such as the admins and arb com) operate in an atmosphere of pervasive suspicion, and nobody is suitable for such jobs who cannot accept it.

As practical suggestions, probably the English WP is too large a structure to test things on; many things are probably best tried on the smaller projects. Even after that sort of a test, we still need to see if it works here, for we are more varied & less consistent than any other of the projects. The use of a beta test is really necessary, and those things that can be done on a sample should be (like protected changes, or article feedback). Most successful changes to the interface have started as opt-in features, that then became opt-out, and eventually universal. Some things do have to be uniform--notifications that cannot be depended on to be uniform are useless, and such features pose particular problems. And the key problem here of dealing with newcomers we know to be our weakest point, and therefore is particularly sensitive. We'd be very grateful for improvements, if you can suggest them.

We are deliberately very tolerant of mistakes. It is extremely hard to do anything wrong enough to be rejected by the community. The editing method has been constructed very deliberately to allow anything to be reversed, even at the sacrifice of stable content; the rules of procedure are designed as a basic principle to permit any exception, even at the sacrifice of consistent decisions. But we have built in this flexibility because we expect mistakes to be corrected. Speaking for not just myself, I think the error that you made in assuming approval of the changes (and it's clear that it was not unreasonable for you to have anticipated approval) would have been insignificant, if you had reversed it pending further discussion. That this still hasn't happened strikes some of as deliberate defiance of the community, and the rathe flowery language you use in complementing us while saying you intend to continue the same path strike us as what we expect from conventional administrators and bureaucrats. Conventional administrators and bureaucrats are what many us us profoundly distrust, both on principle and from experience--when we use the term for our own positions, it's meant as irony. If that's the way you intend to work, we need to consider how to defend ourselves against you.

Those are wrong who say that the responsibility for the programming is that of the foundation. The programming for WP was done primarily by volunteers, and the volunteers regard the foundation is their agent for certain purposes, including legal formalities and the custody of the physical resources. Physical resources are inescapable, and legal formalities are necessary; it is not uncommon for them to usurp a volunteer project, but I rather expect we will resist it. There is no need for such a confrontation if you can learn to work with us, and not depend on formal status within the foundation.

Please understand that I say this not of you personally, but of an entire general attitude. Six moths ago I literally walked out on an attempt to co-opt me into a formal role in one of the WMF-affiliated programs. Six years before, along with most of their volunteers, I quietly left Citizendium because the formal organization became counter-productive. WP was formed in large part by anarchists. I do not share it as a general social or political philosophy, but I honor it as a necessary corrective within the larger society, and I regard WP as the best illustration of Kropotkin's optimism about human potential. The WMF has the power to ruin this, and now might is the time we must persuade it not to make use of it. DGG ( talk ) 06:52, 15 May 2013 (UTC)

• +1 Ignatzmice•talk 11:41, 15 May 2013 (UTC)

• Hi DGG, Tito Dutta and others: thanks for your thoughtful responses to my last post, which I appreciate very much. I am particularly grateful for DGG's thorough description of the motivations and expectations of the WP editing community: while I was already aware of many of these attributes, it was helpful for me to read your detailed and eloquent overview. I look forward to discussing these points in more depth with you later today, and we'll definitely address these observations during our team retrospective for this project at the end of the week. Some of the general questions you raise about the respective roles of the foundation and community in making software decisions seem beyond the scope of this particular project talk page and should probably be discussed in a different forum -- which might include some of our other WMF colleagues, such as Eloquence, Philippe and/or Okeyes (WMF), who are more knowledgeable on this topic than I am. However, I would like to point out that key decisions regarding the OBOD were made in consultation with many other WMF team members, not by a small group of newcomers like me. I hope I have represented the team's rationale accurately and look forward to participating in a broader discussion of how the community and the foundation can collaborate more effectively for new software development, if someone can set it up in a more appropriate forum in coming weeks. For now, we will continue to engage the community in discussions and testing of important new features as soon as practical, for this and other projects we are working on. To that end, TittoDutta's proposals to form an editors' team of testers seems very reasonable -- and we would be happy to support this initiative. Thanks again to everyone for your constructive recommendations. Fabrice Florin (WMF) (talk) 17:36, 15 May 2013 (UTC)

A belated response - I'm not at home and have had trouble getting online. As DGG says, a lot of us are too busy with things here to know what is going on at Meta and other places. I still feel that a lot of the opposition to the Orange Banner was from people who had a personal dislike (an off switch coupled with the red pimple would have dealt with that), and fail to see how it could prevent people from getting messages, while a lot of the support from it came from the people who aren't seen on Meta, but who do have a lot of difficult contact with the newer users. Could some thought be given somewhere to getting a way of communicating with the people who work mainly in certain areas when developments that will affect them come up? A register of interests, maybe - mine would include the deletion arena, pages for translation and SPI for a start. Most of us do occasionally work in more areas - but the main ones as considered so by the user in question would do. Peridon (talk) 20:03, 16 May 2013 (UTC)

This is definitely something I'm interested in working on. With stuff like Page Curation it was easy - who are patrollers? People with patrols! More general projects are going to be a problem. But it's something we should work on, and something we will work on. Okeyes (WMF) (talk) 20:16, 16 May 2013 (UTC)

I have had the talk with Fabrice that he mentioned, though we mainly exchanged our understanding about the general working and decision patterns of the volunteers in the community and the programmers at the Foundation. They are always going to be different, and there are always going to be problems, but I hope the next round will go better. DGG ( talk ) 17:47, 17 May 2013 (UTC)

Revert notification

First of all thanks for implementing this new notifications system. I really like it. One of my edits has been recently reverted (see here) but I received no notification about it. Why was this the case? I've already received revert notifications before and they seemed to work... Thanks. --Snow Blizzard 18:25, 12 May 2013 (UTC)

Huh! Weird :/. I'll poke the devs :). Okeyes (WMF) (talk) 19:49, 13 May 2013 (UTC)

I just got a notification that my edit had been reverted, when in fact it was another user's edit which was reverted and I was simply the last person to have edited the page before the revert [1]. Sounds like a related issue. Jafeluv (talk) 09:38, 19 May 2013 (UTC)

Linking notifications

Tracked in Phabricator
Task T50547

Love the tool, especially the functionality which indicates when pages you have created get new links (I think that is a great way to show the usefulness of materials throughout the community). However, I have noticed an inconsistency in the tool: I got a notification which said "William Blake Archive was linked from And did those feet in ancient time" when the link on And did those feet in ancient time is not recent by any means. Also, as someone who would like to see the newly linked article so that I can explore why it is linked and how to build the web more, it would be really nice to link directly to the newly linked article, Sadads (talk) 13:31, 14 May 2013 (UTC)

Odd! Let me know if it reoccurs? And, yep, we're talking through it - our designer has objections to many links, but it seems reasonable to me. Okeyes (WMF) (talk) 20:57, 14 May 2013 (UTC)

I think I might have figured out something about the delay: I added the article William Blake Archive to the template Template:William Blake a while ago, and just got the notification for the link added to The Great Red Dragon Paintings at 12:01. Apparently when templates update, it triggers a notification? That's interesting, might confuse a lot of people. Sadads (talk) 15:26, 15 May 2013 (UTC)

That's just strange :/. I'll stick it in bugzilla and see if our devs can work out a reasonable way around it; thanks! Okeyes (WMF) (talk) 18:48, 16 May 2013 (UTC)

I think this may be related. Can someone explain what in fact triggers the "Page links" notification. The documentation states

• "Page links: when a new link is made to a page you created"

but does not say anything about indirect links or the interaction between links, redirects, and renames. But this edit to Hitler Cabinet generated the notification

• "Federal Ministry of Economics and Technology was linked from Hitler Cabinet: See all links to this page. Yesterday at 01:50:02"

Federal Ministry of Economics and Technology is a page that I created and was recently renamed. Since then, I keep getting weird notifications about this page. Since the change to Hitler Cabinet that apparently triggered the notification was merely a vandalism revert with no changes to any links, and the Article on the Hitler Cabinet - unsurprisingly - does not link to Federal Ministry of Economics and Technology, I can only imagine that the rename has somehow caused future changes to unrelated pages to (sporadically ?) trigger some sort of tree-traversing search for changes that looks at links in articles referenced in templates included in the article (in this case a navigation bar that links to both the Hitler Cabinet and the Merkel Cabinet - and Merkel Cabinet links to Federal Ministry of Economics and Technology). --Boson (talk) 00:24, 18 May 2013 (UTC)

When are we getting diffs?

Tracked in Phabricator
Task T50183

The diffs in the email notices and on the old orange bar were the most useful part of the old notification system. I'm actually quite shocked that they weren't integrated into this system before its release. I'm seeing all kinds of things about colours and bars (and actually, that new yellow bar isn't obvious at all and I managed not to even notice it for 20 minutes), but it's still only going to my talk page, not even to the right section, and obviously not to the diff. I'm good with the idea of adding functionality, but I'm getting quite concerned that 10 days in, we're still not back to anything close to the old functionality. I'm not trying to trash this new system, but I'm really disappointed that we've moved so far backwards here. Risker (talk) 02:25, 15 May 2013 (UTC)

And perhaps to prove the point...someone left me a talk page message on another wiki that has this enabled. And I scrambled around here on this project trying to figure out where in heaven's name the darn notification was on my talk page, until I realised that it was on another project. A link is not good enough. Give us diffs please. While you're at it, why is this new feature live without having been checked out on suppression? We were told after the last big new feature went live without suppression ability that nothing would be enabled even on opt-in basis that did not have the suppression facility sorted. Risker (talk) 03:03, 15 May 2013 (UTC)

Apparently, the temptation to reinvent the wheel constantly is just too strong. :) --Nemo 09:16, 15 May 2013 (UTC)

I'm confused; Risker, I was under the impression that you were pretty heavily involved in the conversation about suppression yourself? Okeyes (WMF) (talk) 21:06, 15 May 2013 (UTC)

Not for this feature, at least not in its current iteration; I may have had some questions put to me some time ago in a hypothetical manner. Indeed, I didn't know about the concerns until it was pointed out here, and I certainly didn't have any opportunity to test before go-live. Risker (talk) 01:06, 16 May 2013 (UTC)

Hi Risker, thanks for bringing up this important issue, which is very high on our to-do list. We discussed your concerns with the product team yesterday and propose this short-term solution, if it works for you. We would like to add a '(show changes)' link for all talk page messages in the upcoming HTML email notifications, as well as in the archive page. So users will have the option to go straight to the diff page by clicking on this link if they want. This is a tough challenge to solve, because we're serving both new users and experienced users like you with this feature. To a new user, the diff page is largely incomprehensible and useless as currently designed. To an experienced user like you, it is incredibly useful. At the same time, it's not a good idea to offer completely different functions for different user groups, so we need a solution that serves them both effectively. For now, we would like to first add this 'show changes' link on the archive and HTML emails -- and hold off on adding it to the flyout, because putting more than one link per notification in that limited space tends to overwhelm users with too many decisions. However, we will test this specifically with users in coming weeks, and are prepared to revisit this temporary decision after we have more feedback. Would this proposal work for you, as a first step? (you can track this Template:Bug on Bugzilla) Fabrice Florin (WMF) (talk) 18:04, 15 May 2013 (UTC)

I'd note that this is in no way the final feature; I, for one, very much want diff links in the on-wiki notifications. Okeyes (WMF) (talk) 21:06, 15 May 2013 (UTC)

We'd still have them, if you hadn't removed (or had restored as the community wished) the orange bar, before its replacement was properly ready. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:16, 16 May 2013 (UTC)

Andy, I appreciate that the process here has been highly frustrating for everyone involved; as someone who looks at things from both a Product and community mindset, I've been getting both sides of the issue. But I don't think we do the process or ourselves any favours by perpetuating posts beyond the point at which they contribute to the discussion, and I'd argue this does that. Okeyes (WMF) (talk) 18:42, 16 May 2013 (UTC)

Argument noted. Not accepted, but noted. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:02, 16 May 2013 (UTC)

We need the diff link on the Orange notification bar so the you can get a view of the change via the pop-ups without actually opening the link. Keith D (talk) 11:13, 16 May 2013 (UTC)

Agreed. I'm having that conversation now; it'll hopefully branch out into wider on-wiki discussion so we don't make decisions in a vacuum, or behind closed doors. Okeyes (WMF) (talk) 18:42, 16 May 2013 (UTC)

HTML email

"HTML email"?! Such things are (usually) evil. Please assure us that there will be an option to receive plain text mails. From the outset. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:16, 16 May 2013 (UTC)

Seconded. I use alpine (email client) and so cannot easily view HTML emails. HTML-only emails also frequently end up in my spam folder (almost always correctly), where they may sit for several weeks. Thryduulf (talk) 04:01, 16 May 2013 (UTC)

Agreed, HTML email for a simple notification is major overkill. If we are trying to plan for a wide variety of mobile devices, and keep things lean for people with ancient computers and on slow Internet connections around the world, a plain text option is important. (I understand that a long diff link might be unattractive to some, but it's not hard to get used to clicking something -- it's not like people need to read the diff link.) -Pete (talk) 05:54, 16 May 2013 (UTC)

mw:Echo_(Notifications)/Feature_requirements#Email_notifications See the 'formats' section. —TheDJ (talk • contribs) 09:40, 16 May 2013 (UTC)

FFS. "There will not be any email format preferences unless we hear a strong user demand for this" - I wish to express strong demand for a user preference option for plain text. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:57, 16 May 2013 (UTC)

In case my comments immediately above are in any way ambiguous, I too wish to express my view that plain text emails are absolutely essential for accessibility and other reasons.

Please bear in mind that HTML emails can't be as accessible as text emails, primarily because most email clients were originally designed to deal only with text, and the HTML functionality has been added to their features, rather than being at the core of the design. This results in the email client providing relatively poor support for screen readers, which can misread the text. We recommend that, wherever possible, recipients are offered a choice of email format, to avoid this problem.

— Royal National Institute of Blind People, [2]

. Thryduulf (talk) 11:02, 16 May 2013 (UTC)

You beat me to it. I've notified the accessibility project. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:50, 16 May 2013 (UTC)

Thanks for your feedback about HTML Email for notifications. Please note that plain text emails will continue to be sent along with HTML emails, so if your email client cannot read HTML emails, you will see the plain text version instead. Also note that most email notifications are turned off by default for current users, so this may be a moot point for users who do not chose to enable them. That said, HTML email notifications are now widely used on other top sites nowadays, as shown in these screenshots of best practices -- and I am not aware of any major destination that still uses plain text emails as a primary communication medium. The main reason HTML emails are so widely used is because they present information more effectively than plain text emails, by using clear visual cues to inform users of new activity -- and invite them to take action more easily. For these reasons, we are not planning to provide a preference to switch between HTML and plain text email for this first release, but will closely monitor community feedback on this topic in coming weeks to plan our next steps. Fabrice Florin (WMF) (talk) 17:50, 16 May 2013 (UTC)

Why does it matter what other "top" sites are doing? Surely Wikimedia should be striving to provide the best to its users based on principles of accessibility, objectively good design and user choice? The attitude seems to be that HTML email is the best for everybody regardless of their circumstances, ignoring users who have an html-capable client but a need or desire for plain text emails. That seems to be in direct contradiction to [The Wikimedia Foundation's] mission [...] to empower a global volunteer community to collect and develop the world's knowledge and to make it available to everyone for free, for any purpose (emphasis mine). It's worth noting here that our HTML email is in a very poor state, with accusations of bias and no mention of accessibility. Thryduulf (talk) 18:02, 16 May 2013 (UTC)

In those screenshots, which of the evaluated are online encyclopedias? --Onorem♠Dil 18:06, 16 May 2013 (UTC)

Indeed, I was about to ask why Wikimedia is comparing itself to social media sites when it is explicitly not social media? Thryduulf (talk) 18:09, 16 May 2013 (UTC)

LinkedIn is social media now? Trello, for example, is a project management tool. Onorem: if your standard is "only include changes that are based on what another online encyclopedia does" we'll either never change a thing or stop most of us from editing.

Thyrduulf; I totally agree. But we are going to give people a choice; it's not about making design decisions that only benefit a certain subset of users, it's about having options that allow for all users to be covered :). Okeyes (WMF) (talk) 18:16, 16 May 2013 (UTC)

I never said that was my standard, but I'm not surprised that you're portraying it that way. --Onorem♠Dil 18:19, 16 May 2013 (UTC)

If you're looking for a notifications system used by many online collaborative encyclopedias, then see this page on Wikia. FallingGravity (talk) 21:22, 16 May 2013 (UTC)

"LinkedIn is social media now?" - Yes, not least according to both LinkedIn and Social media. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:00, 16 May 2013 (UTC)

I would note to everyone that Fabrice said, above (I appreciate it may be lost in the discussion - I'm very much looking forward to Flow :/) that HTML emails will display as plaintext to those with email clients configured to avoid HTML. Okeyes (WMF) (talk) 18:39, 16 May 2013 (UTC)

You again answer a different issue to the one raised. Nobody has claimed that the emails will not be multipart; but that some people - including me - want to receive text only. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:07, 16 May 2013 (UTC)

Then I'm confused. The argument made was for accessibility; my point is that the sending of multipart emails allows for this to be factored into acconut at the user's end. What's the argument for plaintext-only? If it's data transfer costs, that's something we should discuss, but it's a totally different argument from the RNIB-citing conversation. Okeyes (WMF) (talk) 11:47, 17 May 2013 (UTC)

Tim Starling pretty roundly debunked the myth that HTML e-mail is bad for accessibility in a mailing list post. I can't seem to find it right now, though. :-/ --MZMcBride (talk) 19:27, 16 May 2013 (UTC)

I've found a 2005 post he linked to this, but I can't seem to find anything more recent. Okeyes (WMF) (talk) 19:31, 16 May 2013 (UTC)

After about twenty minutes, I finally found it: mailarchive:wikimedia-l/2011-April/112038.html. And the relevant bug is bugzilla:13303. --MZMcBride (talk) 19:36, 16 May 2013 (UTC)

In which he doesn't address, let alone "debunk", accessibility concerns. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:13, 16 May 2013 (UTC)

What accessibility concerns are you worried about? Please be as specific as possible. I read <http://www.rnib.org.uk/professionals/webaccessibility/articles/Pages/html_emails.aspx> and this thread. I'm still not seeing accessibility issues with HTML e-mails. --MZMcBride (talk) 05:15, 17 May 2013 (UTC)

No mention of accessibility there, either. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:15, 16 May 2013 (UTC)

For what it's worth, as a screen reader user, I find that HTML emails are no longer a problem (I used to hate them with a passion). I only have experience with JAWS and NVDA, but other modern screen readers work similarly; they present *any* HTML textarea as a virtual buffer and allow users to navigate it easily. I think the above RNIB link is a bit out of date in this respect. Graham87 07:33, 17 May 2013 (UTC)

Having said that, we really should make sure the HTML is formatted rationally for screenreaders; any objection to me giving you a poke once we've got something up so you can test it? Okeyes (WMF) (talk) 11:47, 17 May 2013 (UTC)

Indeed; I'd be happy to take a peek at it once it's ready. Graham87 12:29, 17 May 2013 (UTC)

+1 for reports based on actual experience. Thanks, Graham. — Scott • talk 14:35, 17 May 2013 (UTC)

I'd be interested to know the justification for refusing to allow users on per-megabyte dataplans the option to turn off redundant and wasteful multipart emails in favour of light plain-text. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:07, 16 May 2013 (UTC)

I think your case would be bolstered by evidence that the increased message size would have a non-negligible impact. The bandwidth issue was discussed in Tim's e-mail. --MZMcBride (talk) 05:15, 17 May 2013 (UTC)

FSVO "discussed", involving unsubstantiated assertions and overlooking several use cases. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:32, 17 May 2013 (UTC)

Can you give these use cases, then? Okeyes (WMF) (talk) 11:47, 17 May 2013 (UTC)

We can't know all the possibilities; but for example: a mother in the global south, with an expensive mobile data plan and no easy access to healthcare, and who doesn't edit Wikipedia, signs up and watchlists, with email notifications, the stub about the disease her child has, in order that she will receive an email when the article is changed or expanded. A student who want to be notified - with an edit summary - that their talk page has changed, on their expensive mobile data plan, in order to travel to the next town where they have landline access to edit. An employee who can only receive email notifications at their workplace, which blocks HTML or multipart emails. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 17 May 2013 (UTC)

Your first suggestions could be shortened to "internet access is expensive for many people", which is a valid concern. However, for the latter, allowing people editing Wikipedia while on the clock to cope with dodgy firewall rules is hardly the Foundation's problem. — Scott • talk 14:39, 17 May 2013 (UTC)

My latter example does not mention editing; nor doing anything "on the clock". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:01, 17 May 2013 (UTC)

Ladies and gents, this seems like bikeshedding in the extreme. I dislike HTML email as much as the next old-school geek, but plain-text vs. HTML email seems like a pretty ridiculous thing to give an enormous shit about. The issue seems to be "the emails are a bit bigger". Have you loaded WP:ANI recently? Isn't there an encyclopedia to write? —Tom Morris (talk) 13:08, 17 May 2013 (UTC)

Yeah, I must get around to thinking about starting to make a contribution to that... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:01, 17 May 2013 (UTC)

Tracking users via e-mail

It seems strange that nobody seems to have mentioned the potential privacy concerns regarding HTML e-mail. Accessibility is one sword to wield, but surely privacy is another. HTML e-mail allows for much easier tracking via URL (with obfuscated or hidden URL parameters) and can track users by loading arbitrary server-side content (such as images). Interestingly, the Wikimedia Foundation privacy policy seems to go out of its way to exclude itself from governing any user tracking/data collection of this nature. Perhaps this sword is stronger to fight the evil beast that is HTML e-mail. ;-) --MZMcBride (talk) 04:12, 18 May 2013 (UTC)

Date format bug

Tracked in Phabricator
Task T49211

Hi, in Finnish localization the date format is wrong. It says "TOUKOKUUN 12" ("MAY'S 12") while it should say "12. TOUKOKUUTA" ("12ND MAY"). Where can this be changed ? EDIT:Also, the date after the notification is not localized,it's allways English. --Olli (talk) 15:54, 17 May 2013 (UTC)

Hi. Would it be possible for you to upload a screenshot of what you're seeing? I think it would make resolving the issue much easier. --MZMcBride (talk) 16:58, 17 May 2013 (UTC)

Hi, does this help: [3] --Olli (talk) 18:14, 17 May 2013 (UTC)

Yes, that's wonderful, thanks! I've filed bugzilla:48583 accordingly. --MZMcBride (talk) 19:06, 17 May 2013 (UTC)

@Olli: The genitive case issue is Template:Bug. The reason the messages are showing up in English is because no one has translated them into Finnish yet. If you would like to help, just go to: https://translatewiki.net/enwiki/w/i.php?title=Special:Translate&group=core&filter=!translated&language=fi&action=translate. Kaldari (talk) 20:36, 17 May 2013 (UTC)

Hi, thanks for you both. The fixing of the genitive case issue seems to be taking quite long time. I think it's not so difficult job to do... --Olli (talk) 05:22, 18 May 2013 (UTC)

You just see the translation, but these are algorithms and code that need to be fixed and rewritten. It's much more complex than it looks. —TheDJ (talk • contribs) 20:35, 18 May 2013 (UTC)

Okay, I'll understand. --Olli (talk) 05:35, 19 May 2013 (UTC)

Another missing mention notification

This message should have given me a mention notification, but it didn't. Is that because Cyberpower678's signature doesn't link directly to his user page, or some other reason? Or am I just losing the plot? Graham87 03:32, 15 May 2013 (UTC)

@Graham87: After testing with my bot account ([4] — I did not get a mention notification), I think your hypothesis is correct: The signature of the user mentioning you must have a direct link to their user page and/or (?) their talk page. Interesting, isn't it? The Anonymouse (talk | contribs) 04:16, 15 May 2013 (UTC)

@The Anonymouse: It is indeed! The mention notification worked for that message, but not initially when I clicked the "1" link – I had to go to the Special:Notifications page to access it. Graham87 05:08, 15 May 2013 (UTC)

This would cause a problem for users who just link to their talk pages in their signature rather than their main user page (JzG, I'm "looking" at you). :-) It should probably be changed to accept either a user page or a talk page link. Graham87 05:24, 15 May 2013 (UTC)

However, I'm not sure if it requires a direct link to the user page, talk page, or both (hence the ? in my statement). The Anonymouse (talk | contribs) 05:28, 15 May 2013 (UTC)

Ah, didn't notice the question mark in your message; my screen reader just paused as it would for a comma! This edit caused my main account to get a mention notification, so a link to a talk page is all that's needed. Sorry, Guy, for dragging you into this. Graham87 06:30, 15 May 2013 (UTC)

OK, that's good information. So I guess a direct link to the user's talk page is all that is needed. The Anonymouse (talk | contribs) 16:33, 15 May 2013 (UTC)

I would certainly be unhappy with trying to require anyone to link to their user page, I have a redlinked user page for good [FSVO] reason. Guy (Help!) 10:25, 15 May 2013 (UTC)

FSVO? Okeyes (WMF) (talk) 21:03, 15 May 2013 (UTC)

Google is your friend, Oliver! "For Some Value Of". :) Theopolisme (talk) 21:15, 15 May 2013 (UTC)

I've now added the initialism to Wiktionary: wikt:FSVO. If you can give a concise definition for "for some values of" in this meaning please add it. Thryduulf (talk) 22:45, 15 May 2013 (UTC)

Thanks, both :). I'm not sure what the solution is here, to be honest :/. I get the problems of mucking with user signature requirements, but the alternative is to muck with a lot of onwiki templates and processes (can you imagine if a mere user talk link triggered it?) Okeyes (WMF) (talk) 18:47, 16 May 2013 (UTC)

I assume that a link to a non-existent user page would also work, because if it didn't, then this would fail for most new users. Also, if necessary, you could create a non-visible link like " " (yes, there's a link to User:JzG's user page between those quotation marks). WhatamIdoing (talk) 00:58, 17 May 2013 (UTC)

Yeah, it'll work fine; I think there's plausibly an argument to be made for not linking to userpages that don't exist (it could cause some confusion) but linking seems to be the least-onerous and problematic solution here. Okeyes (WMF) (talk) 11:49, 17 May 2013 (UTC)

As an aside, I recommend any admins or other long-standing users either to have a redlinked user page or an alternate account with a redlinked user page and a significant edit history. You would be amazed at the opportunities this provides for "teaching moments", and also at the valid points that come up re your own editing. Do use the email user feature for one-to-one feedback, though, as it is a lot less public and thus less likely to cause defensive reactions. Guy (Help!) 22:21, 19 May 2013 (UTC)

Certainly, but I'd make an argument it causes damage to the community as a whole - it breaks everyone down to identity-less pseudonyms. Okeyes (WMF) (talk) 18:17, 20 May 2013 (UTC)

Aren't pseudonyms inherently identity-less? Writ Keeper ⚇♔ 18:21, 20 May 2013 (UTC)

Not at all; pseudonyms are not linked to your real-world identity - there's a big distinction. Someone can have multiple identities, all tracking different aspects of their achievements, actions and persons. So, for example, I'm Oliver Keyes, but I'm also Ironholds. At a time, these were completely distinct; Ironholds was my online handle, Oliver how I handled myself in the real world. My actions as Ironholds did not impact on my reputation as Oliver. But this is not the same as it not having an impact. Ironholds was my name for Wikipedia, the wider movement, code, gaming - something that impacted on any one of those things impacted on my standing everywhere. Indeed, if I chose to identify who I was in meatspace while I was Ironholds, it impacted everywhere. Pseudonyms can lack an identity behind them, but often don't. Okeyes (WMF) (talk) 16:08, 21 May 2013 (UTC)