1144844 - Simple mobile-friendly page to send users to download iOS or Android - Development

Status: RESOLVED INVALID

(www.mozilla.org :: Pages & Content, defect)

Description

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

We will be creating a simple jump page we can send users to download iOS or Android versions of Firefox.

This is a result of the conversation in https://etherpad.mozilla.org/sms-email-mobile 

Primary application is a place to send a user after SMS or email activations. But could have other applications such as social sharing.

Requirements:

- Simple (image, line of copy, CTA)
- Mobile friendly

Comment 1

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

:pmac, :jpetto

How confident are we in our ability to detect Android vs. iOS?

It seems to be an industry standard to show very platform specific content (e.g. just show iOS button if browsing /mobile on iOS), or do a flat out redirect as we previously discussed.

Is the following reasonable:

Case 1: we are 90% sure they are iOS

- iOS image
- iOS copy
- iOS large CTA to App Store
- small Google Play text link

Case 2: we are 90% sure they are Android

- Android image
- Android copy
- Android large CTA to Google Play
- small App Store text link

Case 3: unidentifiable UA

- generic mobile image
- generic mobile copy
- two equally large buttons (iOS or Android)

I couldn't find another company implementing Case 3 by default, so I'm hoping we can use 1/2.

Let me know your thoughts.

Comment 2

[Paul [:pmac] McLanahan]

My feeling is that the thing to do is:

if is_iOS:
    show case 1

else:
    show case 2

I don't think we need a 3rd thing. If they've gotten to the page and have neither iOS or Android then they're on their own. I use that order since it's much easier to definitely detect iOS than Android.

Comment 3

[Jonathan Petto [:jpetto]]

I agree with pmac. iOS detection is easier, and Android has the bulk of the market share.

I don't know what our non-iOS, non-Android mobile stats are, but I bet they're low enough to not specifically code for at this time.

Comment 4

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

How confident are we of desktop detection? This may sound edgecasey, but we are sending people here from email, so there will be some traffic.

Comment 5

[Jonathan Petto [:jpetto]]

UA detection is a dirty business. We should keep it to a minimum. I think case 2 (Android default) is fine for desktop users who may land on this page. As long as the copy/page intent is clear, we should be good.

Comment 6

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

I'm hoping the dirtiness is mitigated by the fact that we're not locking anyone out of content or redirecting users as a lot of our peers do. Our worst case scenario is presenting a user with equally weighed download buttons (case 3).

Giving desktop and non-Android/iOS visitors the Android heavy CTA is pretty messy. We'll be recommending case 3 as described above for these users.

Comment 7

[Paul [:pmac] McLanahan]

(In reply to Cory Price [:ckprice] from comment #6)
> Giving desktop and non-Android/iOS visitors the Android heavy CTA is pretty
> messy. We'll be recommending case 3 as described above for these users.

I disagree and I think you're misunderstanding me. We CAN NOT have a high confidence that we're dealing with a non-Android user. This page is specifically for mobile and thus will say something along the lines of "Download Firefox for your mobile". It'll have our two offerings of Firefox for mobile on it. Android version first for all but iOS users (who we can confidently identify) seems the best solution. If you want a different look for a desktop sized screen with both buttons side by side or something like that then fine. But as far as UA detection I think it'd be unwise to believe that we can reliably detect Android.

Comment 8

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Thanks Paul/Jon for your input.

How is this:

if is_iOS:

show case 1

else if is_mobile:

show case 2

else:

show case 3

I know it's not perfect, but hoping we can come to a compromise.

Comment 9

[Paul [:pmac] McLanahan]

Works for me. Thanks Cory.

Comment 10

[Jonathan Petto [:jpetto]]

Just to clarify/confirm how & where the logic will be performed:

When the page loads, prior to displaying any content, we will use JS to see if the user is on an iOS device. If they are, layout will be iOS specific at all screen sizes - iPhone portrait (320px wide) to iPad landscape (1024px wide).

If we do not think user is on an iOS device, layout will be Android specific up to...what screen size? 800px? I'm sure there are Android tablets that have a landscape resolution of at least 1024px, which isn't far from a size I'd use on my 13" laptop. This might be where things get tricky.

Anyway, any screen larger than our chosen Android breakpoint will get unique content/copy with two equally sized buttons (Android, iOS).

Is that all correct?

If so, what do we think should be the breakpoint for Android?

Comment 11

[Cory Price [:ckprice] (bugmail disabled, NI me!)]

Hi Jon, thanks for the insight in comment 10. Note that just above it this bug was closed as INVALID. We regrouped again, and felt that the extra step/page load added by this implementation removed it as an option.

We will now ask the user to identify iOS/Android on the form before they submit a phone/email. This will allow us to send them a message with a single link directly to the appropriate market.

We'll run a limited test without the identifier on the form, and sending a user a single message with two links to compare performance.

Further details may be found here: https://etherpad.mozilla.org/send-to-device