Hi everyone,
tl;dr: We’re trialling having separate Trello boards for the iOS and
Android apps sprint 40.
The Mobile Apps Team has been chatting about its process around Trello
boards recently, and the following issues were identified with our current
"one board for both iOS and Android" structure:
- The iOS and Android engineering efforts are completely separate.
- Each platform has its own tech lead.
- The iOS engineers only work on iOS cards, and the Android engineers
only work on Android cards.
- The codebase between the apps is not shared (except for a little
bit of JS).
- Slack on one platform can’t be picked up by the engineers on the
other.
- The iOS and Android engineers have different velocities. Part of this
is because Android currently has an additional engineer, but it’s also
because the cards are disjoint and therefore slight differences are
emerging in how the cards are estimated.
- Tracking these different velocities separately of each other is
senselessly difficult with a single shared board, because you have to apply
and remove filters to do so.
- In the past, features were implemented on both platforms at the same
time, but that isn’t happening anymore due to velocity differences.
- Engineers almost always have a filter on to only show the cards for
the platform they work on, so having the cards from the other team in their
board has little use.
In short, the team has decided that having a single board for both iOS and
Android isn’t actually serving anyone in the team anymore, and instead it’s
just causing some slight inconveniences.
We’re going to try having separate boards for the iOS and Android apps in
sprint 40. The meeting structure will remain the same; we are still a
single team, and the engineers from both platforms share a lot of expertise
and ideas with each other, and we don’t want to lose that. This experiment
is ultra safe-to-fail, as if we decide it’s not working at any point then
we can immediately move all the cards into a single board then archive the
second board.
Let me know if there are any questions.
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Hi everyone,
Kaity, Vibha and myself went out into the wild with the current Wikipedia
Beta build, and tested the rolled-up disambiguation.
The test: we started out on The Sound of Music
<https://en.wikipedia.org/wiki/The_Sound_of_Music>, the article about the
musical. We then asked the user "Say you wanted to go to the article about
the film rather than the musical. How would you do that?".
Of the five people tested, four of the five started scrolling like a madman
and one went looking for the "index" (i.e. the table of contents). A few of
them then said "Oh, I'll just search for the article" and started tapping
interface elements like the ToC or overflow menu. None found search
straight away. None found the "Other meanings text".
Although it's somewhat concerning that nobody found search straight away, I
think it's important to view this finding in the context of the test, and
not panic! Notably, there were several biases in the test that would
disincline people from searching:
- Users in testing scenarios like this are under pressure to try to find
the quickest way to accomplish their goals, and tapping search and typing
is never going to be quick.
- We gave them the device already pointing at an article, so the context
of the task heavily implied that we expected them to find their way to the
new article from the current one rather than explicitly searching.
- People may be iOS users so may not be familiar with how Android works
in general.
That said, it did expose an interesting point. All of the functionality in
the top bar is in the form of icons that you tap, except for search which
is a flat text field. That's kind of weird. We should change that so that
the interaction model for the top bar is consistent with... itself. ;-)
So, if you look at the wrapping up of article issues as "I want to get to
the lead section faster when I first go to an article", it's a 100%
success. On the other hand, if you still want people to actually use
disambiguation, it may not be because nobody used it.
Here's the course of action I think we should try:
- Change the prose slightly. Let's try "Similar articles".
- Change the colour to make it clearer it's a link.
This course of action comes with a patch to implement it:
https://gerrit.wikimedia.org/r/#/c/159236/
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Hi all, first off, apologies for breaking the thread (I've just subscribed
to this list).
TheDJ wrote:
I propose we remove the Wikimedia Commons app from the store.
Clearly there is no time available to work on it, there is no one
maintaining it or following up on the problems that have been reported
since 2013.
Yann is just brining it up on wikimedia-l and I think that it is bad
to have an app out there that no on is taking care of. So we should
pull it and whoever wants to continue with it can release it under a
name of this own.
DJ
===============
The WMF has been focusing more on the Wikipedia app at this point, so
this is a reasonable suggestion. Otherwise there's the reality that
the app will continue to degrade.
I've been told that the mobile team has been emailed about this, so
while it isn't a top priority, removing it will be in the works.
--
Rachel diCerbo
Director of Community Engagement (Product)
Wikimedia Foundation
Rdicerb (WMF) <https://wikimediafoundation.org/wiki/User:Rdicerb_%28WMF%29>
@a_rachel <https://twitter.com/a_rachel>
Just an update on VE editing since we pushed it to stable for tablet users
(as an opt-in secondary editor on all projects) yesterday:
Since yesterday, we're getting about 0.2% of total mobile edits across all
projects coming from VE, and about 2% of unique mobile editors having made
at least 1 successful VE edit. So the volume is, as expected, pretty low –
which is good because it gives us lots of breathing room to fix bugs and
improve features before we make VE any more prominent of an editing
experience :)
For fun, here's a breakdown of which projects those unique editors were on:
Project # of unique editors making at least one successful VE edit
enwiki 42
eswiki 5
frwiki 4
itwiki 3
svwiki 2
cswiki 2
nlwiki 2
cawiki 1
jawiki 1
thwiki 1
dewiki 1
ukwiki 1 <-- this was me :)
--
Maryana Pinchuk
Product Manager, Wikimedia Foundation
wikimediafoundation.org
There are now some app specific reports in
http://mobile-reportcard.wmflabs.org/#apps-graphs-tab.
Since it takes quite some time to load them when there together with the
other reports on the same dashboard I made them also available as a
separate dashboard: http://mobile-reportcard.wmflabs.org/dashboards/apps.
The first three reports are about app edits showing the various stages of
the edit workflow: one for both Android + iOS total, one for Android only,
and one for iOS only.
The next four reports show basically the same data but from a different
perspective: how many times edit got clicked, preview, save attempts,
successful saves.
The last report shows the number of blocked "app users" on English
Wikipedia. For this report you are considered an 'app user' if you've
created the account on the Android or iOS native app.
Enjoy,
Bernd
Hi Designers,
Is there any reason we shouldn't put a search icon next to the "search"
text box in the app? (see image)
The reason I ask is:
- We've received more than one complaint on OTRS saying that the Search
field is not discoverable (because it doesn't look like a normal text box).
- Every other app that implements any kind of "search" functionality has an
icon, so it's universally recognizable.
-Dmitry
device-2014-08-29-123320.png
<https://docs.google.com/a/wikimedia.org/file/d/0BzcksMsMNpY1V0pLNjh0VGI5cjA…>
On 3 September 2014 13:34, Sjoerd de Bruin <sjoerddebruin(a)me.com> wrote:
> Any source for the release date of iOS 8?
>
The source was my lead iOS engineer and my user experience designer. The
real issue is that Apple hasn't officially announced anything, so sure,
we're kind of guessing. That's a fair point.
However, even if we're a week or so off, then this email still stands, as
the compatibility fixes need to be handled in the current sprint since it
runs to Friday 12th September.
Thanks!
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
tldr: Attribution for media on the mobile lightbox viewer is a bit
inconsistent right now, fixing it is IMO worthwhile and doable (and users
do care a fair bit about how it's handled) but you might land on disabling
mobile lightbox or trying a different approach. I understand the mobile
lightbox is not a top priority for the team right now.
- - -
Hi,
There's a bit of a discussion here
https://bugzilla.wikimedia.org/show_bug.cgi?id=69656
on how to do attribution in the mobile lightbox viewer. If you're not
involved with that, feel free to ignore the below.
Attribution is a hot topic for a lot of people, because it is viewed as
fundamentally being a matter of respect and recognition of their work. So
if you don't get why this is a big deal for people, please trust me that it
is, and that we need to show some senitivity in how we handle it. :)
Organizationally, we also want to be an example for how to use CC licenses
correctly, and how third parties should re-use content from our projects.
Since I've been participating in the related discussions on desktop MMV a
fair bit, let me try a concise summary of what the issues are. I'm CCing
Luis who can jump in with clarifications (Luis, one "legal requirement"
question for you below, feel free to answer offlist to Maryana/Kaldari if
you prefer).
1) Creative Commons licenses allow for attribution "reasonable to the
medium or means" by which a file is being utilized. That means some level
of variance between desktop and mobile may be defensible.
Other licenses (used for some files) may or may not include similar
provisions; even without them you could argue that the differences in
medium/means justify a different approach.
2) Lightboxes introduce additional step between user and attribution. We do
not show attribution right below the image in an article, and as you
introduce more steps, you stretch the "reasonableness" definition.
On desktop, the paradigm we follow is "Show required attribution wherever
possible, err on the side of including source information since it _may_ be
required" (the metadata is currently very messy on that aspect).
3) Small variations (such as not linking to the username, which makes some
usernames effectively meaningless without going to the File: page) can
stretch the "reasonableness" definition in the eyes of media contributors.
Note, however, that the username sometimes will point to e.g. a Flickr URL,
and will be ambiguous outside the context of Flickr.
4) Right now mobile MMV does not show any links related to the author, and
does not show the source.
- - -
The specific argument in the bug is that mobile devices have limited
displays and input precision and therefore the introduction of too much
detail can confuse and disorient users if they hit these links by accident,
and that the fallback to the File: page ought to be sufficient for
additional details.
There are two separate sets of questions here:
- What's the right thing to do to show the appropriate level of recognition
for media contributors? Can this be done without violating good UX
principles for mobile?
- What's the legal requirement, e.g., is it OK to omit the source link when
an author may explicitly request a source to be linked to?
Here's how I think this question should be decided:
* Hard legal requirements are non-negotiable;
* Legal and the community at large should be a partner in defining what
good attribution practices (beyond hard requirements) should look like, so
a recommendation from legal or repeatedly expressed community wishes that
are not a dealbreaker from a UX perspective should be taken seriously into
account.
My recommendation: Add the link(s) (including the source link if it
contains a URL), if you're concerned about link precision, throw some
mobile user tests at it and see if it actually causes a problem --
abbreviate if needed. But I'm OK with a different outcome, with full
consideration to the above issues.
I don't think that's actually very complicated, though getting abbreviation
and potential layout explosions from rich HTML content right while
retaining basic links may be the biggest development cost. Gergo / the MM
team may have some advice on how to handle it.
Thanks,
Erik
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation
Hi everyone,
Yesterday, Katherine, Tomasz and I met with Joe Castorena from Google’s
Android Play Partnerships team. I’ve split up the most relevant information
into a few separate emails, to keep the discussion on each separate point
focussed.
Tomasz put forward the idea of using the Wikipedia app as a code tutorial.
Have you ever been on the Android help pages online and seen code snippets?
Tomasz suggested that since our app is totally open source, they could
actually use living examples from the Wikipedia app on those pages if they
wanted. It’d be good PR and branding for them to use the Wikipedia app as
an example, and it would expose our code base to a much larger group of
people, and specifically those people would be developers!
This idea is obviously in its infancy, but I think we should definitely try
to push forward on this. Many thanks to Tomasz for suggesting this.
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation