Skip to content
Categories:

Repository usability review 2: user deposit interfaces

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 post we continue our review of repository usability studies, here with an emphasis on repository interfaces. If we have missed any relevant work that should be included, please leave a comment.

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.

Posted in Uncategorized.

Tagged with , , , , , .

No comments

By Steve Hitchcock – January 25, 2012

Repository usability review 1: designing for metadata deposit

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.

People seem more concerned with which repository software to choose (DSpace v EPrints v Fedora) and the features of those softwares rather than users, usability and task satisfaction and completion. Developers of these softwares would probably argue that a decade of experience and feedback from users, reflected in each iteration and new version, outweighs the need for formal user tests.

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.

Posted in Uncategorized.

Tagged with , , , , , .

No comments

By Steve Hitchcock – January 24, 2012

DepositMO and SWORD at Repository Fringe 2011

Seven posts in the last week is a lot to read, so today we invite you to stop reading, relax and watch – should you still be interested in the repository deposit tools produced by DepositMO, and in SWORDv2. If you have been reading this far you will know about these already, but you might be wondering if they work for real. YouTube videos of Dave Tarrant and Richard Jones demonstrating these tools at Repository Fringe 2011 in Edinburgh last August might persuade you.

Or you might wait for the results of user tests performed with these tools, but since we began this journey towards user testing we have taken such a diversion that you might wonder whether we will get there. We are still on course, so stick with us.

What follows is the @depositMO Twitter commentary on the videos at the time of release in October 2011. For shorter, edited versions of the first video presented below, scroll further down.

Dave Tarrant demos MS Kinect & SWORD v2 deposit

  • Dave T has been accused of hand waving. As you will see from the video, it’s true
  • To be clear, file manager drag-drop tool seen in the video is tech from DepositMO (Kinect hand waving tech courtesy someone else) #jiscdepo
  • It is clearer that the Word deposit tool seen in 2nd half of the video is from DepositMO-so that’s both tools from the project #jiscdepo
  • Good to see both DepositMO tools got a spontaneous round of applause during Dave’s show. So that’s a tick for flashiness #jiscdepo

Deposit with MS Word. For a heavily edited version of just the Word part of the demo, see this alt. video (4min11)

  • From Word video: “Can hold process of ‘publishing’ (to repository) open. One of the key features of SWORDv2, build object before publish”
  • From Word video: “DepositMO has been focussing on building communication between repository and user”
  • From Word video: “Telling users where their content has gone so they can access it, add to it, edit it”
  • From Word video: “Build this conversation between the Web and whatever system you are using to produce (content)”
  • Why demo using Kinect? “Need to think carefully how we are going to get all these things in the repository-make it so intuitive, so easy”

Drag-drop Kinect deposit demo (Watch Folder). For a heavily edited version of just the drag-drop part of the demo, see this alt. video (2min40)

  • From Drag-Drop video: “1st object going in EPrints, 2nd in DSpace, going into both. All underlying technology is SWORD v2”

Richard Jones on SWORD2

Since “all underlying technology” in DepMO is SWORDv2, here is Richard Jones on SWORD2 in another Repo Fringe video

  • RJ on SWORDv2: “awesome community process”
  • RJ on SWORDv2: “going to investigate data deposit aspects that SWORD might be able to support. We’ve also got money for client developments”

Posted in Uncategorized.

Tagged with , , , , , , , , , , .

No comments

By Steve Hitchcock – January 23, 2012

DepositMO for EPrints

With SWORD version 1 it became simple to deposit into many digital repositories using any number of clients which all connected to a common Application Program Interface (API) at the repository. However, it was not specified how resources can be managed and enhanced subsequent to initial deposit. The SWORDv2 and DepositMO projects have been focussed on enabling this enhanced interaction, and also making it incredibly easy for users.

Where the SWORDv1 specification allowed resources to be Created in a repository, SWORDv2 has focussed on adding Retrieve, Update and Delete functions, thus providing full CRUD support. DepositMO focussed on use cases requiring extra functionality beyond basic CRUD but which could still use standard, already available specifications.

With DepositMO and SWORD v2 projects running in parallel this provided a set of clear requirements to enable complete interactive control of repository resources via a set of abstracted interfaces. By building upon existing, well developed and widely implemented standards (including HTTP and AtomPub), both projects utilise these standards to enhance digital repositories.

As both projects essentially outline the ideal RESTful implementation for discovery and control of resources in a digital repository, the specifications of the SWORDv2 and DepositMO projects have been integrated into the core of EPrints (v3.3). As a result, the RESTful interface to EPrints is as powerful and flexible as the built-in web interface, providing the following features:

1. All first-class objects can be managed via the REST interface. All EPrints, Documents, Files, Users and anything else identifiable by a URI can be created, updated and deleted via the REST interface.

2. All import plug-ins are now generic and can be utilised via the REST interface, doubling the number of supported package formats which can be deposited via SWORD. Additional plug-ins, which can be installed in a single click, are also available via the EPrints Bazaar app store.

3. The same permissions model is applied both via the SWORD/REST interface as via the normal EPrints interface. The permissions system provides a granular model via which users can be granted permissions based on item status, item type and even an individual item itself. Basically, if editing is possible via the web interface, then it is possible via SWORD.

4. The SWORDv2 specification supports the notion of “in-progress” items, so it has been possible to reduce the number of SWORD deposit endpoints in EPrints to ONE. This has many benefits:

  • This endpoint represents a user’s deposits (or repository contents), closely aligning it with the Google Docs implementation and extensions of the AtomPub specification on which SWORDv2 is based.
  • SWORD clients are easier to write.
  • The user requires less context about which “collection” their content belongs to – it belongs to their collection.

In EPrints, the collection in which an item belongs is represented as a piece of metadata, a significant difference from DSpace. Rather than managing and connecting with several collections, a user can deposit and discover all of their resources via ONE URI, which is the same URI for every user (typically http://myrepo.org/contents). While the SWORDv2 specification outlines how this URI can be used for deposit, DepositMO mandates that a client should also be able to perform the inverse operation and request a complete list of deposit contents via this same URI, regardless of the status of the object.

4. A unique identifier (in the form of a URI) is assigned to every object (including EPrints, Documents, Files, Users etc…) as soon as it is created regardless of the stage in the workflow. This URI will NEVER be reused or overwritten, and can thus be used to reference an object throughout its entire lifecycle in the repository.

5. All URIs support all REST operations: PUT/POST, HEAD, GET and DELETE. The DepositMO profile of SWORDv2 adds the requirement that each URI must accept a HTTP HEAD request. Using this HEAD request, a client is able to request information about an object, such as last changed date, without needing to download the whole object to find this out. This enables each object to be synchronised with a local copy, allowing two-way update with clients that are keeping a local up-to-date copy, an important requirement in distributed systems.

6. All URIs can be content negotiated, meaning that you can get an RDF/XML, Atom, csv… serialisation of every object in the repository. These plug-ins are the inverse of the import plug-ins, so not only can you ingest items in any format, you can also export them in that same format. Again further plug-ins can be installed in one click from the EPrints Bazaar.

In summary, SWORDv2 and DepositMO on EPrints represents a major leap forward in repository flexibility. By utilising the built-in power of the EPrints identifiers, permissions model and Bazaar Store for plug-ins (all of which have been key parts of the EPrints 3.3 development), the HTTP CRUD interface supports SWORDv2 and DepositMO specifications as core functionality, replicating the functionality available via the web interface. This gives users the power to interact fully with their repository and content via an interface or client which suits their way of working, in their environment!

Posted in Uncategorized.

Tagged with , , , , , , .

No comments

By davetaz – January 20, 2012

DepositMO for DSpace

DepositMO for DSpace is implemented as an extension to the standard SWORDv2 module implemented as part of the SWORD project. It provides additional features to list the items in a DSpace Collection, and to support a full range of CRUD (create, retrieve, update, delete) operations on individual files. The base SWORDv2 implementation recommends support for these kinds of operations, and provides documentation to aid development, but they are not part of the profile as a whole.

The current release of DSpace is version 1.8, and SWORDv2 is a part of that release. As such, the DepositMO extensions to DSpace have also been rolled into the release (with the exception of the packagers, discussed below). This is a significant development, as it means that new DSpace installations will be able to support the DepositMO extensions “out of the box”, which will be in-line with the EPrints support.

There are a number of notable features of the DSpace implementation which may differ from the EPrints experience:

  1. DSpace has a full hierarchical collection structure (called Communities and Collections) which EPrints does not. As such, DSpace Service Documents at least list all of the DSpace Collections as deposit endpoints, but can further offer a full hierarchy of Service Documents containing nested endpoints some of which do not accept deposits but which have sub-collections which do. The consequence of this is that the desktop tools have to be configured with the deposit endpoint of the Collection to which the user will actually be depositing content. There is no option for the user to select an endpoint at deposit-time, and adding such an option would no doubt bring unacceptable complexity in the user experience. Instead the desktop tools must be pre-configured, making them as simple to use as the EPrints version, but at the cost of a less well categorised repository holding. This issue is well known in the DSpace community, and it is therefore not a significant problem.
  2. DSpace’s permissions model is relatively complex and there are known issues with providing the end-user with the appropriate rights to modify their own content via remote APIs under various circumstances. For this reason, the prototyping done for DepositMO utilises relatively privileged users for the demonstration. A real production implementation would have a more carefully crafted user model in DSpace.
  3. DSpace’s collections represent actual collections of content, while EPrints only has a single collection in SWORDv2 which represents the user’s Inbox. This means that all operations in EPrints work only on items which are in the user’s inbox. Since the connection between SWORD Collection and the user’s workspace in DSpace does not exist, the DepositMO extensions have been constructed to ensure that all the content being worked on remains in the user’s workspace to mimic the EPrints implementation. This is actually the ideal implementation, as significant complexity and the need for versioning multiply rapidly once users can modify content which has left the workspace and entered either the review workflow or the archive itself.
  4. DSpace does not provide stable identifiers for objects until they have reached the “archive” itself: items in the workspace or workflow do not have public or even linkable URLs. Since DepositMO requires such URLs to direct users to their repository content, and that content is necessarily in the workspace (see point 3) this presents a problem. To circumvent this problem we have extended the SWORDv2 implementation in DSpace to provide URLs which do resolve to the item in the workspace for both of the application’s web interfaces (JSPUI and XMLUI). The user can therefore follow a link from their desktop to their working item (via a login screen). This feature only works for items in the workspace, as items in the workflow are not directly accessible to the submitting user. This means that the DepositMO desktop client cannot simply remember the identifier for the item on initial deposit, but must regularly check for updates, in case the identifier has changed.

In addition to these developments, the DSpace implementation of DepositMO also provides two Packagers. These are plugins to DSpace which implement SWORD’s ingestion interface and can be brought to bear on incoming content types. As part of the project basic XIF and DocX ingesters were written (utilising pre-existing code contributions by other DSpace developers), and made available open source. These packagers, due to their basic nature, have not been included in the DSpace 1.8 release, but are available separately here.

Overall, the implementation of the DepositMO extensions has been a very natural extension to the SWORDv2 implementation, and will no doubt be valuable to future users of the interface.

Posted in Uncategorized.

Tagged with , , , , , .

No comments

By rjones – January 20, 2012

DepositMO extensions for SWORDv2 clients

Previous posts have described two tools developed in DepositMO – the Word Add-in, and the Watch Folder – for improved repository deposit of in-progress works. These tools are freely downloadable for use now, but if you were to try and use them to add content to your local repository it is likely a key element will be missing. Your target repository has to support SWORDv2. Most support SWORD, but not yet the latest version (v2). They could do, however, because SWORDv2 is available with current versions of EPrints (3.3) and DSpace (1.8). In addition, DepositMO has extended SWORDv2 to add significant features required by the deposit tools produced by this project and which we believe will support further applications, and these extensions are also supported in current repository releases. Forthcoming posts here will look in more detail at how EPrints and DSpace each implement SWORDv2 with DepositMO extensions. First, in this post we look at the reasons for these extensions.

Content Management Systems (CMSs) should allow a number of basic functions to be carried out by a user, and digital repositories are no exception. Historically, such repositories have provided pretty web-based, human-focused interfaces through which users can manually perform the tasks of creating and publishing resources. With the development of SWORD, the creation and management of resources became something which, in part, could be carried out using an automated, machine-based client.

In SWORD version 1, this process was focused on making the operation of publishing a completed resource simpler. Further interaction (including retrieval of the same object) was not defined as a requirement. Thus this first specification, while useful, fell short of being a complete CMS system.

It was the intention of SWORDv2 and the DepositMO project to address these shortcomings. In addition, a DepositMO implementation of SWORDv2, the DepositMO profile, extends the functionality of SWORDv2 using a number of the as yet unused parts of the protocols SWORDv2 is based on – AtomPub and HTTP.

This post describes the features SWORDv2 provides to turn repositories into full CMSs, and details two extensions implemented in the DepositMO profile. While the DepositMO profile is a technical document, here we show how the extensions support two particular use cases, and how the DepositMO-developed deposit clients exploit SWORDv2 and the extensions.

Extending repositories as full content management systems

Figure 1 shows some of the basic operations that need to be supported by a digital repository-based CMS system.

Discover: The ability to provide simple description services which allow the client to choose the best method for deposit. Additionally, a client should be able to discover existing resources in the repository, thus skipping Create directly to Update.

Create: Provides a way for a client to create a resource  – a publication object – in the repository. It is this object that is then populated with relevant content.

Update: By making the repository a workspace, content should also be changeable.

Publish: Provide users with a way of describing an object as being suitable for publishing, making it public.

Retrieve: A critical aspect of any CMS system, a user must be able to retrieve their own content.

Delete: Similar to update, a user may be able to delete any resources they own. This is not always the case in digital repositories due to the ties of such systems with the classic publication model (a physical printed copy is hard to ‘delete’).

Use cases for DepositMO extensions to SWORDv2

As well as playing a key role in developing SWORDv2, the DepositMO specification details two key extensions to the SWORDv2 specification:

  1. A user/client must be able to retrieve a list of their content regardless of the status of that content (edit, review, published, etc.).
  2. A client must be able to obtain basic information about individual objects such that distributed copies can be kept synchronised and up to date.

To demonstrate the importance of these aspects consider the following two use cases:

  • A user creates a formal paper which on completion is deposited and published in a repository for a conference. At the conference the author gives a presentation to accompany this submission. Logically this presentation should also accompany the publication already in the repository. Using the DepositMO discovery specification, the presentation software can list all the resources already in the repository and the user can “attach” the presentation as a complementary resource.
  • A user is working on a publication for a conference, but wants to work both at home and at work without having to carry around a laptop or a USB memory stick, which will get lost just like half  a pair of socks. By using the repository as a workspace, two clients can maintain synchronisation of the same resource. To save download and comparing the document, which might be of substantial size, a DepositMO extension can be used to check the state of the object without having to download it.

As part of the DepositMO project two clients were produced – a Microsoft Word Add-in client, and a Watch Folder drag-and-drop deposit tool that works with file managers on standard PCs – to demonstrate the principles of these use cases. Although neither the most complete or prettiest clients, they do demonstrate the power of the two combined DepositMO extensions to the SWORDv2 specifications.

DropBox-style repository resource control – Watch Folder client

DropBox is easy. You drag stuff in, it is shared, simple. The barrier to entry for such services is low, meaning that people use them for convenience and uptake is high.

During the DepositMO project, questions were asked about how digital repositories, a trusted authority, could keep up with such technologies. This led to the development within DepositMO of a DropBox-style client for a digital repository.

Called “Watch Folder”, this client enables a user to create a folder, representing their resource, in a standard file manager on a personal computer, and then to add objects that are part of this resource to this folder.

As an example, the repository could contain a collection of images (the objects) relating to a single art exhibition (the resource, folder). As each object is copied into the folder it is simultaneously uploaded to the repository. View and edit links also appear as files on the desktop, connecting the user directly with the corresponding object in the digital repository.

As with DropBox, if an object is deleted or updated via either the repository or desktop interface then this change is instantly reflected in both locations. This functionality is not possible without the DepositMO extensions to the SWORDv2 specification.

The Watch Folder client demonstrates the ideal simplicity of a SWORDv2/DepositMO client to the user.

Windows application integration – Word add-in client

The second client produced as part of the DepositMO project integrates Microsoft Word with a digital repository. Although not a new concept – a similar client was produced by Microsoft to conform with the SWORDv1 specification – the DepositMO version integrates the complete CMS functionality as detailed by the SWORDv2 and DepositMO specifications.

From the start the Windows development separated the low-level driver from application integration. In this way the driver connects the application to the SWORDv2/DepositMO server via an easy-to-use API. This has the beneficial side-effect that the same driver can be used by many applications, saving substantial amounts of time when developing further clients.

The Microsoft Word add-in adds a new tab to the menu “ribbon” in Office 2010. Using this tab a user can set up their credentials with the repository, which can then be used to create and edit resources. Again, the user remains connected to their content whether on the local machine or in the repository.

Future of the DepositMO profile of SWORDv2

The DepositMO profile complements the SWORDv2 specification in order to provide more advanced functionality to deposit clients. For now the DepositMO specification remains an extension to SWORDv2, albeit one that is already integrated into the core of the latest EPrints and DSpace softwares, as will be revealed in the next two posts here. It would not be a huge leap to include the two simple DepositMO extensions in a future SWORDv2 specification, as without them many simple operations are just not possible.

Posted in Uncategorized.

Tagged with , , , , , , , .

No comments

By davetaz – January 19, 2012

Watch Folder deposit tool

Having previously looked at the Word Add-in deposit tool, this post illustrates the second of the deposit tools developed in the DepositMO project, the Watch Folder, which uses common file manager services.

Computer systems provide users with file manager tools, such as Windows Explorer or Mac Finder. This organises lists of files, and folders containing files, stored on the computer. Mostly these are fairly static services. Users can save files to designated directories and folders, and can move and copy files to different locations using short-cut keys of drag-and-drop.

We want to make use of this process of copy or drag-and-drop to initiate repository deposit. It works on the basis of a ‘watch folder’. Essentially this folder contains a script that monitors user actions in adding files or folders to the directory containing the watch folder. Figure 1 shows the active directory containing the watch folder, and also the script that runs when you click on the watch folder.

Fig.1 Active directory containing the Watch Folder script

When a new file is added to the directory containing the watch folder the script initiates a session with the selected repository and copies the file there as well. To complete this process the general script needs some information from the user, the same information used in the Word Add-in example:

  • Direction, or url, for the repository
  • User login for the repository

This information is provided via a simple text form that is launched by clicking on the CONFIG file in the same directory (see Figure 2). This information only needs to be provided once per user per session with the script running, not for each new file deposit.

Fig. 2 Opening the Watch Folder CONGIG file to specify repository direction and user’s repository login

The watch folder ‘watches’ for changes to all folders in the directory. When a user adds a new file to a ‘watched’ folder, either a new or existing folder in the active directory, within a few seconds the script automatically adds two new files (Figure 3): METADATA, and VIEW_ITEM.

Fig.3 Adding a new file to a ‘watched’ folder generates a METADATA file and a VIEW_ITEM link file

Clicking on METADATA shows an XML copy of the metadata record for the object (content of folder and files) stored in the repository. The user can edit and save the XML record to update the metadata in the repository.

Clicking on VIEW_ITEM will link the user to the real repository record in a Web browser.

In this scheme, a folder in the active directory containing the watch folder represents a record in the repository, and a file in that folder represents an object linked from that record. Thus, folders can be used to organise collections in the repository, for example, adding two images to a folder will link both images to the same repository record. Hence, creating a new folder will correspond to a new record in the repository; an existing folder to a current record.

You can download the Watch Folder script (folder sync client) from our collected project resources. Note, this is not a formally packaged application for easy installation, unless you are comfortable working with perl scripts. For the brave a short ‘getting started’ guide can be found close to the download link for the script.

In principle, this was designed to be a simple way to deposit any file in a repository using basic drag-and-drop and copy commands, and add/update metadata, on the user desktop. Would it prove to be as simple in practice?

The Watch Folder and Word-Add-in are the two user-facing tools developed in DepositMO, but to work effectively these tools need to communicate interactively with repository servers, or repository ‘endpoints’ as they are known in the SWORD community. It is SWORDv2 that enables this communication between endpoints and user applications. The next three posts will consider SWORDv2 and how DepositMO has shaped and extended this standard for different repository softwares, DSpace and EPrints.

Posted in Uncategorized.

Tagged with , , , , , .

12 comments

By Steve Hitchcock – January 18, 2012

Microsoft Word Add-in deposit tool

DepositMO has produced three tools to enhance repository deposit. Here we describe the first of those tools, the Microsoft Word Add-in deposit tool.

The developer of the tool, Richard Boardman from the School of Engineering Sciences at the University of Southampton and a DepositMO project developer, has written a User Guide. This guide covers installation, use, and advanced features such as how to add and markup metadata using Word to ensure that metadata is recognised and reproduced in the repository deposit process.

In this case we are concerned with using the tool and submitting documents, that is, how it was used in the user tests, and so just that section is reproduced from the guide in this post. If you wish to find out more about installing the tool and other features, please see the full user guide. A link to download the tool will be provided at the end of this post.

Installation of this tool requires the use of Windows and the latest release of Microsoft Office/Word 2010. We chose to work with Word as it is a popular authoring tool, widely used among researchers and scientists to write research papers and create materials that are likely to be deposited in institutional repositories. In addition, Microsoft has been seeking to extend the use of Word for digital science by supporting plugins, applications that provide additional functionality required by science authors, such as science and maths markup, DTDs and deposit in arXiv. The deposit tool described here is another such plugin.

Although it is popular, adoption of the latest version of Word and Windows is not universal. So that we did not exclude possible test users, we set up and installed the tool so that the test was not dependent on the user’s equipment.

Since working with users we have been asked if the tool works with other applications in Office, such as Powerpoint. It does not. Emulation of the tool for Powerpoint is possible but not simple.

The following extracts are taken directly from the User Guide.

Using the add-in

Once the add-in has been installed, you should verify that it is available in your copy of Microsoft Word 2010. To do this, start up Microsoft Word 2010 and look for a new entry along the ribbon at the top of the screen.

Figure 1: DepositMO 2010 Word Add-in is visible at the end of the ribbon tabs

Clicking on the DepositMO tab will display the basic controls for the add-in. Show and Hide on the Repository control group will show and hide the main DepositMO control panel. These will by default appear at the right-hand side of the window.

Specifying an Endpoint in the Quick submission group, and clicking Submit will bring up a dialogue box prompting you for your username and password for that endpoint, and allow you to submit the current document to the repository.

Clicking About DepositMO 2010 in the About group will bring up basic information about the add-in.

Figure 2: DepositMO ribbon controls

Submitting a document

Let’s walk through the deposition process with a new document. Enter some text on to the empty Microsoft Word document.

Figure 3: Creating a basic document

Before you can deposit this to the repository, you must first save it on to your computer.

Figure 4: Saving the basic document

If you do not do this, then the add-in will prompt you to save it later before deposition can occur. Clicking Show in the Repository control group of the ribbon will bring up the main control panel for deposition.

Figure 5: Show the repository control panel

The main control panel can be seen now on the right of the window. This has a number of controls for accessing repositories.

Figure 6: The repository control panel in the Microsoft Word window

The top section of the panel allows you to enter details of the target repository: your repository’s location (sometimes referred to as an endpoint), your username at that repository, and the password associated with that username.

Figure 7: Repository endpoint and user details

After entering these details, you can then submit the document to the repository by clicking the Submit button underneath.

Figure 8: Submit and update buttons

The add-in will then send your document to the remote repository. The progress of the submission is then displayed in the Messages box at the bottom of the panel.

Figure 9: Add-in messages

If the submission was successful, then a message similar to the one above will be displayed. This indicates where a copy of our document resides (note that the original still exists where you saved it locally earlier). If it was not successful, then you should check the endpoint and your credentials (username and password), and additionally check the repository by visiting the area on that repository where you would usually manage your deposits.

Figure 10: Document location field

On a successful submission, the Document location field is automatically updated with the remote location of this document.

Figure 11: Panel appearance after a successful deposition

If you look at the panel now our deposition has successfully completed, you can see that the Repository location remains unchanged, as does the Username and Password, but the Document location is now different, as explained above. The Messages can be reviewed by scrolling up the little text area.

You can review your recent submission to the remote repository by visiting it with your web browser.

Note that as our example document contained no information about the title or authors of the document, there is correspondingly little detail on the server

Figure 12: Reviewing the submission in the remote repository

Download the Add-in

This ends our extracts in this post. If you wish to learn about updating a document submitted to repository and other ways to use to use this tool, continue reading the User Guide.

Now you know the basics of how to use the Word Add-in tool a you may want to download it to use with your copy of Word 2010. This download can be found among our collected project resources. The guide has instructions for installation.

The next post will introduce the second of the repository deposit tools developed by the DepositMO project and subjected to user testing, the Watch Folder tool.

Posted in Uncategorized.

Tagged with , , , , , .

No comments

By Steve Hitchcock – January 18, 2012

Deposit tools produced by DepositMO

Show MS Word Add-in for repository deposit

Show MS Word Add-in for repository deposit

The target of current repository software is completed works.

The principal contribution of the DepositMO project is to provide new tools to support deposit of in-progress digital works. This is a significant change from current methods of repository deposit involving completed works.

To do this requires two new methods: deposit tools built into the authoring applications, and a means for these applications to communicate and interact with the repository software, providing the user with status and update responses. In essence this is like replacing your computer hard drive, instead saving the content destined for the repository directly in that repository and treating it as a network drive. Saving this content to a repository iteratively as it develops, as you do when saving on your local computer, requires the same functionality and assurance of correct execution, security and privacy. As we shall see, however, the expectation of description and metadata for a repository adds complexity compared with the simple method of save-to-hard-disc-and-add-filename.

Watch Folder, repository deposit via a standard file manager

We have blogged before about the principles, reasons and advantages of this new approach to repository deposit, but apart from some early demonstration videos we have not previously described or illustrated the actual deposit tools in any detail. Post-user testing of these tools we can now rectify this omission.

There are three new elements, including two deposit tools, and a means of enhancing and updating popular repository software such as EPrints and DSpace:

SWORDv2 supports Create, Retrieve, Update, Delete

SWORDv2 supports Create, Retrieve, Update, Delete

  1. A Microsoft Word Add-in deposit tool, to allow content in a document to be saved to, updated, or deleted from a repository during composition, without leaving the application.
  2. A Watch Folder deposit tool, to enable content of any type and in any format to be uploaded to a repository simply by dragging in a file manager window.
  3. Extensions to SWORDv2 for repository software

Of course, the second tool obviates the principle of bypassing the local hard drive, since the file manager is a record of what’s on the drive. But it means we can test deposit of a wider range of content before deposit tools are integrated with more authoring applications. Experience with building the Word deposit tool shows this is a major investment of time and expertise, as well as liaison with and support of the developer of the original application, in this case Microsoft – even when the application supports in-application plugins through APIs.

In the next three posts we will explore each of these new deposit tools in more detail, starting with the Word Add-in deposit tool.

Posted in Uncategorized.

Tagged with , , , , , , .

No comments

By Steve Hitchcock – January 17, 2012

User testing: the panic room beckons

Since the post about SWORD and this project from Richard Jones, there have been no blog posts here recently. That’s because we were supposed to have been in user testing purgatory purdah. In fact, the testing process took a break in summer 2011 and did not resume as planned to test some recent updates to enable DepositMO clients to work with DSpace.

With user testing you have to be careful (and you can never be too careful in such matters, as our extended break will attest) not to pre-empt or prejudice the results with prior or leading information.

Having belatedly realised that user testing is complete, we can now resume the story of the project, which set out to change the Modus Operandi, for authors, of repository deposit by enabling them to deposit in-progress work directly from their preferred desktop applications. There is a lot to catch up with, so we are grateful to Balviar Notay and JISC for allowing an extended project schedule and the chance to complete the story.

Testing is towards the culmination of that story, so before we get to the results we have to rewind in order to understand what we are testing and why. Ahead of a full paper, we will build that story in a series of blog posts here. From that you can anticipate these posts will cover background, tools being tested, method and anything else that needs to be known to understand what we have been doing, as well as results and conclusions – all the things you would expect in a formal report of the work.

First, it may help to understand the effects of testing on the people involved, and the careful lines that have to trodden in development and user testing.

There is a saying in commerce that the customer is always right, even if the commercial partner is saying this through gritted teeth. The equivalent on the Web is that the user is always right. For years Jakob Nielsen’s Alertbox newsletter on Web Usability has shown that Web site developers ignore this at their peril. Users don’t have to answer for their decisions when it comes to using a Web site, or not. With a poorly designed Web site or service what you will notice is those users disappear. That is a ruthless outcome.

One way to avoid this, before it is too late, is user testing. When it comes to testing, the outcome can be just as ruthless and unforgiving, but in addition you are giving voice to, and recording the verdict of, the tester.

It can work the other way, of course, that you have a brilliant product and testing reinforces that, but it is more likely that the brilliant product you think you have created will emerge once refinements, learned the hard way from user testing, have been implemented.

Remember, in the line of fire here is the developer of the product or service being tested. Good developers may pour their heart and soul into what they are developing, only for this to be crushed by testing. It’s easy to say developers have to be thick-skinned, but also understandable if their reaction is to dismiss and diminish the tester. So long as they understand that the tester, if properly chosen, should be their next user, and the user will not change a negative opinion unless something else about the object under test changes.

It’s important to distinguish, in the case of typical Web services, between software testing and user testing. Developers do software testing themselves, running their code through machines and debugging. This is not about code testing, however. Machines are more pliable and predictable than real users.

In this project we are fortunate to have others who are not developers to manage user testing, and take the developers out of the immediate test firing line. So here I am, test moderator and reporter, standing in that uneasy space between user and developer.

Don’t assume that makes the process less stressful. To find out what doesn’t work about the subject under test, it is essential that everything else does work. The test process has to be designed and appropriate for the purpose; users have to be recruited; venues found and booked; documentation produced and systems set; all have to be ready on time. This is no different from any other meeting, except where most meetings can recover from organisational oversights, a single mistake can invalidate your test and all the work that has gone into it. Users can be fickle, and so can developers when offered the opportunity to pass off any unfavourable result to other user factors.

On the eve of each test I review every arrangement to try and anticipate what can go wrong – every little boring detail. If a sense of panic fills emails sent at this stage, it’s because there is panic, until all potential fault lines are closed. This often continues until the moment before the test, when everyone and everything is finally and demonstrably ready. Only when the test is underway can you relax, a little.

A test moderator seeks to navigate between objective and outcome, through iteration if necessary, most importantly trying not to be blinded by allegiance or personality or self-interest, but laying the foundation to make objective decisions for what to do next, whether by us or others.

With all that understood, in the next post we will begin the story of the repository deposit tools produced by DepositMO, and how they fared in front of test users. What I can tell you now is that we had no disasters in organising the tests, from my point of view, and I think I would have known. Therefore, like an auditor, I shall present the report as a valid representation of the tools under test. Whether that survives the scrutiny of the other participants and vested interests, we shall see as the story unfolds, but rest assured I am covering my back there as well.

Next, we will start to learn more about the tools under test.

Posted in Uncategorized.

Tagged with , , , , .

No comments

By Steve Hitchcock – January 16, 2012