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

[Bernd Sitzmann]

What's the distribution of the different positions clicked on in Read more?
Pos 1, 2, 3? I bet #1 still gets the most but the other ones are probably
not too far behind.

Since you used the word verdict. Does this imply we abandon Read next?

Bernd

On Fri, Mar 20, 2015 at 11:31 PM, Monte Hurd  wrote:

> 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
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

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

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

[Dan Garry]

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

[WikimediaMobile] Wikipedia Beta for iOS 4.0.7.8 on TestFlight

[Adam Baso]

The Wikipedia Beta for iOS 4.0.7.8 has been sent out to the external
testing group via TestFlight. v 4.0.7.7 was only released internally (it
was missing the Crash button), so we skipped that for the external testing
group.
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Fwd: Versioning MobileFrontend

[Bahodir Mansurov]

Moving to mobile-l

> Begin forwarded message:
> 
> Date: March 20, 2015 at 5:00:09 PM EDT
> Subject: Re: Versioning MobileFrontend
> From: Jon Robson 
> To: Bahodir Mansurov 
> Cc: mobile-tech 
> 
> Seems sensible, but knowing history I don't think it will be updated 
> correctly.
> 
> I think the updating of VERSION.txt really needs to be automated. Can we have 
> a script that can be run bumps the version number and  generates these logs 
> by searching for keywords e.g. 'Bug:' 'Feature:' and generates this list. I 
> think without this, this is a nice idea but will be disastrous.
> 
> 
> On Fri, Mar 20, 2015 at 1:56 PM, Bahodir Mansurov  > wrote:
> Hello,
> 
> I’ve submitted a patch [1] in which I’d like to start documenting changes in 
> MobileFrontend and versioning it so that interested third parties are more 
> informed about developments in MF. I think we will bump versions at the end 
> of our sprints. I would appreciate it if anyone can share any similar 
> experience they had or any other suggestions. Thank you.
> 
> Baha
> 
> 
> [1] https://gerrit.wikimedia.org/r/#/c/198382/ 
> 

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

Re: [WikimediaMobile] Speed

[Vibha Bamba]

+1

Monte and Bernd have already been working hard to improve performance.
It will be awesome to keep improving the performance.

Users tend to jump through a lot of links while reading.
Right now it takes an average of 1 - 2.5 seconds to load an article.
Fast loading will encourage more exploration and jumping to this app than
using google.

Thanks
Vibha



Vibha Bamba
Senior Designer | WMF Design







On Fri, Mar 20, 2015 at 6:57 AM, Adam Baso  wrote:

> For the upcoming unstructured sprint on iOS or perhaps later on, would it
> make sense to explore reinstating the loading of the first section of an
> article in one request, followed by loading of the others?
>
> I've heard that the payload for the upcoming mobile app content service is
> pretty dramatically reduced, although that's down the road for full
> productionization.
>
> I'm wondering if on this single payload for the new content service for
> relatively larger articles the time to interact for the iOS user would
> approach the incredibly fast time-to-interact that's present on Android as
> a consequence of its two-step loading mechanism.
>
> For some historical context, there was two-step loading on iOS, but
> eventually things became crashy, so it was revised to be a one-step
> action=mobileview call.
>
> -Adam
>
> ___
> 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] Speed

[Adam Baso]

Yeah, that's encouraging. Be interesting to test browser overhead and
bandwidth overhead. Lots of things to look at.

On Fri, Mar 20, 2015 at 8:53 AM, Yuvi Panda  wrote:

> I'll note that we have SPDY on the cluster now (mostly on all
> machines, if not complete in the next few days), and so two requests
> don't have as much of a connection overhead as they used to.
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

Re: [WikimediaMobile] Restoring anon editing on all mobile sites by March

[Jon Robson]

Some questions
1) How would anonymous users get to their 'talk pages' on mobile? (note
talk pages are /enabled/ just not surfaced in the UI) and do we have any
evidence anons read them?
2) The majority of MobileFrontend developers are wrapping up projects in
the last two weeks (Extension:Gather and Extension:Wikigrok). To meet this
March release date who will be responsible for enabling this feature and
the work that involves?
3) What does success/failure look like? i.e. under what circumstances could
the feature be disabled. It's good to make this clear so there is no
confusion about when to do this.
4) To be clear, it seems from the feedback you gave me on the meta wiki
proposal talk page that there are no plans at present to enrich the feature
in any way. This is simply a case of turning the feature on. Can you
confirm this? New feature development = time for code review, so I want to
be sure this is not going to become a strain on the development team I am
part of.

Please be sure to enable this feature correctly. With Italian Wikipedia a
cache flush was required and this shouldn't be needed and will not be
allowed on English Wikipedia and other larger projects.

Note: The talk page did not help upload errors in past. Only logged in
users could upload and they had easy access to their talk pages via Echo
notifications.
On 20 Mar 2015 1:01 am, "Federico Leva (Nemo)"  wrote:

> See https://phabricator.wikimedia.org/T93210 for details.
>
> Quoting from the discussion: «As of today, there is broad consensus in
> support of the proposal, as discussed by an ample spectrum of users active
> in multiple wikis. Several users stressed that: talk page access is
> crucial, to ensure communication with mobile users; errors of the past,
> like the mobile uploads campaign, must not be repeated; local and global
> effects in terms of (un)productive contributions will be under constant
> monitoring and re-evaluation per the usual processes.»
>
> 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] Speed

[Yuvi Panda]

I'll note that we have SPDY on the cluster now (mostly on all
machines, if not complete in the next few days), and so two requests
don't have as much of a connection overhead as they used to.

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

Re: [WikimediaMobile] maps on iOS

[Brian Gerstle]

On Fri, Mar 20, 2015 at 11:17 AM, Ulf Buermeyer  wrote:

>
> Hi,
>
> just reporting (not subscribing to) the privacy issues ... and IIRC
> there was also a "non-free maps in the context of free knowledge" issue
> being raised.
>

Interesting, since Apple uses OSM to power Apple Maps
.


>
>
> Anyhow, if what Brian suggests is generally accepted then I'm happy to
> update my patch (using Apple maps) to the current state of the app &
> submit a new pull request. OSM could always be added lated - I feel it's
> a great way to point users to what free content has to offer by now.
>
> Let me know.
>
> Best, Ulf
>
>
> On 20/03/15 16:10, Brian Gerstle wrote:
> > Ulf, thanks bring me up to speed.  I'd love to make this happen, so I've
> > written some responses inline.
> > *
> > *
> > *TL;DR;* I disagree with privacy concerns raised in the PR and (in my
> > non-legal-expert-opinion) think we should be able to do this w/o
> > affecting user privacy or complicated workarounds.
> >
> > On Fri, Mar 20, 2015 at 10:47 AM, Ulf Buermeyer  > > wrote:
> >
> >
> > Hi Brian & all,
> >
> > that's basically what I implemented last year (but for articles with
> > geocoordinates):
> >
> > https://github.com/wikimedia/apps-ios-wikipedia/pull/3
> >
> > The addition was rejected for policy reasons (see discussion in the
> PR)
> > - iOS hits Apple servers to download maps and thereby reveals the
> users'
> > locations to Apple.
> >
> >
> > This was before I joined the org.  Though I'm reluctant to, I'd like to
> > revisit this debate because I feel we'd be adding a non-trivial amount
> > of complexity (maintenance cost) to the app when it can be avoided.
> >
> > First, showing a map with annotations on it does not require knowing the
> > user's location.  We can simply render a map for a given coordinate
> > region and decorate it with annotations from the article.  To put it
> > plainly, does looking up map data about Egypt tell Apple that I'm Egypt?
> >
> > Second, and most importantly, we're already giving Apple the user's
> > location for the Nearby feature.  If we wanted to show the user's
> > location, we could simply ask for it.
> >
> >
> >
> > Thus we thought we might rather use OpenStreetMap data: If you cache
> the
> > tiles on a proxy operated by Wikimedia, then nobody's privacy will be
> > harmed. The OSM tile server guys would probably prefer you to do that
> > anyway (server load on their side would be HUGE if that's rolled out
> in
> > production).
> >
> >
> > Only issue (besides setting up the proxy) was to keep iOS from
> loading
> > Apple data. That's now feasible as of iOS7 using [MKOverlay
> > canReplaceMapContent] => YES.
> >
> >
> > IMO, the cost of implementing and maintaining all of this does not
> > justify the benefit to the user.  We can add a lot of user value with
> > other features, and in this case simply prompt the user with an "Open
> > With..." dialog to view it in an app of their choice.  This shouldn't be
> > necessary, as we can render maps in the Wikipedia app without requiring
> > user location.
> >
> >
> >
> > Best, Ulf
> >
> >
> > On 20/03/15 15:38, Brian Gerstle wrote:
> >
> > > Adding a native map view to display nearby locations on a map
> sounds
> > > like a great feature!  Are there any links to mock-ups of what the
> > > feature is supposed to look like?  I ask because it's not clear
> why we
> > > need custom map tiles or URL protocols instead of simple
> annotations &
> > > annotation views.  These are straightforward to implement and fully
> > > backwards compatible.
> > >
> > > On Fri, Mar 20, 2015 at 9:43 AM, Adam Baso  
> > > >> wrote:
> > >
> > > Migrating thread to mobile-l, with Ulf's permission.
> > >
> > > On Wed, Mar 18, 2015 at 11:29 PM, Ulf Buermeyer <
> ub2...@columbia.edu 
> > > >>
> wrote:
> > >
> > >
> > > Hi all,
> > >
> > > if you're deprecating iOS6 then the solution might be to
> just
> > > implement
> > >
> > > [MKOverlay canReplaceMapContent]
> > >
> > > and return YES. This effectively prevents iOS from loading
> Apple map
> > > content:
> > >
> > >
> https://developer.apple.com/library/ios/documentation/MapKit/Reference/MKOverlay_protocol/#//apple_ref/occ/intfm/MKOverlay/canReplaceMapContent
> > >
> > > As for the MKTileOverlay, that would be an option as well,
> I'm
> > > just not
> > > sure how efficient it is for caching OSM content - the
> > > documentation is
> > > silent on that point:
> > >
> > >
> https://d

Re: [WikimediaMobile] Speed

[Brian Gerstle]

You can always do it manually:

   1. Use network link conditioner on your mac to throttle the emulator

or

   1. Plug your Mac into the internet via ethernet
   2. Share your internet via your Mac's wifi
   3. Join the WiFi on any test devices
   4. Enable network link conditioner on the Mac sharing WiFi


While I think being able to handle both high latency and/or low bandwidth
is important, I'm pretty confident that networking efficiency is not the
main culprit in our case to solve page load time issues.


On Fri, Mar 20, 2015 at 10:51 AM, Adam Baso  wrote:

> Great ideas!
>
> Dmitry or Bernd, do you know of any quick way to cap Android internet
> connection speeds on a physical device without rooting the device for doing
> side by side comparisons on medium to low speed connections? I can think of
> some less quick ways and also about how an emulator may sort of achieve the
> same, but was curious about simple ways to test on physical devices.
>
> -Adam
>
>
> On Fri, Mar 20, 2015 at 7:27 AM, Brian Gerstle 
> wrote:
>
>> Two-step loading could be one viable approach.  However, as with any
>> optimizations, I would prefer to conduct an investigation (or see data from
>> a previous one) about what page loading stages are taking the longest.
>> This can be a combination of loading a few sample articles with the Safari
>> inspector & Instruments attached (as well as loading the page in chrome w/
>> the chrome dev tools).  I'm guessing there would be some high-yield
>> opportunities to collaborate with mobile-web to optimize page load times
>> before (or even in parallel to) any optimizations on the native end.
>>
>> Of course, any page loading optimizations we make need to keep offline
>> use in mind—at least for native apps.
>>
>> On Fri, Mar 20, 2015 at 9:57 AM, Adam Baso  wrote:
>>
>>> For the upcoming unstructured sprint on iOS or perhaps later on, would
>>> it make sense to explore reinstating the loading of the first section of an
>>> article in one request, followed by loading of the others?
>>>
>>> I've heard that the payload for the upcoming mobile app content service
>>> is pretty dramatically reduced, although that's down the road for full
>>> productionization.
>>>
>>> I'm wondering if on this single payload for the new content service for
>>> relatively larger articles the time to interact for the iOS user would
>>> approach the incredibly fast time-to-interact that's present on Android as
>>> a consequence of its two-step loading mechanism.
>>>
>>> For some historical context, there was two-step loading on iOS, but
>>> eventually things became crashy, so it was revised to be a one-step
>>> action=mobileview call.
>>>
>>> -Adam
>>>
>>> ___
>>> 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
>>
>
>


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

Re: [WikimediaMobile] maps on iOS

[Brian Gerstle]

Ulf, thanks bring me up to speed.  I'd love to make this happen, so I've
written some responses inline.

*TL;DR;* I disagree with privacy concerns raised in the PR and (in my
non-legal-expert-opinion) think we should be able to do this w/o affecting
user privacy or complicated workarounds.

On Fri, Mar 20, 2015 at 10:47 AM, Ulf Buermeyer  wrote:

>
> Hi Brian & all,
>
> that's basically what I implemented last year (but for articles with
> geocoordinates):
>
> https://github.com/wikimedia/apps-ios-wikipedia/pull/3
>
> The addition was rejected for policy reasons (see discussion in the PR)
> - iOS hits Apple servers to download maps and thereby reveals the users'
> locations to Apple.
>

This was before I joined the org.  Though I'm reluctant to, I'd like to
revisit this debate because I feel we'd be adding a non-trivial amount of
complexity (maintenance cost) to the app when it can be avoided.

First, showing a map with annotations on it does not require knowing the
user's location.  We can simply render a map for a given coordinate region
and decorate it with annotations from the article.  To put it plainly, does
looking up map data about Egypt tell Apple that I'm Egypt?

Second, and most importantly, we're already giving Apple the user's
location for the Nearby feature.  If we wanted to show the user's location,
we could simply ask for it.


>
> Thus we thought we might rather use OpenStreetMap data: If you cache the
> tiles on a proxy operated by Wikimedia, then nobody's privacy will be
> harmed. The OSM tile server guys would probably prefer you to do that
> anyway (server load on their side would be HUGE if that's rolled out in
> production).


> Only issue (besides setting up the proxy) was to keep iOS from loading
> Apple data. That's now feasible as of iOS7 using [MKOverlay
> canReplaceMapContent] => YES.
>

IMO, the cost of implementing and maintaining all of this does not justify
the benefit to the user.  We can add a lot of user value with other
features, and in this case simply prompt the user with an "Open With..."
dialog to view it in an app of their choice.  This shouldn't be necessary,
as we can render maps in the Wikipedia app without requiring user location.


>
> Best, Ulf
>
>
> On 20/03/15 15:38, Brian Gerstle wrote:
>
> > Adding a native map view to display nearby locations on a map sounds
> > like a great feature!  Are there any links to mock-ups of what the
> > feature is supposed to look like?  I ask because it's not clear why we
> > need custom map tiles or URL protocols instead of simple annotations &
> > annotation views.  These are straightforward to implement and fully
> > backwards compatible.
> >
> > On Fri, Mar 20, 2015 at 9:43 AM, Adam Baso  > > wrote:
> >
> > Migrating thread to mobile-l, with Ulf's permission.
> >
> > On Wed, Mar 18, 2015 at 11:29 PM, Ulf Buermeyer  > > wrote:
> >
> >
> > Hi all,
> >
> > if you're deprecating iOS6 then the solution might be to just
> > implement
> >
> > [MKOverlay canReplaceMapContent]
> >
> > and return YES. This effectively prevents iOS from loading Apple
> map
> > content:
> >
> >
> https://developer.apple.com/library/ios/documentation/MapKit/Reference/MKOverlay_protocol/#//apple_ref/occ/intfm/MKOverlay/canReplaceMapContent
> >
> > As for the MKTileOverlay, that would be an option as well, I'm
> > just not
> > sure how efficient it is for caching OSM content - the
> > documentation is
> > silent on that point:
> >
> >
> https://developer.apple.com/library/prerelease/ios/documentation/MapKit/Reference/MKTileOverlay_class/index.html
> >
> > And as I already have the drawing code we could go with that.
> >
> > Best, Ulf
> >
> >
> >
> > On 19/03/15 01:49, Adam Baso wrote:
> >
> > > Oops, /now/ I'm CC'ing Max.
> > >
> > > On Wed, Mar 18, 2015 at 10:07 PM, Monte Hurd <
> mh...@wikimedia.org 
> > > >>
> wrote:
> > >
> > > Ulf, I was also thinking we could maybe use a custom
> NSURLProtocol
> > > to intercept the MKMapView's requests for the apple map
> tiles
> > > (instead of a "overlay only" mode - would have the same
> effect I
> > > think). Thoughts?
> > >
> > >
> > > On Mar 18, 2015, at 8:45 PM, Adam Baso <
> ab...@wikimedia.org 
> > > >>
> wrote:
> > >
> > >> Ulf,
> > >>
> > >> Great meeting you!
> > >>
> > >> Hi there - I was wondering if there was perhaps a way to
> make use
> > >> of MKTileOverlay for achieving these ends? We're going to
> be
> > >> deprecating iOS 6 in the relatively 

Re: [WikimediaMobile] Speed

[Adam Baso]

Great ideas!

Dmitry or Bernd, do you know of any quick way to cap Android internet
connection speeds on a physical device without rooting the device for doing
side by side comparisons on medium to low speed connections? I can think of
some less quick ways and also about how an emulator may sort of achieve the
same, but was curious about simple ways to test on physical devices.

-Adam


On Fri, Mar 20, 2015 at 7:27 AM, Brian Gerstle 
wrote:

> Two-step loading could be one viable approach.  However, as with any
> optimizations, I would prefer to conduct an investigation (or see data from
> a previous one) about what page loading stages are taking the longest.
> This can be a combination of loading a few sample articles with the Safari
> inspector & Instruments attached (as well as loading the page in chrome w/
> the chrome dev tools).  I'm guessing there would be some high-yield
> opportunities to collaborate with mobile-web to optimize page load times
> before (or even in parallel to) any optimizations on the native end.
>
> Of course, any page loading optimizations we make need to keep offline use
> in mind—at least for native apps.
>
> On Fri, Mar 20, 2015 at 9:57 AM, Adam Baso  wrote:
>
>> For the upcoming unstructured sprint on iOS or perhaps later on, would it
>> make sense to explore reinstating the loading of the first section of an
>> article in one request, followed by loading of the others?
>>
>> I've heard that the payload for the upcoming mobile app content service
>> is pretty dramatically reduced, although that's down the road for full
>> productionization.
>>
>> I'm wondering if on this single payload for the new content service for
>> relatively larger articles the time to interact for the iOS user would
>> approach the incredibly fast time-to-interact that's present on Android as
>> a consequence of its two-step loading mechanism.
>>
>> For some historical context, there was two-step loading on iOS, but
>> eventually things became crashy, so it was revised to be a one-step
>> action=mobileview call.
>>
>> -Adam
>>
>> ___
>> 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

Re: [WikimediaMobile] maps on iOS

[Brian Gerstle]

Adding a native map view to display nearby locations on a map sounds like a
great feature!  Are there any links to mock-ups of what the feature is
supposed to look like?  I ask because it's not clear why we need custom map
tiles or URL protocols instead of simple annotations & annotation views.
These are straightforward to implement and fully backwards compatible.

On Fri, Mar 20, 2015 at 9:43 AM, Adam Baso  wrote:

> Migrating thread to mobile-l, with Ulf's permission.
>
> On Wed, Mar 18, 2015 at 11:29 PM, Ulf Buermeyer 
> wrote:
>
>>
>> Hi all,
>>
>> if you're deprecating iOS6 then the solution might be to just implement
>>
>> [MKOverlay canReplaceMapContent]
>>
>> and return YES. This effectively prevents iOS from loading Apple map
>> content:
>>
>>
>> https://developer.apple.com/library/ios/documentation/MapKit/Reference/MKOverlay_protocol/#//apple_ref/occ/intfm/MKOverlay/canReplaceMapContent
>>
>> As for the MKTileOverlay, that would be an option as well, I'm just not
>> sure how efficient it is for caching OSM content - the documentation is
>> silent on that point:
>>
>>
>> https://developer.apple.com/library/prerelease/ios/documentation/MapKit/Reference/MKTileOverlay_class/index.html
>>
>> And as I already have the drawing code we could go with that.
>>
>> Best, Ulf
>>
>>
>>
>> On 19/03/15 01:49, Adam Baso wrote:
>>
>> > Oops, /now/ I'm CC'ing Max.
>> >
>> > On Wed, Mar 18, 2015 at 10:07 PM, Monte Hurd > > > wrote:
>> >
>> > Ulf, I was also thinking we could maybe use a custom NSURLProtocol
>> > to intercept the MKMapView's requests for the apple map tiles
>> > (instead of a "overlay only" mode - would have the same effect I
>> > think). Thoughts?
>> >
>> >
>> > On Mar 18, 2015, at 8:45 PM, Adam Baso > > > wrote:
>> >
>> >> Ulf,
>> >>
>> >> Great meeting you!
>> >>
>> >> Hi there - I was wondering if there was perhaps a way to make use
>> >> of MKTileOverlay for achieving these ends? We're going to be
>> >> deprecating iOS 6 in the relatively near future, and this is an
>> >> iOS 7+ thing.
>> >>
>> >> http://nshipster.com/mktileoverlay-mkmapsnapshotter-mkdirections/
>> >>
>> >> I've CC'd Max Semenik, who may have some insight into tiling
>> >> server options at Wikimedia.
>> >>
>> >> -Adam
>> >>
>> >> On Fri, Mar 13, 2015 at 3:13 PM, Monte Hurd > >> > wrote:
>> >>
>> >> Good seeing you again as well Ulf!
>> >>
>> >> I'll check out the OpenRadar ticket and experiment some more
>> >> with your maps patch.
>> >>
>> >> Exciting stuff!!!
>> >>
>> >> On Wed, Mar 11, 2015 at 10:19 PM, Ulf Buermeyer
>> >> mailto:ub2...@columbia.edu>> wrote:
>> >>
>> >>
>> >>
>> >> Hi,
>> >>
>> >> good to see you guys today! I just wanted to keep you
>> >> posted about that
>> >> maps issue. In fact I re-filed a rdar with Apple in order
>> >> to have them
>> >> add an "overlay only" mode to MKMapView today (the other
>> >> one had been
>> >> closed w/o any feedback). See my OpenRadar for this issue:
>> >>
>> >> http://www.openradar.me/20132462
>> >>
>> >>
>> >> For your reference here is the pull request I issued last
>> >> year (that's
>> >> effectively the code for what I showed to Moiz today):
>> >>
>> >> https://github.com/wikimedia/apps-ios-wikipedia/pull/3
>> >>
>> >> I'd be happy to work with you on a solution that complies
>> with
>> >> Wikimedia's policies as I think that maps for articles or
>> >> even an
>> >> initial "places around you" feature with pins on a map
>> >> would be very
>> >> useful additions to the Wikipedia app.
>> >>
>> >> All the best, Ulf
>>
>>
>
> ___
> 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

Re: [WikimediaMobile] Speed

[Brian Gerstle]

Two-step loading could be one viable approach.  However, as with any
optimizations, I would prefer to conduct an investigation (or see data from
a previous one) about what page loading stages are taking the longest.
This can be a combination of loading a few sample articles with the Safari
inspector & Instruments attached (as well as loading the page in chrome w/
the chrome dev tools).  I'm guessing there would be some high-yield
opportunities to collaborate with mobile-web to optimize page load times
before (or even in parallel to) any optimizations on the native end.

Of course, any page loading optimizations we make need to keep offline use
in mind—at least for native apps.

On Fri, Mar 20, 2015 at 9:57 AM, Adam Baso  wrote:

> For the upcoming unstructured sprint on iOS or perhaps later on, would it
> make sense to explore reinstating the loading of the first section of an
> article in one request, followed by loading of the others?
>
> I've heard that the payload for the upcoming mobile app content service is
> pretty dramatically reduced, although that's down the road for full
> productionization.
>
> I'm wondering if on this single payload for the new content service for
> relatively larger articles the time to interact for the iOS user would
> approach the incredibly fast time-to-interact that's present on Android as
> a consequence of its two-step loading mechanism.
>
> For some historical context, there was two-step loading on iOS, but
> eventually things became crashy, so it was revised to be a one-step
> action=mobileview call.
>
> -Adam
>
> ___
> 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

[WikimediaMobile] Speed

[Adam Baso]

For the upcoming unstructured sprint on iOS or perhaps later on, would it
make sense to explore reinstating the loading of the first section of an
article in one request, followed by loading of the others?

I've heard that the payload for the upcoming mobile app content service is
pretty dramatically reduced, although that's down the road for full
productionization.

I'm wondering if on this single payload for the new content service for
relatively larger articles the time to interact for the iOS user would
approach the incredibly fast time-to-interact that's present on Android as
a consequence of its two-step loading mechanism.

For some historical context, there was two-step loading on iOS, but
eventually things became crashy, so it was revised to be a one-step
action=mobileview call.

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

Re: [WikimediaMobile] maps on iOS

[Adam Baso]

Migrating thread to mobile-l, with Ulf's permission.

On Wed, Mar 18, 2015 at 11:29 PM, Ulf Buermeyer  wrote:

>
> Hi all,
>
> if you're deprecating iOS6 then the solution might be to just implement
>
> [MKOverlay canReplaceMapContent]
>
> and return YES. This effectively prevents iOS from loading Apple map
> content:
>
>
> https://developer.apple.com/library/ios/documentation/MapKit/Reference/MKOverlay_protocol/#//apple_ref/occ/intfm/MKOverlay/canReplaceMapContent
>
> As for the MKTileOverlay, that would be an option as well, I'm just not
> sure how efficient it is for caching OSM content - the documentation is
> silent on that point:
>
>
> https://developer.apple.com/library/prerelease/ios/documentation/MapKit/Reference/MKTileOverlay_class/index.html
>
> And as I already have the drawing code we could go with that.
>
> Best, Ulf
>
>
>
> On 19/03/15 01:49, Adam Baso wrote:
>
> > Oops, /now/ I'm CC'ing Max.
> >
> > On Wed, Mar 18, 2015 at 10:07 PM, Monte Hurd  > > wrote:
> >
> > Ulf, I was also thinking we could maybe use a custom NSURLProtocol
> > to intercept the MKMapView's requests for the apple map tiles
> > (instead of a "overlay only" mode - would have the same effect I
> > think). Thoughts?
> >
> >
> > On Mar 18, 2015, at 8:45 PM, Adam Baso  > > wrote:
> >
> >> Ulf,
> >>
> >> Great meeting you!
> >>
> >> Hi there - I was wondering if there was perhaps a way to make use
> >> of MKTileOverlay for achieving these ends? We're going to be
> >> deprecating iOS 6 in the relatively near future, and this is an
> >> iOS 7+ thing.
> >>
> >> http://nshipster.com/mktileoverlay-mkmapsnapshotter-mkdirections/
> >>
> >> I've CC'd Max Semenik, who may have some insight into tiling
> >> server options at Wikimedia.
> >>
> >> -Adam
> >>
> >> On Fri, Mar 13, 2015 at 3:13 PM, Monte Hurd  >> > wrote:
> >>
> >> Good seeing you again as well Ulf!
> >>
> >> I'll check out the OpenRadar ticket and experiment some more
> >> with your maps patch.
> >>
> >> Exciting stuff!!!
> >>
> >> On Wed, Mar 11, 2015 at 10:19 PM, Ulf Buermeyer
> >> mailto:ub2...@columbia.edu>> wrote:
> >>
> >>
> >>
> >> Hi,
> >>
> >> good to see you guys today! I just wanted to keep you
> >> posted about that
> >> maps issue. In fact I re-filed a rdar with Apple in order
> >> to have them
> >> add an "overlay only" mode to MKMapView today (the other
> >> one had been
> >> closed w/o any feedback). See my OpenRadar for this issue:
> >>
> >> http://www.openradar.me/20132462
> >>
> >>
> >> For your reference here is the pull request I issued last
> >> year (that's
> >> effectively the code for what I showed to Moiz today):
> >>
> >> https://github.com/wikimedia/apps-ios-wikipedia/pull/3
> >>
> >> I'd be happy to work with you on a solution that complies
> with
> >> Wikimedia's policies as I think that maps for articles or
> >> even an
> >> initial "places around you" feature with pins on a map
> >> would be very
> >> useful additions to the Wikipedia app.
> >>
> >> All the best, Ulf
>
>
___
Mobile-l mailing list
Mobile-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l

[WikimediaMobile] Restoring anon editing on all mobile sites by March

[Federico Leva (Nemo)]

See https://phabricator.wikimedia.org/T93210 for details.

Quoting from the discussion: «As of today, there is broad consensus in 
support of the proposal, as discussed by an ample spectrum of users 
active in multiple wikis. Several users stressed that: talk page access 
is crucial, to ensure communication with mobile users; errors of the 
past, like the mobile uploads campaign, must not be repeated; local and 
global effects in terms of (un)productive contributions will be under 
constant monitoring and re-evaluation per the usual processes.»


Nemo

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