Talk:Wikipedia.org add mobile app badges

As the Wikipedia mobile apps, mobile web, and other Wikipedia apps have gotten quite a bit of interest lately (via blogs, email postings, enhanced visibility in app stores) we felt it was time to give this a test.

We'll go ahead and add links on the wikipedia.org portal page (in the footer) to:

• download the free Wikipedia app for android
• download the free Wikipedia app for iOS
• view list of all Wikipedia apps

We'll coordinate with the Reading/Mobile teams on the analysis that will be done after the links have been in production for a period of time.

This analysis will determine if adding the links to the portal page have provided sufficient information to our visitors that not only do free Wikipedia apps exist, but that they have hopefully sparked curiosity in finding auxiliary ways to read and contribute to Wikipedia.

We're grateful for the conversation around this topic - it's been very enlightening!

Here is a mock of the additional links:

new links for portal page

Update: the new links are now live on wikipedia.org to provide the knowledge to our visitors that there are additional ways for discovering knowledge within Wikipedia. The links will be shown to every visitor, regardless of OS platform or device.

As a reminder, this is a long term test that we'll run and collect data on. Based on future data analysis and community feedback, we'll determine if we want to keep the links on the portal site or take them off.

In case this is useful, for background information about Wikipedia mobile apps, see w:List of Wikipedia mobile applications and related pages under "In other projects" and "Languages" in the navigation column.

I am not sure this is useful, because linking from www.wikipedia.org to a Wikipedia article could be problematic in many ways. Other than this, we have Wikimedia Apps, which focuses on project information and can also be a problematic destination for readers. Mobile projects were initially in Meta, and they were moved to mediawiki.org, so I think as for today there are no other alternatives.

We can display a happy medium for this: have a small section near the bottom of the portal page that will show all download options to all visitors to the page (regardless if the user is on a mobile device or desktop):

• download free app for android
• download free app for iOS
• view list of Wikipedia mobile apps

I've created and uploaded to Phabricator a sample mock of what this could look like.

We could make a new Wikimedia Apps landing page, something like apps.wikimedia.org.

Yup, we have this page: https://en.wikipedia.org/wiki/List%20of%20Wikipedia%20mobile%20applications but, it's not nearly a friendly url as the one you suggested.

It's not just the nice URL, but the page layout and content.

Agreed - it could use some help to get it up-to-date and easier to navigate! :)

I actually like the idea of having a simple, well-designed apps "landing page" at apps.wikimedia.org a lot.

(On a separate note, I should probably point out for the record that WMF doesn't control the "List of Wikimedia mobile applications" article on English Wikipedia.)

"What does this mean? Is it going to link directly to apk and ipa files? I assume you mean Google Play or the iOS App Store here?"

@Legoktm I hope you don't mind, but I moved your question here to better respond. I see your concerns on linking to the stores. Thank you for adding them to the page. As for where we link to - Yes, the stores did seam the most logical to the Portal team. Especially for non-technical folk who are OK with using apps stores.

I though about alternatives to alleviate your concerns. At the moment I can't come up with a good one. I thought maybe having a link to other locations like List of Wikipedia mobile apps? But that only increases the taps to get to the app and that page, in turn, links to the stores. :/

Loading an app outside of the app store in iOS is a pain if not near impossible. I'm not sure there is a way to deploy an .ipa with the number of current Wikipedia mobile app users. I can't speak to the process on Android.

Regardless, if we add a link to the mobile apps, linking anywhere but to the app stores would reduce the amount of people who could actually get the app running, blah, blah, blah. I'm sure you already know this. :)

I could be wrong, but I think encouraging people to bypass the stores would have the side effect of having them not be notified about updates (including security updates). If we're going to have non-technical people use the apps, I think we really do want them to use a store.

Maybe we could offer f-droid as an option for android users?

Are you sure that updates don't appear on apps when installed from outside the official app store?

Technically speaking, it's certainly possible for an app to "self-update" by downloading and installing updates periodically on its own, but most (including us) don't do this because it violates the Google Play terms of service and will get an app banned from the app store. (At least that's my understanding; I haven't looked it up.)

I think, like Google Play, F-Droid sends push notifications when updates are available, but to be honest I'm not 100% sure about that. (I tend to keep what's installed on my phone to a minimum.) If you load an APK directly from our servers, the only update notification you get is via an announcement on the mobile-l email list.

I just noticed that there are legitimate security concerns about f-droid, so I withdraw that suggestion.

Like what? I could just as easily say there are significantly bigger and just as legitimate privacy concerns about Apple and Google.

F-droid is definitely an improvement on the privacy and open source transparency fronts.

My initial reaction was based on information in the enwiki article on f-droid. Now that I have done more reading, it seems that there were legitimate security concerns in 2013, but that they were apparently all resolved by 2015. Assuming the security issues were actually resolved, I don't see a problem supporting f-droid as an option.

@MHolloway (WMF) I flipped a coin and answered here instead of replying to your version of the same question.

Lengthy/nerdy discussion starting in 2013 and ending in 2015: https://github.com/WhisperSystems/Signal-Android/issues/127

Most folks generally go to the google or apple store to get the apps that they're interested in which are verified virus free and also have the ability to get notifications of updates easily. Obviously, there are many other people that would rather bypass those stores (even for a free download) but I'm not sure that the Wikipedia Apps Team have the ability and/or time to create a separate download that can be loaded onto a mobile device.

+1 @DTankersley (WMF). People who prefer apps will likely go looking for them in the app stores - I think we should meet our users where they are to provide them the best service we can.

My personal preference would be at least to offer an F-Droid link as an option alongside Google Play. Based on past pageview statistics I wouldn't expect many to avail themselves of this option, but it seems to me there are important affinities between the free knowledge and free software movements, and free software is important to many of our developers and community members (myself included).

@KSmith (WMF) Are there security concerns specific to F-Droid that you're seeing, or are you talking generally about the risk involved in installing apps without the benefit of Google's malware scanning? FWIW I'm comfortable having F-Droid installed on my personal devices.

Reading this thread again, I'm not sure everyone is aware, so just to be clear, we already offer the Android app in F-Droid (and at https://releases.wikimedia.org/mobile/android/wikipedia/) in addition to the Google Play store.

I do think, as someone mentioned elsewhere, that we'd want to be in contact with F-Droid before putting up a link to avoid the possibility of overloading them with unexpected traffic.

"Native" mobile apps are encouraging and giving into walled gardens - something that Wikimedia should not be promoting on such a prominent page. Pushing people into closed platforms is the wrong direction to go in.

Well, of course resources dedicated to native applications can't be spent on improving a more generic solution, like the web interface. I'm not sure you may say it encourages walled gardens however, as long as this apps have no "exclusive feature", it may provide some integration conveniences, but as far as I know, no service that you can't access if you don't have a device with this or that system.

Why can't those resources be spent on improving the generic solution?

There are resources spent on "generic" solutions, like Flow that we are using here. Putting all resources on a single solution or trying to provide more ease of access through a more diversified ecosystem is an interesting topic, but I'm afraid it don't belong this thread. Please feel free to join/launch discussions on this topic where it's the main point, and let's try to stay focused on providing feedback on the idea and mockup proposed here.

Wikimedia is investing substantial resources in these Wikipedia apps as part of a plan reviewed, approved, and renewed through WMF strategy, annual plans, quarterly goals... As long as we develop, support, and offer these Wikipedia apps to users, I don't see why we shouldn't feature them in www.wikipedia.org, where they are fully on-topic.

"Pushing people into closed platforms is the wrong direction to go in" might be a good discussion topic, but I think the strategy should be changed first, and then our plans and a page like www.wikipedia.org would follow, not the other way around.

Let's stop developing and supporting these Wikipedia applications instead. Sounds great.

I agree with Legoktm. In addition to the points he makes, we absolutely cannot and will not advertise for Android™ or iOS on Wikipedia's home page.

During the WMF Strategy consultation, 462 users expressed their opinion about how to reach to new users. The connection between mobile (web and apps) and better reach to new users was a common theme. On the other hand, the idea of stopping the development of the Wikipedia mobile apps doesn't seem to have community backing in those contributions or in any other strategic / planning discussion I am aware of.

Once the justification for continuing the development of mobile apps is clear, it only makes sense to promote them where we think new users will find them. www.wikipedia.org is one of those places. Informing our users that such mobile apps exist is a logical step. The odd situation is to agree that mobile web and apps are important for our strategy, to develop apps that actually get good reviews and many downloads, but then not even mention them in a place like www.wikipedia.org.

I understand your disagreement. I am not fond of Android and iOS myself, and in the past I have invested a portion of my life in the development of a slightly-more-free mobile platform. However, it seems clear that the Wikimedia consensus points in the direction of using these mobile platforms as a way to reach out to more users and as a channel to distribute free knowledge. I believe there is a way to implement this strategy without blatantly advertising for Android and iOS.

So if our users ask us to ignore and bypass one of our values, that makes it okay to do? I don't think that's how Wikimedia works - we uphold our values even when it's tough and makes it more difficult now - for the hope that in the long run we will be in a better place.

I disagree that building iOS and Android apps are "giving in to walled gardens". Millions of people use these apps to read Wikipedia's open content which is the same content that is available in other channels. The code is open source and people who are not employed by the Foundation are encouraged to contribute. Other people have pointed out that our communities are generally in favor of app development and we've been consistently transparent about our intentions.

Hi @TNegrin (WMF), I don't see how what you've said don't make the iOS and Google-Play-Android environments *not* walled gardens. From that page: A closed platform, walled garden or closed ecosystem is a software system where the carrier or service provider has control over applications, content, and media, and restricts convenient access to non-approved applications or content.

How does the app being open source, being worked on by volunteers, and our communities allegedly being in favor of it, make it not a walled garden?

"control over applications"...at least on android, applications are somewhat uncontrolled.

"content, and media"...I'm not aware of android limiting what content I can access.

So I'm having a hard time seeing android as a "walled garden", in our context.

Maybe mobile users after tapping the badge on the home page could be presented with the option of downloading from:

1.) Google Play / App Store

2.) Wikimedia Servers (https://releases.wikimedia.org/mobile/android/wikipedia/)

That way walled garden issues could be mitigated because the clear FLOSS option is there, and users more comfortable with Play/App stores would have their walled garden choice as well.

And there are alternative app stores as well.

Hi VGrigas (WMF). If we must advertise the mobile apps, a "mobile view" link similar to what we have on the desktop site seems reasonable.

I've been thinking about this a bit more over the past week. Here's an analogy:

If a user visits the portal page using Internet Explorer 8 (a pretty sucky browser), should we offer them links to download Google Chrome (a proprietary browser which has a FOSS way of using it (Chromium), but most people don't) and Opera (an entirely proprietary browser). I think nearly everyone would be opposed to this.

In this context, IE8 is the user's browser on their phone, Chrome is the Android app, and Opera is the iOS app. What makes that situation different?

Hi @Legoktm, I see it as different in a couple of ways.

Firstly, we are not promoting to users that they should be switching to view Wikipedia on mobile apps instead, but are merely letting users know that there exists an iOS and Android app by the WMF. It is at the bottom of the portal page presented alongside other projects and intended to create awareness in the same way as how we show MediaWiki or Wiktionary here.

Secondly, we are not offering a something akin to Chrome or Opera to IE users, since these mobile apps are by the WMF, not a 3rd party tool. A closer equivalent would be if we were to promote viewing on Wikiwand or Google's search knowledge graph, which is not being done.

And addressing the concern raised in this thread, the intention right now is to show a respective iOS or Android badge only to those who access the portal page via an iPhone or Android device; so these are already people who have made the decision to use "walled gardens" in some respect. This merely provides another alternative for people to access and engage with Wikipedia, arguably in a less 'closed' way (since our apps are open source) than if they view it in their native browser apps like Safari or Chrome.

Hello, I support the proposal to add "badges" (I usually call those "buttons") somewhere in the main Wikimedia pages. However, I disagree that mobile app badges should take precedence over website links. I think that it would be best to put the badges of each website on the respective main pages. So the Wikipedia app would appear on wikipedia.org, the Commons app on commons.wikimedia.org, etc. If you want other projects to appear on wikipedia.org, we could discuss it. But it shouldn't be the mobile app badges.

Hi. Historically Meta-Wiki was where wikipedia.org was hosted and its content was discussed there. A small Wikimedia Foundation team has moved the portal's hosting, moved the discussion about the portal's content to mediawiki.org, and now proposes adding advertisements for Apple and Google to the home page. Wow.

Hi @MZMcBride. Do you think it's appropriate to repeat wrong statements like "A small Wikimedia Foundation team has moved the portal's hosting" in order to misguide other readers on this discussion page?

Hi Malyacko. What specifically about my statement(s) is wrong? The www.wikipedia.org portal was previously hosted on Meta-Wiki (meta.wikimedia.org). That's a fact. This portal's contents, and the contents of the other www portals, were moved by a small Wikimedia Foundation team without any community consensus. That's also a fact.

Instead of discussing the portal's contents on the established Wikimedia community site (Meta-Wiki), this discussion is taking place on an obscure part of mediawiki.org, a wiki that's used for technical documentation of the MediaWiki software. Nothing untrue there!

What are you disputing exactly? Or are you just using your volunteer account to cast aspersions on people who are deeply critical of the unsavory ways in which the Wikimedia Foundation has acted here?

>now proposes adding advertisements for Apple and Google

In developing these links the portal team actually shied away from using the vendor-specific 'badges' for their respective stores. The desire is for these links to be unobtrusive, not advertisements for particular vendors.

>The www.wikipedia.org portal was previously hosted on Meta-Wiki (meta.wikimedia.org).

Yes and after a lengthy discussion with the community, including the primary volunteer maintainer of the portal, it was moved to gerrit. You know this as you took part in that conversation.

>and the contents of the other www portals, were moved

I don't think this is true. IIRC, only the content of the Wikipedia.org portal was moved to gerrit. The resulting code after running this module for the other portals is hosted in (and deployed from) gerrit. The content of the other portals are still updated through a meta wiki page. You, or others reading, might be more familiar with how this works than I. Please correct me if that's not the case.

>by a small Wikimedia Foundation team

Small is subjective. Yes, the portal team is small in comparison to other WMF teams, but the decision to work on the Wikipedia.org portal was made by the Discovery department. These improvements, tests, etc. were not done on a lark by a small team.

>without any community consensus

Again, see above.

>Instead of discussing the portal's contents on the established Wikimedia community site (Meta-Wiki), this discussion is taking place on an obscure part of mediawiki.org,

Well, you found it, so I guess it’s not that obscure! :) I did include a link to active and backlog tasks on the Project Portal page.I also recently updated that page to reference the WMF's work around the Wikipedia.org portal specifically. A small gesture admittedly, but the team is not trying to subvert anything here. When I first started at the WMF I saw that not every team had a page to document and discuss their work. WMF engineering teams have had documentation on their projects and work on MediaWiki.org for quite some time. When the product manager asked where to have a chat about her team’s work with the portal I suggested having it along side the other team pages on MediaWiki.org. I think it's great to have more documentation about what our product teams are working on. I hope you agree. It was an oversight on my part to not consider Meta. My apologies.

I’ve also been trying to update said information on Meta to be more clear on how the portals are updated. If you think we should have this conversation at meta:Talk:Project Portals then let’s do so.

>What are you disputing exactly?

I can't speak for Malyacko, but my impression is that your comments (here and in general) are not in good faith.

Chris addressed the look of the "badges".

Speaking as an android user, and not as staff, I appreciate knowing when apps are available, so I can make an informed decision whether or not to use them. In some cases, the app offers amazing features and is vastly superior to the web. In other cases, the app is either terrible, or simply not compelling. Since our apps exist, I think it would be unfair to our users NOT to let them know they exist, so they could make up their own minds whether or not to use them. This isn't about doing favors for Google or Apple--it's about empowering users by giving them options. Again, that's just my personal opinion.

Victor hints at a solution that I also think would be acceptable: a "Mobile apps" link that shows can index of available Wikipedia apps. This is similar to how others have solved the problem Legoktm mentions regarding out-of-date browsers. Instead of suggesting a particular browser, sites suggest that users visit an index page such as <http://browsehappy.com/>. This gives the user a choice among vendors and doesn't advertise for a specific vendor in the way that, for example, File:Version B-02-Wiki-Mobile Portrait 375w.png would.

Thanks for your constructive and positive feedback!

I added that suggestion to the phabricator ticket on this topic. In order for this approach to work, we'll have to display some sort of download badge to all users - not just to targeted mobile devices. Using a single index page, users can can decide which Wikipedia app to download by vendor and OS platform.

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.

Having the grey background (the version with full page width have my preference) show that the entry is really distinct, that's seems really good. As an improvement suggestion, I would recommend to use a target platform symbol to catch attention of interested users, rather than the undistinctive Wikipedia logo. For example with on Android platform.

Hi Psychoslave. Do you think it's appropriate for a site like Wikipedia to advertise for Android with both text and images?

If that is a conditional information based on the system used, well the user probably already have an Android device. I don't feel like it's worst than providing specific configuration for misc. browsers in documentation for example. It's not like it would say "discover new shiny features exclusive to android v.X.Y.Z devices that you may buy here".

If we had some native application for desktop system, for example a "GNOME Wikipedia", I would find it great to see it promoted with the same means, no more no less, not trying to sell GNOME to other users.

Hi and thanks, we're glad you like it! Yes, we had discussed using a typical icon for the download badges and decided that we wanted a different icon for the page. An icon that isn't necessarily immediately identifiable like the existing apple or google store download images but something that would fit in nicely with the other icons at the bottom of the page.

I agree that the mocks look really well done.

Nevermind. I noticed the app has been deprecated since 4 months ago. I think it's time for WMF to take it off the Windows Store, but I digress.

The foundation maintains (or used to maintain) a version of the Wikipedia app for Windows Store. Should a button for that be included as well?

I'm really happy to see this happening, and hope this represents a step in publicizing our apps more on the sites in general. I evangelize the Wikipedia app to everyone I know :)

Are there plans to test the location of the app on the page and see where drives most engagement? I'd be interested to see if higher placement allowed for more app conversions, but we'd need data available to tell us if the user actually continues their search after download, either in the app or on the portal page.

Hi and thanks for evangelizing! :)

Please see my comment above (here) as I think it'll help to answer your question on page placement.