Mobile-l February 2016

mobile-l@lists.wikimedia.org

34 participants
25 discussions

[Apps] Stripping content inside brackets from the first sentence of articles

by Dan Garry

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

4 years, 6 months

Results from similar articles A/B test

by Dmitry Brant

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

6 years, 11 months

Usability of the mobile web site

by Ori Livneh

So, with mobile usage creeping up to and even exceeding desktop, I figured I was overdue for switching over to the mobile skin, so I get to know it a bit better. I think it looks very attractive and modern. But it is marred by a usability issue so severe that it is borderline unusable to me, and that is the manner in which the content jumps around as the page is loading. The problem is that sections are initially loaded in an expanded state, and then collapsed by JavaScript code which is only executed on document ready. This code also pulls in interface elements that are drawn quite late. Even on a fast connection, a quick reader can be halfway through reading a paragraph when all of a sudden the content suddenly and rudely shifts to side or is revoked entirely. The result is very dizzying and unpleasant. As a result, I find that I have to train myself *not* to start reading the text in front of me until the page has settled down. I don't think that this is good performance. It may get something to render sooner than it otherwise would have, but it ends up delaying the time it takes for the page to settle into its fully-loaded layout, which forces the user to wait longer (or tolerate the electric jolt of having the content skip around mid-sentence). Roan filed this as https://phabricator.wikimedia.org/T126825 . I set its priority to "high", and I hope this e-mail gives some context as to why.

8 years, 1 month

[offtopic] interesting read on Android app architecture

by Brian Gerstle

And general architecture: http://devblog.songkick.com/2016/02/25/ingredients-for-a-healthy-android-co… Post links to a presentation as well. Their approach is following some best practices I also strongly agree with, and they're using frameworks I would probably look to use (Dagger & RxJava). -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle

8 years, 1 month

Re: [WikimediaMobile] [Analytics-internal] Pageview API used in iOS app beta

by Nuria Ruiz

Joshua, This is awesome. Now, let's make sure we are not running into throttling limits. Could we get an estimate of the number of requests we expect from the apps? Given that we have about 400.000 daily uniques in IOS daily we would expect about 5 requests per second coming from the app IF traffic is widespread through the day and app is doing 1 request per day. If traffic concentrates in some hours request ratio might be higher We would also like to double check that caching headers are respected in the app and requests are not retried if they are mean to be cached. Can developers confirm this is the case? Thanks, Nuria

8 years, 2 months

by Erik Bernhardson

Both mobile apps and web are using CirrusSearch's morelike: feature which is showing some performance issues on our end. We would like to make a performance optimization to it, but before we would prefer to run an A/B test to see if the results are still "about as good" as they are currently. The optimization is basically: Currently more like this takes the entire article into account, we would like to change this to take only the opening text of an article into account. This should reduce the amount of work we have to do on the backend saving both server load and latency the user sees running the query. This can be triggered by adding these two query parameters to the search api request that is being performed: cirrusMltUseFields=yes&cirrusMltFields=opening_text The API will give a warning that these parameters do not exist, but they are safe to ignore. Would any of you be willing to run this test? We would basically want to look at user perceived latency along with click through rates for the current default setup along with the restricted setup using only opening_text. Erik B.

8 years, 2 months

[RELEASE] Kiwix for Android 1.97

by Emmanuel Engelhart

Hi The Kiwix dev. team is happy to announce the version 1.97 of Kiwix for Android. Most of this release was coded by Google Code-in student mhutti1, big thanks to him. This release brings a few improvements: * FIXED: Soft-keyboard opens on "find in page" click * FIXED: "Back to Top" button fades out after 1.5 seconds * NEW: App can be moved to SD card * NEW: ARM64 support * NEW: Beta full-text search (put the *.idx" directory beside the ZIM) * NEW: Restart with last open article on exact same position * NEW: Click on app title displays the search input box * NEW: Remember fullscreen setting over app restarts * NEW: Few additional languages supported for the UI * NEW: Build against newer version of Android NDK/SDK Kiwix for Android 1.97 is available on multiple app stores like: * Google Play: https://play.google.com/store/apps/details?id=org.kiwix.kiwixmobile * Aptoid: http://www.aptoide.com/search/view/apps?search=org.kiwix.kiwixmobile&x=0&y=0 * F-Droid: https://f-droid.org/repository/browse/?fdfilter=kiwix&fdid=org.kiwix.kiwixm… ... but also via direct download (interesting for people wanting old APK versions) at http://download.kiwix.org/bin/android/ Regards Emmanuel -- Kiwix - Wikipedia Offline & more * Web: http://www.kiwix.org * Twitter: https://twitter.com/KiwixOffline * more: http://www.kiwix.org/wiki/Communication

8 years, 2 months

Re: [WikimediaMobile] Android app now requires "run at startup" permission?

by Florian Schmidt

Hi Legoktm, as far as I know the permission is in the custom build flavor only (it was moved from the main build channel to it in commit[1]). I'm not sure, what flavor is used for fdroid, it's using the custom channel, it get's the permission (added in [2]). [1] https://github.com/wikimedia/apps-android-wikipedia/commit/2b18cea8108b074d… [2] https://github.com/wikimedia/apps-android-wikipedia/commit/026b8ed03996d068… Best, Florian -----Original-Nachricht----- Betreff: [WikimediaMobile] Android app now requires "run at startup" permission? Datum: 2016-02-19T08:29:44+0100 Von: "Legoktm" <legoktm.wikipedia(a)gmail.com> An: "mobile-l" <mobile-l(a)lists.wikimedia.org> Hi, When I upgrade from 2.1.137-fdroid to 2.1.141-fdroid (I fell a little behind in staying up to date), the Android Wikipedia app requests the "run at startup" permission. Is this intentional? Why does the app need to run at startup? Thanks, -- Legoktm _______________________________________________ Mobile-l mailing list Mobile-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l

8 years, 2 months

Wikipedia Mobile v5 for iOS - Last chance to beta test...

by Joshua Minor

Hello mobile wikimedians, In late December the Foundation's iOS team announced[1] a public beta of a major overhaul[2] of the iOS Wikipedia app. Today we delivered what we hope will be a final beta before launch, and are primarily in bug fix and visual touches mode. If you would like to participate as a beta tester, it is NOT TOO LATE. Please sign-up here if interested: https://docs.google.com/forms/d/19flzJ3lObZLfN5gKv69BZWkeouH7Vuznykk6q-O6xR… If you have tried a previous beta (thanks), now would be a great time to update to the latest version. And last but not least, if you have feedback you can provide it via this form: https://docs.google.com/forms/d/1NDBPJvWZ0idh9OuQ8pt684c9MwitOHQGsFvXTO4tcs… In our IRC channel on freenode at #wikimedia-ios or on our project talk page[3] Or just send me an email! Thanks to all the code contributors, bug filers, testers and anyone who's helped make the app better. Prior to release I will send more info to this list about the feedback we've received that we were not able to act on, and future features and improvements based on that feedback. Thanks, Josh [1] https://lists.wikimedia.org/pipermail/mobile-l/2015-December/010011.html [2] https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Why_5 [3] https://www.mediawiki.org/wiki/Talk:Wikimedia_Apps/Team/Why_5

8 years, 2 months

Readership metrics for the two months until February 7, 2016

by Tilman Bayer

Hi all, this resumes the usual look at our most important readership metrics. Among other things, this time we observe the annual Christmas slump in pageviews, hail the advent of the mobile singularity (December saw the first ever day with >50% mobile pageviews), and resolve the mystery of the Android app’s installation drop since mid November. As laid out earlier <https://lists.wikimedia.org/pipermail/mobile-l/2015-September/009773.html>, the main purpose is to raise awareness about how these are developing, call out the impact of any unusual events in the preceding week, and facilitate thinking about core metrics in general. We are still iterating on the presentation; feedback and discussion welcome. After switching away from the weekly schedule (week-over-week and month-over-month changes are now being recorded on the Product page <https://www.mediawiki.org/wiki/Wikimedia_Product#Reading> at MediaWiki.org) we also skipped an issue and added one week, so this edition of the report covers a timespan of nine weeks. See also the slides from the Reading team’s quarter review meeting <https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter…> on January 20 for an in-depth look at various metrics. Now to the usual data. (All numbers below are averages for December 7, 2015 to February 7, 2016 unless otherwise noted.) Pageviews Total: 529 million/day Context (April 2015-February 2016): (see also the Vital Signs dashboard <https://vital-signs.wmflabs.org/#projects=all/metrics=Pageviews>) Total pageviews saw a sharp drop about a week before Christmas (almost entirely on desktop), coinciding with a drop <http://discovery.wmflabs.org/external/#traffic_by_engine> in Google referrals. But both recovered in early January, even rising above earlier levels, thanks to mobile (cf. below). Historical data from one and two years ago shows a very similar slump in total and desktop pageviews in the second half of December (with a lasting increase in mobile around Christmas, too), so I’m interpreting this as seasonal even though it preceded the actual holidays by a few days. In January 2014, traffic did not fully recover to the levels of November/early December. In January 2015, it rose slightly above them, similar to now. Desktop: 54.3% Mobile web: 44.4% Apps: 1.3% Context (April 2015-February 2016): December 20, 2015 will forever be engraved in Wikimedia history as the first day where mobile pageviews surpassed desktop pageviews (51% vs. 49%). It was a Sunday - as we have known for a long time, mobile usage is higher on weekends. In general, the mobile percentage over a whole week still remains well below 50%. But even as desktop pageviews recovered from the Christmas slump at the beginning of January, the mobile percentage remains roughly 2% higher than before mid-December - quite likely due to a lot of new phones entering usage as Christmas presents. Global North ratio: 78.3% of total pageviews Context (April 2015-February 2016): New app installations Android: 38.4k/day Daily installs per device, from Google Play Context (January 2015-February 2016): As reported earlier, the app was featured twice on Google Play in recent months, and we can now estimate how many additional installs each may have caused. November’s placement in the “new and updated” section appears to have brought in more than 200k installs, and from early December to early January, the apps was featured as one of the “Best Apps of 2015” in many countries, resulting in around 350k additional installs. The preceding reports also described how we noticed a sharp drop in the new install rate around November 12, and started investigating the cause with our contact at Google. After some detective work, it turned out that the app had been benefitting (since April) from a new feature <https://googlewebmastercentral.blogspot.com/2015/04/drive-app-installs-thro…> in Google Search showing install buttons for a website’s app next to search results from that site for general search terms. Google ended this experiment in November, causing the app’s baseline install rate to drop significantly (coincidentally around the end of the “new and updated” promotion). Going forward, this means that the ongoing growth rate (installs minus uninstalls) remains much lower than it was during most of 2015. iOS: 4.94k/day Download numbers from App Annie Context (last three months): Like for the Android app, there was a notable bump around Christmas, but also an even larger spike on January 14 - the reason is not clear to us. App user retention Android: 16.8% (Ratio of app installs opened again 7 days after installation, among all installed during the previous week. 1:100 sample) Context (last four months): Retention for installations since around Christmas appears to be higher; but the data is quite noisy. iOS: N/A (Ratio of app installs opened again 7 days after installation, among all installed during the previous week. From iTunes Connect, opt-in only = ca. 20-30% of all users) As reported earlier, we encountered data quality issues with this metric. We eventually received an explanation from Apple last week, but it doesn’t look very satisfactory for our purposes. We are now working <https://phabricator.wikimedia.org/T126693> to measure retention ourselves via EventLogging, like we do on Android. Unique app users Android: 1.206 million / day Context (last four months): A clearly visible and lasting increase around Christmas, which again indicates that the retention rates for the install peak around that time were higher than during the install peaks caused by the Google Play promotions (even though they resulted in more installs initially). iOS: 303 k / day Context (last four months): Similar to Android, a clearly visible and lasting increase around Christmas. ---- For reference, the queries and source links used are listed below (access is needed for each). Unless otherwise noted, all content of this report is © Wikimedia Foundation and released under the CC BY-SA 3.0 <https://creativecommons.org/licenses/by-sa/3.0/> license. Most of the above charts are available on Commons, too <https://commons.wikimedia.org/w/index.php?title=Special:ListFiles&offset=20…> . hive (wmf)> SELECT SUM(view_count)/(7000000*9) AS avg_daily_views_millions FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-12-07" AND "2016-02-07"; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, sum(IF(access_method <> 'desktop', view_count, null)) AS mobileviews, SUM(view_count) AS allviews FROM wmf.projectview_hourly WHERE year > 0 AND agent_type = 'user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; hive (wmf)> SELECT access_method, SUM(view_count)/7 FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-12-07" AND "2016-02-07" GROUP BY access_method; hive (wmf)> SELECT SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0))/SUM(view_count) FROM wmf.projectview_hourly WHERE agent_type = 'user' AND CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) BETWEEN "2015-12-07" AND "2016-02-07"; hive (wmf)> SELECT year, month, day, CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")), SUM(view_count) AS all, SUM(IF (FIND_IN_SET(country_code, 'AD,AL,AT,AX,BA,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FO,FR,FX,GB,GG,GI,GL,GR,HR,HU,IE,IL,IM,IS,IT,JE,LI,LU,LV,MC,MD,ME,MK,MT,NL,NO,PL,PT,RO,RS,RU,SE,SI,SJ,SK,SM,TR,VA,AU,CA,HK,MO,NZ,JP,SG,KR,TW,US') > 0, view_count, 0)) AS Global_North_views FROM wmf.projectview_hourly WHERE year > 0 AND agent_type='user' GROUP BY year, month, day ORDER BY year, month, day LIMIT 1000; https://console.developers.google.com/storage/browser/pubsite_prod_rev_0281… (“overview”) https://www.appannie.com/dashboard/252257/item/324715238/downloads/?breakdo… (select “Total”) SELECT LEFT(timestamp, 8) AS date, SUM(IF(event_appInstallAgeDays = 0, 1, 0)) AS day0_active, SUM(IF(event_appInstallAgeDays = 7, 1, 0)) AS day7_active FROM log.MobileWikiAppDailyStats_12637385 WHERE userAgent LIKE '%-r-%' AND userAgent NOT LIKE '%Googlebot%' GROUP BY date ORDER BY DATE; (with the retention rate calculated as day7_active divided by day0_active from seven days earlier, of course) https://analytics.itunes.apple.com/#/retention?app=324715238 hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS Android_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'Android'; hive (wmf)> SELECT CONCAT(year,"-",LPAD(month,2,"0"),"-",LPAD(day,2,"0")) as date, unique_count AS iOS_DAU FROM wmf.mobile_apps_uniques_daily WHERE platform = 'iOS'; -- Tilman Bayer Senior Analyst Wikimedia Foundation IRC (Freenode): HaeB

8 years, 2 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l February 2016