Earlier this year, we (Swirrl), launched the OpenDataCommunities site, on which we host a Linked Data version of the 2010 English Indices of Multiple Deprivation.
Map Explorer
Over the last week or so, I’ve been building a map-based web app (check it out here), which can be used to explore the data from OpenDataCommunities. The map shows the Lower Layer Super Output Areas (LSOAs) in England, coloured to indicate the level of deprivation in the area. It’s just a single web-page, built purely with HTML, CSS and JavaScript.
I thought it would be useful for others if I shared how I went about building this little app, to illustrate how the combination of Linked Data and JavaScript lets you create quite rich visualisations, and to explain some JavaScript techniques that could easily be re-used elsewhere.
The “Let’s make a Linked Data app” series of blog posts
This is the first of a series of blog posts which describes the process I went through. By following along with these blog articles, you’ll be able to build up the functionality step-by-step. The final source code for the completed app can be found on Swirrl’s Github account (it’s open-source, and you’re welcome to reuse it as you like).
Throughout this series, some basic knowledge of JavaScript and HTML and Linked Data is assumed, but I’ll be explaining everything that I don’t think is obvious.
In this first article, I explain how I set up the overall structure of the page and the code. In the next article, we’ll get on to retrieving and displaying some data.
Note: These articles will use Github gists for showing code-snippets, and if you’re viewing this in a feed reader they might not show up. So I recommend you read it on the web instead.
Features of the app
You’ll see from playing with the app that there are a few main aspects to it:
- A Google map, on which the LSOAs are plotted, with a colour-key.
- A dropdown, to change the deprivation indicator (Combined, Crime, Health etc) being plotted on the map.
- A form, to centre the map by postcode.
- A sidebar which shows additional information about the selected LSOA (area). This includes the frequency distribution of the scores for the current deprivation indicator, and links to the Linked Data resources.
Page Structure
First, let’s set up the basic HTML page structure that will be used for everything in the app.
We’re going to be using Google’s map API, jQuery and Raphael.js, so let’s include them in the page’s head. Also, in the head is a link to the stylesheet that I used for the page (you can find this file here. In the interest of brevity, I wont bother including it in this blog post).
In the body of the page, there’s a container element that wraps everything. This is useful for the way I wanted to do the stylesheet. The info element is the sidebar, and the map_canvas is where the map will be rendered. Next, we have the domain drop-down selector, and an element called colour_key in which the colour-key will eventually go. Finally, we’ll be putting some HTML in templates which we don’t want to render directly, but which we’ll reuse to display some information in the sidebar.
If you create that HTML page, and make the stylesheet available at the right relative path, you should be able to view the basic page structure in your browser.
Code Structure
To keep things nicely organised, let’s just put JavaScript code that deals with the DOM in the HTML file itself, and put everything else in separate JavaScript files, each with its own job.
To avoid polluting the global namespace (that is, to avoid any possible name clashes with other JavaScript that might be on the same page), the JavaScript that goes in the HTML page should go in its own closure – let’s add that at in the html page, just before we close the <body> tag.
Again to avoid polluting the global namespace, we can make a special namespace in which all our JavaScript classes and structures will live. I’m going to call my namespace swirrl, and add it to the window object. This code goes in a file called swirrl.js, which we’ll load in our page’s head.
We’ll be adding more JavaScript files as we go along, and they’ll add stuff to the swirrl object.
This code also adds a simple wrapper to console.log that checks if the console object exists. We can use window.swirrl.log in our code instead of console.log, and we won’t need to worry about removing all the logging before releasing.
Next time…
So that’s the basic structure of the app set up. There isn’t much to see yet, but we now have everything nicely organised. We’ll get cracking with adding some actual functionality next time. Stay tuned!
