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 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 interactive map is currently implemented on Falvey Library’s website here.
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 Way Forward
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 firstname.lastname@example.org and I’d be happy to field your comments or questions.