Page MenuHomePhabricator

Serve the Download App banner from mobile web (restricted to Finland only)
Closed, ResolvedPublic

Assigned To
Authored By
Vibhabamba
Jun 25 2015, 7:39 PM
Referenced Files
F1904716: image (1).png
Aug 20 2015, 12:07 AM
F1904717: image.png
Aug 20 2015, 12:07 AM
F1497168: Nearby_Ring.svg
Aug 14 2015, 11:36 PM
F417207: android_dismiss.png
Aug 4 2015, 10:56 PM
F417048: android_dismiss.png
Aug 4 2015, 10:54 PM
F416274: android_a.png
Aug 4 2015, 10:44 PM
F416276: android_halfpage.png
Aug 4 2015, 10:44 PM
F416275: android_b.png
Aug 4 2015, 10:44 PM
Tokens
"Dislike" token, awarded by Krenair."Dislike" token, awarded by Dzahn."Heartbreak" token, awarded by Jorm."Dislike" token, awarded by Ricordisamoa.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

JKatzWMF (Jon Katz) & Dbrant to add acceptance criteria.

@Deskana fundraising the way we do would be in violation of finnish laws, so we dont fundraise there...so experimentally moving traffic to apps is risk free from that perspective.

That being said, there might not be enough fins on line to drive meaningful results...5M people....means 2M mobile WP users a month? With a CTR of 0.1% (Which is pretty good for an install), we would have 2000 clicks to the app store, and maybe 1000 installs?

1527-play-banner_framed.jpg (1×1 px, 72 KB)

Sample Pattern for Android

Link about banners on Android (Doesn't seem to be a heavily used pattern on Android since Google provides app download entry points in search)
https://signalvnoise.com/posts/3717-google-play-banner-design

Yelp mobile web banner on Android:

device-2015-07-06-181531.png (1×1 px, 680 KB)

Created https://phabricator.wikimedia.org/T105561 to make sure we sync up with Research on methodology.

This is the current design we are working with. I plan to add two color options and the full page version.

Appsdownloadbanner.png (1×746 px, 147 KB)

Is the banner not dismissible? It can get annoying.

Yep, all fundraising banners include a close X. We will also have a close on these Finland banners and will limit the number of times they are shown to each reader.

do we have updated banners for this year? I'd love to see a slightly darker/more prominent background color, even just a #f5f5f5, because those look like plain links as opposed to something we're trying very hard to point out. thoughts?

Here are some of the current designs.

android_a.png (3×1 px, 258 KB)

android_b.png (3×1 px, 258 KB)

android_halfpage.png (3×1 px, 273 KB)

do we have updated banners for this year? I'd love to see a slightly darker/more prominent background color, even just a #f5f5f5, because those look like plain links as opposed to something we're trying very hard to point out. thoughts?

f5f5f5 is actually pretty light.

the proposed set of greys is

@colorGray4: #333;
@colorGray4: #444;
@colorGray5: #555;
@colorGray6: #666;
@colorGray7: #777;

I wouldn't recommend going any darker than #333 for the background.

Is the banner not dismissible? It can get annoying.

I initially imagined that the banner just dissolves if the user starts scrolling, that is what we do on the android app for onboarding banners.

If we want an explicit button, we need to increase the height of the banner to have safe click areas of 45 px with adequate padding between actions.

android_dismiss.png (854×449 px, 61 KB)

Agreed that f5f5f5 is pretty light; I didn't know if there was a desire for a super-light look for some reason (since the old design shows completely white) or what, so that was a compromise suggestion. :)

Love the idea for dissolving. I just feel there could be some feeling of trickery/entrapment if there is no way to permanently get rid of banners....after the dissolve, would the banner reappear if you scroll back up?

Let's do some quick testing of these ideas...dissolve vs. buttons.

Here's a preview of the first banner. I've still to add the link and the logic that hides it after 1 view.
https://en.m.wikipedia.org/wiki/Tern?banner=Aug2015_app_banner_1&force=1

I didn't see the second one coming. The first one looks amazing.

@Pcoombe these look great! Can we make some minor text updates?
Banner 1 - "Discover more.
Try the free Wikipedia app."

Banner 2 - "Want to discover more?
Try the free Wikipedia app: Learn what’s nearby, read articles offline, find beautiful images, share your favorite facts, and more."

I've got the Finnish translation requests in, I'm guessing we'll get them on Monday.

Hi Peter,
Attaching the SVG file for the ring around the image.

The image itself is a 124 px mask of any prominent location in the world.
I was thinking Eiffel tower - https://commons.wikimedia.org/wiki/Category:Eiffel_Tower
Now I know that picking one location as a global is not a great idea, but we can't ask for location permissions to actually show something nearby, so in this one case I think its ok.

Hi Peter,
Let me know of any questions/ comments.

thanks
Vibha

Hey @Pcoombe - a copy update from what's up there vs. what's in the doc:

English: https://en.m.wikipedia.org/wiki/Tern?banner=Aug2015_app_banner_1&force=1
should say "Try the free Wikipedia App" instead of "Try the Wikipedia App"

@Vibhabamba could you confirm that the design looks good?

Actually, looks like the button for the banner 2 is good. Updating my previous comment to clarify.

First Style Tweaks
Need more vertical padding between the label and the button edges so it feels like a comfortable target.
Increase top and bottom padding by 10 px.

image (1).png (594×379 px, 96 KB)

2nd Style Tweaks
Button color is #00AF89
Need 20 px padding/margin between the app icon and the star rating.

image.png (594×377 px, 71 KB)

Thanks team. I'm not sure what the normal Reading process is for closing tickets - but I think we can probably close this one. @Vibhabamba will you update if there's anything else that's required to close?

These look great. A question about the URL parameters though: Do we really need to store the page name where the user clicked the banner? (referrer_url : window.location.href , in this example: https://en.m.wikipedia.org/wiki/Tern )
In case nobody is planning to use that data, I would suggest removing it for privacy reasons and just using the project name instead (e.g. via $wgDBname).

@Tbayer There is actually a significant benefit to passing the page name in the URL parameter. This way, after the user installs the app, it will be possible for the app to navigate directly to the page that the user was browsing in Mobile Web, without the user having to search for it again.

I recall studies from several "open web" type organisations that banners like these are annoying to users. Especially because most websites tend to implement them in a way that produces poor user experience (it's hard to get right).

At least for iOS – Safari has a standardised way that is more native and integrated without disturbing the page flow and in a location and style that the user expects. It also takes care of not showing it every time, not showing it if the user has it already, not having it bump down the page like most central notices do, etc.

Related:
http://googlewebmastercentral.blogspot.com/2015/09/mobile-friendly-web-pages-using-app.html
http://davidwalsh.name/apple-itunes-app
http://www.hongkiat.com/blog/itunes-meta-tag/
https://developer.apple.com/library/ios/documentation/AppleApplications/Reference/SafariWebContent/PromotingAppswithAppBanners/PromotingAppswithAppBanners.html

Wow. This is a terrible, terrible thing that is happening.

Please don't become another one of "those sites" where you try to force people into a shittier version of the website. Just. . . just please don't.

That being said, there might not be enough fins on line to drive meaningful results...5M people....means 2M mobile WP users a month? With a CTR of 0.1% (Which is pretty good for an install), we would have 2000 clicks to the app store, and maybe 1000 installs?

Considering this question was not answered and T105561: Review Finland banner testing strategies has no answer w.r.t. how this is being measured...I'm not sure what's to be gained out of this. It seems awfully rushed...

Dzahn subscribed.

Please don't become another one of "those sites" where you try to force people into a shittier version of the website.

I agree, that is very annoying when it happens on other sites.

@Tnegrin: I'd appreciate it if you could respond to the propriety concerns raised in this task and elsewhere.

http://googlewebmastercentral.blogspot.com/2015/07/google-case-study-on-app-download-interstitials.html

Learn from others.

The current implementation looks like it heavily obscures the page contents, so you're likely to drive users away at a large rate while getting a very small percentage to install an app that's regularly less featureful than the mobile version.

Seriously. Did anyone do any research about interstitials like this before it moved into the "let's do it" phase?

http://googlewebmastercentral.blogspot.com/2015/07/google-case-study-on-app-download-interstitials.html

Learn from others.

The current implementation looks like it heavily obscures the page contents, so you're likely to drive users away at a large rate while getting a very small percentage to install an app that's regularly less featureful than the mobile version.

In terms of features for readers, I think the app is better and has more features. It has lead images and descriptions in production, tables are collapsed, it's been more optimised for speed, has a nifty implementation of nearby, and so on. A lot of effort has gone in to honing it. Web has none of this. For editors, it's unlikely that the app really offers anything substantial, and as you point out; many crucial editing features are missing.

I agree with you on the obscuring of content. That doesn't make sense to me.

It has lead images and descriptions in production, tables are collapsed, it's been more optimised for speed, has a nifty implementation of nearby, and so on. A lot of effort has gone in to honing it. Web has none of this.

Imagine if a quarter of the effort spent on a closed-platform project (which, as far as I can tell, is mostly about . . . well, I'm not sure. I've never heard a good business case for writing apps) - imagine if a quarter of that effort had been spent on improving the mobile web!

We'd not be having this conversation and there'd be a whole team freed up to work on other toys.

@Tbayer There is actually a significant benefit to passing the page name in the URL parameter. This way, after the user installs the app, it will be possible for the app to navigate directly to the page that the user was browsing in Mobile Web, without the user having to search for it again.

And at the same time there's also a privacy loss. We're now sending what page the user was on to Google for them to track the user however they see fit.

Folks -- I'm going to respond to the wikitech thread; let's continue the discussion about the why's behind this project there. It's more accessible and it would be better to have a single discussion thread.

-Toby

For the sake of completeness, could the results of the analysis (i.e. the outcome of this task) be posted here?

We're going to post publicly -- ticket should not be closed until this
happens. Anne/Jon are point since they both worked on the analysis.

Ah, sorry. Will let Jon close when ready.

We're going to post publicly -- ticket should not be closed until this
happens. Anne/Jon are point since they both worked on the analysis.

Ah, sorry. Will let Jon close when ready.

It's been ~4 months, When will the analysis be posted?