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 
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 
> wrote:
>
>> On Thu, Aug 20, 2015 at 1:43 AM Monte Hurd  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]

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]

omatically 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 >>> > 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  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

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 
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 
>> 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 
>>> 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  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*
>>>>

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  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  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 
>> 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  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 
>>>> 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 

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  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 
> 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  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 
>>> 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 :
>>>>
>>>>> 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 
>>>>> 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  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  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 
>> 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 :
>>>
>>>> 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  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  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 
> 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. 
>
>
> 2015-08-18 17:23 GMT+02:00 Magnus Manske :
>
>> 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  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  wrote:
> 
>> On 22 July 2015 at 10:52, Dmitry Brant  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]

Neat! Thanks Stephen!

> On Jul 20, 2015, at 4:35 PM, Stephen Niedzielski  
> 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  wrote:
>> Ooh can you point me to mocks for the floating toc button?
>> 
>>> On Jul 20, 2015, at 1:49 PM, Stephen Niedzielski 
>>>  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]

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

> On Jul 20, 2015, at 1:49 PM, Stephen Niedzielski  
> 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  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  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 ) 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  and  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] Skynet is winning the battle on IRC

[Monte Hurd]

+1

> On Apr 30, 2015, at 10:29 AM, Joaquin Oltra Hernandez 
>  wrote:
> 
> Hi!
> 
> I've been feeling that the signal to noise ratio on #wikimedia-mobile since 
> the addition of wikibugs and our new apps engineers (more grrrit-wm spam) is 
> turning to be 0 (that is, no signal because of too much noise).
> 
> It is really difficult to talk about anything when somebody else is working 
> (and that is what we do, so...).
> 
> I would like to propose moving the machines to a different channel, maybe a 
> couple of them ( #wikimedia-mobile-web-bots & #wikimedia-mobile-apps-bots for 
> example ) so that they continue to be useful but in a different channel, and 
> so that we can read again the chats with just the conversations.
> 
> What do you think?
> 
> Cheers.
> ___
> 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]

An explicit "description" tag eliminates the heuristic problem, but it has 
other problems I think. 

It is markup reliant which raises the contributory bar and complicates any 
description editing UX. 

That is, when a user taps the edit pencil to the right of the description, 
instead of showing just the description in a simple editable text box with a 
small prompt to "Enter a concise description of 'article title'", you'd have to 
show the first section wikitext and explain the description markup. 

It also conflates two concerns, that of a concise description and some 
sub-portion of the first section text. I can appreciate the desire to write 
descriptive information only once, but this comes at a cost - changes to 
improve the quality of the description would have to also be proofed to ensure 
the changes also work in the sub-portion context. 







> On Mar 22, 2015, at 7:28 PM, Dmitry Brant  wrote:
> 
> Hi Monte!
> inline:
> 
> > Deeply hard, in fact, because it's complicated not only by language syntax 
> > and grammatical rules, but also by qualitative factors (readability, 
> > meaning, context, relevance etc).
> > This already complicated situation then becomes many orders of magnitude 
> > more difficult because these qualitative factors can differ between 
> > languages.
> 
> Again, I agree that this is not an easy problem. However, in the case of 
> language translations, automated descriptions have the potential of 
> simplifying things tremendously. The algorithm for the grammar and syntax of 
> a certain language needs to be written only once. And once it's written, it 
> can be applied to every Wikidata item, past and future. Sure, there would 
> likely be a different algorithm for each language, and maybe even different 
> algorithms for various taxa of Wikidata items.  But this kind of solution 
> simply feels more scalable, and I'm surprised that researching methods of 
> accomplishing this are of little interest.
> 
> 
> > I predict this won't be any worse than what happened when we enabled 
> > section editing.
> 
> But when we enabled section editing, did we do it with a prominent call to 
> action? I just feel a little hesitation about going full-on with something 
> like this, without having a baseline level of administrative feedback in the 
> apps (e.g. a notification for when a description is reverted, and the reason 
> for it).
> 
> To be clear, of course I'm totally on board for experimenting with allowing 
> users to contribute descriptions. Making bold moves is what makes our team so 
> great. My goal is simply to point out various other solutions that, to me, 
> make slightly more sense (and to welcome feedback on why they don't!).
> 
> 
> > 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
> 
> That's almost convincing :) but still... why duplicate content when the 
> essential information is already there?
> Maybe I didn't convey my idea of "markup" for extracting a description 
> properly. For example, the description for the [[Fish]] article can be marked 
> up as follows:
> 
> 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.
> 
> The above markup would be done by a human editor, with the knowledge that the 
> text within the  tag will end up as the Wikidata description.  I 
> would wager that a similar scheme could be applied to any number of articles. 
> Let's try it for a few random articles:
> 
> [[Poland]]
> Poland (Polish: Polska; pronounced [ˈpɔlska] ( listen)), officially the 
> Republic of Poland (Polish: Rzeczpospolita Polska; pronounced 
> [ʐɛt͡ʂpɔˈspɔʎit̪a ˈpɔlska] ( listen)), is a country in Central 
> Europe bordered by Germany to the west; the Czech Republic and 
> Slovakia to the south...
> 
> [[Schadenfreude]]
> Schadenfreude (/ˈʃɑːdənfrɔɪdə/; German: [ˈʃaːdn̩ˌfʀɔɪ̯də] ( listen)) is 
> pleasure derived from the misfortunes of 
> others.[1] This word is taken from German...
> 
> [[Ming dynasty]]
> The Ming dynasty, also Empire of the Great Ming, was the ruling 
> dynasty of China for 276 years (1368–1644) following the 
> collapse of the Mongol-led Yuan dynasty...
> 
> [[Homomorphism]]
> In abstract algebra, a homomorphism is a structure-preserving 
> map between two algebraic structures (such as g

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  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 
>> 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
>>
>> Wik

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  wrote:

> Responses inline...
>
>
> On Mar 22, 2015, at 1:53 PM, Dmitry Brant  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 
>> 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 usefu

Re: [WikimediaMobile] Wikidata descriptions: ruminations

[Monte Hurd]

Responses inline...


On Mar 22, 2015, at 1:53 PM, Dmitry Brant  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 
> 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://list

Re: [WikimediaMobile] Wikidata descriptions: ruminations

[Monte Hurd]

Follow-up to my earlier comments:

What do you mean by this:

The "description" field, on the other hand, is the only thing that is *not* 
data, and is not usable by a machine in any way.

How is the description any less usable than any other field? 








> On Mar 22, 2015, at 8:57 AM, Dmitry Brant  wrote:
> 
> The "description" field, on the other hand, is the only thing that is *not* 
> data, and is not usable by a machine in any way.
___
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 8:57 AM, Dmitry Brant  wrote:
> 
> In preparation for next week's quarterly planning, I'd like to restate some 
> of my concerns regarding Wikidata descriptions and flesh them out more 
> comprehensively, since we're featuring them more prominently in the upcoming 
> quarter.
> (n.b. These are more like "devil's advocate" thoughts, lest I make it sound 
> like the Apps team isn't unified in its vision, which it certainly is.)
> 
> My reservations fall under two categories:
> 
> == Philosophical ==
> 
> Wikidata is a superbly valuable repository of *data* -- data that a machine 
> can use to generate all kinds of results that us humans can consume. The 
> "description" field, on the other hand, is the only thing that is *not* data, 
> and is not usable by a machine in any way.
> 
> To allow users to manually fill in the Wikidata description (i.e. to manually 
> duplicate the contents of Wikipedia) is to miss the point of the true 
> potential of Wikidata, which is to be able to *use* the data to generate the 
> description automatically!
> 


I disagree with the premise that the description being "data" means it is 
missing its promise if it is human curated. I am more concerned with the 
quality of the description.




> Of course the counterargument to this is that the current state of 
> auto-generated descriptions is not quite good (they often sound strange or 
> nonsensical), but that's only because the tools we have at our disposal for 
> generating descriptions are still in their infancy. I don't deny that this 
> will be a hard problem to solve, but in my view, this is ultimately the 
> *correct* problem to solve.
> 



It's surprisingly hard to create auto generated descriptions that rival the 
quality of user generated descriptions. 

Deeply hard, in fact, because it's complicated not only by language syntax and 
grammatical rules, but also by qualitative factors (readability, meaning, 
context, relevance etc). 

This already complicated situation then becomes many orders of magnitude more 
difficult because these qualitative factors can differ between languages. 





> The other thing (a more obvious one) that makes Wikidata descriptions 
> redundant is the first sentence of every Wikipedia article which, on its own, 
> is intended to provide a concise description of the article (and many 
> articles already do this with rather good consistency). In fact, as we speak, 
> we're working on programmatically "cleaning up" the first sentence to make it 
> even more concise. Why not simply use this as the description?
> 
> Is the first sentence sometimes too long to be a good description? No 
> problem: create a markup annotation that will denote the *portion* of the 
> first sentence that will serve as the description. In any case, making users 
> manually copy the content from the first sentence (which is from where most 
> of the current Wikidata descriptions appear to be derived) seems 
> extraordinarily unnecessary. 


The description needs to be able to be shorter than the first sentence in the 
article. 




> On top of all that, it creates an unnecessary synchronization cost, 
> fulfillable only by a human contributor, between the two sources of data.
> 
> So, what I mean to say is: every edit to the Wikidata description is a missed 
> opportunity to edit the Wikipedia article in such a way that the description 
> could be auto-generated correctly. (or, similarly, a missed opportunity to 
> edit the *data* of the Wikidata entry in such a way that the description 
> could be auto-generated correctly)
> 
> == Practical ==
> 
> If we open the floodgates to editing the Wikidata description (i.e. if we 
> make it too easy to edit the description), I predict that we'll be very 
> disappointed by the quality of the contributions we'll get. I can see it 
> quickly devolving into a whole lot of noise, spam, and vandalism.
> 



I predict this won't be any worse than what happened when we enabled section 
editing. 




> This means that we would need to implement the same kind of 
> moderation/administration schemes that currently exist on Wikipedia itself.  
> I'm by no means qualified to speak for the Community, but I doubt that many 
> Wikipedians will want to double their workload by having to "watch" the 
> Wikidata description of their favorite articles, in addition to the articles 
> themselves.
> 
> I'll also point out that we do not yet expose any administrative mechanisms 
> in the mobile apps.  This means that users will routinely see their edits 
> disappear or be reverted without any notification or explanation.  This is 
> already the case for the general editing of article content in the apps, but 
> since the description is featured much more prominently, any edits (or 
> reverts) to it will be much more noticeable, and will surely add to the 
> confusion and frustration.




I've been editing descriptions from the Wikidata site directly for m

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

[Monte Hurd]

Whoa interesting!


> On Mar 20, 2015, at 10:29 PM, Dan Garry  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] [ios] nullable annotations in Xcode 6.3!!

[Monte Hurd]

Cool! +1 to setting "Xcode 6.3 as the minimum supported Xcode version"


> On Mar 14, 2015, at 5:04 PM, Brian Gerstle  wrote:
> 
> iOS devs can finally claim functionality that our Java counterparts have been 
> taking for granted: "nullable" annotations in ObjC which transfer to Optional 
> Swift types!
> 
> I hope we can start using these in our app ASAP.  It will help ObjC dev 
> efforts a ton while also easing our (not too distant) transition to Swift.  I 
> think that all we need to do is specify Xcode 6.3 as the minimum supported 
> Xcode version.  I'm guessing lesser versions will fail to compile the code if 
> they encounter one of these new pragmas or annotations.
> 
> -- 
> 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

[WikimediaMobile] iOS app: Xcode "Simulator already in use" message when trying to run project...

[Monte Hurd]

I've run into this quite a bit, and it's super annoying as, once this
message is shown, it seems Xcode can't run the project in the simulator
until you restart Xcode.

What I've found seems to help is always hitting *command-period* before
tapping *command-r*.

ymmv
___
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  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  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 
>>>  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 :
 (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  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, Ma

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  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
> 
> 
> 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
> 
> 
> 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  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]

gt;
>>> make.width.equalTo(@(iconHeight));
>>>
>>>
>>> }];
>>>
>>> It took me longer to grok the old code than it did for me to write the
>>> 10 lines to replace it. Not to mention, the intent of the Masonry code
>>> reads very well (no keys to assign to my views, no dictionaries to hold
>>> values). And the best part is that the compiler would instantly tell me if
>>> I had written an invalid constraint, unlike the old code where it would
>>> have been very easy for someone to forget to type a "(" or a ":"
>>>
>>> (note: conflicting/ambiguous constraints are different concern that
>>> really only IB can handle which is a good reason why you should always try
>>> to use that first)
>>>
>>>
>>> On Thu, Feb 19, 2015 at 12:34 PM, Adam Baso  wrote:
>>>
>>>> Here's my take on this is:
>>>>
>>>> |_ Establish layout related stuff in XIBs via Interface Builder when
>>>> possible.
>>>> |__ If the XIB approach is inadequate, use VFL where it's easy and
>>>> clear and achieves the desired result.
>>>> |___ If VFL is insufficient, try the more verbose builtin methods if
>>>> they don't make it too hard (e.g., 4-8 manual constraints isn't that bad,
>>>> but when it starts to go over that, things are probably getting messier
>>>> than needed).
>>>> | When XIBs, VFL, and verbose methods are too cumbersome, use
>>>> Masonry if it helps achieve the task with greater clarity, easy, and
>>>> correctness.
>>>>
>>>> I trust we'll all be able to make reasonable case-by-case judgments
>>>> about when to fall back from XIB+VFL+builtins to Masonry.
>>>>
>>>> -Adam
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 18, 2015 at 10:07 PM, Corey Floyd 
>>>> wrote:
>>>>
>>>>> Yeah we could swap them out when we need to pretty easily
>>>>>
>>>>> On Wed, Feb 18, 2015 at 6:48 PM, Monte Hurd 
>>>>> wrote:
>>>>>
>>>>>> 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 
>>>>>> 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 
>>>>>>> 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 impl

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  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  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 
>> wrote:
>>
>>> +1
>>>
>>> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd 
>>> 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] 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 
wrote:

> +1
>
> On Wed, Feb 18, 2015 at 12:32 PM, Corey Floyd 
> 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] iOS code style

[Monte Hurd]

Great! Thanks again for note taking and updates!


> On Feb 13, 2015, at 3:17 PM, Brian Gerstle  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] Blockskit (iOS App 3rd Party Library)

[Monte Hurd]

+ 1 to Brian's 1st person comment :)

No reservations.

SHIP IT!

On Fri, Feb 13, 2015 at 2:27 PM, Brian Gerstle 
wrote:

> I love the first-person perspective. Glad to have you BK!
>
> On Fri, Feb 13, 2015 at 3:40 PM, Adam Baso  wrote:
>
>> Great writeup. I don't have any reservations.
>>
>> -Adam
>>
>> On Fri, Feb 13, 2015 at 12:14 PM, Corey Floyd 
>> wrote:
>>
>>> (Testing out our new 3rd party library vetting:
>>> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Third_Party_Libraries
>>> )
>>>
>>>
>>> Early today I interviewed BlocksKit for a potential position in our
>>> codebase (Specifically BlocksKit/Core).
>>>
>>> BlocksKit is a popular functional veneer for the cocoa frameworks. You
>>> can find out more about BlocksKit here:
>>> https://github.com/zwaldowski/BlocksKit
>>>
>>> Read BlocksKit's responses to our interview questions below:
>>>
>>>
>>>
>>>- Is the license permissive?
>>>
>>> Yes, I have an MIT license! Use me how you will.
>>>
>>>- Is the library ubiquitous?
>>>
>>> I have 3,100+ stars and 407 forks on Github - people like me.
>>>
>>>-  Is it installable via CocoaPods?
>>>
>>> Of course!
>>>
>>>- What is the impact on binary size?
>>>
>>> Negligible, I don't contain any assets and consist mostly of small
>>> categories.
>>>
>>>- How severe, if at all, are inbuilt subdependencies?
>>>
>>> I don't need no stinking dependencies.
>>>
>>>- Will this make the code more, or less, understandable for
>>>volunteers?
>>>
>>> Depends on the volunteer - Those with with functional programming skills
>>> will be more comfortable with my syntax. I am however a pretty well
>>> documented and lightweight library, so I should be easy to understand for
>>> anyone how to use me.
>>>
>>>- What are the performance ramifications of using this library?
>>>
>>> None, I use foundation classes to perform enumerations so I get all the
>>> performance benefits of the Cocoa collections.
>>>
>>>- What are the complexity ramifications of using this library?
>>>
>>> My primary purpose is to remove boiler plate code and make developer
>>> intent more clear. I should decrease complexity of your code.
>>>
>>>- Is it actively maintained?
>>>
>>> Yes - I am very well cared for and have a nice test suite.
>>>
>>>- Is it compatible with current deployment targets?
>>>
>>> Yes - I still have a soft spot for iOS 6.
>>>
>>>- Does it hinder interop (e.g., with Swift)?
>>>
>>> I love and Obj-C and Swift (but Swift does include some of my
>>> functionality in the standard library)
>>>
>>>- What is the exit plan if the library becomes unmaintained?
>>>
>>> Since I am pretty lean and have good test coverage, your team should be
>>> able to maintain me if needed. If you decide to not maintain me, you can
>>> move some of your codebase to swift to replace some of my functionality.
>>>
>>>
>>> Thanks for reading… If you have any other questions for BlocksKit, be
>>> sure to leave them here and we will forward them on.
>>>
>>>
>>>
>>> ___
>>> 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] 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  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  wrote:
>> On 5 February 2015 at 13:20, Max Semenik  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  wrote:
> 
>> On Thu, Feb 5, 2015 at 12:00 PM, Dan Garry  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  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"  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  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  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  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&#x

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

[Monte Hurd]

(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  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  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] [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  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  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"  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]

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  wrote:
> 
>> On 19 December 2014 at 21:58, Dan Garry  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  wrote:
> 
>> On 19 December 2014 at 21:58, Dan Garry  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]

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  wrote:
> 
>> On 19 December 2014 at 21:58, Dan Garry  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=query&colimit=1&format=jsonfm&generator=geosearch&ggscoord=37.786816%7C-122.399254&ggslimit=1&ggsradius=1&pilimit=1&pithumbsize=144&prop=coordinates%7Cpageimages%7Cpageterms&wbptterms=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]

Bahaha!!


> On Dec 8, 2014, at 10:17 PM, Dan Garry  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  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  wrote:
>>> 
>>>> On 8 December 2014 at 18:05, Monte Hurd  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] [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  wrote:
> 
>> On 8 December 2014 at 18:05, Monte Hurd  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]

"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. 



> On Dec 8, 2014, at 5:10 PM, Dan Garry  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
___
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=query&prop=imageinfo&format=json&iiprop=url&iiurlwidth=55&titles=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  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 
> 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  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]

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  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  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] 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  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  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  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  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] [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  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] [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  wrote:
> 
>> On Wed, Dec 3, 2014 at 6:15 PM, Dan Garry  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]

Nik just fixed the prefix search result relevancy ordering! Swat deploying in 
the morning:
https://gerrit.wikimedia.org/r/#/c/174624/






> On Nov 19, 2014, at 6:14 PM, Dan Garry  wrote:
> 
> Monte, Dmitry, myself, Nik and Chad are meeting tomorrow to discuss this. I'm 
> pretty hopeful that this will be a fruitful discussion, because it sounds 
> like Nik and Chad are really tuned in to troubles we're having right now.
> 
> Dan
> 
>> On 19 November 2014 15:16, Dmitry Brant  wrote:
>> Note also the bug that I filed today:
>> https://bugzilla.wikimedia.org/show_bug.cgi?id=73623
>> 
>> 
>>> On Wed, Nov 19, 2014 at 6:14 PM, Monte Hurd  wrote:
>>> 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  
>>>> 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  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  wrote:
>>>>>> Do we have a bug to track whatever the issue might be ?
>>>>>> 
>>>>>> On Wed, Nov 19, 2014 at 2:30 PM, Monte Hurd  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  
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> I'd check with Chad and Nick handling todays CirrusSearch deployment.
>>>>>> >>
>>>>>> >> --tomasz
>>>>>> >>
>>>>>> >> On Wed, Nov 19, 2014 at 1:55 PM, Monte Hurd  
>>>>>> >> 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
>> 
>> 
>> ___
>> 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

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 
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  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  wrote:
>>
>>> Do we have a bug to track whatever the issue might be ?
>>>
>>> On Wed, Nov 19, 2014 at 2:30 PM, Monte Hurd  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 
>>> wrote:
>>> >>
>>> >> I'd check with Chad and Nick handling todays CirrusSearch deployment.
>>> >>
>>> >> --tomasz
>>> >>
>>> >> On Wed, Nov 19, 2014 at 1:55 PM, Monte Hurd 
>>> 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] 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  wrote:

> Do we have a bug to track whatever the issue might be ?
>
> On Wed, Nov 19, 2014 at 2:30 PM, Monte Hurd  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 
> wrote:
> >>
> >> I'd check with Chad and Nick handling todays CirrusSearch deployment.
> >>
> >> --tomasz
> >>
> >> On Wed, Nov 19, 2014 at 1:55 PM, Monte Hurd 
> 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]

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  wrote:

> I'd check with Chad and Nick handling todays CirrusSearch deployment.
>
> --tomasz
>
> On Wed, Nov 19, 2014 at 1:55 PM, Monte Hurd  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] switching languages

[Monte Hurd]

How about having the search box placeholder text specify the lang and when the 
search box is empty, since there's no need for a clear button, have instead a 
small lang switcher button?


> On Nov 18, 2014, at 4:03 AM, Amir E. Aharoni  
> wrote:
> 
> Hi,
> 
> I am raising this issue every once in a while...
> 
> Is there any plan to make the app less monolingual? See
> https://bugzilla.wikimedia.org/show_bug.cgi?id=34100
> 
> Currently, the app shows content only in one language. It's possible to 
> switch to another language according to the interlanguage link, but the 
> searching will always be in one language until changed in the preference.
> 
> Back when the feedback mailing list was active this was one of the most 
> requrested features, and I personally strongly support it.
> 
> At the very least, searching must work in the language of the currently 
> displayed article, because seeing content in one language and searching in 
> another is badly confusing.
> 
> Better yet, there should be a way to define several "favorite languages" in 
> which the user is interested, and to show search results from all of them.
> 
> Any chance of that happening soon?
> 
> --
> 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]

Ah! Yes! I left off the "t" :)


> On Nov 15, 2014, at 11:54 AM, Amir E. Aharoni  
> 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 :
>> The signup link for the iOS app:
>> 
>> http://flig.ht/1dhqz8j
>> 
>> 
>> 
>> 
>>> On Nov 15, 2014, at 11:15 AM, Amir E. Aharoni 
>>>  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  wrote:
> 
> Done!
> https://www.mediawiki.org/wiki/Wikimedia_Apps
> 
> 
> 
> 
>> On Sat, Nov 15, 2014 at 2:24 PM, Monte Hurd  wrote:
>> The signup link for the iOS app:
>> 
>> http://flig.ht/1dhqz8j
>> 
>> 
>> 
>> 
>>> On Nov 15, 2014, at 11:15 AM, Amir E. Aharoni 
>>>  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]

The signup link for the iOS app:

http://flig.ht/1dhqz8j




> On Nov 15, 2014, at 11:15 AM, Amir E. Aharoni  
> 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]

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  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  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  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

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  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] 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  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  wrote:
>
>> On 20 October 2014 09:57, Pine W  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

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  wrote:

> On 20 October 2014 09:57, Pine W  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

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  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] [Offline-l] [zero] Re: Thinking about offline search within our native apps

[Monte Hurd]

I would echo Nemo's concern that this sounds a lot like reinventing Kiwix.

Also, Apple doesn't bundle third-party apps, so this would be an Android
only feature.

On Wed, Oct 1, 2014 at 3:30 PM, Federico Leva (Nemo) 
wrote:

> Tomasz Finc, 01/10/2014 23:20:
>
>> In order to do this we can look at the search results on mobile (and
>>> >especially where they are failing today without GS)
>>>
>> One of the asks that I have for the mobile teams in this quarter is to
>> start logging failed search results. I want us to get to the point
>> where we never show a 'no search results' page in any language.
>>
>
> So, a custom solution for the decade-old requests (especially by
> Wiktionary) for logs of search queries without results (cf. countless ML
> threads) and smarter suggestions (cf. e.g.  org/buglist.cgi?bug_id=56320%2C47979%2C10421>)?
> Please make sure the solution is generic enough. Interlanguage suggestions
> and improvements to Cirrus "did you mean", plus some interface to access
> failed searches, would probably solve most problems.
>
> 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] [Apps] Refactoring work on iOS

[Monte Hurd]

Makes sense. 


> On Sep 25, 2014, at 12:20 PM, Yuvi Panda  wrote:
> 
>> On Thu, Sep 25, 2014 at 8:18 PM, Dan Garry  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

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=translate&group=out-wikimedia-mobile-wikipedia-ios-0-all&language=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 :
>
>> 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] 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

[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  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] Pulling the Commons app

[Monte Hurd]

I think it should be pulled. 

> On Sep 8, 2014, at 7:10 PM, Dan Garry  wrote:
> 
>> On 6 September 2014 15:40, Derk-Jan Hartman  
>> wrote:
>> I propose we remove the Wikimedia Commons app from the store.
>> Clearly there is no time available to work on it, there is no one 
>> maintaining it or following up on the problems that have been reported since 
>> 2013.
> 
> Thanks for the suggestion.
> 
> Practically speaking, maintaining this app would mean cannibalising resources 
> currently devoted to the Wikipedia app. Brion and Yuvi are the engineers with 
> the most experience in the Commons app. They're currently split a few 
> different ways (Brion with his duties as an architect, Yuvi with duties to 
> ops) and I'm not eager to split them even further.
> 
> Some framing on userbases: The Commons Android app is installed on around 
> 7,000 devices, compared to the 10 million devices with the Wikipedia app 
> installed on it. The Commons app gets around 300 users per month, and there 
> are more edits than that from the Wikipedia app per day to the English 
> Wikipedia alone. The Commons app user base is minuscule compared to the 
> Wikipedia app.
> 
> Remember that sunsetting the app and removing it from the store would not 
> uninstall it from the devices it's currently installed on, so those people 
> using it would be able to do so. Also, the code would continue to be 
> available, so if someone wanted to clean it up as a volunteer we could then 
> re-publish it easily enough.
> 
> So, in summary, I agree with DJ.
> 
> Thoughts, team?
> 
> 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 6:43 PM, Matthew Flaschen  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] SVG to font (WAS: The future of skins_

[Monte Hurd]

> On Sep 3, 2014, at 8:46 PM, Trevor Parscal  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] [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 
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 
> 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 
>> 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 
>> 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] [Apps] UX review from Google's Android team

[Monte Hurd]

Yes! :)


> On Aug 25, 2014, at 1:59 PM, Tomasz Finc  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  
>> 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  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

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  wrote:

> It should be faster soon, with CirrusSearch just around the corner!
>
> On Mon, Aug 25, 2014 at 6:59 PM, Jon Robson  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 
> wrote:
> >> On 25 August 2014 10:24, Jon Robson  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] Reviews on iOS

[Monte Hurd]

After the next update perhaps :) 

> On Aug 25, 2014, at 10:47 AM, Moiz Syed  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] iOS Wikipedia app beta 4.01 beta 10

[Monte Hurd]

That's great! 

> On Aug 23, 2014, at 2:00 AM, Vibha Bamba  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  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] [Apps] Featuring the app in Google Play

[Monte Hurd]

That's so great! :) 

> On Aug 22, 2014, at 3:44 PM, Dan Garry  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

[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] opensearch vs. prefixsearch

[Monte Hurd]

Awesome!


On Wed, Aug 20, 2014 at 12:08 PM, Maryana Pinchuk 
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 
> wrote:
>
>> Yep, currently working on that card.
>>
>>
>> On Wed, Aug 20, 2014 at 10:43 PM, Tomasz Finc 
>> wrote:
>>
>>> On Fri, Aug 15, 2014 at 12:57 PM, Maryana Pinchuk
>>>  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  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  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=thumbnail&pithumbsize=144&format=json&gpssearch=s&generator=prefixsearch&prop=pageimages&action=query&gpsnamespace=0&pilimit=24&gpslimit=24
> >
> > Do you see any problems with the query?
> >
> > Thanks!
> >
> >
> > On Mon, Aug 11, 2014 at 11:21 PM, Max Semenik 
> 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" 
> >> написал:
> >>>
> >>> 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=thumbnail&pithumbsize=144&format=json&gpssearch=s&generator=prefixsearch&prop=pageimages&action=query&gpsnamespace=0&pilimit=24&gpslimit=24

Do you see any problems with the query?

Thanks!


On Mon, Aug 11, 2014 at 11:21 PM, Max Semenik  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" 
> написал:
>
>> 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] Creating a shell app to house Wikidata games

[Monte Hurd]

I hate to dissent, but I don't think a separate app is the way to go at this 
time for a few reasons. 

First, many of the types of contributions to wikidata that we've talked about 
game-ifying are article specific. ie, "have user read some portion of an 
article and summarize what it's about in 5 words or less", etc. 

This would mean we'd need search and browse etc, and my gut tells me a variety 
of other context and interactions the existing app provides would need to be 
recreated. 

If the existing app could launch the game app, that could be one way to provide 
context, but from a UX perspective, we would otherwise be limiting ourselves to 
tasks that didn't require heavy back-and-forth comparisons and the transition 
between apps, at least on iOS, is super annoying (the way Facebook swaps out to 
Messenger annoys the hell out of me).

I also think, at this time, our limited resources are better spent carefully 
crafting one or two gamed interactions which we can carefully insert into the 
existing app rather than having to solve the inevitable wider set of challenges 
a new app would present. 

The existing app also has a flood of users based on name recognition alone. 
Although I suppose we could call it "Wikipedia Games"...

tl:dr, game-ify yes, other app no/not now










> On Aug 9, 2014, at 17:37, mobile-l-requ...@lists.wikimedia.org wrote:
> 
> Send Mobile-l mailing list submissions to
>mobile-l@lists.wikimedia.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.wikimedia.org/mailman/listinfo/mobile-l
> or, via email, send a message with subject or body 'help' to
>mobile-l-requ...@lists.wikimedia.org
> 
> You can reach the person managing the list at
>mobile-l-ow...@lists.wikimedia.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Mobile-l digest..."
> 
> 
> Today's Topics:
> 
>   1. Creating a shell app to house Wikidata games (Tomasz Finc)
>   2. Re: Creating a shell app to house Wikidata games
>  (May Tee-Galloway)
>   3. Re: Creating a shell app to house Wikidata games (Dmitry Brant)
>   4. Re: Creating a shell app to house Wikidata games (Moiz Syed)
>   5. Re: Creating a shell app to house Wikidata games (Yuvi Panda)
>   6. Re: Creating a shell app to house Wikidata games (Bernd Sitzmann)
> 
> 
> --
> 
> Message: 1
> Date: Sat, 9 Aug 2014 13:35:41 +0100
> From: Tomasz Finc 
> To: mobile-l 
> Subject: [WikimediaMobile] Creating a shell app to house Wikidata
>games
> Message-ID:
>
> Content-Type: text/plain; charset=UTF-8
> 
> It's been amazing to see the interest in WikiData games here at
> Wikimania and i've been approached by a number of people who've wanted
> to create them. From label creation to data validation there have been
> many ideas of how to engage users in new and creative ways.
> 
> I'm curious to hear from users on this list and beyond about interest
> in a WikiData games app that would facilitate simple and quick
> contributions.
> 
> The idea would be that the app would act as a simple frontend shell
> that would allow anyone to interact with WikiData games to create,
> curate, and validate content. Putting aside the difficulties of
> dynamic custom user content with the app I'm curious about the
> interest in this.
> 
> I know that that mobile web team is already planning a handful of
> experiments with this and I'm eager to see if some of you would
> frequent an app that collected these and empowered users to contribute
> in ways that doesn't exist yet.
> 
> Do let know
> 
> --tomasz
> 
> 
> 
> --
> 
> Message: 2
> Date: Sat, 9 Aug 2014 15:11:04 +0100
> From: May Tee-Galloway 
> To: Tomasz Finc 
> Cc: mobile-l 
> Subject: Re: [WikimediaMobile] Creating a shell app to house Wikidata
>games
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
> 
> You got a designer here!
> 
> 
>> On Sat, Aug 9, 2014 at 1:35 PM, Tomasz Finc  wrote:
>> 
>> It's been amazing to see the interest in WikiData games here at
>> Wikimania and i've been approached by a number of people who've wanted
>> to create them. From label creation to data validation there have been
>> many ideas of how to engage users in new and creative ways.
>> 
>> I'm curious to hear from users on this list and beyond about interest
>> in a WikiData games app that would facilitate simple and quick
>> contributions.
>> 
>> The idea would be that the app would act as a simple frontend shell
>> that would allow anyone to interact with WikiData games to create,
>> curate, and validate content. Putting aside the difficulties of
>> dynamic custom user content with the app I'm curious about the
>> interest in this.
>> 
>> I know that that mobile web team is already planning a handful of
>> experiments with this and I'm eager to see if some of you would
>> frequent an app that collected these and empowered us

[WikimediaMobile] iOS Wikipedia app crash reports!

[Monte Hurd]

With Brion's help I now have symbolicated crash reports!

Based on my airport session this afternoon we have another crash fix patch
already merged and one more which we'll test on old iOS 6 devices over the
next few days :)

These crashes are going down!!!
___
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] 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] 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

Re: [WikimediaMobile] Can iOS app be released to a couple small localizations intially?

[Monte Hurd]

opps! thanks yuvi!


On Tue, Apr 15, 2014 at 12:02 PM, Yuvi Panda wrote:

> Moving to mobile-l.
>
> This is to have a way to conduct a wider amount of testing on iOS than has
> been currently possible.
>
> -- Forwarded message ------
> From: Monte Hurd 
> Date: Wed, Apr 16, 2014 at 12:27 AM
> Subject: Can iOS app be released to a couple small localizations intially?
> To: mobile-tech 
>
>
> As Tomasz pointed out, it may not be possible, but it's worth looking in
> to.
>
> Thoughts?
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l