I'm still not convinced this is a good idea and this village pump post [1] seems to show its now just me (although there is also one of the opposite mindset).
Please do consider this in the redesign which has now been promoted to beta.
"Before in the mobile edition of Wikipedia, it showed at the top the hours or days since last revision and the user name. Now the username is not there. Bring it back and even consider it for the full desktop version. That is how we encourage people to update this site and not think some editorial board does it."
[1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Bring_back_...
Interesting. What exactly is being tested by moving the "last edited by..." down to the bottom?
On Mon, Mar 23, 2015 at 12:15 PM, Jon Robson jrobson@wikimedia.org wrote:
I'm still not convinced this is a good idea and this village pump post [1] seems to show its now just me (although there is also one of the opposite mindset).
Please do consider this in the redesign which has now been promoted to beta.
"Before in the mobile edition of Wikipedia, it showed at the top the hours or days since last revision and the user name. Now the username is not there. Bring it back and even consider it for the full desktop version. That is how we encourage people to update this site and not think some editorial board does it."
[1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Bring_back_...
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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@wikimedia.org wrote:
I'm still not convinced this is a good idea and this village pump post [1] seems to show its now just me (although there is also one of the opposite mindset).
Please do consider this in the redesign which has now been promoted to beta.
"Before in the mobile edition of Wikipedia, it showed at the top the hours or days since last revision and the user name. Now the username is not there. Bring it back and even consider it for the full desktop version. That is how we encourage people to update this site and not think some editorial board does it."
[1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Bring_back_...
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
See:
* *http://blog.wikimedia.org/2013/09/25/humanizing-wikipedia-editing-mobile-exp... http://blog.wikimedia.org/2013/09/25/humanizing-wikipedia-editing-mobile-experiments/* * https://www.mediawiki.org/wiki/Humanizing_features
"Experiment" is a terrible misnomer for this project. AFAIK, there was no specific hypothesis or set of metrics that the team was measuring around the time the strapline was launched; this was simply an attempt to update the design and make it look a little more, for lack of a better word, human. I would look at any work in this area as an ongoing visual design iteration (including the current work in alpha to move the strapline down), not an "experiment," unless there is a specific set of metrics we're trying to move one way or another.
In general, we need to start getting a lot better about bucketing our work into these types of user-facing categories ("experiment" versus "ongoing design iterations") and creating shared understanding both within the teams and in the community about what that means. Both kinds of work are totally valid and necessary – we don't have the time or resources to test every change we want to make, and for some things, we just need to trust ourselves and do what we think is right for our users, even if we can't measure exactly how it will impact the system. When we do have a specific hypothesis about how a change will impact the system for the better and some metrics we can measure to prove or disprove it – and only then! – we should call it an experiment. A healthy mix of both types of projects is necessary for ensuring that we're both being rigorous/data-informed AND not getting caught in analysis paralysis to make simple, quick, obvious changes.
On Mon, Mar 23, 2015 at 1:57 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
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@wikimedia.org wrote:
I'm still not convinced this is a good idea and this village pump post [1] seems to show its now just me (although there is also one of the opposite mindset).
Please do consider this in the redesign which has now been promoted to beta.
"Before in the mobile edition of Wikipedia, it showed at the top the hours or days since last revision and the user name. Now the username is not there. Bring it back and even consider it for the full desktop version. That is how we encourage people to update this site and not think some editorial board does it."
[1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Bring_back_...
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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@wikimedia.org wrote:
See:
http://blog.wikimedia.org/2013/09/25/humanizing-wikipedia-editing-mobile-experiments/*
"Experiment" is a terrible misnomer for this project. AFAIK, there was no specific hypothesis or set of metrics that the team was measuring around the time the strapline was launched; this was simply an attempt to update the design and make it look a little more, for lack of a better word, human. I would look at any work in this area as an ongoing visual design iteration (including the current work in alpha to move the strapline down), not an "experiment," unless there is a specific set of metrics we're trying to move one way or another.
In general, we need to start getting a lot better about bucketing our work into these types of user-facing categories ("experiment" versus "ongoing design iterations") and creating shared understanding both within the teams and in the community about what that means. Both kinds of work are totally valid and necessary – we don't have the time or resources to test every change we want to make, and for some things, we just need to trust ourselves and do what we think is right for our users, even if we can't measure exactly how it will impact the system. When we do have a specific hypothesis about how a change will impact the system for the better and some metrics we can measure to prove or disprove it – and only then! – we should call it an experiment. A healthy mix of both types of projects is necessary for ensuring that we're both being rigorous/data-informed AND not getting caught in analysis paralysis to make simple, quick, obvious changes.
On Mon, Mar 23, 2015 at 1:57 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
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@wikimedia.org wrote:
I'm still not convinced this is a good idea and this village pump post [1] seems to show its now just me (although there is also one of the opposite mindset).
Please do consider this in the redesign which has now been promoted to beta.
"Before in the mobile edition of Wikipedia, it showed at the top the hours or days since last revision and the user name. Now the username is not there. Bring it back and even consider it for the full desktop version. That is how we encourage people to update this site and not think some editorial board does it."
[1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Bring_back_...
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Mon, Mar 23, 2015 at 2:46 PM, Ryan Kaldari rkaldari@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.
I think since documentation is the kind of thing that tends to slip through the cracks, it probably makes sense for some combination of the Rule of Three to take effect to make sure everyone does their due diligence with respect to documentation: for big new projects/initiatives, devs should make sure technical docs are up to date on mw.org, CLs + PMs should create a space on meta or local wikis for a FAQ/high-level overview of the what and why, and designers should add a few mocks and help flesh out any UX or visual design related sections as needed.
That said, I still think it's going to be up to the team to decide what kind of changes merit this (non-trivial) amount of effort/time and when it's appropriate (e.g., a major overhaul of all the icons and design of the lead section of articles like the one we're playing with in alpha now certainly does need this level of documentation before it goes to stable, but probably not until it's closer to launch). And not every change is going to be worth it.
Kaldari
On Mon, Mar 23, 2015 at 2:26 PM, Maryana Pinchuk mpinchuk@wikimedia.org wrote:
See:
http://blog.wikimedia.org/2013/09/25/humanizing-wikipedia-editing-mobile-experiments/*
"Experiment" is a terrible misnomer for this project. AFAIK, there was no specific hypothesis or set of metrics that the team was measuring around the time the strapline was launched; this was simply an attempt to update the design and make it look a little more, for lack of a better word, human. I would look at any work in this area as an ongoing visual design iteration (including the current work in alpha to move the strapline down), not an "experiment," unless there is a specific set of metrics we're trying to move one way or another.
In general, we need to start getting a lot better about bucketing our work into these types of user-facing categories ("experiment" versus "ongoing design iterations") and creating shared understanding both within the teams and in the community about what that means. Both kinds of work are totally valid and necessary – we don't have the time or resources to test every change we want to make, and for some things, we just need to trust ourselves and do what we think is right for our users, even if we can't measure exactly how it will impact the system. When we do have a specific hypothesis about how a change will impact the system for the better and some metrics we can measure to prove or disprove it – and only then! – we should call it an experiment. A healthy mix of both types of projects is necessary for ensuring that we're both being rigorous/data-informed AND not getting caught in analysis paralysis to make simple, quick, obvious changes.
On Mon, Mar 23, 2015 at 1:57 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
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@wikimedia.org wrote:
I'm still not convinced this is a good idea and this village pump post [1] seems to show its now just me (although there is also one of the opposite mindset).
Please do consider this in the redesign which has now been promoted to beta.
"Before in the mobile edition of Wikipedia, it showed at the top the hours or days since last revision and the user name. Now the username is not there. Bring it back and even consider it for the full desktop version. That is how we encourage people to update this site and not think some editorial board does it."
[1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Bring_back_...
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
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@wikimedia.org wrote:
See:
http://blog.wikimedia.org/2013/09/25/humanizing-wikipedia-editing-mobile-experiments/*
"Experiment" is a terrible misnomer for this project. AFAIK, there was no specific hypothesis or set of metrics that the team was measuring around the time the strapline was launched; this was simply an attempt to update the design and make it look a little more, for lack of a better word, human. I would look at any work in this area as an ongoing visual design iteration (including the current work in alpha to move the strapline down), not an "experiment," unless there is a specific set of metrics we're trying to move one way or another.
In general, we need to start getting a lot better about bucketing our work into these types of user-facing categories ("experiment" versus "ongoing design iterations") and creating shared understanding both within the teams and in the community about what that means. Both kinds of work are totally valid and necessary – we don't have the time or resources to test every change we want to make, and for some things, we just need to trust ourselves and do what we think is right for our users, even if we can't measure exactly how it will impact the system. When we do have a specific hypothesis about how a change will impact the system for the better and some metrics we can measure to prove or disprove it – and only then! – we should call it an experiment. A healthy mix of both types of projects is necessary for ensuring that we're both being rigorous/data-informed AND not getting caught in analysis paralysis to make simple, quick, obvious changes.
On Mon, Mar 23, 2015 at 1:57 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
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@wikimedia.org wrote:
I'm still not convinced this is a good idea and this village pump post [1] seems to show its now just me (although there is also one of the opposite mindset).
Please do consider this in the redesign which has now been promoted to beta.
"Before in the mobile edition of Wikipedia, it showed at the top the hours or days since last revision and the user name. Now the username is not there. Bring it back and even consider it for the full desktop version. That is how we encourage people to update this site and not think some editorial board does it."
[1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Bring_back_...
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Maryana Pinchuk Product Manager, Wikimedia Foundation wikimediafoundation.org
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Among discussions, "experiments" and proposals, it's still unclear what actually happened. Is there a Phabricator report outlining recent or upcoming steps?
Kaity Hammerstein, 25/03/2015 21:47:
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?"
And the answer to the question is "this is a collaboratively edited wiki page". Seeing the history means immediately understanding that.
I still really want to work on humanizing the editors
No idea what this means.
and letting people know if an article is fresh.
That's not a particularly important goal.
We can do better for sure. Maybe a design brainstorm sometime in the future?
Why in the future? It would be nice to define what's the expected benefit of altering the "last modified" link, for instance. See question above.
Then sub-questions can be asked, for instance where the link should be, whether other messaging would be more effective, whether the mention of a username is needed, whether linking some random special page is useful, etc. etc. Many ideas were provided across the years and it's not clear which were considered.
Nemo
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@gmail.com wrote:
Among discussions, "experiments" and proposals, it's still unclear what actually happened. Is there a Phabricator report outlining recent or upcoming steps?
Kaity Hammerstein, 25/03/2015 21:47:
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?"
And the answer to the question is "this is a collaboratively edited wiki page". Seeing the history means immediately understanding that.
I still really want to work on humanizing the editors
No idea what this means.
and letting people
know if an article is fresh.
That's not a particularly important goal.
We can do better for sure. Maybe a design
brainstorm sometime in the future?
Why in the future? It would be nice to define what's the expected benefit of altering the "last modified" link, for instance. See question above.
Then sub-questions can be asked, for instance where the link should be, whether other messaging would be more effective, whether the mention of a username is needed, whether linking some random special page is useful, etc. etc. Many ideas were provided across the years and it's not clear which were considered.
Nemo
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Thanks Kairy for explaining more. I still don't know what happened. If something was merged or coded, please link patches. If something was decided, please link the decision.
Kaity Hammerstein, 25/03/2015 22:20:
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.
I'd say the contrary: for instance the app doesn't show a warning present on the page, which makes it harder to understand the real meaning (value, status) of the page. In your screenshots, apart from everything being so hard to read because of the flashy colours which made me blind for a second, the first thing I notice is the space taken by the search bar and the silly text flow around images (and tables). If your point is that a certain number of pixels in heights can be saved in favour of text, it's not clear to me why focus on the smallest item first. I suggest to a) compare apples to apples (i.e. your screenshot includes a location bar which is not relevant in a comparison to the app), b) identify which are the biggest wins possible and at what cost, c) communicate your findings clearly (e.g. in a phabricator report).
Nemo
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@gmail.com wrote:
Thanks Kairy for explaining more. I still don't know what happened. If something was merged or coded, please link patches. If something was decided, please link the decision.
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.
Kaity Hammerstein, 25/03/2015 22:20:
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.
I'd say the contrary: for instance the app doesn't show a warning present on the page, which makes it harder to understand the real meaning (value, status) of the page.
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?
In your screenshots, apart from everything being so hard to readbecause of the flashy colours which made me blind for a second, the first thing I notice is the space taken by the search bar and the silly text flow around images (and tables).
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.
If your point is that a certain number of pixels in heights can besaved in favour of text, it's not clear to me why focus on the smallest item first. I suggest to a) compare apples to apples (i.e. your screenshot includes a location bar which is not relevant in a comparison to the app), b) identify which are the biggest wins possible and at what cost,
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.
c) communicate your findings clearly (e.g. in a phabricator report).
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 Thu, Mar 26, 2015 at 3:12 PM, Quim Gil qgil@wikimedia.org wrote:
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".
Agreed.
In the discussion about this last year,[1] I suggested:
"I think the strapline could be usefully tweaked, to indicate that: "[dozens/hundreds/two] editors have worked on this article over its lifetime" - This would provide useful context for understanding articles-in-general, and also the individual-article being looked at. (i.e. I could see and think "it's only been edited by 1 person! Suspicion!").
[...]
Based on all the above, I would tentatively suggest changing the strapline to instead say something like:
"Last edited 10 months ago, by one of 245 editors"
and then on wikis that use an article-assessment system (ie. some Wikipedias, but not many), it could add that info:
"Last edited 10 months ago, by one of 3 editors. Stub-class quality."
.... [1] See rationales and details at the bottom of this sub-thread https://en.wikipedia.org/wiki/Wikipedia:Requests_for_comment/Mobile_site_str...
On Fri, Mar 27, 2015 at 12:11 AM, quiddity pandiculation@gmail.com wrote:
"Last edited 10 months ago, by one of 245 editors"
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.
On Thu, Mar 26, 2015 at 4:39 PM, Quim Gil qgil@wikimedia.org wrote:
On Fri, Mar 27, 2015 at 12:11 AM, quiddity pandiculation@gmail.com wrote:
"Last edited 10 months ago, by one of 245 editors"
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.
I meant to add in my previous message, I do like your tweak of saying "volunteers". I was primarily just copying my old message, to note that it had been suggested before - I'm not attached to any particular wording or ordering, but I do strongly agree with moving away from "naming a particular person" (for rationales detailed onwiki).
+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@gmail.com wrote:
On Thu, Mar 26, 2015 at 4:39 PM, Quim Gil qgil@wikimedia.org wrote:
On Fri, Mar 27, 2015 at 12:11 AM, quiddity pandiculation@gmail.com
wrote:
"Last edited 10 months ago, by one of 245 editors"
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.
I meant to add in my previous message, I do like your tweak of saying "volunteers". I was primarily just copying my old message, to note that it had been suggested before - I'm not attached to any particular wording or ordering, but I do strongly agree with moving away from "naming a particular person" (for rationales detailed onwiki).
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Fri, Mar 27, 2015 at 1:07 AM, Moushira Elamrawy melamrawy@wikimedia.org wrote:
The banner itself is currently driving traffic to the userpage (which
itself needs further iteration)
I think offering a link to the history of the page is better. The last editor is not that relevant (and quite often it will be a bot), but the history gives you a quick glance to the fact that this page has 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.
The history monile page is ok already today. It would benefit from a summary at the top that could provide interesting information to newcomers and regular editors alike, i.e.
This page was created on DD-MM-YYYY and has been edited N times by N registered volunteers and N anonymous users.
Improve it anonymously Log in / Register
(((for logged in users we could simply show the edit pencil icon)))
On 27 Mar 2015 2:11 am, "Quim Gil" qgil@wikimedia.org wrote:
On Fri, Mar 27, 2015 at 1:07 AM, Moushira Elamrawy <
melamrawy@wikimedia.org> wrote:
The banner itself is currently driving traffic to the userpage (which
itself needs further iteration)
I think offering a link to the history of the page is better.
We already do.
The last editor is not that relevant (and quite often it will be a bot),
Yet more people click on it for whatever reason: http://mobile-reportcard.wmflabs.org/#other-graphs-tab.
but the history gives you a quick glance to the fact that this page has
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.
The history monile page is ok already today. It would benefit from a
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?
This page was created on DD-MM-YYYY and has been edited N times by N
registered volunteers and N anonymous users.
Improve it anonymously Log in / Register
(((for logged in users we could simply show the edit pencil icon)))
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. _______________________________________________
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Fri, Mar 27, 2015 at 11:09 AM, Jon Robson jdlrobson@gmail.com wrote:
On 27 Mar 2015 2:11 am, "Quim Gil" qgil@wikimedia.org wrote:
On Fri, Mar 27, 2015 at 1:07 AM, Moushira Elamrawy melamrawy@wikimedia.org wrote:
The banner itself is currently driving traffic to the userpage (which itself needs further iteration)
I think offering a link to the history of the page is better.
We already do.
The last editor is not that relevant (and quite often it will be a bot),
Yet more people click on it for whatever reason: http://mobile-reportcard.wmflabs.org/#other-graphs-tab.
I don't think people realize that the date links to the history. I certainly didn't until someone told me.
In some ways that makes sense - users (I'm assuming) want to know who is writing this stuff, so they click on the name, as that's a person. But that presents skewed information where really they would be better served by the history page (Maybe anyways. That's making a lot of assumptions about user intentions which could be wrong).
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.
Is the goal of the last modified header to drive edits? Sure it implies that people like "me" can edit but it seems more like it would communicate to the reader the nature of the page they are reading as opposed to encourage them to actually edit.
--bawolff
On 27 Mar 2015 7:44 am, "bawolff" bawolff+wn@gmail.com wrote:
On Fri, Mar 27, 2015 at 11:09 AM, Jon Robson jdlrobson@gmail.com wrote:
On 27 Mar 2015 2:11 am, "Quim Gil" qgil@wikimedia.org wrote:
On Fri, Mar 27, 2015 at 1:07 AM, Moushira Elamrawy melamrawy@wikimedia.org wrote:
The banner itself is currently driving traffic to the userpage
(which
itself needs further iteration)
I think offering a link to the history of the page is better.
We already do.
The last editor is not that relevant (and quite often it will be a bot),
Yet more people click on it for whatever reason: http://mobile-reportcard.wmflabs.org/#other-graphs-tab.
I don't think people realize that the date links to the history. I certainly didn't until someone told me.
In some ways that makes sense - users (I'm assuming) want to know who is writing this stuff, so they click on the name, as that's a person. But that presents skewed information where really they would be better served by the history page (Maybe anyways. That's making a lot of assumptions about user intentions which could be wrong).
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).
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.
Is the goal of the last modified header to drive edits? Sure it implies that people like "me" can edit but it seems more like it would communicate to the reader the nature of the page they are reading as opposed to encourage them to actually edit.
From my understanding the idea was to help people realise that wikipedia is
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 Fri, Mar 27, 2015 at 3:09 PM, Jon Robson jdlrobson@gmail.com wrote:
The last editor is not that relevant (and quite often it will be a bot),
Yet more people click on it for whatever reason: http://mobile-reportcard.wmflabs.org/#other-graphs-tab.
Not for whatever reason. The string says:
"Last edited 6 months ago by P64"
"P64" is marked as bold in a line of plain text. Clearly an invitation to click.
"Last edited 6 months ago" has no visual indication of being a link. The 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.
The history monile page is ok already today. It would benefit from a 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?
You get two for the price of one!
Rephrase "Last edited..." in mobile web UI and link only to page history https://phabricator.wikimedia.org/T94298
Summary of activity at the top of mobile history page https://phabricator.wikimedia.org/T94297
On 28 Mar 2015 3:15 am, "Quim Gil" qgil@wikimedia.org wrote:
On Fri, Mar 27, 2015 at 3:09 PM, Jon Robson jdlrobson@gmail.com wrote:
The last editor is not that relevant (and quite often it will be a bot),
Yet more people click on it for whatever reason:
http://mobile-reportcard.wmflabs.org/#other-graphs-tab.
Not for whatever reason. The string says:
"Last edited 6 months ago by P64"
"P64" is marked as bold in a line of plain text. Clearly an invitation to
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.
"Last edited 6 months ago" has no visual indication of being a link. The
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.
The history monile page is ok already today. It would benefit from a
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?
You get two for the price of one!
Rephrase "Last edited..." in mobile web UI and link only to page history https://phabricator.wikimedia.org/T94298
Summary of activity at the top of mobile history page https://phabricator.wikimedia.org/T94297
-- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Jon Robson wrote:
On 27 Mar 2015 2:11 am, "Quim Gil" qgil@wikimedia.org wrote:
The last editor is not that relevant (and quite often it will be a bot),
Yet more people click on it for whatever reason: http://mobile-reportcard.wmflabs.org/#other-graphs-tab.
This is an incredibly spurious argument. You're manipulating the meaning of data to fit your own purposes. Is there _any_ bold link that you could place on top of every English Wikipedia mobile article that wouldn't receive substantial traffic given the overall amount of traffic that the site receives? Of course not.
You linked to this same graph to justify the existence of the horrible Special:UserProfile (i.e., "look, people are visiting it!"). Tell me, of the users who click on this username link in the mobile strapline, what percentage find the content helpful? What percentage immediately click back to the previous page? If you moved the strapline to the bottom of the article, how quickly would you stop citing a graph on wmflabs.org (trusted stats source that it is...)?
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.
You mean like pointing to a graph showing that a link placed very prominently somehow means that the underlying feature is a good idea? That kind of specious reasoning? The anti-pattern is your behavior here.
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.
Just to recap, you want to take a feature intended to humanize Wikipedia and turn it into a feature in which you can treat every visitor as a lab rat ready to be tested upon without their consent? Maybe instead of treating site visitors and readers as customers, we could treat them as colleagues and stop wasting their limited screen real estate with a relatively useless mobile strapline. Just a thought.
MZMcBride
On Sat, Mar 28, 2015 at 9:39 AM, MZMcBride z@mzmcbride.com wrote:
Jon Robson wrote:
On 27 Mar 2015 2:11 am, "Quim Gil" qgil@wikimedia.org wrote:
The last editor is not that relevant (and quite often it will be a bot),
Yet more people click on it for whatever reason: http://mobile-reportcard.wmflabs.org/#other-graphs-tab.
This is an incredibly spurious argument.
Sigh. Nowhere am I arguing. I give up on this mailing list thread.
You're manipulating the meaning of data to fit your own purposes. Is there _any_ bold link that you could place on top of every English Wikipedia mobile article that wouldn't receive substantial traffic given the overall amount of traffic that the site receives? Of course not.
You linked to this same graph to justify the existence of the horrible Special:UserProfile (i.e., "look, people are visiting it!"). Tell me, of the users who click on this username link in the mobile strapline, what percentage find the content helpful? What percentage immediately click back to the previous page? If you moved the strapline to the bottom of the article, how quickly would you stop citing a graph on wmflabs.org (trusted stats source that it is...)?
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.
You mean like pointing to a graph showing that a link placed very prominently somehow means that the underlying feature is a good idea? That kind of specious reasoning? The anti-pattern is your behavior here.
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.
Just to recap, you want to take a feature intended to humanize Wikipedia and turn it into a feature in which you can treat every visitor as a lab rat ready to be tested upon without their consent? Maybe instead of treating site visitors and readers as customers, we could treat them as colleagues and stop wasting their limited screen real estate with a relatively useless mobile strapline. Just a thought.
MZMcBride
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 28/03/15 18:29, Jon Robson wrote:
On Sat, Mar 28, 2015 at 9:39 AM, MZMcBride <z@mzmcbride.com mailto:z@mzmcbride.com> wrote:
Jon Robson wrote: >On 27 Mar 2015 2:11 am, "Quim Gil" <qgil@wikimedia.org <mailto:qgil@wikimedia.org>> wrote: >>The last editor is not that relevant (and quite often it will be a bot), > > Yet more people click on it for whatever reason: >http://mobile-reportcard.wmflabs.org/#other-graphs-tab. This is an incredibly spurious argument.Sigh. Nowhere am I arguing. I give up on this mailing list thread.
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
Jon, I'm still following the idea that this is like a group discussion in a table with pencils or dinner plates.
In this table some of us are volunteers that join the discussion, and give some ideas probably based more on subjective criteria than scientific data indeed. However, this is also our value: we come, bring some ideas with the best of the intentions, and then you (the ones in the table fully dedicated to this piece of software) evaluate, contrast, survey, test...
With my reply I wasn't trying to invalidate your point about trying options, gathering data, etc. On the contrary, I'm as convinced as you that this is the way to work. However, we cannot expect from volunteers and other occasional contributors to invest all this research before sharing an opinion. The full-time maintainers and experts are in a position of clear advantage here. Each one is valuable in our own roles.
The thread you started has produced and recovered some interesting ideas. I'm looking forward to the next steps.
On Sat, Mar 28, 2015 at 5:39 PM, MZMcBride z@mzmcbride.com wrote:
This is an incredibly spurious argument. You're manipulating the meaning of data to fit your own purposes.
(...)
That kind of specious reasoning? The anti-pattern is your behavior here.
Sorry, but the behavior in your reply constitutes an anti-pattern of collaboration in a friendly space. No bug or feature or difference of opinions justifies it. Please, let's be friendly, or at the very least respectful.
This thread seems to be exhausted indeed. I'll look for the continuation... hopefully in Phabricator, getting into tasks and details.
Quim Gil wrote:
Sorry, but the behavior in your reply constitutes an anti-pattern of collaboration in a friendly space. No bug or feature or difference of opinions justifies it. Please, let's be friendly, or at the very least respectful.
There's no indication that the Wikimedia Foundation mobile team is interested in collaboration. Years of evidence suggest that the team is only interested in shoving as many features as possible into the MobileFrontend extension to avoid scrutiny and review. The Wikimedia Foundation mobile team needs to re-integrate with the rest of the Wikimedia community. The past behavior of violating core Wikimedia design principles, such as prohibiting open editing with misleading error messages and discouraging new article creation by unilaterally removing red links, has been consistently unacceptable and it needs to stop.
Better than Phabricator tasks, there are Gerrit changesets waiting to be reviewed, but there's only been obstructionism from the mobile team. It's pretty tiring and any help you can provide in cleaning up this mess would definitely be appreciated. As it is, I'm still hoping we can kill the MobileFrontend extension in 2015, but it's a bit of a long shot.
I've been thinking about some mobile development principles. One easy principle seems to be, as a general rule, that mobile features are a strict subset of desktop site features. That is, if this mobile strapline is so important that it must be shouted at our users, using bold font and bright colors in a very prominent position, then there should at least be some parity with the desktop site. And there are, of course, lessons to be learned from the stripped down mobile interface. For example, if the sidebar links and paragraph of disclaimer text in the footer really aren't necessary, why include them on desktop? It's time for reconciliation here.
MZMcBride
I vehemently disagree with almost every line you just wrote. Just to get that out there...
DJ
On 29 mrt. 2015, at 23:02, MZMcBride z@mzmcbride.com wrote:
Quim Gil wrote:
Sorry, but the behavior in your reply constitutes an anti-pattern of collaboration in a friendly space. No bug or feature or difference of opinions justifies it. Please, let's be friendly, or at the very least respectful.
There's no indication that the Wikimedia Foundation mobile team is interested in collaboration. Years of evidence suggest that the team is only interested in shoving as many features as possible into the MobileFrontend extension to avoid scrutiny and review. The Wikimedia Foundation mobile team needs to re-integrate with the rest of the Wikimedia community. The past behavior of violating core Wikimedia design principles, such as prohibiting open editing with misleading error messages and discouraging new article creation by unilaterally removing red links, has been consistently unacceptable and it needs to stop.
Better than Phabricator tasks, there are Gerrit changesets waiting to be reviewed, but there's only been obstructionism from the mobile team. It's pretty tiring and any help you can provide in cleaning up this mess would definitely be appreciated. As it is, I'm still hoping we can kill the MobileFrontend extension in 2015, but it's a bit of a long shot.
I've been thinking about some mobile development principles. One easy principle seems to be, as a general rule, that mobile features are a strict subset of desktop site features. That is, if this mobile strapline is so important that it must be shouted at our users, using bold font and bright colors in a very prominent position, then there should at least be some parity with the desktop site. And there are, of course, lessons to be learned from the stripped down mobile interface. For example, if the sidebar links and paragraph of disclaimer text in the footer really aren't necessary, why include them on desktop? It's time for reconciliation here.
MZMcBride
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
