@RHo would have time to take a crack at it?

Note: On desktop, we can't do OS detection so we'll have to show both badges, on mobile, we can detect, so we can show only the badge for the current OS

@Nirzar sure, can put something together for iOS and Android.

@Nirzar I don't think we should start this on desktop as the path to download and usage of the app is much weaker.

Also, not sure we want to send to both iOS and Android, simply because there is 0 cost to playing it slow and we aren't sure how much traffic or churn it is going to generate. Let's start with sending iOS users to our app and see how that goes before sending Android users.

Just to address @JMinor and @Nirzar's comments about OS detection. The portal is responsive so it's the same page on mobile and desktop. We can detect if someone is on an Android or iOS device client-side, and show them only the appropriate badge.

For desktop, we don't have to show them either badge if the userAgent string doesn't match ios or android.

Let's start with sending iOS users to our app and see how that goes before sending Android users.

this works.

i think it would be easier for designer to think about this on all devices irrespective of what we will ship and test

@RHo we can still work on how it will look on all devices. for this test, we can use only the mobile version of it.

Hi there,

I've added mocks to pholio

M173 Mobile app badges on the Portal page

80

As I see it we can either go with using the standard badges from both App stores (Version A), or something like version B is to use our own badge design with text. My preference is Version B as it is much less obtrusive than the big black App store buttons, and also less jarring since we wouldn’t be seeing 3rd party logos below the Wikipedia ones on the portal page.

Mocks A04 and B04 show how it may look if we decide to do the hard sell and add badges on Desktop as well.

Although the standard badges are more well known and would likely drive more clicks, I strongly agree with Rita that B is much more in line with who we are. I also just think its nicer, visually :)

For the URL for the app store, please use:
https://itunes.apple.com/app/apple-store/id324715238?pt=208305&ct=portal&mt=8

Totally agree; design B is more visually consistent with the rest of the page.

The URL for the Play store should be:
https://play.google.com/store/apps/details?id=org.wikipedia&referrer=campaign_id%3Dportal

+1 to version B comments!

@RHo great buttons and I agree that its better to start with something more wiki branded than app branded. minor thing to consider: it might be worth increasing the perceived separation between the app and the sister projects (maybe thicken the line?). As is, it might be confused with a continuation of that list.

as is:

Version B FTW! :)

Thanks for the URL's to use as well!

I'm a bit confused about the end goal here:

If the priority is to make people download the app, I think version A is better.
If the intent is to simply make available a nice and discreet link to download the apps, version B looks much better.

Hi @JGirault - yes that pretty much the reason for the version B preference
from everyone; we want a way to let users know mobile apps by Wikipedia
are available for download, but not be overtly pushing them to do so.

Also @JKatzWMF I can put up another another visual style option that
differentiates these badges from the other WMF projects listed.

Hi @RHo - looking forward to the new style option! :)

Hi @debt – just updated the mock with style options.

M173 Mobile app badges on the Portal page

80

We could simply place the same version B style on a pale gray background; or make the entire banner like a button per Version C.

Version B
Version C

My pref is for Version C since it clearly differentiates from the other projects; is a button style similar but not as in your face as the standard app download buttons, and is a style that currently exists in the current site (see below).

@RHo these look great!

I would prefer version B. I have been working on new footer for articles and if we ever decide to let our readers know about the app on articles, B seems like it will fit nicely with the treatment that I was going for.

footer> https://phabricator.wikimedia.org/T133899#2287935

Just to be clear, it's not planned or we don't know if we even want to do that but just thinking ahead.

I think I also have a slight preference towards version B.
To me, version B is better at conveying the message that the app isn't a separate 'project' of WMF, but rather a different way of experiencing Wikipedia content.

@RHo This is awesome and thanks for addressing that concern! I will chime in for Version B as well for the reasons that @Nirzar and @Dbrant had and to maintain the 2-Dness of the page, but don't feel strongly.

Cool, if we don't want to overly differentiate mobile apps then Version B works for me too. @debt I will post assets for this shortly.

Thanks, @RHo !

Here they are.

App tile Android (2x and 1x size)

App tile iOS (2x and 1x size)

In T135441#2301558, @JKatzWMF wrote:

Also, not sure we want to send to both iOS and Android, simply because there is 0 cost to playing it slow and we aren't sure how much traffic or churn it is going to generate. Let's start with sending iOS users to our app and see how that goes before sending Android users.

There's the cost of questions like the one (rightly) raised by Tbayer above, and drama of why iOS and not Android, and moreover iOS is proprietary, etc.

I'd favor instead to show it to eg. 10% of both iOS and Android devices. I expect that would also provide interesting data about the platforms, while doing it separately, they wouldn't be comparable.

For me as a reader and internet user, if I saw that the app was avalible for iOS/Android when reading Wikipedia on my desktop it would be likely I would notice it and download it. To only show the icons for the specific OS user would be very disfavourable, imo. I'd rather see that these (both) icons would display for everyone, and not just when using such a device.

As for the different versions of the icons, I think that just having an icon with a "W" wouldn't gain any attention - these icons are used for a lot of things on Wikipedia, while the Apple/Market-icons is promint what they mean.

My guess is that most readers on mobile go directly to an article instead of a portal, and that's why I think that showing it on desktops would gain more downloads, than acually showing it for the mobile users.

I'd !vote for version A, and that both OS-icons is shown at all times, for everyone, even desktop users.

Hi @Josve05a, thanks for your input! :)

I agree with your comment that quite a few of our readers do a search in their favorite search engine and then go directly to the article, rather than hitting up the Wikipedia.org portal first and doing their search on that page. But, we do have quite a large number of users who use the portal every day - of which we're grateful and very happy about and want to give the best way forward to discovering all the knowledge that Wikipedia has.

The question on which icon(s) to use is difficult - should we use one that is more commonly recognized as an app download badge or use icons that are more Wikipedia branded. It's a tough question!

However, I do like your idea of showing the app download badges to everyone, regardless of if they're on a mobile device or on a desktop. It'll help those users realize that an app does exist and hopefully it'll be on an OS that they can use.

In T135441#2412945, @debt wrote:

The question on which icon(s) to use is difficult - should we use one that is more commonly recognized as an app download badge or use icons that are more Wikipedia branded. It's a tough question!

I like the idea (which I read somewhere) to do an A/B test, of both these icons - both for download/clicks, but also for UX/feedback... (However if shown on desktop, most would not click, but just search on the stores, so wouldn't generate many clicks). But that's just my 2c.

In T135441#2412992, @Josve05a wrote:

In T135441#2412945, @debt wrote:

The question on which icon(s) to use is difficult - should we use one that is more commonly recognized as an app download badge or use icons that are more Wikipedia branded. It's a tough question!

I like the idea (which I read somewhere) to do an A/B test, of both these icons - both for download/clicks, but also for UX/feedback... (However if shown on desktop, most would not click, but just search on the stores, so wouldn't generate many clicks). But that's just my 2c.

Agreed on desktop - visitors might not be too interested in an app. But, I've created a new mock that could be shown to all visitors (regardless of device or desktop) and gives the user the knowledge that we have apps for Android and iOS and also a page listing of other freely available apps to browse through.

Here's the mock (also in T138877):

Using this type of display, we could run a very long term A/B test to see which set of app badges (typical or Wikipedia branded) fares best for downloads. It's a nice idea!

@debt I've implemented you mock with links to the apps in all platforms (and third-party apps).

I have to say the design with all three links doesn't translate very well on mobile. These links might be hard to tap, perhaps for mobile the text should be centred and the links should all go on separate lines.

The links can go on separate lines, that's fine.

Plus, if we make the font size the same as the descriptive text, that will give us a bit more space on mobile. Would it be better if the W icon is above the text (creating 5 lines)?

@debt @Jdrewniak – how feasible would something like the mock below be to implement?

Key changes:

• smaller icon
• Centred text
• Split iOS/Android download 50% columns with store link on line break.
• per Deb's note, links text size reduced to same font-size as description text for projects

can we figure out which OS the mobile runs (under our privacy policy)? as an iOS user don't wanna see the playstore link and as an android user hide the appstore link?

a single call to action that says "download" will have better conversion IMO

In T135441#2685378, @Nirzar wrote:

can we figure out which OS the mobile runs (under our privacy policy)? as an iOS user don't wanna see the playstore link and as an android user hide the appstore link?

a single call to action that says "download" will have better conversion IMO

I'd imagine you could use some JS to check the user agent and display the links conditionally based on that, with a fallback to displaying all links if the user agent is indeterminate or if JS is disabled. It adds implementation complexity, of course. That's up to @debt. :-)

It adds implementation complexity, of course.

i think a single appropriate download action is much better for end user. as you said it's up to @debt because this would require increase in scope. but i would recommend for having cleaner experience for end user.

This seems like a basic thing to do if you look at from a non technical perspective. an Appstore link has no value to an android user.

@Nirzar @Deskana - this is only a test / experiment (T137495) at this time - we want to let all our visitors know that we have apps that are freely available.

If the test / experiment goes well, we can always refine it, based on OS or other factors.

At this time, I don't want to rule the possibility of a visitor to the portal that happens to be using a friend's Windows mobile device could see that there are apps available for different OS mobile devices. Same with desktop - if we rule out the fact that someone is using a Linux OS machine but has an Android mobile device, we don't want to not display the fact that we have apps.

@RHo - I like the new mock for mobile!

thank you @RHo! that mobile design looks great!

Change 319322 had a related patch set uploaded (by Jdrewniak):
Stats update for wikipedia.org

https://gerrit.wikimedia.org/r/319322

Change 319322 merged by jenkins-bot:
Stats update for wikipedia.org

https://gerrit.wikimedia.org/r/319322

Change 319327 had a related patch set uploaded (by Jdrewniak):
Updating wikipedia.org portal

https://gerrit.wikimedia.org/r/319327

Change 319327 merged by jenkins-bot:
Updating wikipedia.org portal

https://gerrit.wikimedia.org/r/319327

Mentioned in SAL (#wikimedia-operations) [2016-11-02T18:09:10Z] <thcipriani@tin> Synchronized portals/prod/wikipedia.org/assets: SWAT: [[gerrit:319327|Updating wikipedia.org portal (T128546) (T135441)]] (duration: 00m 47s)

Mentioned in SAL (#wikimedia-operations) [2016-11-02T18:09:57Z] <thcipriani@tin> Synchronized portals: SWAT: [[gerrit:319327|Updating wikipedia.org portal (T128546) (T135441)]] (duration: 00m 47s)

The links are now live on wikipedia.org portal page as part of the test outlined in T137495

👏👏

The app download links have now been updated for campaign tracking (during evening SF swat).

Based on the results the long term test of the addition of the Wikipedia / Wikimedia app links to the Wikipedia.org portal page - all signs have shown that the addition of the links have been successful in aiding discovery for our visitors that there are mobile apps available for download.

The test results are calculated in T146807 for November and December 2016 for mobile and desktop devices as well as for iOS, Android and app page clickthroughs.

We've also had several calls to translate the text of the app links and now that the test has concluded, I've updated T154350, asking for translations to be added to translatewiki for these links, so that we can add them to the portal page (along with the other translations as described in T142582).

Since the app links will now be a permanent part of the wikipedia.org portal page, we will also add them to the portal dashboard stats, as described in T154634.

Third time's the charm.

Have the various concerns raised at https://www.mediawiki.org/wiki/Talk:Wikipedia.org_add_mobile_app_badges been addressed?

Hi @MZMcBride, yes, I believe that all the concerns have been addressed in the various tickets that were opened as a subtask of the epic ticket T135441 and in the comments on the talk page.

Please let me know if something hasn't been answered to satisfaction.