Hi everyone,
*tl;dr: We'll be stripping all content contained inside brackets from the first sentence of articles in the Wikipedia app.*
The Mobile Apps Team is focussed on making the app a beautiful and engaging reader experience, and trying to support use cases like wanting to look something up quickly to find what it is. Unfortunately, there are several aspects of Wikipedia at present that are actively detrimental to that goal. One example of this are the lead sentences.
As mentioned in the other thread on this matter https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008715.html, lead sentences are poorly formatted and contain information that is detrimental to quickly looking up a topic. The team did a quick audit https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BJ7uDgzO8IJT0M3UM2q-e5dM5Tzt6p7w1mgNAd-Z3WE/edit#gid=0 of the information available inside brackets in the first sentences, and typically it is pronunciation information which is probably better placed in the infobox rather than breaking up the first sentence. The other problem is that this information was typically inserted and previewed on a platform where space is not at a premium, and that calculation is different on mobile devices.
In order to better serve the quick lookup use case, the team has reached the decision to strip anything inside brackets in the first sentence of articles in the Wikipedia app.
Stripping content is not a decision to be made lightly. People took the time to write it, and that should be respected. We realise this is controversial. That said, it's the opinion of the team that the problem is pretty clear: this content is not optimised for users quickly looking things up on mobile devices at all, and will take a long time to solve through alternative means. A quicker solution is required.
The screenshots below are mockups of the before and after of the change. These are not final, I just put them together quickly to illustrate what I'm talking about.
- Before: http://i.imgur.com/VwKerbv.jpg - After: http://i.imgur.com/2A5PLmy.jpg
If you have any questions, let me know.
Thanks, Dan
I got the screenshots the wrong way around in my original email. They should be like this:
- Before: http://i.imgur.com/2A5PLmy.jpg - After: http://i.imgur.com/VwKerbv.jpg
Thanks, Dan
Would this also strip away something like a pointer to disambiguation pages or other common uses of the title? (I.e. "This is an article about the austrian composer did you mean the French football player?")
James Alexander Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Thu, Mar 12, 2015 at 6:11 PM, Dan Garry dgarry@wikimedia.org wrote:
I got the screenshots the wrong way around in my original email. They should be like this:
- Before: http://i.imgur.com/2A5PLmy.jpg
- After: http://i.imgur.com/VwKerbv.jpg
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On 12 March 2015 at 18:16, James Alexander jalexander@wikimedia.org wrote:
Would this also strip away something like a pointer to disambiguation pages or other common uses of the title? (I.e. "This is an article about the austrian composer did you mean the French football player?")
No. Not unless such links are contained inside brackets in what the user would consider to be the first sentence... which is never the case.
In fact, if you look at my screenshots, we're actually already stripping those links from being displayed and putting them behind a button, "Similar pages", to save UI space. This is a screenshot http://i.imgur.com/esKUIon.jpg of what happens when you tap on that button.
Dan
On Fri, Mar 13, 2015 at 2:11 AM, Dan Garry dgarry@wikimedia.org wrote:
I got the screenshots the wrong way around in my original email. They should be like this:
- Before: http://i.imgur.com/2A5PLmy.jpg
- After: http://i.imgur.com/VwKerbv.jpg
It would be one thing if you were simply moving this content, such as into a collapsable or non-collapsable div. If it was that, maybe it could be non-collapsed by default, with a remembered preference, based on whether the user collapses it.
Stripping it removes important information. Just clicking Special:Random, I come across some example:
* https://en.wikipedia.org/wiki/6610_Burwitz - there is no infobox, the information is not duplicated and is important. * https://en.wikipedia.org/wiki/Mozilla_Mail_%26_Newsgroups - important to know the alternative names here, no infobox * https://en.wikipedia.org/wiki/Ferdinando_Orlandi - no infobox, but important information in brackets * https://en.wikipedia.org/wiki/FVM_%C3%961_Tummelisa - important information to me, not really suited for the infobox
those are just some examples, and think it's bad idea to strip such information, imho.
I think it would be good to bring up the problem and ideas with the community. Maybe someone has a better idea.
Cheers Katie
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
I've been quiey about this discussion because I see Dan's point, on the other hand I think there should to be a better solution than hiding content in this way. I like Aude's idea of experimenting with a user preference for a collapsable div.
Pine On Apr 9, 2015 12:13 AM, "aude" aude.wiki@gmail.com wrote:
On Fri, Mar 13, 2015 at 2:11 AM, Dan Garry dgarry@wikimedia.org wrote:
I got the screenshots the wrong way around in my original email. They should be like this:
- Before: http://i.imgur.com/2A5PLmy.jpg
- After: http://i.imgur.com/VwKerbv.jpg
It would be one thing if you were simply moving this content, such as into a collapsable or non-collapsable div. If it was that, maybe it could be non-collapsed by default, with a remembered preference, based on whether the user collapses it.
Stripping it removes important information. Just clicking Special:Random, I come across some example:
- https://en.wikipedia.org/wiki/6610_Burwitz - there is no infobox, the
information is not duplicated and is important.
to know the alternative names here, no infobox
- https://en.wikipedia.org/wiki/Ferdinando_Orlandi - no infobox, but
important information in brackets
information to me, not really suited for the infobox
those are just some examples, and think it's bad idea to strip such information, imho.
I think it would be good to bring up the problem and ideas with the community. Maybe someone has a better idea.
Cheers Katie
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- @wikimediadc / @wikidata
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Thu, Apr 9, 2015 at 9:12 AM, aude aude.wiki@gmail.com wrote:
On Fri, Mar 13, 2015 at 2:11 AM, Dan Garry dgarry@wikimedia.org wrote:
I got the screenshots the wrong way around in my original email. They should be like this:
- Before: http://i.imgur.com/2A5PLmy.jpg
- After: http://i.imgur.com/VwKerbv.jpg
It would be one thing if you were simply moving this content, such as into a collapsable or non-collapsable div. If it was that, maybe it could be non-collapsed by default, with a remembered preference, based on whether the user collapses it.
Just want to add that I am not sure doing even this is a good idea or perhaps not in this exact way.
Maybe an wrapping in a span tag, inline would be better or maybe these suggestions are terrible idea. Someone might have better idea :)
Cheers, Katie
Stripping it removes important information. Just clicking Special:Random, I come across some example:
- https://en.wikipedia.org/wiki/6610_Burwitz - there is no infobox, the
information is not duplicated and is important.
to know the alternative names here, no infobox
- https://en.wikipedia.org/wiki/Ferdinando_Orlandi - no infobox, but
important information in brackets
information to me, not really suited for the infobox
those are just some examples, and think it's bad idea to strip such information, imho.
I think it would be good to bring up the problem and ideas with the community. Maybe someone has a better idea.
Cheers Katie
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- @wikimediadc / @wikidata
A few notes:
1. Will it be done only in English or also in other languages? In particular, what about languages that don't use the '(' and ')' characters, such as Chinese?
2. Can this be made optional for people who really want to see it? (I know it sounds like xkcd 1172, but still.)
3. A counter-example of something in parentheses that can be useful: https://en.wikipedia.org/wiki/Square_and_Compasses .
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2015-03-13 3:07 GMT+02:00 Dan Garry dgarry@wikimedia.org:
Hi everyone,
*tl;dr: We'll be stripping all content contained inside brackets from the first sentence of articles in the Wikipedia app.*
The Mobile Apps Team is focussed on making the app a beautiful and engaging reader experience, and trying to support use cases like wanting to look something up quickly to find what it is. Unfortunately, there are several aspects of Wikipedia at present that are actively detrimental to that goal. One example of this are the lead sentences.
As mentioned in the other thread on this matter https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008715.html, lead sentences are poorly formatted and contain information that is detrimental to quickly looking up a topic. The team did a quick audit https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BJ7uDgzO8IJT0M3UM2q-e5dM5Tzt6p7w1mgNAd-Z3WE/edit#gid=0 of the information available inside brackets in the first sentences, and typically it is pronunciation information which is probably better placed in the infobox rather than breaking up the first sentence. The other problem is that this information was typically inserted and previewed on a platform where space is not at a premium, and that calculation is different on mobile devices.
In order to better serve the quick lookup use case, the team has reached the decision to strip anything inside brackets in the first sentence of articles in the Wikipedia app.
Stripping content is not a decision to be made lightly. People took the time to write it, and that should be respected. We realise this is controversial. That said, it's the opinion of the team that the problem is pretty clear: this content is not optimised for users quickly looking things up on mobile devices at all, and will take a long time to solve through alternative means. A quicker solution is required.
The screenshots below are mockups of the before and after of the change. These are not final, I just put them together quickly to illustrate what I'm talking about.
- Before: http://i.imgur.com/VwKerbv.jpg
- After: http://i.imgur.com/2A5PLmy.jpg
If you have any questions, let me know.
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
It is a totally valid concern in terms of readability, and kudos to everyone who put time and energy to investigate solutions for it, however, in addition to all what Amir asked:
1. Is there a chance to expand the quick audit? Do we have any estimate of many articles will be negatively affected, as the example Amir mentioned
2. What is the cost of adding an option of "view original text" in right panel, with articles that will have this kind of display? (at the end of the day, information between brackets is_always_ good to know). Or else, "view lite edition" while keeping original text as default.
3. How does this work with editing? ..and excuse the ridiculous example, but what happens if, from mobile I made a small edit that contained brackets, to the first lines?
4. Is this the best approach? Am quoting from Dan's earlier email, where I totally agree with: " *the long term solution is, at least to me, to invest in is getting our engaged readers to write clear, coherent Wikidata descriptions. These can then be used across all platforms to support that workflow.*" or other ideas similar ideas. I would just worry to have this implemented and left to run without another longer term strategy being planned besides.
Many Thanks :-) M
On Fri, Mar 13, 2015 at 12:25 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
A few notes:
- Will it be done only in English or also in other languages? In
particular, what about languages that don't use the '(' and ')' characters, such as Chinese?
- Can this be made optional for people who really want to see it? (I know
it sounds like xkcd 1172, but still.)
- A counter-example of something in parentheses that can be useful:
https://en.wikipedia.org/wiki/Square_and_Compasses .
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2015-03-13 3:07 GMT+02:00 Dan Garry dgarry@wikimedia.org:
Hi everyone,
*tl;dr: We'll be stripping all content contained inside brackets from the first sentence of articles in the Wikipedia app.*
The Mobile Apps Team is focussed on making the app a beautiful and engaging reader experience, and trying to support use cases like wanting to look something up quickly to find what it is. Unfortunately, there are several aspects of Wikipedia at present that are actively detrimental to that goal. One example of this are the lead sentences.
As mentioned in the other thread on this matter https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008715.html, lead sentences are poorly formatted and contain information that is detrimental to quickly looking up a topic. The team did a quick audit https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BJ7uDgzO8IJT0M3UM2q-e5dM5Tzt6p7w1mgNAd-Z3WE/edit#gid=0 of the information available inside brackets in the first sentences, and typically it is pronunciation information which is probably better placed in the infobox rather than breaking up the first sentence. The other problem is that this information was typically inserted and previewed on a platform where space is not at a premium, and that calculation is different on mobile devices.
In order to better serve the quick lookup use case, the team has reached the decision to strip anything inside brackets in the first sentence of articles in the Wikipedia app.
Stripping content is not a decision to be made lightly. People took the time to write it, and that should be respected. We realise this is controversial. That said, it's the opinion of the team that the problem is pretty clear: this content is not optimised for users quickly looking things up on mobile devices at all, and will take a long time to solve through alternative means. A quicker solution is required.
The screenshots below are mockups of the before and after of the change. These are not final, I just put them together quickly to illustrate what I'm talking about.
- Before: http://i.imgur.com/VwKerbv.jpg
- After: http://i.imgur.com/2A5PLmy.jpg
If you have any questions, let me know.
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Hey Amir,
Thanks for your comments. I'm always appreciative of how you get us thinking about the broader problem! Responses in-line.
On 13 March 2015 at 03:25, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
- Will it be done only in English or also in other languages? In
particular, what about languages that don't use the '(' and ')' characters, such as Chinese?
For those languages, we'll still be running the stripping, but obviously if there are no such characters in the first sentence (because those characters are not used), nothing will be stripped.
- Can this be made optional for people who really want to see it? (I know
it sounds like xkcd 1172, but still.)
I refer you to the email I sent to Florian half an hour ago for an answer to this one.
- A counter-example of something in parentheses that can be useful:
Indeed, and it's unfortunate that such information will be lost. But that kind of highlights the problem, which is that there's no consistent model for what's included in brackets in the first sentence. The tradeoff is a difficult one to make because of cases exactly like this, and it leaves us feeling somewhat uneasy, but I'm of the belief that, on balance, it's a helpful change.
For what it's worth, I added this article to the quick audit https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BJ7uDgzO8IJT0M3UM2q-e5dM5Tzt6p7w1mgNAd-Z3WE/edit#gid=0 we did, as an example of information that's lost by what we're proposing.
Thanks, Dan
On 03/12/2015 06:07 PM, Dan Garry wrote:
Stripping content is not a decision to be made lightly. People took the time to write it, and that should be respected. We realise this is controversial. That said, it's the opinion of the team that the problem is pretty clear: this content is not optimised for users quickly looking things up on mobile devices at all, and will take a long time to solve through alternative means. A quicker solution is required.
Yes, this is controversial and probably needs wider discussion outside of this mainly technically-focused list.
I'm concerned with this being a slippery slope. Part of the problem that I see is that the content being controlled by the apps rather than on-wiki. I don't really have any better ideas than something similar to class="metadata" which TextExtracts removes though.
-- Legoktm
Hi,
On Mar 15, 2015 19:20, "Legoktm" legoktm.wikipedia@gmail.com wrote:
Yes, this is controversial and probably needs wider discussion outside of this mainly technically-focused list.
agreed. has that happened?
This is something that needs community discussion on-wiki as well as announcement on wikitech-ambassadors@lists.w.o
Is this intended for web too or just app?
I'm concerned with this being a slippery slope. Part of the problem that I see is that the content being controlled by the apps rather than on-wiki. I don't really have any better ideas than something similar to class="metadata" which TextExtracts removes though.
Is there a team (or even a phabricator project) responsible for tracking, prioritizing, implementing, etc the use of standard templates, element IDs, microformats and semantic markup?
What teams and external users need what structure?
Then maybe you can differentiate between unrelated bracket scenarios (pronunciation vs. aka name vs. dates vs. transliteration) by the markup. And if heuristics are absolutely necessary then there should be a way for editors to override the heuristic for a particular case adhoc. And to later for an editor to reset that case back to deferring to the heuristic.
There should be a way for a desktop editor to see from the desktop site what will be hidden from or shown to app readers and mobile web readers.
-Jeremy
Hi Jeremy,
Thanks for the feedback. Responses in-line.
On 8 April 2015 at 20:56, Jeremy Baron jeremy@tuxmachine.com wrote:
agreed. has that happened?
This is something that needs community discussion on-wiki as well as announcement on wikitech-ambassadors@lists.w.o
I am interested in constructive feedback and discussion on how to solve the problem of first sentences not being very readable on mobile devices. Feel free to begin such a discussion. Moushira, the Community Liaison for the Mobile Teams, would probably be interested in helping you out. :-)
In the mean time though, the perfect cannot be the enemy of the good. The team intends to proceed with this until a more firm solution is found for the problem of first sentences being difficult to read on mobile devices due to screen space.
Is this intended for web too or just app?
This change is only in the app right now.
I personally would like to see this change adopted on mobile web, as the rationale for mobile web and mobile apps is the same. Something like this would also be nice for desktop, but it's nowhere near as critical as desktop devices typically have much more screen space to work with.
Is there a team (or even a phabricator project) responsible for tracking,
prioritizing, implementing, etc the use of standard templates, element IDs, microformats and semantic markup?
Not right now. I think there should be!
There should be a way for a desktop editor to see from the desktop site
what will be hidden from or shown to app readers and mobile web readers.
Absolutely agreed. A large part of what caused this problem is a lack of awareness of how things look on other devices. It's not feasible to expect users to check every change they make on their mobile phone... or to expect all users to even have mobile phones. The software should support them.
In my opinion the preview screen should support the ability to preview how a change will look on a mobile device. This is nontrivial for a variety of reasons.
Dan
On 9 apr. 2015, at 06:45, Dan Garry dgarry@wikimedia.org wrote:
I am interested in constructive feedback and discussion on how to solve the problem of first sentences not being very readable on mobile devices. Feel free to begin such a discussion. Moushira, the Community Liaison for the Mobile Teams, would probably be interested in helping you out. :-)
In the mean time though, the perfect cannot be the enemy of the good. The team intends to proceed with this until a more firm solution is found for the problem of first sentences being difficult to read on mobile devices due to screen space.
This is me waving my red flag and telling you that you are walking into/picking a huge fight with ‘the community’. You can’t win anything here, there will only be losers.
If you want to convince users that something needs to be done here, you should consider handing tools to the community to detect that something is wrong. Like https://meta.wikimedia.org/wiki/File_metadata_cleanup_drive
It’s hugely inefficient, but empower the user, instead of making decisions for him.
DJ
Hey Derk-Jan,
Thanks for chiming in. It's great to have your input.
On 8 April 2015 at 23:22, Derk-Jan Hartman d.j.hartman+wmf_ml@gmail.com wrote:
This is me waving my red flag and telling you that you are walking into/picking a huge fight with ‘the community’. You can’t win anything here, there will only be losers.
As a long time community member myself, I am aware of how contentious this change is. But I disagree that there will only be losers, as there are plenty of readers who will benefit from the change.
If you want to convince users that something needs to be done here, you should consider handing tools to the community to detect that something is wrong. Like https://meta.wikimedia.org/wiki/File_metadata_cleanup_drive
I'd love to solve this more systematically. What are your suggestions for how we could do that? We've not had much luck thinking of any so far.
Dan
Dan Garry, 09/04/2015 06:45:
agreed. has that happened? This is something that needs community discussion on-wiki as well as announcement on wikitech-ambassadors@lists.w.oI am interested in constructive feedback and discussion on how to solve the problem of first sentences not being very readable on mobile devices. Feel free to begin such a discussion.
"Feel free to do my job for me" is not an appropriate answer to a volunteer. Cc Rachel.
Nemo
Cc noted (inline) :)
On Thu, Apr 9, 2015 at 12:25 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Dan Garry, 09/04/2015 06:45:
agreed. has that happened? This is something that needs community discussion on-wiki as well as announcement on wikitech-ambassadors@lists.w.oI am interested in constructive feedback and discussion on how to solve the problem of first sentences not being very readable on mobile devices. Feel free to begin such a discussion.
"Feel free to do my job for me" is not an appropriate answer to a volunteer. Cc Rachel.
Nemo, while I have always deeply appreciated your level of engagement, I'm not sure that was necessary. It sounds like there's frustration around roles, but part of what empowers everyone within this movement is that one is able to begin a discussion on how to improve something. Has that ever stopped someone in the past? What's stopping you now? Am I missing something?
I welcome conversation about roles of volunteers or any other frustrations about communication and collaboration on my Meta talk page or via email (it would probably be counter-productive to get into this on this thread).
Cheers, rachel
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
We are also looking into implementing “Article Previews” over the next couple months. As a middle ground it may be a good idea that we sanitze the sentence in the preview, but leave it untouched in the article. Best of both worlds?
On Thu, Apr 9, 2015 at 5:47 PM, Rachel diCerbo rdicerb@wikimedia.org wrote:
Cc noted (inline) :)
On Thu, Apr 9, 2015 at 12:25 AM, Federico Leva (Nemo) nemowiki@gmail.com wrote:
Dan Garry, 09/04/2015 06:45:
agreed. has that happened? This is something that needs community discussion on-wiki as well as announcement on wikitech-ambassadors@lists.w.oI am interested in constructive feedback and discussion on how to solve the problem of first sentences not being very readable on mobile devices. Feel free to begin such a discussion.
"Feel free to do my job for me" is not an appropriate answer to a volunteer. Cc Rachel.
Nemo, while I have always deeply appreciated your level of engagement, I'm not sure that was necessary. It sounds like there's frustration around roles, but part of what empowers everyone within this movement is that one is able to begin a discussion on how to improve something. Has that ever stopped someone in the past? What's stopping you now? Am I missing something?
I welcome conversation about roles of volunteers or any other frustrations about communication and collaboration on my Meta talk page or via email (it would probably be counter-productive to get into this on this thread).
Cheers, rachel
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Rachel diCerbo Director of Community Engagement (Product) Wikimedia Foundation Rdicerb (WMF) https://meta.wikimedia.org/wiki/User_talk:Rdicerb_%28WMF%29 @a_rachel https://twitter.com/a_rachel
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Corey, I'm not entirely sure what you mean. Could you expand? Where is this preview meant to be shown (where does the reader and/or editor see it) and so what are you thinking would be the work flow to see the sanitized version vs the article version you describe?.
James Alexander Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Thu, Apr 9, 2015 at 3:53 PM, Corey Floyd cfloyd@wikimedia.org wrote:
We are also looking into implementing “Article Previews” over the next couple months. As a middle ground it may be a good idea that we sanitze the sentence in the preview, but leave it untouched in the article. Best of both worlds?
On Thu, Apr 9, 2015 at 5:47 PM, Rachel diCerbo rdicerb@wikimedia.org wrote:
Cc noted (inline) :)
On Thu, Apr 9, 2015 at 12:25 AM, Federico Leva (Nemo) <nemowiki@gmail.com
wrote:
Dan Garry, 09/04/2015 06:45:
agreed. has that happened? This is something that needs community discussion on-wiki as well as announcement on wikitech-ambassadors@lists.w.oI am interested in constructive feedback and discussion on how to solve the problem of first sentences not being very readable on mobile devices. Feel free to begin such a discussion.
"Feel free to do my job for me" is not an appropriate answer to a volunteer. Cc Rachel.
Nemo, while I have always deeply appreciated your level of engagement, I'm not sure that was necessary. It sounds like there's frustration around roles, but part of what empowers everyone within this movement is that one is able to begin a discussion on how to improve something. Has that ever stopped someone in the past? What's stopping you now? Am I missing something?
I welcome conversation about roles of volunteers or any other frustrations about communication and collaboration on my Meta talk page or via email (it would probably be counter-productive to get into this on this thread).
Cheers, rachel
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Rachel diCerbo Director of Community Engagement (Product) Wikimedia Foundation Rdicerb (WMF) https://meta.wikimedia.org/wiki/User_talk:Rdicerb_%28WMF%29 @a_rachel https://twitter.com/a_rachel
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
The preview will be shown when someone taps a link, before loading the article.
I’d like to stress that this is very early stages. Here is the phabricator ticket explaining the feature:
EPIC: As a mobile reader, I would like links that I tap on to show quick previews so that I can choose whether to navigate to it or not. https://phabricator.wikimedia.org/T94630
On Thu, Apr 9, 2015 at 6:59 PM, James Alexander jalexander@wikimedia.org wrote:
Corey, I'm not entirely sure what you mean. Could you expand? Where is this preview meant to be shown (where does the reader and/or editor see it) and so what are you thinking would be the work flow to see the sanitized version vs the article version you describe?.
James Alexander Community Advocacy Wikimedia Foundation (415) 839-6885 x6716 @jamesofur
On Thu, Apr 9, 2015 at 3:53 PM, Corey Floyd cfloyd@wikimedia.org wrote:
We are also looking into implementing “Article Previews” over the next couple months. As a middle ground it may be a good idea that we sanitze the sentence in the preview, but leave it untouched in the article. Best of both worlds?
On Thu, Apr 9, 2015 at 5:47 PM, Rachel diCerbo rdicerb@wikimedia.org wrote:
Cc noted (inline) :)
On Thu, Apr 9, 2015 at 12:25 AM, Federico Leva (Nemo) < nemowiki@gmail.com> wrote:
Dan Garry, 09/04/2015 06:45:
agreed. has that happened? This is something that needs community discussion on-wiki as wellas announcement on wikitech-ambassadors@lists.w.o
I am interested in constructive feedback and discussion on how to solve the problem of first sentences not being very readable on mobile devices. Feel free to begin such a discussion.
"Feel free to do my job for me" is not an appropriate answer to a volunteer. Cc Rachel.
Nemo, while I have always deeply appreciated your level of engagement, I'm not sure that was necessary. It sounds like there's frustration around roles, but part of what empowers everyone within this movement is that one is able to begin a discussion on how to improve something. Has that ever stopped someone in the past? What's stopping you now? Am I missing something?
I welcome conversation about roles of volunteers or any other frustrations about communication and collaboration on my Meta talk page or via email (it would probably be counter-productive to get into this on this thread).
Cheers, rachel
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
--
Rachel diCerbo Director of Community Engagement (Product) Wikimedia Foundation Rdicerb (WMF) https://meta.wikimedia.org/wiki/User_talk:Rdicerb_%28WMF%29 @a_rachel https://twitter.com/a_rachel
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
-- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Thu, Apr 9, 2015 at 10:53 PM, Corey Floyd cfloyd@wikimedia.org wrote:
We are also looking into implementing “Article Previews” over the next couple months. As a middle ground it may be a good idea that we sanitze the sentence in the preview, but leave it untouched in the article. Best of both worlds?
that middle ground seems to be exactly what's described in recent edit summaries.
* https://gerrit.wikimedia.org/r/#/q/bug:96871,n,z * https://phabricator.wikimedia.org/T96871
-Jeremy
On 13 March 2015 at 01:07, Dan Garry dgarry@wikimedia.org wrote:
tl;dr: We'll be stripping all content contained inside brackets from the first sentence of articles in the Wikipedia app.
Having enjoyed meeting and breaking bread with members of the mobile team at Wikimania last year, I'm saddened to once again be taking issue with yet another of your plans.
You will recall my concern at the removal and continued absence of the map-based "nearby" feature.
The problems I highlighted with your cropping of header images are unresolved.
I recently highlighted accessibility problems created by the new feature for posting images of text: https://blog.wikimedia.org/2015/04/02/share-a-fact-with-friends-on-android-a...
And now this; others have already explained the problems inherent in it. I'll add the use case of works with parenthetical titles, such as:
https://en.wikipedia.org/wiki/New_Amerykah_Part_One_(4th_World_War)
In each case, it seems that an announcement is made: "we are going to do this". Lila has recently written (I paraphrase) of the need to bring the WMF's actions, regarding technical changes, and the wishes of the community closer together.
I'd like to see that evidenced in changes to the way modifications to the mobile app (and mobile website) are proposed, considered and implemented.
A blast from the past!
Only now I noticed that text in brackets is back now.
I may have missed it, but I don't remember that this was announced anywhere. I'm curious, what was the thinking behind restoring it?
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
בתאריך יום ו׳, 13 במרץ 2015 ב-3:07 מאת Dan Garry <dgarry@wikimedia.org >:
Hi everyone,
*tl;dr: We'll be stripping all content contained inside brackets from the first sentence of articles in the Wikipedia app.*
The Mobile Apps Team is focussed on making the app a beautiful and engaging reader experience, and trying to support use cases like wanting to look something up quickly to find what it is. Unfortunately, there are several aspects of Wikipedia at present that are actively detrimental to that goal. One example of this are the lead sentences.
As mentioned in the other thread on this matter https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008715.html, lead sentences are poorly formatted and contain information that is detrimental to quickly looking up a topic. The team did a quick audit https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BJ7uDgzO8IJT0M3UM2q-e5dM5Tzt6p7w1mgNAd-Z3WE/edit#gid=0 of the information available inside brackets in the first sentences, and typically it is pronunciation information which is probably better placed in the infobox rather than breaking up the first sentence. The other problem is that this information was typically inserted and previewed on a platform where space is not at a premium, and that calculation is different on mobile devices.
In order to better serve the quick lookup use case, the team has reached the decision to strip anything inside brackets in the first sentence of articles in the Wikipedia app.
Stripping content is not a decision to be made lightly. People took the time to write it, and that should be respected. We realise this is controversial. That said, it's the opinion of the team that the problem is pretty clear: this content is not optimised for users quickly looking things up on mobile devices at all, and will take a long time to solve through alternative means. A quicker solution is required.
The screenshots below are mockups of the before and after of the change. These are not final, I just put them together quickly to illustrate what I'm talking about.
- Before: http://i.imgur.com/VwKerbv.jpg
- After: http://i.imgur.com/2A5PLmy.jpg
If you have any questions, let me know.
Thanks, Dan
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation _______________________________________________ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l