Mobile-l December 2014

mobile-l@lists.wikimedia.org

32 participants
27 discussions

[Apps] Q3 focus: improving our recent MVPs
by Dan Garry 15 Dec '14

15 Dec '14

Hi everyone, *tl;dr: The Mobile Apps Team will focus on rounding out and improving the MVPs we're shipping soon, and looking at a lightweight onboarding framework. A more concrete agenda and goals will come out of our quarterly planning sessions in January.* Last Friday, the Mobile Apps Team used its normal sprint planning session to instead discuss what we want to work on in Q3 (Jan-Mar 2014). On Android, if you look at what we've shipped to production, or are expecting to shipping to production at the very start of Q3, we have: - Nearby - Search improvements MVP - Lead images MVP - Image viewer MVP - Read more MVP - Tweet a fact MVP You may notice a pattern in the above. These features all have known things that were cut as part of the process of defining the MVP; lead images doesn't work in landscape mode, image viewer has no share/gallery functionality, tweet a fact is undiscoverable, and so on. The team has decided to focus on rounding out these MVPs into more holistic, fully-fledged features at the start of the quarter rather than moving on to a new feature. The team will also explore a lightweight onboarding framework to expose new users to features. The goal is to have it be reusable, and probably just be a little popup that can be easily dismissed. Exact MVP for this to be defined. :-) Our first step in January will be to add the gallery viewing functionality and sharing functionality to the image viewer, as those features are already pretty well defined and we can start moving on them immediately. Our next steps after that for Q3 will come out of our quarterly planning sessions during the all staff meeting in January. Let me know if you've got any questions! Thanks, Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

1 0

Anonymous editing and Italian Wikipedia
by Jon Robson 15 Dec '14

15 Dec '14

Italian Wikipedia recently started an experiment to enable anonymous editing for its editors. Many thanks to Florian and Nemo for making this happen! They enabled it on the 1st November so now we have a month of data let me state about what we've found. For the month of November anonymous edits counted for 50% of all edits on Italian Wikipedia and increased the average number of edits by roughly 55%. Average edits before switch was 1688 Average edits after switch was 2619 Logged in editing took a slight dive as a result of this - 1687 edits were coming from logged in users before to 1305 The graph [1] shows not too much impact to the current trend for editing from logged in users but it's clear that anonymous editing does bring in slightly more edits, but not a radical amount to get us excited about. Florian has recently written a patch that simplifies the workflow for editing such that clicking edit loads a screen with anon editing, sign in and sign up options. It will be interesting to see if this effects the data at all. Can anyone from the Italian community analyse the types of anonymous edits that were made in the month of November and comment on what % of those got reverted / were bad edits? I've included the data [1] (should be public) for anyone to analyse and pick apart. [1] https://docs.google.com/spreadsheets/d/1k3QaksUtkSA7s2W-bMhvE8hYF9hT_OBW4tn…

3 3

WikiGrok test in stable now live
by Ryan Kaldari 12 Dec '14

12 Dec '14

After a few false starts, the WikiGrok test in stable has finally been activated. This test is for all logged in users of the mobile site for 1 week. I've updated the test documentation here: https://meta.wikimedia.org/wiki/Research:Mobile_microcontributions/WikiGrok… The test officially went live at 00:41 UTC (20141212004100). We will turn it off next Thursday. Ryan Kaldari

11 12

Local instance with Wikidata?
by Jon Robson 12 Dec '14

12 Dec '14

Is there any easy way to store wikidata id inside my local pages? Ideally I want to stop using: http://localhost:8080/wiki/Albert_Einstein?wikidataid=Q937&mobileaction=alp… and go to http://localhost:8080/wiki/Albert_Einstein?mobileaction=alpha and pull data magically from Wikidata's Q937 entry. Is this something we can get fixed? Not having this is making it hella tricky to work on https://trello.com/c/mvYxnIz6/9-3-alpha-page-styling-experiment-wikidata-de…

2 2

Android Wikipedia Beta app release
by Bernd Sitzmann 09 Dec '14

09 Dec '14

Dear Android app users, A few minutes ago a new beta release got published, which should be available through the store in a couple of hours. It's been a while since we last published a new beta so the list of changes is fairly long and exciting: * Material design icons and 5.0 toolbar/support * Search bar is back * Search order improvements * Add page descriptions from wikidata.org to search results, similar pages, and on pages under the title * Swipe to refresh on pages and for Nearby feature * Infoboxes are collapsed by default * Layout improvements for tablets * Added "Read more" section at the end of the page (except main page) * New setting to allow disabling images * Simple syntax highlighting of templates while editing * Hide IPA * ToC drawer always on * Similar pages, page issues, reference info display changes * Correctly display MathML fallback images * Remove pinch-zoom in WebView * Various bug fixes Please report any issues you find. Enjoy, Bernd

2 2

CommonsMetadata API returning HTML?
by Dan Garry 09 Dec '14

09 Dec '14

Greetings, Multimedia Team! *Background:* The Mobile Apps Team is working on a restyling of the way content the first fold of content is presented in the Wikipedia app. You can see this image <http://i.imgur.com/dxqfJKd.png> to see what this looks like. Having a high-resolution image so prominently at the top of the page will likely drive a lot of clicks, so we're working on a lightweight image viewer to deal with file pages, which are poorly styled monstrosities on the mobile app. We're going to use the CommonsMetadata API to help us out. :-) *Problem:* The CommonsMetadata API can sometimes return HTML [1]. Having HTML in the API response is a bit problematic for us. Native apps make next to no use of HTML when creating links or layouts, so we have to strip the HTML from every API response, lest it be displayed as plaintext to the user. In the short term this is fine, we can strip it and throw the information away. But in the long run it'd be better if the API didn't return HTML. *Our ask: *Can the CommonsMetadata API please not return HTML in its responses? :-) Thanks, Dan [1]: Run this query <https://commons.wikimedia.org/w/api.php?action=query&prop=imageinfo&format=…. >, and look at "artist" key. The API response has an HTML link in it. -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

7 13

Fwd: CommonsMetadata API returning HTML?
by Florian Schmidt 08 Dec '14

08 Dec '14

Forward to mobile-l, forget to press "answer all" :) -----Ursprüngliche Nachricht----- Von: Florian Schmidt [mailto:florian.schmidt.welzow@t-online.de] Gesendet: Montag, 8. Dezember 2014 20:46 An: 'Dan Garry' Betreff: AW: [WikimediaMobile] CommonsMetadata API returning HTML? First: That looks great! Maybe a good input for mobile web, too :) I remember a similar problem for mobile media viewer (you see the author of an image, too, if returned by commonsmeta api). The problem is, iirc, that the html is in the input (the template used on commons to describe images where the information is extracted from), so CommonsMeta has to strip the html out, like the app do it locally. I don't know, what would be the best way :/ Kind regards / Freundliche Grüße Florian Von: mobile-l-bounces(a)lists.wikimedia.org [mailto:mobile-l-bounces@lists.wikimedia.org] Im Auftrag von Dan Garry Gesendet: Montag, 8. Dezember 2014 20:31 An: Multimedia(a)lists.wikimedia.org; mobile-l Betreff: Re: [WikimediaMobile] CommonsMetadata API returning HTML? Sorry, the example query I provided was incorrect. Use this instead: https://en.wikipedia.org/w/api.php?action=query&prop=imageinfo&format=jsonf… Thanks, Dan On 8 December 2014 at 11:29, Dan Garry <dgarry(a)wikimedia.org> wrote: Greetings, Multimedia Team! Background: The Mobile Apps Team is working on a restyling of the way content the first fold of content is presented in the Wikipedia app. You can see this image to see what this looks like. Having a high-resolution image so prominently at the top of the page will likely drive a lot of clicks, so we're working on a lightweight image viewer to deal with file pages, which are poorly styled monstrosities on the mobile app. We're going to use the CommonsMetadata API to help us out. :-) Problem: The CommonsMetadata API can sometimes return HTML [1]. Having HTML in the API response is a bit problematic for us. Native apps make next to no use of HTML when creating links or layouts, so we have to strip the HTML from every API response, lest it be displayed as plaintext to the user. In the short term this is fine, we can strip it and throw the information away. But in the long run it'd be better if the API didn't return HTML. Our ask: Can the CommonsMetadata API please not return HTML in its responses? :-) Thanks, Dan [1]: Run this query, and look at "artist" key. The API response has an HTML link in it. -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

1 0

[Apps] How good is our search? Here's some data!
by Dan Garry 05 Dec '14

05 Dec '14

We've now got some preliminary data in about how effective our search is in mobile apps. Note that this is only half a day's data, and it's sampled at 1%. High-level metrics: - *Number of searching sessions which end by tapping on a result:* 91% - *Percentage of queries that give 0 results: *19% - *Mean queries per searching session:* 3.8 - *Median user-perceived time taken to retrieve search results: *486ms - *90th percentile of user-perceived time taken:* 898ms My quick take-homes from this: - 91% clickthrough seems pretty good. - 19% of queries giving "no results" seems really bad. - The combination of the above two means users are generally finding what they need, but that it's a struggle to do it. - User-perceived performance seems pretty good; 90% of our users get search results within a second! What I think our next steps are: - Push out our new search improvements and see how these baselines change. - Try to tackle the "0 results" problem, which seems to be more of a problem than clickthrough. Spreadsheet containing my queries and processed data: https://docs.google.com/a/wikimedia.org/spreadsheets/d/1syLgNygAS7Prxxg7RTI… Dan -- Dan Garry Associate Product Manager, Mobile Apps Wikimedia Foundation

7 6

Thumbnail filename URL extraction rules
by Brion Vibber 05 Dec '14

05 Dec '14

Per request in meeting, thought I'd stick it on the public list for references. :) As I recall there should be three possible URL formats for images embedded in <img> tags in wiki pages or returned as thumbnails via the API: http(s)?:// upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/(base-filename) ^ original-size images http(s)?:// upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-file… ? ^ thumbnails http(s)?:// upload.wikimedia.org/(project)/(subdomain)/(hash1)/(hash2)/thumb/(base-file… ^ this last is used in cases where the filename is very very long and we can't actually prepend all the options to the filename (happens mostly in South Asian languages where UTF-8 is 3 bytes per letter) * project: 'wikipedia' in all cases we need to handle; local files on Wiktionary etc will have it separate but we don't use these. * subdomain: language 'en' etc for Wikipedias, subproject for special-case wikis like Commons/'commons' * hash1: first digit of md5 hash of the filename (you don't need to use this here, consider it opaque) * hash2: first 2 digits of md5 hash of the filename * base-filename: the base filename -- you want this! This is the raw filename for files served at original size; thumbnails will use it as a directory component. * render-extension: files other than PNG, GIF, and JPEG are rendered to one of those, usually PNG. So you'll see things like ".svg.png" at times -- but never ".png.png". These only appear on thumbnails. * size: thumbnails are always given with the pixel size. * possible-other-options: Note that other options may include a page number for PDF, DjVu, or TIFF files, or a time position for video thumbnails. To avoid parsing that stuff out, consider using the subdirectory base name on thumbnails if possible. -- brion

3 3

iOS Wikipedia app 4.0.6 going into the Apple queue
by Brion Vibber 05 Dec '14

05 Dec '14

Per usual caveat, expect to take a couple days at least to work its way through review. Numerous small fixes, most notably: * fix for horrible hanging bug on certain large articles on iOS 7 * recently-used search list * translation updates The fulltext search mode in the latest betas is not included as it needs some performance and UI work still. Coming soon! -- brion

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l December 2014