Designing a Visual Interface for GAP Texts

In my last two posts, I covered some of the technical approaches we used to develop GapVis, a visual interface for exploring GAP texts. In this post, I’ll discuss some of the interface and visualization choices we made in designing the application.

Our starting point, as with the technical work, was the prototype interface I built for HESTIA. This was a single-screen application with various components to help the reader navigate through the Histories of Herodotus, including a map, a narrative timeline, the text of the page, and a set of navigational controls. As we started to brainstorm all of the new features we might add in adapting this for GAP, we quickly realized that presenting every widget and visualization to the user on one screen would be visually overwhelming. With that in mind, we broke up the application into three “views”, focused respectively on one book, one page, and one place:

• The Book Summary View, which provides a perspective on the text as a whole;
• The Reading View, based on the original interface, which focuses on a single point in the narrative and is meant as an enhanced interface for reading the text; and
• The Place Detail View, which offers more information on how a particular geographic location fits into the text.

In each of these views, we present a set of interface components providing textual detail, visual analysis, and navigation controls, including:

Google Maps: Each view has a map, but each map functions differently according to the focus of the view. The Book Summary has a static map of all places referenced, giving a quick view of the book’s geographic scope; the Reading View only shows places in the narrative vicinity of the current page, fading them out as they fade from the reader’s attention; and the Place Details view shows a network map of related places, based on co-reference (i.e. places that appear on the same page) within the current text. In each of the maps, the dots marking each location are colored according to reference rank, with highly referenced places shown in red while rarer places are a darker purple.

Place Frequency Bars: These are essentially sparklines of textual references, showing where in the narrative each place is mentioned. A good example is the frequency bar for Carthage in Gibbon’s Decline and Fall of the Roman Empire – the city has a lot of references in the beginning of the text, then fades out of the narrative later on. The Book Summary includes frequency bars for all referenced places, allowing you to compare and contrast, while the Place Details view emphasizes the bar for the current location.

Narrative Timeline: The Reading View includes a narrative timeline (using the SIMILE Timeline widget), showing the current narrative location and the places referenced on nearby pages. The timeline is linked to the map, so that locations are hidden as they move out of the timeline’s visual area.

Navigation Controls: Each view has a set of navigation controls allowing the user to move either within the current view (e.g. switching to a different page or geographic location) or between views, allowing users to change their area of focus. Almost all place or page references are also navigation controls, offering a link to more details. For example, clicking on a point in a place’s frequency bar will jump to that point in the narrative, with that place highlighted.

Screen Transitions: The ease of navigation carries an associated risk of confusing the user by jumping from view to view, which we’ve tried to mitigate with the screen transitions. Each screen slides in logical order from left to right, as do the pages in the Reading View, helping users to situate themselves in the application – a design pattern cribbed from mobile apps (and supported by increasing user familiarity with these interfaces).

There’s a lot more we’d do if we had the time – for example, we have views for a book, a page, or a place, but not for the entire corpus or for a single author, both of which might be interesting. And there are still a number of tweaks and refinements we’ll probably get around to adding eventually, like better interstitial loading screens. It’s definitely a work in progress (we even added “beta” to the header, which is basically the Web 2.0 equivalent of a little animated man with a shovel), but we hope it’s solid enough to test out some of these approaches and get some feedback on what works. Let us know what you think!

Advertisement