Over the past couple of months, we’ve been busy working on the new SciSports platform, a one-stop shop where the football community can access all our product and service offerings. It’s now been a few weeks since we launched this new platform, and we thought we’d take a step back to reflect and share some lessons learned along the way.
Before the launch of the platform, most of our player search and intelligence tools were earlier offered through ‘Insight’. A lot of our features were originally prototyped and brought to life in this codebase with the help of Vuetify. This served well to get us off the ground, but as we start to build more polished and custom interfaces, we wanted to be able to fully express ourselves without the constraints of a component library such as Vuetify.
Upon evaluating our options, we decided the best course of action was to start with a fresh codebase for platform rather than building on top of Insight with convoluted workarounds for legacy setups and CSS class conflicts. We moved to a single sign-on (SSO) mechanism on both the old Insight and the new platform and by sharing a newly developed navigation bar across both deployments, we were able to create a near-seamless experience for end-users. This allowed us to continuously ship new features without having to refactor a lot of ‘working’ code in one go.
Over the next few months, we plan to migrate features from Insight and into platform, but we now have the latitude to do so along with improvements in a more thoughtful manner.
We feel it’s important for developers to build for users and not just to a spec handed over by designers and product owners. Developers with empathy towards end users ask the right questions and make the right micro-decisions when implementing a feature (micro-decisions that would be extremely tedious to communicate via design handoffs).
At SciSports we felt we had room to improve on this, and so while building the platform, we made a conscious effort to keep developers involved in the product development lifecycle beyond technical implementation. Developers took turns in participating in both customer interviews (before designing a feature) and user testing sessions (post building a feature), leading to a better overall appreciation for why and for whom we were building something.
Our platform is used by football clubs all over the world, and this means some users prefer to use it in their own local language. Our earlier web interface, Insight, did have the standard internationalization system for the web (i18n) built in. However, this involves maintaining a JSON for each language with key-value pairs for messages that need translation. Thus, adding a new section to your app, would mean adding a bunch of key-value pairs to as many JSON files as there are languages. This involves manual work and coordination between a developer and multiple translators – cumbersome and prone to human error.
As is our approach to anything we work on, we were keen to automate this in a smart and feasible way. We wrote a script that could generate a JSON file for each language from one shared Google Sheet with a column for each language. Google Sheets also allows you to protect cells and selectively give access to certain parties, allowing us to restrict control of key names to developers and translations in a language to the respective translator. With this, developers could focus on development and translators could update translations independently.
In the near future, we plan to take this one step further and automate the process of creating a pull request to our repositories when an update is made to the shared translations Google Sheet.
WE'RE HIRING
We always strive to attract the brightest (tech) talents in the world.
SCISPORTS PLATFORM
The ultimate football data intelligence platform.
