MobileFrontend Builds [1] 536-592 have failed. That's a lot.
Does anyone care about this job?
Should we disassemble it into smaller jobs just like we did with smoke
tests [2]?
That said even our smaller smoke test job has been problematic (Chris
mentioned an issue with the latest chrome driver but that was a month ago
and I don't know where the bug for this is).
These browser tests are useless if no one is watching them and/or they are
spinning out false positives and I can't be the only one to complain when
these tests break. This should be a shared responsibility.
These are not new issues and they continue to frustrate me.
[1]
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
[2]
https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
Thanks for sending this out Daisy.
There are a few things I'd like to add from my observations with users.
2 users were pretty concerned that it was so easy it would lead to vandalism at worst and edit wars at best.
The one user that interacted with the CTA unprompted had the least helpful contribution, literally describing the contents of the lead image. "It's the Golden Gate Bridge and the bay" which causes me some concern.
In general even the users who understood the point of the descriptions failed to write descriptions that would hold up to the standards of the Wikidata community.
If we intend on moving forward with this I think we should consider the following:
- figure out a way to do a smaller rollout first
- tag edits done through this method
- consider allowing IP users only to contribute new descriptions (not edit existing ones)
- show a brief "guided tour" with examples of good descriptions for first time contributors
Thank you for the quick work on the prototype Dan, and thank you for organizing the last minute testing Daisy.
From: Daisy Chen <dchen(a)wikimedia.org>
Date: Thu, Mar 26, 2015 at 9:13 AM
Subject: [WikimediaMobile] [Apps] Description editing prototype testing
To: mobile-l(a)lists.wikimedia.org
Cc: Abbey Ripstra <aripstra(a)wikimedia.org>
Hi all,
Please find the goals for and top-level findings from guerrilla testing description editing on Wikipedia Alpha below. More in-depth information including tasks/questions posed and raw notes on the 5 participants can be found here. There may be typos and small formatting errors (I'll be proofing the page in the next hour).
Happy quarterly planning--
Daisy
---
Goal
The goal of this research was to observe people interact with the CTA ("Tap to add a description!") line in the header under article titles in Wikipedia Alpha. After tapping the CTA, users experience 3 editable scenarios: 1. an meaningful description suggestion, 2. a blank form field, and 3. a random/irrelevant description suggestion.
Do users notice the CTA prompt? How effective are they in triggering action?
How do users feel about the CTA?
How effective are descriptions that are auto-generated and meaningful? Do they assist users with finalizing the description or confuse users as to why they are prompted to edit a description that is already automated and correct?
How effective is not giving a user a pre-populated description field?
How effective are descriptions that are auto-generated and random?
How do users feel about the process of editing description lines overall?
Findings: Patterns Observed
3 of 5 users required some level of facilitator prompting to notice the CTA.
Interactivity breakdown:2 users would most likely overlook this field, 2 users might notice/interact depending on the situation, and 1 user was not sure.
All users either specifically indicated field interaction was easy and intuitive or had no specific complaint or struggle that was observed. Only 1 user was briefly confused about the blank SF description field, thinking he couldn't type because he didn't see a blinking cursor.
3 scenarios feedback breakdownMeaningful description suggestionmost helpful: 2 users
most helpful, but pointless because I can't see it on page: 1 user
confusing: 1 user
Blankfine if you know about topic: 1 user
fine and having the CTA here made most sense: 1 user
most engaging: 1 user
easiest: 1 user
Random/irrelevant description suggestionif visible, could prompt action: 2 users
2 of 5 users expressed some level of confusion around why the CTA hides the description. One user was confused about why he was prompted to action when the description was correct on Picasso. Another user was confused about the same thing, and also mentioned that he would be much more likely to take action on the random article if he could see that the description was incorrect. The latter also mentioned that the CTA really only makes sense on the SF blank description page.
1 user was confused about whether these descriptions were for himself or for all of Wikipedia.
No users indicated confusion about the CTA pop-up language.
_______________________________________________
Mobile-l mailing list
Mobile-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mobile-l
Hi all,
Please find the goals for and top-level findings from guerrilla testing
description editing on Wikipedia Alpha below. More in-depth information
including tasks/questions posed and raw notes on the 5 participants can be
found here
<https://www.mediawiki.org/wiki/Guerrilla_Testing,_March_24,_2015:_Descripti…>.
There may be typos and small formatting errors (I'll be proofing the page
in the next hour).
Happy quarterly planning--Daisy
---
Goal
The goal of this research was to observe people interact with the CTA ("Tap
to add a description!") line in the header under article titles in
Wikipedia Alpha. After tapping the CTA, users experience 3 editable
scenarios: 1. an meaningful description suggestion, 2. a blank form field,
and 3. a random/irrelevant description suggestion.
1. Do users notice the CTA prompt? How effective are they in triggering
action?
2. How do users feel about the CTA?
3. How effective are descriptions that are auto-generated and
meaningful? Do they assist users with finalizing the description or confuse
users as to why they are prompted to edit a description that is already
automated and correct?
4. How effective is not giving a user a pre-populated description field?
5. How effective are descriptions that are auto-generated and random?
6. How do users feel about the process of editing description lines
overall?
Findings: Patterns Observed
1. 3 of 5 users required some level of facilitator prompting to notice
the CTA.
2. Interactivity breakdown:
1. 2 users would most likely overlook this field, 2 users might
notice/interact depending on the situation, and 1 user was not sure.
3. All users either specifically indicated field interaction was easy
and intuitive or had no specific complaint or struggle that was observed.
Only 1 user was briefly confused about the blank SF description field,
thinking he couldn't type because he didn't see a blinking cursor.
4. 3 scenarios feedback breakdown
1. Meaningful description suggestion
1. most helpful: 2 users
2. most helpful, but pointless because I can't see it on page: 1
user
3. confusing: 1 user
2. Blank
1. fine if you know about topic: 1 user
2. fine and having the CTA here made most sense: 1 user
3. most engaging: 1 user
4. easiest: 1 user
3. Random/irrelevant description suggestion
1. if visible, could prompt action: 2 users
5. 2 of 5 users expressed some level of confusion around why the CTA
hides the description. One user was confused about why he was prompted to
action when the description was correct on Picasso. Another user was
confused about the same thing, and also mentioned that he would be much
more likely to take action on the random article if he could see that the
description was incorrect. The latter also mentioned that the CTA really
only makes sense on the SF blank description page.
6. 1 user was confused about whether these descriptions were for himself
or for all of Wikipedia.
7. No users indicated confusion about the CTA pop-up language.
--
Daisy Chen
Wikimedia Foundation
Imagine a world in which every single human being can freely share in
the sum of all knowledge. Help us make it a reality!
*https://donate.wikimedia.org <https://donate.wikimedia.org/>*
A heads up about a new extension (Gather [1]) being deployed to the cluster
on Thursday [2]. We are aiming to deploy to testwiki on Thursday 26th March
and English Wikipedia on Monday 30th March.
We're not expecting this to cause any problems since traffic is limited to
the mobile beta mode of the site which accounts for 1/70th of mobile
traffic and approximately only 500 of those users are logged in (and this
feature is primarily for logged in users).
The extension makes use of the API, firing an API query request when
1) the special page is loaded (available to all users including anons). The
special page is only linked to within the beta site (in the main menu) for
logged in users so all traffic. However traffic is expected from social
networks and links from wiki pages.
2) when the watchstar is clicked by a logged BETA user
I'm not expecting any problems with this deployment, but in worse case
scenario since this is an experimental feature and we can disable the
extension in the unlikely event that we hit any issues.
Please let me know if you have any further questions and please complain to
me if notice any issues.
We've announced this on en:vp [3]. For anything non-ops related feel free
to engage in the conversation there.
Thanks!
Jon R, mobile web team
[1] https://www.mediawiki.org/wiki/Extension:Gather
[2] https://phabricator.wikimedia.org/T91341
[3]
https://en.m.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#Exte…
>
> Seems sensible, but knowing history I don't think it will be updated
> correctly.
We're a different team now. Whaddya say we give it a try?
> I think the updating of VERSION.txt really needs to be automated. Can we
> have a script that can be run bumps the version number and generates these
> logs by searching for keywords e.g. 'Bug:' 'Feature:' and generates this
> list. I think without this, this is a nice idea but will be disastrous.
https://github.com/tj/git-extras/wiki/Commands#git-changelog is one of the
many solutions to this turned up by a quick Google :)
–Sam
In preparation for next week's quarterly planning, I'd like to restate some
of my concerns regarding Wikidata descriptions and flesh them out more
comprehensively, since we're featuring them more prominently in the
upcoming quarter.
(n.b. These are more like "devil's advocate" thoughts, lest I make it sound
like the Apps team isn't unified in its vision, which it certainly is.)
My reservations fall under two categories:
== Philosophical ==
Wikidata is a superbly valuable repository of *data* -- data that a machine
can use to generate all kinds of results that us humans can consume. The
"description" field, on the other hand, is the only thing that is *not*
data, and is not usable by a machine in any way.
To allow users to manually fill in the Wikidata description (i.e. to
manually duplicate the contents of Wikipedia) is to miss the point of the
true potential of Wikidata, which is to be able to *use* the data to
generate the description automatically!
Of course the counterargument to this is that the current state of
auto-generated descriptions is not quite good (they often sound strange or
nonsensical), but that's only because the tools we have at our disposal for
generating descriptions are still in their infancy. I don't deny that this
will be a hard problem to solve, but in my view, this is ultimately the
*correct* problem to solve.
The other thing (a more obvious one) that makes Wikidata descriptions
redundant is the first sentence of every Wikipedia article which, on its
own, is intended to provide a concise description of the article (and many
articles already do this with rather good consistency). In fact, as we
speak, we're working on programmatically "cleaning up" the first sentence
to make it even more concise. Why not simply use this as the description?
Is the first sentence sometimes too long to be a good description? No
problem: create a markup annotation that will denote the *portion* of the
first sentence that will serve as the description. In any case, making
users manually copy the content from the first sentence (which is from
where most of the current Wikidata descriptions appear to be derived) seems
extraordinarily unnecessary. On top of all that, it creates an unnecessary
synchronization cost, fulfillable only by a human contributor, between the
two sources of data.
So, what I mean to say is: every edit to the Wikidata description is a
missed opportunity to edit the Wikipedia article in such a way that the
description could be auto-generated correctly. (or, similarly, a missed
opportunity to edit the *data* of the Wikidata entry in such a way that the
description could be auto-generated correctly)
== Practical ==
If we open the floodgates to editing the Wikidata description (i.e. if we
make it too easy to edit the description), I predict that we'll be very
disappointed by the quality of the contributions we'll get. I can see it
quickly devolving into a whole lot of noise, spam, and vandalism.
This means that we would need to implement the same kind of
moderation/administration schemes that currently exist on Wikipedia
itself. I'm by no means qualified to speak for the Community, but I doubt
that many Wikipedians will want to double their workload by having to
"watch" the Wikidata description of their favorite articles, in addition to
the articles themselves.
I'll also point out that we do not yet expose any administrative mechanisms
in the mobile apps. This means that users will routinely see their edits
disappear or be reverted without any notification or explanation. This is
already the case for the general editing of article content in the apps,
but since the description is featured much more prominently, any edits (or
reverts) to it will be much more noticeable, and will surely add to the
confusion and frustration.
If we really want to get it right, we have to figure this out before
proceeding.
-Dmitry
Hi everyone,
For those of you who aren't aware, the Mobile Apps Team has been running an
experiment in Wikipedia Beta on Android. We're trialling a single, visually
appealing result at the end of articles instead of the three from "Read
more". We're calling this "Read next". What happens is that approximately
half of Wikipedia Beta users are shown read next on every article, and the
other half are shown read more. Here's some example screenshots:
- Read next: http://i.imgur.com/StTLAPU.png
- Read more: http://i.imgur.com/ecb2cy2.png
Here's the verdict of the test!
- Read more has a clickthrough rate of 15.4% (65,448 views, 10,600
clicks)
- Read next has a clickthrough rate of 10.4% (59,668 views, 6,180 clicks)
So it would seem that read next is not as effective at driving clicks as
read more is. Interesting!
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Good news, everyone!
The latest version of the Beta app[1] has been released, and will be
available on the Play Store shortly. Some highlights from this version:
- Improved layout and styling of Share-a-fact cards.
- Enabled caching of pages on internal/external storage of the device
(should improve memory usage and fix out-of-memory errors).
- Updated launcher icon and miscellaneous Material design elements in the
app.
- Updated for the latest Android SDK version.
- Fixed miscellaneous bugs and updated translations.
Best,
Dmitry
[1] https://play.google.com/store/apps/details?id=org.wikipedia.beta
