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
It really saddens me how very few engineers seem to care about browser
tests. Our browser tests are failing all over the place. I just saw this
bug [1] which has been sitting around for ages and denying us green tests
in Echo one of our most important features.
How can we change this anti-pattern?
Dan Duval, would it make sense to do a survey as you did with Vagrant to
understand how our developers think of these? Such as who owns them... who
is responsible for a test failing... who writes them... who doesn't
understand them.. why they don't understand them etc...?
[1] https://phabricator.wikimedia.org/T72298
On Thu, Mar 26, 2015 at 5:54 PM, Dan Duvall <dduvall(a)wikimedia.org> wrote:
> On Thu, Mar 26, 2015 at 3:38 PM, Jon Robson <jdlrobson(a)gmail.com> wrote:
> > The lack of replies from any mobile team members seems to suggest I'm the
> > only one watching this. In that case I'd rather we split up the big
> > MobileFrontend job into various jobs based on certain features. How can
> we
> > get more people caring about browser tests? Naming and shaming?
>
> We have a couple projects in the works that will hopefully help.[1][2]
> They don't go so far as to name and shame (we'll leave that up to you
> :), but they should promote more ownership over browser tests, better
> communication of failure, and analysis of failure over time and by
> test function (feature vs smoke vs regression).
>
> If many of these browser tests are serving as regression/smoke tests,
> it might be worthwhile to not only separate them out, but to remove
> some of the layers of abstraction to make tests more maintainable. I
> often try to think about tests in terms of a value-to-debt ratio (i.e.
> "How likely is it that I'll have to fix or refactor this test down the
> road and is it worth it?") and, while I find quite a bit of value in
> Cucumber for the sake of acceptance(-esque) testing (it keeps me
> mindful of the UX),[3] it introduces quite a bit of debt in its layers
> of abstraction and indirection (it's always a red flag when you have
> to grep to find your test implementation). Even its creators believe
> the value of Cucumber lies in its collaboration/planning capacities,
> not in its function as a test runner.[4]
>
> It's entirely possible, as of the 1.0.0 release, to use MW-Selenium
> without Cucumber, so perhaps we could experiment with simple RSpec
> examples for these types of tests.
>
> Tooling aside, there are broader discussions that need to take place
> among those that are practicing or have practiced TDD/BDD in the
> organization and how we might (or might not) promote theses practices
> among others. I'll be trying to form such a group next quarter (will
> it be a 'guild'?, a 'league'?, no need for tough decisions just
> yet[5]), so let's maintain a dialogue on that front if you're
> interested and willing.
>
> [1] https://phabricator.wikimedia.org/T88706
> [2] https://phabricator.wikimedia.org/T89375
> [3]
> https://gerrit.wikimedia.org/r/#/c/196492/10/features/role_settings.feature
> [4]
> https://cukes.info/blog/2014/03/03/the-worlds-most-misunderstood-collaborat…
> [5] https://www.youtube.com/watch?v=6KSiyaqnZYs
>
> > Practically, the current big job [1] we have has far too many false
> > positives and it is just noise to me. I was paying attention to the smoke
> > tests [2] but I was told that was an upstream bug and haven't been
> watching
> > it since. Any idea why that has been failing recently? Nothing has broken
> > here...
> >
> > [1]
> >
> https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
> > [2]
> >
> https://integration.wikimedia.org/ci/view/Mobile/job/browsertests-MobileFro…
> >
>
> Have you tried to reproduce these failures by executing the tests
> locally, against either Beta or your local MW? I'll be in the office
> tomorrow if you want advice on how to best go about it.
>
> Dan
>
> --
> Dan Duvall
> Automation Engineer
> Wikimedia Foundation
>
--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon
*tl;dr: The programming language used to develop new features by our iOS
app engineering team is changing from Objective C to Swift at some point in
the near future.*
When making a native app, the language you have to implement the app in is
chosen by the third party responsible for the platform. For iOS apps, Apple
chose Objective C to be the language the app is written in. Objective C is
a... very strange language. It has a lot of quirks that slow down
development.
To solve the above problem, you can now write apps in a new language called
Swift. Notably, Swift has features that make it less error prone and more
concise than Objective C, which should increase our velocity of feature
development. Swift is also much more readable and in-line with other
languages, which lowers the barrier of entry (which is currently very high
with Objective C).
Importantly, Objective C and Swift can live alongside each other. So, when
we "switch to Swift" we do not need to rewrite all of our existing code
from Objective C to Swift. Instead, we can just start developing new
features using Swift, and slowly rewrite the old code from Objective C into
Swift as time allows.
On the downsides, Swift is only supported on iOS 7 and above. iOS 6 only
represents around 5% of our user base, and we can pin iOS 6 users to the
last version of the app we released before we used Swift. We need to decide
what the last set of features we're want in that build are before we switch.
Here are our next steps:
- Evaluate more concretely whether Swift actually fits our needs or not.
[Engineering]
- Decide last set of features for our iOS 6 build. [Product/Design]
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Hi mobile teams,
Awhile ago I pointed out (https://phabricator.wikimedia.org/T91621) that
the important template in content pages that directs readers from article
subsections to "main articles" is missing from mobile web pages. I have
since found other templates with relevant reader-oriented content to be
missing from mobile web. With the latest Android app release this problem
appears to be happing at greater scale in mobile apps now as well. For
example the audio demonstration of jazz that I placed at the top of the
"Jazz" article on English Wikipedia is missing from Android and from mobile
web. Please, please __do not__ use technical means to delete content or
templates from mobile views when they are intended for our readers on all
platforms and were placed in articles through the efforts of volunteers,
especially not without a community discussion first. Formatting tweaks are
negotiable, but this kind of content elimination makes me upset. I feel
that it degrades Wikipedia's value to readers, and as a person who adds
audio and other templates to articles I find it discouraging to have my
efforts removed from the view of so many Wikipedia readers.
Thank you for your work to make Wikipedia reading be a good experience on
mobile.
Pine
This morning we pushed a release to Android which contained several fun new
features.
- Most notably, we've enhanced sharing! Highlight an interesting fact
from an article and tap "Share" in the overflow menu to create an image
which can be shared to social networks and other platforms. Did you know
the University of Manchester is the largest single site university in the
United Kingdom? You do now! <https://i.imgur.com/DgULFLQ.jpg>
- We've added featured article and search widgets. Long press on your
home screen to bring up the widgets menu.
- We've enabled caching of pages on internal/external storage. This
should significantly reduce memory usage and reduce the frequency of "out
of memory" crashes.
- We made miscellaneous design tweaks, bug fixes, crash fixes, and
translation updates. Thanks translators!
Also, we've been getting a lot of five star reviews today
<https://i.imgur.com/IXOuxy2.png>. ;-)
Nice work, team!
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Hi,
I am translating Gather, and I feel very uncomfortable about the term
"Owner".
It's challenging to translate, because in the languages I care about -
Hebrew and Russian - it requires gender. Now gender can be added without
too much technical effort, but there's still the general feeling of
discomfort - "owner" is a strong word in the Wikimedia world, which should
usually be avoided without a good reason.
Was this word chosen intentionally, to show that lists are, in fact, owned,
and privately curated?
Maybe it could be changed to something like "maintainer", "curator" or
something else? Or simply "User"?
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
I've split this off because it has the potential to derail the other
conversation about Wikidata descriptions.
On 22 March 2015 at 09:53, Pine W <wiki.pine(a)gmail.com> wrote:
>
> I do wonder if it would be better to focus on encouraging more mobile app
> users to become Wikipedia and/or Commons contibutors instead of Wikidata
> contributors. Thoughts?
>
We've considered such problems at great length, and so far never actually
managed to succeed at drawing people in to editing on mobile devices. As
always, there are the obvious exceptions to that (people like you and me),
but we're by far the minority.
No other mobile app out there has the same kind of barrier to entry for a
contribution as Wikipedia. Some of that is a result of the core product
(contributing to an encyclopedia requires serious thought!), but some of it
is for no good reason (wikitext is scary to newbie).
On the other hand, the mobile uploads feature did draw a lot of people
in... to uploading selfies. So that was problematic from the other side: it
got a lot of engagement, but of the totally wrong kind. There was
considerable backlash, which naturally makes the team want to avoid trying
something similar again.
Do you have any specific suggestions?
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Another Wikipedia Beta for iOS has been updated on TestFlight (v 4.0.7.10).
Source available via git clone
https://gerrit.wikimedia.org/r/apps/ios/wikipedia
git tag is beta/4.0.7.10-beta-2014-03-27
