Sports betting is a popular entertainment among people that love sports. Today people are always connected to the internet so betting is possible anywhere, even while watching live sports events.
Kambi is one of the top sports betting providers and their services include popular sports from all over the world.
This is the story of how we were part of taking their sports betting web application to the next level.
At the time we joined the team, a mobile web application had just been released to users. Soon, users also wanted an application specially designed for tablets such as the iPad & Nexus 7.
At that same time it was becoming clear that the desktop application would not stand the test of time. Not because it wasn’t good. It was very good and mature after years of development.
The fact that it was built in Flash was a burden for few reasons:
- It required users to install Flash.
- It required features in two places, HTML5 and Flash.
- It required talents with different skill-sets to develop the product.
HTML5 is now ready to deliver the quality user experience Kambi wanted for their customers. The first idea was to build three versions of the application in HTML5. One for mobiles, one for tablets and one for desktops.
However, we quickly realized that it would complicate our work a lot. It would require us have three separate teams, code-bases and todo lists to manage these applications. It was just not likely to result in a consistent and good user experience for different devices.
We believe the path we took was more future friendly.
What we built
In the multi-device world we live in, building responsive web applications that adapt to different screen sizes and capabilities is the sensible way forward.
At Kambi we went all-in on this bet and decided to build a web application that scales across the board. The value was clear, unified development process and consistent user experience on all platforms.
Live Right Now
Live score-board that scales nicely from small to big screens.
The betslip is always visible on the desktop, but on mobile it shows up when the user places a bet.
Video streaming for live sport events, using the HTML5 video element.
The platform is growing fast, each customer gets a branded theme for their users.
What we learned
Making a complex web application responsive, without sacrificing usability, performance or good development process was not just a walk in the park.
Here are the lessons we learned along the way.
Starting with the mobile web app in the beginning turned out to be a huge benefit. The limited screen size required the team to prioritize features and to keep the user interface simple.
We would enhance the user experience as scaling up to bigger screens, but starting mobile first forced us to constantly focus on the most important parts.
Some people say that Photoshop is dead for responsive web design. That fluid layouts can’t be designed on a fixed canvas. We don’t believe it to be 100% correct.
Instead making prototypes while designing becomes really important. We were lucky enough to work with talented designers that constantly built prototypes to feel out the user interface. This was a key factor in getting the experience right.
The library is open source, it’s available on github.
One of the main challenges of building responsive was making sure everything works on all modern devices and browsers. We built unit tests and other automatic methods, but that only solves the logical part of the problem.
Truth is, there is no replacement for real manual hands-on testing for the user interface. In the end everything has to work for real.
Kambi provides a branded theme of the application to all their customers. Each theme has different colors, fonts and background-images. Making sure the themes were looking good while many people worked on the code-base turned out to be a hassle.
That is why the team created a style guide. Style guide is a HTML document that shows all the user interface components of the app and possible states for all the themes. This gave us a quick overview for the styling of the application.
Another great benefit, it helped us to build components that were reusable and forced us to keep the CSS clean.
In the beginning we used to work in two week sprints. After few sprints we felt that there was wasted time between completing and planning new sprints.
So we thought, why having sprints at all? In our team we decided to skip sprints and do more continuous flow of working. We did planning for each feature just before implementing instead of planning two weeks in advanced.
This made us more productive as a team and gave us more time for actual work.
Following our two week sprints we were used to package new releases every two weeks. Problem is, the longer time it took to release, the longer time it took for us to learn how users responded.
Therefore we changed to frequent releases and ship as soon as completing new features or fixes. This gave us instant feedback while building the product.
We used Google Analytics to track and validate how users responded to new features. Often our assumptions about the product turned out different from expected.
Faster releases called for better ways to work and constantly make sure that the everything works as expected.
Our team at Kambi made many improvements. More pair programming and code reviews. Limit tasks in progress. Always improve code while touching it. Keep retrospectives open and be honest as a team.
One of the great thing about Kambi’s culture is trusting teams to make their own decisions, both about the product and how to work.
Talented people is key to deliver quality services, but the right tools are important to keep everyone sane while doing it.
Following is the front-end technology stack that evolved at Kambi, we feel very good about it.
DOM manipulation made easy. First we used Zepto.js as a lightweight library for mobile devices, when extending support to desktop browsers jQuery was the choice.
CSS3 pre-processor that is hard to life without. First we used LESS but it fell short on many features, specially for responsive web design.
Opinionated front-end library from Google to rapidly build web applications. We used to build an back office application as fast as possible.
Eliminates the 300ms click delay for touch events. This library serves its purpose to make the user interface respond as quickly as possible.
Mature build tool to run tasks such as unit tests, code quality checks, deploy to servers, to compile Sass to CSS, and others to automate our processes.
Native video player, supported by all modern browsers. We used it to stream live sports matches while betting on mobiles, tablets and in desktop browsers.
Communications from server to client, also known as EventSource, part of the HTML5 Spec. We used it to instantly push odds updates to users.
Fully responsive web applications is not just a pipe dream anymore. With the right mindset, tools and processes it all becomes possible.
We are truly thankful for the time at Kambi. Awesome place overall and fantastic people in every position.
Tack så mycket!