We’ve known since a major Chrome announcement in August 2015 that there would be a hard date when Flash support would end in the major desktop browsers.
As far as we were concerned it would be early December 2016, after which date Google would start including a warning bar for all Flash sites. That’s not a good look for any brand and it’s not something we wanted for ours.
When you consider that 80% of our customers connect via Chrome, it would impact the majority.
We would need a new desktop site. The question was, did we need to build a new stand-alone product or could we look at a mobile-first strategy and reuse our mobile site?
This type of mobile-first approach is trending at the moment and is somewhat of a no brainer when you consider the cost and development time savings.
We had already decided that the new site would be written in HTML5. That much we knew for certain. We’d used the technology for our mobile site and found that it increased the efficiency of data exchange and offered a more stable streaming platform.
>See also: To app or not to app: how Bet365 is tackling the mobile UI challenge
Mobile certainly seemed to be the dominant platform. At that time more of our users connected to our services via some sort of mobile device. We could only see that number increasing. In the face of such evidence, why wouldn’t we take our mobile collaterals and port them over to the desktop?
One interface elegantly responding to the screen size of our users; it felt like our prayers had been answered. After years of developing individual sites for different platforms and different types of mobile phone, we would finally have one site and one development stream.
However, that’s not what happened. While it would be easy to conclude from a quick look at the numbers that we could transition to a mobile-first approach, deeper interrogation of the data uncovered that this would be a mistake.
Certainly mobile was becoming the dominant platform but what was interesting was the number of desktop users hadn’t declined. It would seem that one was not growing to the detriment of the other.
When we looked at the profiles of our mobile and desktop users we made another interesting discovery. The usage profiles on the two platforms were very different.
On mobile it was all about immediacy. Our users wanted to take action in as few gestures as possible. This suits our In-Play product because it’s all about real-time decision making, on events, as they happen.
Users can simply take out their phones and in just a couple of gestures they can, log in and quickly make their bet or cash out a bet they’ve made earlier.
On the desktop, it was a very different story. On average, users were spending a lot more time. They were using it as a place to do research. We found that they are more tactical in their betting.
This is something the desktop is far better suited to. You can present more information on one screen and link to deeper data sets. You can even have several browser windows open, displaying statistics and background information from multiple sources.
The result was two different front ends with very different purposes.
This was a defining insight. We knew we couldn’t attempt a responsive design because the mobile site wouldn’t present the right experience for our desktop users. Rather than a mobile first world, we found we were operating in an omnichannel one.
A world where user activities dictate design and development philosophies and not platform trendiness. It’s a world where you make assumptions at your peril because users aren’t contained to anyone platform. And where our job is to create a seamless transition from one platform to the next.
You certainly can’t escape the popularity of mobile but had we pushed forward with a responsive site without doing our due diligence first, we likely would have cannibalised our desktop user base. With much of the information removed to make way for a responsible philosophy, we could have risked sending them to our competitors.
Now that we understood what we needed to do, we looked at the most efficient and effective roadmap for building the site and found it made sense to refactor the existing Flash site into HTML5.
>See also: Why Bet365 swapped Java for Erlang
We liked Flash’s modular approach and used Scrum to transfer each component from actionscript to typescript. It also gave us the opportunity to train our actionscript developers into typescript. The learning curve wasn’t as steep because they were already familiar with the Flash components.
To be fair, we did refactor some of the mobile code to help shortcut the development process but there is no mobile code in the desktop site. In fact, we’ve taken some of the learning from the development of the desktop site and fed it back into our mobile site.
Moving forward, we believe that the desktop has a long tail and that it will be around for some time yet. Not only do our users prefer it for certain activities but there are also those regions where mobile has yet to penetrate in the same way as it has here.
My advice to anyone looking at responsive design is to do your due diligence first. Don’t assume that the popularity of mobile means that you don’t need a fully functioning desktop site. Look at the behaviour of your users and let them help you to determine your design philosophy.
