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
Cross-posting from various lists...
*TL;DR a new Foundation grant program starts today. Recent posts to this
list highlighted efforts to revive and improve Android Commons app by
Josephine Lim, with a similar type of grant[1]. Grants with this new
program could be a great source of support for similar mobile related
Wikimedia projects.*
[1] - https://lists.wikimedia.org/pipermail/mobile-l/2016-June/010255.html
---------- Forwarded message ----------
From: Alex Wang <awang(a)wikimedia.org>
Date: Fri, Jul 1, 2016 at 10:10 AM
Subject: [Wmfall] Launching Project Grants!
To: "Staff (All)" <wmfall(a)lists.wikimedia.org>
Hi everyone,
The Wikimedia Foundation Project Grants program will launch its first open
call on July 1. We will be accepting proposals through August 2nd for new
ideas to improve Wikimedia projects. <
https://meta.wikimedia.org/wiki/Grants:Project>.
Funds are available to support individuals, groups and organizations to
implement new experiments and proven ideas, whether focused on building a
new tool or gadget, organizing a better process on your wiki, researching
an important issue, coordinating an editathon series or providing other
support for community-building.
Ideas from the current Inspire Campaign on addressing harassment are very
welcome. <https://meta.wikimedia.org/wiki/Grants:IdeaLab/Inspire>
Do you have have a good idea, but would like some feedback before applying?
Put it into the IdeaLab, where volunteers and staff can give you advice and
guidance on how to bring it to life. <
https://meta.wikimedia.org/wiki/Grants:IdeaLab> Once your idea is ready,
it can be easily migrated into a grant request.
Marti Johnson and I will also be hosting weekly proposals clinics via
Hangouts and IRC for real-time discussions about the Project Grants Open
Call. We’ll answer questions and help you make your proposal better. Dates
and times are as follows:
* Tuesday, July 5 - 16:00 UTC
* Thursday, July 14 - 02:00 UTC
* Wednesday, July 20 - 15:00 UTC
* Friday, July 29 - 02:00 UTC
* Tuesday, August 2 - 01:30 UTC
* Tuesday, August 2 - 16:00 UTC
Links for Hangouts and the IRC channel are available here: <
https://meta.wikimedia.org/wiki/Grants:IdeaLab/Events#Upcoming_events>
We are excited to see your grant ideas that will support our community and
make an impact on the future of Wikimedia projects. Put your idea into
motion, and submit your proposal between July 1 and August 2! <
https://meta.wikimedia.org/wiki/Grants:Project/Apply>
Please feel free to get in touch with me (awang(a)wikimedia.org) or Marti
Johnson (mjohnson(a)wikimedia.org) with questions about getting started with
your project!
Warm regards,
Alex & Marti
--
Alexandra Wang
Program Officer
Community Resources
Wikimedia Foundation <http://wikimediafoundation.org/wiki/Home>
+1 415-839-6885
Skype: alexvwang
_______________________________________________
Wmfall mailing list
Wmfall(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wmfall
*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
Hello,
On Friday of last week, the Wikimedia Foundation's iOS team pushed a new
version to our beta channel[1]. During this testing we discovered a
regression with tapping images in articles, and have just pushed a very
slightly updated version to TestFlight.
This is our release candidate build for version 5.0.5, and barring any
issues we plan to submit this update to the App Store early next week.
As usual thanks to our volunteer testers for the help and feedback,
Josh Minor
[1] https://lists.wikimedia.org/pipermail/mobile-l/2016-June/010254.html