Mobile-l

mobile-l@lists.wikimedia.org

4 participants
6884 discussions

Server side mustache templates in Gather
by Joaquin Oltra Hernandez 22 Jun '15

22 Jun '15

Hi friends, Recently we've merged in Gather a patch so that the extension uses precompiled templates ( Custom TemplateParser for MobileFrontend and Gather https://phabricator.wikimedia.org/T102941 ) because of a bug in HHVMs closure creation ( https://phabricator.wikimedia.org/T102937 ). Once hhvm is patched and running everywhere we feel like it is safer to keep precompiled templates on Gather since the extension makes fair use of templates sharing them between the server and js client code. If you are developing or plan to develop patches for the Gather extension be sure to include $wgGatherRecompileTemplate = true in LocalSettings.php or equivalent during development. That way templates will be recompiled and written to disk every time you visit the page that renders them, so that you can submit them with your patches. We'll keep an eye on the tracking bug and remove this when it is safe (it is a bit cumbersome, but the best solution considering the tradeoffs right now). I've updated the Extension:Gather page and added the information ( https://www.mediawiki.org/wiki/Extension:Gather#Development). Cheers.

1 0

WebM/Ogg playback: testing energy usage on iOS
by Brion Vibber 19 Jun '15

19 Jun '15

One of the reasons we've always worried about using the open Ogg and WebM formats on iPhones and iPads is that we don't get to make use of the hardware MP4/H.264 codec... using the main CPU cores is presumed to drain the battery faster. I've done a first-pass test measuring energy usage of native-code WebM/Ogg playback using the new energy reporting in the Xcode 7 / iOS 9 beta: https://brionv.com/log/2015/06/19/webm-and-ogg-energy-usage-on-ios-9-beta-w… The good news is that playback of buffered data at my target resolutions (360p for 32-bit, 720p for 64-bit) is barely under the "Low" mark on the energy drain meter! :D The bad news is that H.264 playback with the native widget reports post-buffer-download energy drain even lower, at the "Zero" mark... if you can believe that! (In both cases, reported drain is significantly higher during network download, at least on my fast wifi.) But "Low" sounds pretty good... If folks would like to see more concrete measures, I can rig up my test to run continuously until the battery runs out and time it. -- brion

3 3

maps w/ nearby
by Brian Gerstle 18 Jun '15

18 Jun '15

The hackathon and a recent comment on a great GitHub pull request <https://github.com/wikimedia/apps-ios-wikipedia/pull/3> (which we received almost a year ago) have gotten me thinking about maps. Did we ever find a maps provider? Regards, Brian -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle

8 12

Who is responsible for the Wiktionary app?
by Florian Schmidt 18 Jun '15

18 Jun '15

Hi all, especially mobile apps people ;) Recently we got a support request on our Android mobile OTRS queue[1] with the question, if the Wiktionary App[2] receives any updates in the future (like the Wikipedia app, or at least "some" updates). I looked into Phabricator and found these projects: https://phabricator.wikimedia.org/tag/wiktionary/ -> seems to be for the website only https://phabricator.wikimedia.org/tag/unofficial-apps-wiktionary-android/ -> seems to be for the app, but the "unofficial" confuses me :/ See the open tasks, too: https://phabricator.wikimedia.org/maniphest/?statuses=open() <https://phabricator.wikimedia.org/maniphest/?statuses=open()&projects=PHID- PROJ-6ydvnqng4lo7a2ijzt3n#R> &projects=PHID-PROJ-6ydvnqng4lo7a2ijzt3n#R Which could indicate, that the app isn't really supported. So, the question is: Is Mobile apps responsible for bug fixing and feature requests (or, e.g., digging through the feedback on Google Play?) or is this project likely abandoned? If so, we probably should add a notice to the app description in Google Play, so that our users know, that they don't get any updates anymore (which doesn't mean, that we should remove the app ;)). Thanks for your answer! Best, Florian [1] https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom <https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom&TicketID= 8435107#> &TicketID=8435107# [2] https://play.google.com/store/apps/details?id=org.wiktionary

5 7

[Update] Browser tests per patch
by Jon Robson 18 Jun '15

18 Jun '15

Background: mobile wants to gain more confidence in its browser tests by running a subset of browser tests on a case by case basis [0]. Good news: I've got a proof of concept running and Barry the browser test bot has given some legitimate helpful reviews to Gather [1]. Even better news: It's proving itself valuable already [2]. As you can see in the messages the bot has posted on [3] we have a couple of options on display option format for his reviews. So.. hopefully this short experience has sold you all already. This script is currently a manual job and needs a bit of tweaking before we can put it in a cron job/run it always - it needs to watch for new commits and then run a modification of the above script on a per case basis (if two versions of it run in parallel we have an issue). Definitely something we should push for next sprint! Long live Barry bot! Devs... (everyone else now of what follows is likely to be useful): I got the labs instance up and running on: http://gather-browser-tests.wmflabs.org/wiki/Main_Page Most of you in readership team should be able to ssh gather-browser-tests.eqiad.wmflabs Let me know if you have no access. It's currently working via a script that you can find here: /srv/mediawiki/extensions/Gather/tests/browser/Barry.sh [0] https://phabricator.wikimedia.org/T100293 [1] https://gerrit.wikimedia.org/r/#/q/reviewer:jdlrobson%252Bbarry%2540gmail.c… [2] https://gerrit.wikimedia.org/r/#/c/218731/

1 0

Re: [WikimediaMobile] [reading-wmf] [Web] Reverting commits
by Adam Baso 16 Jun '15

16 Jun '15

Moving to mobile-l. On Friday, June 12, 2015, Sam Smith <samsmith(a)wikimedia.org> wrote: > Hey web slingers, > > If there is a regression introduced by a patch, then please revert that > patch as soon as you've identified it and let the team know via > Phabricator, email, or both. Reverting the commit will often be cheaper to > do than fixing the regression in a follow-on patch, but there'll > undoubtedly be exceptions, which we'll deal with (and learn from) as a team. > > Fixing the regression in a follow-on patch means that: > > - *master won't be deployable* until the patch has been reviewed, > tested, and merged, which should be communicated to the Release Engineering > team > - reviewers might have to drop what they're working on in order to get > it reviewed > - what if the original patch was lower priority? > - we should be cognisant of the cost of context switching > - the commit history will be dirty > > *Master should always be depoyable.* > > –Sam >

4 3

Wikigrok code no longer being worked on
by Jon Katz 16 Jun '15

16 Jun '15

Hi, *TLDR:* Wikigrok proved that readers are interested in and capable of making casual, mobile contributions to Wikipedia. We are putting continued development of the 'Wikigrok' casual contribution feature on hold until we have a plan for optimally harnessing this interest/capability. *Background* Given the growth of mobile traffic on wikipedia and the challenges inherent to traditional editing on a mobile device, Wikigrok was proposed as a way to test if regular wikipedia readers would be interested in making smaller, more casual contributions to wikimedia projects while reading Wikipedia on a mobile device. *Results* By early 2015, the results were in: readers were relatively interested in engaging with the feature[1]. Some oft-quoted comparisons include: - 3x the number of unique responders as mobile editors during test period (4.5K editors, 12.3K WikiGrokkers), even with WG on sample of articles & users - 1.5x better clickthrough than 2014 Fundraising full-screen mobile banner (I actually do not have references for these, as they are borrowed quotes) Furthermore, we found that the quality of responses was rather high [2,3]. *Future* The original thought was to use these responses to fill in gaps in Wikidata and our initial test results (2 weeks worth) were successfully ported over in late April [4]. However, in order to production-ize the system, we would have to: 1. scale and develop queries against the new wikidata query service 2. create an article parser to identify potential multiple choice answers for each question 3. create a system for attributing aggregated results to the specific contributors (per Wikidata bot request discussion[5]) None of these are unsurpassable, but we have learned a great deal and, at this stage, we believe that further effort should be devoted to evaluating areas of need and fit before we commit additional efforts to specifically porting information into Wikidata. Please feel free to reach out if you have any questions or concerns about this decision. Best, Jon [1] https://meta.wikimedia.org/wiki/Research:WikiGrok/Test2 [2] Quality of responses, version A: https://www.wikidata.org/wiki/File:All_Campagins,_Scatterplot,_version_(a).… [3] Quality of responses, version B: https://www.wikidata.org/wiki/File:All_Campaigns,_Scatterplot,_version_(b).… [4] *https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500 <https://www.wikidata.org/wiki/Special:Contributions/WikiGrok?limit=500>* [5] https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/WikiGrok

7 10

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l