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
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…
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
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
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
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
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
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
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
