This experiment desperately needs documentation (both on mediawiki.org and Meta:Research). Moushira, would you be able to help coordinate such documentation so that we are more clearly communicating with the community about these changes? (Even I can't keep up with what we are doing with the last modified bar in mobile and why.) You might need to talk with some of the designers about the rationale for the changes. Maryana may also be able to provide some insights. Kaldari On Mon, Mar 23, 2015 at 12:15 PM, Jon Robson <jrobson(a)wikimedia.org> wrote:

Thanks for the explanation Maryana. I've always been confused about these changes, especially since they have frequently been referred to as "experiments" (see blog post for example), and because we've gone back and forth on the implementation without really understanding why. If I'm confused about it, I'm sure the community is even more confused. I also didn't know that https://www.mediawiki.org/wiki/Humanizing_features existed (it isn't linked from anywhere). It seems to basically be a brainstorming page from 2013. Do you think it would make more sense for developers to write documentation about UI features they implement (this model is often followed by small projects like WikiLove) or for design and/or PM and/or community liaison to write such documentation (this model is often followed by larger projects such as Echo and Visual Editor)? Either way, I think we definitely need more documentation and should start creating more cards for it in our sprint planning. Kaldari On Mon, Mar 23, 2015 at 2:26 PM, Maryana Pinchuk <mpinchuk(a)wikimedia.org> wrote:

Thanks Maryana, The last edited bar is a good start at humanizing articles, but I think its noticed and understood by editors more than readers. We've been working to improve the reader experience, and we've been really focused on what readers see when they first arrive at an article. There were so many icons, UI elements, page issues and such that gets in the way of readers immediately understanding "what is this?" I still really want to work on humanizing the editors and letting people know if an article is fresh. We can do better for sure. Maybe a design brainstorm sometime in the future? On Mon, Mar 23, 2015 at 2:26 PM, Maryana Pinchuk <mpinchuk(a)wikimedia.org> wrote:

By "What is this?" I mean the reader asking the question, "What is this article about?" For example, someone is learning about color theory. "What is subtractive color?" Here is a screenshot of the mobile web interface, and a screenshot of the app interface. In the app, it is much easier to quickly determine the meaning of the article. The benefit of altering the last modified link is part of a redesign to prioritize reader understanding. On Wed, Mar 25, 2015 at 2:02 PM, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote:

This is an interesting discussion. Let's continue it more as if we were sharing a table with pencils or dinner plates, aiming to get together to the best conclusions we can produce -- less as if we were in a tribunal or a senate trying to see how is more right. On Wed, Mar 25, 2015 at 10:42 PM, Federico Leva (Nemo) <nemowiki(a)gmail.com> wrote: I think what happened is that there are different approaches (desktop, mobile web, mobile app, and a world out there) and Kaity and others are trying to find the right approach. Ok, this is a good point. But Kaity's is also a good point (the amount of objects before getting to the information is not particularly useful either). Maybe a clickable "!" icon in the right location could bring back the accuracy while keeping the clean design? This is your opinion and your wording, but let's see. The mobile app approach clearly bets on promoting the first image when available, which makes sense for devices with shiny color screens like most mobile devices with web browsers nowadays, makes sense for a movement that puts an emphasis on free media beyond text, and makes sense for 2015 and a tradition of online and printed publishing. It is a bet with some risks, but imho a more interesting bet than continuing with the just too grey (again imho) and uniform mobile web UI. About the 'hard to read' the mockup doesn't have a darker gradient under the title text, but the mobile app does have it, and after dozens of random articles, I would say the problem is well solved. 'space taken by the search bar' looks like a smaller problem that allows fine tuning if needed. About 'silly text flow', I don't see why flowing text is silly in a constrained surface. It seems to be eating space of only the first line of text, and it looks like an idea worth testing instead of dismissing beforehand. Also very important, you may or may not be aware that calling 'silly' something might be perceived just like calling 'silly' the person(s) who worked on that something. There is no need for this, we are all trying to contribute our best. Kaity's point as described previously is "what readers see when they first arrive at an article". Therefore, as far as I understand her comments, this is not about saving pixels in heights to squeeze more text, but about providing a natural path for the reader (background illustration - title - content), removing the many obstacles we have now, and pushing them down or to the side. Yes, I agree that discussing work in editable tasks that can link to mockups, subtasks, plans, etc, are better than discussing work in mailing lists. PS: I agree with Nemo and bawolff that the current wording of "Last edited by..." highlights the elements that are perhaps less relevant. Still, the purpose of that object is correct (telling to the readers that such articles have been created by people like them). Have other text alternatives been considered? What about something like "Created by NN volunteers or more".

On Fri, Mar 27, 2015 at 12:11 AM, quiddity <pandiculation(a)gmail.com> wrote: While I don't think "last edited" is particularly useful and I prefer to focus on simplicity and what really matters, I don't have a strong opinion either. However, I do have a strong opinion about trying the use of "volunteers" rather than "editors". While for us wikimedians "an editor" sounds almost as familiar as a friend, for a big percentage of our readers, an editor sounds like a literary or newspaper editor, like someone almost professional and erudite, "not like me". "Volunteer" is an accurate and actually more descriptive term, which sounds a lot closer (and should I say human?), and sounds "like me" for an interesting portion of our readers.

+1 to Quim and Nick and bawollf. A step back: - Q: What was the purpose of the banner? It was a test in humanizing articles? After running the test for some time now, are we able to measure what value it has added the way it is? It is an interesting idea towards allowing readers to understand how Wikipedia works, but as Kaity mentioned, it needs further iteration, with clear ideas about what to measure after implementation. The banner itself is currently driving traffic to the userpage (which itself needs further iteration) --tuning both experiments, might be a wonderful idea :). Cheers, M On Fri, Mar 27, 2015 at 2:02 AM, quiddity <pandiculation(a)gmail.com> wrote:

On 27 Mar 2015 2:11 am, "Quim Gil" <qgil(a)wikimedia.org> wrote: melamrawy(a)wikimedia.org> wrote: itself needs further iteration) We already do. Yet more people click on it for whatever reason: http://mobile-reportcard.wmflabs.org/#other-graphs-tab. been updated by several people at different points of time for reasons summarized in the description of each edit. From there you can click to user profile pages if you wish. summary at the top that could provide interesting information to newcomers and regular editors alike, i.e. Yeh that's not a bad idea - Phabricator task? registered volunteers and N anonymous users. More generally we really need to pay attention to our data and rely on it more. I see far too many changes across the site based on guesswork and personal preferences and that's an anti pattern we need to reverse. Now we have a ux research team and ways to a/b test we can test different designs and see if they generate the correct behaviour. In this case I hope we will test to see if last modified at the top is driving more edits than putting it at the bottom. _______________________________________________

On 27 Mar 2015 7:44 am, "bawolff" <bawolff+wn(a)gmail.com> wrote: (which Sure. this is definitely one interpretation and you are probably right but I'm saying we should test and validate that hypothesis... Otherwise we are just making guesses (albeit good ones). it we designs will putting edited by volunteers (and thus make people at least aware they can edit. It still shocks me in 2015 that I have conversations with people who don't know they can edit). My point here is we should think about why we are doing things and what we are trying to achieve. I hear too many times: "I don't like this! This is ugly!" But when this doesn't have any qualitative reasoning this is pretty useless to the movement and seems to zap everyone's energy. I kicked off this thread just to bring up the point that this thread has confirmed which is many people are going to have different opinions around moving this bar (just like any design changes) and we need to make sure if we do make this change we can explain them and explain why it was the right thing to do. I'm confident the design team is thinking about these things.

On 28 Mar 2015 3:15 am, "Quim Gil" <qgil(a)wikimedia.org> wrote: http://mobile-reportcard.wmflabs.org/#other-graphs-tab. click. Sigh.. But as I said in my other email although this is a strong hypothesis this is guess work and we need to stop making changes without data. We have data that can tell us how many repeat users click the profile link vs the history link. We can check bounce rates on both page (do people quickly leave those pages after visiting). Why isn't our first reaction to test our hypothesis? Another hypothesis is that the last modified bar is too prominent and none of the links are interesting in it to the majority of our users (which is I guess the current design hypothesis) and they only click it by accident/out of curiosity. We can find this out by checking bounce rates with and without the bar. only way to find out is tapping on it, an action that a user not knowing about wiki page history might do more accidentally than on purpose. This string is underlined after visiting the page, but then it's too late. summary at the top that could provide interesting information to newcomers and regular editors alike, i.e.

On Sat, Mar 28, 2015 at 9:39 AM, MZMcBride <z(a)mzmcbride.com> wrote: Sigh. Nowhere am I arguing. I give up on this mailing list thread.

On 28/03/15 18:29, Jon Robson wrote: Why not? Even if you don't like the wording, the points may still be worth considering. That's the nature of any meaningful discussion - different points are brought up and considered, whether you call them 'points', 'ideas', 'arguments', 'opinions', or 'pine trees'. We consider, we address, we decide what to do for the time being, we move onto the next thing. We should always be arguing, though there are times when it should perhaps be done so more politely in order to keep it productive, indeed. -I

I vehemently disagree with almost every line you just wrote. Just to get that out there... DJ