Looking forward, there have been glimpses of repository interfaces that might play a role for in-progress file deposit and management, where in-progress means as the work is written and created. Runner-up in the Developer Challenge at Open Repositories 2009 was a prototype called FedoraFS by Rebecca Koesar, who exposed Fedora as a desktop filestore using Fuse: “while only a command line prototype at this point the ease of overlaying a Graphical User Interface with file-folder icons is all but a done deal.”

At Open Repositories 2011 the same Developer Challenge was won by Repository as a Service (RaaS) based on the idea that with standard repository interfaces, to get data in and out the repository becomes a commodity that can be swapped. The entry demonstrated an Android mobile app that used SWORD to deposit photos into both DSpace and EPrints. A common interface was provided to access the items in the repository. Both EPrints and DSpace provided identical experiences because of the common interfaces.

Which brings us to SWORD (Simple Web service Offering Repository Deposit). The idea that repository deposit might be abstracted from repository software began in practice with SWORD in 2007. At the core of its proposition was, given the plethora of repositories and user interfaces, that users could choose a single interface for deposit in multiple repositories. It may thus be the single-most important development in repository user interfaces since the original repository softwares, but its impact is still more in principle than practice in terms of alternative interfaces that have attracted wide use. This may be due to a lack of interfaces, or lack of uptake, but it has not limited the number of potential use cases, as shown by Lewis, et al. (2012).

Or it could be due to limited functionality, which will be fixed by SWORD version 2, released in December 2011. We have written on this blog before about the key developments in SWORD v2, taking it from a ‘fire and forget’ deposit method that is limited in terms of what authors can do with their content after depositing in a repository, to a model where authors retain more control over their content and items can be created, updated, replaced, or deleted (CRUD) in the repository. SWORD v2 is the basis of DepositMO’s vision for in-progress deposit.

SWORD builds on AtomPub, the Atom Publishing Protocol. Many may be more familiar with Atom in the form of an RSS-like syndication protocol; AtomPub is the flip side, about pushing content into a dissemination resource rather than its receipt by readers (Snell 2006). SWORD 2.0 continues to build on AtomPub through the inclusion of the CRUD operations of AtomPub to enable the following kinds of interactions, described by the SWORD 2.0 Profile:

1. Clients may create resources by sending compound resources, such as archive files (tar, zip).
2. Workflows which may or may not include manual stages before deposited resources become available as web resources, are acknowledged and supported
3. Clients may update or delete the compound resources or associated metadata

In the progression to profile 2.0, SWORD becomes more explicitly a deposit lifecycle standard: “Most of the enhancements in SWORD 2.0 are around closing the deposit loop. This deposit process is only a portion of the full content lifecycle and does not attempt to provide support for collaborative or distributed authoring environments or policy management; it is focused entirely on the process of moving content from one location to another.”

During consultation over the new profile the adoption of more powerful publication protocols was advocated, but these have not so far been included, leaving the profile specification to note: “For standards to integrate detailed content management operations it is recommended to look at OASIS CMIS (Organization for the Advancement of Structured Information Standards – Content Management Interoperability Services), or the Google Documents (GData) List API.” It was this aim of bringing more powerful content management features to repositories that led to the DepositMO extensions using the platform and flexibility that SWORDv2 created with reference to these other publication protocols.

A similar publishing protocol connecting content-producing tools and repositories for learning resources and metadata is the Simple Publishing Interface (SPI), which also uses AtomPub. The main difference between SWORD and SPI, according to Ternier, et al. (2010), is in the submission of metadata. “In SWORD, metadata is available in a package and thus submitted to the repository as a part of the resource. In contrast, the SPI model makes a clear distinction between metadata and content at submission time. The rationale for this strict separation comes from the SPI application domain. Where SWORD is primarily concerned with depositing data, SPI is also intended for application scenarios where only metadata is considered.”

We have presented in this series of three posts a sweeping review of practical work on the usability of repository interfaces, most notably the deposit interface. Broadly these studies have found little wrong with current ‘fire and forget’ deposit interfaces while in some cases making adjustments for the structure and volume of metadata collected at deposit. Detailed and critical evidence on whether deposit interfaces make a substantive difference to levels of deposit, however, is hard to find. If we are to move towards more sophisticated Web 2.0-like interfaces for repositories, providing more interaction with authors using new protocols such as SWORD v2 to capture work at an earlier stage of creation, then users and usability will have to become much more central to repository testing.

This concludes our three-part review of repository usability focussing on user deposit. The next post will start to report the results of user testing of the repository deposit tools developed in DepositMO.

If the deposit projects described in part 1 of this review were more concerned with metadata than the usability of repository interfaces, it may be because, unlike the Southampton projects that have close links with the development of EPrints, most of these projects do not have the keys to develop one of the main repository softwares. In response to its repository user survey, however, University of Rochester went further: it built its own repository software, known as ‘IR+’. This began with studies of faculty work practices and “resulted in modifications to the University of Rochester’s implementation of the DSpace code to better align the repository with the existing work practices of faculty.” (Foster and Gibbons 2005)

This included the introduction of Researcher and Researcher Tools pages. Further studies of work practices, of graduate students, followed at Rochester (Randall, et al. 2008). “The results of our work-practice study pointed to several enhancements, including personal showcase pages for faculty members and researchers, download statistics, and a checksum tool to support long-term preservation of files. We added these features to our IR and observed an increase in repository use as a result, but it was not a dramatic increase.” Note that the interest here was on authoring and information management practices used by the students: “Specifically, we wanted to build an authoring environment on our IR platform, while also integrating traditional and digital library functions and services. The end product is to be one interface for a wide range of research, writing, and archiving activities.”

The result, in 2010, was IR+, which “focuses on giving researchers an online ‘workspace’ within the repository where they can upload and preserve different versions of an article they are working on.” (Kolowich 2010)

An animated video on authoring support in IR+ shows that this private user workspace provides a file manager interface for sharing and collaboration, versioning and publication (Bell and Sarr 2010). In this respect IR+ can be compared with document services such as Google Docs and file management services such as Microsoft Sharepoint, rather than conventional repositories. DepositMO has worked on enabling deposit from similar applications – word processing and file management – but these applications are external to the repository.

There have been number of user studies of repositories focussed on the content submission process. A user evaluation of the DSpace multimedia repository B@bele (Caccialupi, et al. 2009) covered a variety of user issues including ‘Upload’, concluding: “The problem with submitting a new document depends on the layout of the upload page. Finding the upload link on that page is not simple since it is not visually recognizable as the link is inserted in the middle of the page. This task becomes especially difficult if other processes are not yet concluded and are therefore still active.” The method used here proceeded in a similar form to the DepositMO user tests.

Silva, et al. (2007, not OA) measured the ability of segregated groups of users to submit metadata to a repository, in this case the Brazilian Digital Library of Computing (BDBComp). Users had to access the repository, register, login, submit and check data. Results were claimed to show BDBComp to be an easy, comfortable, and useful self-archiving service, without indicating the motivations to use the system.

A model user study – simple, fast, focused – tested the submission process for a DSpace repository for electronic theses and dissertations (Boock 2005). The test included registration as well as deposit: “Usability testing proved we were on the right track and was well worth the two hours invested. Try it; it’s easy.”

While there are other usability studies of repositories and software, not all are from the author deposit viewpoint. McKay (2007) is concerned with repository users and usability, but not authors because they are “better studied than any other users of IRs.” Many such studies are to do with author motivations, or the lack of them, to use repositories (Mark and Shearer 2006, Davis and Connolly 2007) rather than with Web user interfaces.

Where usability studies get closer to repositories and software, they tend to be interested in functional issues, installation and configuration (Ottaviani 2006, Körber and Suleman 2008). Ottaviani considers deposit usability, but in practice proposes functional changes rather than a test report.

McKay and Burriss (2008) perform usability testing of VTLS Vital, one of the Fedora user interfaces, but in this case they test the information-seeking interfaces for end-users rather than deposit interfaces. Kim (J) (2005) compared the search user interfaces of DSpace and EPrints.

Kim (HH) and Kim (YH) (2008, not OA) provide suggestions that could be adapted to improve the usability of institutional repository systems, and to establish a usability evaluation framework. They seem principally interested in how to search for documents, improving visual appearance, clustering and display.

Similarly, although Feng and Huang (2008, not OA) claim to have evaluated the usability of three discipline repositories – arXiv, PubMed Central and E-LIS – their framework, or criteria, for evaluation are really features and usage data taken from the repositories rather than direct involvement with users.

Also based on E-LIS, a subject-focussed digital repository, Tsakonas and Papatheodorou (2008) explored usefulness, usability and performance of an open access digital library based on a statistical analysis of a user questionnaire. Using a theoretical framework rather than observations of practical use, the work revealed that repositories would need to be more closely linked with users’ work tasks.

The next post will continue this review of studies of repository usability by looking at repository deposit processes and protocols that increase the utility of deposit, which we expect will receive greater attention and use going forward.

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.