Digital Medievalist 7 (2011). ISSN: 1715-0736.
© Roberto Rosselli Del Turco, 2011. Creative Commons Attribution-NonCommercial licence

After the editing is done: Designing a Graphic User Interface for digital editions

[ Skip to Abstract | Return to Top ]

Commissioned Tutorial

Commissioning Editor: Daniel Paul O'Donnell, University of Lethbridge.
Accepting Editor: Daniel Paul O'Donnell, University of Lethbridge.
Received: May 18, 2009
Revised: July 26, 2009
Accepted: August 1, 2010
Published: February 9, 2012

Keywords: Interface Design; Graphical User Interface (GUI); Digital Editions; Digital Humanities (History).


[ Return to Navigation]

Introduction

§ 1    With its origins dating back only to the second half of the twentieth century, Computer Science can be considered a very young discipline. The widespread adoption of the "Personal Computer" is even more recent. Introduced in the 1970s, its ascendancy was recognised by Time Magazine as recently as 1983 (Time Magazine 1983). As a logical consequence, the study of User Interface design for computing devices is even younger. Indeed the idea of a Graphical User Interface (GUI) is quite a novelty: it is possible to trace a clear evolution from a non-graphical interaction by means of physical devices (punchcards and readers) to the CLI (Command Line Interface), where you type instructions that the computer will execute, and finally to the recent advent of the GUI and its WIMP (Windows, Icons, Menus and Pointing device) paradigm. So recent indeed is this development that a number of crucial key concepts and theories that govern their use were conceived a long time before an actual implementation would become feasible. The word "hypertext," for example, was coined by Theodor Nelson, who later worked at a Hypertext Editing System at Brown University, in the mid sixties (see Nelson 1965).

§ 2    The evolution of the GUI hasn't been easy or uncontroversial: looked upon with disdain by experienced CLI users, the desktop metaphor took quite some time to establish itself; then the advent of Internet and of the World Wide Web exposed a completely new set of issues with regards to web sites' usability and accessibility. Some of the most common problems have been solved in the most recent versions of widely used Operating Systems (OS) and in the most popular applications, which have greatly benefited from a broad user base, more theoretical attention, and more opportunities for experimentation by trial and error on the part of the developers. Even then, developments in this field do not always represent improvements (see Spolsky 2006 on design flaws in Windows Vista).

§ 3    Computers have become widely accepted as a research tool by Humanities Scholars in the course of the last decade. And academic applications like Digital Library or Digital Edition software are both limited in their diffusion and often quite complex to create. This is especially true in the case of Digital Edition software: its goal is to integrate and interconnect several layers of information through hypertextuality and hypermediality and it faces a number of task-specific presentation problems (e.g. image-text linking, visualization of variant readings, etc.) that pose unique UI problems. Robinson (2005) lists several reasons why electronic editions aren't more widespread and widely used in the scholarly community: they can be quite expensive, big publishers are not interested and, most significantly from Robinson's point of view, they're very hard to produce because we lack appropriate tools. To this list, I would add the difficulty from the end user perspective of having to learn how to use a new GUI for almost every new electronic edition. It is my opinion that these problems have to be solved in full for Digital Editions to be widely accepted by the scholarly community. In this paper I will examine some important editions of medieval works to identify the most frequent pitfalls in general GUI design, suggesting appropriate workarounds and proposing some thoughts on future developments in this area.

Digital Edition (DE) software

The layers of footnotes, the multiplicity of textual views, the opportunities for dramatic visualization interweaving the many with each other and offering different modes of viewing the one within the many—all this proclaims "I am a hypertext: invent a dynamic device to show me".

Robinson 2005

§ 4    A simple definition of a Digital Edition (DE) might be:

A critical or diplomatic edition in electronic form where every text object (introduction, edition text, critical apparatus, notes, sources and analogues, etc.) is available in digital form and possibly, but not necessarily, organised as a hypertext; again possibly, but not necessarily, including images of the manuscript holding the text (or texts) object of the edition.

§ 5    The latter case is the most interesting for the purposes of this article, as image-based editions are the most complete type, at least as far as medieval manuscripts are concerned. As such, the DE is a very complex object, depending on a software program to connect the different parts together and to allow the user to consult it in the most effective manner.

§ 6    On a purely technical level, a DE can be judged on the basis of several criteria: durability, expandability, usability and accessibility, to list the most important. [1] Usability is important for a successful DE: if the user can't access the edition information in an easy and transparent way, his or her experience is likely to be very frustrating, and the very idea of taking advantage of interesting concepts like hypertext and hypermediality a sterile exercise in technology. Ideally, the DE software should be as completely transparent for the user as is the technology of a printed book: this is a lofty ideal that probably won't be attained in full, at least as long as we'll be forced to browse DEs using the current computing technology, but developers have a clear duty of trying to improve software so to get as close as possible to it.

§ 7    If we actually compare the existing DEs with their noble ancestor and competitor, the printed edition (which, by the way, still seems to enjoy a pretty enviable health), it will be evident how, instead of a simple, consistent, portable, durable and relatively inexpensive UI, contemporary DEs present the user with different UIs, involving different levels of user-friendliness, are often dependent on specific hardware or software platforms, risk a (relatively) quick obsolescence (see O'Donnell 2007), and, finally, are at times quite expensive. In some cases, these UIs restrict the activities of the user by presenting them with a limited number of tools and applications; in others they are even too rich in functionality, which adds to their complexity.

What software for digital editions?

§ 8    The wide assortment of different UIs is to be explained by the fact that, except for the printed critical edition, there is no clear model for developers to build upon; e-books and the document readers used to show them are distant cousins to the DE and similarly uncertain about their origins and future developments. Hypertextual navigation is a powerful theory that still needs further work and experimentation to fulfill its potential. [2] Moreover, the technical path leading to the "dynamic device" dreamed by Robinson (2005) was, and still is, not as clear-cut as we would like it to be. Pioneers in electronic editing were presented with a vast assortment of programming tools—an assortment that is even richer today—and the first decision that they had to make was between using existing software or creating ad hoc programs.

§ 9    At the time the first of the newer generations of DEs were being developed (i.e. at the birth and during the initial rapid growth of Internet), the web browser (or programs with comparable hypertextual capabilities) looked like the most natural choice. Since the World Wide Web is the most natural medium to spread "documents" of all kinds, moreover, DEs included, a very important distinction would come to exist between browser- (or web-) based and stand-alone DEs. Distribution via the Web isn't always possible, but in many cases this is more a publishing choice than a technical problem: many stand-alone DEs are actually browser-based and could be published on the World Wide Web, were it not for lack of permission from rights holders (usually to digitised manuscript images used in the edition). In these cases, we can group them under the browser-based label. DEs based on custom, non browser-based software, on the other hand, are usually stand-alone editions and rarely if ever run from the web.

Browser-based digital editions

§ 10    In a browser-based edition the general aspect and functionality of the GUI is strongly conditioned by the underlying software: the web browser or other browser-like, hypertextual software. This choice presents several advantages, not all of them GUI related: quite often the software is already present on the users' computer, which implies no installation at all; even if that's not the case, 'alternative' browsers such as Firefox, Opera or Chrome can be installed quickly, freely, and with little risk of compatibility problems with the underlying OS. Especially in the case of commercial web browsers, developers can also make a number of relatively certain assumptions about the environment in which users will encounter their work: it can be already localised into a language familiar to the user; its functionality can be extended using a variety of well-understood mechanisms from simple scripts in Javascript to AJAX applications; and the basic elements of the GUI will be quite familiar already to the user.

§ 11    There are some disadvantages, however (again, not all of them GUI related): browser GUIs are somewhat inflexible and difficult to customize and not all browsers are available for all OSs. This first disadvantage can be a real limiting factor, especially for image-based DEs that aim to offer rich functionalities: some important elements in the DE design will have to be implemented as browser plugins, and pose problems of integration, and the limitations and constraints of the programming language (Java, Javascript) being used. The second disadvantage arises if a developer designs the DE with a specific browser in mind (often to take advantage of custom functionality or non-standard/propriety extensions). The can result in work that is unavailable to users of a different OS, or even changes in the OS and/or browser for which the edition was first designed.

Custom environments for stand-alone digital editions

§ 12    In contrast to DEs designed to work with commercial browsers, DEs built upon custom software, offer far greater flexibility, with more freedom to implement different functionalities and organize the GUI according to the author's will. This is unfortunately counterbalanced by potentially more crippling compatibility problems, as portability between different platforms, both hardware and software, is not trivial and obsolescence becomes a real danger. There is little doubt that current valid (X)HTML pages will be readable in fifty years from now and perhaps much longer (although that is surely a less than impressive achievement when compared to the durability of a printed book). Custom-written software older than five years could be impossible to use today without special techniques such as the development of a backwards-compatible "compatibility mode" in the OS or, in the worse case, an emulator for an obsolete OS (see O'Donnell 2004 and O'Donnell 2007 for examples). The risk in this case is that a digital scholarly edition, which is undoubtedly the result of as much work and research as a print scholarly edition, might end up being actually usable for only five-to-ten years: this is clearly an unacceptably short life-span for disciplines where standard editions have citation life-spans of many decades, and one that would greatly detract from the digital edition's usefulness. [3]

§ 13    These different technical problems and potential pitfalls are an important consideration for developers of DEs as they begin their work. And both types of editions are seen amongst recent DEs, although there is a prevalence of the browser-based type. Once it has been decided whether an edition will be browser-based or operate in a custom, stand-alone environment, however, the remaining issues regarding GUI design are substantially identical.

Basic principles of user interface design

§ 14    Human-Computer Interaction (HCI) is a discipline concerned with the design, evaluation and implementation of interactive computing systems for human use. HCI is interdisciplinary, drawing from Computer Science (technology), Psychology (attention, perception and recognition, memory, problem solving), and Visual Design (see below). HCI aims at user-centered design; we should never forget that it's a user interface and that the user's needs should be at the forefront of the developer's concerns.

§ 15    There are many studies of effective UI design [4] : the following, while not exhaustive, lists some of the more important principles for developers of DEs to keep in mind. I explain these briefly here in order to clarify the analysis of existing work presented in the next section rather than as an exhaustive guide.

General principles

Consistency

§ 16    Similar actions should be performed in the same way under the same circumstances; at the same time, different actions should be made explicitly so by means of visual inconsistency. Examples of this principle in action might include ensuring that annotations of all types—e.g. editorial notes, textual notes, interpretative notes—appear in the same location when selected by the reader; conversely, links to other kinds of textual apparatus must be clearly distinguished.

Readability

§ 17    Type and size of characters, as well as choice of foreground/background colors, should make text legible even for visual-impaired users. In addition to the simple question of font, designers should keep in mind the ability to distinguish between different layers of text (e.g. different levels of headers vs. the main text). As uses begin to access DEs using multiple platforms, designers should also be careful about being overly prescriptive: font faces and weights that work well on one platform (e.g. a wide screen monitor or printer) may not work well on another (e.g. a small monitor or tablet).

Recognition rather than recall

§ 18    Users should not be forced to learn what tools, icons, or symbols mean or do. The purpose of every aspect of the interface should be immediately recognizable in the context in which they are made available.

Availability and discoverability

§ 19    The most important actions and options should always be visible and near at hand, secondary actions and invisible structures should be easily discoverable by the user. Users should not need to access secondary menus or pages in order to perform key functions in their work with the DE. It should be easy for users to discover secondary or "advanced" features. A good example of this is in the case of a search menu: users should be able to conduct basic searches by typing directly in the search form, rather than by selecting "basic search" first; the action required to access "advanced" search capabilities, however, should also be immediately obvious from the "basic" form.

Control

§ 20    The user should feel in control of the working environment and should not be forced to learn complicate sequences of steps. Instead designers should provide visible and up to date status information, as well as easy error-handling, and allow reversal of actions. Errors should always be reported in meaningful terms to the user and the user should always know—via icons or time bars or similar indicators—when the processor is responding to user input.

Visible navigation

§ 21    Moving between different "areas" of an application should be an easy process for the user, who shouldn't be forced to learn complicated mental maps; furthermore, the UI should be fully explorable without intimidating the user or risking that the user lose his or her way.

Ergonomics/Human factors

§ 22    The UI should be designed to maximize efficiency and ease of use. In particular, designers should pay attention to the location of important tools and utilities. Navigation links and buttons should be in a consistent location and designed to reduce the need to move the pointing device across the screen. Search bars and other tools should be located where they can be accessed with a minimum of movement or scrolling.

Scalability

§ 23    A good UI should be able to take advantage of advanced system resources (wide screen, fast CPU to allow better responsiveness), but should also prove usable in a low resource environment. Designers should be aware of the different types of devices users will use to access their work and preferably present users different options for access via major types of platform. This can be as simple as supplying different stylesheets for printing and on-screen browsing or as complex as building distinct apps for access via various common tablet platforms.

DE-specific requirements

§ 24    These above principles are of course generally applicable. But they should be a constant concern to developers of DEs, however, because DEs present further requirements, dictated by the functionalities typical of a full image-based edition, that can make defining an optimal GUI even more difficult:

Good hyper-textual functionalities

§ 25    DEs, more than other texts, often make very heavy use of hyper-textual functionality. Individual words and objects in a DE, for example, commonly have more than one obvious target—e.g. a gloss, alternate readings, editorial notes, links to specific regions on an associated image. This presents real challenges for the designer who wishes to ensure qualities like discoverability, recognition rather than recall, and consistency in their GUI.

Special character handling

§ 26    Many editions, particularly of historical texts or of works in languages other than English, make heavy use of "special" characters, including possibly reference to characters not found in standard OS fonts or even characters not included in standard Unicode. Designers of DEs in such cases need to pay careful attention to questions of scalability and control. How can "unusual" Unicode characters be accessed by users? To what extent can private-use code points be avoided? When characters are not found in standard Unicode, are there disciplinary conventions in the use of private-use code points? Are alternative methods of presenting extremely unusual characters or scripts possible?

Image manipulation tools

§ 27    Users of DEs often need to manipulate images. At the most basic level this might involve finding specific locations in a given image, magnifying select portions of an image, and navigating across an image that has been magnified to the point that it is larger than the available presentation medium (e.g. page, screen, etc.). More advanced uses might include manipulating and filtering image data in order for purposes of analysis (e.g. altering colour profiles or contrast for specific research purposes). In satisfying these needs, designers of DEs need to consider questions of ergonomics, scalability, control, recognition and discoverability as well as questions of cost vs. benefit for the design of custom tools and issues on intellectual property rights regarding the images they use. One solution is to include basic manipulation tools as part of the GUI and, where IP agreement permit, allowing users direct access to high quality image files for use with standalone image manipulation tools.

Advanced search functionality

§ 28    Users of DEs often have need for advanced search functionalities. Especially when the underlying text is encoded in eXtensible Markup Language (XML), advanced search tools should include options allowing the user to take advantage of this rich markup.

Integration of supplementary tools (glossary, concordances, etc.)

§ 29    Critical editions (whether digital or in print) are densely organised, information rich environments. In the DE, designers need to consider how users will be able to discover and access a wide range of supplementary tools including glossaries, concordances, appendices, archives of ancillary material or primary and secondary sources. Additional questions include whether it makes sense to replicate traditional print models in the design and integration of these tools into the digital environment. Should a DE contain an analytic index or is full-text indexing sufficient? Should links among witnesses be presented as a traditional textual apparatus? How should glossary or bibliographic information be presented and linked to relevant forms in the text and analytic material? Decisions in this area will have a great impact on control, discoverability, recognition, and ergonomics.

Examples of good and bad design

§ 30    In general, DEs have shown a steady improvement in the usability of their GUIs as technology has improved and more robust cross-platform standards have developed. At the same time, however, it is worth considering examples of problematic design, even from earlier generation DEs, in order to see just how significantly the above principles can affect the user experience. The following survey discusses how successful or less successful implementations of specific GUI features have affected the usability of various DEs published in the last decade. Especially in the case of references to early DEs, this criticism should not be understood as criticism of the design team itself rather than illustrations of a general principle: in most cases, better options were not available at the time; in some cases (such as non-proportional scaling bars on early Mac computers, for example), the limitations were build into the OS or other software itself. Such examples do serve a cautionary function for contemporary designers, however, as they consider how to design editions to work with relatively novel and sometimes still immature technology including the newer mobile platforms.

Legibility of text/icons

§ 31    Legibility of text and icons impacts on Readability and Ergonomics. It is one of the most basic requisites, and it is therefore surprising to see that some editions have problems in this respect. In the initial window of the Canterbury Tales General Prologue (Figure 1), for instance, the selected section of the navigation tree in the left frame is highlighted in a way that makes it almost unreadable. Also, and more important, note the small size of the edition text: the software used for this DE doesn't allow users to increase the text size, but doing this would greatly improve its readability (Solopova 2000).

Figure 1: Chaucer's General Prologue digital edition (Solopova 2000) Chaucer's General Prologue digital edition (Solopova 2000)

§ 32    The Bayeux Tapestry edition (Foys 2003)shares this problem of small text size (Figure 2). Furthermore, a very important element of the GUI, the navigation cursor, is not as immediately visible as it should be both because of its dimensions and because the color chosen (light orange) makes it difficult to distinguish from the background image.

Figure 2: The Digital Bayeux Tapestry cursor (Foys 2003) The Digital Bayeux Tapestry cursor (Foys 2003)

§ 33    Apart from the problems detailed above, these and many other otherwise excellent editions suffer from a problem of scalability: a good GUI should automatically adjust to take advantage of "better" hardware and software, and not force users to live with the lowest common technological denominator available at the time the DE was built. This way the edition can be scaled to work with future, inevitably higher resolution and often larger screens (and in recent years, of course, smaller and more mobile ones). Designers should take care to test their edition does not break when scaled using text-zooming capabilities found in most major browsers. Since such adjustments often treat different components of the GUI differently (e.g. scaling character size in text menus, but not objects such as images), the problem can't be considered fully solved if the GUI relies on absolutely determined font sizes or makes extensive use of images to carry text labels, and so on.

Lack of feedback

§ 34    When buttons are not depressed after clicking on them, or a search operation is started but there is no indication that it is still in operation, the user is puzzled and possibly confused by the software's behaviour. This affects the user's sense of control and may result in such potentially disastrous user behaviour as clicking repeatedly on a given button or link because nothing seems to happen.

Figure 3: Search and image zoom buttons that don't give feedback when used, the latter also fail to show the current image size (Stolz 2003) Search and image zoom buttons that don't give feedback when used, the latter also fail to show the current image size (Stolz 2003)

§ 35    A simple visual cue like an alternative image showing the button in a depressed state, an hourglass, or a completion bar in case of complex operations, would help the user feeling in control and not controlled by the browsing software.

§ 36    Designers should be particularly careful about avoiding the temptation to interfere with the standard functionality of hyperlinks—e.g. by using stylesheets to eliminate the distinction between new and visited links. A useful technique is to add style cues that indicate that a hyperlink has received focus and has been selected.

Cryptic icons

§ 37    In some DEs icons (image- or letter-based) and other graphical widgets are sometimes difficult to understand and operate; furthermore, they are often unaccompanied by any kind of visual help. This affects factors such as Control, Availability, Discoverability, and Ergonomics.

§ 38    Information relevant to the user's task and the actions immediately available must be immediately evident, in primis through a careful choice of icons for buttons and other graphical objects; the very number of interactive objects should be limited to those of most common use, avoiding crowded toolbars as much as possible. When the nature of the action corresponding to a button is not clearly conveyed by the latter's appearance, a non-intrusive use of tool-tips should be sufficient to help the user understanding its purpose quickly.

Figure 4: Toolbars, buttons and cursor from some digital editions: Their purpose is not always evident Toolbars, buttons and cursor from some digital editions: Their purpose is not always evident

Exposing the underlying encoding and files to allow text searches

§ 39    Contemporary textual editions are almost invariably initially encoded using a rich markup language such as Text Encoding Initiative XML. The underlying encoding files are often accessible, although many editors are reluctant to allow users access to them, but in any case they should be completely transparent to the user: requiring that a user perform a search on the basis of the elements employed in the SGML/XML texts means exposing the inner workings of the edition on the assumption that the user knows about markup languages, which is not always the case, and may be intimidating to the less experienced user.

Image manipulation

§ 40    Even a simple task like exploring an image larger than the current window can be a painful experience if it has to be performed through the window's scrollbars. A much better approach to this issue of Ergonomics is to provide for a direct manipulation of the image by means of the mouse pointer.

§ 41    The first Macintosh computers used a non-proportional scrollbar (Figure 5). Not only was this unwieldy, it also prevented the user from guessing how much of the image is currently visible and how much is hidden (compare this to the modern, proportional scrollbar in Figure 6, which allows the user to "sense" the image dimension).

§ 42    Since most modern computer OSs make use of proportional scrollbars, this problem has long been considered largely eliminated, although even many modern OSs still often use unwieldy and ergonomically poor methods of navigating to areas of interest at high zoom levels. But it can still be a matter of concern to designers who make use of a graphical toolkit, such as some Javascript libraries, that implements non-proportional bars. Related problems of navigation may also face designers who intend to work with newer mobile platforms, many of which are still relatively poor in handling the navigation and presentation of large images.

Figure 5: A non-proportional scroll-bar A non-proportional scroll-bar

Figure 6: A proportional scroll-bar A proportional scroll-bar

Visual inconsistency

§ 43    Sometimes the navigation software shows elements of the underlying engine. This can affect Consistency and is true of both stand-alone and browser-based DEs—although the specific problems are often slightly different.

§ 44    In the stand-alone EPPT software, for example, only a small subset of the menus are specifically DE-related. Clicking on the menubar often presents the user with a large number of options derived from the underlying Eclipse environment (on which the EPPT framework is based). In the Electronic Junius edition, based on Internet Explorer, the contextual menus of the browser are still visible and accessible to the user.

Figure 7: Eclipse menus in the EPPT user interface Eclipse menus in the EPPT user interface

§ 45    This intermingling of GUI elements of different origin and purpose can be confusing to the user: the menu voices or buttons corresponding to the user's tasks could be "lost" or not immediately accessible, slowing down the edition navigation. In the case of the EPPT software some of these GUI items, specifically those related to Eclipse's IDE (Integrated Development Environment) capabilities, are useless and probably unintelligible for most users.

Navigation problems

§ 46    Navigation should be simple and consistent: editors should avoid welcoming the user with introductory and/or navigation screens crowded with too many entries and choices, instead presenting a clear and concise table of contents, and assigning to other navigation instruments content selection and visualization. Tools like drop down menus or thumbnails for image and text selection should be enough to make navigation intuitive and unobtrusive, although the designer should be careful not to steal too much space from content display. Navigation should also be predictable and consistent with user's expectations, so to minimize the chance of getting lost or selecting undesired content.

§ 47    Problems in navigation usually occur when the editor makes use of different "environments" to propose different types of content. When the DE is composed of two or more different screens it is quite likely that, if navigation tools are lacking, the user may wonder "How do I get back to where I was?" The creation of a complex, multiple screen DE should be limited to those cases where it is strictly necessary, e.g. in DEs that involve mixed media that current technology cannot easily handle in a homogeneous fashion. In such cases it should include effective navigation tools so that the user can quickly build a mental map of the edition structure.

Designing a better GUI

§ 48    Since the UI has such a fundamental role in empowering the user with regards to selection and access to the edition content, developers should devote an appropriate amount of time to its design. To this purpose they can rely not only on general books about HCI, but also on specific, OS/Desktop-related guidelines, and tools.

Documentation

§ 49    A general recommendation is to study and follow UI guidelines for specific OSs or environments as much as possible (and where applicable): there are good guidelines publicly available for the Apple MacOS X, the Gnome desktop environment (available on Linux and other UNIX-like OSs), and the Java programming framework. Even if the software will be developed to be multi-platform there are many sensible suggestions and ideas that can be gleaned from these texts.

§ 50    Another interesting resource are the usability and user interface sites devoted to help UI design of software applications; some of these are specifically targeted at free software development: see for instance Open Usability (http://openusability.org/) and Better Desktop (http://www.betterdesktop.org/wiki/index.php?title=Main).

§ 51    Finally, it might be useful to look at what has been done wrong to avoid similar errors. A simple Google search for "interface hall of shame" will yield a large number of results (see the Interface Hall of Shame web at http://homepage.mac.com/bradster/iarchitect/shame.htm for somewhat dated but still-useful examples). Positive examples are also available, but are far less numerous (see the Interface Hall of Fame at <http://homepage.mac.com/bradster/iarchitect/fame.htm>).

Use cases

§ 52    The first step for improving current DE GUIs is understanding how users might be using the browsing software. The GUI designer should first identify users' tasks in detail, and define use cases accordingly, then start thinking of a way to implement those tasks in a UI framework. Task analysis can be performed defining use cases using Unified Modeling Language (UML). UML is a notation system for object-oriented analysis and design, a very powerful and widely used open standard (see Jacobson et al. 1992).

§ 53    As a starting point it is possible to define basic tasks common to every conceivable DE:

Figure 8: The GUI study must start here: First approach with the DE. The GUI study must start here: First approach with the DE.

§ 54    Building on this initial, and very limited, set we can describe a minimal use case for DE software as follows:

Figure 9: The simple use case: A text-only edition with standard tools (glossary, search function) and hypertextual navigation. The simple use case: A text-only edition with standard tools (glossary, search function) and hypertextual navigation.

§ 55    It's reasonable to assume, though, that editors may desire more functionalities, and to show manuscript images, which means that the most common use case could look like this:

Figure 10: The most common case: An image-based edition with standard tools (glossary, search function) and hypertextual navigation. The most common case: An image-based edition with standard tools (glossary, search function) and hypertextual navigation.

§ 56    A full-featured DE will expand on image-related functionalities (e.g. hot spots, thumbnail navigation) and on a direct link between text and images:

Figure 11: A rich features case: an image-based edition with text tools (glossary, search function), image tools, and hypertextual navigation. A rich features case: an image-based edition with text tools (glossary, search function), image tools, and hypertextual navigation.

§ 57    It would be possible to add more functionalities, such as note-taking, more complex image-processing tools and 3-D besides 2-D visualization, but these would go beyond the scope of an image-based digital edition, at least in its current form.

Ideas and concepts for a better GUI

Use all the space, use the space well

§ 58    The available space is a very important resource for any type of software, all the more so for a DE browsing software: since many DE visualize manuscript images, as well as text (especially if comparing two or more texts), they need as much space as possible. This also means that, space being such an important resource, it has to be used wisely.

§ 59    The most simple way to access all of the available screen space is to create a full screen application: every other component of the desktop will be temporarily hidden while using the DE browser software. This approach not only allows for optimal visualization of the edition content, but also to follow Fitts' law (see below) and to access important GUI objects (toolbar buttons, collapsible frames) with more ease than if they were used in a normal window on the desktop. The main disadvantage of this solution is that it breaks the normal work-flow of the user, making it difficult to take notes in a word processor, for example, or to alternate edition browsing with other activities. It is therefore recommended to make this an option, possibly not even the default browsing option, and to allow for an easy switch between full screen and normal window visualization.

Flexibility in UI design

§ 60    A way to optimize space use is choosing GUI elements that are flexible and dynamic. Some of the first digital editions adopted a very rigid approach, using fixed frames to display content. Use of toolbars, menus and, most of all, frames that are easily expanded or hidden (Figure 8) allows to concentrate on the specific content that the user is currently browsing.

Figure 12: Text (philological introduction) and search frames for the Electronic Junius Text (philological introduction) and search frames for the Electronic Junius

Controls

§ 61    The user will interact with the browsing software by means of a vast assortment of graphic objects: toolbars and the buttons they host, general purpose menus, drop-down menus, sliders, and so on. It is important to handle them carefully:

  • never put too many objects in the foreground;
  • allow easy switching from one object to another (both via keyboard navigation and visual manipulation);
  • allow easy minimize/maximize, hide/recall of objects;
  • allow easy moving to the desired object, e.g. let the user select among all the texts (preferably via drop-down menus); this is known as "principle of constant availability";
  • "ghost" menu choices that aren't available in one mode.

§ 62    A clean, well ordered GUI will make browsing the edition a much easier and more enjoyable activity.

Fitts' law

§ 63    Fitts' law is a model of human psychomotor behavior describing the relationship between movement time, distance and target in the context of quick and aimed movement. Fitt's law is actually a mathematical formula: MT = a + b log2(2A/W). A convenient translation of this might be "The time to acquire a target is a function of the distance to and size of the target" (see Tognazzini 2003; also Tognazzini 1999).

§ 64    This principle is particularly relevant with regard to the user-friendliness and effectiveness of a GUI: if the user is forced to use small, difficult to locate GUI objects, the time necessary to interact with them will be much greater. As a consequence, the learning curve of any application will be steeper, and its use might be perceived as more "difficult", or even downright frustrating, by the user. Applications with a well thought-out GUI, on the other hand, designed keeping in mind Fitts' law and its implications, will greatly improve the user's experience.

§ 65    The consequences of Fitts' law might not be immediately evident to the user, but they will be experienced nonetheless. Consider, for instance, the difference between the menu bar in MacOS and other common OSs: in the former case you can move the mouse cursor to the upper screen limit and then choose on the desired menu item; in the latter one you have to carefully aim towards the desired menu item because the menu bar is part of the window; to quote B. Tognazzini: "Fitts' law [...] dictates that the Macintosh pull-down menu acquisition should be approximately five times faster than Windows menu acquisition, and this is proven out." (Tognazzini 2003). In other words, the pinning action of the MacOS menu bar makes it much easier and faster to choose from an application menu, even if the mouse pointer has to cover more space than in other OSes.

§ 66    Some features of a GUI designed with attention to Fitt's law include:

  • buttons, and possibly other GUI objects such as drop-down menus, are grouped in toolbars and not placed alone in random areas of the application window: besides being a clear sign of bad design, isolated buttons are also a more difficult target for the user;
  • toolbars are located on the screen edges to take advantage of their "pinning effect", so that buttons are reached easily and quickly;
  • the most important buttons are located at the screen corners, again to make the most of these important points on the screen
  • the GUI offers context sensitive menus, activated via a right mouse click, each containing a limited number of items: a right click in a medium to large area of the screen allows to reach the desired functionality in a very short time, especially if the developer simplifies navigation not including too many items in the menu; the only disadvantage being its reduced discoverability, as context menus are invisible until recalled and as a consequence they are far less discoverable than all other GUI objects;
  • collapsible panels/frames are located on the screen edges and recalled/hidden with a simple mouse click.

§ 67    As I hinted above, these features are very hard to implement in an application that doesn't operate in full-screen mode, since any application operating as a window on the desktop will have no screen edges: toolbar buttons, menus and other GUI objects will have to be carefully located and activated by the user, slowing down interaction with all related functionalities.

Philological issues

§ 68    As stated above, DE software may share features with other, more general purpose applications, but it has some peculiarities with regard to what features are needed and how they're used to display the edition material. I will briefly hint at two issues that would deserve an article of their own to be explored in full.

Critical apparatus

§ 69    In many of the DEs I've browsed for the purpose of writing the present article the critical apparatus is inserted in a fixed text frame placed below (or on the side of) the edition text; this is particularly frequent in web-based editions, e.g. Beowulf on Steorarume by B. Slade (http://www.heorot.dk/); other online editions omit the critical apparatus altogether, e.g. Beowulf in Hypertext by A. Savage, (http://www.humanities.mcmaster.ca/~beowulf/), while some of the oldest ones are little more than digital facsimiles of printed editions, e.g. The Wanderer e-Edition and translation by T. Romano (<http://www.aimsdata.com/tim/anhaga/edition.htm>). While this choice is effective in presenting this essential component of any critical edition, it is actually extremely conservative, being nothing more than a faithful replica of the printed edition layout. Mimicking an editorial form largely shaped up by physical considerations means giving up the flexibility and possibilities that a digital, non-material edition offers to the scholar: it is not necessary, for instance, to impose a limit to the number of variants reported, and it is likewise possible to propose links to the the respective texts holding them, to view them in context. A minimal solution to take advantage of this flexibility could be using collapsible, or otherwise visible on demand, frames/panels where the apparatus, but also editorial comments, notes, and so on, could be shown when needed and if so desired by the user. An effective solution to this specific issue, considering both the amount and diversity of texts that might be part of the edition, and the limits of an UI that is still limited by a two-dimensional space, will require more research and experimenting.

Text-image linking

§ 70    In some image-based digital editions (such as the Electronic Junius by B.J. Muir), the manuscript images and the relative texts aren't simply juxtaposed, but they are linked in some way, so that, for instance, a mouse click on a line in the edition's text will result in a highlighting of the corresponding line in the manuscript image. This is another area which would benefit from more theoretical work, because it has deep implications with regard to the navigation of the DE. One specific problem, for example, involves synchronising displays: when the layout is based on two frames to display both text and image, usually the user can browse the edition text and the images in an independent manner, moving back and forward on one of the frames; this is problematic because it disrupts the navigation state for the user, who has no way to tell if the currently displayed image corresponds to the currently displayed text: it would be better to link image and text so that one follows the other when browsing, and vice versa (see Rosselli Del Turco 2009).

Prototype and test

§ 71    All of the above is of little use if the software to be developed lives in a vacuum until its final release. The open source software saying "release early, release often" might be paraphrased as "prototype early, evaluate often" for our purposes: only by experimenting since the early stages with the design of an application UI, and proposing it to users and/or experts for evaluation, the developers will be able to implement it correctly and avoid to incur in typical UI mistakes.

§ 72    A first attempt at prototyping, often called "soft" (or "low-fi") prototyping, can be as simple as sketching the application UI on paper, drawing the GUI objects defined in the UI design phase and estimating their effectiveness. "Hard" (or "hi-fi") prototyping, on the other hand, is accomplished creating UI mockups by means of GUI design software integrated in development frameworks such as the GUI builders available for the Eclipse framework or the GLADE tools under Linux, but there are also software tools created for this specific purpose, such as Silverback Spontaneous, which is described by its makers as an "unobtrusive usability testing software for designers and developers" (http://silverbackapp.com/).

§ 73    

Figure 13: Prototyping and testing: The UI design cycle Prototyping and testing: The UI design cycle

UI evaluation will be most likely internal to the project, unless GUI mockups are proposed to a sample of volunteering testers, until the first beta version of the software will permit direct user testing.

Conclusion, and a look at the future

§ 74    So far, my excursus on the importance of the GUI design for DE software has been mostly technology-agnostic, as I refrained from considering the two different methods to implement such software: as browser-based or stand-alone applications. It is important to understand, though, that this early choice implies non negligible consequences on the UI working and on the final appearance for the browsing software.

§ 75    There is little doubt that the traditional browser GUI is ineffective if the editor plans to add rich functionalities to the DE: it will be necessary to make use of supplementary technologies to add the desired functionalities; also, more sophisticated functionalities will require equally sophisticated programming tools and technologies to be implemented.

§ 76    On the other hand, using an Internet browser as the starting point to build a DE application presents several advantages, as noticed in § 2.2, to which we might add the following:

  • to guarantee compatibility between different browsers on different OSs both the edition data (HTML, XML) and the programming framework (CSS, XSLT; Javascript, Java) must be based on open standards, which is a solid foundation and a safeguard with regards to the durability and maintainability of such software (see O'Donnell 2004);
  • a browser-based DE software is suitable not only to work as a stand-alone application, but also as a web-distributed one: this factor can't be underestimated because web publication is the most effective mean to reach the wide public, and also because there is a distinct movement towards web-applications such as Google mail, Google Office, Windows Live and similar software and away from (certain) desktop applications.

§ 77    Stand-alone software presents its own advantages: it allows the developer greater flexibility in designing the GUI, and more power in implementing functionalities. It will also be possible to fully take advantage of Fitts' law in case the application will work in full-screen or has a full-screen mode of operation. To produce a multi-platform software, however, it will be necessary to use an interpreted, "write once, run everywhere" language such as Java, or adopting a cross-platform framework like Eclipse (which is itself written in Java).

§ 78    Whichever the technical path that will be chosen, we also have to consider the intrinsic limitations of the physical device that will be used to display the DE precious content: a computer monitor. While LCD monitors, currently going up in sizes and coming down in price, have dramatically improved the readability and usability of text on the screen, in the recent past applications conceived for brief interaction, like CD-based or on-line dictionaries, have surely enjoyed more popularity than Digital Editions. A computer monitor still is a sub-optimal device for prolonged reading purposes, although it's more than suitable for consultation ones.

§ 79    Fortunately, technology constantly evolves and several products already available on the market, plus others presented as experimental prototypes, let us have a glimpse of what the future holds for DE editors: a portable device, most likely based on innovative technology such as e-ink [5] and a TUI (Touch User Interface), [6] light enough to compete with printed editions, flexible enough to fulfill the promise of true hyper-textual, image-based Digital Editions. The TUI concept, in particular, will bring significant changes to the user-computing device interaction model, changes that will imply a substantial evolution, or possibly even the abandonment, of the familiar WIMP (Windows, Icons, Menus and Pointing device) paradigm. The desktop metaphor that has been the cornerstone of the current OSs' GUI has already shown its limits when applied to devices smaller than a full-blown computer (desktop or laptop): ebook readers, smartphones, tablet computers. The traditional GUI doesn't work well on these devices: traditional scrollbars are too small to drag using your fingers or even a stylus, which means that it is necessary to design a new interface specifically tailored on smaller screen sizes and/or TUI principles: given the success of even the earliest versions of these devices, it seems very likely that in the future we'll be touching and moving things around instead of clicking and dragging even on traditional desktop and laptop computers. As ebook readers and tablet computing will gain in popularity during the next 5-10 years it will be essential to follow the development of the TUI to adjust DEs for these devices.

§ 80    It is important, in conclusion, that discussion on the optimal GUI for DE browsing software continues so that there will be a theoretic model ready for those who will try to implement it on such devices.

Notes:

[1] Usability is closely linked to accessibility; on the subject of accessibility in DEs see Wymer 2005.

[2] Currently hypertext and hypermedia are struggling with unresolved technical and implementation issues such as the fabled one to many linking (see Landow 1997: 11), with serious usability issues (mainly disorientation, the getting lost in the virtual hypertextual space, and cognitive overhead, the conscious effort to keep track of links already followed and to decide which new links to explore) and the challenges of integration in the Semantic Web infrastructures (see Ossenbruggen et al. 2002).

[3] A solution to the obsolescence problem for DEs designed using custom software - an abstraction layer that would effectively shield the DE from the actual hardware and OS on which it runs - is outside the scope of this article. For an example of this approach, see the Edition Production and Presentation Tool (<http://beowulf.engl.uky.edu/eppt/>), developed by Kevin S. Kiernan.

[5] See <http://en.wikipedia.org/wiki/E-ink> for a short explanation.

Works cited

Clearleft. Silverback 2.0 <http://silverbackapp.com/> (accessed September 2011).

Foys, Martin K. 2003. The Bayeux Tapestry: Digital edition [CD-ROM]. Leicester: SDE.

Hockey, Susan. 1997. "Electronic texts: The promise and the reality." ACLS Newsletter 4.4.

Hockey, Susan. 2000. Electronic texts in the humanities. Oxford: Oxford UP.

Isys Information Architects Inc. [2011a]. Interface hall of shame <http://homepage.mac.com/bradster/iarchitect/shame.htm> (accessed on September 2011).

Isys Information Architects Inc. [2011b]. Interface hall of fame <http://homepage.mac.com/bradster/iarchitect/fame.htm> (accessed on September 2011).

Jacobson, Ivar, et al. 1992. Object-Oriented software engineering: A use-case driven approach. Reading, MA: Addison-Wesley.

Karlsson, Lina & Linda Malm. 2004. "Revolution or remediation? A study of electronic scholarly editions on the web." HumanIT 7.1: 1–46. <http://www.hb.se/bhs/ith/1-7/lklm.pdf> (accessed on November 2008).

Kiernan, Kevin S. [2011a]. Edition Production & Presentation Technology (EPPT) <http://beowulf.engl.uky.edu/eppt/> (accessed on September 2011).

Kiernan, Kevin S. 2011b. Electronic Beowulf [CD-ROM]. Third edition. London: British Library.

Landow, George P. 1997. Hypertext 2.0: The convergence of contemporary critical theory and technology. Baltimore: Johns Hopkins University Press.

Lavagnino, John 1995. "Reading, scholarship, and hypertext editions." TEXT: Transactions of the Society for Textual Scholarship 8: 109-124. <http://www.stg.brown.edu/resources/stg/monographs/rshe.html> (accessed on November 2008).

McGann, Jerome J. 1997. "The Rationale of Hypertext." Electronic text: Investigations in method and theory. Ed. Kathryn Sutherland. Oxford: Clarendon Press. 19-46.

Modern Language Association: Committee on Scholarly Editions. 1997. Guidelines for electronic scholarly editions. Berkeley: University of California. <http://sunsite.berkeley.edu/MLA/guidelines.html> (accessed on November 2008).

Molich, R., and Nielsen, J. 1990. "Improving a human-computer dialogue." Communications of the ACM 33, 3 (March), 338-348.

Muir, Bernard James. 2004a. The Exeter anthology of Old English poetry: An edition of Exeter Dean and Chapter MS 3501 [CD-ROM]. Revised second edition. Exeter: Exeter University Press.

Muir, Bernard James. 2004b. A digital facsimile of Oxford, Bodleian Library MS. Junius 11. Software by Nick Kennedy. Bodleian Library Digital Texts 1. Oxford: Bodleian Library.

Nelson, T. H. 1965. "Complex information processing: a file structure for the complex, the changing and the indeterminate". In Proceedings of the 1965 20th National Conference (Cleveland, Ohio, United States, August 24 - 26): 84-100.

Nelson, T. H. 1992. Literary machines: The report on, and of, Project Xanadu concerning word processing, electronic publishing, hypertext, thinkertoys, tomorrow's intellectual revolution, and certain other topics including knowledge, education and freedom. Sausalito: Mindful.

Nielsen, J., and Molich, R. 1990. "Heuristic evaluation of user interfaces." Proceedings of the ACM CHI'90 Conference (Seattle, WA, 1-5 April): 249-256.

Nielsen, J. 1994a. "Enhancing the explanatory power of usability heuristics." Proceedings of the ACM CHI'94 Conference (Boston, MA, April 24-28), 152-158.

Nielsen, J. 1994b. "Heuristic evaluation." In Nielsen, J., and Mack, R.L. (eds.), Usability inspection methods, New York, NY: John Wiley & Sons.

Nielsen, J. 2008. Usability heuristics. Useit.com <http://www.useit.com/papers/heuristic/heuristic_list.html> (accessed on November 2008).

O'Donnell, Daniel Paul. 2004. "The Doomsday Machine, or, 'If you build it, will they still come ten years from now?': What Medievalists working in digital media can do to ensure the longevity of their research." Heroic Age 7. <http://www.mun.ca/mst/heroicage/issues/7/ecolumn.html> (accessed on November 2008).

O'Donnell, Daniel Paul. 2005a. Cædmon's Hymn : A multimedia study, archive and edition. Society for early English and Norse electronic texts A.7. Cambridge and Rochester: D.S. Brewer in association with SEENET and the Medieval Academy.

O'Donnell, Daniel Paul. 2005b. "O Captain! My Captain! Using technology to guide readers through an electronic edition." Heroic Age 8. <http://www.mun.ca/mst/heroicage/issues/8/em.html> (accessed on November 2008).

O'Donnell, Daniel Paul. 2007. "Disciplinary impact and technological obsolescence in digital medieval studies". In A companion to digital literary studies. Ed. Susan Schreibman and Ray Siemens. Oxford: Blackwell. 65-81. <http://www.digitalhumanities.org/companion/view?docId=blackwell/9781405148641/9781405148641.xml&chunk.id=ss1-4-2> (accessed on November 2008).

Ossenbruggen, Jacco van, L. Hardman, and Lloyd Rutledge. 2002. "Hypermedia and the Semantic Web: A research agenda." Journal of Digital Information, Vol 3, No 1. <http://journals.tdl.org/jodi/article/viewArticle/78/77> (accessed on November 2008).

Robinson, Peter and N. F. Blake. 1996. The Wife of Bath's Prologue on CD-ROM. Canterbury Tales Project. Cambridge: Cambridge University Press.

Robinson, Peter. 2005. "Current issues in making digital editions of medieval texts, or, Do electronic scholarly editions have a future?" Digital Medievalist 1.1. <http://www.digitalmedievalist.org/article.cfm?RecID=6> (accessed on November 2008).

Romano, Tim. 1999. The Wanderer: Edition and translation. <http://www.aimsdata.com/tim/anhaga/edition.htm> (accessed on September 2011).

Rosselli Del Turco, Roberto.2009. 'Il progetto Vercelli Book Digitale: codifica e visualizzazione di un'edizione diplomatica grazie alle norme TEI P5.' In Medieval texts - contemporary media: The art and science of editing in the digital age. Como – Pavia: Ibis. 131-152.

Savage, Anne, ed. Beowulf in hypertext. <http://www.humanities.mcmaster.ca/~beowulf/> (accessed on September 2011).

Shneiderman, Ben. 1997. "Designing the user interface: Strategies for effective human-computer interaction." Reading, MA: Addison Wesley.

Siemens, Ray G. 1998. "Disparate structures, electronic and otherwise: Conceptions of textual organisation in the electronic medium, with reference to electronic editions of Shakespeare and the internet." Early Modern Literary Studies 3.3 / Special Issue 2. <http://purl.oclc.org/emls/03-3/siemshak.html> (accessed on November 2008).

Slade, Benjamin. ed. Beowulf on steorarume (Beowulf in cyberspace) <http://www.heorot.dk/> (accessed on September 2011).

Solopova, Elizabeth. 2000. The general prologue on CD-ROM. Cambridge: Cambridge University Press

Spolsky, Joel. 2001. User interface design for programmers. Berkeley: Apress.

Spolsky, Joel. 2006. Choices = headaches. <http://www.joelonsoftware.com/items/2006/11/21.html> (accessed on November 2008).

Stolz, Michael. 2003. Die St. Galler Epenhandschrift: Parzival, Nibelungenlied und Klage, Karl, Willehalm. Faksimile des Codex 857 der Stiftsbibliothek St. Gallen und zugehöriger Fragmente. CD-ROM mit einem Begleitheft. Hg. von der Stiftsbibliothek St. Gallen und dem Basler Parzival-Projekt (Codices Electronici Sangallenses 1).

Time-Life Inc. 1983. "Machine of the year: The computer." Time. January 3.

Tognazzini, Bruce. 1999. A quiz designed to give you fitts. Asktog.com. <http://www.asktog.com/columns/022DesignedToGiveFitts.html> (accessed on November 2008).

Tognazzini, Bruce. 2003. First principles of interaction design. Asktog.com. <http://www.asktog.com/basics/firstPrinciples.html> (accessed on November 2008).

White, Ryan W. and Ian Ruthven. 2006. "A study of interface support mechanisms for interactive information retrieval." Journal of the American Society for Information Science and Technology (JASIST) 57.7: 933-948. <http://www3.interscience.wiley.com/journal/112506315/abstract?CRETRY=1&SRETRY=0> (accessed on November 2008).

Wymer, Kathryn. 2005. "Why universal accessibility should matter to the digital medievalist." Digital Medievalist 1.1. <http://www.digitalmedievalist.org/article.cfm?RecID=7> (accessed on November 2008).