Informed choices

In order to follow the principle of improving the quality of eventual data collected, it is also important that the user is able to make informed choices when specifying the descriptive data requirements for the project. The specialisation interface thus must support the making of informed choices by insuring the user is aware of the nature of the data elements they are working with and their relationships to each other. This criterion includes ensuring the visibility of system status, effective feedback and access to definitions.

6.5.3.1 Visibility of System Status

Usability literature commonly cites the visibility of system status as a key usability heuristic [Nielsen 1994, Tognazzini 2003, Norman 1988]. Keeping users informed about the the current status of the edited specialised domain model, is equally a key enabler for users to make informed decisions.

One of the uses of the description object hierarchy tree (see figure 6.1A) is as an overview visualisation of the system status that is always visible. It is a view of the state of the specialised domain model, showing which description objects are included in the model, whether they have any descriptive attributes specified and which of them is currently selected.

The linked visualisation of the attribute-value tree of the selected description object (figure 6.1B) provides a visible status of the selected description object’s attributes. This is visible whilst that description object is being worked upon. Although this element of system status is only visible when the relevant description object is

selected, this is usually the time when such detail is required. At other times, the description object node icon summary information of whether any attributes are specialised for a description object is sufficient for system status.

System status also needs to be up to date to have best impact on usability [Nielsen 1993, Tognazzini 2003], ensuring users are informed to make their decisions. The description object hierarchy tree (as well as all other elements of the interface) reflects the current status of the specialised domain model, matching this requirement.

Observation of users during the user tests, combined with speak-aloud feedback and post-test interview feedback showed users generally believed they knew the state of the specialised domain model and where they were working within it. Users also demonstrated an understanding of the node summary information, particularly commenting upon the distinctiveness of greyed-out elements and noticing that they had failed to add a viable value domain for an attribute they had included (based on red warning text/icon).

Visibility of the entire system status was however not always complete. When fully expanded, the overview scrolled off the screen, hiding elements of the model. Elements of the tree could also be occluded because they were contracted. In practice however this made little difference to users, as they only required to have a view on the detail of the immediate area of the description object hierarchy around which they were currently working. As the groups of description objects that users worked in matched well with the organising hierarchy structure (as observed during narrow user tests, when users were able to select their own working pattern), they did not usually require to view at a glance the details of the status of the remaining elements of the model. Their domain knowledge was sufficient to provide them with a wider context for these description objects. While a case for focussing techniques such as fisheyes [Furnas 1986] could be made here to improve the view of the immediate area whilst maintaining a wider context, and briefly tested in early storyboards, however they were not pursued in prototype development as the simpler to implement filter method of tree expansion/contraction was found to be sufficient to maintain a user’s awareness of description object space, particularly the important sibling, parent and child nodes.

This issue emphasises the importance of the primary organising relationship and the size of the ontology’s description object hierarchy. In the angiosperm ontology, the relationship’s match with working practice is good and consequently the occlusion of elements of the description object hierarchy is not a serious issue.

6.5.3.2 Description space awareness

As well as providing a general overview of the specialised domain model status, the description object hierarchy tree has a related system status visibility role in providing users with awareness of their location within the description space. Other cues are given in the attribute-value tree and in the various panel headings.

It was observed during observation of the 4th phase wide user test, that some users (with less domain experience) were very occasionally becoming confused as to which description object they were working with. This was noticed particularly where there were other description objects using the same basic defined term nearby in the description object hierarchy. These users were not observing the current description object’s hierarchy context from the tree.

The heading to the attribute-values tree displayed details of the current selected description object node. Initially, these displayed details were kept to the basic nametag data for reasons of clarity and to minimise length. During development however, the heading was expanded to include the full path data of the description object (to show all its parents to the root). To evaluate these alternate headings, a short test with 3 taxonomists was conducted to compare the headings. This test showed an improved awareness with the longer path heading for the users who had shown most difficulty previously and no change, but no complications, for those who had previously shown no difficulty using the hierarchy view as a navigational cue.

6.5.3.3 Reviewing the specialised domain model

Linked to the visibility of system status, is the need for users to be able to review their specialisation decisions. Users need to be able to review their work in detail to see what effect their decisions have had, spot possible errors or omissions and determine what still requires to be done. The task options for reviewing the specialised domain model

are 1. using the specialisation interface views (with filter); 2. previewing the data entry interface; or 3. exporting and viewing an XML file (see table 6.2).

During the final wide user test, users were asked to review the specialised domain model that they had specified using the filtered specialisation views and the XML file. Impressionistically, users were pleased with the filtered view, believing they were readily and effectively able to review their ‘proforma’. Ignoring the effects of different interpretations of the same domain data, users made a small number of errors in their test tasks, mainly of omission. Of those errors that had not been corrected before the user reviewed the specialised domain model at the end of the specialisation process, 50% were picked up in the review with the filtered view (excluding errors due to misinterpretation of the test questions). Error catching is not the only objective of the reviewing task, but does have some indicative role in determining if users could effectively review their work.

Feedback from users, completing the full system task for real data sets of their own, stressed the usefulness of the filtered view for reviewing the content of their work, allowing them to determine relatively quickly and effectively if they had omitted anything of importance. These users were observed on a number of occasions returning to the specialisation process following review, to add or re-edit attributes to the specialised domain model.

Using the XML file, viewing it effectively as a text file in a web browser, users were not convinced they were able to review their work. No errors were discovered using this method in the final wide user test. Users were observed to be intimidated by the amount of detail and the technical format. In order for the file to be useful for this purpose, it would be necessary to improve the view of the XML, possibly through some form of xml transformation using a user-friendly display template. Users did retain a desire to be able to print out their specialised domain model for reviewing and the XML file could form such a basis. One notable contrary indication came from the experiences of an angiosperm ontology developer who was an IT expert as well as an expert biologist. This user used the XML file by preference for reviewing specialised domain models and gave feedback indicating they had no difficulty reading the format. They were not a representative end-user however.

Although users were not specifically asked to review their work by previewing the data entry screens during the final wide test. Users did find the vast majority of any errors they had made during the data entry task for their first specimen. Additionally users that completed the full system tasks did occasionally use the preview to check another view of description objects they were working upon if they had a number of different attributes. As the data entry view concentrated on one description object per page, this effectively acted as a filtered view of the current description object’s attributes and values, showing only those that were included in the specialised domain model.

6.5.3.4 Warning messages feedback

Warning messages are used to inform users of possibly unintended logical consequences to ensure consistency with the ontology. Ideally for usability, the system should ensure the system guides the user with constraints to remove the need for warnings [Nielsen 1993, Schneiderman 1998]. Whilst the system only presents choices to users that are supported by the ontology, removing a descriptive element may have a cascade action on other elements due to the logic of the ontology (see 6.6.1.2). In these cases, warning feedback in the form of confirmation dialog boxes is immediately provided. These messages attempt to explain in clear language the nature of the consequence, using domain specific terms where possible and identifying the descriptive elements involved. Error messages can generally help users understand systems better [Frese 1991] and this could be the case with these warning messages which safely explain consequences that may not be apparent to new or inexperienced users.

The system does not support full undo/redo facilities as usability guidelines would normally suggest [Nielsen 2004, Toganzzini 2003], however the significance of this is offset by the ability of users to undo any unwanted inclusion or removal of descriptive elements by using the same procedure as originally used to do it. During the final wide test, 15% of users looked for such undo facilities. In all cases however users were able to recover from their errors by simply reversing the mistaken inclusion decision.

Even with undo facilities, the need for warning message feedback of possible intended consequences would remain, as users would need to be informed in cases where their editing decisions would have a larger impact on the specialised domain model, than

was perhaps readily apparent in the immediate area of the description space in which they were working. There is however no reason in theory why undo and redo could not also be incorporated into such a system. It was not implemented during development, as it was a usability issue that never received a level of priority sufficient to justify the effort of implementation, especially considering that few research related insights were likely to be gained in a well known field.

6.5.3.5 Definitions access

A key concept of the approach for improving the comparability and general quality of collected data is the use of descriptive elements based upon defined ontology terms. This however, is not sufficient in itself. The user needs effective access to the definitions to make informed decisions on about the elements they choose to use.

Users were observed to make substantial use of mouse-over definitions during initial exploration of the description object hierarchy tree. This use declined after initial exploration, but users still tended to check the definitions of description objects that they were using, usually via mouse-over. Invoking pop-up full definitions of description objects was rarely witnessed in testing, but the angiosperm ontology did not have multimedia definitions assigned to the description objects, which would reduce the reason to do so.

Users also tended to check mouse-over definitions of value objects of interest, to determine if they matched what is desired. Initial interest was gained from their node text (name) and from association with other sibling value objects of interest. More occasionally, users were observed to use pop-up definition boxes of value objects for comparison or to check multimedia definitions. Most commonly this behaviour was observed in cases where there was multiple similar domain terms (e.g. leaf and petal outline shapes) or where the domain term was open to very variable interpretation (so- called “woolly terms” e.g. textures). When comparing definitions, users were observed to use 2 to 4 definition boxes at a time. Their domain knowledge, along with use of the mouse-over definitions was utilised to determine which elements to compare.

Attribute definitions were not represented in the angiosperm ontology, with their definitions being just their name. Many of these names had no strong domain basis for

them, leading users to be unclear as to what they were. Consequently, users used the value domain of attributes to infer a meaning, which was slow and imprecise. This is a result of the ontology model and will not necessarily hold true in other domains where attribute definition use could be different.

Use of definitions was generally observed to fall with increased familiarity with the ontology. Users with greatest domain experience also demonstrated a very rapid fall off in accessing definitions, particularly description object definitions. This probably represents their improved learning curve for the ontology. These more experienced users (in domain and ontology terms) primarily made use of mouse-over definitions to very rapidly check select descriptive elements, just essentially checking that the definitions were as expected.

Users were generally positive with the access to definitions in the specialisation interface. 77% of final wide test users made positive comments on their access to definitions and their awareness of the definitions. Users were particularly positive about quick mouse-over access to desired definitions.

Alternative facilities for definitions access were considered before and during development. Assigning screen space to an always-visible definition area could in theory increase awareness of the ontology definitions underlying the descriptive elements being used.

To represent full definitions for all three descriptive elements (description object, attribute and value object) being manipulated, would however require a significant investment of limited screen space. Representing only text definitions would reduce screen space requirements, but multiple text definitions would be less readily distinguishable from each other, requiring extra cognitive steps to distinguish between them, thus losing the benefit of having them always visible. Representing only one descriptive element at a time would also reduce screen space requirements, but could cause user confusion over which element was being represented.

Additionally, having a multimedia definition display that was constantly changing as the user navigated the interface could prove to be distracting to users. Finally, a

dedicated fixed screen space might be insufficient to display the multiple definitions required for comparison.

Whilst no full comparison test was attempted, users were asked at a number of stages during development for their views on an always visible definition access, including mock-up interface views for three experienced users. Whilst users’ opinions are generally not infallible with regards to their own needs, these users did not believe they required constant always visible reminders of the definitions during the specialisation stage. This contrasts with their desire for multimedia definitions during data entry as can be seen in chapter 7. It should be noted however that users familiar with the ontology accessed fewer definitions than unfamiliar users.

The use of mouse-over text definitions and user-requested multimedia boxes was thus determined to offer the best match for the needs of the specialisation interface for reasons balancing: limited screen space; task flexibility; and ease of access. User testing showed this approach to satisfactorily support users and their informed decision- making.