Mobile-l September 2014

mobile-l@lists.wikimedia.org

35 participants
51 discussions

[Apps] Trial of separate Trello boards for iOS/Android
by Dan Garry 09 Sep '14

09 Sep '14

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

1 0

Jobs page doesn't work
by Moiz Syed 09 Sep '14

09 Sep '14

Our jobs page doesn't work on mobile web. I was trying to send someone this page for the mobile web job and it wasn't good experience. This is the first thing a potential job candidate sees, we should fix this quick. Thanks! Mobile: http://m.wikimediafoundation.org/wiki/Work_with_us Desktop: http://wikimediafoundation.org/wiki/Work_with_us

7 9

[Apps] User testing of rolled-up disambiguation
by Dan Garry 09 Sep '14

09 Sep '14

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

1 0

Re: [WikimediaMobile] Pulling the Commons app
by Rachel diCerbo 08 Sep '14

08 Sep '14

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>

1 0

VE edits & editors in first 24 hours
by Maryana Pinchuk 04 Sep '14

04 Sep '14

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

2 2

new app specific reports
by Bernd Sitzmann 04 Sep '14

04 Sep '14

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

1 0

Search icon in Android app
by Dmitry Brant 04 Sep '14

04 Sep '14

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…>

4 4

Re: [WikimediaMobile] [Apps] Working on iOS 8 compatibility fixes
by Dan Garry 04 Sep '14

04 Sep '14

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

2 1

Media Attribution on Mobile
by Erik Moeller 03 Sep '14

03 Sep '14

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

1 0

[Apps] Our app code on the Android help pages?
by Dan Garry 03 Sep '14

03 Sep '14

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

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

Mobile-l September 2014