Mobile-l June 2016

mobile-l@lists.wikimedia.org

16 participants
19 discussions

[Apps] Stripping content inside brackets from the first sentence of articles
by Dan Garry 07 Oct '19

07 Oct '19

Hi everyone, *tl;dr: We'll be stripping all content contained inside brackets from the first sentence of articles in the Wikipedia app.* The Mobile Apps Team is focussed on making the app a beautiful and engaging reader experience, and trying to support use cases like wanting to look something up quickly to find what it is. Unfortunately, there are several aspects of Wikipedia at present that are actively detrimental to that goal. One example of this are the lead sentences. As mentioned in the other thread on this matter <https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008715.html>, lead sentences are poorly formatted and contain information that is detrimental to quickly looking up a topic. The team did a quick audit <https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BJ7uDgzO8IJT0M3UM2q…> of the information available inside brackets in the first sentences, and typically it is pronunciation information which is probably better placed in the infobox rather than breaking up the first sentence. The other problem is that this information was typically inserted and previewed on a platform where space is not at a premium, and that calculation is different on mobile devices. In order to better serve the quick lookup use case, the team has reached the decision to strip anything inside brackets in the first sentence of articles in the Wikipedia app. Stripping content is not a decision to be made lightly. People took the time to write it, and that should be respected. We realise this is controversial. That said, it's the opinion of the team that the problem is pretty clear: this content is not optimised for users quickly looking things up on mobile devices at all, and will take a long time to solve through alternative means. A quicker solution is required. The screenshots below are mockups of the before and after of the change. These are not final, I just put them together quickly to illustrate what I'm talking about. - Before: http://i.imgur.com/VwKerbv.jpg - After: http://i.imgur.com/2A5PLmy.jpg If you have any questions, let me know. Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

13 22

Results from similar articles A/B test
by Dmitry Brant 04 May '17

04 May '17

Hello all, As mentioned previously, the current version of the Android app contains an A/B test where it presents "read more" suggestions to the user, based on (a) the standard "morelike" query, or (b) the new "opening_text" query. Here are the results from the last ~10 days of the test[0]: - The clickthrough rate using the default morelike query is (and has been) around 15%. - With the new opening_text query, the clickthrough rate decreases to about 12%: [image: Inline image 1] Therefore, it seems that the new query has a nontrivial negative effect on CTR :( We'll plan on removing this test in the next release of the app, but we'll be happy to plug in a different or updated query, if it will be of further use to Discovery. [0] https://docs.google.com/a/wikimedia.org/spreadsheets/d/1BFsrAcPgexQyNVemmJ3… (queries embedded as comments in the headers) -- Dmitry Brant Senior Software Engineer / Product Owner (Android) Wikimedia Foundation https://www.mediawiki.org/wiki/Wikimedia_mobile_engineering

4 3

Comparison of collapsed vs. expanded section view on mobile web
by Tilman Bayer 05 Jul '16

05 Jul '16

Hi, as most on this list will be aware, on the mobile web version of Wikipedia, all top-level sections below the lead section are currently shown collapsed on initial view. Users can tap on a section heading to show the content, and to collapse it again. To examine the tradeoffs of this solution and inform future product decisions, we ran an experiment where 0.05% of mobile web users were shown all pages with every section expanded on initial load, instrumented alongside a control group of 0.05% that kept seeing the standard view where all sections all initially collapsed. A high-level summary of results is now available at https://meta.wikimedia.org/wiki/Research:Collapsed_vs_uncollapsed_section_v… . In particular: * Readers in the test group (sections expanded) tend to stay longer on the page * Readers in the test group tend to spend more time reading, and less time navigating * Readers in the test group tend to scroll more sections into view than readers in the control group open * Readers in the test group tend to stay shorter on the page than readers using the Android Wikipedia app (which offers a TOC for easier navigation, something not yet available in the mobile web test group) Comments and questions are welcome, feel free to use the talk page for them too. Note that this experiment only measured some aspects, and that the results don't yet allow the unambiguous conclusion that it would be better to switch to the uncollapsed view. That said, they certainly suggest that such a change should be considered. It is being planned to examine this question further with some user testing sessions. (As an experiment, I've taken the opportunity to write this up this analysis as a page in the research namespace on Meta, instead of on Phabricator or in form of an email as done on other occasions. Feedback on the format is welcome too.) -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB

4 5

Scaling with Edge Caching at Wikimedia
by Adam Baso 30 Jun '16

30 Jun '16

WMF's Emanuele Rocca talks at VarnishCon about how we scale to hundreds of millions of users: https://www.infoq.com/fr/presentations/varnishcon-emanuele-rocca-scaling-wi… Enjoy! -Adam

2 1

Client-server request-response contract meeting minutes
by Stephen Niedzielski 30 Jun '16

30 Jun '16

*Action items:* - Audit any assumptions apps make about contents of HTML returned by API and make tickets for tests [*Jon Robson*] - Make sure all edge cases are covered e.g. What if srcset is not present? What if there are no img and the figure tag is being used? - Rely less on HTML wherever possible - explore if it would make more sense to pull out metadata in API responses - Capture in a task for Reading Web team to write a MobileFrontend test to protect app requirements - Write new tests for MobileFrontend (wherever they make most sense) to make sure they cover what is needed by iOS and Android and they need to be triggered by MobileFrontend commits - Could add some MCS tests for HTML content - Look into hooking up Jenkins Android / iOS to the mobile front end tests so that MobileFrontend merges are blocked when they break things in apps [*Corey Floyd + Michael Holloway*] - Explore if TemplateData could be used by Apps for replacing editor created template constructs e.g. infobox - Look at testing apps against beta cluster [*Monte Hurd*] - Android / iOS should try to get CSS / JavaScript into MobileFrontend more rather than changing it on the client [T137992 <https://phabricator.wikimedia.org/T137992>] *Copy and paste of Etherpad <https://etherpad.wikimedia.org/p/Client-server> for posterity:* Agenda 9:00-9.15: What happened. Let's get a shared understanding of the problem hit. Demo would be useful here if this can be arranged. 9:15-9.40: How could this have been avoided? What APIs would have made it better? 9:40-10:00: Actions/story writing. >From Google invite: - "I think this is something we should probably discus more next week - probably as a separate meeting. It would be good to talk about the strategies we use in the apps to get the content and what we can do to improve them. This is also very relevant for the content service." - - I've marked some as mandatory and some as optional, but I don't think it would hurt to join and even just listen passively even if you're optional, especially if you have an interest. - - The removal of srcset led to some breakage in the iOS app's galleries. - Notes: App clients have two different calls: Meta data: search, something powering the feed Content: HTML <-- This is where the issue is. HTML content: - HTML is valid but... We extract somethings (with selector queries) to do things natively. This is kind of hacky generally because content is tough and variable. For example, table of contents (the sections themselves are parsed out server side...? it's pulled down and seperated). Any changes to the structure of this HTML can break things. - Content Service does this kind of thing too but at least the output is from Parsoid. - Web does very little with HTML content. The stuff we do is very minimal. Somethings get stripped out but generally considered small. - More tests would be nice for content specifically. For instance, if you clients are expected a src set, then write a test for that. - iOS added a test for srcset. Content Service has lots of content tests. - It's tricky for native apps since the tests are written in a different environment than the other app tests? Just need to make sure the HTML isn't messed up. - MobileFrontend has some Jenkins automated tests. Probably could use some fleshing out to make sure they cover whatever the apps need. This won't be super simple. - Can we move some of the Android screenshot tests to Mobile Frontend somehow? - testwiki gets code drops on tuesdays - beta cluster (en[.m].wikipedia.beta.wmflabs.org) gets whatever's merged to master like within 30 minutes of merge - Action items: Audit any assumptions apps makes about contents of HTML returned by API and make tickets for tests [JR] - Make sure all edge cases are covered e.g. What if srcset is not present? What if there are no img and the figure tag is being used? - Rely less on HTML wherever possible - explore if it would make more sense to pull out metadata in API responses - Capture in a task for Reading Web team to write a MobileFrontend test to protect app requirements - Write new tests for MobileFrontend (wherever they make most sense) to make sure they cover what is needed by iOS and Android and they need to be triggered by MobileFrontend commits - Content Service is used by Android and already has a lot of tests, remaining tests are integration level screenshot tests - Could add some MCS test for HTML content - Look into hooking up Jenkins Android / iOS to the mobile front end tests so that MobileFrontend merges are blocked when they break things in apps [CF + MHolloway] Explore if TemplateData could be used by Apps for replacing editor created template constructs e.g. infobox Look at testing apps against beta [MHurd] Android / iOS should try to get CSS / JavaScript into MobileFrontend more rather than changing it on the client [ https://phabricator.wikimedia.org/T137992]

4 3

mobile-l:招用待岗、内退、停薪留职的人员，应注意哪些细节问题？
by mp 29 Jun '16

29 Jun '16

mobile-l: 您好 1.如何预防劳动者的“应聘欺诈”，如何证明劳动者的“欺诈”？ 2.招收应届毕业生，应注意哪些细节问题？ 3.招用达到法定退休年龄的人员，应注意哪些细节问题？ 4.招用待岗、内退、停薪留职的人员，应注意哪些细节问题？ 5.入职体检需注意哪些细节问题？ 6.入职前后用人单位应告知劳动者哪些情况，如何保留证据？ 7.《入职登记表》如何设计，才能起到预防法律风险的作用？ 8.劳动者无法提交《离职证明》，该怎么办？ 9.企业如何书写《录用通知书》，其法律风险有哪些？附件中的内容希望能帮助到您的工作。。。床前明月光，疑是地上霜。 2016-6-2915:39:16 闽念阳

1 0

Wikipedia for iOS v5.0.5 beta 4 -- help test
by Joshua Minor 29 Jun '16

29 Jun '16

Hello, As previously posted on list, the WMF's iOS app team has been focused on improving the performance and stability of the app with our next update[1]. We've made huge improvements under the hood with this version, and we're optimistic users will see faster article loading and less crashes. But we still need your help! If you are a registered beta tester,* please update to the latest version available on TestFlight now. *Particularly if you use: - A device with iOS 8 - An iPad - An older device ...or if you have experienced crashes in recent versions. We've added a specialized reporting mechanism to help us investigate a particularly thorny issue. *If the app encounters this issue it will pop up an email pre-filled out with diagnostic information. This report is specific to this issue and provides us logging beyond our normal crash reporting. If this email pops up for you while using the app, please hit send.* It will be very very helpful in diagnosing and resolving any remaining issues. If you are not a tester but would like to get on board and help (please!), please sign up here: https://docs.google.com/forms/d/19flzJ3lObZLfN5gKv69BZWkeouH7Vuznykk6q-O6xR… Thanks again for your help, Josh Minor Product Manger, Wikipedia for iOS [1] https://lists.wikimedia.org/pipermail/mobile-l/2016-June/010254.html

1 0

[Mobile][Engineering] Java 8 now required to build the Android app
by Michael Holloway 24 Jun '16

24 Jun '16

Dear Mobile Wikimedians, The Android app recently upgraded to the latest version (24.0.0) of the Android support library, which requires Java 8 in order to build. Accordingly, Java 8 is now required to build the Android app. As of about an hour ago, our CI jobs have moved from using Java 7 to Java 8. Details are here: https://phabricator.wikimedia.org/T138506 Big thanks to @hashar for making the CI change! Warmly, Michael

1 0

[NEW] Offline Phet Interfactive Simulations
by Emmanuel Engelhart 23 Jun '16

23 Jun '16

Hi I'm happy to announce that during our Kiwix hackathon @Wikimania Esino Lario, we have achieved to build an offline version of the famous "PhET Interactive Simulations for Science and Math": https://phet.colorado.edu/ This is of course available in the ZIM format at this URL: http://download.kiwix.org/zim/phet_en_all.zim We will release monthly updates integrating that way the last published new PhET simulations. In addition, we have also released and will maintained a dedicated Android app on the Google Play store, making its usage even easier: https://play.google.com/store/apps/details?id=org.kiwix.kiwixcustomphet All the source code is available in Kiwix source code repository at https://github.com/kiwix/phet and the next version is already in the pipeline. Git it a try! Regards Emmanuel -- Kiwix - Wikipedia Offline & more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication

1 0

Update: Upload to Commons Android app
by Josephine Lim 23 Jun '16

23 Jun '16

Hi all, A quick update re: the Upload to Commons Android app: - We are now considered an 'official' app and have been granted permission by WMF to use the Wikimedia Commons logo and name. As such, the app is now named "Wikimedia Commons" < https://play.google.com/store/apps/details?id=fr.free.nrw.commons> instead of "Upload to Commons", and its icon has been changed to the Commons logo. Ownership of the app should also soon be transferred to the WMF Google Play account. On a practical basis, there should be no change in the use of the app and it will still be maintained by volunteers. - I am happy to announce that my IEG proposal for further work on the app < https://meta.wikimedia.org/wiki/Grants:IEG/Improve_%27Upload_to_Commons%27_…> has been selected. :) I will be starting work on it shortly, so there will be regular releases planned for the next 6 months. Bug/crash reports and feedback are welcome on our Google Groups forums < https://groups.google.com/forum/#!forum/commons-app-android> and GitHub page <https://github.com/nicolas-raoul/apps-android-commons/issues> as always. Have a great day! Cheers, Josephine

5 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l June 2016