EE September 2014

ee@lists.wikimedia.org

31 participants
49 discussions

What's the point of page review notifications?
by Dario Taraborelli 11 Sep '14

11 Sep '14

I received this morning an Echo notification for a new page that I created: Meadow Fire was reviewed byTillman. I never paid much attention to page review notifications ( I haven't created many new pages since Echo was deployed) but it strikes me that these messages do not convey any meaningful information to the recipient: * they refer to a "new page review" process that most new editors are definitely not aware of (when creating a page we don't tell the page creator: your page will be reviewed") and don't provide any link to it. * they mention a moderation action that the user will have trouble interpreting (is this good? Is this bad? Am I supposed to do something? Should I talk to the reviewer that the notification links to? What happens now to the page that I created?) * if the notification is not meant to be actionable but is supposed to work as a positive feedback signal, it's poorly designed for this purpose in its current form. I'd like to hear thoughts from this list on the intended purpose of this notification and how we can improve it so the recipient understands what s/he is being notified about. Dario

3 2

Re: [EE] +1 (was: Adding Thanks to more places)
by Nick Wilson (Quiddity) 11 Sep '14

11 Sep '14

On Thu, Sep 11, 2014 at 4:11 PM, Pine W <wiki.pine(a)gmail.com> wrote: > This ties in with an idea I had for Flow. Could there be ways to thank, > favorite, and +1 individual comments made via Flow, and sort Flow comments > by +x count? > The possibility of "+1" has been suggested in a few places recently. It could be the equivalent of the Enwiki's frequent usage of "support, per user:foo". A few links are now collected at https://www.mediawiki.org/wiki/Flow/Prior_discussion-thread-roundup#.2B1_pl… I think it's an interesting possibility, but not a feature that will be added anytime soon. There are other more important features to work on for now, and there are significant possibilities of that kind of feature being mis-used, that would need to be thought about at length. I'd suggest reading through those existing links, and then adding any notes to the discussion at the linked talkpage discussion.

1 0

Flow scrum notes, Thurs Sept 11
by Danny Horn 11 Sep '14

11 Sep '14

There's been some vandal activity on en.WP's Flow pages over the last day or so, exploiting a couple of vulnerabilities in the way that Flow interacts with Echo. We're currently writing and backporting a couple of fixes. We'll keep working on finding and patching attack vectors, and we'll keep monitoring for vandal activity. *Matthias*: Today, worked on putting watch star back at the top on board pages. There's a patch in Gerrit -- a little hacky, but it works. There's Found a couple bugs in the Close/Lock transition. Tomorrow: more work on search. *Benny*: Worked on script for cleaning out notifications, it's in code review. This will unlock G-101 -- unread notifications in reverse chronology. Working on H-2 -- email titles. We can't reproduce X-9 -- the bug that Amir reported. He'll post on the bug as can't reproduce, and see if Amir can reproduce. *Shahyar* Working on notifications - topic title should be easier to read, that may get backported after today's release. Currently working on new modal dialog box. Question about hide/unhide modal on Monobook -- can we do a hack for this quickly? Shahyar says he'll take it today. *Erik*: Yesterday -- mostly worked on bug 70662 -- contributions aren't appearing in All view. He's having a hard time reproducing the bug, but he's found an error in the code that should fix it. This will get resolved from the content handler work.

1 0

What works for increasing editor engagement?
by Pine W 11 Sep '14

11 Sep '14

Hello research colleagues, When I look at the WMF Report Card, it appears to me that the global active editor stats and the number of new accounts being registered per month has been relatively flat since at least 2011. Those of you who work in EE research and analytics, I would like to ask if there is a summary of techniques that you have found that do produce statistically significant results in improving editor retention. I know that some of you write tools, design projects, or pull and analyze data about editors. It looks to me like WMF is investing significant effort in research and tool creation, but we're not moving the needle to create the results that we had hoped to achieve. So I'd like to ask what have we learned from all of our time working on editor engagement about techniques and programs that do improve the EE stats significant ways, so that we can hopefully accelerate the implementation of programs and techniques that have demonstrated success. I'd also like to ask what barriers you think prevent us from becoming more effective at improving the number of users who register and the number of active editors. For example, are users who go through GettingStarted often being deterred by quickly being confronted by experienced editors in ways that make the newbies want to leave? If that is a significant problem, how do you suggest addressing this? One of my concerns about investing further in developing Flow, analytics tools like like WIkimetrics, and further complex editor engagement research projects, is that the most important challenges related to editor engagement may be problems that can only be solved through primarily interpersonal and social means rather than the use of software tools and mass communications. I like Wikimetrics and I use it, and I think there's an important place for analytics and tool development in EE work, but I wonder if WMF should scale up the emphasis on grassroots social and interpersonal efforts, particularly in the context of the 2015+ Strategic Plan and Jimmy's speech at the 2014 Wikimania. What do you think,and if your answer is yes, how do you think WMF can do this while respecting the autonomy and social processes of the volunteer projects? Thanks, Pine

1 0

Fwd: Non-JavaScript Flow: Hiding non-ready functionality
by Jon Robson 10 Sep '14

10 Sep '14

Whoops this was meant to be to the public mailing list! ---------- Forwarded message ---------- From: Jon Robson <jrobson(a)wikimedia.org> Date: Wed, Aug 27, 2014 at 2:39 PM Subject: Non-JavaScript Flow: Hiding non-ready functionality To: "Editor engagement list for the core E2 development team." <e2(a)lists.wikimedia.org> I noticed in a code review today that S was confused to why actions are unavailable in titlebar and posts (.client-nojs .flow-menu" has display:none in CSS) Recently in the last retrospective the Flow team agreed to record on the mailing list decisions, and since this decision happened prior to the meeting (about 3/4 weeks ago) I should try my best to record that decision. May, Danny, Shahyar and I sat down and spoke about the non-JavaScript version of the site, in particular with respect to mobile, as many mobile devices on slow connections will hit the non-JS site at some point. The summary was that the current non-js needed lots of love, but that we should focus on the topic and reply workflows (which are currently being looked on as part of this iteration [1]) Any functions that didn't fit into this, where the UX was suboptimal would be hidden, even if they were functional. The link to summarize for instance will take you to a page like this: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Topic:S15sspioi5wvqz… The page simply shows a textarea and doesn't really help you understand what you are doing. Likewise clicking edit title takes you to a page like so: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=Topic:S15sspioi5wvqz… Displaying them again is pretty easy (Shahyar already has a patch [2]) but the UX love is much needed before doing so. [1] https://trello.com/c/fp2odUa3/531-g-1-mobile-no-js-make-reply-field-a-link-… [2] https://gerrit.wikimedia.org/r/153354

3 8

Flow scrum notes, Wed Sept 10
by Danny Horn 10 Sep '14

10 Sep '14

*Jon*: Yesterday - code review, mostly mw-ui Today - working on failing browser test for H-4 (Close --> Lock) *Benny*: Finished script for clearing >2000 notifications. Needs to do some tests, should be ready today. Also looked at H-2 - useful titles on email notifications -- not as easy as he thought -- the title token is used in other places -- need to find a way to update to differentiate this. *Matthias*: Worked on X-13 -- Highlights on Monobook in the wrong place. Has a question on the card for Shahyar/Jon. Added one more small patch to change Close to Lock H-4. Tomorrow -- start working on search again. *Erik*: Yesterday -- watchlist and RC -- doesn't highlight things appropriately when they're read/unread -- put in patches on that. Pushed code from Mediawiki to enwiki, went well as far as we can see. Shahyar traveling today.

2 1

Fwd: Echo Limn graphs need to be fixed
by Jon Robson 10 Sep '14

10 Sep '14

What are the state of these graphs? Does Echo have any metrics that it measures success against that we should be keeping an eye on? ---------- Forwarded message ---------- From: Ryan Kaldari <rkaldari(a)wikimedia.org> Date: Fri, Sep 5, 2014 at 2:30 PM Subject: Echo Limn graphs need to be fixed To: Danny Horn <dhorn(a)wikimedia.org>, Erik Bernhardson <bernhardsonerik(a)gmail.com>, Jon Robson <jdlrobson(a)gmail.com> There used to be a bunch of awesome Limn graphs for Echo at http://ee-dashboard.wmflabs.org/dashboards/features/# and http://ee-dashboard.wmflabs.org/dashboards/metrics/#. I'm not sure what happened to them though. If someone wants to get them running again, there's a lot of documentation about how they are set up at https://wikitech.wikimedia.org/wiki/Ee_dashboard Ryan Kaldari

5 4

Standardising icons across projects
by Jon Robson 09 Sep '14

09 Sep '14

Since we had the luxury of having several people in the office, Trevor, Juliusz, Rob Moen, Ed Sanders, Shahyar, May, Monte and I sat down to talk about the problem we currently have of having no standard way to create icons. Here is my write up of this meeting, again, if you attended please add/correct me on anything and if you were not please ask for clarification where needed. Currently we have two modes of creating icons in MediaWiki 1) Using a font 2) Using SVGs with PNG fallbacks and the markup varies depending on what extension you look at. We discussed both approaches and advantages and disadvantages of each. One of the major disadvantages of the WikiFont is the additional HTTP request it creates to download the font and cannot be embedded in the stylesheet using data uris like SVGs can (due to URL size restrictions). One of the major advantages of WikiFont is you can design a grayscale icon, and style it using font colour. Shahyar was happy to move Flow to using SVG based fonts if we could build grayscale SVGs and change their colours using ResourceLoader. One concrete example is when you have an icon used in a constructive anchor. The icon needs to be green, but when hovered over a lighter green. Another advantage brought up by May was that currently she finds it much easier to build icons in this way, and that having to maintain separate coloured versions of the SVGs is a pain point to her. We decided that we should push towards using SVGs that can be built into fonts for the purpose of the app. As next steps 1) Monte to explore using SVGs in the Wikipedia apps. He will create font from SVGs. He will work with May to ensure her workflow is as easy as before. 2) Trevor is going to look into how we can automatically generate different colour versions of SVGs and automatically create PNGs from them. 3) I am going to aim to agree on a standard icon HTML markup for mediawiki ui. We still have an issue with the fact that everyone is using different HTML markup to create icons. After reviewing all our current approaches [1] it was clear that we were relatively closely aligned and that it simply is a case of agreeing on class names. We aim to get all the above done by Sept 15th, 2014 so please poke us on the mailing list if you haven't had a follow up then. Full disorganised notes can be found here [2]. [1] https://www.mediawiki.org/wiki/Icon_standardisation [2] http://etherpad.wikimedia.org/p/Icon_standardisation

2 3

The future of skins
by Jon Robson 09 Sep '14

09 Sep '14

Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and talked about the future of skins. Hopefully this mail summarises what we talked about and what we agreed on. Feel free to add anything, or ask any questions in the likely event that I've misinterpreted something we talked about or this is unclear :) Specifically we talked about how we are unhappy with how difficult it currently is for developers to create a skin. The skin class involves too many functions and does more than a skin should do e.g. manage classes on the body, worry about script tags and style tags. Trevor is going to create a base set of widgets, for example a list generator to generate things like a list of links to user tools. The widgets will be agnostic to how they are rendered - some may use templates, some may not. We identified the new skin system will have two long term goals: 1) We would like to get to the point where a new skin can be built by simply copying and pasting a master template and writing a new css file. 2) Should be possible for us in future to re-render an entire page via JavaScript and using the modern history push state re-render any page via the API. (Whether we'd want to do this is another consideration but we would like to have an architecture that is powerful enough to support such a thing) As next steps we agreed to do the following: 1) Trevor is going to build a watch star widget on client and server. We identified that the existing watch star code is poorly written and has resulted in MobileFrontend rewriting it. We decided to target this as it is a simple enough example that it doesn't need a template. It's small and contained enough that we hope this will allow us to share ideas and codify a lot of those. Trevor is hoping to begin working on this the week of the 2nd September. 2) We need a templating system in core. Trevor is going to do some research on server side templating systems. We hope that the templating RFC [1] can get resolved however we are getting to a point that we need one as soon as possible and do not want to be blocked by the outcome of this RFC, especially given a mustache based templating language can address all our current requirements. [1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library

8 14

Flow: Concept work for searching on a board
by Danny Horn 09 Sep '14

09 Sep '14

One of the big things that we have to work on next is searching on a Flow board. It's important for people to be able to easily browse and find the relevant topics, and a busy board will sink older topics pretty quickly. Because each Flow conversation is an individual, discrete unit, we actually have the opportunity to do interesting things, to filter and remix threads in a number of helpful ways. ErikB and I were talking about how to represent Flow search results, and we came up with a model that's based on Gmail search results. It's a very similar use case -- you're searching for keywords in a large body of threaded conversations -- so I think the model is instructive. (See the attached screenshot of Gmail search results for an example.) So I put together a few early concept wireframes, which are also attached. On these wireframes, the exact placement of the elements are entirely hypothetical -- I just wanted to put them somewhere on the page as a starting point for discussion. The user flow is: * A user clicks into the entry field, and types keywords to search for. * This brings up a Gmail-style list of topics that contain that keyword set. This is simple flat keyword matching -- it doesn't weight a match in the topic title more heavily than a match in the posts. * The list of topics is arranged in reverse chronological order, so the user can scan back through time to find the topic they're looking for. (This will be especially helpful for the use case of "Where's that discussion we had about X? It was about two months ago...") * In the list, there's a limited amount of useful metadata. In this wireframe, I tried out showing the number of posts in the thread, and the watch star to indicate threads that you're subscribed to. * The user clicks on a topic title, and navigates to that thread's Topic page, where the matching keywords are highlighted. * On the Topic page, there's a clear way to get back to the list of search results. So -- this is early stuff, just communicating the general direction that I think we should go. What do you guys think? Danny

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

EE September 2014