Topic on Talk:Wikipedia.org add mobile app badges/Flow

I think this app-button experiment should be paused, and postponed for a medium-to-long-term future, for a few reasons:

• The portal improvements are starting to be well-received, with the recent auto-adjusting language items, and the highlighting of smaller wikis. We should focus on building off this success, instead of risking a step backwards. There are much higher priority improvements for the portal page, including replicating these upgrades to the sister project portals (unless that is already done), and automatically updating the article counts, and translating the sister project descriptions.
• The readers probably arrived at the portals with the intent of searching for something, and the app-buttons are a distraction from that task.
• The app-buttons do not funnel readers towards the wikis, which is the primary goal of the portals.
• The apps do not currently support the sister projects, which frustrates editors and readers alike.
• The app-buttons are placed below/next to the sister project links, which is thus even more confusing.
• The app-buttons are harder to translate, given the graphical nature and custom fonts. Having the apps available to non-English speakers is probably a priority, and whilst they'll be used to recognizing the visual aspects of 'app download buttons', it would still be nice to translate this, too.

That said, and whilst I do understand some of the other reasons why some people are not fond of the apps in general, I also appreciate that a huge part of the world wants "an app" for a few reasons (hence the dozens of existing externally created apps in the mobile stores): I/they appreciate the speed of software load (versus my android browsers which both take an age); they also want the easy installation on the "home screen" that installing an app provides (the non-technically inclined are less likely to discover how to add https://en.wikipedia.org/wiki/Special:Search ). Plus the variety of additional features that apps (internal and external) can more easily experiment with. So I do grok the impetus to both create the apps, and to promote the existence of our apps (especially given that we are helpfully supplying some less personally intrusive apps than I would assume many of the externally developed apps provide). But I respectfully suggest that this is a poor moment in time to do the latter, at our Wikipedia portal page.

As for criteria as to when a good time would be, I would suggest at the earliest would be after some more milestones are reached, such as the tasks given in my first list item. A much longer milestone would be my 4th list item, but that's less pragmatic, and there must be balance.

If these points are not judged to be sufficient rationale to pause the experiment, then I urge the creation of some sort of "success criteria" before the experiment (currently missing from the docs page, though possibly it appears within a phab task?), so that we know how the metrics that are collected will be interpreted, and thus know how the success or failure of the experiment will be judged.

Thanks for your comments and suggestions on this matter. However, I must admit I disagree with many of the points you've raised and I've numbered my responses to correlate with your bullet points in your post:

1. Portal improvements have been well received (yay!) and we will continue to update the portal page, thus building off of our recent successes of data collection and analysis - consulting with the community and rolling out regular updates to the page. The addition of the app download badges is simply just one of those updates that we want to do to make the portal easier to use and to enhance our visitors experience by enabling them to discover the information that they're are looking for.

-- Translating the sister project descriptive text is on our sprint board and is is actively being worked.

-- Replicating the wikipedia.org portal code to the sister project portals are not within the scope of the Discovery team at this time. We will, however, make the code available to the sister projects if they'd like to take advantage of the work we've accomplished on the wikipedia.org portal.

-- We are working to automate the updating of the language statistics, but it's not complete yet.

2. Readers arrive at the portal for a variety of reasons and we don't exactly know how or why; we've recently run two surveys to try and find out. The app badges are a way to educate and inform those readers that we have more ways for them to search and to find out more information within Wikipedia.

-- If the visitor doesn't want to download the app (or alternatively, they already have it on their mobile device) they'll ignore the app badges and go on about what they want to do on the portal page, which is extremely typical of any web site that has an app along with their mobile website and desktop site(s).

-- The search box will continue to be very prominent on the portal page, as it currently is, to facilitate easy access to all the knowledge in Wikipedia.

3. The app badges do not funnel readers and encourage them to only use the mobile apps; the apps are just an additional method to use to discover content within Wikipedia.

4. The mobile apps do make quite a bit of usage of Commons and Wikidata, in order to display the data that the user requests.

5. The app button area has a grey background and are apart (not in direct visual alignment) with the sister project links, so I'm not sure that they would ever be confused as a project on their own.

-- However, we can certainly take another look at the design to see if further distancing the app badges makes sense.

6. The app badges should be easy enough to translate as part of our gathering translations for the sister projects descriptive text work.

-- We had decided against using the more commonly used app badges so as to keep in line with the rest of the page's look and feel. We can revisit this idea, possibly as an A/B test to see which has more click-throughs.

I've updated the Portal Sprint board in Phabricator with many of these concerns and we'll prioritize them accordingly.