Determine browser support

[toolness]

It's unclear what browsers we're trying to support.

As noted in #143, I'm assuming at the moment that we'll essentially not progressively enhance anything below IE9 with JavaScript, meaning that we can use modern JS libraries for our client-side code.

However, this also implies that browser-side JS will only be used for progressive enhancement, and not core functionality. Looking at the current roadmap and mock-ups, I'm not sure how well we'll be able to keep this promise, at least not without migrating from our current static site generation model to one of dynamic server-side page generation.

We should talk about this soon!

[toolness]

/cc @simonwex @hannahkane

[mmmavis]

im also wondering if flexbox is safe to use (ref)

[alicoding]

Can we get the data from our user on webmaker.org at least for /teach to see what is their browser? @adamlofting can we get specific details for that? @hannahkane is this something we can come up with minimum browser support? This will really help us through development if we know which browser we want to support.

[hannahkane]

I don't have a lot of data to inform this decision. I would default to whatever browsers we support for Webmaker. Would welcome feedback from others, though.

[gesa]

In general, Webmaker supports current minus one, which translates to, for example:

(i just grabbed a random screenshot from caniuse to show which versions are current)

[gesa]

So this kind of wandered back in to my mind and think it's as good a time as ever to talk about whether we support Android 4.2 in our general Webmaker properties. (we do target it on Webmaker App)

[alicoding]

I don't think we need to worry about Android Web view? Do we? Since we are not bundling into an app? Or are we planning to?

[gesa]

oh right that's just webview that is evil, not chrom(e | ium)

[davidascher]

We will hopefully get visitors from emerging markets who are likely to run oldish androids and may very well have stock browsers (not Chrome). If that becomes a real blocker in terms of our css feature set for example, we could UA-detect and suggest they upgrade to either Firefox or Chrome, assuming those actually work on 4.2.

Alternatively, a UA detection early in the process that renders a specially-made-for-that audience set of pages, but treat it like an entirely different responsive view.

In general, I suspect we need to file a separate issue on what interactions we want people to be able to have on this site when coming from a mobile browser.

[hannahkane]

+1 that we are hoping to get visitors from emerging markets.

For the v1, mobile users will ideally be able to:

• view all content, including the locations of Clubs (not necessarily on a map)
• add/edit/delete their Club
• the above requires authentication workflows

Later versions may include mobile-friendly interactive functionality such as:

• browsing Mentor profiles
• sending or receiving a message from another Mentor
• finding a Club near you
• "connecting" yourself to a Club that you don't own
• inviting someone to join a Club
• "liking" a curriculum activity
• commenting on a curriculum activity
• applying for a badge (?)
• being notified after receiving a badge (that sounds like an app....hmmm....not sure I want to go that far)
• Perhaps it will be useful to be able to download curriculum activities to access in offline mobile environments

Later versions will likely also include add'l functionality that I'm not sure would need to be particularly mobile-friendly, such as:

• creating/editing a Mentor profile
• maintaining a personal portfolio of projects and curriculum
• reviewing badge applications / issuing badges

It's difficult to say, because we're trying to do this in an agile way and see what needs emerge from users. But hopefully this provides a sense of what might be coming down the pipeline.

Not sure the best way to advance this conversation. Should I put this list in a separate ticket?

[adamlofting]

FWIW, here is data from when we looked at browser usage for webmaker.org (including tools) last year. But, I would caution that our existing audience does not equal our target audience. Given much of our target audience isn't yet connected to the internet ;)

Thoughts on how to decide
Current version -1 will work for the majority of our desktop audience.

But the point of contention here is balancing the needs of an audience on older systems, with the speed (and joy!) of the developer experience. I'd encourage weighting that decision in favour of the audience as there are more of them than us, and our strategy specifically aims at reaching the people new to the web.

Can we

1. List the devices / browsers we think are likely to be used which fall into the 'annoying to develop and test for' category? E.g. old android stock browser, old I.E. etc. Perhaps check-in with @LauraReynal's existing research for clues here.
2. Then research / guesstimate which are most important to our audience.
3. Estimate the developer cost (mostly in time) for testing against these systems.
4. Agree which ones we will support, and document a testing strategy
5. Over time, use data to decide when we can stop supporting a system as it's use drops below a useful threshold.

Re: local clubs on a mobile device
As a fallback, you can always search and see a list of local clubs without needing to see a map. The data is essential, the map presentation is the progressive enhancement.

[hannahkane]

Thanks, @adamlofting. This sounds like a good plan. Who is in the best position to start the list of devices / browsers we think are challenging to develop for?

Good point re: not needing the map interface for mobile. I amended my comment above to reflect that.

[gesa]

While I agree that we should favor our audience over developer experience, I should mention that anything older than IE 10 and Android default browser 4.2-4.4 (depending on how we build the site) can be so constraining as to having to completely rethink how we design certain features. I'm by no means saying we can't support these browsers, but if we're going to, it's not just going to be unpleasant for devs. It's going to require re-thinking our whole approach from a CSS standpoint.

[adamlofting]

Here are a few further data points to weigh up against developer 'costs'. Also, we might want to move this discussion to a general engineering space, as these decisions are also important to Webmaker tools (maybe even more so there).

I've had a look at versions of Android.

These two views are global averages:

• https://developer.android.com/about/dashboards/index.html
• http://www.appbrain.com/stats/top-android-sdk-versions

You can also look at top devices for a given country, if you want to cross check with what OS that device ships with. But it's a bit tedious.

From a much smaller dataset, I went through the people we've interviewed in Bangladesh, India and Kenya and checked which versions of Android their devices run.

So, by supporting these versions of Android we would 'reach':

Android Version	Globally	Our small target market dataset
4.3 and up	~50%	~25% of these people
4.2 and up	~70%	~50% of these people
4.1 and up	~85%	~75% of these people
2.3 and up	~100%	100% of these people

[adamlofting]

I'm happy to explore more data if it's useful here, but I think this gets us in the right ballpark.

Now, this discussion is between product and engineering to weigh up the cost and benefits of being able to reach each % of the market.

I'll assign the ticket back to @hannahkane. Conversation is likely to need @davidascher @simonwex @thisandagain @hannahkane .

[thisandagain]

For reference, here is what we've been looking at for Webmaker:

Desktop

Chrome: Latest - 1
Firefox: Latest - 1
Safari: 7+
IE: 11+

Tablet

Mobile Chrome: Latest - 1
Mobile Firefox: Latest - 1
Mobile Safari: iOS 7+

Phone*

Android: 4.2.2+**

* We are shipping an app to Google Play and so our compatibility matrix between Webmaker and 
  Teach is kinda like comparing apples and oranges here. We will have some browser support 
  needed for published views but this will likely match what we are looking at on tablets.

** We are looking at potentially embedding our own rendering engine to help us get lower than this

[lauradereynal]

Opera mini is very popular also in emerging markets - given its low data consumption. Will check if I find numbers. Would that be supported @thisandagain ?

[thisandagain]

Opera mini will almost certainly not be supported for Webmaker as it isn't particularly relevant to the tablet market and on Android we are shipping an app. Good consideration for the teach site though! Clarified the segmentation between tablet and phone above.

[gesa]

a quarter of a billion people use Opera mini, good call @LauraReynal.

[hannahkane]

So, it sounds like Webmaker is set. My instinct for Teach is to follow Webmaker's lead for desktop and tablet, and to only consider phones a distinct question. How about I set up a call with @toolness @davidascher and @simonwex to hash this out?

[davidascher]

My stance would be to be optimistic in order to not slow down v1 launch, and then measure to see if we're wrong. So, assume that our audience for teach is more tech literate & engaged than average, but critically, measure how many visits are breaking that assumption. We may need to build a version of the site specifically for tiny tiny screens and older browsers, but I suspect that might have much bigger redesign implications than we're ready to decide now (e.g. non-map based views, way lower resolution images, much fewer words, etc). Measuring that "bad assumption rate" per country becomes an important metric to put in place.

[toolness]

Sounds good to me--also, we've already got a non-map view, hooray! (Though to your point, it won't necessarily work well w/ tiny tiny screens and older browsers yet.)

[hannahkane]

I like this approach. We'll start looking at these metrics once we're actively promoting the site, and can form our forward-looking strategy based on what we learn.