Mobile-l June 2015

mobile-l@lists.wikimedia.org

39 participants
58 discussions

Re: [WikimediaMobile] RESTBase on .m sites?
by Bernd Sitzmann 15 Jun '15

15 Jun '15

+ mobile-l Thank you, Gabriel! Cheers, Bernd On Mon, Jun 15, 2015 at 11:50 AM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote: > > > On Fri, Jun 12, 2015 at 11:00 AM, Bernd Sitzmann <bernd(a)wikimedia.org> > wrote: > >> Gabriel and Yuri: >> >> Can we get RESTBase also deployed on the mobile sites, too? >> > > > This should be doable with some Varnish tweaks. Brandon might have an > opinion on this too. I created https://phabricator.wikimedia.org/T102524 > to track this and cc'ed him there. > > >> Or would it be better to send out the Zero headers on the non-m sites, >> too? >> >> If we don't have one of the above and the apps use their RESTBase >> services they cannot detect the Zero-rated state. >> >> Thanks, >> Bernd >> >

1 0

new features in swift 2
by Brian Gerstle 13 Jun '15

13 Jun '15

Looks like Swift 2 is going to lean more on exceptions than returning (and out-param'ing) errors: http://www.hackingwithswift.com/new-features-swift-2 -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle

1 0

Re: [WikimediaMobile] [reading-wmf] A plan for the "new" mobile view service
by S Page 13 Jun '15

13 Jun '15

Awesome. Dmitry I shall make you explain "How I wrote a new RESTBase service" :) Will this replace or subsume http://www.mediawiki.org/wiki/Extension:TextExtracts ? Will clients be able to request first paragraph, first 3 sentences, etc.? > In the case of entities existing within a paragraph, we can decide (with a > little help from Design) whether it's important to keep them inline with > the text, or strip and move them outside of the paragraph. > Will clients be able to request different kinds of stripping? It seems really hard. If you look at the Vincent van Gogh article, its opening sentence is *Vincent Willem van Gogh* (Dutch: [ˈvɪnsɛnt ˈʋɪləm vɑn ˈɣɔx] <https://en.wikipedia.org/wiki/Help:IPA_for_Dutch> ( <https://en.wikipedia.org/wiki/File:Nl-Vincent_van_Gogh.ogg> listen <https://upload.wikimedia.org/wikipedia/commons/3/32/Nl-Vincent_van_Gogh.ogg> );[note 1] <https://en.wikipedia.org/wiki/Vincent_van_Gogh#cite_note-1> 30 March 1853 – 29 July 1890) was a major Post-Impressionist <https://en.wikipedia.org/wiki/Post-Impressionism> painter. and it seems every client shows this differently: Google search results snippet displays Vincent Willem van Gogh (Dutch: [ˈvɪnsɛnt ˈʋɪləm vɑn ˈɣɔx] ( listen); 30 March 1853 – 29 July 1890) was a major ... Clearly " (listen)" shouldn't be there. Meanwhile Wikipedia Beta Android app and Google's Knowledge graph box remove everything in parentheses (how?) and show two sentences: Vincent Willem van Gogh was a major Post-Impressionist painter. He was a Dutch artist whose work had a far-reaching influence on 20th-century art. Wikipedia <http://en.wikipedia.org/wiki/Vincent_van_Gogh> But the Wikipedia Beta Android app's Share as image gives me: [image: Displaying Vincent_van_Gogh.jpg] (I filed https://phabricator.wikimedia.org/T102208 ). It looks like the mobile view service http://appservice.wmflabs.org/en.wikipedia.org/v1/mobile/app/page/lite/Vinc… also renders the full HTML, including the "listen" speaker icon. There's no single correct form for this snippet, it can't be decomposed into separate bits of JSON, and the pronunciation isn't cleanly nested in HTML for clients to easily remove the right parts of it. The mobile view service could have an ill-defined "Do the right thing" API, or implement a lot of named transform styles, or have some kind of domain-specific language 8-), or always returns structured Parsoid HTML that clients strip, or ?? Cheers, - - - - originals to end - - - - - On Jun 11, 2015 10:05 AM, "Dmitry Brant" <dbrant(a)wikimedia.org> wrote: > Yes, we should definitely do both, keeping in mind that the JSON-only > service will be much more important for apps in the long run. > The part that worries me a little bit is not knowing when exactly these > services can be deployed to production at full scale. Since so many of our > brainstorming ideas for Q1 and beyond are dependent on these services, we > should have a concrete time frame for this. > > The JSON service basically already exists[1] (in its infancy), and > experimenting with changes to the output JSON structure is absurdly easy. > I would suggest that we take an inventory[2] of all the non-text entities > that one might find in articles (infoboxes, tables, references, images, > math formulas, etc), and update the service to structure them as JSON. Then > we'll be free to decide how we want to present these entities natively in > the apps. > > In the case of entities existing within a paragraph, we can decide (with a > little help from Design) whether it's important to keep them inline with > the text, or strip and move them outside of the paragraph. For entities > that are important to keep inline, we can still strip them out and > restructure them as JSON, but also replace the inline occurrence with a > syntax marker that the apps will recognize, and decide how to handle > natively. > > Whether to preserve HTML formatting might also be a question for design / > UX research. However, at least on Android, the native TextView does support > some limited HTML tags, and we can do additional formatting with Spans if > necessary. > > > [1] > http://appservice.wmflabs.org/en.wikipedia.org/v1/mobile/app/page/lite/Womb… > [2] https://etherpad.wikimedia.org/p/json-content-service-structure > > > On Thu, Jun 11, 2015 at 11:28 AM, Corey Floyd <cfloyd(a)wikimedia.org> > wrote: > >> >> Mostly apps have been talking about this, but I think it would be good to >> get web folks involved as well. >> >> We have a lot of ideas, and this is at the top of the list for things we >> need to accomplish potential goals for the quarter. It also seems there >> are at least 2 ideas for how we should do this: >> >> 1. Deploy a service backed by Parsed that delivers better marked up HTML >> than mobile View. >> 2. Deploy a service that converts HTML to JSON and delivers that instead. >> >> My suggestion would be to do both… deliver better HTML first (this should >> be "easier"), then build another service upon that to serve JSON. >> >> The JSON spec for an article needs some discussion - but I think will be >> pretty easy to settle on. >> >> A couple of questions we will have solve: >> - Should text still be marked up in HTML? If not, what about formatting >> loss? >> - Entities like images that are between paragraphs are easy to handle, >> but what about entities within paragraphs? >> >> >> Any other thoughts here? >> >>

5 6

Google IO 15 notes
by Bernd Sitzmann 12 Jun '15

12 Jun '15

Here are some, mostly Android related, notes from Google IO this year: https://www.mediawiki.org/wiki/Notes_from_Google_I/O_15. If you are interested in Android or performance check it out. Cheers, Bernd

1 0

Strategy presentation
by Adam Baso 12 Jun '15

12 Jun '15

I realized I forgot to send this to mobile-l. Lila unveiled the *high level* organizational strategy draft. I encourage you to watch Metrics June 2015 <https://www.youtube.com/watch?v=skCBCYArUaA&feature=youtu.be>and review https://upload.wikimedia.org/wikipedia/commons/a/ab/WMF_Strategy_Preview%2C…. This is high level strategy, and as a department we will need to work out what our more detailed supporting strategy will be (in addition to factoring in our as-practiced current strategy), but it will help us to channel our efforts better.

1 0

[Apps] Android Wikipedia beta app release (2.0.103-beta-2015-06-11)
by Stephen Niedzielski 11 Jun '15

11 Jun '15

The Android team[1] is proud to announce a new Wikipedia Android app beta release, v2.0.103-beta-2015-06-11[2]. In summary, this revision contains the following enhancements[3]: * Enable link previews for even more users and improve design. * Improve page caching. Content is cached when possible but is always the latest available. * New! Enable "Search Wikipedia" when sharing text from other apps. * Fix text direction for mixed left-to-right and right-to-left languages. * Replace Chinese language options with Simplified and Traditional dialects. * Fix thumbnails in saved pages. * New! Use system language option. * Numerous translation updates. * Many minor fixes & improvements. [1] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team#Android_App [2] Rolling out at https://play.google.com/store/apps/details?id=org.wikipedia.beta [3] A complete list of changes is available at http://git.wikimedia.org/compare/apps%2Fandroid%2Fwikipedia/beta%2F2.0.102-… [4] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Wikipedia_Android_app_ha… Wanna do Android? Read our getting started guide[4]. We can't wait for your contributions!

1 0

iOS Beta 4.1.5 available for testing
by Corey Floyd 11 Jun '15

11 Jun '15

Hey everyone, we have a new iOS release in the hopper. If you are part of the beta channel, you can download the new version using Apple's TestFlight. If you would like to be in the beta, just email me, Brian or Monte to get access. Here are the highlights of this release: * Lead images now load faster and fade in smoothly * More article layout improvements * More reliable loading of articles from the cache * Added a link to the FAQ in Settings > More * Fix crash on startup for some device languages (Like Norwegian) * Several other crash fixes Also of note: this our last "scheduled" iOS 6 release. After release, this version will be available for download indefinitely for our users who are unable to upgrade to iOS 7. For users who are running iOS 7 or higher, this will allow us to support more great features in future versions of the iOS application. Thanks for testing and please send us any feedback you may have! -- Corey Floyd Software Engineer Mobile Apps / iOS Wikimedia Foundation

3 5

Audio/video updates: TimedMediaHandler, ogv.js, and mobile
by Brion Vibber 11 Jun '15

11 Jun '15

I've been passing the last few days feverishly working on audio/video stuff, cause it's been driving me nuts that it's not quite in working shape. TL;DR: Major fixes in the works for Android, Safari (iOS and Mac), and IE/Edge (Windows). Need testers and patch reviewers. *== ogv.js for Safari/IE/Edge ==* In recent versions of Safari, Internet Explorer, and Microsoft's upcoming Edge browser, there's still no default Ogg or WebM support *but* JavaScript has gotten fast enough to run an Ogg Theora/Vorbis decoder with CPU to spare for drawing and outputting sound in real time. The ogv.js decoder/player has been one of my fun projects for some time, and I think I'm finally happy with my TimedMediaHandler/MwEmbedPlayer integration patch <https://gerrit.wikimedia.org/r/#/c/165478/> for the desktop MediaWiki interface. I'll want to update it to work with Video.js later, but I'd love to get this version reviewed and deployed in the meantime. Please head over to https://ogvjs-testing.wmflabs.org/ in Safari 6.1+ or IE 10+ (or 'Project Spartan' on Windows 10 preview) and try it out! Particularly interested in cases where it doesn't work or messes up. *== Non-JavaScript fallback for iOS ==* I've found that Safari on iOS supports QuickTime movies with Motion-JPEG video and mu-law PCM audio <https://gerrit.wikimedia.org/r/#/c/217295/>. JPEG and PCM are, as it happens, old and not so much patented. \o/ As such this should work as a fallback for basic audio and video on older iPhones and iPads that can't run ogv.js well, or in web views in apps that use Apple's older web embedding APIs where JavaScript is slow (for example, Chrome for iOS). However these get really bad compression ratios, so to keep bandwidth down similar to the 360p Ogg and WebM versions I had to reduce quality and resolution significantly. Hold an iPhone at arm's length and it's maybe ok, but zoom full-screen on your iPad and you'll hate the giant blurry pixels! This should also provide a working basic audio/video experience in our Wikipedia iOS app, until such time as we integrate Ogg or WebM decoding natively into the app. Note that it seems tricky to bulk-run new transcodes on old files with TimedMediaHandler. I assume there's a convenient way to do it that I just haven't found in the extension maint scripts... *== In progress: mobile video fixes ==* Audio has worked on Android for a while -- the .ogg files show up in native <audio> elements and Just Work. But video has been often broken, with TimedMediaHandler's "popup transforms" reducing most video embeds into a thumbnail and a link to the original file -- which might play if WebM (not if Ogg Theora) but it might also be a 1080p original which you don't want to pull down on 3G! And neither audio nor video has worked on iOS. This patch <https://gerrit.wikimedia.org/r/#/c/217485/> adds a simple mobile target for TMH, which fixes the popup transforms to look better and actually work by loading up an embedded-size player with the appropriately playable transcodes (WebM, Ogg, and the MJPEG last-ditch fallback). ogv.js is used if available and necessary, for instance in iOS Safari when the CPU is fast enough. (Known to work only on 64-bit models.) *== Future: codec.js and WebM and OGVKit ==* For the future, I'm also working on extending ogv.js to support WebM <https://brionv.com/log/2015/06/07/im-in-ur-javascript-decoding-ur-webm/> for better quality (especially in high-motion scenes) -- once that stabilizes I'll rename the combined package codec.js. Performance of WebM is not yet good enough to deploy, and some features like seeking are still missing, but breaking out the codec modules means I can develop the codecs in parallel and keep the high-level player logic in common. Browser infrastructure improvements like SIMD, threading, and more GPU access should continue to make WebM decoding faster in the future as well. I'd also like to finish up my OGVKit package <https://github.com/brion/OGVKit> for iOS, so we can embed a basic audio/video player at full quality into the Wikipedia iOS app. This needs some more cleanup work still. Phew! Ok that's about it. -- brion

3 2

handling HTML in native apps
by Brian Gerstle 11 Jun '15

11 Jun '15

I've been thinking about our client-side strategy, and it just occurred to me that I should check out other open source projects. WordPress seems to be using DTCoreText <https://github.com/wordpress-mobile/WordPress-iOS/blob/develop/WordPress/Cl…> in their iOS app, which is a library for natively rendering HTML in text views (w/o UIWebView). The developer also has a great iOS blog <http://cocoanetics.com>. The closest thing I could find for Android is HtmlSpanner <http://nightwhistler.github.io/HtmlSpanner/>. Anyone have ideas for other projects or technologies to check out? Maybe we should talk to people at WordPress, as it seems their problem space is somewhat similar to ours (many installs, user-created content, custom styling, multiple platforms ...). Regards, Brian -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle

2 2

Some data on apps and web
by Adam Baso 11 Jun '15

11 Jun '15

Hi all, thought I'd share some data from a few queries around apps uniques and apps + web pageviews, etc. from recent history: https://www.mediawiki.org/wiki/Reading/2015-2016_Q1_Planning_Data We're at the beginning of our FY2015-2016 Q1 planning, and are also readying our thinking on Reading strategy for the longer haul, and I was hoping this may be of some use. -Adam

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l June 2015