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

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 com

Re: [WikimediaMobile] maps on iOS

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

[WikimediaMobile] Speed

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 dramatical

Re: [WikimediaMobile] Speed

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 inspecto

Re: [WikimediaMobile] maps on iOS

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

Re: [WikimediaMobile] Speed

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

Re: [WikimediaMobile] maps on iOS

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,

Re: [WikimediaMobile] Speed

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 shar

Re: [WikimediaMobile] maps on iOS

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

Re: [WikimediaMobile] Speed

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

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

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

Re: [WikimediaMobile] Speed

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 re

Re: [WikimediaMobile] Speed

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

[WikimediaMobile] Fwd: Versioning MobileFrontend

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

[WikimediaMobile] Wikipedia Beta for iOS 4.0.7.8 on TestFlight

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 Mobil

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

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 a

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

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

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

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 wro