Hi Dan!
I'm fine with solutions, that try to save space and put as much meaningful content as possible to the first view (available without scrolling) to the app. I'm wondering, if this new feature will be behind a feature flag in the settings of the app?
Like you said, stripping (or adding) content to or from a wikipedia article is very controversial, so i think the user should have the possibility to turn on (or off) the feature (i'm fine with default "on") to change the content in this way, or implement a setting to turn off _all_ changes to the content, so a user can see the plain wikipedia article without any changes?
Kind reagrds,
Florian
Freundliche Grüße Florian Schmidt
-----Original-Nachricht-----
Betreff: [WikimediaMobile] [Apps] Stripping content inside brackets from the first sentence of articles
Datum: Fri, 13 Mar 2015 02:07:34 +0100
Von: Dan Garry dgarry@wikimedia.org
An: mobile-l mobile-l@lists.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 [1], lead sentences are poorly formatted and contain information that is detrimental to quickly looking up a topic. The team did a quick audit [2] 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 [3] *After: http://i.imgur.com/2A5PLmy.jpg [4]
If you have any questions, let me know. Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Links: ------ [1] https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008715.html [2] https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BJ7uDgzO8IJT0M3UM2q-... [3] http://i.imgur.com/VwKerbv.jpg [4] http://i.imgur.com/2A5PLmy.jpg
Hi Florian,
Thanks for the feedback!
Adding options for everything into the settings is a very slippery slope. If you want examples of where it can end up, take a look at your settings on Wikipedia! Tabs and tabs of options, many of which you don't even realise exist. Ultimate customisation seems like a good thing on the surface, but it creates tangled messes like that one. And it creates a nightmare for customer support, too; the user has to recount all the options they have turned on for you to reproduce their problems. VisualEditor is a good example of this, as it frequently breaks due to user CSS/JS that the user didn't even realise they had.
The other thing to consider about this is the development overhead. For every option we have, we're adding an extra combination of settings that we'd need to test and support. Those combinations grow exponentially with each option that's added; so if you've got four settings then that's 16 combinations... and adding a fifth option increases that to 32! So we must only add options for things that are truly the most important things, and supporting suboptimal layouts with an option doesn't seem worth that tradeoff to me.
Thanks, Dan
On 12 March 2015 at 23:32, florian.schmidt.welzow@t-online.de < florian.schmidt.welzow@t-online.de> wrote:
Hi Dan!
I'm fine with solutions, that try to save space and put as much meaningful content as possible to the first view (available without scrolling) to the app. I'm wondering, if this new feature will be behind a feature flag in the settings of the app?
Like you said, stripping (or adding) content to or from a wikipedia article is very controversial, so i think the user should have the possibility to turn on (or off) the feature (i'm fine with default "on") to change the content in this way, or implement a setting to turn off _all_ changes to the content, so a user can see the plain wikipedia article without any changes?
Kind reagrds,
Florian
Freundliche Grüße Florian Schmidt
-----Original-Nachricht-----
Betreff: [WikimediaMobile] [Apps] Stripping content inside brackets from the first sentence of articles
Datum: Fri, 13 Mar 2015 02:07:34 +0100
Von: Dan Garry dgarry@wikimedia.org
An: mobile-l mobile-l@lists.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
Hi Dan,
thanks for your fast answer :)
I know what you mean, and I know, that a start of much settings increases the time you need to support these. But think about the problem: The content is the _most_ important thing we have to support in and with MediaWiki, it’s, apart from editing, the focus object we have :) Now you’re (as the only team) strip some text from the user contributed content, and I’m sure, this step wasn’t so easy for you and took a long discussion with the team and I fully support this change, because it will be a really good and cool feature for the environment of mobile. But, in fact, you still massively change the content of the article, which the community can’t control (if the still want to use brackets, which I support, too). And what if I use the app on my Nexus 7 or other tablet’s? There is enough space to show the plain version of the article, but I can’t? Hmm, not so good :)
So, in my point of view, it’s a big change you made, which can be a big advantage for the user, but it still has a big importance, big enough to add it behind a feature flag. I don’t say, that the app need (or should have) a setting for each feature, but I think one setting to turn on/off _all_ content stripping/adding (if there, maybe, will follow others) would be good :)
Best, Florian
Von: Dan Garry [mailto:dgarry@wikimedia.org] Gesendet: Freitag, 13. März 2015 15:57 An: florian.schmidt.welzow@t-online.de Cc: mobile-l Betreff: Re: [WikimediaMobile] [Apps] Stripping content inside brackets from the first sentence of articles
Hi Florian,
Thanks for the feedback!
Adding options for everything into the settings is a very slippery slope. If you want examples of where it can end up, take a look at your settings on Wikipedia! Tabs and tabs of options, many of which you don't even realise exist. Ultimate customisation seems like a good thing on the surface, but it creates tangled messes like that one. And it creates a nightmare for customer support, too; the user has to recount all the options they have turned on for you to reproduce their problems. VisualEditor is a good example of this, as it frequently breaks due to user CSS/JS that the user didn't even realise they had.
The other thing to consider about this is the development overhead. For every option we have, we're adding an extra combination of settings that we'd need to test and support. Those combinations grow exponentially with each option that's added; so if you've got four settings then that's 16 combinations... and adding a fifth option increases that to 32! So we must only add options for things that are truly the most important things, and supporting suboptimal layouts with an option doesn't seem worth that tradeoff to me.
Thanks, Dan
On 12 March 2015 at 23:32, florian.schmidt.welzow@t-online.de mailto:florian.schmidt.welzow@t-online.de <florian.schmidt.welzow@t-online.de mailto:florian.schmidt.welzow@t-online.de > wrote: Hi Dan!
I'm fine with solutions, that try to save space and put as much meaningful content as possible to the first view (available without scrolling) to the app. I'm wondering, if this new feature will be behind a feature flag in the settings of the app?
Like you said, stripping (or adding) content to or from a wikipedia article is very controversial, so i think the user should have the possibility to turn on (or off) the feature (i'm fine with default "on") to change the content in this way, or implement a setting to turn off _all_ changes to the content, so a user can see the plain wikipedia article without any changes?
Kind reagrds, Florian
Freundliche Grüße Florian Schmidt
-----Original-Nachricht----- Betreff: [WikimediaMobile] [Apps] Stripping content inside brackets from the first sentence of articles Datum: Fri, 13 Mar 2015 02:07:34 +0100 Von: Dan Garry <dgarry@wikimedia.org mailto:dgarry@wikimedia.org > An: mobile-l <mobile-l@lists.wikimedia.org mailto:mobile-l@lists.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 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
Hi dan,
I d like to switch to an expert view where I see the real contents of an article not just a mock up some machine generates from whatever source. If generating is your goal you might consider joining google.
I am pretty sure product management is able to design the options so that they are easy to set and do not become messy :)
BTW where did you invent the text in the headline picture from?
Rupert On Mar 13, 2015 3:57 PM, "Dan Garry" dgarry@wikimedia.org wrote:
Hi Florian,
Thanks for the feedback!
Adding options for everything into the settings is a very slippery slope. If you want examples of where it can end up, take a look at your settings on Wikipedia! Tabs and tabs of options, many of which you don't even realise exist. Ultimate customisation seems like a good thing on the surface, but it creates tangled messes like that one. And it creates a nightmare for customer support, too; the user has to recount all the options they have turned on for you to reproduce their problems. VisualEditor is a good example of this, as it frequently breaks due to user CSS/JS that the user didn't even realise they had.
The other thing to consider about this is the development overhead. For every option we have, we're adding an extra combination of settings that we'd need to test and support. Those combinations grow exponentially with each option that's added; so if you've got four settings then that's 16 combinations... and adding a fifth option increases that to 32! So we must only add options for things that are truly the most important things, and supporting suboptimal layouts with an option doesn't seem worth that tradeoff to me.
Thanks, Dan
On 12 March 2015 at 23:32, florian.schmidt.welzow@t-online.de < florian.schmidt.welzow@t-online.de> wrote:
Hi Dan!
I'm fine with solutions, that try to save space and put as much meaningful content as possible to the first view (available without scrolling) to the app. I'm wondering, if this new feature will be behind a feature flag in the settings of the app?
Like you said, stripping (or adding) content to or from a wikipedia article is very controversial, so i think the user should have the possibility to turn on (or off) the feature (i'm fine with default "on") to change the content in this way, or implement a setting to turn off _all_ changes to the content, so a user can see the plain wikipedia article without any changes?
Kind reagrds,
Florian
Freundliche Grüße Florian Schmidt
-----Original-Nachricht-----
Betreff: [WikimediaMobile] [Apps] Stripping content inside brackets from the first sentence of articles
Datum: Fri, 13 Mar 2015 02:07:34 +0100
Von: Dan Garry dgarry@wikimedia.org
An: mobile-l mobile-l@lists.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
-- 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 Fri, Mar 13, 2015 at 6:25 PM rupert THURNER rupert.thurner@gmail.com wrote:
BTW where did you invent the text in the headline picture from?
BTW where did you invent the text in the headline picture from?
It’s the title + wikidata description :)
Best,
Florian
Von: rupert THURNER [mailto:rupert.thurner@gmail.com] Gesendet: Freitag, 13. März 2015 19:24 An: Dan Garry Cc: florian.schmidt.welzow@t-online.de; mobile-l Betreff: Re: [WikimediaMobile] [Apps] Stripping content inside brackets from the first sentence of articles
Hi dan,
I d like to switch to an expert view where I see the real contents of an article not just a mock up some machine generates from whatever source. If generating is your goal you might consider joining google.
I am pretty sure product management is able to design the options so that they are easy to set and do not become messy :)
BTW where did you invent the text in the headline picture from?
Rupert
On Mar 13, 2015 3:57 PM, "Dan Garry" <dgarry@wikimedia.org mailto:dgarry@wikimedia.org > wrote:
Hi Florian,
Thanks for the feedback!
Adding options for everything into the settings is a very slippery slope. If you want examples of where it can end up, take a look at your settings on Wikipedia! Tabs and tabs of options, many of which you don't even realise exist. Ultimate customisation seems like a good thing on the surface, but it creates tangled messes like that one. And it creates a nightmare for customer support, too; the user has to recount all the options they have turned on for you to reproduce their problems. VisualEditor is a good example of this, as it frequently breaks due to user CSS/JS that the user didn't even realise they had.
The other thing to consider about this is the development overhead. For every option we have, we're adding an extra combination of settings that we'd need to test and support. Those combinations grow exponentially with each option that's added; so if you've got four settings then that's 16 combinations... and adding a fifth option increases that to 32! So we must only add options for things that are truly the most important things, and supporting suboptimal layouts with an option doesn't seem worth that tradeoff to me.
Thanks,
Dan
On 12 March 2015 at 23:32, florian.schmidt.welzow@t-online.de mailto:florian.schmidt.welzow@t-online.de <florian.schmidt.welzow@t-online.de mailto:florian.schmidt.welzow@t-online.de > wrote:
Hi Dan!
I'm fine with solutions, that try to save space and put as much meaningful content as possible to the first view (available without scrolling) to the app. I'm wondering, if this new feature will be behind a feature flag in the settings of the app?
Like you said, stripping (or adding) content to or from a wikipedia article is very controversial, so i think the user should have the possibility to turn on (or off) the feature (i'm fine with default "on") to change the content in this way, or implement a setting to turn off _all_ changes to the content, so a user can see the plain wikipedia article without any changes?
Kind reagrds,
Florian
Freundliche Grüße Florian Schmidt
-----Original-Nachricht-----
Betreff: [WikimediaMobile] [Apps] Stripping content inside brackets from the first sentence of articles
Datum: Fri, 13 Mar 2015 02:07:34 +0100
Von: Dan Garry <dgarry@wikimedia.org mailto:dgarry@wikimedia.org >
An: mobile-l <mobile-l@lists.wikimedia.org mailto:mobile-l@lists.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
Hey Rupert,
Thanks for reaching out to us about this.
On 13 March 2015 at 11:23, rupert THURNER rupert.thurner@gmail.com wrote:
I d like to switch to an expert view where I see the real contents of an article not just a mock up some machine generates from whatever source.
What exactly do you mean by "real contents of an article"? I'm not trying to be facetious, but there are a multitude of factors that can affect how an article looks, such as browser settings, operating system settings, platform you're looking at the article on, and so forth.
If you want to see Wikipedia exactly like it looks on desktop, but on your phone instead, the app is by definition not suited to your use case. You should use mobile web, and choose "Desktop view".
I am pretty sure product management is able to design the options so that they are easy to set and do not become messy :)
See my above reply on this. The complexity of a settings interface grows exponentially with each setting added, as does the amount of support that needs to go into maintaining the product. It's not a matter of "just making it simple"; ultimate customisability comes at a cost.
Dan
+ Anna Stillwell
---- Vibha Bamba Senior Designer | WMF Design
On Fri, Mar 13, 2015 at 1:24 PM, Dan Garry dgarry@wikimedia.org wrote:
Hey Rupert,
Thanks for reaching out to us about this.
On 13 March 2015 at 11:23, rupert THURNER rupert.thurner@gmail.com wrote:
I d like to switch to an expert view where I see the real contents of an article not just a mock up some machine generates from whatever source.
What exactly do you mean by "real contents of an article"? I'm not trying to be facetious, but there are a multitude of factors that can affect how an article looks, such as browser settings, operating system settings, platform you're looking at the article on, and so forth.
If you want to see Wikipedia exactly like it looks on desktop, but on your phone instead, the app is by definition not suited to your use case. You should use mobile web, and choose "Desktop view".
I am pretty sure product management is able to design the options so that they are easy to set and do not become messy :)
See my above reply on this. The complexity of a settings interface grows exponentially with each setting added, as does the amount of support that needs to go into maintaining the product. It's not a matter of "just making it simple"; ultimate customisability comes at a cost.
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 Fri, Mar 13, 2015 at 9:24 PM, Dan Garry dgarry@wikimedia.org wrote:
On 13 March 2015 at 11:23, rupert THURNER rupert.thurner@gmail.com wrote:
I d like to switch to an expert view where I see the real contents of an article not just a mock up some machine generates from whatever source.
What exactly do you mean by "real contents of an article"? I'm not trying to be facetious, but there are a multitude of factors that can affect how an article looks
lol, what i mean by the contents? compared to the look? the contents is the text, not the formatting. i'd be not so keen in putting some text into an article and you censor it away ;)
I am pretty sure product management is able to design the options so that they are easy to set and do not become messy :)
See my above reply on this. The complexity of a settings interface grows exponentially with each setting added, as does the amount of support that needs to go into maintaining the product. It's not a matter of "just making it simple"; ultimate customisability comes at a cost.
that is true, and that is fair enough. in the last 15 years i did not ask for an additional setting, but i often thought to myself that the existing ones would need some reorganisation or rework.
if you do not like a setting than you might consider leaving the text as it is, and tackle the problem at source. one guideline is sufficient to get the parenthesis or this lenghty translations to a different position. it would fix the broken short-text in search engine view with it. which is anyway better than code that takes part of the information from wikidata, part it constructs itself, part is from wikipedia, some is from commons. there is no edit button or you would need 5 edit buttons and at the end everybody is confused where to edit what.
and if i find this complex the answer is "use desktop version and look on your mobile phone" *wonder*
best, rupert