Skip Navigation
Falvey Library
You are exploring: Home > Blogs

Interactive Map Building using the Raphaël JavaScript Library


With the dual challenges of a complex building and constant resource and personnel movement due to construction, Falvey Memorial Library at Villanova University required an easy-to-update method to both guide our patrons around the building and help them find the resources they need. To do this, the Library Technology Team developed an interactive map system built using the Raphaël JavaScript libraries that allows for fast updates and easy map construction, while still allowing the map to be dynamic and interactive. JavaScript and the Raphaël libraries were chosen over other technologies to maximize accessibility by our community.


Nowadays, when people talk about challenges facing the modern library, they most refer to issues and challenges in the digital world. Here at Falvey Library though, one of our daily challenges is still in the brick-and-mortar realm – specifically, the actual brick and mortar that makes up our library building. Starting in summer of 2011 (Monday, August 22 to be exact), Falvey Library began renovations to the building to improve the working space of the library, with one of the goals to merge the different disparate sections of the library building into one (mostly) unified space. This work will go far in reducing the challenge of the physical building which, previous to the construction, has been a patchwork of different additions and extensions, resulting in the library building operating as if it were two separate spaces.

During this process, many of the stacks and collections are being moved around to make way for the construction teams, with many of our collections crossing over from one of the previously mentioned operating spaces into the other. As well, many members of our staff, including our library Director, have moved to temporary offices, with future plans for various staff members to move into newly constructed spaces. A new learning commons is also planned, so whole departments within the library will be moving to take advantage of this new space (including our campus writing center and campus math center, amongst others).

As you can see from above, our library is currently in a state of flux, and with a complex “gestalt” building and constantly moving locations of both collections and people, we have a real challenge on our hands making sure patrons can find the people and resources they need in a timely and efficient manner.

So how can the tech department help?

The Challenge

The quick answer of course is we need a map and directory that can keep up with the changes and can quickly inform patrons on where to find the person or resource they need. This system needs to be flexible enough to handle periodic changes both to the locations of people and resources as well as changes to the physical building itself. Furthermore, it needs to be accessible by the widest possible audience. Finally, since we’re taking the time to do this, why not make the map interactive and code it to work directly with our catalog, pointing patrons directly to the shelf on which a book or resource currently resides?

From above, it looks like we want more than a static map, and thus code is involved. But what method to use to implement our new interactive map?

The first and most obvious choice would be to use Adobe Flash, and a quick spin around the Internet confirms this as the majority of interactive maps are built using this technology. The reason for this is simple – Flash use is widespread in the web universe and Flash itself is relatively cheap to implement. On the other hand, the webverse is starting to turn on Flash as being a dated technology on its way out the door. Now, though I believe the rumors of the demise of Flash to be a bit premature, there’s no denying that the loss of accessibility to the map on the Apple mobile devices is a big loss to our patrons. As much as I don’t like my technology use dictated by the whims of a corporate giant, excising Apple users from the interactive map is too big a loss in community share for me to be comfortable with this choice. Besides, I do share some of Steve Jobs’ criticism of Flash in its bulkiness, incessant need for upgrades, and general sluggishness of pages running Flash applications. So, what else do we have?

Always out to clone and usurp hot technologies, Microsoft has its Flash competitor in Silverlight, our next contestant in the “Interactive Map Technology Showdown”. Now, having been a WPF programmer awhile back (Silverlight having started its life as WPF/Everywhere, so the technologies are very similar) I have to admit to being slightly partial to this choice. Personally, I find WPF/Silverlight coding the most fun of any language I’ve run into in a long time – unfortunately, I have to admit that not only are the issues from Flash above also prevalent in Silverlight, Silverlight has the added huge negative not being nearly as widely adopted as Flash. Therein, Silverlight also isn’t a great choice for the map with our requirement of maximum accessibility.

One more technology of note in this challenge is HTML5, and though HTML5 looks highly promising, but it technically doesn’t exist yet (as of this writing, it’s expected to publish in 2014).

So what’s the winner?

The Solution


More specifically, the backbone of the graphics is powered by the Raphaël JavaScript Library, a free, open source (we like those at Falvey Library) vector graphics library. This library allows me to draw and display any shape using the SVG standard and to add event handlers to these shapes (i.e., adding an event that turns the shape red when the mouse moves over the shape). It also includes a simple library to add animations to shapes (including motion and fading), as well as image manipulation and display.

So, why JavaScript (and the Raphaël library) over the competitors? For one, JavaScript and the Raphaël libraries don’t require a plug-in, whereas Flash and Silverlight do. In terms of accessibility, this puts JavaScript on top of the list (and no annoying software update or broken players). Furthermore, JavaScript is much more lightweight than Flash and Silverlight – for example, JavaScript loads much faster on page load that either Flash or Silverlight (both of which feel sluggish to me in general on page load). Finally, compared to Flash at least, I found that working with JavaScript and Raphaël made making animations much easier. Most of all, by using JavaScript, I am hoping to allow the widest range of users to access the interactive map, as JavaScript is the most universal and dynamic web language available today.

The Implementation

The interactive map is currently implemented on Falvey Library’s website here.

Like JavaScript itself, the whole interactive map system is very lightweight – the system consists of only a few JavaScript files, a JSON file to hold the map data, and a few image files. All the highlighted areas you see (front desk, shelves, etc) are shapes created via Raphaël, but hidden from view until highlighted. The “floors” as well are Raphaël image objects piled on top of each other — to switch pages I just change the order of the image objects in the Raphaël object stack, while pushing the shapes associated with that page on top of the image, so that mousing over them will trigger their event (and since other floors are piled under the image object moved to the top of the stack, you don’t get interference from these objects).

I used the free, open source SVG tool InkScape to determine the graphics coordinates of my shapes. To do this, I simply loaded a floor map into Inkscape, drew each shape using the SVG freedraw tool, saved the image, then finally copied the coordinates of the shape (pulled from the save file) into a JSON file. This process is a bit labor intense (especially since I did every stack row) though it didn’t take me more than a day since each successive shape gets easier once you get the rhythm of the process down. Once this is done, the JSON is updated to hold info on any person, department, or call number range held in each shape — this way, when the map info changes, all I have to do is change a setting in the JSON file and I can quickly manipulate the information on the map.

The final step is to add a set of JavaScript functions to the page header that read the JSON file and build the page. All the extra JavaScript functionality (determining which range an entered call number is in, etc.) is also stored in the header.

The Way Forward

Right now a lot of my JavaScript code is tied into our CMS (Concrete5). I hope to refactor the code soon to break this dependency and allow easier code adaptation by other institutions. As well, there are currently way too many hard coded items in the code – these need to be moved out into a config file or JSON file to allow for much greater flexibility in updating maps (I’ve begun this process but have a long way to go). Paradoxically, I hope in the near future to packagize and submit the map software to the Concrete5 marketplace (under the GPL or MIT licence) to allow the general Concrete5 community to take advantage of this code

If you’re interested in more technical details, or are considering adopting this system in your own website, please don’t hesitate to contact me at and I’d be happy to field your comments or questions.

1 People Like This Post


Last Modified: September 14, 2011

Ask Us: Live Chat
Back to Top