> BTW where did you invent the text in the headline picture from?

 

It’s the title + wikidata description :)

 

Best,

Florian

 

Von: rupert THURNER [mailto:[email protected]] 
Gesendet: Freitag, 13. März 2015 19:24
An: Dan Garry
Cc: [email protected]; 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" <[email protected] 
<mailto:[email protected]> > 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, [email protected] 
<mailto:[email protected]>  
<[email protected] <mailto:[email protected]> 
> 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 <[email protected] <mailto:[email protected]> >

An: mobile-l <[email protected] 
<mailto:[email protected]> >

 

 

 

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
[email protected] <mailto:[email protected]> 
https://lists.wikimedia.org/mailman/listinfo/mobile-l





 

-- 

Dan Garry

Associate Product Manager, Mobile Apps

Wikimedia Foundation


_______________________________________________
Mobile-l mailing list
[email protected] <mailto:[email protected]> 
https://lists.wikimedia.org/mailman/listinfo/mobile-l

_______________________________________________
Mobile-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Reply via email to