Adapt Learning Community: Browser Support

Skip to main content

Good morning,

So here we are with HTML and it's ability to work on most devices. Kinda.

One discussion I'd quite like to open up is the browser spec for core Adapt. Currently as a company we support IE8 and above. I mention only IE8 as most of our mobile browsers/tablet browsers are of a good standard.

The reasoning behind just supporting IE8+ is so we can create beautiful content across all the browsers. The client has an expectation that whatever device they go on it should look the same. I'd disagree and find the idea of progressive enhancement a much more sustainable approach. Maybe IE6 and 7 don't have fancy stuff, instead you can still see the content and work through it.

I've tested Adapt in IE6 and IE7 - it works. Doesn't look pretty and some styling issues are a nightmare to fix.

After a few discussions with the team at Learning Pool, I've come to realise that we're claiming to create a platform that can deliver learning content across any device. So this means future devices but also older browsers.

Responsive content plays a big part of this. It enables us to create content based upon the width of the screen size. So really our platform should work on all future devices.

Let's not worry too much about the newer browsers and let's discuss the older ones. Firstly - anything below IE6 is not supported. I can safely make that claim because IE5- does not render content properly and has troubles with ajax requests. Not only that - they are not support by Microsoft and haven't been for a very long while.

So discussions start with how far are developers willing to work?

Does this benefit Adapt?

Does this benefit companies - I know that we have clients using IE6 and IE7 but we have another framework we could use.

Our initial thoughts on iOS devices and mobile devices tend to update more frequently so two versions back is ok.

Plugins for Adapt - do they need to have a browser supported attribute or should they all gracefully fall back?

Should the editor have the same spec? (I'm more on the verge of saying no to this)

From a discussion with Sven, we both agreed that a 'reasonable' spec would need to be agreed.

Would love to hear people input, especially project managers/ and learning designers as progressive enhancement will mean a significant change to the way we sell Adapt to clients.

Thanks,

Daryl

I think plugin developers should be allowed to develop for whatever browsers they like, but there should be clearly defined meta data so that when a hypothetical content creator wants to put something in their course, they can, should they wish, filter plugins by browser availability.

Show parent | Reply

In principle, we divide the codebase into two main chunks:

core code
community code

Further to that, we should consider that there are two further scopes for each of these, making the full list of code bases:

core code output framework
core code authoring tool
community code output framework
community code authoring tool

For cases 1 and 2, i.e. the core code we have to lay down a set of rules (tech spec) that we commit to adhere to at all times. I think we also need to give ourselves room to consider the two core codebases independently in terms of what the end results (i.e. the authoring tool and any published e-learning modules) work on.

For case 3, I agree with your statement: community developers should have full freedom to develop for whatever they see fit / whatever meets their need. However, we would like them to capture metadata saying what the code has been developed for and tested on. This way, end users can decide whether the interaction is suitable for their needs and the core team can consider whether a really useful plug-in can be incorporated into core and what the effort would be to do so.

For case 4, I expect we will have a mixture akin to what happens on the Moodle community. We are designing the the tool to have a plug-in architecture, too, so hopefully, we will be able to capture a lot of plug-in type code. Having said that, I expect we will at some point be dealing with customisations in the community codebase etc. Generally, I think looking at Moodle for this item is a good comparison...

Show parent | Reply

Coincidentally I was just reading this when I got the email notification of this post!

IE6 support should no longer be required at all beyond the 8th April 2014 - as that's the point at which Microsoft stop supporting Windows XP, which effectively means IE6 is no longer officially supported (pretty sure you can't install it on Vista).

As for IE7 support - I think some level of support might have to be included. This is mainly due to how IE8 has an annoying tendency to drop into IE7 document mode - either for reasons of its own choosing or because the server is telling it to (Cornerstone LMS does this). Whether you officially support IE7-the-browser though is another matter, my concern would be: what if IE7 starts going into IE6 mode?! Note that I'm not actually sure it does this - someone needs to check!

As for other desktop browsers - our position has always been that the minimum versions are the latest version of Chrome and the ESR release (currently v17, shortly to change to v24) of Firefox. For Safari (OS X only) it is v5 and above. We don't get much call for Opera - just one request that I can remember.

Interesting to note that Opera is now 3rd place in the HTML test...

Show parent | Reply

Worth mentioning that there's still a LOT of people out there using Android v2.3.x http://developer.android.com/about/dashboards/index.html

Also one thing to point out that a lot of people don't realise - all browsers on iOS are still Safari 'under the hood'. App developers are expressly forbidden from attempting to introduce a new rendering engine into their app, so they all have to use the same underlying rendering engine as Safari - only slower because the 'Nitro' JavaScript engine isn't enabled.

Show parent | Reply

I need to be careful here, because I'm aware that I have some strong opinions (!) which are probably incorrect.

I'll not say much at this point, though I intend to produce a longer, more nuanced response.

3 points:

1. I think we need to be clear about what we mean by "support". I would argue that it should be possible to achieve the learning objectives of any piece of e-learning on _any_ web browser (ie6 included). I think we need to adjust our understanding (or perhaps our customers' understanding) of what that ability should look like in practice. It could be a publishing requirement, or a content one, or a front-end plugin role to ensure ubiquitous availability. It may be then that we start talking about Adapt being "optimised" for a certain set of devices. I recognise that this state might not be achievable given our current development position (reliance on backbone/jquery/handlebars.js etc.)

2. Future browser support is a bigger issue I suspect. I worry that we optimise for current standards and store problems for ourselves in the future (a world with lots of "odd" devices, like Google Glass, Smart watches, screen-less devices etc. etc.) - Anyone remember those intranet sites that don't work on non-IE browsers? They still exist...

3. The Authoring environment is an entirely different discussion, can we safely leave it aside in this thread?

Ok, so there are probably more than three points hidden in there...

Show parent | Reply

Responding to the easy one(s) first:

3. As you suggest, let's keep the authoring environment outside of the scope of this discussion. And let's start a second discussion on that front soon - I think this is quite important to bottom out early on.

2. I almost think that future browser support is a lesser issue from a 'being signed up to it' point of view. Ryan, like you, I expect this will bring a lot of technical challenges but in many ways we are already committed to addressing them as we come across them. Otherwise, I doubt that we can attain (or maintain; allowing myself to dream) a market leading position. I also think that the principles of separation the data (JSON) from the presentation (JS/CSS/HTML etc) will help with that.

(bit like a countdown)

1. agreed this does need thrashing out some more and I look forward to your more detailed response. I expect that we will also need to look at achievability, starting from what we have, what it needs to lead the market etc. - all of that to come.

The point that struck me though is the point made against no 2, i.e. the separation of data from the display. Unless I am wrong, there are limitations that the older browsers have, which make it much harder to achieve the data/logic/display separation. I remember attempting what we have done with Adapt some years back and failing to achieve a suitable outcome. I feel that the increased capability of modern browsers has helped with this becoming achievable.

In older browsers you may find that to achieve a similar effect means having to marry content and presentation much more tightly. This is not something the Adapt framework currently does and I wonder whether it really should attempt this in a single version of output. Maybe there are ways of packaging the raw content as additional plain HTML files alongside in the output (but isn't that cheating either way seeing as it's not a single version?). The thing I would like us to steer away from is packaging a lot of extra code or data and thus convoluting the output, making maintenance harder etc.

Either way, good to have this discussion. Maybe we can also apply a bit of data to our decision making, i.e:

What is the lowest common denominator in terms of our code and the libraries we use?
What is the market penetration of devices / browsers?
What do our own customers say?

Hope this helps.

Show parent | Reply

1. I agree in theory but in practice this can be much harder to achieve. there's also cost vs. benefit to consider

2. I don't know that there's really much you can do about this except be as standards-compliant as possible. The reason those Intranet sites don't work on non-IE browsers was likely because many of them were created using FrontPage - a program which (deliberately most people would say!) created non-standard HTML that broke browsers like Netscape.

3. I think the Authoring environment spec should be a separate discussion.

Show parent | Reply

Here are my views:

Point 1:

We're beginning to see our large corporates who use IE6 slowly 'update' to IE8 . That said, the breadth of the segments we deliver to, whilst extensive, isn't exhaustive. Elegant degradation to ensure the content is viewable on older browsers is something I could see being of use, but setting the lowest common denominator as low as IE6 for core functionality would worry me - over 50% of all our Adapt QA fixes are born out of support IE8.

Point 2 I agree with.

Point 3: I think its reasonable to expect a more contemporary browser if yoru using the authoring tool than IE6/7.

Show parent | Reply

I really think we should exclude IE6 altogether on the basis of it only being supported for another 7 months, 5 days and 10 hours (not that I'm counting)

Show parent | Reply

like

Show parent | Reply

We're not really interested in IE6 support. Sounds time intensive and not really worth it, however being open source, if someone wanted to spend time contributing patches for IE6 then that's fine. It just won't be me.

Show parent | Reply

Thanks, Chris. Likewise, I will be making a case not to support IE6.

The point in need of highlighting is that we are agreeing a tech spec for all of the core of Adapt output. This means that all core code, including components, extensions, themes etc will have to adhere to this and that we, as the core team are committing to work to this spec until a change to the spec itself is agreed.

In open source terms, someone / some parts of the code may go beyond the agreed minimal spec but that is optional and up to individuals to achieve and maintain.

So this has quite far reaching implications and the baseline for the spec and this discussion should be what the Adapt output code currently covers - and whether that needs amending. We can then assess our reading of the market needs - this is where the views of the people wearing commercial content producer and authoring tool expert hats will need to be sought and considered alongside the technical / principle based views.

Daryl, would you be ok to post up the current Adapt baseline, please?

Show parent | Reply

We have loads of stats data collected from the many sites that we host. The trend has been that IE6 is almost non-existent (4-6%). IE7 usage is dropping slowly (18-19%), with IE8 getting over 48%, the rest are a real mixed bag. Granted our users are mostly public sector – but you’d hope that they have the lowest common dominator with regards to kit.

Microsoft are dropping support for WindowsXP in Apr 2013, with it goes IE6 and IE7. The min browser in Win7 is IE8. If anyone is running IE6 or IE7 after Apr 2013 they are on their own on unsupported technology.

Our customers are telling us that they have to get rid of WinXP by APR 2013 (they have plans in place to migrate) and that IE8 will at that point be the min browser across the board.

From a desktop point of view IE8 should be the min browser we support, IE6/IE7 gives us (as Paul mentions above) about 50% more work on average to create and maintain sites. Degrading gracefully is also not an option and customers have complained when their site renders differently in one browser over the other.

IE6 is 15years old, with IE7 not being far behind – We are building a responsive framework, falling back to basic html is not an option – it’s not worth the effort.

If someone is using WinXP they have the option to download and install a supported browser (FF or Chrome). If they don’t want to do that, they don’t get to view the content.

We have no real interest in supporting anything older than IE8.

Found this great article last night

http://arstechnica.com/information-technology/2013/10/internet-explorer-6-usage-drops-below-5-percent-in-september/

Show parent | Reply

I've just had this email from head of QA here at Kineo:

"Hi, have done a click through of the core Adapt package on an iPhone 4S with iOS7, and I couldn’t see any issues at all.

Cheers-Sam"

As you might expect, but good to know, all the same.

Paul

Show parent | Reply

actually - given how much Safari was changed in iOS 7 I was actually quite concerned that we'd see some issues. So quite a relief to find that it's all OK!

Show parent | Reply

I promised I would make another comment on browser support, so here goes. Apologies if it doesn't add anything to the discussion...

I'd prefer not to use the word support at all in reference to devices. We support users achieve their goal of completing some learning. We optimise our content for specific devices, we allow as many devices as possible to use our content.

What is the minimum set of device capabilities that we require in order for a user to use our content? I think that should be "understands html". I suspect everyone else on this thread disagrees with me. And that's ok. Adapt currently sets a higher bar, and I guess the question is whether that bar is set too high.

Second question, What is the subset of devices that we choose to optimise our content for? I think this is more straightforward. It's the set of devices that understand modern web standards, HTML5, CSS 3 (ish) & Media Queries, JavaScript 1.7 (ish) - There are several ways of deciding on that cut off. I particularly like the BBC's Cut The Mustard approach. IE7 & 8 don't fit the bill, so we shouldn't optimise for them. We should however let them access the content in a sub-optimal way.

In a mobile first progressive enhancement responsive approach, we'd serve a core set of simple html and css to all devices, then do a cutTheMustard check on load and pull in additional content (including enhanced css and javascript behaviours) as required. I think that because we are sending JSON to the client and rendering HTML via Javascript we can't do that. So I think our current approach makes IE7/8 optimisation impossible (or at least very labour intensive).

So recognising that there's a difference between principle and practice. My principle is that we should allow users to use any device to complete learning via Adapt but we optimise the experience for "HTML5" devices. In practice I suspect we'll not achieve that with the current version of the Adapt front-end framework.

I think the move to something Responsive gives us some leeway with customers who expect things to look the same. They can't expect an iPhone and IE10 on a 22" screen to look the same, so we can help them understand that IE8 and Chrome on the same screen don't need to look the same. As a developer I'd find explaining that difficult, but our support staff are probably highly skilled at that sort of thing. That in turn frees us up to cut some corners with our legacy browser optimisations should they be considered important enough to be optimised for.

Show parent | Reply

Hi everyone,

I thought I would throw my comments into this thread as I know there was quite a discussion about this when Sponge came to visit Kineo last week.

After going over the comments above I think there are some great points here.

I agree with Matt, Chris, Sven and about everyone on the forum on the IE6 support front, if Microsoft have stopped support for this, it really is time to move forward. Looking back at previous projects over the past 12 months I cannot recall any clients that we have worked with that have insisted on IE6 support due to their technical infrastructure.

IE7 & IE8 - This one caused a bit of a debate last week. There were 2 flows of conversation.

1) Should we be supporting IE7 document mode, I believe the decision was that this was a very rare occurrence that this needed to be supported so wouldn’t be included in the core of adapt.

2) Standard IE7&IE8 support – We discussed on the day that certainly from Sponge’s experience IE7 is still very much in demand (the new IE6!!) It was argued both that we should support IE7 & IE8, but to what level. From a usability perspective, as long as the core course can function in IE7/8 (even if it is not displaying as nicely as expected) this is still an acceptable solution to still support older browsers. The technical specification can include a disclaimer to highlight that although the course supports x,y,z, browsers, some browsers may display content in a slightly different form, we could even go as deep as mentioning some of the characteristics. An open an honest approach. This information is what sales teams and users of the authoring tool must ensure the end client knows up-front.

From conversation and your comments here I believe one of the areas which Kineo has had to over come previously is issues with IE7 and 8 have been down to the menu screens and managing to get them to work in these older browsers.

One great Idea that Daryl suggested was to create a plug-in which offers a simplified menu which will work in IE7 & 8 but will be at a very basic level, this way uses can still access content, but users with the most up-to-date browsers will benefit from the best viewing experience.

I think this all comes down to setting the expectations with the end user / author using the tool.

Will my course work for users who have older browsers, it may not look quite as good to some, but if they can access the information they need, can be challenged from a learning perspective and can be tracked for LMS purposes and I understand this, I am happy to use adapt.

Daryl’s question about the editor, and should this support all browsers, this again is a tricky one, however I feel there is more scope to minimise support for older browsers here. But as Ryan mentioned maybe this is another discussion point altogether.

Anymore thoughts on this?

Show parent | Reply

Alan, with regards to IE7 - do you know: what OS are most of your IE7 users on? Because if it's Windows XP then essentially they should all disappear in 7 months time when Microsoft withdraw support for this OS, leaving Windows Vista and Server 2008 being the only operating systems still supporting IE7.

According to netmarketshare, IE7 already has lower usage than IE6 - just 1.37% of users compared to 4.87%. Obviously other sites give slightly different figures but all show IE7 as being used less than IE6.

As to the IE7 'document mode' problem - that isn't a rare occurrence in my experience. In fact I can only think of one instance where we haven't run into this problem!

The reason it crops up so often is that your SCORM content is generally being displayed in a container created and controlled by the LMS. As a recent example, SABA LMS displays the course content within a frameset - an HTML tag that was removed completely in the HTML5 spec and so which causes IE to jump into 'quirks mode'.

In many cases we've been able to work around whatever causes this - but sometimes not in a way their either we or the client finds entirely satisfactory.

My preference would be to drop support for IE6 and IE7 (the browser) altogether and to have some level of support for IE7 'document mode' for those instances where we are completely unable to stop this from happening or work around it.

Show parent | Reply

In don’t know if its just the sectors we operate in, but to date the vast majority of our Adapt clients (14 of the 15) have insisted on IE8 which in most instances been the primary browser used to view the course. It might therefore be a hard sell if the menu’s where too diluted. Do we know how simplified we’re talking? I think it would be an easier pitch to sell a functional menu for IE7.

As Matt says, re: document mode. We have encountered it with frustrating regularity to date, with at least three different LMSs forcing Adapt content to be viewed in this manner. I’m not the best person to comment on the cause/solution here but its happening enough that we’ve built a test page that shows an alert if document mode is active to ensure we have early oversight of this fact.

Show parent | Reply

Hi,

update on our browser stats from last month, we continue to see a fall off in IE6, down now to around 2.7%.

IE7 also continues to fall, with IE8 increasing %wise.

I've also been speaking to several of our customers across our events and the trend seems to be that XP is getting phased out with a W7 replacement. The replacement browser is IE8.

IE8 is the minimum browser for W7, so any of the hits coming from IE7 are users using XP or Vista. Support for XP ends April 2014 (with it goes IE6).

IE6 – XP – April 8 2014 end of extended support
IE7 – Vista – April 11, 2017 end of extended support
IE 8 – Win 7 – January 14 – 2020 end of extended support
IE 9 – Win 7 – January 14 – 2020 end of extended support

Support for Vista and IE7 is April 2017.

Vista did not sell a lot of copies, so if we were to support IE7 it would be for a small percentage of users.

Is that small percentage worth the effort?

Show parent | Reply

Thanks, Mark. Very useful to see the data.

Matt, Paul, do we have similar data from Kineo clients we could share?

Show parent | Reply

I'll see what I can get - browser stats from our website would be pretty easy to get hold of but I'm not sure that's really representative of what our clients' learners are running - which is the really important info.

From memory, use of these browsers is very low indeed and it's my recollection that any instances I've encountered were all Windows XP so therefore won't be around much longer.

Show parent | Reply

Hi, Brian from Kineo US checking in here.

Here' some interesting data from a recent Adapt release for one of our US clients. This was a global initiative, and the course was released to over 10 countries/languages. The numbers are still relatively low as the course was just introduced, but I think they're still quite indicative. Note IE statistics.Unfortunately I don'f have the version breakdown.

From August, 2013 - October 2013:

Platform

Desktop: 4,294

Mobile: 446

tablet: 111

Browser

IE: 1,588

FF: 1,555

Chrome: 1,100

Safari: 270

Andriod: 113

Safari (iOS): 91

Lunascape: 60

Opera: 43

Opera Mini: 17

Blackberry: 4

Show parent | Reply

Adding some of our browser stats for the past month as another data point.

Our primary audience is health care sector nurses, with a mixture of work and home computers. We do however recommend Firefox and Google Chrome as the ideal browsers to use with our systems and we recently dropped support for IE7 in our course enrollment application, explicitly blocking login and requiring a different browser to be used.

In order of increasing share, we have:

0.2% IE6

5.7% IE 7

6.5% IE 9

10% Firefox

15% Safari on Mac

17.1% IE 10

18% Chrome

22% IE 8

It's also worth noting we have seen different behaviour for CSS rendering in terms of Windows XP IE8 vs Windows 7 IE8. Windows XP might be discontinuing support but I expect it will still be running for a long time, particularly if the browser upgrades to IE8.

Show parent | Reply

Hopefully not chiming in too late here, great discussion so far.

Just when much of the IE6 fanbase decided enough was enough and began the upgrade path to IE8, another large set of corporates come into view for us though. Parts of the Asian market mainly; China, Malaysia, others.

As I've read so far, it's clear that everyone is pretty much right in their views: it's a tough call to announce an all-platforms framework, while at the same time denouncing support for a few platforms, coupled with the need to reach into the future by making the most of technologies that will benefit everyone (eventually..).

While I agree with Ryan's mention of BBC's Cut The Mustard approach, I still have to acknowledge Daryl's very first comment, "The client has an expectation that whatever device they go on it should look the same.".. and I can only hope that some serious 360's happen when Matt's countdown really hits home.

On the costing front, I already add an IE factor to projects with legacy browsers. I'd be really interested to read some customer stories and scenarios on the ways that they can make allowances, so we can use that as ammo for those that won't. Bringing progressive enhancement to the party to save the customer money, backed up by hard stats and success stories hopefully can help - Alan's "open and honest approach".

So maybe cutting IE6 lose won't be a realistic option for some of our projects, others too, but the plug-in architecture and Open Source liveliness of Adapt made me read Chris' post a few times over, and generally agreeing that there's an opportunity here for fringe projects to supply browser support and plugins. Sven, I understand we're discussing Core here, so is it a possibility to identify not only the baseline specification of the chosen technologies, but also keep a running and responsibly active Issues list of weak points in older browsers?

Perhaps providing "support" for older browsers might not be the way forward, but perhaps providing some level of support for the contributors whose intention it is to bolt on fixes or otherwise, to include IE6, is an option. It might even be enjoyable to make lists of the ways that IE actively destroys everyone's hard work, Quirks Mode has certainly enjoyed many years of doing it!

Show parent | Reply