Re: [WikimediaMobile] Wiki-specific parsing in mobile "services"

[Monte Hurd]

Thanks Florian.

I see your point about ease of forking. Would you have time later, perhaps
off thread, to detail the challenges you faced?

Regarding the data endpoint topic of this thread, it isn't app-specific
despite being part of 'mediawiki/services/mobileapps'. We'll probably want
a more generic name with only truly app specific endpoints named
accordingly.


On Thu, Jan 12, 2017 at 10:05 AM, Florian Schmidt <
florian.schmidt.wel...@t-online.de> wrote:

> What is also in my mind: the app wasn't easy to fork and use on other
> (third-party) projects before that, too, however with the track in this
> direction (specific Parsons of contents, which apply to Wikimedia projects
> only) makes it, in reality, impossible to fork (and maintain) the app
> projects to other, MediaWiki based, third-party projects. I understand,
> that this might not be the goal of the WMF, which in my personal opinion
> isn't quite correct, however it's very very sad. I tried to maintain an
> up-to-date version of the Wikipedia app some time ago, but it takes so much
> time, as it is so Wikimedia, and not MediaWiki specific, that I ended up
> mostly stopping the effort in this direction.
>
> This is probably not a response which should be in this thread, and I
> apologize for that, however I wanted to say that somewhere.
>
> Best,
> Florian
>
> ___
> 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

Re: [WikimediaMobile] Wiki-specific parsing in mobile "services"

[Monte Hurd]

> I see little effort on finding solutions potentially able to scale to all
our projects and languages

See my reply to your initial comment on that ticket. This was just a first
hack at implementing this functionality. If you had simply asked if there
were plans to expand this to other projects/languages the answer you would
have received would have been "absolutely! this is just a first pass".

I have pasted the referenced comment and response from that ticket below:



> It's inappropriate an unsustainable to hardcode such wiki-specific
parsing in our code.

In the future please consider the tone and impact of your comments before
clicking "post".

Imagine you were, say, a first-time volunteer contributor and the first
piece of feedback you received was the comment you posted above. How would
that make you feel about even trying to contribute?

I'm not saying there's not a kernel of truth in your comment, because there
is*, but the way you phrased it actually inclines me to take your opinion,
and you, far less seriously.

*I agree it would indeed be better to have this endpoint work across all
language wikis. I intend to examine such functionality, but as a first pass
I chose to implement the core logic for my native language. My
implementation should be fairly easy to modify, as well, because I had this
eventuality in mind throughout development.

On Thu, Jan 12, 2017 at 12:41 AM, Federico Leva (Nemo) 
wrote:

> Is it considered acceptable now to produce a service or API that hardcodes
> wiki-specific parsing of certain wikitext or HTML patterns in certain wiki
> pages (such as the "On this day" section of the main page of one wiki)?
>
> I'm confused by the status of things and after my comment
> https://phabricator.wikimedia.org/T143408#2919000 I see little effort on
> finding solutions potentially able to scale to all our projects and
> languages (which I assume to be the mission, see "globally" in
> https://wikimediafoundation.org/wiki/Mission_statement ; please point it
> out if this assumption is incorrect).
>
> It might be that wiki-specific parsing hardcoded in MediaWiki/Wikimedia
> code is actually able to scale, if written correctly; a comment on the
> association patch seemed to imply so. This would be a very surprising
> finding, and one which goes against 15 years of experience, so if we have
> some examples or evidence of this it would be very worthwhile to point them
> out.
>
> 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

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Monte Hurd]

 This is why the automatic description cache and the manual description
 need to be kept separate; just pasting the autodesc into the manual
 description field would mean it could never be updated automatically. That
 would be very bad indeed.


+1000 Exactly! I was operating under the assumption we were talking
about the existing description field. Separate auto and manual
description fields completely avoids *all* of the issues/concerns I raised
:)

On Thu, Aug 20, 2015 at 2:48 AM, Magnus Manske magnusman...@googlemail.com
wrote:

 So it turns out that ValterVBot alone has created over 1.8 MILLION
 manual descriptions. And there are other bots that do this. We already
 HAVE automatic descriptions, we just store them in the manual field.

 The worst of both worlds.

 On Thu, Aug 20, 2015 at 9:24 AM Magnus Manske magnusman...@googlemail.com
 wrote:

 On Thu, Aug 20, 2015 at 1:43 AM Monte Hurd mh...@wikimedia.org wrote:

 True about algorithms never being finished, but aren't we essentially
 stuck with the first run output, unless I misunderstand how you envision
 this working?

 (assuming you don't want to over-write non-blank descriptions the next
 time you improve and re-run the process)


 Of course we're not stuck with the initial automatic descriptions!
 Whatever gave you that idea? Ideally, each description would be computed
 on-the-fly, but that won't scale; output needs to be cached, and
 invalidated when necessary.

 Possible reasons for cache invalidation:
 * The item statements have changed
 * Items referenced in the description (e.g. country for nationality) have
 changed
 * The algorithm has been improved
 * After cache reached a certain age, just to make sure

 This is why the automatic description cache and the manual description
 need to be kept separate; just pasting the autodesc into the manual
 description field would mean it could never be updated automatically. That
 would be very bad indeed.


___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Monte Hurd]

Those were literally the first 10 random articles I encountered which
didn't have descriptions.


The tool that generates the descriptions deserves a lot more development.
 Magnus' tool is very much a prototype, and represents a tiny glimpse of
 what's possible. Looking at its current output is a straw man.


It's not a straw man at all - it's a baseline to move the discussion away
from the abstract. We need to start looking at real examples.

One of my main concerns is a lot more development is actually an
understatement as many of the optimizations will be language dependent.


On Wed, Aug 19, 2015 at 2:57 AM, Magnus Manske magnusman...@googlemail.com
wrote:

 Oh, and as for examples, random-paging just got me this:

 https://en.wikipedia.org/wiki/Jules_Malou

 Manual description: Belgian politician

 Automatic description:  Belgian politician and lawyer, Prime Minister of
 Belgium, and member of the Chamber of Representatives of Belgium
 (1810–1886) ♂

 I know which one I'd prefer...


 On Wed, Aug 19, 2015 at 10:50 AM Magnus Manske 
 magnusman...@googlemail.com wrote:

 Thank you Dmitry! Well phrased and to the point!

 As for templating, that might be the worst of both worlds; without the
 flexibility and over-time improvement of automatic descriptions, but making
 it harder for people to enter (compared to free-style text). We have a
 Visual Editor on Wikipedia for a reason :-)



 On Wed, Aug 19, 2015 at 4:07 AM Dmitry Brant dbr...@wikimedia.org
 wrote:

 My thoughts, as ever(!), are as follows:

 - The tool that generates the descriptions deserves a lot more
 development. Magnus' tool is very much a prototype, and represents a tiny
 glimpse of what's possible. Looking at its current output is a straw man.
 - Auto-generated descriptions work for current articles, and *all
 future articles*. They automatically adapt to updated data. They
 automatically become more accurate as new data is added.
 - When you edit the descriptions yourself, you're not really making a
 meaningful contribution to the *data* that underpins the given Wikidata
 entry; i.e. you're not contributing any new information. You're simply
 paraphrasing the first sentence or two of the Wikipedia article. That can't
 possibly be a productive use of contributors' time.

 As for Brian's suggestion:
 It would be a step forward; we can even invent a whole template-type
 syntax for transcluding bits of actual data into the description. But IMO,
 that kind of effort would still be better spent on fully-automatic
 descriptions, because that's the ideal that semi-automatic descriptions can
 only approach.


 On Tue, Aug 18, 2015 at 10:36 PM, Brian Gerstle bgers...@wikimedia.org
 wrote:

 Could there be a way to have our nicely curated description cake and
 eat it too? For example, interpolating data into the description and/or
 marking data points which are referenced in the description (so as to mark
 it as outdated when they change)?

 I appreciate the potential benefits of generated descriptions (and
 other things), but Monte's examples might have swayed me towards human
 curated—when available.

 On Tuesday, August 18, 2015, Monte Hurd mh...@wikimedia.org wrote:

 Ok, so I just did what I proposed. I went to random enwiki articles
 and described the first ten I found which didn't already have 
 descriptions:


 - Courage Under Fire, *1996 film about a Gulf War friendly-fire
 incident*

 - Pebasiconcha immanis, *largest known species of land snail,
 extinct*

 - List of Kenyan writers, *notable Kenyan authors*

 - Solar eclipse of December 14, 1917, *annular eclipse which lasted
 77 seconds*

 - Natchaug Forest Lumber Shed, *historic Civilian Conservation
 Corps post-and-beam building*

 - Sun of Jamaica (album), *debut 1980 studio album by Goombay Dance
 Band*

 - E-1027, *modernist villa in France by architect Eileen Gray*

 - Daingerfield State Park, *park in Morris County, Texas, USA,
 bordering Lake Daingerfield*

 - Todo Lo Que Soy-En Vivo, *2014 Live album by Mexican pop singer
 Fey*

 - 2009 UEFA Regions' Cup, *6th UEFA Regions' Cup, won by Castile
 and Leon*



 And here are the respective descriptions from Magnus' (quite
 excellent) autodesc.js:



 - Courage Under Fire, *1996 film by Edward Zwick, produced by John
 Davis and David T. Friendly from United States of America*

 - Pebasiconcha immanis, *species of Mollusca*

 - List of Kenyan writers, *Wikimedia list article*

 - Solar eclipse of December 14, 1917, *solar eclipse*

 - Natchaug Forest Lumber Shed, *Construction in Connecticut, United
 States of America*

 - Sun of Jamaica (album), *album*

 - E-1027, *villa in Roquebrune-Cap-Martin, France*

 - Daingerfield State Park, *state park and state park of a state of
 the United States in Texas, United States of America*

 - Todo Lo Que Soy-En Vivo, *live album by Fey*

 - 2009 UEFA Regions' Cup, *none*



 Thoughts?

 Just trying to make my own bold assertions falsifiable :)



 On Tue, Aug 18, 2015 at 6:32 PM, Monte Hurd

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Monte Hurd]

, Aug 18, 2015 at 10:36 PM, Brian Gerstle bgers...@wikimedia.org
  wrote:

 Could there be a way to have our nicely curated description cake and
 eat it too? For example, interpolating data into the description and/or
 marking data points which are referenced in the description (so as to mark
 it as outdated when they change)?

 I appreciate the potential benefits of generated descriptions (and
 other things), but Monte's examples might have swayed me towards human
 curated—when available.

 On Tuesday, August 18, 2015, Monte Hurd mh...@wikimedia.org wrote:

 Ok, so I just did what I proposed. I went to random enwiki articles
 and described the first ten I found which didn't already have 
 descriptions:


 - Courage Under Fire, *1996 film about a Gulf War friendly-fire
 incident*

 - Pebasiconcha immanis, *largest known species of land snail,
 extinct*

 - List of Kenyan writers, *notable Kenyan authors*

 - Solar eclipse of December 14, 1917, *annular eclipse which
 lasted 77 seconds*

 - Natchaug Forest Lumber Shed, *historic Civilian Conservation
 Corps post-and-beam building*

 - Sun of Jamaica (album), *debut 1980 studio album by Goombay
 Dance Band*

 - E-1027, *modernist villa in France by architect Eileen Gray*

 - Daingerfield State Park, *park in Morris County, Texas, USA,
 bordering Lake Daingerfield*

 - Todo Lo Que Soy-En Vivo, *2014 Live album by Mexican pop singer
 Fey*

 - 2009 UEFA Regions' Cup, *6th UEFA Regions' Cup, won by Castile
 and Leon*



 And here are the respective descriptions from Magnus' (quite
 excellent) autodesc.js:



 - Courage Under Fire, *1996 film by Edward Zwick, produced by John
 Davis and David T. Friendly from United States of America*

 - Pebasiconcha immanis, *species of Mollusca*

 - List of Kenyan writers, *Wikimedia list article*

 - Solar eclipse of December 14, 1917, *solar eclipse*

 - Natchaug Forest Lumber Shed, *Construction in Connecticut,
 United States of America*

 - Sun of Jamaica (album), *album*

 - E-1027, *villa in Roquebrune-Cap-Martin, France*

 - Daingerfield State Park, *state park and state park of a state
 of the United States in Texas, United States of America*

 - Todo Lo Que Soy-En Vivo, *live album by Fey*

 - 2009 UEFA Regions' Cup, *none*



 Thoughts?

 Just trying to make my own bold assertions falsifiable :)



 On Tue, Aug 18, 2015 at 6:32 PM, Monte Hurd mh...@wikimedia.org
 wrote:

 The whole human-vs-extracted descriptions quality question could be
 fairly easy to test I think:

 - Pick, some number of articles at random.
 - Run them through a description extraction script.
 - Have a human describe the same articles with, say, the app
 interface I demo'ed.

 If nothing else this exercise could perhaps make what's thus far
 been a wildly abstract discussion more concrete.




 On Tue, Aug 18, 2015 at 6:17 PM, Monte Hurd mh...@wikimedia.org
 wrote:

 If having the most elegant description extraction mechanism was the
 goal I would totally agree ;)

 On Tue, Aug 18, 2015 at 5:19 PM, Dmitry Brant dbr...@wikimedia.org
  wrote:

 IMO, allowing the user to edit the description is a missed
 opportunity to make the user edit the actual *data*, such that the
 description is generated correctly.



 On Tue, Aug 18, 2015 at 8:02 PM, Monte Hurd mh...@wikimedia.org
 wrote:

 IMO, if the goal is quality, then human curated descriptions are
 superior until such time as the auto-generation script passes the 
 Turing
 test ;)

 I see these empty descriptions as an amazing opportunity to give
 *everyone* an easy new way to edit. I whipped an app editing 
 interface up
 at the Lyon hackathon:
 bluetooth720 https://www.youtube.com/watch?v=6VblyGhf_c8

 I used it to add a couple hundred descriptions in a single day
 just by hitting random then adding descriptions for articles which 
 didn't
 have them.

 I'd love to try a limited test of this in production to get a
 sense for how effective human curation can be if the interface is 
 easy to
 use...


 On Tue, Aug 18, 2015 at 1:25 PM, Jan Ainali 
 jan.ain...@wikimedia.se wrote:

 Nice one!

 Does not appear to work on svwiki though. Does it have something
 to do with that the wiki in question does not display that tagline?


 *Med vänliga hälsningar,Jan Ainali*

 Verksamhetschef, Wikimedia Sverige http://wikimedia.se
 0729 - 67 29 48


 *Tänk dig en värld där varje människa har fri tillgång till
 mänsklighetens samlade kunskap. Det är det vi gör.*
 Bli medlem. http://blimedlem.wikimedia.se


 2015-08-18 17:23 GMT+02:00 Magnus Manske 
 magnusman...@googlemail.com:

 Show automatic description underneath From Wikipedia...:
 https://en.wikipedia.org/wiki/User:Magnus_Manske/autodesc.js

 To use, add:
 importScript ( 'User:Magnus_Manske/autodesc.js' ) ;
 to your common.js

 On Tue, Aug 18, 2015 at 9:47 AM Jane Darnell jane...@gmail.com
 wrote:

 It would be even better if this (short: 3 field max)
 pipe-separated list was available as a gadget to wikidatans on 
 Wikipedia
 (like me). I can't see

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Monte Hurd]

True about algorithms never being finished, but aren't we essentially
stuck with the first run output, unless I misunderstand how you envision
this working?

(assuming you don't want to over-write non-blank descriptions the next time
you improve and re-run the process)
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Monte Hurd]

Ok, so I just did what I proposed. I went to random enwiki articles and
described the first ten I found which didn't already have descriptions:


- Courage Under Fire, *1996 film about a Gulf War friendly-fire incident*

- Pebasiconcha immanis, *largest known species of land snail, extinct*

- List of Kenyan writers, *notable Kenyan authors*

- Solar eclipse of December 14, 1917, *annular eclipse which lasted 77
seconds*

- Natchaug Forest Lumber Shed, *historic Civilian Conservation Corps
post-and-beam building*

- Sun of Jamaica (album), *debut 1980 studio album by Goombay Dance Band*

- E-1027, *modernist villa in France by architect Eileen Gray*

- Daingerfield State Park, *park in Morris County, Texas, USA, bordering
Lake Daingerfield*

- Todo Lo Que Soy-En Vivo, *2014 Live album by Mexican pop singer Fey*

- 2009 UEFA Regions' Cup, *6th UEFA Regions' Cup, won by Castile and Leon*



And here are the respective descriptions from Magnus' (quite excellent)
autodesc.js:



- Courage Under Fire, *1996 film by Edward Zwick, produced by John Davis
and David T. Friendly from United States of America*

- Pebasiconcha immanis, *species of Mollusca*

- List of Kenyan writers, *Wikimedia list article*

- Solar eclipse of December 14, 1917, *solar eclipse*

- Natchaug Forest Lumber Shed, *Construction in Connecticut, United
States of America*

- Sun of Jamaica (album), *album*

- E-1027, *villa in Roquebrune-Cap-Martin, France*

- Daingerfield State Park, *state park and state park of a state of the
United States in Texas, United States of America*

- Todo Lo Que Soy-En Vivo, *live album by Fey*

- 2009 UEFA Regions' Cup, *none*



Thoughts?

Just trying to make my own bold assertions falsifiable :)



On Tue, Aug 18, 2015 at 6:32 PM, Monte Hurd mh...@wikimedia.org wrote:

 The whole human-vs-extracted descriptions quality question could be fairly
 easy to test I think:

 - Pick, some number of articles at random.
 - Run them through a description extraction script.
 - Have a human describe the same articles with, say, the app interface I
 demo'ed.

 If nothing else this exercise could perhaps make what's thus far been a
 wildly abstract discussion more concrete.




 On Tue, Aug 18, 2015 at 6:17 PM, Monte Hurd mh...@wikimedia.org wrote:

 If having the most elegant description extraction mechanism was the goal
 I would totally agree ;)

 On Tue, Aug 18, 2015 at 5:19 PM, Dmitry Brant dbr...@wikimedia.org
 wrote:

 IMO, allowing the user to edit the description is a missed opportunity
 to make the user edit the actual *data*, such that the description is
 generated correctly.



 On Tue, Aug 18, 2015 at 8:02 PM, Monte Hurd mh...@wikimedia.org wrote:

 IMO, if the goal is quality, then human curated descriptions are
 superior until such time as the auto-generation script passes the Turing
 test ;)

 I see these empty descriptions as an amazing opportunity to give
 *everyone* an easy new way to edit. I whipped an app editing interface up
 at the Lyon hackathon:
 https://www.youtube.com/watch?v=6VblyGhf_c8

 I used it to add a couple hundred descriptions in a single day just by
 hitting random then adding descriptions for articles which didn't have
 them.

 I'd love to try a limited test of this in production to get a sense for
 how effective human curation can be if the interface is easy to use...


 On Tue, Aug 18, 2015 at 1:25 PM, Jan Ainali jan.ain...@wikimedia.se
 wrote:

 Nice one!

 Does not appear to work on svwiki though. Does it have something to do
 with that the wiki in question does not display that tagline?


 *Med vänliga hälsningar,Jan Ainali*

 Verksamhetschef, Wikimedia Sverige http://wikimedia.se
 0729 - 67 29 48


 *Tänk dig en värld där varje människa har fri tillgång till
 mänsklighetens samlade kunskap. Det är det vi gör.*
 Bli medlem. http://blimedlem.wikimedia.se


 2015-08-18 17:23 GMT+02:00 Magnus Manske magnusman...@googlemail.com
 :

 Show automatic description underneath From Wikipedia...:
 https://en.wikipedia.org/wiki/User:Magnus_Manske/autodesc.js

 To use, add:
 importScript ( 'User:Magnus_Manske/autodesc.js' ) ;
 to your common.js

 On Tue, Aug 18, 2015 at 9:47 AM Jane Darnell jane...@gmail.com
 wrote:

 It would be even better if this (short: 3 field max) pipe-separated
 list was available as a gadget to wikidatans on Wikipedia (like me). I
 can't see if a page I am on has an instance of (though it should) and 
 I
 can see the description thanks to another gadget (sorry no idea which 
 one
 that is). Often I will update empty descriptions, but if I was served 
 basic
 fields (so for a painting, the creator field), I would click through to
 update that too.

 On Tue, Aug 18, 2015 at 9:58 AM, Federico Leva (Nemo) 
 nemow...@gmail.com wrote:

 Jane Darnell, 15/08/2015 08:53:

 Yes but even if the descriptions were just the contents of fields
 separated by a pipe it would be better than nothing.


 +1, item descriptions are mostly useless in my experience.

 As for get

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Monte Hurd]

The whole human-vs-extracted descriptions quality question could be fairly
easy to test I think:

- Pick, some number of articles at random.
- Run them through a description extraction script.
- Have a human describe the same articles with, say, the app interface I
demo'ed.

If nothing else this exercise could perhaps make what's thus far been a
wildly abstract discussion more concrete.




On Tue, Aug 18, 2015 at 6:17 PM, Monte Hurd mh...@wikimedia.org wrote:

 If having the most elegant description extraction mechanism was the goal I
 would totally agree ;)

 On Tue, Aug 18, 2015 at 5:19 PM, Dmitry Brant dbr...@wikimedia.org
 wrote:

 IMO, allowing the user to edit the description is a missed opportunity to
 make the user edit the actual *data*, such that the description is
 generated correctly.



 On Tue, Aug 18, 2015 at 8:02 PM, Monte Hurd mh...@wikimedia.org wrote:

 IMO, if the goal is quality, then human curated descriptions are
 superior until such time as the auto-generation script passes the Turing
 test ;)

 I see these empty descriptions as an amazing opportunity to give
 *everyone* an easy new way to edit. I whipped an app editing interface up
 at the Lyon hackathon:
 https://www.youtube.com/watch?v=6VblyGhf_c8

 I used it to add a couple hundred descriptions in a single day just by
 hitting random then adding descriptions for articles which didn't have
 them.

 I'd love to try a limited test of this in production to get a sense for
 how effective human curation can be if the interface is easy to use...


 On Tue, Aug 18, 2015 at 1:25 PM, Jan Ainali jan.ain...@wikimedia.se
 wrote:

 Nice one!

 Does not appear to work on svwiki though. Does it have something to do
 with that the wiki in question does not display that tagline?


 *Med vänliga hälsningar,Jan Ainali*

 Verksamhetschef, Wikimedia Sverige http://wikimedia.se
 0729 - 67 29 48


 *Tänk dig en värld där varje människa har fri tillgång till
 mänsklighetens samlade kunskap. Det är det vi gör.*
 Bli medlem. http://blimedlem.wikimedia.se


 2015-08-18 17:23 GMT+02:00 Magnus Manske magnusman...@googlemail.com:

 Show automatic description underneath From Wikipedia...:
 https://en.wikipedia.org/wiki/User:Magnus_Manske/autodesc.js

 To use, add:
 importScript ( 'User:Magnus_Manske/autodesc.js' ) ;
 to your common.js

 On Tue, Aug 18, 2015 at 9:47 AM Jane Darnell jane...@gmail.com
 wrote:

 It would be even better if this (short: 3 field max) pipe-separated
 list was available as a gadget to wikidatans on Wikipedia (like me). I
 can't see if a page I am on has an instance of (though it should) and I
 can see the description thanks to another gadget (sorry no idea which one
 that is). Often I will update empty descriptions, but if I was served 
 basic
 fields (so for a painting, the creator field), I would click through to
 update that too.

 On Tue, Aug 18, 2015 at 9:58 AM, Federico Leva (Nemo) 
 nemow...@gmail.com wrote:

 Jane Darnell, 15/08/2015 08:53:

 Yes but even if the descriptions were just the contents of fields
 separated by a pipe it would be better than nothing.


 +1, item descriptions are mostly useless in my experience.

 As for get into production on Wikipedia I don't know what it
 means, I certainly don't like 1) mobile-specific features, 2) overriding
 existing manually curated content; but it's good to 3) fill gaps. Mobile
 folks often do (1) and (2), if they *instead* did (3) I'd be very 
 happy. :)

 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



 ___
 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




 --
 Dmitry Brant
 Mobile Apps Team (Android)
 Wikimedia Foundation
 https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering



___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Monte Hurd]

If having the most elegant description extraction mechanism was the goal I
would totally agree ;)

On Tue, Aug 18, 2015 at 5:19 PM, Dmitry Brant dbr...@wikimedia.org wrote:

 IMO, allowing the user to edit the description is a missed opportunity to
 make the user edit the actual *data*, such that the description is
 generated correctly.



 On Tue, Aug 18, 2015 at 8:02 PM, Monte Hurd mh...@wikimedia.org wrote:

 IMO, if the goal is quality, then human curated descriptions are superior
 until such time as the auto-generation script passes the Turing test ;)

 I see these empty descriptions as an amazing opportunity to give
 *everyone* an easy new way to edit. I whipped an app editing interface up
 at the Lyon hackathon:
 https://www.youtube.com/watch?v=6VblyGhf_c8

 I used it to add a couple hundred descriptions in a single day just by
 hitting random then adding descriptions for articles which didn't have
 them.

 I'd love to try a limited test of this in production to get a sense for
 how effective human curation can be if the interface is easy to use...


 On Tue, Aug 18, 2015 at 1:25 PM, Jan Ainali jan.ain...@wikimedia.se
 wrote:

 Nice one!

 Does not appear to work on svwiki though. Does it have something to do
 with that the wiki in question does not display that tagline?


 *Med vänliga hälsningar,Jan Ainali*

 Verksamhetschef, Wikimedia Sverige http://wikimedia.se
 0729 - 67 29 48


 *Tänk dig en värld där varje människa har fri tillgång till
 mänsklighetens samlade kunskap. Det är det vi gör.*
 Bli medlem. http://blimedlem.wikimedia.se


 2015-08-18 17:23 GMT+02:00 Magnus Manske magnusman...@googlemail.com:

 Show automatic description underneath From Wikipedia...:
 https://en.wikipedia.org/wiki/User:Magnus_Manske/autodesc.js

 To use, add:
 importScript ( 'User:Magnus_Manske/autodesc.js' ) ;
 to your common.js

 On Tue, Aug 18, 2015 at 9:47 AM Jane Darnell jane...@gmail.com wrote:

 It would be even better if this (short: 3 field max) pipe-separated
 list was available as a gadget to wikidatans on Wikipedia (like me). I
 can't see if a page I am on has an instance of (though it should) and I
 can see the description thanks to another gadget (sorry no idea which one
 that is). Often I will update empty descriptions, but if I was served 
 basic
 fields (so for a painting, the creator field), I would click through to
 update that too.

 On Tue, Aug 18, 2015 at 9:58 AM, Federico Leva (Nemo) 
 nemow...@gmail.com wrote:

 Jane Darnell, 15/08/2015 08:53:

 Yes but even if the descriptions were just the contents of fields
 separated by a pipe it would be better than nothing.


 +1, item descriptions are mostly useless in my experience.

 As for get into production on Wikipedia I don't know what it means,
 I certainly don't like 1) mobile-specific features, 2) overriding 
 existing
 manually curated content; but it's good to 3) fill gaps. Mobile folks 
 often
 do (1) and (2), if they *instead* did (3) I'd be very happy. :)

 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



 ___
 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




 --
 Dmitry Brant
 Mobile Apps Team (Android)
 Wikimedia Foundation
 https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering


___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] What people think about Wikidata descriptions in search on mobile web beta, and a question about arbitrary access of Wikidata data

[Monte Hurd]

IMO, if the goal is quality, then human curated descriptions are superior
until such time as the auto-generation script passes the Turing test ;)

I see these empty descriptions as an amazing opportunity to give *everyone*
an easy new way to edit. I whipped an app editing interface up at the Lyon
hackathon:
https://www.youtube.com/watch?v=6VblyGhf_c8

I used it to add a couple hundred descriptions in a single day just by
hitting random then adding descriptions for articles which didn't have
them.

I'd love to try a limited test of this in production to get a sense for how
effective human curation can be if the interface is easy to use...


On Tue, Aug 18, 2015 at 1:25 PM, Jan Ainali jan.ain...@wikimedia.se wrote:

 Nice one!

 Does not appear to work on svwiki though. Does it have something to do
 with that the wiki in question does not display that tagline?


 *Med vänliga hälsningar,Jan Ainali*

 Verksamhetschef, Wikimedia Sverige http://wikimedia.se
 0729 - 67 29 48


 *Tänk dig en värld där varje människa har fri tillgång till mänsklighetens
 samlade kunskap. Det är det vi gör.*
 Bli medlem. http://blimedlem.wikimedia.se


 2015-08-18 17:23 GMT+02:00 Magnus Manske magnusman...@googlemail.com:

 Show automatic description underneath From Wikipedia...:
 https://en.wikipedia.org/wiki/User:Magnus_Manske/autodesc.js

 To use, add:
 importScript ( 'User:Magnus_Manske/autodesc.js' ) ;
 to your common.js

 On Tue, Aug 18, 2015 at 9:47 AM Jane Darnell jane...@gmail.com wrote:

 It would be even better if this (short: 3 field max) pipe-separated list
 was available as a gadget to wikidatans on Wikipedia (like me). I can't see
 if a page I am on has an instance of (though it should) and I can see the
 description thanks to another gadget (sorry no idea which one that is).
 Often I will update empty descriptions, but if I was served basic fields
 (so for a painting, the creator field), I would click through to update
 that too.

 On Tue, Aug 18, 2015 at 9:58 AM, Federico Leva (Nemo) 
 nemow...@gmail.com wrote:

 Jane Darnell, 15/08/2015 08:53:

 Yes but even if the descriptions were just the contents of fields
 separated by a pipe it would be better than nothing.


 +1, item descriptions are mostly useless in my experience.

 As for get into production on Wikipedia I don't know what it means, I
 certainly don't like 1) mobile-specific features, 2) overriding existing
 manually curated content; but it's good to 3) fill gaps. Mobile folks often
 do (1) and (2), if they *instead* did (3) I'd be very happy. :)

 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



 ___
 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

Re: [WikimediaMobile] In-app editing / talk pages support

[Monte Hurd]

+1 Dan's team bandwidth comment. 

I totally want to implement native interfaces for all of the fundamentals 
central to editing which Dmitry listed, but we'll just need to plan and stage 
things very deliberately. 

If we eventually do commit to this, we may even consider keeping all of these 
fundamental editing interfaces beta only until all parts are working and 
working well together - even if this takes a while. 


 On Jul 24, 2015, at 7:38 PM, Dan Garry dga...@wikimedia.org wrote:
 
 On 22 July 2015 at 10:52, Dmitry Brant dbr...@wikimedia.org wrote:
 Therefore, providing access to talk pages without providing the other 
 fundamentals that are central to editing (moderation tools, watchlists, 
 diffs, notifications, etc) may be putting the cart before the horse, and may 
 lead to confusion.
 
 I think you hit the nail on the head with this comment.
 
 Experienced Wikipedians know the value of talk pages. For many of them, talk 
 pages actually comprise the majority of their usage of the site. But, the 
 majority of their navigation to those pages are through their watchlist, so 
 adding a talk page link doesn't serve them; they know the talk page is there, 
 and how to find it if they need it.
 
 For newer users, talk pages are their entry point into the inner workings of 
 the wiki, and how they get sucked in. But, there are some pretty fundamental 
 formatting issues with talk pages in the app right now. If you're going to 
 make it read only, how are you going to explain to users why other users are 
 leaving comments, but they can't edit it? Suddenly, there are a lot of 
 questions that will take a lot of team bandwidth, designs, and discussions to 
 answer. Can you commit to answering all of these questions given the other 
 work you have in the pipeline?
 
 For the reasons above, I was opposed (and still am) to adding links to talk 
 pages in the app. For experienced editors, they know where to find them and 
 don't need a button to get there. For readers (the primary user type that the 
 app supports), the talk page experience in the app is not good enough to 
 expose the users to it, and we never had the capacity to get the experience 
 to a place where it was good enough for them without considerable work to 
 build out the entire pipeline.
 
 Dan
 
 -- 
 Dan Garry
 Lead Product Manager, Discovery
 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

Re: [WikimediaMobile] [Apps] Android Wikipedia beta app release (2.0.106-beta-2015-07-20)

[Monte Hurd]

Ooh can you point me to mocks for the floating toc button?

 On Jul 20, 2015, at 1:49 PM, Stephen Niedzielski sniedziel...@wikimedia.org 
 wrote:
 
   The Android team[0] is delighted to announce a new Wikipedia Android app 
 beta release, v2.0.106-beta-2015-07-20[1]. In summary[2], this revision 
 includes the following improvements:
 
   * New! Floating table of contents access button.
   * New! Language selection button in search bar.
   * New! Better references when sharing facts as text.
   * New! Footer link to open the current page in a browser.
   * New! One-time tooltips that describe various app features.
   * More consistent and accurate error messages.
   * Two weeks of UI refinements  bug fixes.
 
   Make it better! Read our getting started guide[3]. We can't wait for your 
 contributions!
 
   [0] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team#Android_App
   [1] Rolling out at 
 https://play.google.com/store/apps/details?id=org.wikipedia.beta
   [2] A complete list of changes is available at 
 http://git.wikimedia.org/commits/apps%2Fandroid%2Fwikipedia/beta%2F2.0.105-beta-2015-06-30..beta%2F2.0.106-beta-2015-07-20
   [3] 
 https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Wikipedia_Android_app_hacking
 ___
 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

Re: [WikimediaMobile] [Apps] Android Wikipedia beta app release (2.0.106-beta-2015-07-20)

[Monte Hurd]

Neat! Thanks Stephen!

 On Jul 20, 2015, at 4:35 PM, Stephen Niedzielski sniedziel...@wikimedia.org 
 wrote:
 
   I believe this[0] was the original task. I don't know of any mocks but 
 here's the final implementation in a restful state[1] and when scrolling[2]. 
 It's quite Material-y[3] so I suspect you will be putting an iOS spin on it, 
 in which case Android screenshots / mocks probably won't be very useful.
 
 
 --stephen
 
 [0] https://phabricator.wikimedia.org/T104654
 [1] https://img.bi/#/cZHQG8C!azhexEwlltfdgnfbQQfogzvNzmCZ1rDtieaasIad
 [2] https://img.bi/#/1keLiNs!yMhameApH2ClaMbaJwlfebgiwgEJbGhqRjcdjfGo
 [3] 
 http://www.google.com/design/spec/components/buttons-floating-action-button.html#buttons-floating-action-button-floating-action-button
 
 On Mon, Jul 20, 2015 at 1:40 PM, Monte Hurd mh...@wikimedia.org wrote:
 Ooh can you point me to mocks for the floating toc button?
 
 On Jul 20, 2015, at 1:49 PM, Stephen Niedzielski 
 sniedziel...@wikimedia.org wrote:
 
   The Android team[0] is delighted to announce a new Wikipedia Android app 
 beta release, v2.0.106-beta-2015-07-20[1]. In summary[2], this revision 
 includes the following improvements:
 
   * New! Floating table of contents access button.
   * New! Language selection button in search bar.
   * New! Better references when sharing facts as text.
   * New! Footer link to open the current page in a browser.
   * New! One-time tooltips that describe various app features.
   * More consistent and accurate error messages.
   * Two weeks of UI refinements  bug fixes.
 
   Make it better! Read our getting started guide[3]. We can't wait for your 
 contributions!
 
   [0] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team#Android_App
   [1] Rolling out at 
 https://play.google.com/store/apps/details?id=org.wikipedia.beta
   [2] A complete list of changes is available at 
 http://git.wikimedia.org/commits/apps%2Fandroid%2Fwikipedia/beta%2F2.0.105-beta-2015-06-30..beta%2F2.0.106-beta-2015-07-20
   [3] 
 https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Wikipedia_Android_app_hacking
 ___
 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

Re: [WikimediaMobile] deep-linking in apps

[Monte Hurd]

Some background for iOS - Apple has *vastly* improved their deep linking 
support w iOS 9: 

http://searchengineland.com/apple-ios-9-deep-linking-promises-improved-app-discoverability-even-for-apps-not-installed-222845

This is a huge and long overdue improvement for iOS and should really be great 
for our use cases. 



 On Jul 13, 2015, at 10:28 AM, Toby Negrin tneg...@wikimedia.org wrote:
 
 Do we support any deep-linking[1] scheme for our apps? I know that we've made 
 some steps in integrating with google search on this but I don't know what 
 our general approach.
 
 thanks,
 
 -Toby
 
 [1] https://en.wikipedia.org/wiki/Mobile_deep_linking
 ___
 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

Re: [WikimediaMobile] The path to video: media playback for the iOS app

[Monte Hurd]

Brion this is so exciting! :)

On Wed, Jun 24, 2015 at 3:53 PM, Brion Vibber bvib...@wikimedia.org wrote:

 We've been stalled for years on adding media playback to the Wikipedia iOS
 app due to the impasse between Wikimedia's insistence on free formats and
 Apple's insistence on only supporting patented formats.

 I'm trying to route around that impasse by getting Ogg and WebM playback
 up and running on iOS through a native widget library, which I've been
 cleaning up to ready it for CocoaPods packaging.

 Here's the high-level library:
 https://github.com/brion/OGVKit

 and provisional CocoaPods specifications for the low-level open-source
 libraries it needs:
 https://github.com/brion/OGVKit-Specs

 Once I finish some further fixes and do an API cleanup (version 0.5 on my
 provisional milestones https://github.com/brion/OGVKit/milestones) I
 plan to publish my podspecs and write a patch to the Wikipedia app that
 uses OGVKit to handle media playback.


 Rough patch plan:
 * add OGVKit as dependency
 * enhance the photo carousel view to instantiate a player view for
 audio/video files, just like on Android
 * add content CSS to clean up those video thumbnail 'Play media' links
 * add a JS click handler for 'Play media' links to launch the carousel
 * add a JS click handler for audio and video elements in content
 * add a bunch of libraries to the list on the about page

 Ideally this should be a surgical patch and relatively minimal, though
 an update of the Pods dir will pull in a lot of files. :)

 -- brion

 ___
 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

Re: [WikimediaMobile] Wikidata descriptions: ruminations

[Monte Hurd]

Responses inline...


On Mar 22, 2015, at 1:53 PM, Dmitry Brant dbr...@wikimedia.org wrote:

Hi Lydia,

Indeed, there are many more Wikidata items than Wikipedia articles.
However, the users of our mobile apps only see Wikipedia articles in our
search results (at least for now),




They are also used in Recent and  Nearby and Vibha wants them in Saved
Pages list as well.



which means that they will only be able to contribute descriptions to
Wikidata items for which a Wikipedia article exists.

No doubt, the description field is an important component of each Wikidata
entry.  But, when there is a corresponding Wikipedia article, why not query
it to provide an automatic description?


This could be based on the first sentence of the article, or a subset of
the first sentence, or some other kind of metadata within the article.





For example, take the enwiki Fish article.

The first couple sentences are these:

*A fish is any member of a paraphyletic group of organisms that consist of
all gill-bearing aquatic craniate animals that lack limbs with digits.
Included in this definition are the living hagfish, lampreys, and
cartilaginous and bony fish, as well as various extinct related groups.*

So if the we reduce the description to its first sentence we have:

*A fish is any member of a paraphyletic group of organisms that consist of
all gill-bearing aquatic craniate animals that lack limbs with digits. *

Now, for the sake of argument, let's imagine the *bold *words below
represent a best case scenario for a relevant *subset* of the first
sentence:

*A fish is any member of a paraphyletic group of organisms that consist of
all gill-bearing aquatic craniate animals that lack limbs with digits. *

A fish is a gill-bearing aquatic animal.

That's nice and short and descriptive and reads like a little sentence.
It's arguably the best reduction of the first sentence possible.

But reducing the first sentence in this way is deceptively complicated to
do programmatically, precisely because of the word arguably in the
preceding sentence. You have to know *what a fish is* to know what parts of
the first sentence are *most* important.

In other words, the best description is much more qualitative than it is
quantifiable.



type of living organism typified by living in water and having gills











The key is that the description would stay with the article, which would
eliminate the need for duplication and synchronization.

So, in a sense, I would look at it the other way: descriptions within
Wikipedia articles would be useful for Wikidata entries.

-Dmitry

On Sun, Mar 22, 2015 at 4:17 PM, Lydia Pintscher 
lydia.pintsc...@wikimedia.de wrote:

 On Sun, Mar 22, 2015 at 9:10 PM, Dmitry Brant dbr...@wikimedia.org
 wrote:
  Hi Jane,
 
  Perhaps my comments came off as more pessimistic than I intended. Of
 course
  I believe in the power of crowdsourcing, and I would never want to make
  anyone feel like their contributions are being marginalized.
 
  I'll agree for now that the idea of fully automated descriptions leans
  more towards science fiction than reality. :)
 
  However, my whole point has more to do with the apparent duplication of
  content that seems to be happening between the first sentence of
 Wikipedia
  articles and the corresponding Wikidata description.  There's something
  about it that seems unnecessary.  If we can figure out a way to
  automatically extract the description from the first sentence of the
  article, it would simplify things in two ways:
 
  1) People wouldn't need to edit Wikidata descriptions, and would instead
  focus on improving the Wikipedia article.
  2) People who monitor changes made to articles would need to monitor only
  the article, instead of the article plus its corresponding Wikidata
  description.

 There are a lot more items on Wikidata than articles on Wikipedia. And
 not every language has a Wikipedia article for each item. Don't just
 look at descriptions on Wikidata as something useful for Wikipedia.
 They're much more than that.


 Cheers
 Lydia

 --
 Lydia Pintscher - http://about.me/lydia.pintscher
 Product Manager for Wikidata

 Wikimedia Deutschland e.V.
 Tempelhofer Ufer 23-24
 10963 Berlin
 www.wikimedia.de

 Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

 Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
 unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
 Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

 ___
 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

Re: [WikimediaMobile] Wikidata descriptions: ruminations

[Monte Hurd]

Ignore that last reply - I accidentally hit submit while mid-way through
writing it.

On Sun, Mar 22, 2015 at 6:03 PM, Monte Hurd mh...@wikimedia.org wrote:

 Responses inline...


 On Mar 22, 2015, at 1:53 PM, Dmitry Brant dbr...@wikimedia.org wrote:

 Hi Lydia,

 Indeed, there are many more Wikidata items than Wikipedia articles.
 However, the users of our mobile apps only see Wikipedia articles in our
 search results (at least for now),




 They are also used in Recent and  Nearby and Vibha wants them in
 Saved Pages list as well.



 which means that they will only be able to contribute descriptions to
 Wikidata items for which a Wikipedia article exists.

 No doubt, the description field is an important component of each Wikidata
 entry.  But, when there is a corresponding Wikipedia article, why not query
 it to provide an automatic description?


 This could be based on the first sentence of the article, or a subset of
 the first sentence, or some other kind of metadata within the article.





 For example, take the enwiki Fish article.

 The first couple sentences are these:

 *A fish is any member of a paraphyletic group of organisms that consist of
 all gill-bearing aquatic craniate animals that lack limbs with digits.
 Included in this definition are the living hagfish, lampreys, and
 cartilaginous and bony fish, as well as various extinct related groups.*

 So if the we reduce the description to its first sentence we have:

 *A fish is any member of a paraphyletic group of organisms that consist of
 all gill-bearing aquatic craniate animals that lack limbs with digits. *

 Now, for the sake of argument, let's imagine the *bold *words below
 represent a best case scenario for a relevant *subset* of the first
 sentence:

 *A fish is any member of a paraphyletic group of organisms that consist of
 all gill-bearing aquatic craniate animals that lack limbs with digits. *

 A fish is a gill-bearing aquatic animal.

 That's nice and short and descriptive and reads like a little sentence.
 It's arguably the best reduction of the first sentence possible.

 But reducing the first sentence in this way is deceptively complicated to
 do programmatically, precisely because of the word arguably in the
 preceding sentence. You have to know *what a fish is* to know what parts
 of the first sentence are *most* important.

 In other words, the best description is much more qualitative than it is
 quantifiable.



 type of living organism typified by living in water and having gills











 The key is that the description would stay with the article, which would
 eliminate the need for duplication and synchronization.

 So, in a sense, I would look at it the other way: descriptions within
 Wikipedia articles would be useful for Wikidata entries.

 -Dmitry

 On Sun, Mar 22, 2015 at 4:17 PM, Lydia Pintscher 
 lydia.pintsc...@wikimedia.de wrote:

 On Sun, Mar 22, 2015 at 9:10 PM, Dmitry Brant dbr...@wikimedia.org
 wrote:
  Hi Jane,
 
  Perhaps my comments came off as more pessimistic than I intended. Of
 course
  I believe in the power of crowdsourcing, and I would never want to make
  anyone feel like their contributions are being marginalized.
 
  I'll agree for now that the idea of fully automated descriptions leans
  more towards science fiction than reality. :)
 
  However, my whole point has more to do with the apparent duplication of
  content that seems to be happening between the first sentence of
 Wikipedia
  articles and the corresponding Wikidata description.  There's something
  about it that seems unnecessary.  If we can figure out a way to
  automatically extract the description from the first sentence of the
  article, it would simplify things in two ways:
 
  1) People wouldn't need to edit Wikidata descriptions, and would instead
  focus on improving the Wikipedia article.
  2) People who monitor changes made to articles would need to monitor
 only
  the article, instead of the article plus its corresponding Wikidata
  description.

 There are a lot more items on Wikidata than articles on Wikipedia. And
 not every language has a Wikipedia article for each item. Don't just
 look at descriptions on Wikidata as something useful for Wikipedia.
 They're much more than that.


 Cheers
 Lydia

 --
 Lydia Pintscher - http://about.me/lydia.pintscher
 Product Manager for Wikidata

 Wikimedia Deutschland e.V.
 Tempelhofer Ufer 23-24
 10963 Berlin
 www.wikimedia.de

 Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

 Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
 unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
 Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

 ___
 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

Re: [WikimediaMobile] Wikidata descriptions: ruminations

[Monte Hurd]

My previous reply was partial and accidentally sent - here's my actual
reply :)




On Sun, Mar 22, 2015 at 1:53 PM, Dmitry Brant dbr...@wikimedia.org wrote:

 Hi Lydia,

 Indeed, there are many more Wikidata items than Wikipedia articles.
 However, the users of our mobile apps only see Wikipedia articles in our
 search results (at least for now), which means that they will only be able
 to contribute descriptions to Wikidata items for which a Wikipedia article
 exists.




They are also used in *Recent* and  *Nearby* and Vibha wants them
in *Saved
Pages* list as well.





 No doubt, the description field is an important component of each Wikidata
 entry.  But, when there is a corresponding Wikipedia article, why not query
 it to provide an automatic description? This could be based on the first
 sentence of the article, or a subset of the first sentence, or some other
 kind of metadata within the article.





Why not query it to provide an automatic description? Because finding the
best subset of the first sentence(s) isn't all there is to it.

For example, take the enwiki Fish article.

The first couple sentences are these:

*A fish is any member of a paraphyletic group of organisms that consist of
all gill-bearing aquatic craniate animals that lack limbs with digits.
Included in this definition are the living hagfish, lampreys, and
cartilaginous and bony fish, as well as various extinct related groups.*



So if the we reduce the description to its first sentence we have:

*A fish is any member of a paraphyletic group of organisms that consist of
all gill-bearing aquatic craniate animals that lack limbs with digits. *



Now, for the sake of argument, let's imagine the *bold* words below
represent a best case scenario for a relevant subset of the first sentence:

*A fish is* any member of *a* paraphyletic group of organisms that consist
of all *gill-bearing aquatic* craniate *animal*s that lack limbs with
digits.



So, we have *A fish is a gill-bearing aquatic animal*, or you could
reduce it further to a *gill-bearing aquatic animal*.


But reducing the first sentence in this way is deceptively complicated to
do programmatically, precisely because of the word arguably in the
preceding sentence - it's almost entirely a matter of qualitative
judgement. You have to know what a fish is to know what parts of the first
sentence are most important and then you have to know how to contextually
stitch these words together according to rules of the language's grammar
and syntax so they read nicely (see the word a and the s on the end
of animal*s*).

Basically, great descriptions require a native speaker of the language with
some skill at summarizing. This is such a low bar for humans that almost
anyone could contribute quality descriptions.


But, If descriptions are not human editable, then we are stuck with the
limitations of whatever heuristics are used to auto-generate the
description.














 The key is that the description would stay with the article, which would
 eliminate the need for duplication and synchronization.

 So, in a sense, I would look at it the other way: descriptions within
 Wikipedia articles would be useful for Wikidata entries.

 -Dmitry

 On Sun, Mar 22, 2015 at 4:17 PM, Lydia Pintscher 
 lydia.pintsc...@wikimedia.de wrote:

 On Sun, Mar 22, 2015 at 9:10 PM, Dmitry Brant dbr...@wikimedia.org
 wrote:
  Hi Jane,
 
  Perhaps my comments came off as more pessimistic than I intended. Of
 course
  I believe in the power of crowdsourcing, and I would never want to make
  anyone feel like their contributions are being marginalized.
 
  I'll agree for now that the idea of fully automated descriptions leans
  more towards science fiction than reality. :)
 
  However, my whole point has more to do with the apparent duplication of
  content that seems to be happening between the first sentence of
 Wikipedia
  articles and the corresponding Wikidata description.  There's something
  about it that seems unnecessary.  If we can figure out a way to
  automatically extract the description from the first sentence of the
  article, it would simplify things in two ways:
 
  1) People wouldn't need to edit Wikidata descriptions, and would instead
  focus on improving the Wikipedia article.
  2) People who monitor changes made to articles would need to monitor
 only
  the article, instead of the article plus its corresponding Wikidata
  description.

 There are a lot more items on Wikidata than articles on Wikipedia. And
 not every language has a Wikipedia article for each item. Don't just
 look at descriptions on Wikidata as something useful for Wikipedia.
 They're much more than that.


 Cheers
 Lydia

 --
 Lydia Pintscher - http://about.me/lydia.pintscher
 Product Manager for Wikidata

 Wikimedia Deutschland e.V.
 Tempelhofer Ufer 23-24
 10963 Berlin
 www.wikimedia.de

 Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

 Eingetragen im Vereinsregister des Amtsgerichts 

Re: [WikimediaMobile] [Apps] Read next vs Read more: the verdict

[Monte Hurd]

Whoa interesting!


 On Mar 20, 2015, at 10:29 PM, Dan Garry dga...@wikimedia.org wrote:
 
 Hi everyone,
 
 For those of you who aren't aware, the Mobile Apps Team has been running an 
 experiment in Wikipedia Beta on Android. We're trialling a single, visually 
 appealing result at the end of articles instead of the three from Read 
 more. We're calling this Read next. What happens is that approximately 
 half of Wikipedia Beta users are shown read next on every article, and the 
 other half are shown read more. Here's some example screenshots:
 Read next: http://i.imgur.com/StTLAPU.png
 Read more: http://i.imgur.com/ecb2cy2.png
 Here's the verdict of the test!
 Read more has a clickthrough rate of 15.4% (65,448 views, 10,600 clicks)
 Read next has a clickthrough rate of 10.4% (59,668 views, 6,180 clicks)
 So it would seem that read next is not as effective at driving clicks as read 
 more is. Interesting!
 
 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

Re: [WikimediaMobile] Readability of the first sentence on Wikipedia articles

[Monte Hurd]

 On Mar 9, 2015, at 11:17 AM, Ryan Kaldari rkald...@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 jane...@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.ahar...@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 dga...@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 jrob...@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 vba...@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 

Re: [WikimediaMobile] [ios] re-mapping your Xcode hotkeys to uncrustify

[Monte Hurd]

Thanks Brian! This is great!


 On Mar 4, 2015, at 7:26 AM, Brian Gerstle bgers...@wikimedia.org wrote:
 
 Now that the iOS app is using uncrustify to standardize code formatting, we 
 recommend that you setup the BBUncrustify Xcode plugin to reformat your code 
 instead of using Xcode's default Re-indent functionality.  
 
 Optional: if you want to re-map Ctrl-I (default re-indent hotkey) to use 
 uncrustify, you should first remove the default mapping in Xcode:
 In Xcode, go to Preferences and click the Key Bindings tab
 Search for indent and remove the key binding for Ctrl-I
 image.png
 
 Now add an application keyboard shortcut for Xcode:
 Open the System Preferences  Keyboard  Shortcuts  App Shortcuts  Click +
 Set the application to be Xcode
 Set the menu title to an action title, e.g. Format Selected Lines
 Set your shortcut, e.g. Ctrl-I
 image.png
 
 Happy code linting!
 
 Brian
 
 P.S.
 You can also use this approach to set shortcuts for any other functionality!  
 You might want to run scripts/setup_git_hooks.sh to install the uncrustify 
 pre-commit hook.
 
 -- 
 EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
 IRC: bgerstle
 ___
 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

Re: [WikimediaMobile] Node.js service prototype for mobileapps

[Monte Hurd]

Very cool!!!


 On Mar 2, 2015, at 12:56 PM, Bernd Sitzmann be...@wikimedia.org wrote:
 
 Hi,
 
 As part of the Node.js prototype spike, I created a Github repo:
 https://github.com/berndsi/service-mobileapp-node/tree/dev
 
 Note that this is the dev branch, where I put the mobileapp specific code for 
 now. Most info is available in the README. It tells you how to get started, 
 install the prerequisites, and how to run and use the service. I also added a 
 troubleshooting section at the end. As mentioned there, I had to nuke the 
 node_modules folder a few times. Besides that, it went quite smoothly.
 
 The current version uses mobileview action as the source, and then removes a 
 few DOM elements (via the domino node module).
 It uses the bluebird node module for the promises implementation, which makes 
 async code nicer.
 You can try an example once you have it installed with 
 http://localhost:6927/en.m.wikipedia.org/v1/mobileapp/lite/cat.
 
 I originally forked https://github.com/wikimedia/service-template-node
 but needed two repos in my Github account, so I can push template changes 
 upstream, and another to develop the mobileapp code.
 Marko and Gabriel from the services team created the template and helped me 
 getting started. Thank you!
 
 This is just a prototype. So, here's a short list of ideas we could try to 
 make this more useful for a Mobile Lite app that doesn't require use WebViews:
 * Use Parsoid as mentioned in https://phabricator.wikimedia.org/T90758#1074382
 * Split the text objects of each section into paragraph and table objects
 * Add some transformations that currently are being done by the apps and 
 remove some more unneeded data
 
 Cheers,
 Bernd
 ___
 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

Re: [WikimediaMobile] Masonry (iOS 3rd party library)

[Monte Hurd]

I found this Swift version of Masonry: https://github.com/Masonry/Snap

Are we confident in it, or does anyone know if the original Masonry repo
maintainers have Swift plans?

If not, assuming one of our long-term goals is to eventually convert as
much of the codebase to Swift as is practical, wouldn't adopting Masonry
further entrench Obj-C implementations?

i.e. to Swift-ify Masonry'ed code we'd have to decompose Masonry syntax
back to VFL strings and/or NSLayoutConstraints.

If there's not a solid Swift implementation, I'd be unsure if Masonry use
is wise strategically. Thoughts?

Any concern that Masonry's syntax, while concise/elegant, raises the bar
for outside contributions in that it deviates from the standard approach
at all?


On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle bgers...@wikimedia.org
wrote:

 +1

 On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd cfl...@wikimedia.org
 wrote:

 We were evaluating Masonry prior to our new 3rd party lib vetting process 
 (See
 here for more info:
 https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries),
 but still wanted to do a write up for everyone.

 Masonry is a library that allows developers to write autolayout code
 similar to the Visual Format Language, but instead of error prone strings
 to describe relationships, it provides a compact compiler checked syntax.
 You can read more here:
 https://github.com/Masonry/Masonry


 Below are answers to our standard questions:


- Is the license permissive?

 Yes - MIT

- Is the library ubiquitous?

 Yes 4,362+ stars and 475 forks on Github.

-  Is it installable via CocoaPods?

 Yes

- What is the impact on binary size?

 Negligible - no included assets

- How severe, if at all, are inbuilt subdependencies?

 No 3rd party dependencies

- Will this make the code more, or less, understandable for
volunteers?

 More understandable - it provides an expressive english syntax for
 creating autolayout constraints. It introduces no new concepts, just type
 checking and syntax.

- What are the performance ramifications of using this library?

 None, it uses cocoa autolayout under the covers.

- What are the complexity ramifications of using this library?

 Masonry allows developers to write layout code in a much more concise and
 expressive way - this should reduce number of lines while increasing
 expressiveness.

- Is it actively maintained?

 Yes and receives frequent pull requests.

- Is it compatible with current deployment targets?

 Yep

- Does it hinder interop (e.g., with Swift)?

 Nope

- What is the exit plan if the library becomes unmaintained?

 Since Masonry is basically just a syntax veneer of autolayout - it should
 be possible for us to maintain if needed. There aren't any foreign concepts
 to understand. If we choose not to maintain - the constraints can be
 translated to the VFL language (or Interface Builder) easily.



 If anyone has questions / comments - please reply here.



 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l




 --
 EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
 IRC: bgerstle

 ___
 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

Re: [WikimediaMobile] Masonry (iOS 3rd party library)

[Monte Hurd]

Oooh interesting! I hadn't considered calling back to the Obj-C version
from Swift land...

On Wed, Feb 18, 2015 at 3:13 PM, Brion Vibber bvib...@wikimedia.org wrote:

 It looks like it is possible to use the Obj-C version from Swift:

 https://github.com/Masonry/Masonry/issues/75#issuecomment-55230720

 so one could probably migrate UI classes using it bit by bit.

 But the new all-Swift version in Snap apparently has a cleaner syntax that
 fits with Swift better...

 Actually, do they conflict? Could we start with one in Obj-C and
 transition to the Swift one in Swift classes, while both sit in place? In
 theory they're creating regular layout constraints so it's just the setup
 calls that are different...

 -- brion

 On Wed, Feb 18, 2015 at 2:59 PM, Monte Hurd mh...@wikimedia.org wrote:

 I found this Swift version of Masonry: https://github.com/Masonry/Snap

 Are we confident in it, or does anyone know if the original Masonry repo
 maintainers have Swift plans?

 If not, assuming one of our long-term goals is to eventually convert as
 much of the codebase to Swift as is practical, wouldn't adopting Masonry
 further entrench Obj-C implementations?

 i.e. to Swift-ify Masonry'ed code we'd have to decompose Masonry syntax
 back to VFL strings and/or NSLayoutConstraints.

 If there's not a solid Swift implementation, I'd be unsure if Masonry use
 is wise strategically. Thoughts?

 Any concern that Masonry's syntax, while concise/elegant, raises the bar
 for outside contributions in that it deviates from the standard approach
 at all?


 On Wed, Feb 18, 2015 at 10:09 AM, Brian Gerstle bgers...@wikimedia.org
 wrote:

 +1

 On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd cfl...@wikimedia.org
 wrote:

 We were evaluating Masonry prior to our new 3rd party lib vetting
 process (See here for more info:
 https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries),
 but still wanted to do a write up for everyone.

 Masonry is a library that allows developers to write autolayout code
 similar to the Visual Format Language, but instead of error prone strings
 to describe relationships, it provides a compact compiler checked syntax.
 You can read more here:
 https://github.com/Masonry/Masonry


 Below are answers to our standard questions:


- Is the license permissive?

 Yes - MIT

- Is the library ubiquitous?

 Yes 4,362+ stars and 475 forks on Github.

-  Is it installable via CocoaPods?

 Yes

- What is the impact on binary size?

 Negligible - no included assets

- How severe, if at all, are inbuilt subdependencies?

 No 3rd party dependencies

- Will this make the code more, or less, understandable for
volunteers?

 More understandable - it provides an expressive english syntax for
 creating autolayout constraints. It introduces no new concepts, just type
 checking and syntax.

- What are the performance ramifications of using this library?

 None, it uses cocoa autolayout under the covers.

- What are the complexity ramifications of using this library?

 Masonry allows developers to write layout code in a much more concise
 and expressive way - this should reduce number of lines while increasing
 expressiveness.

- Is it actively maintained?

 Yes and receives frequent pull requests.

- Is it compatible with current deployment targets?

 Yep

- Does it hinder interop (e.g., with Swift)?

 Nope

- What is the exit plan if the library becomes unmaintained?

 Since Masonry is basically just a syntax veneer of autolayout - it
 should be possible for us to maintain if needed. There aren't any foreign
 concepts to understand. If we choose not to maintain - the constraints can
 be translated to the VFL language (or Interface Builder) easily.



 If anyone has questions / comments - please reply here.



 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l




 --
 EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
 IRC: bgerstle

 ___
 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

Re: [WikimediaMobile] iOS code style

[Monte Hurd]

Great! Thanks again for note taking and updates!


 On Feb 13, 2015, at 3:17 PM, Brian Gerstle bgers...@wikimedia.org wrote:
 
 After a meeting in which the team reviewed Corey's suggested coding style 
 guidelines, I've made the following edits:
 Use of dot-notation for instance methods that are cheap  free of side-effects
 Added note about auto-trimming trailing whitespace via Xcode settings
 More if statement examples (one-line w/ curly brackets)
 Ternary statement with ?: operator (Ruby/JS or behavior)
 ObjC method declaration and invocation spacing guidelines
 Block declarations as typedef and method arguments
 Category instance method prefix
 Use of extern for public constants, and static for private ones
 Replaced FJ  Flying Jalapeno w/ WMF  Wikimedia Foundation
 I decided to leave some other stuff for best practices (i.e. not coding 
 style), e.g. telescoping methods and use of const for local variables.
 
 Feel free to leave comments on the talk page or add in anything I missed.
 
 -- 
 EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
 IRC: bgerstle
 ___
 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

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Monte Hurd]

Saving pages is not the primary use case for the image meta data portion - 
users tapping on an image and not having to wait for another server round trip 
to determine the high res url and meta data is the primary use case. 

Having all this data as part of one request means image taps can be much lower 
latency from the user's perspective. The panel can pop up immediately with meta 
data overlay over the already downloaded low res image and can immediately 
begin lazy loading the high res version. It will seem much more responsive, 
which is really important. 

As a side benefit, saving page data for offline access also becomes easier, but 
users tap on images (I think) more than they save pages.



 On Feb 5, 2015, at 1:40 PM, Max Semenik maxsem.w...@gmail.com wrote:
 
 Saving a page for offline is not that speed sensitive, however, serving this 
 information as part of normal page views would definitely impact overall 
 latency.
 
 On Thu, Feb 5, 2015 at 1:24 PM, Dan Garry dga...@wikimedia.org wrote:
 On 5 February 2015 at 13:20, Max Semenik maxsem.w...@gmail.com wrote:
 
 
 Wouldn't that bloat the response size?
 
 
 The rationale for including this is because that way the image viewer will 
 work even if you've not tapped on any of the images. This is pretty 
 important functionality that doesn't work offline right now, even if you 
 save the page for offline reading.
 
 That said, we may want to punt this until after the MVP as being possibly 
 outside of scope.
 
 Dan
 
 -- 
 Dan Garry
 Associate Product Manager, Mobile Apps
 Wikimedia Foundation
 
 
 
 -- 
 Best regards,
 Max Semenik ([[User:MaxSem]])
 ___
 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

Re: [WikimediaMobile] [Apps] Scope of the apps content service

[Monte Hurd]

I think it will be more than offset by the reduction in response size gained by 
the Exclude unused HTML bullet point. Also, gzip encoding is pretty good at 
text compression. 


 On Feb 5, 2015, at 1:20 PM, Max Semenik maxsem.w...@gmail.com wrote:
 
 On Thu, Feb 5, 2015 at 12:00 PM, Dan Garry dga...@wikimedia.org wrote:
 Image meta data for all images in the page
 License
 Description
 Includes the URL for the high resolution version used for the lead image
 Wouldn't that bloat the response size?
 
 -- 
 Best regards,
 Max Semenik ([[User:MaxSem]])
 ___
 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

Re: [WikimediaMobile] [Apps] Wikipedia Lite app?

[Monte Hurd]

For sure. Always fun to think about optimising :) 


 On Jan 31, 2015, at 12:26 AM, Yuri Astrakhan yastrak...@wikimedia.org wrote:
 
 I also like the idea, but I think Android is a much better initial target, as 
 it is much more common in the low bandwidth market from what I gathered.
 
 On Jan 31, 2015 8:52 AM, Brian Gerstle bgers...@wikimedia.org wrote:
 Love the idea, and I agree with everything Monte said.  We might also need 
 to drop some 3rd party libs to go super-ultra light, depending on their 
 size.  Quick inspection shows the following:
 
 AFNetworking: ~500 KB
 hpple: 41 KB
 We'll need to be careful adding too many other frameworks to the light 
 version, but we can use a separate target for it which doesn't link to 3rd 
 party code.
 
 More importantly, we'll also need to thoroughly analyze CPU usage (primarily 
 animations) and network efficiency—cache misses and extra round trips will 
 kill the experience.
 
 Excited to talk about this next quarter!
 
 Brian
 
 
 On Fri, Jan 30, 2015 at 11:45 PM, Monte Hurd mh...@wikimedia.org wrote:
 (Oh, the splash images I'm talking about on the iOS app are only shown at 
 startup and only for the brief second it takes the app to load. The reason 
 they take up so much space is older versions of iOS made you include one 
 version for your image for each screen dimension and density - that is, one 
 sized for 3.5 inch phones, one for 3.5 retina, iPad  iPad retina, iPad 
 mini  retina etc...)
 
 On Fri, Jan 30, 2015 at 11:37 PM, Monte Hurd mh...@wikimedia.org wrote:
 That sounds like it may be the way to go!
 
 For iOS:
 
 Probably no time for a lite version this quarter, but maybe the current 
 version could be made lighter?
 
 It could actually be a relatively simple thing to do. In fact, I just did 
 a quick experiment:
 
 Our current iOS app weighs in at 4.38 MB.
 
 By simply removing the splash images the app binary size drops to 2.37 MB.
 
 iOS 8 has some fancy new abilities to present non-images as splash 
 screens, so I say we do this for iOS 8, drop the splash images for older 
 devices, and pay very close attention to the change in binary size that 
 results from any external libraries we use.
 
 We can also migrate a couple more images used by the iOS app to glyphs in 
 our font - which is an easy process with the scripts I wrote a while back. 
 This will save a bit more space. We could also do a couple spikes to see 
 what other low-hanging fruit there is for trimming the binary size.
 
 I think we could get to under 2 MB without breaking a sweat, or even the 
 need for a separate version.
 
 
 
 On Fri, Jan 30, 2015 at 9:45 PM, Dan Garry dga...@wikimedia.org wrote:
 Hi everyone,
 
 Those of you who were at the Mobile quarterly review heard me mention 
 Facebook Lite, an app that's designed especially for the developing world.
 
 Notably, their app has a lot of optimisations which make it good for 
 users in developing world:
 It's only 252kB, good for limited data plans.
 It supports down to Android 2.2, good for older devices.
 It's data-efficient, good for 2G connections and for people on limited 
 data plans.
 From a development perspective, some advantages are:
 You no longer have to support older versions of Android in your main app.
 You can tailor the performance of the lite app to the older devices so 
 it's faster.
 You can tailor the features of the lite app to the developing market.
 So obviously there are a lot of advantages for our users if we do this. 
 And, selfishly, I can't stress enough how much dropping Android 2.3 from 
 our current app would speed up development. As an example, almost all of 
 the edge cases with lead images occurred on 2.3 devices, and they 
 required quite a lot of investigation and hacking to fix them up. 
 Obviously we've not dropped 2.3 so far because it's a very strategically 
 important part of our user base, which I'm sure Carolynne can attest to!
 
 I'd say that we should put some serious thought into whether we'd prefer 
 to have a Wikipedia Lite app for the developing world, rather than our 
 current one app to rule them all.
 
 Comments? Questions?
 
 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
 
 
 
 -- 
 EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle
 IRC: bgerstle
 
 ___
 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

Re: [WikimediaMobile] [Apps] Wikipedia Lite app?

[Monte Hurd]

That sounds like it may be the way to go!

For iOS:

Probably no time for a lite version this quarter, but maybe the current
version could be made lighter?

It could actually be a relatively simple thing to do. In fact, I just did a
quick experiment:

Our current iOS app weighs in at *4.38 MB*.

By simply removing the splash images the app binary size drops to *2.37 MB*.

iOS 8 has some fancy new abilities to present non-images as splash screens,
so I say we do this for iOS 8, drop the splash images for older devices,
and pay very close attention to the change in binary size that results from
any external libraries we use.

We can also migrate a couple more images used by the iOS app to glyphs in
our font - which is an easy process with the scripts I wrote a while back.
This will save a bit more space. We could also do a couple spikes to see
what other low-hanging fruit there is for trimming the binary size.

I think we could get to under 2 MB without breaking a sweat, or even the
need for a separate version.



On Fri, Jan 30, 2015 at 9:45 PM, Dan Garry dga...@wikimedia.org wrote:

 Hi everyone,

 Those of you who were at the Mobile quarterly review heard me mention
 Facebook Lite, an app that's designed especially for the developing world.

 Notably, their app has a lot of optimisations which make it good for users
 in developing world:

- It's only 252kB, good for limited data plans.
- It supports down to Android 2.2, good for older devices.
- It's data-efficient, good for 2G connections and for people on
limited data plans.

 From a development perspective, some advantages are:

- You no longer have to support older versions of Android in your main
app.
- You can tailor the performance of the lite app to the older devices
so it's faster.
- You can tailor the features of the lite app to the developing market.

 So obviously there are a lot of advantages for our users if we do this.
 And, selfishly, I can't stress enough how much dropping Android 2.3 from
 our current app would speed up development. As an example, almost all of
 the edge cases with lead images occurred on 2.3 devices, and they required
 quite a lot of investigation and hacking to fix them up. Obviously we've
 not dropped 2.3 so far because it's a very strategically important part of
 our user base, which I'm sure Carolynne can attest to!

 I'd say that we should put some serious thought into whether we'd prefer
 to have a Wikipedia Lite app for the developing world, rather than our
 current one app to rule them all.

 Comments? Questions?

 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

Re: [WikimediaMobile] Long-form editing on mobile

[Monte Hurd]

I was thinking more about people for whom a laptop / tablet in addition to 
their phone would be cost prohibitive, but a keyboard like this perhaps 
affordable, especially as a family could share to some degree. 


 On Jan 19, 2015, at 9:53 AM, Jon Robson jdlrob...@gmail.com wrote:
 
 IMO nah.
 
 This might catch on in a tablet world but I personally couldn't imagine it 
 being used in a mobile world. If I have a table or other surface to work off 
 of I might as well use a laptop. I personally have a habit of 
 forgetting/losing my headphones so having a portable keyboard is just not 
 going to happen for me.
 
 That said some people use tablets as cameras. That's not me, so maybe there 
 is a niche group of people this will appeal to but I don't expect to see this 
 taking off in SF any time soon.
 
 On 16 Jan 2015 23:26, Monte Hurd mh...@wikimedia.org wrote:
 I think we're all aware of the challenges of editing on mobile, especially 
 when it comes to long-form editing.
 
 Does the device in the following video make anyone else feel hopeful about 
 the future of long-form edits on mobile?
 
 http://youtu.be/HwGK5RvNOFI
  
 http://i.imgur.com/DWrI2JY.gif
 
 ___
 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

[WikimediaMobile] Long-form editing on mobile

[Monte Hurd]

I think we're all aware of the challenges of editing on mobile, especially when 
it comes to long-form editing.

Does the device in the following video make anyone else feel hopeful about the 
future of long-form edits on mobile?

http://youtu.be/HwGK5RvNOFI
 
http://i.imgur.com/DWrI2JY.gif___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Wikipedia Beta Android app update

[Monte Hurd]

Hey Andy,

While we await commonsdata and the ability to do an image focal area micro 
contribution, what about the following ideas:

We could top align or align nearer the top. Experimenting with this has seemed 
to produce fewer edge cases for me. (I'm implementing the same functionality in 
the iOS app.) 

We could make the image not only tap-able but also vertically drag-able so with 
a simple flick up or down any hidden bit could come into view. 

If we do the item above and detect that there is some overlap we could do a 
subtle vertical pan of the image within its crop box when an article loaded to 
give the user a hint that there's more to see. 

A variation on that could be subtle scale adjustment hinting. 

We could, if the article image dimensions are not conducive to being cropped, 
use the next image in the article which is. 

We could, instead of showing a single image in the cropped area, show a mosaic 
layout of the main image and a few others from the article scaled and sized to 
present a seamless bird's eye gallery in the crop box. 

We could do the item above only on the condition that the article image 
dimensions are ill suited to cropping. 

We could animate a horizontal slide between all of the article images, in a 
subtle, non distracting fashion, of course, within the crop box. 

We could animate a cross fade between all of the article images in the crop 
box. 

We could, if we detect an image ill suited to the crop box, slowly pan from 
center to top left, then top right, then bottom left, then bottom right, then 
back to center. 

We could start the image zoomed out such that no cropping is evident, with 
black bars in the narrower dimensions margins, the zoom in to aspect fill the 
crop box. 

Any of these are doable, quite easily, in isolation or some combined fashion. 
Do any of these sound like good ideas? 

-Monte





 On Dec 19, 2014, at 3:27 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote:
 
 On 19 December 2014 at 21:58, Dan Garry dga...@wikimedia.org wrote:
 
 I'm sorry that you feel our efforts are not good enough.
 
 I didn't express a view on our efforts (I've no doubt they're
 commendable); it's the results which are causing me concern.
 
 That said, for the reasons I mentioned, we've made a decision, both within
 the team and at the highest level of the Wikimedia Foundation, to not let
 perfect be the enemy of the good. Both with this feature, and in general.
 
 Great. Perfect should never be the enemy of the good.
 
 The problem is, the proposed change is not good; it's the opposite.
 
 We can't make software that has zero edge-cases. If we tried to do that, we'd
 never release anything.
 
 Indeed not. Perhaps you could explain the basis for implying that the
 instances I found (perhaps I was unlucky) are edge cases. Maybe
 there's some research on that you could share?
 
 Especially with only two engineers.
 
 Yes; you mentioned that before. I suspect, therefore, that there's
 some underlying yet serious issue about resourcing for your team. I'd
 be happy to support you if you make a call for extra resources to
 solve this and other issues, and to enable more or faster improvements
 in the future. But I don't see it as justification for proceeding with
 what appears to be a significant bug still in place, and one for which
 no solution appears to be in sight.
 
 -- 
 Andy Mabbett
 @pigsonthewing
 http://pigsonthewing.org.uk
 
 ___
 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

Re: [WikimediaMobile] Wikipedia Beta Android app update

[Monte Hurd]

Oh, or we could do a subtle rotational 3D transform about the x axis which 
tracked with the device rotation about the x axis, but reversed, and clipped 
to, say, +- 5 degrees. The effect would be, if you tilt the device away from 
yourself, the image would ever so subtly appear to maintain perpendicular 
orientation from your perspective. In so tilting, the top and bottom cropped 
bits would be progressively revealed/hidden. It would be another neat clue and 
super discoverable - if you move you'd notice it, and maybe want to tap it :)

I love apps. 


 On Dec 19, 2014, at 3:27 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote:
 
 On 19 December 2014 at 21:58, Dan Garry dga...@wikimedia.org wrote:
 
 I'm sorry that you feel our efforts are not good enough.
 
 I didn't express a view on our efforts (I've no doubt they're
 commendable); it's the results which are causing me concern.
 
 That said, for the reasons I mentioned, we've made a decision, both within
 the team and at the highest level of the Wikimedia Foundation, to not let
 perfect be the enemy of the good. Both with this feature, and in general.
 
 Great. Perfect should never be the enemy of the good.
 
 The problem is, the proposed change is not good; it's the opposite.
 
 We can't make software that has zero edge-cases. If we tried to do that, we'd
 never release anything.
 
 Indeed not. Perhaps you could explain the basis for implying that the
 instances I found (perhaps I was unlucky) are edge cases. Maybe
 there's some research on that you could share?
 
 Especially with only two engineers.
 
 Yes; you mentioned that before. I suspect, therefore, that there's
 some underlying yet serious issue about resourcing for your team. I'd
 be happy to support you if you make a call for extra resources to
 solve this and other issues, and to enable more or faster improvements
 in the future. But I don't see it as justification for proceeding with
 what appears to be a significant bug still in place, and one for which
 no solution appears to be in sight.
 
 -- 
 Andy Mabbett
 @pigsonthewing
 http://pigsonthewing.org.uk
 
 ___
 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

Re: [WikimediaMobile] Wikipedia Beta Android app update

[Monte Hurd]

One more - probably a bad idea, but we could disrespect the original image 
aspect ratio and do an aspect fit scale. Nothing would be cropped, but things 
could stretch/squish. 


 On Dec 19, 2014, at 3:27 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote:
 
 On 19 December 2014 at 21:58, Dan Garry dga...@wikimedia.org wrote:
 
 I'm sorry that you feel our efforts are not good enough.
 
 I didn't express a view on our efforts (I've no doubt they're
 commendable); it's the results which are causing me concern.
 
 That said, for the reasons I mentioned, we've made a decision, both within
 the team and at the highest level of the Wikimedia Foundation, to not let
 perfect be the enemy of the good. Both with this feature, and in general.
 
 Great. Perfect should never be the enemy of the good.
 
 The problem is, the proposed change is not good; it's the opposite.
 
 We can't make software that has zero edge-cases. If we tried to do that, we'd
 never release anything.
 
 Indeed not. Perhaps you could explain the basis for implying that the
 instances I found (perhaps I was unlucky) are edge cases. Maybe
 there's some research on that you could share?
 
 Especially with only two engineers.
 
 Yes; you mentioned that before. I suspect, therefore, that there's
 some underlying yet serious issue about resourcing for your team. I'd
 be happy to support you if you make a call for extra resources to
 solve this and other issues, and to enable more or faster improvements
 in the future. But I don't see it as justification for proceeding with
 what appears to be a significant bug still in place, and one for which
 no solution appears to be in sight.
 
 -- 
 Andy Mabbett
 @pigsonthewing
 http://pigsonthewing.org.uk
 
 ___
 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

[WikimediaMobile] API Nearby query coordinate bug

[Monte Hurd]

I spent a while today trying to figure out why the app's Nearby didn't seem
to be very accurately determining the angle between the device and the
article's geo coords.

Angles seemed to be off by strange amounts depending on how close I was to
an article's supposed location.

I believe I found the problem. Run the query below and you'll see the
result for Wikimedia Foundation:

https://en.m.wikipedia.org/w/api.php?action=querycolimit=1format=jsonfmgenerator=geosearchggscoord=37.786816%7C-122.399254ggslimit=1ggsradius=1pilimit=1pithumbsize=144prop=coordinates%7Cpageimages%7Cpagetermswbptterms=description

The API result says the foundation's coordinates are:
  37.787, -122.4

But if you look at the article on desktop it says the Foundation's
coordinate are:
  37.78*697*, -122.*399677*

You can see what's happening.

Can we make the API not degrade the coordinates? Super quick fix? (Or is
there some extra parameter I should be using?)
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Multimedia] CommonsMetadata API returning HTML?

[Monte Hurd]

Ya could always do a UIWebview for the descriptions but that just seems icky :)


 On Dec 8, 2014, at 6:26 PM, Dan Garry dga...@wikimedia.org wrote:
 
 On 8 December 2014 at 18:05, Monte Hurd mh...@wikimedia.org wrote:
 
 On iOS, it's worse, because we don't get any HTML parsing for free, and we 
 actually have to strip the HTML manually too
 
 Oops, Dan I may have misspoken - on iOS we can strip html w/NSXMLParser 
 which is SAX style. What we don't get for free is labels which can render 
 html links like the android ones you showed me. 
 
 Okay, thanks for clarifying! Still, we will have to omit links for 
 simplicity. :-)
 
 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

Re: [WikimediaMobile] [Multimedia] CommonsMetadata API returning HTML?

[Monte Hurd]

Bahaha!!


 On Dec 8, 2014, at 10:17 PM, Dan Garry dga...@wikimedia.org wrote:
 
 Darth WebView: Your native code is weak old man.
 Objecti-Cee Kenobi: You can't win, WebView. If you strike me down, I shall 
 become more native than you could possibly imagine.
 
 ;-)
 
 Dan
 
 On 8 December 2014 at 22:06, Monte Hurd mh...@wikimedia.org wrote:
 Ya could always do a UIWebview for the descriptions but that just seems icky 
 :)
 
 
 On Dec 8, 2014, at 6:26 PM, Dan Garry dga...@wikimedia.org wrote:
 
 On 8 December 2014 at 18:05, Monte Hurd mh...@wikimedia.org wrote:
 
 On iOS, it's worse, because we don't get any HTML parsing for free, and 
 we actually have to strip the HTML manually too
 
 Oops, Dan I may have misspoken - on iOS we can strip html w/NSXMLParser 
 which is SAX style. What we don't get for free is labels which can render 
 html links like the android ones you showed me. 
 
 Okay, thanks for clarifying! Still, we will have to omit links for 
 simplicity. :-)
 
 Dan
 
 -- 
 Dan Garry
 Associate Product Manager, Mobile Apps
 Wikimedia Foundation
 
 
 
 -- 
 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

Re: [WikimediaMobile] [Apps] Simplified search? It's possible!

[Monte Hurd]

If there are fewer than 5 prefixsearch results, show fulltext search results 
instead.

To be clear, in this case the full text results would append after the 5 prefix 
results. 



 On Dec 5, 2014, at 1:19 PM, Dan Garry dga...@wikimedia.org wrote:
 
 Hi everyone,
 
 tl;dr: The Mobile Apps Team is going to trial seamlessly surfacing full text 
 search results instead of prefixsearch results in cases where prefixsearch 
 does not give satisfactory results.
 
 The Mobile Apps Team has received a lot of feedback that our search feature 
 isn't the best. Our latest metrics confirm this; around 19% of queries give 
 the user no results. Our working hypothesis is that this is because we use 
 prefixsearch on article titles, which is very insensitive to typos and 
 free-form text.
 
 To help with this, we implemented full-text search. The user has two options 
 for searching, prefixsearch and full text. You can see this example to see 
 what these options look like.
 
 However, the way we present the two options to users is suboptimal. There's 
 no clear mental model for when one should be used compared to the other. The 
 design team recommended that we simply present whichever result set is better 
 for any given query. But how do we decide which result set is better? To 
 validate this course of action, we audited which of the two options, 
 prefixsearch or full text search, was better for a set of queries. The 
 results are here.
 
 The takehomes of our audit:
 In cases where there are very few prefixsearch results (less than around 5), 
 the full text results are just as good or better than the prefixsearch 
 results. Often, this is because the did you mean functionality of the full 
 text API helps the user out.
 In cases where there are a good number of prefixsearch results, the 
 prefixsearch results tend to be better than the fulltext results.
 Here's what we're going to try:
 Remove the buttons from the UI.
 By default, use prefixsearch for searches.
 If there are fewer than 5 prefixsearch results, show fulltext search results 
 instead.
 Metrics for success:
 Higher search clickthrough (users finding what they need more)
 Fewer number of queries give 0 results (users served more results)
 Fewer number of queries per search session (users finding what they need 
 faster)
 The advantage of this experiment is that it's safe to fail: there is no 
 actual UX change, so if we decide our solution isn't good enough, then we can 
 rollout the fallback of surfacing the buttons without users thinking we're 
 just endlessly tweaking the UI.
 
 Please do get in touch if you have any questions!
 
 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

Re: [WikimediaMobile] iOS Wikipedia app 4.0.6 going into the Apple queue

[Monte Hurd]

Oh! Nice! 


 On Dec 5, 2014, at 1:45 PM, Brion Vibber bvib...@wikimedia.org wrote:
 
 Ok, it's made its way through review and should appear in the store  updates 
 shortly.
 
 -- brion
 
 On Tue, Dec 2, 2014 at 5:07 PM, Brion Vibber bvib...@wikimedia.org wrote:
 Ok I had a slight fight with iTunes Connect where it was rejecting the 
 format of our app icon, which is now resolved. (Apparently you must now 
 submit your large app icon without an alpha channel, even if it's opaque, 
 and the SVG-PNG conversion from Inkscape creates an alpha channel by 
 default. Lol as the kids say.)
 
 It's now *really* in the queue, Waiting For Review.
 
 Now back to merging up the refactorings!
 
 -- brion
 
 On Tue, Dec 2, 2014 at 4:46 PM, Dan Garry dga...@wikimedia.org wrote:
 This is a bug fix release to fix the really bad freezing bug we've 
 encountered recently, which is why we're releasing outside of our normal 
 schedule and why the release is a bit bare, feature-wise. We're doing our 
 final testing alongside the Apple review process.
 
 Thanks Monte and Brion for your work on this!
 
 Dan
 
 On 2 December 2014 at 16:40, Brion Vibber bvib...@wikimedia.org wrote:
 Per usual caveat, expect to take a couple days at least to work its way 
 through review.
 
 
 Numerous small fixes, most notably:
 
 * fix for horrible hanging bug on certain large articles on iOS 7
 * recently-used search list
 * translation updates
 
 The fulltext search mode in the latest betas is not included as it needs 
 some performance and UI work still. Coming soon!
 
 -- brion
 
 ___
 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
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Thumbnail filename URL extraction rules

[Monte Hurd]

Max showed me how to get the file page url from the api. So if all we have
is the image name we can get the file page url automagically. I attached a
sample query to:
https://trello.com/c/cXEMxGb3/8-5-retrieve-file-metadata-from-commonsmetadata-api-and-display-it-in-the-panel

On Fri, Dec 5, 2014 at 3:52 PM, Brion Vibber bvib...@wikimedia.org wrote:

 Per request in meeting, thought I'd stick it on the public list for
 references. :)

 As I recall there should be three possible URL formats for images embedded
 in img tags in wiki pages or returned as thumbnails via the API:

 http(s)?://
 upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/(base-filename)
 ^ original-size images

 http(s)?://
 upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-(base-filename)(.render-extension)
 ?
 ^ thumbnails

 http(s)?://
 upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-thumbnail.(render-extension)
  ^ this last is used in cases where the filename is very very long and we
 can't actually prepend all the options to the filename (happens mostly in
 South Asian languages where UTF-8 is 3 bytes per letter)

 * project: 'wikipedia' in all cases we need to handle; local files on
 Wiktionary etc will have it separate but we don't use these.
 * subdomain: language 'en' etc for Wikipedias, subproject for special-case
 wikis like Commons/'commons'
 * hash1: first digit of md5 hash of the filename (you don't need to use
 this here, consider it opaque)
 * hash2: first 2 digits of md5 hash of the filename
 * base-filename: the base filename -- you want this! This is the raw
 filename for files served at original size; thumbnails will use it as a
 directory component.
 * render-extension: files other than PNG, GIF, and JPEG are rendered to
 one of those, usually PNG. So you'll see things like .svg.png at times --
 but never .png.png. These only appear on thumbnails.
 * size: thumbnails are always given with the pixel size.
 * possible-other-options: Note that other options may include a page
 number for PDF, DjVu, or TIFF files, or a time position for video
 thumbnails. To avoid parsing that stuff out, consider using the
 subdirectory base name on thumbnails if possible.

 -- brion

 ___
 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

Re: [WikimediaMobile] Thumbnail filename URL extraction rules

[Monte Hurd]

Oh, here's the query for the record:

http://en.wikipedia.org/wiki/Special:ApiSandbox#action=queryprop=imageinfoformat=jsoniiprop=urliiurlwidth=55titles=File%3AWiki.png

Should see a  descriptionurl in the results with the file page url.

On Fri, Dec 5, 2014 at 4:23 PM, Monte Hurd mh...@wikimedia.org wrote:

 Max showed me how to get the file page url from the api. So if all we have
 is the image name we can get the file page url automagically. I attached a
 sample query to:
 https://trello.com/c/cXEMxGb3/8-5-retrieve-file-metadata-from-commonsmetadata-api-and-display-it-in-the-panel

 On Fri, Dec 5, 2014 at 3:52 PM, Brion Vibber bvib...@wikimedia.org
 wrote:

 Per request in meeting, thought I'd stick it on the public list for
 references. :)

 As I recall there should be three possible URL formats for images
 embedded in img tags in wiki pages or returned as thumbnails via the API:

 http(s)?://
 upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/(base-filename)
 ^ original-size images

 http(s)?://
 upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-(base-filename)(.render-extension)
 ?
 ^ thumbnails

 http(s)?://
 upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-filename)/(size)px(possible-other-options)-thumbnail.(render-extension)
  ^ this last is used in cases where the filename is very very long and we
 can't actually prepend all the options to the filename (happens mostly in
 South Asian languages where UTF-8 is 3 bytes per letter)

 * project: 'wikipedia' in all cases we need to handle; local files on
 Wiktionary etc will have it separate but we don't use these.
 * subdomain: language 'en' etc for Wikipedias, subproject for
 special-case wikis like Commons/'commons'
 * hash1: first digit of md5 hash of the filename (you don't need to use
 this here, consider it opaque)
 * hash2: first 2 digits of md5 hash of the filename
 * base-filename: the base filename -- you want this! This is the raw
 filename for files served at original size; thumbnails will use it as a
 directory component.
 * render-extension: files other than PNG, GIF, and JPEG are rendered to
 one of those, usually PNG. So you'll see things like .svg.png at times --
 but never .png.png. These only appear on thumbnails.
 * size: thumbnails are always given with the pixel size.
 * possible-other-options: Note that other options may include a page
 number for PDF, DjVu, or TIFF files, or a time position for video
 thumbnails. To avoid parsing that stuff out, consider using the
 subdirectory base name on thumbnails if possible.

 -- brion

 ___
 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

Re: [WikimediaMobile] [Apps] How good is our search? Here's some data!

[Monte Hurd]

Since presently all app searches are prefix, I'm not too surprised by 19% - I 
seem to misspell at least that percentage typing on phone screens, and most 
misspellings result in zero prefix results. But yes, really excited about 
supplementing small/null prefix results sets with full text results as 
suggested by Jared. We'll see that 19% really drop.



 On Dec 3, 2014, at 6:27 PM, Tomasz Finc tf...@wikimedia.org wrote:
 
 On Wed, Dec 3, 2014 at 6:15 PM, Dan Garry dga...@wikimedia.org wrote:
 19% of queries giving no results seems really bad.
 
 Fixing this needs to be our priority across all projects. It doesn't
 matter what we fix later down the pipeline if this number is as high
 as it is. Let's get this as a daily/hourly number so that we can see
 live stats and then discuss changes/improvements.
 
 Great work getting these
 --tomasz
 
 ___
 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

Re: [WikimediaMobile] Did something change about prefix search today?

[Monte Hurd]

I spoke with Chad about it and he's confirmed the issue and is going to
discuss with Nick and get back to me.


On Wed, Nov 19, 2014 at 2:07 PM, Tomasz Finc tf...@wikimedia.org wrote:

 I'd check with Chad and Nick handling todays CirrusSearch deployment.

 --tomasz

 On Wed, Nov 19, 2014 at 1:55 PM, Monte Hurd mh...@wikimedia.org wrote:
  Here's what searching for fish returned yesterday:
 
 
 
 
 
 
  And here's what I get today:
 
 
 
 
  ___
  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

Re: [WikimediaMobile] Did something change about prefix search today?

[Monte Hurd]

Not yet. Will file one once I have a bit more info about what the issue is.

On Wed, Nov 19, 2014 at 2:33 PM, Tomasz Finc tf...@wikimedia.org wrote:

 Do we have a bug to track whatever the issue might be ?

 On Wed, Nov 19, 2014 at 2:30 PM, Monte Hurd mh...@wikimedia.org wrote:
  I spoke with Chad about it and he's confirmed the issue and is going to
  discuss with Nick and get back to me.
 
 
  On Wed, Nov 19, 2014 at 2:07 PM, Tomasz Finc tf...@wikimedia.org
 wrote:
 
  I'd check with Chad and Nick handling todays CirrusSearch deployment.
 
  --tomasz
 
  On Wed, Nov 19, 2014 at 1:55 PM, Monte Hurd mh...@wikimedia.org
 wrote:
   Here's what searching for fish returned yesterday:
  
  
  
  
  
  
   And here's what I get today:
  
  
  
  
   ___
   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

Re: [WikimediaMobile] Did something change about prefix search today?

[Monte Hurd]

Confirmed with Chad that it's related to the Cirrus Search update that just
went live. I asked him if he wanted me to open and bug and he said he will
- he's still investigating.

On Wed, Nov 19, 2014 at 2:52 PM, Bernd Sitzmann bsitzm...@wikimedia.org
wrote:

 Monte, The screenshots show title search (prefixsearch). I'm suprised that
 prefixsearch would be affected by any full text search (
 CirrusSearch/ElasticSearch) changes. I thought those would be independent
 systems.

 -Bernd

 On Wed, Nov 19, 2014 at 3:39 PM, Monte Hurd mh...@wikimedia.org wrote:

 Not yet. Will file one once I have a bit more info about what the issue
 is.

 On Wed, Nov 19, 2014 at 2:33 PM, Tomasz Finc tf...@wikimedia.org wrote:

 Do we have a bug to track whatever the issue might be ?

 On Wed, Nov 19, 2014 at 2:30 PM, Monte Hurd mh...@wikimedia.org wrote:
  I spoke with Chad about it and he's confirmed the issue and is going to
  discuss with Nick and get back to me.
 
 
  On Wed, Nov 19, 2014 at 2:07 PM, Tomasz Finc tf...@wikimedia.org
 wrote:
 
  I'd check with Chad and Nick handling todays CirrusSearch deployment.
 
  --tomasz
 
  On Wed, Nov 19, 2014 at 1:55 PM, Monte Hurd mh...@wikimedia.org
 wrote:
   Here's what searching for fish returned yesterday:
  
  
  
  
  
  
   And here's what I get today:
  
  
  
  
   ___
   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

Re: [WikimediaMobile] availability of apps beta installation instructions

[Monte Hurd]

The signup link for the iOS app:

http://flig.ht/1dhqz8j




 On Nov 15, 2014, at 11:15 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il 
 wrote:
 
 Hi,
 
 I am testing the beta apps for both Android and iOS. If I recall correctly, I 
 got the installation instruction for them by email. I wanted to suggest 
 testing them to somebody, but I couldn't find convenient instructions for 
 doing this.
 
 I'd expect to find them somewhere on 
 https://www.mediawiki.org/wiki/Wikimedia_Apps or on 
 https://www.mediawiki.org/wiki/Mobile , or by searching ios app beta on 
 mediawiki.org, but I couldn't find anything.
 
 Can these be posted in some convenient place at mediawiki.org, please?
 
 Thanks!
 
 --
 Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
 http://aharoni.wordpress.com
 ‪“We're living in pieces,
 I want to live in peace.” – T. Moore‬
 ___
 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

Re: [WikimediaMobile] availability of apps beta installation instructions

[Monte Hurd]

Thanks Dmitry! (I couldn't get my WMF credentials to authenticate when I tried 
to edit it...)


 On Nov 15, 2014, at 11:43 AM, Dmitry Brant dbr...@wikimedia.org wrote:
 
 Done!
 https://www.mediawiki.org/wiki/Wikimedia_Apps
 
 
 
 
 On Sat, Nov 15, 2014 at 2:24 PM, Monte Hurd mh...@wikimedia.org wrote:
 The signup link for the iOS app:
 
 http://flig.ht/1dhqz8j
 
 
 
 
 On Nov 15, 2014, at 11:15 AM, Amir E. Aharoni 
 amir.ahar...@mail.huji.ac.il wrote:
 
 Hi,
 
 I am testing the beta apps for both Android and iOS. If I recall correctly, 
 I got the installation instruction for them by email. I wanted to suggest 
 testing them to somebody, but I couldn't find convenient instructions for 
 doing this.
 
 I'd expect to find them somewhere on 
 https://www.mediawiki.org/wiki/Wikimedia_Apps or on 
 https://www.mediawiki.org/wiki/Mobile , or by searching ios app beta on 
 mediawiki.org, but I couldn't find anything.
 
 Can these be posted in some convenient place at mediawiki.org, please?
 
 Thanks!
 
 --
 Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
 http://aharoni.wordpress.com
 ‪“We're living in pieces,
 I want to live in peace.” – T. Moore‬
 ___
 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

Re: [WikimediaMobile] availability of apps beta installation instructions

[Monte Hurd]

Ah! Yes! I left off the t :)


 On Nov 15, 2014, at 11:54 AM, Amir E. Aharoni amir.ahar...@mail.huji.ac.il 
 wrote:
 
 Monte - You probably meant http://tflig.ht/1dhqz8j :)
 
 Dmitry - Thanks a lot for adding the instructions!
 
 
 --
 Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
 http://aharoni.wordpress.com
 ‪“We're living in pieces,
 I want to live in peace.” – T. Moore‬
 
 2014-11-15 21:24 GMT+02:00 Monte Hurd mh...@wikimedia.org:
 The signup link for the iOS app:
 
 http://flig.ht/1dhqz8j
 
 
 
 
 On Nov 15, 2014, at 11:15 AM, Amir E. Aharoni 
 amir.ahar...@mail.huji.ac.il wrote:
 
 Hi,
 
 I am testing the beta apps for both Android and iOS. If I recall correctly, 
 I got the installation instruction for them by email. I wanted to suggest 
 testing them to somebody, but I couldn't find convenient instructions for 
 doing this.
 
 I'd expect to find them somewhere on 
 https://www.mediawiki.org/wiki/Wikimedia_Apps or on 
 https://www.mediawiki.org/wiki/Mobile , or by searching ios app beta on 
 mediawiki.org, but I couldn't find anything.
 
 Can these be posted in some convenient place at mediawiki.org, please?
 
 Thanks!
 
 --
 Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
 http://aharoni.wordpress.com
 ‪“We're living in pieces,
 I want to live in peace.” – T. Moore‬
 ___
 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

Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS

[Monte Hurd]

Being able to use Swift will be a huge benefit!

It lowers the bar for volunteer contribution - Obj-C is pretty tough to
wrap your mind around as a beginner. Obj-C code also ends up being *much*
more bloated than Swift code, making it even harder for volunteer
contributors to grok our Obj-C code base.

Being much more concise and generally less clunky than Obj-C is great, but
Swift also has baked-in protection against entire classes of errors common
to Obj-C, and TONS of time saving and powerful modern language features.

So, yes, Swift a.s.a.p. please!

On Thu, Nov 13, 2014 at 3:21 AM, Joaquin Oltra Hernandez 
jhernan...@wikimedia.org wrote:

 Swift is a very interesting language, should be exciting!

 On Thu, Nov 13, 2014 at 7:05 AM, Dan Garry dga...@wikimedia.org wrote:

 *tl;dr: The programming language used to develop new features by our iOS
 app engineering team is changing from Objective C to Swift at some point in
 the near future.*

 When making a native app, the language you have to implement the app in
 is chosen by the third party responsible for the platform. For iOS apps,
 Apple chose Objective C to be the language the app is written in. Objective
 C is a... very strange language. It has a lot of quirks that slow down
 development.

 To solve the above problem, you can now write apps in a new language
 called Swift. Notably, Swift has features that make it less error prone and
 more concise than Objective C, which should increase our velocity of
 feature development. Swift is also much more readable and in-line with
 other languages, which lowers the barrier of entry (which is currently very
 high with Objective C).

 Importantly, Objective C and Swift can live alongside each other. So,
 when we switch to Swift we do not need to rewrite all of our existing
 code from Objective C to Swift. Instead, we can just start developing new
 features using Swift, and slowly rewrite the old code from Objective C into
 Swift as time allows.

 On the downsides, Swift is only supported on iOS 7 and above. iOS 6 only
 represents around 5% of our user base, and we can pin iOS 6 users to the
 last version of the app we released before we used Swift. We need to decide
 what the last set of features we're want in that build are before we switch.

 Here are our next steps:

- Evaluate more concretely whether Swift actually fits our needs or
not. [Engineering]
- Decide last set of features for our iOS 6 build. [Product/Design]

 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


___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Using Swift for new feature development on iOS

[Monte Hurd]

With Tomasz I added a new Swift spike to the iOS board:
https://trello.com/c/3jKbmL0z/22-spike-2-hour-convert-at-least-5-single-method-categories-to-swift

Basically it's a dry run to convert some of the most simple code in the app
codebase to Swift to see what issues we encounter and give us a rough
baseline for how quickly existing code can be converted.

The spike should not be considered to signify the moment we officially fork
the code (with the pre-Swift base being maintained only for iOS 6 bug
fixes). Timing for this forking should be informed by what we learn during
the spike and Dan will make the call as to when we fork.

When we do fork and enable Swift for ongoing development, I do not think we
should necessarily immediately switch all development to Swift. My
preference would be to switch completely to Swift over the course of a few
months as we gain experience and mastery of it. We may find this doesn't
actually take months, and I suspect it won't, but I would prefer to ease
into it.

Does this sound ok?



On Thu, Nov 13, 2014 at 1:45 PM, Dan Garry dga...@wikimedia.org wrote:

 The product expectations here are:

- After the transition, no new features will be backported to
Objective C to be used on iOS 6. All new features will be developed in
Swift. The exact feature cut-off is to be defined by product and design
(setting up a meeting about this tomorrow).
- Crash fixes and major bug fixes will continue to be handled on the
iOS 6 version for the mid future (e.g. next few months).
- Code will be refactored from Objective C to Swift as time allows,
e.g. possibly as an onboarding task for new engineers. There will be no
planned effort in the short- or mid-term (e.g. next few months) to refactor
old code from Objective C to Swift, although this is the plan in the long
term.

 Let me know if you need more, or need any clarification.

 Dan

 On 13 November 2014 13:35, Tomasz Finc tf...@wikimedia.org wrote:

 Thanks for kicking this off Dan. I've been following Swifts
 development from the sidelines and I'm eager to put it through its
 paces. Given that modern iOS releases can support hybrid Swift and iOS
 apps, the risk of experimenting is low and potential pay off is high.

 Addressing some of the questions I've gotten.

 = Existing Engineers =

 I expect all of our engineers to be well rounded and exposed to
 multiple languages. This means picking up new languages as necessary
 for their job and anticipating future platform changes that require
 new expertise. Swift is just another one of these.

 While jumping between some languages can be a huge leap, Swift is not.
 The language [1], migration [2], and iOS/OSX integration are well
 documented giving me confidence that we have the resources to move
 forward giving our current resourcing.

 = Team Growth =

 I expect no significant change to recruitment in the short term 6month
 - 1year. I expect a significant difference in the 1yr - 2yr range as
 more people come up to speed and have built real world applications
 with it. Thus I anticipate and huge help in hiring in the future with
 this change.

 I do expect more volunteers experimenting with our code base if its
 swift based and I know that we have internal non app staff who are
 curious to join these efforts. I can easily see a 1day hackathon
 centered on helping us get to swift pulling in various resources.

 Next step will be to define a spike to assess a migration. [3]

 Dan, i'll need you to define what this migration means to product if
 we decide to go forward. Product needs to define what features will be
 frozen, what if anything need to be backported, and which iO6 bugs we
 will respond to.

 --tomasz

 [1] -
 https://developer.apple.com/library/ios/documentation/swift/conceptual/Swift_Programming_Language/TheBasics.html
 [2] -
 https://developer.apple.com/library/ios/documentation/swift/conceptual/buildingcocoaapps/Migration.html
 [3] -
 https://trello.com/c/dgYqIuId/21-spike-hr-determine-whether-we-re-ready-to-migrate-to-swift

 On Wed, Nov 12, 2014 at 10:05 PM, Dan Garry dga...@wikimedia.org wrote:
  tl;dr: The programming language used to develop new features by our iOS
 app
  engineering team is changing from Objective C to Swift at some point in
 the
  near future.
 
  When making a native app, the language you have to implement the app in
 is
  chosen by the third party responsible for the platform. For iOS apps,
 Apple
  chose Objective C to be the language the app is written in. Objective C
 is
  a... very strange language. It has a lot of quirks that slow down
  development.
 
  To solve the above problem, you can now write apps in a new language
 called
  Swift. Notably, Swift has features that make it less error prone and
 more
  concise than Objective C, which should increase our velocity of feature
  development. Swift is also much more readable and in-line with other
  languages, which lowers the barrier of entry (which is 

Re: [WikimediaMobile] Collapsing sections in app

[Monte Hurd]

Hi Pine,

Thanks for the feedback on the collapsed vs expanded section navigation
issue! :)

Here's some background about why we went with expanded sections for the
apps:

Somewhat counterintuitively, it was largely because of the example you
gave: really large articles.

This may seem odd. How could keeping the sections expanded make navigating
large articles easier*?

It turns out, with collapsed sections navigation, if you are reading a long
section, you have to scroll repeatedly if you are partway through reading
that section and decide it does not contain what you are looking for, or
you want to read another section. The number of these useless extra
scrolls depends on how long the section is, how far you've read through
it, whether the next section you wish to read is above or below the section
you were reading, and how many sections there are in the article.

So extra scrolls are no good. But if an article is read from top to
bottom, the reader is not really not doing any extra scrolls. They're
scrolling as they read and simply tapping the next collapsed section title
to read it.

So what's counterintuitive about collapsed section navigation and large
articles? It's this: the longer the article is, the less likely the user is
going to read it in-order or in its entirety, and in these cases, the
number of extra scrolls increases with collapsed section navigation.

This is why we give the user single-tap access to the article table of
contents. With this approach, if they read from top to bottom, nothing has
changed from a swipe count perspective, but we save the user a tap for each
section they read. When the top navigation is scrolled off-screen, as you
had mentioned, we also give the user single-swipe access to the table of
contents. Additionally, when the table of contents appears, it gives you a
birds-eye view of the section you had been reading and also
simultaneously scrolls the zoomed out article as you scroll the table of
contents to help you quickly find other parts of the article, whether text,
images or tables, which interest you.

We do need to make it more obvious to users that a single swipe will reveal
the table of contents at any time. We have designs for a little intro for
this which is already implemented on the Android app, and will soon be on
the iOS app as well.

Additionally, not collapsing the sections opens up new article styling and
presentation possibilities which would be confusing from a UX perspective
if sections had to be manually and individually expanded or collapsed.
(in-article search for example, but there are many more, including
inconsistencies with larger screen tablet presentations)

Did this help make the decision to go with expanded sections make more
sense? Let me know, and thanks again for the feedback!

-Monte



*(For me easier came down to how many touch gestures I had to do to find
what I was looking for. So, one tap or swipe gesture was easier than 4 or
6.)

On Mon, Oct 20, 2014 at 4:22 PM, Dan Garry dga...@wikimedia.org wrote:

 On 20 October 2014 09:57, Pine W wiki.p...@gmail.com wrote:

 When I am scrolling down a page such as WP:GAB, the navbar at the top of
 the page disappears, which takes the TOC icon away with it. I was finding
 it easy to get lost in a mass of text when scrolling down the page; hence
 my request for collapsed sections. However when I scroll up the navbar
 reappears. Can you make the navbar remain visible at all times?


 Our app is a reader app like Kindle, but it's also a web browser app like
 Chrome. This navbar hiding is a common design pattern on both these kinds
 of apps, as it removes the clutter and lets the user focus on long form
 reading. Given that the ToC can be summoned by swiping left even if the nav
 bar is hidden, and that the user is informed of this in the form of an
 onboarding screen the first time they go to a page with a ToC, making the
 nav bar persistent would do nothing other than damage our long-form reading
 experience.

 * Facilitate the viewing of page history within the app


 What is the user story for this? As a reader, I want to view the page
 history, so that...?


 * Allow images to be disabled


 This is something we're talking about at the minute. There are a lot of
 people out there, particularly on the Android app but also on iOS, that are
 on connections that have highly restricted bandwidth. Giving those users a
 text only mode would be great.

 The real question is, where does the option go? It's an application-level
 setting so it should go in the More menu, but I am very *very* reluctant
 to go down the road of adding tons of preferences to the app and turning it
 into something like the preferences page we have on the desktop site.

 We're continuing to think about this.


 * Facilitate easy access to the Refdesk, Teahouse, and other help
 resources for both readers and editors


 Many of these pages (like the Reference Desk) look really bad on the
 mobile app, and others (like the 

Re: [WikimediaMobile] Collapsing sections in app

[Monte Hurd]

To clarify, the zooming behavior I described is only on the iOS version
of the app presently, but this feature could be added to the list of new
article styling and presentation possibilities which would not be possible
with collapsed section nav.

On Mon, Oct 20, 2014 at 4:37 PM, Monte Hurd mh...@wikimedia.org wrote:

 Hi Pine,

 Thanks for the feedback on the collapsed vs expanded section navigation
 issue! :)

 Here's some background about why we went with expanded sections for the
 apps:

 Somewhat counterintuitively, it was largely because of the example you
 gave: really large articles.

 This may seem odd. How could keeping the sections expanded make navigating
 large articles easier*?

 It turns out, with collapsed sections navigation, if you are reading a
 long section, you have to scroll repeatedly if you are partway through
 reading that section and decide it does not contain what you are looking
 for, or you want to read another section. The number of these useless
 extra scrolls depends on how long the section is, how far you've read
 through it, whether the next section you wish to read is above or below the
 section you were reading, and how many sections there are in the article.

 So extra scrolls are no good. But if an article is read from top to
 bottom, the reader is not really not doing any extra scrolls. They're
 scrolling as they read and simply tapping the next collapsed section title
 to read it.

 So what's counterintuitive about collapsed section navigation and large
 articles? It's this: the longer the article is, the less likely the user is
 going to read it in-order or in its entirety, and in these cases, the
 number of extra scrolls increases with collapsed section navigation.

 This is why we give the user single-tap access to the article table of
 contents. With this approach, if they read from top to bottom, nothing has
 changed from a swipe count perspective, but we save the user a tap for each
 section they read. When the top navigation is scrolled off-screen, as you
 had mentioned, we also give the user single-swipe access to the table of
 contents. Additionally, when the table of contents appears, it gives you a
 birds-eye view of the section you had been reading and also
 simultaneously scrolls the zoomed out article as you scroll the table of
 contents to help you quickly find other parts of the article, whether text,
 images or tables, which interest you.

 We do need to make it more obvious to users that a single swipe will
 reveal the table of contents at any time. We have designs for a little
 intro for this which is already implemented on the Android app, and will
 soon be on the iOS app as well.

 Additionally, not collapsing the sections opens up new article styling and
 presentation possibilities which would be confusing from a UX perspective
 if sections had to be manually and individually expanded or collapsed.
 (in-article search for example, but there are many more, including
 inconsistencies with larger screen tablet presentations)

 Did this help make the decision to go with expanded sections make more
 sense? Let me know, and thanks again for the feedback!

 -Monte



 *(For me easier came down to how many touch gestures I had to do to find
 what I was looking for. So, one tap or swipe gesture was easier than 4 or
 6.)

 On Mon, Oct 20, 2014 at 4:22 PM, Dan Garry dga...@wikimedia.org wrote:

 On 20 October 2014 09:57, Pine W wiki.p...@gmail.com wrote:

 When I am scrolling down a page such as WP:GAB, the navbar at the top of
 the page disappears, which takes the TOC icon away with it. I was finding
 it easy to get lost in a mass of text when scrolling down the page; hence
 my request for collapsed sections. However when I scroll up the navbar
 reappears. Can you make the navbar remain visible at all times?


 Our app is a reader app like Kindle, but it's also a web browser app like
 Chrome. This navbar hiding is a common design pattern on both these kinds
 of apps, as it removes the clutter and lets the user focus on long form
 reading. Given that the ToC can be summoned by swiping left even if the nav
 bar is hidden, and that the user is informed of this in the form of an
 onboarding screen the first time they go to a page with a ToC, making the
 nav bar persistent would do nothing other than damage our long-form reading
 experience.

 * Facilitate the viewing of page history within the app


 What is the user story for this? As a reader, I want to view the page
 history, so that...?


 * Allow images to be disabled


 This is something we're talking about at the minute. There are a lot of
 people out there, particularly on the Android app but also on iOS, that are
 on connections that have highly restricted bandwidth. Giving those users a
 text only mode would be great.

 The real question is, where does the option go? It's an application-level
 setting so it should go in the More menu, but I am very *very* reluctant
 to go down the road of adding

Re: [WikimediaMobile] [Apps] Release candidates!

[Monte Hurd]

Build was cut for iOS.

Signup link for Wikipedia iOS app Testflight betas here:
http://tflig.ht/1dhqz8j

On Tue, Oct 7, 2014 at 4:18 PM, Dan Garry dga...@wikimedia.org wrote:

 Hi everyone,

 As mentioned at the standup yesterday, let's get our next release
 candidates for the apps in order!

 On iOS, this release candidate should include:

- UI scaling for larger devices
- Fix for the web view loading half way down the screen on slow
connections
- Page load indicator

 On Android, this release candidate should include:

- Page issues and disambiguation rolled up into a button under the
page title
- Onboarding for the table of contents
- Nearby, a feature that lets you see articles about things you're near

 Let's aim to get these release candidates in the appropriate channels
 (TestFlight for iOS, Wikipedia Beta for Android) by end of day tomorrow
 (Wednesday), so that we can get them submitted for release at the start of
 next week.

 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

Re: [WikimediaMobile] [Apps] Refactoring work on iOS

[Monte Hurd]

Makes sense. 


 On Sep 25, 2014, at 12:20 PM, Yuvi Panda yuvipa...@gmail.com wrote:
 
 On Thu, Sep 25, 2014 at 8:18 PM, Dan Garry dga...@wikimedia.org wrote:
 I chatted with Monte and he said that Core Data is still being used, but to
 more a limited extent. So it's a nice to have rather than a must have
 for the candidates.
 
 He also suggested another nice to have would be experience with the
 AFNetworking library, as we're migrating our network operations to using
 that instead of using totally custom-made network operations.
 
 IMO, looking for very specific library/framework experience is
 suboptimal at best, and should be avoided.
 
 
 -- 
 Yuvi Panda T
 http://yuvi.in/blog
 
 ___
 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

[WikimediaMobile] Wikipedia App (iOS) beta tester numbers and feedback

[Monte Hurd]

In the last 2 days we went from 110 signups to 336!

Of these, 143 people have actually installed the latest beta, up from a
previous high of 20.

I've also received multiple feedback emails through the testflight system.

Dan, I've added you as a leader in testflight so hopefully these feedback
emails will go to you as well. Is this ok?



Other thoughts on where to forward feedback email? In the mean time, here's
the feedback from yesterday:


-


I went to Article History and tried to click on an article Editor's name to
see articles they have also edited, and this functionality is not yet there.

I have no understandable way to Mark an article for watching (for web WP
usage) - will this be implemented?

I also do not see articles i am already watching from The web WP

Are These saved for offline use articles somehow saved to web WP?

I think the top-right article summary button could show The amount of
languages The article is available in and allow to choose when 26 other
languages is tapped, f.ex.

Editing a segment of an article could allow for a toolbar above The editor,
having The usual set of functionality or a subset of them (link with text,
bold, list, reference generation)

Tapping on this:
↑ a b Yle, uutiset viitat
(Am referring to a and b) should modify Back-button functionality so that
can get back to references by tapping on Back.
Also, i am seeing hugely garbled text pasted now, see attached screenshot

I.e. Would be nice to get a non-formatted copy-to-clipboard out of WP

Share button on lower-right could have AirPrint? Hmm.

I will attach two crashlogs that occurred while searching for a WP article
in the next Mail.

Sent from some iDevice. Written by Esa.





Great update,

Can i translate the app into arabic language ?

Feras Younis Qrinawi





Hey I have the TestFlight iOS 8 app how could I transfer the Wikipedia App
inside the TestFlight App?





Just from using this to view 2 articles, Infobox placement is a bit
problematic. On an iPod 5, the page Carboxynorspermidine decarboxylase is
split up by the Infobox; half the equation seems to be on either side of it.


(Note: ^ this last one is from the previous beta)
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Wikipedia App (iOS) beta tester numbers and feedback

[Monte Hurd]

Thanks Amir! I will forward the info!

On Wed, Sep 17, 2014 at 10:30 AM, Amir E. Aharoni 
amir.ahar...@mail.huji.ac.il wrote:

  Great update,
  Can i translate the app into arabic language ?
  Feras Younis Qrinawi

 He-he, a couple of years ago I was the crazy guy who read much of the
 copious feedback about the old apps. I received several questions like this
 one, and I used it as an opportunity to acquire several new translatewiki
 translators, and it actually worked in a few cases.

 If it's possible to reply, the link for translation is this:

 https://translatewiki.net/wiki/Special:Translate?filter=action=translategroup=out-wikimedia-mobile-wikipedia-ios-0-alllanguage=ar

 (For other languages just change the language code in the end, but first
 make sure that iOS actually supports this language.)

 A translatewiki.net account must be create through the
 https://translatewiki.net/ main page first. I am available for more
 assistance.

 And of course the About page in the iOS app should have a link to
 translatewiki, like the Android app [
 https://bugzilla.wikimedia.org/show_bug.cgi?id=70946 ].


 --
 Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
 http://aharoni.wordpress.com
 ‪“We're living in pieces,
 I want to live in peace.” – T. Moore‬

 2014-09-17 20:07 GMT+03:00 Monte Hurd mh...@wikimedia.org:

 In the last 2 days we went from 110 signups to 336!

 Of these, 143 people have actually installed the latest beta, up from a
 previous high of 20.

 I've also received multiple feedback emails through the testflight system.

 Dan, I've added you as a leader in testflight so hopefully these
 feedback emails will go to you as well. Is this ok?



 Other thoughts on where to forward feedback email? In the mean time,
 here's the feedback from yesterday:


 -


 I went to Article History and tried to click on an article Editor's name
 to see articles they have also edited, and this functionality is not yet
 there.

 I have no understandable way to Mark an article for watching (for web WP
 usage) - will this be implemented?

 I also do not see articles i am already watching from The web WP

 Are These saved for offline use articles somehow saved to web WP?

 I think the top-right article summary button could show The amount of
 languages The article is available in and allow to choose when 26 other
 languages is tapped, f.ex.

 Editing a segment of an article could allow for a toolbar above The
 editor, having The usual set of functionality or a subset of them (link
 with text, bold, list, reference generation)

 Tapping on this:
 ↑ a b Yle, uutiset viitat
 (Am referring to a and b) should modify Back-button functionality so that
 can get back to references by tapping on Back.
 Also, i am seeing hugely garbled text pasted now, see attached screenshot

 I.e. Would be nice to get a non-formatted copy-to-clipboard out of WP

 Share button on lower-right could have AirPrint? Hmm.

 I will attach two crashlogs that occurred while searching for a WP
 article in the next Mail.

 Sent from some iDevice. Written by Esa.


 


 Great update,

 Can i translate the app into arabic language ?

 Feras Younis Qrinawi


 


 Hey I have the TestFlight iOS 8 app how could I transfer the Wikipedia
 App inside the TestFlight App?


 


 Just from using this to view 2 articles, Infobox placement is a bit
 problematic. On an iPod 5, the page Carboxynorspermidine decarboxylase is
 split up by the Infobox; half the equation seems to be on either side of it.


 (Note: ^ this last one is from the previous beta)




 ___
 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

[WikimediaMobile] iOS app feedback (via testflight)

[Monte Hurd]

We received the following feedback email through testflight:


Hi, I already tested your latest updates in Wikipedia 4.0.2, and I want to
give you some feedbacks :

1.) If I want to see my previous article or my next article, I don't need
to press the back () button or forward () button. Instead, I can swipe my
finger from the left or right side of the display. (For example, the
navigation gesture in Safari)

2.) When I want to delete my saved page, the animation is a bit late.

3.) The Random button in the sidebar. Actually, I don't understand why it
was made. Because, someone who opens Wikipedia, must be know what he/she
looking for. So, I want to suggest to delete the Random button (*if you
don't mind)

That's all I want to say. And I hope to see another beta updates. Thank you.
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] iOS 8 testing notes

[Monte Hurd]

Brion fixed the first issue. 

 On Sep 9, 2014, at 2:26 PM, Dan Garry dga...@wikimedia.org wrote:
 
 Hi everyone,
 
 The iOS 8 testing notes are available here: 
 http://etherpad.wikimedia.org/p/WikipediaiOSTesting (mw.o page dump).
 
 Note that as we didn't have enough test devices this ended up being more 
 general, but there were a few issues with the iOS 8 build in particular that 
 were identified:
 Today doesn't work properly. If you try to scroll after tapping Today, the 
 web view shoots down then gets stuck. (iPhone 5S, iOS 8 build 4.0.2 - 5th 
 September 2014)
 In some (unknown) cases, summoning the ToC can cause the webview to resize as 
 expected, but the ToC to never appear and the ToC button to stop working. The 
 only workaround is to manually close the app. (iPhone 4, iOS 7, build 4.0.2.1 
 - 6th September 2014)
 A few esoteric crashes relating to search (e.g. 'click lots of bluelinks' or 
 'click lots of search results') that I've so far been unable to reproduce.
 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

Re: [WikimediaMobile] SVG to font (WAS: The future of skins_

[Monte Hurd]

 On Sep 3, 2014, at 8:46 PM, Trevor Parscal tpars...@wikimedia.org wrote:
 
 The font-to-SVG workflow was an idea to try and make it possible for 
 designers to use their font is the source workflow.


Not quite. The point of the conversion scripts (which are done and seem to work 
pretty well) is to make it possible for designers (and me) to use a svg is the 
source workflow and pipe these svgs through the scripts if we happen to need a 
font representation. 
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] SVG to font (WAS: The future of skins_

[Monte Hurd]

 On Sep 3, 2014, at 6:43 PM, Matthew Flaschen mflasc...@wikimedia.org wrote:
 
 WikiFont (which generates font file output from SVG source code).


tl:dr SVGs yay!

The problem was WikiFont did not generate itself (magic?) from svgs. The svgs 
had to be fairly painstakingly imported into a font forge project which was 
then used to generate the font.

The font forge importation workflow was sticky enough (importing svgs and 
mapping them, etc) that small visual tweaks (baseline offsets and such) ended 
up being made in the font forge project itself as well, thus diverging from the 
source svgs. 

I think this workflow stickiness was what led the designer to see the font 
forge project as canonical. 

So... the 2 scripts I wrote. 

One automates creating a font from a folder of svgs. Svgs are canonical as they 
should be, but hey, you want a font? You got it.

The second script, just for fun, reverses the process and creates a folder of 
svgs from the font.

I've been dogfooding these for the last week for a supplemental font the iOS 
app uses. 

I'll post them hopefully next week when I get a chance to document them. If you 
can't wait and are in the SF office stop by my desk and I can demo it in about 
2 minutes. 
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Wikitech-l] The future of skins

[Monte Hurd]

I've finished the SVGs-to-font and font-to-SVGs scripts. I'll document and
post these in the next couple days.


On Wed, Aug 27, 2014 at 2:26 PM, Trevor Parscal tpars...@wikimedia.org
wrote:

 Someone in the meeting also claimed that Swig and Twig were compatible,
 and that does appear to be generally true, but I think there are some
 deviations.

 - Trevor


 On Wed, Aug 27, 2014 at 1:39 PM, Juliusz Gonera jgon...@wikimedia.org
 wrote:

 Someone in one of our meetings mentioned that Twig is a PHP
 implementation of Mustache. This doesn't seem to be the case though.
 We need a templating solution that works both on the server and the
 client.

 On Tue, Aug 26, 2014 at 5:21 PM, Trevor Parscal tpars...@wikimedia.org
 wrote:
  Thanks for summarizing the meeting Jon.
 
  So, let's get Twig/Swig into core then, eh? :)
 
  - Trevor
 
 
  On Tue, Aug 26, 2014 at 3:53 PM, Jon Robson jrob...@wikimedia.org
 wrote:
 
  Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
  talked about the future of skins. Hopefully this mail summarises what
  we talked about and what we agreed on. Feel free to add anything, or
  ask any questions in the likely event that I've misinterpreted
  something we talked about or this is unclear :)
 
  Specifically we talked about how we are unhappy with how difficult it
  currently is for developers to create a skin. The skin class involves
  too many functions and does more than a skin should do e.g. manage
  classes on the body, worry about script tags and style tags.
 
  Trevor is going to create a base set of widgets, for example a list
  generator to generate things like a list of links to user tools. The
  widgets will be agnostic to how they are rendered - some may use
  templates, some may not.
 
  We identified the new skin system will have two long term goals:
  1) We would like to get to the point where a new skin can be built by
  simply copying and pasting a master template and writing a new css
  file.
  2) Should be possible for us in future to re-render an entire page via
  JavaScript and using the modern history push state re-render any page
  via the API. (Whether we'd want to do this is another consideration
  but we would like to have an architecture that is powerful enough to
  support such a thing)
 
  As next steps we agreed to do the following:
 
  1) Trevor is going to build a watch star widget on client and server.
  We identified that the existing watch star code is poorly written and
  has resulted in MobileFrontend rewriting it. We decided to target this
  as it is a simple enough example that it doesn't need a template. It's
  small and contained enough that we hope this will allow us to share
  ideas and codify a lot of those. Trevor is hoping to begin working on
  this the week of the 2nd September.
 
  2) We need a templating system in core. Trevor is going to do some
  research on server side templating systems. We hope that the
  templating RFC [1] can get resolved however we are getting to a point
  that we need one as soon as possible and do not want to be blocked by
  the outcome of this RFC, especially given a mustache based templating
  language can address all our current requirements.
 
  [1]
 
 https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
 
  ___
  Wikitech-l mailing list
  wikitec...@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-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

Re: [WikimediaMobile] Reviews on iOS

[Monte Hurd]

After the next update perhaps :) 

 On Aug 25, 2014, at 10:47 AM, Moiz Syed ms...@wikimedia.org wrote:
 
 This is a good app to keep tabs on app reviews on iOS.
 
 http://reviewsapp.io/
 ___
 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

Re: [WikimediaMobile] When is mobile search index updated?

[Monte Hurd]

I suspected it may just take time for caches to update...


On Mon, Aug 25, 2014 at 11:01 AM, Yuvi Panda yuvipa...@gmail.com wrote:

 It should be faster soon, with CirrusSearch just around the corner!

 On Mon, Aug 25, 2014 at 6:59 PM, Jon Robson jdlrob...@gmail.com wrote:
  [[2014 Napa earthquake]] was created at 23:44 yesterday (PST)
  It is now showing up when I search.
  So I guess if there is some kind of cache it's around 11ish hours :)
 
 
  On Mon, Aug 25, 2014 at 10:33 AM, Dan Garry dga...@wikimedia.org
 wrote:
  On 25 August 2014 10:24, Jon Robson jdlrob...@gmail.com wrote:
 
  The search is a limited prefix search. The title thus has to be exact
  and the title of this page is 2014 South Napa earthquake (so
  omitting the word south is what's giving you no results.
 
 
  True. However, [[2014 Napa earthquake]] does exist as a redirect to
 [[2014
  South Napa earthquake]], so it should show up in search results even if
  they're done with strict prefix searching.
 
  Interestingly, this problem does not appear to be present on Android.
 Not
  only is [[2014 Napa earthquake]] showing up in search results, but
 yesterday
  when I created [[Page with four sections]] on testwiki it showed up
  instantaneously in the search results. That said, a quick test on iOS
 shows
  [[2014 Napa earthquake]] showing up in my search results... so I'm at a
  loss.
 
  Dan
 
  --
  Dan Garry
  Associate Product Manager, Mobile Apps
  Wikimedia Foundation
 
 
 
  --
  Jon Robson
  * http://jonrobson.me.uk
  * https://www.facebook.com/jonrobson
  * @rakugojon
 
  ___
  Mobile-l mailing list
  Mobile-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/mobile-l



 --
 Yuvi Panda T
 http://yuvi.in/blog

 ___
 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

Re: [WikimediaMobile] [Apps] UX review from Google's Android team

[Monte Hurd]

Yes! :)


 On Aug 25, 2014, at 1:59 PM, Tomasz Finc tf...@wikimedia.org wrote:
 
 I'm eager to put our app to this test and use the feedback to help our
 app become one of the best examples of open source android
 development.
 
 Given our reach, openness, and content I truly believe we can be one of the
 flagship apps within both the iOS and Android apps stores.
 
 Now lets make it happen.
 
 --tomasz
 
 On Fri, Aug 22, 2014 at 4:22 PM, Bernd Sitzmann bsitzm...@wikimedia.org 
 wrote:
 We should definitely do this. I'm very excited about all three initiatives
 you sent out.
 I think the UX review should be the first one. Then once we've addressed
 some of the bigger issues from the UX review we should proceed with the
 other two.
 
 Thank you,
 Bernd
 
 
 On Fri, Aug 22, 2014 at 4:46 PM, Dan Garry dga...@wikimedia.org wrote:
 
 Hi everyone,
 
 On Wednesday, Katherine, Tomasz and I met with Joe Castorena from Google’s
 Android Play Partnerships team. I’ve split up the most relevant information
 into a few separate emails, to keep the discussion on each separate point
 focussed.
 
 Joe mentioned something that Google offers its partners, called a UX
 review. He said that he could get the build passed to the Android
 engineering team at Google, and in short they’d critique every aspect of the
 user experience. The result would be a long document (on the order of 20
 pages) where the Android team at Google would make recommendations about how
 we could improve the UX of the app. He said that this process is entirely
 voluntary, so we could take or leave the feedback as we see fit. He did
 suggest, however, that doing something like this is going to massively
 increase the way that we’re perceived by Google, and would increase the
 possibility of getting featured as a “Best App 2014” or “Best Designed App”.
 Basically, we’d be seen as a shining example of what Android could do.
 
 Given that we can take and leave the feedback as we see fit, I think we
 should definitely do this. Once we have the feedback, we can figure out
 where the individual items of feedback sit in our priorities. I'm really
 excited to get some feedback from the people who literally wrote the book on
 Android design.
 
 Thoughts?
 
 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
 
 ___
 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

[WikimediaMobile] iOS Wikipedia app beta 4.01 beta 10

[Monte Hurd]

Today's beta includes the following newness:

- Fix for table of contents sometimes causing the article to jump around
erratically when selecting a section near the bottom of an article. This
fix incidentally made the TOC animation much more smooth :)

- Networking crash fix.

- More responsive article touch event handling.

- Fix for reference panel sometimes flickering to blank.

- Better table of contents swipe gesture responsiveness.

- Slight increase in size of Nearby item distance label for better
readability.



If you haven't already signed up to the beta program you can do so here:

http://tflig.ht/1dhqz8j

Feel free to share this link too!
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] [Apps] Featuring the app in Google Play

[Monte Hurd]

That's so great! :) 

 On Aug 22, 2014, at 3:44 PM, Dan Garry dga...@wikimedia.org wrote:
 
 Hi everyone,
 
 On Wednesday, Katherine, Tomasz and I met with Joe Castorena from Google’s 
 Android Play Partnerships team. I’ve split up the most relevant information 
 into a few separate emails, to keep the discussion on each separate point 
 focussed.
 
 Joe informed us of the process for getting featured in Google Play. The long 
 and short of it is that once we decide we’ve got a build that’s worth 
 featuring, we upload it to Google Play and contact Joe. There is a board at 
 Google that makes the decision about whether or not to feature an app and 
 that decision is multifactorial, including factors like what other apps are 
 featured at that time and whether it fits with the current theme of the store 
 (e.g. “Back to School”, etc.). We made need to make some tweaks to get it 
 featured (e.g. he said they might say something like “Make the app more 
 tablet-friendly and we can feature it”), and we’d be informed of what those 
 were.
 
 We’ve got a choice with how we proceed with this:
 We submit the current form of the production build to be featured. 
 We wait to finish some of the current threads of work (e.g. wrapping up page 
 issues and disambiguation), upload and hold that build unpublished, then 
 submit that to be featured, coordinating the release date with Joe.
 I have a mild preference for option 2 as then we can coordinate the release 
 of the new features with the featuring, and get more bang for our buck. That 
 said, I am extremely proud of the app that we have out there right now, so I 
 would be more than happy to submit to be featured if that’s the consensus.
 
 Thoughts?
 
 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

Re: [WikimediaMobile] iOS Wikipedia app beta 4.01 beta 10

[Monte Hurd]

That's great! 

 On Aug 23, 2014, at 2:00 AM, Vibha Bamba vba...@wikimedia.org wrote:
 
 I examined for all the previous reference bugs using my list of articles.No 
 more empty panes, Its all fixed! yay :)
 
 
 Vibha Bamba
 Senior Designer | WMF Design
 
 
 
 
 
 
 
 
 On Sat, Aug 23, 2014 at 12:36 AM, Monte Hurd mh...@wikimedia.org wrote:
 Today's beta includes the following newness:
 
 - Fix for table of contents sometimes causing the article to jump around 
 erratically when selecting a section near the bottom of an article. This fix 
 incidentally made the TOC animation much more smooth :)
 
 - Networking crash fix.
 
 - More responsive article touch event handling.
 
 - Fix for reference panel sometimes flickering to blank.
 
 - Better table of contents swipe gesture responsiveness. 
 
 - Slight increase in size of Nearby item distance label for better 
 readability.
 
 
 
 If you haven't already signed up to the beta program you can do so here:
 
 http://tflig.ht/1dhqz8j
 
 Feel free to share this link too!
 
 
 ___
 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

[WikimediaMobile] Thoughts on using different wikifont icon for TOC (Wikipedia App)

[Monte Hurd]

When the TOC is closed it would use the one on the left, and when open the one 
on the right (see attachment). (Reversed for RTL langs of course)

I think this would really help distinguish it from just being a hamburger 
type settings icon.___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] opensearch vs. prefixsearch

[Monte Hurd]

Awesome!


On Wed, Aug 20, 2014 at 12:08 PM, Maryana Pinchuk mpinc...@wikimedia.org
wrote:

 It's https://trello.com/c/J52fOPCY/17-5-better-search-results in the
 current sprint :)


 On Wed, Aug 20, 2014 at 12:07 PM, Max Semenik maxsem.w...@gmail.com
 wrote:

 Yep, currently working on that card.


 On Wed, Aug 20, 2014 at 10:43 PM, Tomasz Finc tf...@wikimedia.org
 wrote:

 On Fri, Aug 15, 2014 at 12:57 PM, Maryana Pinchuk
 mpinc...@wikimedia.org wrote:
  Yeah, this sounds like the issue ErikM reported before Wikimania. We
 (and by
  we I mean Max after he gets back from vacation...) should fix it :)

 Do we have a card/bug tracking this? I want to make sure it doesn't get
 lost.

 --tomasz

 ___
 Mobile-l mailing list
 Mobile-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/mobile-l




 --
 Best regards,
 Max Semenik ([[User:MaxSem]])




 --
 Maryana Pinchuk
 Product Manager, Wikimedia Foundation
 wikimediafoundation.org

 ___
 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

Re: [WikimediaMobile] opensearch vs. prefixsearch

[Monte Hurd]

Whoa you're right! In Firefox when I search for color the color article
is first, but in Chrome colorado is first...



On Fri, Aug 15, 2014 at 7:07 AM, Jon Robson jdlrob...@gmail.com wrote:

 JSON objects e.g. pages:{} in this example have arbitrary sorting.

 I'm pretty sure mobile web gets the same JSON response as you but the
 browser parses it into the object that gets rendered. You'll notice if
 you search for 's' on Firefox San Francisco is the top article not
 Spain as it is in Chrome.

 Mobile web should probably alphabetize them.. anyone want to raise a bug?
 :)

 On Thu, Aug 14, 2014 at 10:54 PM, Monte Hurd mh...@wikimedia.org wrote:
  Hey Max, I'm trying using the same generator query that mobile web uses,
 but
  I'm getting a different results order as well.
 
  The first result of the following (searching for s) returns San
 Francisco
  as the first result, but when I search using mobile web the first result
 is
  Spain.
 
 
 https://en.m.wikipedia.org/w/api.php?piprop=thumbnailpithumbsize=144format=jsongpssearch=sgenerator=prefixsearchprop=pageimagesaction=querygpsnamespace=0pilimit=24gpslimit=24
 
  Do you see any problems with the query?
 
  Thanks!
 
 
  On Mon, Aug 11, 2014 at 11:21 PM, Max Semenik maxsem.w...@gmail.com
 wrote:
 
  They're powered by the same code, producing identical results, web uses
  prefixsearch because it can be used as a generator. However, the order
 of
  results might be different because the API has its own ideas about
 sorting
  of page set returned by generators. Maryana, we already discussed this
  briefly before WM, do you want me to work on this after my vacation?
 
  11.08.2014 18:47 пользователь Dmitry Brant dbr...@wikimedia.org
  написал:
 
  I was just looking at the Mobile Web search functionality, and I
 noticed
  that the drop-down list of search results in Mobile Web is different
 from
  the list in our native apps for the same search term. It looks like
 Mobile
  Web uses prefixsearch, whereas the apps are using opensearch.
 
  I'm curious what was the rationale for using a different API in the
 apps?
  (Wouldn't we want the search results to be consistent between the Apps
 and
  Mobile Web?)
 
 
  -Dmitry
 
 
  ___
  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
 



 --
 Jon Robson
 * http://jonrobson.me.uk
 * https://www.facebook.com/jonrobson
 * @rakugojon

___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] opensearch vs. prefixsearch

[Monte Hurd]

Hey Max, I'm trying using the same generator query that mobile web uses,
but I'm getting a different results order as well.

The first result of the following (searching for s) returns San Francisco
as the first result, but when I search using mobile web the first result is
Spain.

https://en.m.wikipedia.org/w/api.php?piprop=thumbnailpithumbsize=144format=jsongpssearch=sgenerator=prefixsearchprop=pageimagesaction=querygpsnamespace=0pilimit=24gpslimit=24

Do you see any problems with the query?

Thanks!


On Mon, Aug 11, 2014 at 11:21 PM, Max Semenik maxsem.w...@gmail.com wrote:

 They're powered by the same code, producing identical results, web uses
 prefixsearch because it can be used as a generator. However, the order of
 results might be different because the API has its own ideas about sorting
 of page set returned by generators. Maryana, we already discussed this
 briefly before WM, do you want me to work on this after my vacation?
 11.08.2014 18:47 пользователь Dmitry Brant dbr...@wikimedia.org
 написал:

 I was just looking at the Mobile Web search functionality, and I noticed
 that the drop-down list of search results in Mobile Web is different from
 the list in our native apps for the same search term. It looks like Mobile
 Web uses prefixsearch, whereas the apps are using opensearch.

 I'm curious what was the rationale for using a different API in the apps?
 (Wouldn't we want the search results to be consistent between the Apps and
 Mobile Web?)


 -Dmitry


 ___
 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

[WikimediaMobile] New Testflight beta for iOS app!

[Monte Hurd]

If you have already signed up to receive betas you should get an email
shortly.

If you want to sign up, go here:
http://www.testflightapp.com/join/b1a2a80c3a53dc30691503e6cc0a98c7-MTYyNTU3/

Thanks!
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] New iOS Wikipedia app beta

[Monte Hurd]

If you've signed up to receive beta notifications you should receive one
shortly.

If you'd like to sign up to receive betas, you may do so here:
http://www.testflightapp.com/join/b1a2a80c3a53dc30691503e6cc0a98c7-MTYyNTU3/
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Apps page styling issues etherpad link

[Monte Hurd]

Here's a quick link to a page Vibha and I started as a scratchpad for a
list of page styling issues we've identified in particular articles.

https://etherpad.wikimedia.org/p/App_Page_Styling

Wanted to share this as an initial touchpoint for surfacing some small
styling tweaks that may need to be made to MobileApp css files.
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] QQQuestion

[Monte Hurd]

Is there a standard way to indicate in a qqq file that a particular
translation should try to be as few characters as possible?
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l