This is one of a series of posts building towards a full paper on the use and testing of the repository deposit tools, specifically for deposit of in-progress work, developed in the JISC DepositMO project. In this and the next two posts we shall explore earlier attempts to document and test repository usability, particularly from the author viewpoint, and try to show how it relates to our work in this area. This is an area that spans both formally reported work and practical work that may have been reported informally. If we have missed any relevant work that should be included, please leave a comment.
Digital repositories essentially provide a series of interfaces to get things done, such as deposit content in the repository, manage content (usually an administrator, but can involve others) and access content (users can browse or search, or machines can harvest content using OAI-PMH). It’s curious, then, that there have been few published studies of repository deposit or user testing of deposit interfaces.
In this work we are concerned with one of the repository interfaces, for deposit – that is, how new content is added to the repository. Both EPrints and DSpace provide native deposit interfaces, configurable by repository administrators; another popular repository software, Fedora, requires third-party interfaces. Basically, these deposit interfaces consist of Web forms that collect information, or metadata, describing the item or digital object being deposited, and a button to start the download of the selected item from a specified Web location.
These forms have been criticised for being too long and taking too much time to complete, even if the claim may be shown to be exaggerated (Carr and Harnad 2005). There is a perennial trade-off between collecting sufficient information from an author or creator of an object at the point of deposit to ensure it can be categorised, differentiated and fully searchable, and minimising inconvenience and time taken by the depositor.
Thus for digital repositories, user-facing issues in supporting deposit include design and requirements for metadata as well as more general Web usability.
This is not a new issue for a repository deposit interface. EPrints launched as the first institutional repository software in 2000, and by 2003 its deposit interface was being reviewed by the JISC TARDis project: “A focal point of the Southampton-TARDis re-design has been to simplify and assist user input, which was tackled in two principal ways. A facility for mediated data input is provided. Also, data input pages were structured so that authors, or mediators, need see only those input fields required for the type of document to be deposited.” (Gutteridge, et al. 2003) In fact, this structure is still clearly evident in the native EPrints deposit interface today.
It is notable that the TARDis report refers to “testing by local Southampton users and by administrators of EPrints.org software elsewhere”, but does not provide detail of the tests, just the outcomes. Later, around 2006, an independent research group did some user testing of EPrints, but its report was only briefly available online, was incomplete, and now seems to have been removed entirely. EPrints may have been a little coy about revealing the results of past user tests.
Taking the minimal metadata approach to its extreme, one repository project, EdShare was to develop “a closer, integrated deposit mechanism such that with a single deposit ‘click’, resources will be made visible within the institutional learning and teaching repository” (Morris 2009)
Together with Language Box, another teaching and learning repository project at the University of Southampton, EdShare aimed to raise use of such repositories but had recognized that traditional repositories ‘fell flat’ for this audience. They were inspired by Web 2.0 sharing sites such as YouTube and Flickr that allow users to deposit content with the minimum of overhead.
“Both repositories have simplicity at their heart. We used a minimum manual set of metadata, requiring only that users name their deposits and provide a minimum set of automatic metadata such as time and date of deposit, attribution, etc. The few optional metadata fields are based on well-understood terms (such as language) or are nonrestrictive (such as a description and tag fields).” (Davis, et al. 2009)
All the projects described so far have been funded by JISC, which has recently invested in a series of projects that have investigated aspects of repository deposit, culminating in its most substantial deposit strand within the Information Environment Programme 2009-11.
Earlier projects were concerned with metadata requirements and automated metadata extraction from source documents (Deposit Plait 2008-9), and making deposit more convenient for users by supporting batch deposit of documents (EM-Loader, 2008-9).
Motivations for many of the tools being developed in current projects, including DepositMO, can be seen in the JISC Deposit Tool Show & Tell Meeting (October 2009)
Among current JISC projects there is an emphasis on improving and supplementing repository metadata, and thereby reducing the information required from depositors, by linking information with research information systems and other institutional publications management systems. Enrich, DURA and RePosit are among the projects connecting repositories with systems such as Mendeley and Symplectics.
Another concern for repository deposit – given the different types of repository available to authors, including subject-based repositories such as ArXiv and PubMed Central, as well as institutional repositories – is that authors may have different requirements from research funders and institutional open access policies to deposit in one or more repositories. Based on such factors, the likely information flows between repository types were examined by Jones, et al. (2008).
Similarly, multi-authored papers may need to be deposited in multiple repositories.
Given these competing or complementary requirements placed on authors for repository deposit, Open Access Repository Junction is producing a broker tool to assist authors to deposit “in all the appropriate locations”, and to make the whole deposit process as simple as possible: “Deposit once, send to many”.
The next post will continue this review of studies of repository usability and user interfaces, with more emphasis on the interfaces.
0 Responses
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.