Visual Interface Design for Digital Cultural Heritage

A Guide to Rich-Prospect Browsing

Stan Ruecker, Milena Radzikowska, Stefan Sinclair, MIlena Radzikowska

• Publisher: Routledge
• Year: 2016
• Print ISBN:
  9781409404224
• eBook ISBN:
  9781317001201
• Topic: Languages & Linguistics
• Subtopic: World History
• Index: Languages & Linguistics

Browsing for information is a significant part of most research activity, but many online collections hamper browsing with interfaces that are variants on a search box. Research shows that rich-prospect interfaces can offer an intuitive and highly flexible alternative environment for information browsing, assisting hypothesis formation and pattern-finding. This unique book offers a clear discussion of this form of interface design, including a theoretical basis for why it is important, and examples of how it can be done. It will be of interest to those working in the fields of library and information science, human-computer interaction, visual communication design, and the digital humanities as well as those interested in new theories and practices for designing web interfaces for library collections, digitized cultural heritage materials, and other types of digital collections.

Chapter 1
Introduction to Rich-Prospect Interfaces

In the early stages of a new technology, people tend to think that its purpose is merely to replace and improve on something they already know. The promise of the new is thought to be quantitative: the new thing will do the old job faster, more efficiently, and more cheaply. Tools, however, are perceptual agents. A new tool is not just a bigger lever and a more secure fulcrum, rather a new way of conceptualising the world.

(McCarty 1991)

In this book, we discuss our efforts, as designers, programmers, and scholars in the humanities, to explore some theories we have about how we can improve people’s experience in working with digital collections and documents. As authors, we represent collectively a variety of educational backgrounds and research experiences in visual communication design, literary studies, digital humanities, and computer science, and we routinely work with others who bring deeper skills in these areas as well as complementary skills in other areas. We believe that the approach that we take and the results we achieve benefit from our multidisciplinary perspectives and that our work will be relevant to colleagues working in several fields.

Our strategy has been to create prototypes that reify (and refine) our theories, in consultation with the intended users of the tools. The task is complex and open-ended, since the theories could be instantiated for testing in a variety of ways. Morever, the responses of users trying out the systems are influenced by any number of factors that may or may not derive directly from the tools. There are also diverse opinions about the best ways to consult people, ranging from controlled psychometric experiments in labs, which produce comparative statistics, to thinkaloud protocols and screen captures, which provide potentially richer qualitative data about fewer people, to in situ observational studies or documentary reports of people living with new technologies in their homes and workplaces.

Different research communities also espouse different standards with respect to appropriate numbers and kinds of participants, the nature of the introductory information participants receive, and the types of tasks or questions that yield the most useful results. From our perspective, we think it is important to recognise that we are primarily interested in formative rather than summative studies, meaning that we hope to learn what we can, then move on to the next iteration of a prototype or to the next project (this is in contrast to other objectives, such as understanding a user community or conducting an in-depth study of a production-level tool). We are also working with digital artifacts that are amenable to our revision. Although large summative studies performed under carefully controlled conditions remain the primary interest of many publication venues, we believe that the core work consists of reifying a theory by creating an object that can be studied and revised, and in order to do that, a series of small studies is often more than sufficient. As David Sless (2004) has said, if you are someone who has built a staircase and are interested in finding out if any of the stairs creak, how many participants do you need to walk up the stairs?

In total, we have produced well over two dozen experimental prototypes, for nearly that many different communities of people and kinds of data, and we have used a wide range of existing methods for finding out if we are actually improving people’s experience in working with digital materials. Links to many of these prototypes can be found at the following URLS:

• humviz.org

• monkproject.org

• inke.org

• voyeurtools.org

Where it seemed appropriate or necessary, we have also worked on developing new research methods for studying prototype digital humanities tools (Chapter 3).

Our starting point – some 10 years ago – was the idea that retrieval systems, or search engines, are often provided to users when dedicated browsing technologies would be more congenial for the user. From a tool provider perspective, this is not surprising since search interfaces (such as the Google single box model) tend to be much easier and faster to design and develop than meaningful browsing interfaces. The danger is that the user may not realise that a more nuanced way of exploring a dataset is possible and that the dataset remains needlessly mysterious.

For people who are looking for a well-defined target document, search interfaces, based on more or less sophisticated retrieval engines, are a good solution. However, users looking for an understanding of an entire collection and how the various components comprising it interact are not well served by retrieval interfaces. The limitations of a retrieval interface become even more apparent when potentially useful information is available in the relationships between items – how they group, for instance, or whether they are sequenced in some particular way, or if they happen to be a component in some more complicated structure such as a tree or a pattern of relationships. Often this information is stored in ways that are invisible to the user, being contained, for example, in structural and semantic markup, links and anchors, relational fields, and other forms of metadata.

Valuable research has already been done to expand the range of tools and perceptual advantages available to people accessing electronic materials. The literature is impressive and constantly growing, with thousands of papers published annually by scholars at research centers like MIT, UIUC, IBM, HCIL Maryland, Carnegie Mellon, and elsewhere. We owe a tremendous intellectual debt to colleagues in the areas of human-computer interaction, visual communication design, user experience studies, library and information studies, and digital humanities. We have attempted to recognise some of that important work in this book where appropriate, without attempting to exhaustively contextualise the relevant fields. Our perspective here is what we call experimental prototype design where we try to allow the design and HCI literature (among others) to inform the process of iteratively developing prototypes (we don’t share the same priorities as, say, developers of a widely used online store). In any case, more work remains to be done in the area of tool development in the digital humanities, especially as the number and sophistication of research projects continue to increase.

One of our fundamental beliefs is that providing the user with a wealth of well-designed visual information is better than attempting to artificially or arbitrarily restrict the amount of information provided, especially if certain features of the visual display can be easily controlled by the person using the system (and if those controls presented in an intuitive way). We have been trying to understand the conditions under which this approach is generally useful, but within localised contexts, given the necessity of working with specific people undertaking particular kinds of work with a given type of digital materials. We have also tried to learn which features of the visual display are most important to put under user control. Finally, we have been attempting to expand the range of forms that control can take.

Rich-Prospect Browsing

In many of our experimental interfaces, the home page displays a visual representation of every item in a given collection, combined with tools for manipulating the display. We call these kinds of interfaces “rich-prospect browsers,” using a term first suggested in conversation by the designer Jorge Frascara (1999). Rich-prospect browsers embody the following list of principles:

• The primary page or screen should show a meaningful representation of every item in the collection (these might consist of photos, graphical objects, or pieces of text; however, for brevity, rather than saying “meaningful representation of every item in the collection,” we’ll often opt for the word “image” as shorthand).

• The user should be able to adjust various controls in order to reorganise these images.

• Each item or image should link to more data.

• The available metadata about the images should determine the tools available, so that, for example, metadata that could produce groups should be used for grouping, and metadata about associations should allow the user to see network diagrams.

• Where possible, more than one image should be available, so that the user can choose among alternatives (Ruecker and Liepert 2004).

• The visual organisation of the images should bear meaning that is apparent to the user.

• The user should be able to mark the images somehow, so that it is possible to keep track of images even when they are reorganised in the display (Giacometti et al. 2008).

Rich-prospect browsers have the benefit of providing the user with a visual basis for understanding what is available in a collection. This kind of visual knowledge is particularly suitable for many collections of digital cultural objects, where a meaningful image of each item is readily available, and users may not be aware of everything that is in the collection, making searching more difficult. However, our research timeline does not typically involve the creation or digitisation stage. Although there have been some exceptions, in general, we take as our starting point the existence of a digital collection, which usually includes some metadata.

In attempting to develop our list of principles above, and in the process of assessing the degree to which they are valid, we have created a wide range of prototypes. The flagship group consists of a family of eight or nine rich-prospect showcase browsers, each one of which allows people to browse through a different kind of material. For instance, there is a browser for a collection of biodiversity projects in the city of Edmonton (Figure 1.1), another of researcher profiles at Mount Royal University in Calgary, and a third showcasing some of Edmonton’s historic buildings. As a means of introducing the concept of rich-prospect browsing with reference to some specific details, we will use the biodiversity project browser as an example. Carried out in conjunction with the City of Edmonton and the 2009 conference of the International Council for Local Environmental Initiatives (ICLEI), the biodiversity browser was a means of showcasing approximately 60 environmental projects in the Edmonton city region.

The showcase browsers implement a type of faceted browsing (Spiteri 1998) and each relies on the metadata that are specific to the collection, so that for biodiversity projects, the user can group by any of the following criteria, or by any combination:

• project type

• ecological areas

• status

• project lead

• what groups are involved

• biodiversity threats

• methods

To return briefly to the subject of “images” in rich-prospect browsing, note that it is not necessarily straightforward to represent something as complex as a biodiversity project with a picture or graphical object. Some projects have taken a photo of a representative landscape. Others have chosen to identify themselves with a logotype. Ideally, the representations should be meaningful for the users, but one of our studies (Giacometti et al. 2008) suggests that putting the representation under user control is not as important as it might at first seem. People seem to be able to treat the representations as signifiers for the items they access.

Figure 1.1 Biodiversity stewardship projects of Edmonton¹

Note too that in cases where a project falls into more than one category, the image gets duplicated, since the goal is not to have a set of mutually exclusive categories, but rather, to allow the user to see within each category what projects are included (obviously, the less duplication of images possible, the better). Returning to the ungrouped display removes the duplicates, which only appear when necessary to display a particular grouping.

Using the Biodiversity browser, people with no knowledge of the projects being done in Edmonton can quickly get a sense of their range and scope. They can recognise with a few button clicks what groups are involved in supporting the projects, what kinds of biodiversity threats are being confronted, and who is leading the work. They can see at the push of one button, and without leaving the screen, the relative proportion of projects within each category. Furthermore, they can begin to understand (or at least speculate) how the people who created the metadata for the collection construed the material. For example, in terms of biodiversity threats, the largest group of projects in Edmonton deal with habitat destruction, fragmentation, and degradation – a category that sits alongside climate change, extirpation, and invasive species. A person examining the topic of biodiversity stewardship for the first time would not necessarily guess that these were the kinds of threats that would be listed, or that these were the terms used.

In general, any prospect-based interface should address three fundamental questions for the user; these questions relate to the affordances of the interface and the tools that are provided with it:

• What am I looking at? (Chapter 4: meaningful representation)

• Why would I want to look at it? (Chapter 3: the study of new affordances)

• What can I do with it? (Chapter 2: affordances of prospect)

Research Life Cycle

Our approach to research involves a life cycle that is not necessarily unique, but because it is a product of our interdisciplinary approach and the realities of our funding structures, it might be worth pointing out explicitly. In general terms, we have a design phase, a prototype phase, and a production phase. We try to carry out user studies in all three phases. We try to publish or present results in all three phases. Each phase typically requires a minimum of a year, although with many of the prototypes we have been iteratively progressing for two or three times that long (in some cases there’s a renewal of the life cycle with what is partly a continuation of an existing project and partly a new endeavour).

The process often begins with some aspect of what in the business community is called a SWOT analysis: Strengths, Weaknesses, Opportunities, and Threats (Freisner 2010). Given any of these four aspects of a situation, we look at a given area of interest to one of the potential team members. This might be in the form of a domain interest or a research problem. For example, we started looking at visualisations for decision support systems when some of our colleagues in engineering approached us with a series of problems they had been addressing related to making and coordinating decisions in a multi-modal environment. Alternatively, the starting point might be derived from observing an existing trajectory in interface design and thinking of its limitations. An example here is our work on a new kind of timeline that can support multiple conflicting witnesses as well as the concept of subjectivity. It is not unusual for other researchers to be following a similar trajectory, so that for the timeline project, we were able to work with Johanna Drucker and Bethany Nowviskie, whose earlier temporal modeling project produced a wealth of theoretical and practical groundwork.

The real start to the project is a planning meeting where we familiarise ourselves as a team (we often have new collaborators, such as colleagues, clients, or research assistants), we revisit the overall objectives of the project (often described in a grant proposal that led to funding for the project), and we set out tentative timelines and collaborative practices (project governance, modes of communication, and so on).

The next step is often an environmental scan (Albright 2004) and a literature review. An environmental scan proceeds by collecting examples from the internet, combining a series of searches with further investigation of the backlog of visualisation and interface examples sent over time by colleagues. The result is both a subset of selected examples and a report that describes the range. Since not all of the important design innovation is associated with the academic literature, an environmental scan helps us to spot relevant work being done outside the academy. Interestingly, existing environmental scans tend to be easier to find for non-academic projects since academics are not always in the habit of making their preparatory research publicly available. Having realised this more recently, we have become more diligent in making available the full trace of our research work, most often published through a wiki or ticket-tracking system (such as TRAC).

Associated with this activity, we sometimes include the development of personas and scenarios (Cooper 1998). A persona is a written description of a potential user, highlighting specific attributes such as experience and reasons for wanting to use the system. Normally, three or more personas will be necessary, in order to cover a sufficient range of potential users. However, it is important not to multiply personas to the point that they are difficult to remember and use in discussion. It is also a good rule of thumb to avoid giving them comic names, which is often an initial impulse but can tend to become distracting over time.

A scenario, sometimes also referred to as a use case, describes a circumstance of use, typically written as a set of steps that form an outline of the task. The level of detail should be sufficient to include all steps, but not so specific as to constrain the implementation of each step. For example, a typical scenario might begin with “step 1: John opens a file” rather than “step 1: John goes to the File menu and chooses Open.” The former version allows any number of mechanisms for opening files, including double-clicking a data file, pushing a button, or choosing a menu option, while the latter version assumes files will be opened only from a file menu within a running application.

The design phase itself usually involves a dozen or more iterations. The politics of design, programming, users, and domain experts become central at this time, as each contributor brings her own background and practices. For example, the domain experts may feel that some particular aspect of the information should be emphasised, while the users express their primary interest in something else. The designers may suggest an approach that the programmers feel will be unnecessarily difficult to implement, while the programmers may have design ideas of their own that seem to the designers to be visually uninspiring. No one agrees on where the bar should be set for ease of use. We negotiate that terrain and end up with a set of sketches. These might be static drawings or sequences of sketches to suggest how the interaction works, or they might be interactive animations with no real data on the back end. We believe that the importance of the design phase cannot be overstated. The involvement of visual communication designers on the research team results in a completely different kind of prototype than would be possible with computer programmers working without designers (we have made it a sine qua non of our projects to integrate a design perspective). No matter how immersed in visual culture the programmers might be, the designers are specialists in visual culture, and the results they are capable of producing through that specialisation show a significant attention to detail that is not otherwise possible (similarly, there are technical aspects that may not be fully understood by the designers). There are innumerable difficulties, however, in finding and training appropriate designers, since they need to learn how to work with computer programmers so that the interaction is positive, fruitful and efficient. Similarly, the programmers need to be open to the idea that design is valuable, time-consuming, and difficult. This awareness can be difficult to establish, since programming education often ignores design entirely, or worse yet, gives it a cursory treatment.

Following (or in delayed lockstep to) the design phase is a programming phase, where a prototype using actual data is created. The goal of the prototype is to allow a more interactive user study, where people can use a working (if preliminary) system. At this point, there are often trade-offs around what components get built, and it is important to keep the dominant project objectives in mind. A prototype is not a production system, so it may actually be missi...

Table of contents

• Cover Page
• Dedication
• Title Page
• Copyright Page
• Contents
• List of Figures
• 1 Introduction to Rich-Prospect Interfaces
• 2 I See What I Can Do: Affordances of Prospect
• 3 Is This Thing Working? The Study of New Affordances
• 4 I Never Forget a Face: Meaningful and Useful Representation of Items
• 5 Textual Markup for Digital Collections
• 6 The Design of New Interface Tools
• 7 Conclusions
• References
• Index