Frenzel, Tabea
Beuth Hochschule für Technik, Germany
tabea.frenzel@web.de
Philipp, Luisa
Beuth Hochschule für Technik, Germany
luisa.philipp@beuth-hochschule.de
Kreutel, Jörn
Beuth Hochschule für Technik, Germany
joern.kreutel@beuth-hochschule.de
When users shall be offered web interfaces for manually entering textual data to be persistently stored, form-based graphical interfaces are supposedly the first choice, regardless of the domain of application and the availability of alternative input modalities like voice input. However, depending on the type of task for which data input takes place and depending on the type of data to be input, forms, while basically being able to conform to users’ expectations and being self-descriptive, may yet lack suitability.1 Not only if the data model underlying a form does not match with the user’s mental model, but also in cases where it allows to express by far more than what a user actually wants to express,2 data entry might not be carried out efficiently. Particularly if substantial amounts of data need to be input as part of a user’s everyday activity, the latter issue suggests thinking about alternatives to forms as user interfaces for data entry.
Our contribution will report on an ongoing development of a web-based software platform for collecting and analysing bio-bibliographical data for literary studies on GDR authors,3 and will present findings from the evaluation of a text-based editor that shall support domain experts in gathering data from heterogeneous analogue archival resources, which may be handwritten by multiple authors, typewritten or printed.4 Heterogeneity, however, does not only characterise the form in which data is available but also its content. Information on a person’s employment, e.g., may be as sparse as “ casual work as a trucker and a library assistant” or as rich as “ 1955-1968, dramatic advisor at Deutsches Theater in Berlin, from 1962 chief advisor”. From a form-based perspective, data diversity of this kind hardly allows the assumption of any obligatory input fields apart from an event’s protagonists. Hence, the provision of forms for the different types of biographical events to be collected was seen as a necessary baseline, but not as an optimal solution as it inevitably requires skipping a greater or smaller number of potential input fields by employing mouse movements and clicks or by tab navigation.
As an alternative to forms, the employment of a mere text-based editor, enhanced with supportive features from programming environments like code completion and syntax highlighting, was taken into consideration.5 Such an approach would allow to collect data by just specifying, in an order independent way, the attributes of an entity actually found in the resources as a continuous movement of text generation based on keyboard input only. However, even though the usage of such a tool appeared intuitive and natural to the software engineers within the project team, the actual users of the tool would be domain experts from the field of literary studies without any experience in using such tools, yet a strong affinity to writing texts.
Example of the editor’s syntax highlighting and code completion functionality for the creation of new entities (A), the addition of attributes to an entity (B) and the ad-hoc creation of related entities that serve as attribute values (C).
Starting from the domain experts’ positive feedback on a demonstration of the IntelliJ IDEA programming environment6 and the improvisation, in an ordinary text editor, of how content creation could look like if comparable supportive features were available,7 a simple controlled language for content creation was developed, which allows to describe instances of the platform’s domain model entity classes. It employs natural language keywords and the surface signifiers for classes, attributes and enumeration values that are declared by the model and are known to the domain experts from their usage of the existing form-based interface and their participation in the iterative refinement of the model. Technically, a web application was developed using the JavaScript-based text editor Ace8, which supports the provision of custom components for syntax highlighting and code completion.9 Examples of the editor’s current functionality are shown in the figure above.
A first prototype of the editor was tested qualitatively with two groups of four users each, where the first group was agnostic with respect to both the domain and the context of the platform, and two users had experience in using programming environments. The second group were domain experts that were involved in everyday form-based data collection and, hence, had experience in using the platform and applying its domain model. Each user had to complete six written tasks that consisted in creating entries for biographical events of different types involving various protagonists, places and institutions.
As for the results, both groups took longer to complete the tasks using the text-based editor than with the form-based interface, where the domain experts needed nearly twice as long for text-based vs. form-based task completion but were overall faster for both task sequences than the first group,10 supposedly due to their familiarity with the domain model. This shows, on the one hand, that experience with the domain model and its signifiers can be transferred successfully from the familiar interface paradigm of forms to the new and - due to its “programming style” usage - unfamiliar text editor. On the other hand, in both groups, three out of four persons stated, once being asked after completing the tests, a preference for using the text-based editor in the future. The domain experts mentioned that the possibility of order-independent entry of attributes felt more flexible and less time consuming than the form-based input, which even for them as experienced users sometimes required searching the correct form fields. Particularly for long-term data collection tasks like theirs, that flexibility is seen as a relevant improvement compared to the usage of forms.
Considering an everyday usage of our application, the dimensions of conformity with user expectations and self-descriptiveness, which were mentioned initially and which for novice users cannot be taken for granted, can be assumed to be gradually improvable. Overall, the evaluation results confirm our initial assumption that a text-based editor might provide an improved suitability for the given task. In addition, from the users’ subjective perspective, the text editor’s enablement of a data-driven input process - as opposed to the rather interface-driven process of forms - is experienced as an improvement of the editor’s controllability and, hence, as advantageous with regard to yet another dimension of usability according to (ISO 9241-110 2006).
See (ISO 9241-110 2006) for a definition of these three criteria.
One solution for such cases is, e.g., the distinction between a “basic” and an “advanced” view of a form, where the latter offers additional input fields. The authors of this paper rely on readers’ everyday web usage experience here. See, e.g., Bargas-Avila et al. (2010) for proposals of design guidelines for web forms.
See http://www.ddr-literatur.de for further details. The project is funded by Deutsche Forschungsgemeinschaft (DFG), grant number 419244741. The authors would like to thank their project partners from Humboldt University of Berlin and the Berlin Brandenburg Academy of Sciences and Humanities, who participated in the user tests underlying the work presented here.
Given this usage scenario, which is not atypical for the humanities, here we do not consider the possibility that, generally, many textual input tasks might be supported by automatic processing or preprocessing of textual data.
Following Feinman (2019), we call this a text-based interface. For a comparison of text-based vs. graphical user interfaces in terms of usability see, e.g., Chen / Zhang (2007). See Hempel et al. (2018) for the enhancement of a linear textual representation with GUI style interaction capabilities and advanced menus. However, usage of this editor is situated in a genuine programming context, where programmers shall be supported with intuitive code refactoring capabilities. Particular work from digital humanities focusing on a use case comparable to ours has, to date, not been found by the authors. Closest to the task supported by our tool are studies on the usage of controlled language in the area of ontology authoring and annotation creation, see, e.g., Funk et al. (2007) and Davis et al. (2009), respectively, which address the creation of data or meta data based on a given data model.
In terms of Ries (2011), this demonstration could be seen as one of a minimum viable product, from which we learned that a text-based editor could, principally, be acceptable to our envisaged user group.
These components are automatically generated from the Java representation of the domain model, thus complying with the platform’s iterative development.
The average completion times for the domain experts were 42% (12:59min vs. 30:42min) and 65% (25:13min vs. 38:34min) of the times for the first group, respectively, where the fastest person without domain expertise was about as fast as the slowest domain expert (30:18min vs. 30:28min).