Interface Design: Crafting an Experience

Given the core of the experience needed to focus on discovery, it was decided to in- corporate both a standard keyword search feature (with advanced search options) as well as a visualisation-based search feature. The latter would provide a data visual- isation as its search output (as opposed to table of results which is standard practice for a keyword search). This data visualisation would clearly demonstrate the pat- terns in the data and would also contain an interactive element that would allow the user to click through to an underlying data model for a relevant aspect of the visu- alisation. This would allow the user to effectively create a smaller subset of results that could then be individually read and analysed. Such a system would—at least in theory—support notions of interactive search, furthering immersion in the data and engagement with the source object. It also would act as a facilitator for close reading (as opposed to a replacement), as it would create a narrow set of documents to be read by the user.

In addition to facilitating discovery, the design also sought to address some of the concerns with replicability and access to the underlying data. While wholesale exports of the encoded text and images were not possible given copyright restric- tions, the decision was made to implement a metaphor that would not only further learning and engagement, but also create a reproducible, static object that could be downloaded and re-used. The goal here, then, was to enable a feeling of data relia- bility, as well as to craft an environment for the learner to leverage in an attempt to facilitate the overall learning experience. This goal was accomplished through the use of boundary object12_{and the poster metaphor, the design of which drew inspira-}

tion from Laurillard’s Conversational Framework. By allowing the learner to annotate information and construct her own knowledge of the system, the system is forming the basis for what could be developed into a larger conversational model, allowing the teacher and the learner to communicate learning objectives and outcomes. It was within this larger context that the boundary object design was implemented.

The boundary objects exist in three forms: a keyword search (see Figure4.6), a visualisation search (see Figure4.7), and a page view (see Figure4.8). The user can opt to save any keyword search, visualisation search, or individual page and anno- tate the saved object with their own comments. Relying on a notecard metaphor, the idea here was to create an annotated object, using the user’s own words that could be reliably and repeatedly replicated with complete accuracy. This was accomplished

by storing the exact parameters (in the case of searches), visual configurations (in the case of the visualisation search), or unique identifiers (in the case of page views) along with the text of the annotated object. Each object is tied to a user and can also be referred back to a specific search log entry (in the case of search-related boundary objects) based on the parameters and creation time of the object. Thus this boundary object furthers engagement with the source material by forcing the user to chunk13 information into a smaller subset and provide annotation in their own words for why the boundary object matters. Such a design seeks to offload some of the cogni- tive load of working memory through chunking, as well as providing the user with the space to more deeply engage with the manuscript.

FIGURE4.6: Annotated screen grab highlighting the ability to create a boundary object from a keyword search. A larger version is available

in AppendixEin FigureE.11

4.3. System and UI Design Methodology 115

FIGURE4.7: Annotated screen grab highlighting the ability to create a boundary object from a visualisation search. A larger version is

available in AppendixEinE.12

FIGURE4.8: Annotated screen grab highlighting the ability to create a boundary object from a page view. A larger version is available in

AppendixEin FigureE.13

Initially, there was an included dashboard that highlighted various metrics in the system (such as number of Boundary Objects created, Keyword with the most matches, etc.), as well as other user specific metrics such as recent searches, lists of boundary objects, etc. (early designs of these components can be seen in the wire- frames described in AppendixC). During initial beta testing (which occurred using volunteers from the Computer Science undergraduate programme), many of these metrics were found to be confusing, and the purpose of the dashboard was not clear. Thus much of the dashboard was scrapped in favour of a simplified approach that

allowed users to see all of their created boundary objects and then compile these boundary objects into a poster.

The poster metaphor (originally referred to in the initial designs as a story) sought to offer a compilation mechanism for the boundary objects and create a static, down- loadable object that could be re-used. Drawing on the metaphor of the academic conference poster, the interface provides the user with the ability to describe the overall narrative of the work and then place selected boundary objects which sup- port the narrative into the poster. This poster could then be exported to .png and downloaded so it could be re-used.

Additionally, at any time a user can log into the system and view a dashboard which will display all of their created boundary objects as well as all of their user- generated posters. This functionality allows the user to manage their boundary ob- jects (editing or deleting as needed), as well as their poster objects. Originally, the idea of the dashboard was more sophisticated, allowing the user to track particu- lar aspects of the system they found intriguing (such as most frequent word, or the number of transactions in a given category), allowing the user to build out a top- level custom view into the data. The undertaking proved to be confusing in initial beta tests and was later dropped for simplicity’s sake.

The initial wireframes highlighting each of these items described above can be seen in AppendixC.