(moving to mobile-l)
Thanks Vibha, this is really informative.
It's very clear that our first sentences really suck for supporting quick lookup, primarily because their information hierarchy is all wrong. That said, it's important to remember that we now have Wikidata descriptions displayed in the apps for this exact reason: to let people find out quickly and easily what something is.
So, although I agree that our first sentences are suboptimal, it's important to put the problem in context and remember that users do have Wikidata descriptions now to satisfy this use case. It's not like we're totally failing them, we could just be doing a bit better.
Rather than piling on hacks by trying to scrape the content in the first sentence and reorganise it (which causes information loss, and is extremely fragile from a technological perspective), 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.
Of course, there may be room for some quick wins that we can put in place while we figure out truly compelling UX for getting readers to submit descriptions. We can explore those quick wins in our brainstorming session on Monday. But we must remember that these will only be short-term, hacky solutions to the problem, and that we need to address this problem at the source in order to be really successful at it.
Thanks!
Dan
On 6 March 2015 at 16:13, Jon Robson jrobson@wikimedia.org wrote:
Any reason this is on mobile-tech and not mobile-l (I'd love to hear from people like Amir on this subject)? It would be good to flag this problem to a wider audience and part of our problem with most mobile issues is people just are not aware of this sort of thing. Many probably haven't even heard of the hemingway app...
It would be interesting to see how a wikidata generated first sentence would score with the same app.
On Fri, Mar 6, 2015 at 3:54 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Hi Folks, Kaity and I used the Hemingway app http://www.hemingwayapp.com/ to analyze the readability of our first sentence, using a few articles. They all scored poorly, an ideal grade level of 10 is recommended for clear bold writing.
This difficult problem arises from the first sentence containing one or more of the following:
- IPA Keys
- Birth/ death dates
- Other Names/ AKA's
- Help/info links
- Alternate spellings and scripts
- Additional details
Details like dates are replicated in the infobox, if it exists in the article. Other templates such as AKA's/IPA's are extremely useful but need to be presented in a clear and structured manner. Some of this comes from the Manual of style https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#First_sentence, but it is abused in many cases.
Its sad, because many readers come to Wikipedia to answer the 'What is this/ who is this' question. Google Knowledge panel strips out all brackets and presents important details as a list, under the description.
We have started investigating solutions for this on mobile. I would encourage you to try this out on mobile web or apps.
Thanks Vibha & Kaity
Articles we used: Bern https://en.wikipedia.org/wiki/Bern Genghis Khan https://en.wikipedia.org/wiki/Genghis_Khan Cephalopod https://en.wikipedia.org/wiki/Cephalopod Mahatma Gandhi https://en.wikipedia.org/wiki/Mahatma_Gandhi Nietzsche https://en.wikipedia.org/wiki/Friedrich_Nietzsche Carthage https://en.wikipedia.org/wiki/Carthage Phoenicia https://en.wikipedia.org/wiki/Phoenicia Timur https://en.wikipedia.org/wiki/Timur
Vibha Bamba Senior Designer | WMF Design
What's the scientific background of hemingwayapp? I don't see anything on their website. There is no one-size-fits-all readability algo for English, as far as I know.
Nemo
May I use this as a shameless plug for my automatic description API: http://magnusmanske.de/wordpress/?p=265
It scores a 9 in the Hemmingway app for Nietzsche, as opposed to the 22 for the English Wikipedia initial paragraph: https://tools.wmflabs.org/autodesc/?q=Q9358&lang=&mode=long&link...
On Sat, Mar 7, 2015 at 8:38 AM Federico Leva (Nemo) nemowiki@gmail.com wrote:
What's the scientific background of hemingwayapp? I don't see anything on their website. There is no one-size-fits-all readability algo for English, as far as I know.
Nemo
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On 7 Mar 2015 09:13, "Magnus Manske" magnusmanske@googlemail.com wrote:
May I use this as a shameless plug for my automatic description API: http://magnusmanske.de/wordpress/?p=265
It scores a 9 in the Hemmingway app for Nietzsche, as opposed to the 22
for the English Wikipedia initial paragraph:
Thanks Magnus Was hoping this would be the case and you would confirm that :-)
I personally would be very keen to get this into Wikidata via a bot. What are the blockers for doing that? What has the discussion been around that so far?
https://tools.wmflabs.org/autodesc/?q=Q9358&lang=&mode=long&link...
On Sat, Mar 7, 2015 at 8:38 AM Federico Leva (Nemo) nemowiki@gmail.com
wrote:
What's the scientific background of hemingwayapp? I don't see anything on their website. There is no one-size-fits-all readability algo for English, as far as I know.
Nemo
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
I would strongly recommend NOT to import automatic descriptions as manual descriptions into Wikidata. Automatic descriptions change when the data changes, new data is added, or the algorithm improves. I would prefer manual descriptions done by humans, for the comparatively small number of items that are hard to auto-describe, and use (properly cached) automated descriptions for everything else.
On Sat, Mar 7, 2015 at 6:36 PM Jon Robson jdlrobson@gmail.com wrote:
On 7 Mar 2015 09:13, "Magnus Manske" magnusmanske@googlemail.com wrote:
May I use this as a shameless plug for my automatic description API: http://magnusmanske.de/wordpress/?p=265
It scores a 9 in the Hemmingway app for Nietzsche, as opposed to the 22
for the English Wikipedia initial paragraph:
Thanks Magnus Was hoping this would be the case and you would confirm that :-)
I personally would be very keen to get this into Wikidata via a bot. What are the blockers for doing that? What has the discussion been around that so far?
https://tools.wmflabs.org/autodesc/?q=Q9358&lang=&mode=long&link...
On Sat, Mar 7, 2015 at 8:38 AM Federico Leva (Nemo) nemowiki@gmail.com
wrote:
What's the scientific background of hemingwayapp? I don't see anything on their website. There is no one-size-fits-all readability algo for English, as far as I know.
Nemo
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
On 7 March 2015 at 09:13, Magnus Manske magnusmanske@googlemail.com wrote:
May I use this as a shameless plug for my automatic description API: http://magnusmanske.de/wordpress/?p=265
You absolutely may! It has made it into my proposal for the Mobile Apps Team's work next quarter: In-line Wikidata description editing on the Wikipedia app https://www.mediawiki.org/wiki/Talk:Wikimedia_Engineering/2014-15_Goals/Q4#In-line_Wikidata_description_editing_on_the_Wikipedia_app .
Thanks!
Dan
On Fri, Mar 6, 2015 at 4:13 PM, Jon Robson jrobson@wikimedia.org wrote:
Any reason this is on mobile-tech and not mobile-l (I'd love to hear from people like Amir on this subject)? It would be good to flag this problem to a wider audience and part of our problem with most mobile issues is people just are not aware of this sort of thing. Many probably haven't even heard of the hemingway app...
Any reason this on mobile-tech and not on https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Lead_section? Content issues are best handled by the community, IMO, not by programmers. There was recently a discussion there on this exact topic[1] and I think they would have appreciated input from the WMF designers. Believe it or not, the community generally appreciates it when the WMF shares opinions (rather than imposing solutions without discussion), especially when it comes to content. For example, the Commons community has a good relationship with WMF Legal and is constantly asking their opinion on legal issues related to content. Compare this to when Jimmy went in and unilaterally deleted porn from Commons. It caused a huge fight, which Jimmy lost and led to him losing his founder rights.[1][2] I would prefer that WMF Design emulate the relationship with the community that WMF Legal has cultivated rather than the relationship that Jimmy has cultivated. Let's actually talk to the community about content issues rather than always trying to work around them.
Ryan Kaldari
1. https://en.wikipedia.org/wiki/Wikipedia_talk:Manual_of_Style/Lead_section#Pr... 2. http://www.telegraph.co.uk/technology/wikipedia/7711486/Wikipedia-porn-row-s... 3. http://venturebeat.com/2010/05/16/wikipedia-founder-gives-up-control-of-site...
I'll state a bunch of things that are obvious to me, but should probably be written down in some way...
IPA, other names, and names in other languages indeed make reading harder. They are there because of a tradition. There's a tradition of printing encyclopedia articles like this (that's also where the bold font in each articles' first words comes from). Just open any printed encyclopedia. It's a nice continuation of tradition, and Wikipedia takes it to extremes thanks to the blessings of Unicode - old printed encyclopedias were lucky to have Cyrillic characters in their typography, and some good ones had IPA, Arabic, and Devanagari, but you won't find pervasive use of Georgian or Kannada in a lot of printed encyclopedias. We have pretty much everything in Wikipdeia. The information is valuable, but having it all in parentheses in the first sentence begins to be non-practical.
It will help to at least be aware that a proposal to change this will break with traditions; traditions must be treated with respect. But in the 21st century on the web it may make sense to transfer IPA and names in other languages to the infobox. Other names in the same language will probably have to stay in the opening sentence, because article naming is a super-contentious issue.
And yes, the Foundation has no authority to just change it, because it's a matter for the Manual of Style, which is owned by the community (in all languages). As a member of the editing community, I would support it, and I even mentioned it on mailing lists in the past (too busy to search where), but it needs to go through proper discussion.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2015-03-07 2:49 GMT+02:00 Dan Garry dgarry@wikimedia.org:
(moving to mobile-l)
Thanks Vibha, this is really informative.
It's very clear that our first sentences really suck for supporting quick lookup, primarily because their information hierarchy is all wrong. That said, it's important to remember that we now have Wikidata descriptions displayed in the apps for this exact reason: to let people find out quickly and easily what something is.
So, although I agree that our first sentences are suboptimal, it's important to put the problem in context and remember that users do have Wikidata descriptions now to satisfy this use case. It's not like we're totally failing them, we could just be doing a bit better.
Rather than piling on hacks by trying to scrape the content in the first sentence and reorganise it (which causes information loss, and is extremely fragile from a technological perspective), 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.
Of course, there may be room for some quick wins that we can put in place while we figure out truly compelling UX for getting readers to submit descriptions. We can explore those quick wins in our brainstorming session on Monday. But we must remember that these will only be short-term, hacky solutions to the problem, and that we need to address this problem at the source in order to be really successful at it.
Thanks!
Dan
On 6 March 2015 at 16:13, Jon Robson jrobson@wikimedia.org wrote:
Any reason this is on mobile-tech and not mobile-l (I'd love to hear from people like Amir on this subject)? It would be good to flag this problem to a wider audience and part of our problem with most mobile issues is people just are not aware of this sort of thing. Many probably haven't even heard of the hemingway app...
It would be interesting to see how a wikidata generated first sentence would score with the same app.
On Fri, Mar 6, 2015 at 3:54 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Hi Folks, Kaity and I used the Hemingway app http://www.hemingwayapp.com/ to analyze the readability of our first sentence, using a few articles. They all scored poorly, an ideal grade level of 10 is recommended for clear bold writing.
This difficult problem arises from the first sentence containing one or more of the following:
- IPA Keys
- Birth/ death dates
- Other Names/ AKA's
- Help/info links
- Alternate spellings and scripts
- Additional details
Details like dates are replicated in the infobox, if it exists in the article. Other templates such as AKA's/IPA's are extremely useful but need to be presented in a clear and structured manner. Some of this comes from the Manual of style https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#First_sentence, but it is abused in many cases.
Its sad, because many readers come to Wikipedia to answer the 'What is this/ who is this' question. Google Knowledge panel strips out all brackets and presents important details as a list, under the description.
We have started investigating solutions for this on mobile. I would encourage you to try this out on mobile web or apps.
Thanks Vibha & Kaity
Articles we used: Bern https://en.wikipedia.org/wiki/Bern Genghis Khan https://en.wikipedia.org/wiki/Genghis_Khan Cephalopod https://en.wikipedia.org/wiki/Cephalopod Mahatma Gandhi https://en.wikipedia.org/wiki/Mahatma_Gandhi Nietzsche https://en.wikipedia.org/wiki/Friedrich_Nietzsche Carthage https://en.wikipedia.org/wiki/Carthage Phoenicia https://en.wikipedia.org/wiki/Phoenicia Timur https://en.wikipedia.org/wiki/Timur
Vibha Bamba Senior Designer | WMF Design
-- 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 agree with Magnus that it should be Wikidata to the rescue for problems like these, not some new policy that throws current WP contributors into a tizzy. I am not sure how precisely, but maybe if all parts of a lead sentence were in Wikidata then one could then experiment with a new Wikidata property for "Mobile lead" which could first be seeded with the label and barring that the WP lead?
On Mon, Mar 9, 2015 at 12:47 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
I'll state a bunch of things that are obvious to me, but should probably be written down in some way...
IPA, other names, and names in other languages indeed make reading harder. They are there because of a tradition. There's a tradition of printing encyclopedia articles like this (that's also where the bold font in each articles' first words comes from). Just open any printed encyclopedia. It's a nice continuation of tradition, and Wikipedia takes it to extremes thanks to the blessings of Unicode - old printed encyclopedias were lucky to have Cyrillic characters in their typography, and some good ones had IPA, Arabic, and Devanagari, but you won't find pervasive use of Georgian or Kannada in a lot of printed encyclopedias. We have pretty much everything in Wikipdeia. The information is valuable, but having it all in parentheses in the first sentence begins to be non-practical.
It will help to at least be aware that a proposal to change this will break with traditions; traditions must be treated with respect. But in the 21st century on the web it may make sense to transfer IPA and names in other languages to the infobox. Other names in the same language will probably have to stay in the opening sentence, because article naming is a super-contentious issue.
And yes, the Foundation has no authority to just change it, because it's a matter for the Manual of Style, which is owned by the community (in all languages). As a member of the editing community, I would support it, and I even mentioned it on mailing lists in the past (too busy to search where), but it needs to go through proper discussion.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2015-03-07 2:49 GMT+02:00 Dan Garry dgarry@wikimedia.org:
(moving to mobile-l)
Thanks Vibha, this is really informative.
It's very clear that our first sentences really suck for supporting quick lookup, primarily because their information hierarchy is all wrong. That said, it's important to remember that we now have Wikidata descriptions displayed in the apps for this exact reason: to let people find out quickly and easily what something is.
So, although I agree that our first sentences are suboptimal, it's important to put the problem in context and remember that users do have Wikidata descriptions now to satisfy this use case. It's not like we're totally failing them, we could just be doing a bit better.
Rather than piling on hacks by trying to scrape the content in the first sentence and reorganise it (which causes information loss, and is extremely fragile from a technological perspective), 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.
Of course, there may be room for some quick wins that we can put in place while we figure out truly compelling UX for getting readers to submit descriptions. We can explore those quick wins in our brainstorming session on Monday. But we must remember that these will only be short-term, hacky solutions to the problem, and that we need to address this problem at the source in order to be really successful at it.
Thanks!
Dan
On 6 March 2015 at 16:13, Jon Robson jrobson@wikimedia.org wrote:
Any reason this is on mobile-tech and not mobile-l (I'd love to hear from people like Amir on this subject)? It would be good to flag this problem to a wider audience and part of our problem with most mobile issues is people just are not aware of this sort of thing. Many probably haven't even heard of the hemingway app...
It would be interesting to see how a wikidata generated first sentence would score with the same app.
On Fri, Mar 6, 2015 at 3:54 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Hi Folks, Kaity and I used the Hemingway app http://www.hemingwayapp.com/ to analyze the readability of our first sentence, using a few articles. They all scored poorly, an ideal grade level of 10 is recommended for clear bold writing.
This difficult problem arises from the first sentence containing one or more of the following:
- IPA Keys
- Birth/ death dates
- Other Names/ AKA's
- Help/info links
- Alternate spellings and scripts
- Additional details
Details like dates are replicated in the infobox, if it exists in the article. Other templates such as AKA's/IPA's are extremely useful but need to be presented in a clear and structured manner. Some of this comes from the Manual of style https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#First_sentence, but it is abused in many cases.
Its sad, because many readers come to Wikipedia to answer the 'What is this/ who is this' question. Google Knowledge panel strips out all brackets and presents important details as a list, under the description.
We have started investigating solutions for this on mobile. I would encourage you to try this out on mobile web or apps.
Thanks Vibha & Kaity
Articles we used: Bern https://en.wikipedia.org/wiki/Bern Genghis Khan https://en.wikipedia.org/wiki/Genghis_Khan Cephalopod https://en.wikipedia.org/wiki/Cephalopod Mahatma Gandhi https://en.wikipedia.org/wiki/Mahatma_Gandhi Nietzsche https://en.wikipedia.org/wiki/Friedrich_Nietzsche Carthage https://en.wikipedia.org/wiki/Carthage Phoenicia https://en.wikipedia.org/wiki/Phoenicia Timur https://en.wikipedia.org/wiki/Timur
Vibha Bamba Senior Designer | WMF Design
-- 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
Call me old-fashioned, but I would really hate to see the lead sentences of Wikipedia articles auto-generated by a program. Our text is dry and monotonous enough as it is :)
On Mon, Mar 9, 2015 at 5:05 AM, Jane Darnell jane023@gmail.com wrote:
I agree with Magnus that it should be Wikidata to the rescue for problems like these, not some new policy that throws current WP contributors into a tizzy. I am not sure how precisely, but maybe if all parts of a lead sentence were in Wikidata then one could then experiment with a new Wikidata property for "Mobile lead" which could first be seeded with the label and barring that the WP lead?
On Mon, Mar 9, 2015 at 12:47 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
I'll state a bunch of things that are obvious to me, but should probably be written down in some way...
IPA, other names, and names in other languages indeed make reading harder. They are there because of a tradition. There's a tradition of printing encyclopedia articles like this (that's also where the bold font in each articles' first words comes from). Just open any printed encyclopedia. It's a nice continuation of tradition, and Wikipedia takes it to extremes thanks to the blessings of Unicode - old printed encyclopedias were lucky to have Cyrillic characters in their typography, and some good ones had IPA, Arabic, and Devanagari, but you won't find pervasive use of Georgian or Kannada in a lot of printed encyclopedias. We have pretty much everything in Wikipdeia. The information is valuable, but having it all in parentheses in the first sentence begins to be non-practical.
It will help to at least be aware that a proposal to change this will break with traditions; traditions must be treated with respect. But in the 21st century on the web it may make sense to transfer IPA and names in other languages to the infobox. Other names in the same language will probably have to stay in the opening sentence, because article naming is a super-contentious issue.
And yes, the Foundation has no authority to just change it, because it's a matter for the Manual of Style, which is owned by the community (in all languages). As a member of the editing community, I would support it, and I even mentioned it on mailing lists in the past (too busy to search where), but it needs to go through proper discussion.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2015-03-07 2:49 GMT+02:00 Dan Garry dgarry@wikimedia.org:
(moving to mobile-l)
Thanks Vibha, this is really informative.
It's very clear that our first sentences really suck for supporting quick lookup, primarily because their information hierarchy is all wrong. That said, it's important to remember that we now have Wikidata descriptions displayed in the apps for this exact reason: to let people find out quickly and easily what something is.
So, although I agree that our first sentences are suboptimal, it's important to put the problem in context and remember that users do have Wikidata descriptions now to satisfy this use case. It's not like we're totally failing them, we could just be doing a bit better.
Rather than piling on hacks by trying to scrape the content in the first sentence and reorganise it (which causes information loss, and is extremely fragile from a technological perspective), 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.
Of course, there may be room for some quick wins that we can put in place while we figure out truly compelling UX for getting readers to submit descriptions. We can explore those quick wins in our brainstorming session on Monday. But we must remember that these will only be short-term, hacky solutions to the problem, and that we need to address this problem at the source in order to be really successful at it.
Thanks!
Dan
On 6 March 2015 at 16:13, Jon Robson jrobson@wikimedia.org wrote:
Any reason this is on mobile-tech and not mobile-l (I'd love to hear from people like Amir on this subject)? It would be good to flag this problem to a wider audience and part of our problem with most mobile issues is people just are not aware of this sort of thing. Many probably haven't even heard of the hemingway app...
It would be interesting to see how a wikidata generated first sentence would score with the same app.
On Fri, Mar 6, 2015 at 3:54 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Hi Folks, Kaity and I used the Hemingway app http://www.hemingwayapp.com/ to analyze the readability of our first sentence, using a few articles. They all scored poorly, an ideal grade level of 10 is recommended for clear bold writing.
This difficult problem arises from the first sentence containing one or more of the following:
- IPA Keys
- Birth/ death dates
- Other Names/ AKA's
- Help/info links
- Alternate spellings and scripts
- Additional details
Details like dates are replicated in the infobox, if it exists in the article. Other templates such as AKA's/IPA's are extremely useful but need to be presented in a clear and structured manner. Some of this comes from the Manual of style https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#First_sentence, but it is abused in many cases.
Its sad, because many readers come to Wikipedia to answer the 'What is this/ who is this' question. Google Knowledge panel strips out all brackets and presents important details as a list, under the description.
We have started investigating solutions for this on mobile. I would encourage you to try this out on mobile web or apps.
Thanks Vibha & Kaity
Articles we used: Bern https://en.wikipedia.org/wiki/Bern Genghis Khan https://en.wikipedia.org/wiki/Genghis_Khan Cephalopod https://en.wikipedia.org/wiki/Cephalopod Mahatma Gandhi https://en.wikipedia.org/wiki/Mahatma_Gandhi Nietzsche https://en.wikipedia.org/wiki/Friedrich_Nietzsche Carthage https://en.wikipedia.org/wiki/Carthage Phoenicia https://en.wikipedia.org/wiki/Phoenicia Timur https://en.wikipedia.org/wiki/Timur
Vibha Bamba Senior Designer | WMF Design
-- 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
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
It’s official, Ryan is old-fashioned, unless you can show otherwise. Here is the challenge: [1].
[1] http://www.nytimes.com/interactive/2015/03/08/opinion/sunday/algorithm-human... http://www.nytimes.com/interactive/2015/03/08/opinion/sunday/algorithm-human-quiz.html?_r=0
On Mar 9, 2015, at 2:17 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Call me old-fashioned, but I would really hate to see the lead sentences of Wikipedia articles auto-generated by a program. Our text is dry and monotonous enough as it is :)
On Mon, Mar 9, 2015 at 5:05 AM, Jane Darnell <jane023@gmail.com mailto:jane023@gmail.com> wrote: I agree with Magnus that it should be Wikidata to the rescue for problems like these, not some new policy that throws current WP contributors into a tizzy. I am not sure how precisely, but maybe if all parts of a lead sentence were in Wikidata then one could then experiment with a new Wikidata property for "Mobile lead" which could first be seeded with the label and barring that the WP lead?
On Mon, Mar 9, 2015 at 12:47 PM, Amir E. Aharoni <amir.aharoni@mail.huji.ac.il mailto:amir.aharoni@mail.huji.ac.il> wrote: I'll state a bunch of things that are obvious to me, but should probably be written down in some way...
IPA, other names, and names in other languages indeed make reading harder. They are there because of a tradition. There's a tradition of printing encyclopedia articles like this (that's also where the bold font in each articles' first words comes from). Just open any printed encyclopedia. It's a nice continuation of tradition, and Wikipedia takes it to extremes thanks to the blessings of Unicode - old printed encyclopedias were lucky to have Cyrillic characters in their typography, and some good ones had IPA, Arabic, and Devanagari, but you won't find pervasive use of Georgian or Kannada in a lot of printed encyclopedias. We have pretty much everything in Wikipdeia. The information is valuable, but having it all in parentheses in the first sentence begins to be non-practical.
It will help to at least be aware that a proposal to change this will break with traditions; traditions must be treated with respect. But in the 21st century on the web it may make sense to transfer IPA and names in other languages to the infobox. Other names in the same language will probably have to stay in the opening sentence, because article naming is a super-contentious issue.
And yes, the Foundation has no authority to just change it, because it's a matter for the Manual of Style, which is owned by the community (in all languages). As a member of the editing community, I would support it, and I even mentioned it on mailing lists in the past (too busy to search where), but it needs to go through proper discussion.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com http://aharoni.wordpress.com/ “We're living in pieces, I want to live in peace.” – T. Moore
2015-03-07 2:49 GMT+02:00 Dan Garry <dgarry@wikimedia.org mailto:dgarry@wikimedia.org>: (moving to mobile-l)
Thanks Vibha, this is really informative.
It's very clear that our first sentences really suck for supporting quick lookup, primarily because their information hierarchy is all wrong. That said, it's important to remember that we now have Wikidata descriptions displayed in the apps for this exact reason: to let people find out quickly and easily what something is.
So, although I agree that our first sentences are suboptimal, it's important to put the problem in context and remember that users do have Wikidata descriptions now to satisfy this use case. It's not like we're totally failing them, we could just be doing a bit better.
Rather than piling on hacks by trying to scrape the content in the first sentence and reorganise it (which causes information loss, and is extremely fragile from a technological perspective), 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.
Of course, there may be room for some quick wins that we can put in place while we figure out truly compelling UX for getting readers to submit descriptions. We can explore those quick wins in our brainstorming session on Monday. But we must remember that these will only be short-term, hacky solutions to the problem, and that we need to address this problem at the source in order to be really successful at it.
Thanks!
Dan
On 6 March 2015 at 16:13, Jon Robson <jrobson@wikimedia.org mailto:jrobson@wikimedia.org> wrote: Any reason this is on mobile-tech and not mobile-l (I'd love to hear from people like Amir on this subject)? It would be good to flag this problem to a wider audience and part of our problem with most mobile issues is people just are not aware of this sort of thing. Many probably haven't even heard of the hemingway app...
It would be interesting to see how a wikidata generated first sentence would score with the same app.
On Fri, Mar 6, 2015 at 3:54 PM, Vibha Bamba <vbamba@wikimedia.org mailto:vbamba@wikimedia.org> wrote: Hi Folks, Kaity and I used the Hemingway app http://www.hemingwayapp.com/ to analyze the readability of our first sentence, using a few articles. They all scored poorly, an ideal grade level of 10 is recommended for clear bold writing.
This difficult problem arises from the first sentence containing one or more of the following: IPA Keys Birth/ death dates Other Names/ AKA's Help/info links Alternate spellings and scripts Additional details Details like dates are replicated in the infobox, if it exists in the article. Other templates such as AKA's/IPA's are extremely useful but need to be presented in a clear and structured manner. Some of this comes from the Manual of style https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#First_sentence, but it is abused in many cases.
Its sad, because many readers come to Wikipedia to answer the 'What is this/ who is this' question. Google Knowledge panel strips out all brackets and presents important details as a list, under the description.
We have started investigating solutions for this on mobile. I would encourage you to try this out on mobile web or apps.
Thanks Vibha & Kaity
Articles we used: Bern https://en.wikipedia.org/wiki/Bern Genghis Khan https://en.wikipedia.org/wiki/Genghis_Khan Cephalopod https://en.wikipedia.org/wiki/Cephalopod Mahatma Gandhi https://en.wikipedia.org/wiki/Mahatma_Gandhi Nietzsche https://en.wikipedia.org/wiki/Friedrich_Nietzsche Carthage https://en.wikipedia.org/wiki/Carthage Phoenicia https://en.wikipedia.org/wiki/Phoenicia Timur https://en.wikipedia.org/wiki/Timur
Vibha Bamba Senior Designer | WMF Design
-- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation
Mobile-l mailing list Mobile-l@lists.wikimedia.org mailto:Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org mailto:Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l https://lists.wikimedia.org/mailman/listinfo/mobile-l
Mobile-l mailing list Mobile-l@lists.wikimedia.org mailto:Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l 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
Well, I only got 5 out of 8. I guess computers have gotten clever. Damn new-fangled gadgets!
On Mon, Mar 9, 2015 at 11:34 AM, Bahodir Mansurov bmansurov@wikimedia.org wrote:
It’s official, Ryan is old-fashioned, unless you can show otherwise. Here is the challenge: [1].
[1] http://www.nytimes.com/interactive/2015/03/08/opinion/sunday/algorithm-human...
On Mar 9, 2015, at 2:17 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Call me old-fashioned, but I would really hate to see the lead sentences of Wikipedia articles auto-generated by a program. Our text is dry and monotonous enough as it is :)
On Mon, Mar 9, 2015 at 5:05 AM, Jane Darnell jane023@gmail.com wrote:
I agree with Magnus that it should be Wikidata to the rescue for problems like these, not some new policy that throws current WP contributors into a tizzy. I am not sure how precisely, but maybe if all parts of a lead sentence were in Wikidata then one could then experiment with a new Wikidata property for "Mobile lead" which could first be seeded with the label and barring that the WP lead?
On Mon, Mar 9, 2015 at 12:47 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
I'll state a bunch of things that are obvious to me, but should probably be written down in some way...
IPA, other names, and names in other languages indeed make reading harder. They are there because of a tradition. There's a tradition of printing encyclopedia articles like this (that's also where the bold font in each articles' first words comes from). Just open any printed encyclopedia. It's a nice continuation of tradition, and Wikipedia takes it to extremes thanks to the blessings of Unicode - old printed encyclopedias were lucky to have Cyrillic characters in their typography, and some good ones had IPA, Arabic, and Devanagari, but you won't find pervasive use of Georgian or Kannada in a lot of printed encyclopedias. We have pretty much everything in Wikipdeia. The information is valuable, but having it all in parentheses in the first sentence begins to be non-practical.
It will help to at least be aware that a proposal to change this will break with traditions; traditions must be treated with respect. But in the 21st century on the web it may make sense to transfer IPA and names in other languages to the infobox. Other names in the same language will probably have to stay in the opening sentence, because article naming is a super-contentious issue.
And yes, the Foundation has no authority to just change it, because it's a matter for the Manual of Style, which is owned by the community (in all languages). As a member of the editing community, I would support it, and I even mentioned it on mailing lists in the past (too busy to search where), but it needs to go through proper discussion.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2015-03-07 2:49 GMT+02:00 Dan Garry dgarry@wikimedia.org:
(moving to mobile-l)
Thanks Vibha, this is really informative.
It's very clear that our first sentences really suck for supporting quick lookup, primarily because their information hierarchy is all wrong. That said, it's important to remember that we now have Wikidata descriptions displayed in the apps for this exact reason: to let people find out quickly and easily what something is.
So, although I agree that our first sentences are suboptimal, it's important to put the problem in context and remember that users do have Wikidata descriptions now to satisfy this use case. It's not like we're totally failing them, we could just be doing a bit better.
Rather than piling on hacks by trying to scrape the content in the first sentence and reorganise it (which causes information loss, and is extremely fragile from a technological perspective), 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.
Of course, there may be room for some quick wins that we can put in place while we figure out truly compelling UX for getting readers to submit descriptions. We can explore those quick wins in our brainstorming session on Monday. But we must remember that these will only be short-term, hacky solutions to the problem, and that we need to address this problem at the source in order to be really successful at it.
Thanks!
Dan
On 6 March 2015 at 16:13, Jon Robson jrobson@wikimedia.org wrote:
Any reason this is on mobile-tech and not mobile-l (I'd love to hear from people like Amir on this subject)? It would be good to flag this problem to a wider audience and part of our problem with most mobile issues is people just are not aware of this sort of thing. Many probably haven't even heard of the hemingway app...
It would be interesting to see how a wikidata generated first sentence would score with the same app.
On Fri, Mar 6, 2015 at 3:54 PM, Vibha Bamba vbamba@wikimedia.org wrote:
Hi Folks, Kaity and I used the Hemingway app http://www.hemingwayapp.com/ to analyze the readability of our first sentence, using a few articles. They all scored poorly, an ideal grade level of 10 is recommended for clear bold writing.
This difficult problem arises from the first sentence containing one or more of the following:
- IPA Keys
- Birth/ death dates
- Other Names/ AKA's
- Help/info links
- Alternate spellings and scripts
- Additional details
Details like dates are replicated in the infobox, if it exists in the article. Other templates such as AKA's/IPA's are extremely useful but need to be presented in a clear and structured manner. Some of this comes from the Manual of style https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#First_sentence, but it is abused in many cases.
Its sad, because many readers come to Wikipedia to answer the 'What is this/ who is this' question. Google Knowledge panel strips out all brackets and presents important details as a list, under the description.
We have started investigating solutions for this on mobile. I would encourage you to try this out on mobile web or apps.
Thanks Vibha & Kaity
Articles we used: Bern https://en.wikipedia.org/wiki/Bern Genghis Khan https://en.wikipedia.org/wiki/Genghis_Khan Cephalopod https://en.wikipedia.org/wiki/Cephalopod Mahatma Gandhi https://en.wikipedia.org/wiki/Mahatma_Gandhi Nietzsche https://en.wikipedia.org/wiki/Friedrich_Nietzsche Carthage https://en.wikipedia.org/wiki/Carthage Phoenicia https://en.wikipedia.org/wiki/Phoenicia Timur https://en.wikipedia.org/wiki/Timur
Vibha Bamba Senior Designer | WMF Design
-- 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
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
Damn, now I need to write a wiki poetry generator?
On Mon, Mar 9, 2015 at 6:41 PM Ryan Kaldari rkaldari@wikimedia.org wrote:
Well, I only got 5 out of 8. I guess computers have gotten clever. Damn new-fangled gadgets!
On Mon, Mar 9, 2015 at 11:34 AM, Bahodir Mansurov <bmansurov@wikimedia.org
wrote:
It’s official, Ryan is old-fashioned, unless you can show otherwise. Here is the challenge: [1].
[1] http://www.nytimes.com/interactive/2015/03/08/opinion/sunday/algorithm-human...
On Mar 9, 2015, at 2:17 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Call me old-fashioned, but I would really hate to see the lead sentences of Wikipedia articles auto-generated by a program. Our text is dry and monotonous enough as it is :)
On Mon, Mar 9, 2015 at 5:05 AM, Jane Darnell jane023@gmail.com wrote:
I agree with Magnus that it should be Wikidata to the rescue for problems like these, not some new policy that throws current WP contributors into a tizzy. I am not sure how precisely, but maybe if all parts of a lead sentence were in Wikidata then one could then experiment with a new Wikidata property for "Mobile lead" which could first be seeded with the label and barring that the WP lead?
On Mon, Mar 9, 2015 at 12:47 PM, Amir E. Aharoni < amir.aharoni@mail.huji.ac.il> wrote:
I'll state a bunch of things that are obvious to me, but should probably be written down in some way...
IPA, other names, and names in other languages indeed make reading harder. They are there because of a tradition. There's a tradition of printing encyclopedia articles like this (that's also where the bold font in each articles' first words comes from). Just open any printed encyclopedia. It's a nice continuation of tradition, and Wikipedia takes it to extremes thanks to the blessings of Unicode - old printed encyclopedias were lucky to have Cyrillic characters in their typography, and some good ones had IPA, Arabic, and Devanagari, but you won't find pervasive use of Georgian or Kannada in a lot of printed encyclopedias. We have pretty much everything in Wikipdeia. The information is valuable, but having it all in parentheses in the first sentence begins to be non-practical.
It will help to at least be aware that a proposal to change this will break with traditions; traditions must be treated with respect. But in the 21st century on the web it may make sense to transfer IPA and names in other languages to the infobox. Other names in the same language will probably have to stay in the opening sentence, because article naming is a super-contentious issue.
And yes, the Foundation has no authority to just change it, because it's a matter for the Manual of Style, which is owned by the community (in all languages). As a member of the editing community, I would support it, and I even mentioned it on mailing lists in the past (too busy to search where), but it needs to go through proper discussion.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2015-03-07 2:49 GMT+02:00 Dan Garry dgarry@wikimedia.org:
(moving to mobile-l)
Thanks Vibha, this is really informative.
It's very clear that our first sentences really suck for supporting quick lookup, primarily because their information hierarchy is all wrong. That said, it's important to remember that we now have Wikidata descriptions displayed in the apps for this exact reason: to let people find out quickly and easily what something is.
So, although I agree that our first sentences are suboptimal, it's important to put the problem in context and remember that users do have Wikidata descriptions now to satisfy this use case. It's not like we're totally failing them, we could just be doing a bit better.
Rather than piling on hacks by trying to scrape the content in the first sentence and reorganise it (which causes information loss, and is extremely fragile from a technological perspective), 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.
Of course, there may be room for some quick wins that we can put in place while we figure out truly compelling UX for getting readers to submit descriptions. We can explore those quick wins in our brainstorming session on Monday. But we must remember that these will only be short-term, hacky solutions to the problem, and that we need to address this problem at the source in order to be really successful at it.
Thanks!
Dan
On 6 March 2015 at 16:13, Jon Robson jrobson@wikimedia.org wrote:
Any reason this is on mobile-tech and not mobile-l (I'd love to hear from people like Amir on this subject)? It would be good to flag this problem to a wider audience and part of our problem with most mobile issues is people just are not aware of this sort of thing. Many probably haven't even heard of the hemingway app...
It would be interesting to see how a wikidata generated first sentence would score with the same app.
On Fri, Mar 6, 2015 at 3:54 PM, Vibha Bamba vbamba@wikimedia.org wrote:
> Hi Folks, > Kaity and I used the Hemingway app http://www.hemingwayapp.com/ > to analyze the readability of our first sentence, using a few articles. > They all scored poorly, an ideal grade level of 10 is recommended for clear > bold writing. > > This difficult problem arises from the first sentence containing one > or more of the following: > > - IPA Keys > - Birth/ death dates > - Other Names/ AKA's > - Help/info links > - Alternate spellings and scripts > - Additional details > > Details like dates are replicated in the infobox, if it exists in > the article. > Other templates such as AKA's/IPA's are extremely useful but need to > be presented in a clear and structured manner. Some of this comes from the Manual > of style > https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Lead_section#First_sentence, > but it is abused in many cases. > > Its sad, because many readers come to Wikipedia to answer the 'What > is this/ who is this' question. Google Knowledge panel strips out all > brackets and presents important details as a list, under the description. > > We have started investigating solutions for this on mobile. I would > encourage you to try this out on mobile web or apps. > > Thanks > Vibha & Kaity > > --- > > Articles we used: > Bern https://en.wikipedia.org/wiki/Bern > Genghis Khan https://en.wikipedia.org/wiki/Genghis_Khan > Cephalopod https://en.wikipedia.org/wiki/Cephalopod > Mahatma Gandhi https://en.wikipedia.org/wiki/Mahatma_Gandhi > Nietzsche https://en.wikipedia.org/wiki/Friedrich_Nietzsche > Carthage https://en.wikipedia.org/wiki/Carthage > Phoenicia https://en.wikipedia.org/wiki/Phoenicia > Timur https://en.wikipedia.org/wiki/Timur > > > > ---- > Vibha Bamba > Senior Designer | WMF Design > > > > > > >
-- 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
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
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Mar 9, 2015, at 11:17 AM, Ryan Kaldari rkaldari@wikimedia.org wrote:
Call me old-fashioned, but I would really hate to see the lead sentences of Wikipedia articles auto-generated by a program. Our text is dry and monotonous enough as it is :)
+1
On Mon, Mar 9, 2015 at 5:05 AM, Jane Darnell jane023@gmail.com wrote: I agree with Magnus that it should be Wikidata to the rescue for problems like these, not some new policy that throws current WP contributors into a tizzy. I am not sure how precisely, but maybe if all parts of a lead sentence were in Wikidata then one could then experiment with a new Wikidata property for "Mobile lead" which could first be seeded with the label and barring that the WP lead?
On Mon, Mar 9, 2015 at 12:47 PM, Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote: I'll state a bunch of things that are obvious to me, but should probably be written down in some way...
IPA, other names, and names in other languages indeed make reading harder. They are there because of a tradition. There's a tradition of printing encyclopedia articles like this (that's also where the bold font in each articles' first words comes from). Just open any printed encyclopedia. It's a nice continuation of tradition, and Wikipedia takes it to extremes thanks to the blessings of Unicode - old printed encyclopedias were lucky to have Cyrillic characters in their typography, and some good ones had IPA, Arabic, and Devanagari, but you won't find pervasive use of Georgian or Kannada in a lot of printed encyclopedias. We have pretty much everything in Wikipdeia. The information is valuable, but having it all in parentheses in the first sentence begins to be non-practical.
It will help to at least be aware that a proposal to change this will break with traditions; traditions must be treated with respect. But in the 21st century on the web it may make sense to transfer IPA and names in other languages to the infobox. Other names in the same language will probably have to stay in the opening sentence, because article naming is a super-contentious issue.
And yes, the Foundation has no authority to just change it, because it's a matter for the Manual of Style, which is owned by the community (in all languages). As a member of the editing community, I would support it, and I even mentioned it on mailing lists in the past (too busy to search where), but it needs to go through proper discussion.
-- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore
2015-03-07 2:49 GMT+02:00 Dan Garry dgarry@wikimedia.org:
(moving to mobile-l)
Thanks Vibha, this is really informative.
It's very clear that our first sentences really suck for supporting quick lookup, primarily because their information hierarchy is all wrong. That said, it's important to remember that we now have Wikidata descriptions displayed in the apps for this exact reason: to let people find out quickly and easily what something is.
So, although I agree that our first sentences are suboptimal, it's important to put the problem in context and remember that users do have Wikidata descriptions now to satisfy this use case. It's not like we're totally failing them, we could just be doing a bit better.
Rather than piling on hacks by trying to scrape the content in the first sentence and reorganise it (which causes information loss, and is extremely fragile from a technological perspective), 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.
Of course, there may be room for some quick wins that we can put in place while we figure out truly compelling UX for getting readers to submit descriptions. We can explore those quick wins in our brainstorming session on Monday. But we must remember that these will only be short-term, hacky solutions to the problem, and that we need to address this problem at the source in order to be really successful at it.
Thanks!
Dan
On 6 March 2015 at 16:13, Jon Robson jrobson@wikimedia.org wrote: Any reason this is on mobile-tech and not mobile-l (I'd love to hear from people like Amir on this subject)? It would be good to flag this problem to a wider audience and part of our problem with most mobile issues is people just are not aware of this sort of thing. Many probably haven't even heard of the hemingway app...
It would be interesting to see how a wikidata generated first sentence would score with the same app.
On Fri, Mar 6, 2015 at 3:54 PM, Vibha Bamba vbamba@wikimedia.org wrote: Hi Folks, Kaity and I used the Hemingway app to analyze the readability of our first sentence, using a few articles. They all scored poorly, an ideal grade level of 10 is recommended for clear bold writing.
This difficult problem arises from the first sentence containing one or more of the following: IPA Keys Birth/ death dates Other Names/ AKA's Help/info links Alternate spellings and scripts Additional details Details like dates are replicated in the infobox, if it exists in the article. Other templates such as AKA's/IPA's are extremely useful but need to be presented in a clear and structured manner. Some of this comes from the Manual of style, but it is abused in many cases.
Its sad, because many readers come to Wikipedia to answer the 'What is this/ who is this' question. Google Knowledge panel strips out all brackets and presents important details as a list, under the description.
We have started investigating solutions for this on mobile. I would encourage you to try this out on mobile web or apps.
Thanks Vibha & Kaity
Articles we used: Bern Genghis Khan Cephalopod Mahatma Gandhi Nietzsche Carthage Phoenicia Timur
Vibha Bamba Senior Designer | WMF Design
-- 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
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