Stats Central


Stats Central is a webapp that covers global and regional statistics for the popular MOBA League of Legends by Riot Games. Based on the client's designs, the site was built from the ground up using numerous web technologies to provide a realtime response across a large dataset and to present it in a mobile-friendly and maintainable interface.

My Role

I was the sole developer on this project as well as providing my own insights into how the site would be designed. I worked closely with the client in order to make sure the project kept close to their initial vision of the functionality and feel of the site whilst making sure that it was up to current coding standards and best practices. Emphasis was placed on making sure that the site was mobile responsive and worked cross-platform. The codebase itself went through several revisions in order to keep it maintainable and scalable for potential expansions.


Colour Scheme


Even early on in the design process, it was decided that the site was to be done in a monochromatic colour scheme with an emphasis on the white and grey that would take up the majority of the screen space. A deep blue was chosen to be the primary colour of the site and to only have minimal amounts of accenting hues for things like low-contrast borders or hover effects. This meant the design took on a minimalist approach so as to give the emphasis of the site over to the content itself. With all of the images and graphs the site has to go along with the textual content, there was little need to go for a more advanced colour scheme and any attempts to find a complementary colour would create a clash with a number of the images and graphics that the site hosts.


For the title text, fonts were looked at to be both easy to read but also stylistically pleasing. The choices were narrowed down to a series of block-type fonts in order to invoke an image in the user of battle or the sort that tied nicely in with the League of Legends game that the site pertains to. Evogria by Situjuh Nazara was finally chosen as the best compromise between the block-type fonts and fonts that were instantly readable and not so overtly stylistic as to seem outdated.

The body text was chosen to be sans-serif to fit the minimalistic style that the site was going for. Also to improve readability with the formats that the body text would find itself in, such as in graph axes or table contents. A serif font would have been too noisy and would not have scaled down to the necessarily small sizes with as much legibility as the sans-serif fonts that were looked into. PT Sans by Paratype was chosen after an initial idea of Roboto as the more rounded nature of the PT Sans letters provided a nice contrast to the blocky title text.

There is very little decorative text on the site so it meant that whatever font was chosen should not be too stylistic otherwise it would stand out too much, but it should still be more noticable than the body and title text that surrounds it. After a few different options, Raleway by Matt McInerney was chosen as its lightness and shape provided the best design to allow for wider kerning this created decorative text that stood out but fitted with the style of the rest of the site.


Frontend Technologies Used

DOM manipulation, deletion and insertion, also required for Foundation
Grid system to aid with mobile responsiveness and layouting
Provide various icons throughout the site with minimal footprint
Provide some material design theming and layout for dropdowns/tables
Automate table responsiveness, layouting and interactivity
Display certain data as mobile responsive charts and graphs
Extract primary colours of images for inidividual page theming


Full Stack Diagram

The initial plan was to simply convert the raw data from the MongoDB server to useable JSON upon request and then inject that into the layout. However, as testing was undertaken into the scalability of the system, some problems were seen. As it was, this system would be far too slow to respond, would use far too much data and proposed a potential security risk with the client directly touching the server.

After numerous potential solutions were considered, the stack diagram above was formulated and put into action. By using Cron to provide a weekly update of specially constructed JSON files that the client read from instead, the majority of the problems were solved. The client could quickly read in the JSON file specific to that page using AJAX with no conversion necessary and because all bloat was removed, data usage was kept to a minimum, there is also no direct connection to the server by the client.

The system can also be switched from a weekly update to a daily one during the peak season where there is likely to be more updates than other times during the year. Manual updates are also possible server-side. For data that needs to be real-time, such as the match schedule API which needs to be checked each page load, AJAX is again used to only load in the specific region schedule specified. This again minimises data usage as the client only receives schedule data for the region they wish for.