Discussion:
[Design] Moving last modified to the bottom of the page on mobile
Jon Robson
2015-03-23 19:15:13 UTC
Permalink
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_recognition_to_mobile_WP_version.21
Jonathan Morgan
2015-03-23 20:46:15 UTC
Permalink
Interesting. What exactly is being tested by moving the "last edited by..."
down to the bottom?
Post by Jon Robson
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_recognition_to_mobile_WP_version.21
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
--
Jonathan T. Morgan
Community Research Lead
Wikimedia Foundation
User:Jmorgan (WMF) <https://meta.wikimedia.org/wiki/User:Jmorgan_(WMF)>
***@wikimedia.org
Ryan Kaldari
2015-03-23 20:57:06 UTC
Permalink
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
Post by Jon Robson
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_recognition_to_mobile_WP_version.21
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
Maryana Pinchuk
2015-03-23 21:26:01 UTC
Permalink
See:

* *http://blog.wikimedia.org/2013/09/25/humanizing-wikipedia-editing-mobile-experiments/
<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.
Post by Ryan Kaldari
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
Post by Jon Robson
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_recognition_to_mobile_WP_version.21
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
Ryan Kaldari
2015-03-23 21:46:24 UTC
Permalink
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
Post by Maryana Pinchuk
* *http://blog.wikimedia.org/2013/09/25/humanizing-wikipedia-editing-mobile-experiments/
<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.
Post by Ryan Kaldari
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
Post by Jon Robson
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_recognition_to_mobile_WP_version.21
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
Maryana Pinchuk
2015-03-24 00:23:33 UTC
Permalink
Post by Ryan Kaldari
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.
Post by Ryan Kaldari
Kaldari
Post by Maryana Pinchuk
* *http://blog.wikimedia.org/2013/09/25/humanizing-wikipedia-editing-mobile-experiments/
<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.
Post by Ryan Kaldari
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
Post by Jon Robson
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_recognition_to_mobile_WP_version.21
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
Kaity Hammerstein
2015-03-25 20:47:00 UTC
Permalink
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?
Post by Maryana Pinchuk
* *http://blog.wikimedia.org/2013/09/25/humanizing-wikipedia-editing-mobile-experiments/
<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.
Post by Ryan Kaldari
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
Post by Jon Robson
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_recognition_to_mobile_WP_version.21
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
Federico Leva (Nemo)
2015-03-25 21:02:09 UTC
Permalink
Among discussions, "experiments" and proposals, it's still unclear what
actually happened. Is there a Phabricator report outlining recent or
upcoming steps?
Post by Kaity Hammerstein
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.
Post by Kaity Hammerstein
I still really want to work on humanizing the editors
No idea what this means.
Post by Kaity Hammerstein
and letting people
know if an article is fresh.
That's not a particularly important goal.
Post by Kaity Hammerstein
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
Kaity Hammerstein
2015-03-25 21:20:31 UTC
Permalink
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.
Post by Federico Leva (Nemo)
Among discussions, "experiments" and proposals, it's still unclear what
actually happened. Is there a Phabricator report outlining recent or
upcoming steps?
Post by Kaity Hammerstein
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.
Post by Kaity Hammerstein
I still really want to work on humanizing the editors
No idea what this means.
and letting people
Post by Kaity Hammerstein
know if an article is fresh.
That's not a particularly important goal.
We can do better for sure. Maybe a design
Post by Kaity Hammerstein
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
https://lists.wikimedia.org/mailman/listinfo/design
Federico Leva (Nemo)
2015-03-25 21:42:47 UTC
Permalink
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.
Post by Kaity Hammerstein
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
Quim Gil
2015-03-26 22:12:42 UTC
Permalink
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.
Post by Federico Leva (Nemo)
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.
Post by Federico Leva (Nemo)
Post by Kaity Hammerstein
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?
Post by Federico Leva (Nemo)
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).
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.
Post by Federico Leva (Nemo)
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,
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.
Post by Federico Leva (Nemo)
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".
quiddity
2015-03-26 23:11:12 UTC
Permalink
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_strapline#Is_there_a_compromise.3F
Quim Gil
2015-03-26 23:39:41 UTC
Permalink
Post by quiddity
"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.
quiddity
2015-03-27 00:02:51 UTC
Permalink
Post by Quim Gil
Post by quiddity
"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).
Moushira Elamrawy
2015-03-27 00:07:07 UTC
Permalink
+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
Post by Quim Gil
Post by Quim Gil
Post by quiddity
"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
Post by Quim Gil
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
Post by Quim Gil
familiar as a friend, for a big percentage of our readers, an editor
sounds
Post by Quim Gil
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
Post by Quim Gil
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
https://lists.wikimedia.org/mailman/listinfo/design
Quim Gil
2015-03-27 09:11:01 UTC
Permalink
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)))
Jon Robson
2015-03-27 14:09:33 UTC
Permalink
On Fri, Mar 27, 2015 at 1:07 AM, Moushira Elamrawy <
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
https://lists.wikimedia.org/mailman/listinfo/design
bawolff
2015-03-27 14:44:48 UTC
Permalink
Post by Jon Robson
On Fri, Mar 27, 2015 at 1:07 AM, Moushira Elamrawy
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),
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).
Post by Jon Robson
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
Jon Robson
2015-03-27 16:26:39 UTC
Permalink
Post by bawolff
Post by Jon Robson
On Fri, Mar 27, 2015 at 1:07 AM, Moushira Elamrawy
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),
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).
Post by bawolff
Post by Jon Robson
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.
Quim Gil
2015-03-28 10:15:09 UTC
Permalink
Post by Jon Robson
The last editor is not that relevant (and quite often it will be a bot),
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.
Post by Jon Robson
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
Jon Robson
2015-03-28 16:23:58 UTC
Permalink
Post by Quim Gil
Post by Jon Robson
The last editor is not that relevant (and quite often it will be a bot),
http://mobile-reportcard.wmflabs.org/#other-graphs-tab.
Post by Quim Gil
"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.
Post by Quim Gil
"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.
Post by Quim Gil
Post by Jon Robson
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.
Post by Quim Gil
Post by Jon Robson
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
http://www.mediawiki.org/wiki/User:Qgil
_______________________________________________
Design mailing list
https://lists.wikimedia.org/mailman/listinfo/design
MZMcBride
2015-03-28 16:39:17 UTC
Permalink
Post by Jon Robson
The last editor is not that relevant (and quite often it will be a bot),
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...)?
Post by Jon Robson
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.
Post by Jon Robson
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
Jon Robson
2015-03-28 18:29:52 UTC
Permalink
Post by MZMcBride
Post by Jon Robson
The last editor is not that relevant (and quite often it will be a bot),
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.
Post by MZMcBride
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...)?
Post by Jon Robson
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.
Post by Jon Robson
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
https://lists.wikimedia.org/mailman/listinfo/design
Isarra Yos
2015-03-29 18:10:56 UTC
Permalink
Post by MZMcBride
Post by Jon Robson
The last editor is not that relevant (and quite often it will be a bot),
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
Quim Gil
2015-03-28 22:11:53 UTC
Permalink
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.
Post by MZMcBride
This is an incredibly spurious argument. You're manipulating the meaning
of data to fit your own purposes.
(...)
Post by MZMcBride
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.
MZMcBride
2015-03-29 21:02:47 UTC
Permalink
Post by Quim Gil
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
Derk-Jan Hartman
2015-04-07 17:07:56 UTC
Permalink
I vehemently disagree with almost every line you just wrote. Just to get that out there...

DJ
Post by MZMcBride
Post by Quim Gil
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
https://lists.wikimedia.org/mailman/listinfo/design
bawolff
2015-03-26 00:12:09 UTC
Permalink
Try 2...
You are not allowed to post to this mailing list, and your message has
been automatically rejected. If you think that your messages are
being rejected in error, contact the mailing list owner at
---------- Forwarded message ----------
Date: Wed, 25 Mar 2015 19:02:26 -0300
Subject: Re: [Design] Moving last modified to the bottom of the page on
mobile
Post by Kaity Hammerstein
By "What is this?" I mean the reader asking the question, "What is this
article about?"
Post by Kaity Hammerstein
For example, someone is learning about color theory. "What is
subtractive color?"
Post by Kaity Hammerstein
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.
Post by Kaity Hammerstein
The benefit of altering the last modified link is part of a redesign to
prioritize reader understanding.
That seems like a mighty specific example. There are very few topics that
can be concisely explained by a simple colour diagram to the same extent as
subtractive colour model can be with a venn diagram. (That said the general
goal of explaining things quickly sounds like a good one)
[To go offtopic. Im not even clear what the topic is here...] the last
modified bar has always rubbed me slightly the wrong way as it gives too
much visibility to the last author, almost implying that its his or her
work and not a collaborative work.
--bawolff
Continue reading on narkive:
Loading...