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
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
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
*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]
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
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
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
