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.
