Originally published on Medium.

Two years ago, we published "Supporting Internet Explorer 11 in 2019". This year, we are bidding farewell to it. But hold on a minute! What happened between then and now? Let me tell you the story of a difficult break up between Doctolib and Internet Explorer... (and we're not the only ones 🤫)

Motivations

Back in 2019, a major motivation for us to stop supporting old browsers on the website healthcare professionals use to access our service was that we had two different pipelines to bundle JavaScript code: one was through Webpack and Babel, the other one through the Ruby on Rails asset pipeline (also known as Sprockets). The good news is, last year we managed to get rid of Sprockets. Now, all of our JavaScript files go through Webpack. Therefore, we do not need to write ES5-compliant code anymore, we can write modern JavaScript everywhere in our mono-repository. However we still have to instruct Babel to transpile some packages that do not come pre-transpiled. And let's be honest, monitoring breaking changes as library authors release new versions is no fun at all.

Our other motivations were:

• Cost of maintaining additional integration tests running on old browsers. Back then we were using Browserstack, we since then moved to Lambdatest, because we found it to be more reliable and noticed less random test fails. But that still remains a pain to maintain. Not only does Lambdatest occasionally fail, but also some specific browser versions do not mingle well with Capybara (our test framework). For instance, we found that click_on would consistently not work with Safari 13 in some pages.
• We still have occasional down incidents. One of the recent ones was due to scrollTo being used with options, which is not supported by Internet Explorer 11. And of course, Babel can't do anything about it.

These motivations are still valid to this day. On top of that, since 2019, we have developed new features and brought end-to-end encryption everywhere in the app. Yet, some of these old browsers have limited support for some of the web APIs we are using. As a consequence, these users can not enjoy the complete feature set Doctolib has to offer, and they are unable to see encrypted documents (PDF documents for instance), as encryption/decryption is done in the browser. Therefore, at the beginning of this year, we initiated a new project that we like to call "Browser Upgrade Campaign: reborn".

Browser Upgrade Campaign: reborn

Admittedly, our previous attempt at having our customers upgrade their browsers was a failure. We are trying to get it right this time. The timeline we laid out was as follows:

Regarding the list of browsers we wanted to keep supporting, we kept the same list as in 2019, with one minor change: we would no longer support Edge 17. Here are the browsers we officially support from now on, on our pro website:

• Safari 12+
• Edge 18+ (18 is the last non Chrome-based version of Edge)
• Chrome 50+
• Firefox 45+ (version 45 in an Extended Support Release)
• No Internet Explorer version at all

Preventing the use of non supported browsers internally was an easy win. All it took was good communication and the flip of a switch. After that, any Doctolib employee trying to use an outdated browser would be welcomed by the following page:

The two following steps were almost as easy. After setting up some tracking through New Relic, we realized we did not have that many new connections on outdated browsers every day. What's a new connection? It's a connection from a browser that never connected to Doctolib before. How do we determine whether it ever accessed Doctolib before? We look for existing cookies sent in the request.

Based on that fact, we first blocked any new connection on Internet Explorer 11. Then, over the next few days, we monitored the amount of support tickets and phone calls: nothing. No one complained. We then did the same operation with other deprecated browsers.

Then came the fourth step.

Walking on eggs

Given that there had been a red banner displayed at the top of Doctolib for the last two years to users surfing with outdated browsers, our users were well aware of that. But of course we knew it was not enough. Why would our graphs still show relatively high usage of outdated browsers, uh?

In April and May we sent out two email campaigns: one to remote secretaryship centers, another one to key accounts (most of them being hospitals or Covid-19 vaccination centers). This time, unlike in 2019, we explicitly told them which users were still using non supported browsers and gave them a deadline after which we would no longer be able to use these browsers. We made sure to tell them which obsolete browsers they were using and what options they had to upgrade.

In the meantime, we compiled a big list of user accounts that were using multiple browsers, both supported and non supported ones. Every day, we'd pick a bunch of them and enable a feature switch on their account, that would prevent them from logging in with a non supported browser. Once again, we daily monitored our support, making sure everything was going as smoothly as possible.

And it finally happened for good this time: the curve went down and eventually reached zero.

After the feature switch had been flipped for all of our users seamlessly, we removed the feature switch and hardcoded these browsers' name and versions directly in the codebase, to make sure no one would ever use them again.

This project is, as I am writing this article, coming to an end. Interestingly enough, in two years' time, our browser market share changed a lot, Internet Explorer slowing fading out into oblivion... and Microsoft Edge taking off!

If you want more technical news, follow our journey through our docto-tech-life newsletter.

And if you want to join us in scaling a high traffic website and transforming the healthcare system, we are hiring talented developers to grow our tech and product team in France and Germany, feel free to have a look at the open positions.