In December 2019, Uta Hinrichs, Stefania Forlini, and Bridget Moynihan published a reflective piece entitled ‘In defence of sandcastles’ in Digital Scholarship in the Humanities. In the article, the authors argued that visualizations in humanities projects are not only tools for end users to search through complex data, but are themselves critical research in their own right. Like much humanities scholarship, digital visualizations of historical data are the result of a set of editorial decisions. What makes these decisions interesting is that they must cross different disciplines — bringing together humanities scholars and technical specialists (data modellers, UI/UX designers, web developers etc). In what follows, I want to outline the rationale for some of the decisions behind the visualizations in the Mapping the Scottish Reformation website and to underline how the maps users can play with on the ‘site are the product of deep collaboration between different disciplines.
I want to focus on the Journeys map on the MSR website. This will keep me on track, but it is also because this particular map contained a number of editorial and technical challenges that made us reflect critically on what constituted a clerical career path in early modern Scotland.
TL;DR: The interdisciplinary discussions around the creation of the Journeys map — a process that was part of a modern humanities project — made us reflect on the experience of being a cleric in early modern Scotland.
For context, our current Journeys map contains the career paths of 654 ministers and includes 935 separate appointments made across Lothian and Tweeddale between 1560 and the turn of the end of the seventeenth century. At the outset, the historians on the project team had some ideas for what such a map should achieve:
- To show clerical migration patterns
- To be able to identify typical clerical careers
- To understand the distances a minister might cover in his professional life
These questions are all related to longstanding discussions within scholarship of the Reformation and, as such, they represented our own assumptions about what a) users might find useful and b) what we think constitutes a clerical career.
The discussions over how to visualize these journeys forced us to reflect on these assumptions. Our original idea was that parishes in which a minister served would simply be connected by lines that would be clickable by users. These lines would be searchable in some manner. Here is an early example we built on Wikidata:
The example above had four properties:
- Places and years: ‘Athelstaneford (1682), Bathgate (1665)
- Total moves: ‘2’
- Name: Walter Rigg’
- Coordinates: [to plot him on the map]
Once the data was presented on our test website, however, it quickly became apparent that these lines would not be particularly useful for visitors to our website (for example, simply drawing lines from one place to the next offered no temporal context), but also that, from a technical perspective, applying filters to huge lines with no differentiation would be very difficult: we had exported our data as strings of text so places and years could not be read by separate filters. Also, the string of text showed a minister’s journey in any order (notice how Rigg’s career in the image above is recorded in reverse sequence). The technical limitations of our data and what this data was saying about a minister’s career forced us to go back to the database and extract a different set of values:
- Name
- Total moves
- Place ranking sequence
- Separate year for each move
- Year when a minister left parish
- Coordinates
This change to the data model gave us a much more flexible structure for our filters to actually work, but it also allowed us to consider the direction a minister’s career could take. We could now add arrowheads to each move in a cleric’s career and red and green dots denoting the start and end point of (what could be v lengthy) careers :
This was a significant technical and user-friendly fix, but our approach belied one huge assumption we, as historians on the team, had made: our decisions to this point had privileged clerical mobility. In a project about mapping the Scottish Reformation we had fesitishized the idea of movement.
In our passion to convey to our developer partners that we wanted to explore movement, we had missed a huge chunk of our dataset: those ministers who had only served one parish — those who did not move. Our data modelling allowed for these individuals, but our ideas about visualization gave no place for them. Here is a screengrab of an early prototype showing James French, a minister who had served at only one parish (Penicuik):
Without a conversation with our developer partners who spotted this issue, we may have shipped a build of our website that did not show these individuals (who, btw, represent the largest proportion of ministers). But their diligence also raised the question of how, in a website about mobility, we give due credit to those individuals who dedicated their lives to just one place? Historical assumptions meet visualization questions.
A technical solution solved the historical question: our developer partners implemented a system whereby those ministers with a parish count of ‘one’ would be listed in their parish. This would allow these critical figures to be displayed and that their service to one parish be specifically parked: in other words, their lack of mobility is marked by a specific UI element and defined by the parish they served:
These kinds of fruitful discussions between developers, UI/UX specialists, and historians can be cyclical. For example, having seen the linestrings and prompted by feedback online, we reflected on the extent to which the point to point linestrings reflected contemporary travel routes, roads, and communication networks. Using a modern route planner, we cobbled together an example for our developers:
This looks even better when there are longer distances involved.
— Chris R. Langley (@Chris_R_Langley) September 14, 2020
The routes, obviously, are along modern roads, but it gives some sense of the geography of these journeys.
This was built using the Leaflet Routing Machine & a bit of css animation pic.twitter.com/l8RoZVOXEo
Unfortunately, there were both technical and historical problems with this solution. First, this route planner used modern road networks. It will only really be with the fulfilment of projects like this one that would allow scholars to follow contemporary travel routes. Second, the route plug-ins for our maps platform only allowed for one route to be animated at any one time raising questions about how to implement this at scale. Finally, there was an issue of interpretation in animating lines like this: were we, again as historians, privileging mobility in clerical careers with cool UI features that were not actually representative of most clerical careers. This is an example of where editorial discussions between developers, historians, and UI designers forced us to reconsider what we were conveying with these visualizations.
There are many more examples in our discussions over our first website where expertise in web development, historical knowledge, and UI/UX design brought about significant innovations in how we treated historical material, modelled the data, and built the website. This is just one of them. The process of iterating different versions of our maps forced us to ask questions of what we were seeing: not merely from the perspective of ‘how might a user use this’, but also fundamentally questioning what we thought we knew about the data. Our dev’ partners posed questions to the historians on the team, which in turn forced reflection, which then forced further questions about visualisation.
At their best — and I cannot emphasise this enough — these conversations are utterly energising. While the historians on the team have already been outed for their sheer enthusiasm during these meetings, the level of collaboration implicit in this process is very real and exciting. I remember several project meetings where the collaboration between the team was so fluent that we were flying through new ideas, facing interpretative or technical challenges, devising alternatives, and then watching our developer partners design and revise the website code live on a screen share on Zoom. We were watching the results of our editorial conversations between different disciplines come to life in real time.
This communication process isn’t always easy. But with a degree of candour, an understanding of what domain expertise one area brings to the project, and an ability to openly reflect on the assumptions you bring to the table, projects like ours can build data structures and visualizations that are products of collaboration in their own right, as well as tools for other researchers.
Chris R. Langley
