Posts Tagged ‘ interface ’

The Implications of Database Design

In studying the database schema for the Prosopography of Anglo-Saxon England (PASE), several features of the design are immediately apparent[1].  Data is organized around three principal tables, or data points: the Person (i.e. the historical figure mentioned in a source), the Source (i.e. a text or document from which information about historical figures is derived), and the Factoid (i.e. the dynamic set of records associated with a particular reference in a source about a person).  There are a number of secondary tables as well, such as the Translation, Colldb and EditionInfo tables that provide additional contextual data to the source, and the Event, Person Info, Status, Office, Occupation and Kinship tables, among others, that provide additional data to the Factoid table.  In looking at these organizational structures, it is clear that the database is designed to pull out information about historical figures based on Anglo-Saxon texts.   I admire the versatility of the design and the way it interrelates discrete bits of data (even more impressive when tested using the web interface at ), but I can’t help but recognize an inherent bias in this structure. In reading John Bradley and Harold Short’s article “Using Formal Structures to Create Complex Relationships: The Prosopography of the Byzantine Empire—A Case Study”, I found myself wondering at the choices made in the design of both databases.  The PBE database structure appears to be very similar if not identical to that of the PASE.  Perhaps it’s my background as an English major—rather than a History major—but I found it especially unhelpful in one particular instance: how do I find and search the information associated with a unique author? With its focus on historical figures written about in sources, rather than the authors of those sources, the creators made a conscious choice to value historical figures over authors and sources.  To be fair, the structure does not necessarily preclude the possibility of searching author information, which appears in the Source table, and there is likely something to be said of the anonymous and possibly incomplete nature of certain Anglo-Saxon texts.  In examining the PASE interface, the creators appear to have resolved this issue somewhat by allowing users to browse by source, and listing the author’s name in place of the title of the source (which, no doubt, is done by default when the source document has no official title).  It is then possible to browse references within the source and to match the author’s name to a person’s name[2].  The decision to organize information in this way, however, de-emphasizes the role of the author and his historical significance, and reduces him to a faceless and neutral authority.  This is maybe to facilitate interpretation; Bradley & Short discuss the act of identifying factoid assertions about historical figures as an act of interpretation, in which the researcher must make a value judgment about what the source is saying about a particular person(8).  Questions about the author’s motives would only problematize this act.  The entire organization of the database, in fact, results in the almost complete erasure of authorial intent. What this analysis of PASE highlights for me is how important it is to be aware of the implications of our choices in designing databases and creating database interfaces.  The creators of PASE might not have intended to render the authors of their sources so impotent, but the decisions they made both in the construction of their database tables and of the user interface, and of the approach to entering factoid data had that ultimate result. Bradley, J. and Short, H. (n.d.).  Using Formal Structure to Create Complex Relationships: The Prosopography of the Byzantine Empire.  Retrieved from PASE Database Schema. (n.d.). [PDF].  Retrieved from Prosopography of Anglo-Saxon England. (2010, August 18). [Online database].  Retrieved from

[1] One caveat: As I am no expert, what is apparent to me may not be what actually is.  This analysis is necessarily based on what I can understand of how PASE and PBE are designed, both as databases and as web interfaces, and it’s certainly possible I’ve made incorrect assumptions based on what I can determine from the structure.  Not unlike the assumptions researchers must make when identifying factoid assertions (Bradley & Short, 8).
[2] For example, clicking “Aldhelm” the source will list all the persons found in Aldhelm, including Aldhelm 3, bishop of Malmsbury, the eponymous author of the source (or rather, collection of sources).  Clicking Aldhelm 3 will provide the Person record, or factoid—Aldhelm, as historical figure.  The factoid lists all of the documents attributed to him under “Authorship”.  Authorship, incidentally, is a secondary table linked to the Factoid table; based on the structure, it seems like this information is derived from the Colldb table, which links to the source table.  All this to show that it is possible but by no means evident to search for author information.

Pleasure-seeking scholarly primitives

HuCo500 – Weekly questions

According to Aristotle, scientific knowledge (episteme) must be expressed in statements that follow deductively from a finite list of self-evident statements (axioms) and only employ terms defined from a finite list of self-understood terms (primitives). [Stanford Encyclopedia of Philosophy] (Unsworth)

In his article, Unsworth uses the notion of “primitives” as a way of understanding how humanities researchers can put digital methods into practice.  More specifically, he looks at how Aristotle’s “episteme” could be applied as a method in interface design.  In reading the article, it seemed that the “scholarly primitives” (our finite list of self-understood terms) stood in for the basic needs of the “scholarly” user.  Could we alternately frame Unsworth’s “scholarly primitives” by defining the user’s basic needs as the starting point in designing interfaces (for humanities scholars)?


From a theoretical perspective, the exploration of online browsing environments can be situated wihtin the design of new digital affordances…  As Frascara (xvii) points out, such affordances are particularly attractive when they exist in a context of an environment specifically inteneded to support and extend communication: “We need so much to see what surrounds us that the sheer fact of seeing a wide panorama gives us pleasure.” (Ruecker)

Is “pleasure” a goal of humanities research?  Is this perhaps where we can situate the previously discussed element of “play” and its role in digital humanities methods (e.g. Sinclair’s Hyperpo, Ramsay’s ‘Algorithmic Criticism’, Manovich’s ‘Cultural Analytics’)?



Ruecker, Stan. “Experimental Interfaces Involving Visual Grouping During Browsing.” Partnership: the Canadian Journal of Library and Information Practice and Research. 1(1). 2006.

Unsworth, John. “Scholarly Primitives: what methods do humanities researchers have in common, and how might our tools reflect this?” part of a symposium on “Humanities Computing: formal methods, experimental practice” sponsored by King’s College, London. 2000.

Designing Users/Interfaces

Huco 500 – Weekly questions

Tognazzini uses the term “user” quite a bit in his article without qualifying it.  He indicates that the most important part of building an interface that “anticipates” a user’s needs is knowing your user, but this goes without saying.  The user as a concept relies entirely on the service one offers; the user for a medical reference database for medical professionals will not be the same as the user of a social media application (e.g. Twitter).  It might be more valuable to start by thinking about the service an interface offers, and to consider the best/most effective possible way of showcasing/presenting that service.  Determining user expectations and behaviours will be much easier once this task is complete, and will avoid making generalizations about what users want.

Effective applications and services perform a maximum of work, while requiring a minimum of information from users. (Tognazzini)

How do you determine what the “minimum” is?  The interface still relies on the user having some idea of what result they need.  A developer should start with what service(s) the interface assists with, and build the interface based on what the requirements are to fulfill that service.  Note that the less information a user provides the less accurate a result will be.

How do you conduct an interface user study?  What tasks do you need test users to perform?  What questions should you ask?  How do you measure effectiveness and efficiency?


Tognazzini, Bruce. “First Principles of Interaction Design.” Last accessed 7 October 2009.