Tuesday 31 July 2012

Pelagios WP3 at a glance - Pt.1 widgets and user testing


WP3 tackles end-user engagement: i.e. subject specialists who lack the technical coding expertise to use the data underlying what is seen on the screen. The visualization service has been exploring ways of allowing these users to get to grips with the data both in a single Pelagios interface but also as embedded widgets hosted on each partner’s site. There have been three strands to our work in WP3 namely: (1) evaluation of users needs and requirements; (2) development of widgets; and (3) evaluation of the widgets.  We have been working on these strands through an iterative process, with initial requirements leading to the development of an alpha version of the widgets, which, after being evaluated, in turn led to a refined set of requirements for the final beta version of the widgets.

1. Evaluation of User Needs (a.k.a. deliverable D3.1 in project speak)
In an earlier post we identified three distinct types of users that would have distinct requirements and needs with respect to visualisation widgets:
       "Super users" - e.g. developers, digital humanities specialists typified by the Pelagios2 project partners. This group includes folk who own and/or manage data that the widgets will display;
       "End users" - people with an interest in Pelagios data, but without the technical skills necessary to exploit it. e.g. ancient history students, teachers and researchers, or else the general public with an interest in the ancient world;
       "Web site admins" - people who own and/or administer sites that could embed Pelagios widgets. These could be museum or history related sites, and it's their technical requirements and restrictions that are the initial concern.

Past experience told us that asking end users a general question, like "What could or should visualisation widgets do for you?", are not particularly helpful: far better is to ask specific questions in order to get an idea about the kinds of tasks that end users currently perform, with which widgets may be able to assist. Because super users know the data that is to be visualised, we began by asking super users what they thought visualisation widgets might be good for, and for whom. We also asked them to identify any technical or legal issues they could think of that might restrict or prevent the widgets being used in the way that the person answering the question had imagined. These findings from the super user group were used to develop  a series of questions  for end users to find out what they thought visualisation widgets could be useful for. These responses from 12 end users were then  analysed and, coupled with the knowledge gained from the super users, were used to  inform the development of an alpha version of a Pelagios place widget, i.e a widget for showing the relationships between places and data in ancient history collections (e.g. digitised books, data about ancient artefacts, etc.).


2. Widget Suite, Alpha version (a.k.a. D3.2)
The alpha version of the place widget was evaluated by four end users. Three of the participants tried out the widget in a face-to-face session with the evaluator, while one tried it remotely. In the face-to-face sessions the users were shown a re-versioned Openlearn page, entitled ‘The broader context: Other athletic festivals in Ancient Greece’, and asked to think aloud as they intearcted with the page and the embedded widgets.  A version of the page they interacted with is available, but this version includes the final version of the widgets (i.e. not the alpha version the participants saw). This evaluation led to series of recommendations group into two sets: (i) on improving existing functionality, and (ii) on extending the functionality. These are described below.

 (i) On existing usability, functionality and accessibility

Overall, the interface seems well designed and is clear and easy to use. Here are some comments about specific aspects of the usability, functionality and accessibility of the widget, along with some recommendations...
       When the user hovers their mouse over the widget icon embedded in a page, the mouse cursor style remains as the default cursor.
 Recommendation:  The mouse cursor should change to pointer style when over the widget icon embedded in a page. In addition, there ought to be some alt text for the widget icon, and there should be some ‘tool tip’ information which appears when the user hovers over the widget icon to indicate what will happen if the user clicks on it. There could also be alt text for each of the images used in the widget pop-up.
       On the widget pop-up, the information sources titles (e.g. GAP, Perseus, etc.) and the arrow icon to the right of the title are clickable, but the mouse cursor does not change to pointer style.
 Recommendation:  The mouse cursor ought to change to pointer style when over the source titles and the arrow icon.
       The information provided by GAP about each group of hits, and about each individual hit, is relatively helpful to users without specialist digital ancient history and place knowledge. In contrast, for both Perseus and Arachne the information about each group of hits, and about each individual hit, is not terribly helpful. It provides no way of distinguishing between the hits before the user clicks on them.
Recommendation:  For Arachne, each hit is currently shown as e.g. ‘Item 5’ i.e. the text ‘Item’ along with a number. This should probably be replaced with a title that allows the user to distinguish between the hits displayed before they select a hit to click on. For Perseus, the hits are grouped, as in e.g.:
“Perseus Greco-Roman:1999.02.0076:Book 3 1 hit
Perseus Greco-Roman:1999.02.0132 2 hits”
but these group titles are not intelligible to the participants.  The lists of hits follow the same pattern as those for Arachne i.e. ‘Item 5’ etc., and have the same problem. 
Recommendation:  As for Arachne, the title of individual hits could be best changed from ‘Item 5’ or similar to something meaningful that allows the user to distinguish between the hits. The grouping of Perseus hits should be explained to users in some way, such as through a tip that appears when the user hovers over a group title, or through a help page that is linked to from the widget.
       Opening the widget pop-up causes the browser window to scroll to the top of the page. The participants did not mention this as it was explained to them that it was an alpha version and it would be fixed.
       All participants liked the Flickr section (e.g. “it gave me a sense of the place as it is now”).
 Recommendation: The experimental Flickr section should be kept. There could, however, be an indication as to how the images displayed are sourced so that users can find out that it is not a search of the whole Flickr database but a constrained search e.g. through a link to some help text.
       Sometimes a section will indicate that data is being retrieved by showing the text ‘Loading’.  This is helpful, but the ‘Loading’ text remains static and the user can think something has gone wrong if nothing happens for several (tens of) seconds.
 Recommendation:  Show that something is happening: e.g. display ‘Loading item x  of 2112’, where the x changes as the individual items are loaded.
       The widget pop-up obscures the page and cannot be moved to reveal the page. 
Recommendation:  Make the widget pop-up moveable and resizable so that the user can move it to see the information displayed by the widget pop-up alongside the page context from which the user triggered the pop-up.
       The Pelagios icon and text at the top of the widget pop-up occupy a lot of screen space.
 Recommendation: Make the logo at the top of the pop-up occupy less space!

(ii) On extending the functionality
       To be able to save items via bookmarking, and to share  via social bookmarking, tweeting etc.
       To be able to filter large hit sets: e.g. for some of the places the different services produced more than 100 hits (occasionally more than 1000). It could be useful to filter these hits before examining them.
       To be able to see relationships between places on the map. In the case presented to the participants, for each different example a single place was shown on the map. It would be useful to be able to see where different examples are on the same map.
       To be able to search for other places so as to find the datasets for the user’s place of interest.

3. Widget Suite, Beta version (deliverable D3.4)
Findings from the alpha testing resulted in the decision to implement a search widget in addition to the place widget. The final (beta) version of the two visualization widgets was announced in mid-July

No comments:

Post a Comment