Rasenball – The Implementation
This article discusses the Rasenball visualization from a more technological point of view. A general overview over the application can be found in the previous article Rasenball – World Cup Visualization. The main technical obstacles were performance issues in the mobile version that led to a couple of design decisions. Using a flat design enabled us on the other hand to use a couple of state of the art design techniques to realize the application like Icon-Fonts and CSS effects where otherwise images might have been necessary.
For single-colored icons we used icon fonts whereever possible. Using vector fonts as basis, these fonts can easily be scaled. Additionally an icon can easily be replaced by another using CSS only. For more information have a look at our article on Icon Fonts.
CSS-Transforms and -Transitions
Building a scalable web application introduces a couple of difficulties. It is no longer possible to use pixel-based positioning as different devices have different widths and heights. Instead we used relative positioning based on the screen size available. This can be done using em as the basic unit of measure. (Using rem would be even better as its purpose is to be defined once on the root element, but rem did not work on some mobile devices, so we used em instead.) Depending on the screen resolution we calculate a font-size on the body element. One em is corresponding to the font-size in pixels. If, for example we defined the font-size of the body as 10px, 10em would be 100px. We can thus divide our pixel-based positioning by 10 and use em.
In those cases where we actually need font-sizes different from the base font size, we can again specifiy them relatively either by percentage or by em-values. A font of 20px thus becomes 2em or 200%.
CSS-Transform and -Transition
SVG and HTML Alignment
Another architectual decision was to use HTML whenever possible. HTML has much better support for images and text. The challenge was thus to align both technologies. As mentioned above, this was accomplished by using relative sizes with ems and percents on the HTML and a viewBox on the SVG. The main SVG has a width depending on the available screen width. Once the screen is resized, the font-size value on the body element is recomputed and all HTML elements are rerendered in the same relation to the SVG.
SVGs: Pre-Rendering vs Rendering on Client
SVG obviously could have been prerendered on the server-side. This would, however, have resulted in larger documents and a layout that needs to be synchronized between client and server. Since we wanted to highlight elements on mouseover we needed to know their position so that most of the algorithms would have been on the client anyway. Tests showed that modern clients could easily manage rendering larger SVGs on the fly, so that we decided to render everything on the client.
We heavily used CSS in favor of inline-styles or SVG-attributes. This has some advantages as the SVG can easily be styled using CSS-properties and can be animated using CSS-transitions. The main disadvantage is that a lot of SVG rasterizers cannot cope with external styles in SVG. Therefore a lot of server-side tools fail to render PNG- or JPG-files. Luckily we we already had a little Java-tool for inlining styles, so that we could use the same SVGs in Charts that got e-mailed during the game.
Client Specific Elements
Slightly annoying was the fact that apple has little support for fullscreen applications. Starting with iOS 7.1, however, one can declare minimal-ui as HTML-Meta-Tag resulting in less controls on the side in mobile Safari.