Visualization Wall Digital Collections Explorer
The Hunt Library has many interesting architectural elements and unique spaces. Outside of the Teaching and Visualization Lab is the Visualization Wall which occupies an area 25.3 feet wide and 10 feet tall. Each of its seven columns is 10 tiles high. The second and fourth columns from the left are two tiles wide instead of one. This wall can be approached in multiple ways from a design perspective. Content can be designed on a single rectangular canvas and the wall will automatically create a picket fence effect. Or the design can make use of the columnar arrangement in other interesting ways.
We wanted to place some of our rare and unique digital collections content on the Visualization Wall, and wanted to show the variety of the content that we have. We decided to place images from a different broad content topic on each column. Topics include people, sports, engineering, architecture, campus and town, student life, and textiles. We had previously created the supporting metadata to place all of our resources into these broad topic areas. Each column contains a full-width strip of images down each column from a single topic. The initial set of random images shown when the application loads is filtered by a boolean facet in our metadata that allows us to select some of the most visually interesting resources in the collection.
The Visualization Wall is near a busy study space, so I did not want to create something that was too distracting. For this reason we only ever include a small number of videos. At the same time we do not want the content to grow stale and want folks to notice the exhibit which functions as an advertisement for our digital special collections materials.
We balance these concerns through periodic animations. The exhibit is created with Web technologies so we can use some simple JavaScript for the animations. Most of the time the columns do not have any motion. Every 20 seconds the columns animate a move up by one image. Extra images are placed into each column to show a greater variety of images and allow the column of images to be taller than the column viewport. New images come into view from the bottom. Once the last image in a column has become visible the column animates up to the first image at the top again. In this way a wider variety of images can be loaded into the HTML page at one time and visitors in the space can still see new images each time they pass by. The videos are embedded using HTML5 video and use the loop attribute so that they are always playing when they come into view.
Take Control
While the special collections images on the Visualization Wall function just fine as an attractive advertisement of our digital special collections, we wanted to take it further. Visitors in the space are encouraged to “TAKE CONTROL” and “Change the images.” The URL they visit presents them with an HTML page that works as a remote control.
First a user selects a column to change, and then they select a topic to put on that column. Once a topic is selected, random images from that topic are displayed on the selected column. This allows anyone who enters the space to reconfigure the exhibit in a constrained, simple way that still allows for lots of different combinations.
When the user makes selections with the remote control application, it triggers a message to be sent to the HTML page that makes up the columns on the Visualization Wall. The web page displayed on the wall persistently listens on a WebSocket channel for updates. The message the wall receives contains the column where to display the data, the topic, and the HTML needed to display the images on the wall. Again, the messages are delivered over WebSockets to decrease any latency in displaying the content on the wall. A WebSocket is also used to communicate back to the user remote control.
Now what happens when the user sees an image that they are interested in? We did not want to add a lot of descriptive text like titles or other metadata to the wall. Too much text detracted from the appearance of a wall which is very much a part of the architecture. But we still wanted to provide access to the full resource metadata and encourage further discovery within our collections. The remote control includes a view that allows you to see more information about the content on the wall. The column topics are arranged down the page in the same order as they are on the wall. You can tap through any of the column topics and see thumbnails and titles of the images in the same order as they are displayed in that column on the wall. Then you can tap on the image to see more information about each of the resources on our responsive digital collections site.
The interesting technical piece about how this works is that there is no persistent data store on the server to supply this data to the remote control page. All of the data comes directly from the Visualization Wall HTML page itself. The canonical source of this data is always the HTML page on the wall. When the remote control client requests the current contents of the wall, a message is sent to the wall via WebSockets. The HTML page on the wall then collects and sends back the data also via WebSockets. The data includes the column number and topic and the identifier and title of each image on that column. The communication to the wall and to the client is done over WebSockets, and it removes the possible latency of two browser requests that might be introduced with a polling strategy.
The architecture used for this particular feature has its limitations. It is probably slower than maintaining state on the server and returning it more directly to the remote control. This approach also has some advantanges. While I have access to a server where I could run an application and database, I wanted to see what would be involved in potentially eliminating the requirements for such infrastructure. We may have partners who would like to design something for one of the walls who either do not have access to or are less familiar with server-side technologies. We have not done it yet, but we can consider offering use of a WebSocket server or show simple ways to deploy a pre-packaged WebSocket server to a cloud service. With a WebSocket server and some knowledge of JavaScript, doing this kind of interactive development may be easier for our partners and still allow for maintaining some state.
Here’s a screen recording of the basic look and interactions of the piece:
For more information about this project see the following:
- WebSockets for Real-Time and Interactive Interfaces presentation at Code4Lib 2014