Theming Victoria's first govCMS site

Recently Salsa Digital had the pleasure of building the first Victorian govCMS Budget website. A responsive, ‘mobile-as-desktop’ modern website that took the best bits of www.regions.vic.gov.au and implemented them into the govCMS platform.

The centrepiece of this project was undoubtedly the interactive maps to allow users to discover how funding was split over Victorian regions. The mapping feature is split into an "explore" page (allowing users to find their region at a glance), and an in-depth "regional" map, which filters through pins to show funded projects across Victoria.

What we hadn’t expected when we began was the amount of raw data we’d need to serve to users. As a comparison, the regions.vic.gov.au site uses nine region shapes of simple geometric detail. This means fewer data points, smaller file transfers and faster load times. However, budget.vic.gov.au has 79 regions of high detail — the Mildura region alone is about the same size as the entire regions mappage load.

We built various prototypes during development stages for serving this data, testing the use of:

• Shapefiles (compressed files that contain geometric data for mapping).
• Decompression using unzipping in JavaScript (with and without parallel processing).
• Storing processed data in an indexedDB to reduce future data calls or data processing.

We found that when JavaScript processed 7MB zip files (25MB of text-based data), at best Chrome was slightly unresponsive (for about three seconds), and at worst it completely crashed. Mobile phones (Windows Phone 8, iPhone and a HTC One m7) would take one to two minutes to process and IE9 simply couldn’t handle the zip decompression. Overall this configuration resulted in poor performance and was unreliable for most devices.

Ultimately the most stable and compatible implementation using full data passing was to:

• Pre-process the shapefile before serving to the client (to reduce JavaScript processing).
• Keep the data as text-based JSON and avoid any client decompression.

However, this meant 25MB of data would need to be sent upfront, giving roughly a two-minute load time at 3G speeds. While this option was slower to load with more data to transfer, this had the best compatibility with browsers and had little issues in processing. The two-minute load time was unacceptable, so we decided to keep the mobile site as lean as possible by removing the map completely and only displaying the funding data. For the desktop version we figured that if the user had trouble seeing the map or was on restricted data usage, there should be an option (as per mobile) to see only the funding too. So we trialled a warning message that showed up on first visit to the map, with an option to switch between views as well. This was better, but we felt further improvements could be made.

The final solution

In the final version we split up the 25MB total region data into specific regional chunks. This means when you view a region, only the data for that region is collected, reducing what you download to only what you need right now. For a user interested in only one or two regions, this saves them from downloading the other 77 regions they will never see. Once this was implemented, page load times dropped significantly. Approx 1.5MB/18.05 seconds (94% less data, and 85% less initial loading time) for 3G.

A good UX design is one that puts the user first and the technology second, and we hope the users of the Budget site don’t even notice map performance and considerations we’ve invested. But you, dear reader, are now a little wiser than most.