Dropbox is a data storage and retrieval service that is typical of the new breed of network or ‘cloud’ services. What’s more interesting is the apparent popularity and wide use of this service among research scientists, at least according to those on our project user panel and the correspondent above. This post will look at Dropbox, to see what we can learn from its deposit method and interface, and to consider how it compares with the repository deposit model.

Dropbox immediately affirms its credentials as a Web 2.0 service on its front page, with its simple call to find out (video) or use (download). More unusually, there is no catchy slogan to sum up the service, unless you think the name does that already.

The video animation never stresses the technical aspects, but seeks to contextualise the service as a ‘magic pocket’ within a traveller scenario for synchronised cross-device access and sharing with others. We are asked to believe that our storybook user treats Dropbox as a “home for all of his stuff” and urges “you can stop worrying about managing files and backups and get on with your next adventure”. Less enticingly perhaps, but just as importantly, we are reassured the service provider “takes the security and privacy of your files very seriously”. In terms of cost, the service is free up to 2 GB of storage, with prices to expand this up to 100 GB.

There we have it, a pretty broad characterisation of the service, but not without the obligatory “You’re done.”

Alternatively, Dropbox is slow to upload and size-limited if you have a number of x-large files to upload (e.g. 30 GB), and expensive relative to a local institutional repository, say – I expected a withering response from the project developers to our user input, but not that this would be their target.

@depositMO Dropbox vs repository? Since reminded of distinction between research data cycle and publication cycle, but these now harder to separate (24 Jan 2011)

So a repository, especially an institutional repository of research papers, has a different purpose of access and dissemination centred on formal publication, often in conjunction with publication elsewhere, such as in a journal (the “authoritative” source). The first thing to note here is that in the case of such content the repository is not the only source, or even the primary source, but the free and open source, and unlike the content targetted by Dropbox that would otherwise simply reside on the author’s hard drive, this must have an effect on author motivations to deposit in a repository. This purpose also has consequential effects on author versus administrator/repository control of the content to be deposited, where Dropbox instead can leave the user in control.

Where repositories target content that is less likely to have alternative means of dissemination or publication, such as arts materials or teaching and learning content, then this has produced encouraging content growth, after careful consideration and redesign of the default repository deposit interfaces.

It might be expected that authors will write papers on a personal computer or over a number of such machines, and the text, especially in sciences, will be shared with co-authors working on other similar machines. What’s less clear is to what extent this process is mediated by other types of, e.g. mobile, devices. So the sharing and collaboration feature exhibited by Dropbox, if less so the cross-device support, might have repository application. Such support does not exist in repositories now, but that is what we might be seeking to add in the DepositMO project, leading to quite lively and heated discussion centred on support for workspace, sharing and deposit/publication. The need to maintain the distinction between a private, if shared, workspace and public space is something that repositories, but not Dropbox, have to give special attention.

By exhorting us to our next ‘adventure’ Dropbox seeks to get the service out of the user’s way, to minimise its impact on the user as far as possible. Depositing content is a necessary chore to be tolerated in lieu of more fun activities, it suggests. Repositories, in contrast, excepting the examples such as those above, rather than minimising the deposit process have tended to expand it in the quest for enhanced metadata, resulting in the widespread reversion from author deposit to mediated deposit by repository administrators. This was never the intention in the original conception of institutional repositories.

To what extent Dropbox achieves its claimed functionality in practice rather than in marketing spin requires experience of real use, but some initial feedback suggests that a simple drag-and drop method of placing saved files in the Dropbox ‘magic’ folder in the user’s file management tool (such as Windows Explorer) is simple and effective. This has encouraged us to ramp up our efforts to offer a similar approach in DepositMO, and an initial demo has been shown ahead of further testing.

Repositories and Dropbox (and no doubt other cloud storage services) appear to have similar and overlapping features but are not the same thing and are offering different services for different purposes. While recognising the differences, repositories may be able to learn something about reaching out to users in terms that seek to address their problems.

Developers work on instinct and an unflagging belief that what they do will work (after a bit of debugging). They turn complex problems into solutions in ways that can amaze the rest of us. Towards the end of the work, however, often there can be a lack of time for full user testing, or little interest in the results.

Does what it says on the tin, photo by chris5aw

If it does what it says on the proverbial tin, who specified the problem, and whose requirements are being addressed? Many developers will argue they know the intended use case and the users (for it is they). This can work well for original, highly innovative products or for projects sans users. In other cases, where users are key, or which are refinements and extensions of known products, the outputs will have to be measurable against clearly specified requirements, ideally with reference to real users. This project falls squarely into the latter category. Repository deposit interfaces are hardly new – how could they be – so what we seek to add has to be measured against what is already there.

It is important this is addressed before devising a plan for test and evaluation of the product, otherwise you may end up testing against a limited set of (developer) requirements – it works exactly as the developer said it would – or it doesn’t work with reference to a wider set of (user) requirements, because that’s not what the developer was building.

DepositMO has been a developer-driven project, with a team of developers working for it. As you can tell from entries to this blog, unless we missed something big we have some concepts so far, but not yet implementations for users to try and for us to report. We have requirements, set out in the project proposal, but technical frameworks can be a moving target. For example, we are working with the technical advisory group to produce the next version of SWORD, v2, which we expect will be a core component of what the project produces. That has yet to be finalised.

So at risk of a wilting response from the developers – “you can’t do that”, or “that won’t work” – we convened our user panel, sans developers (well, one crept in, but with a different hat on), to establish a preliminary plan for user testing and evaluation of the products and services from the DepositMO project, and to sketch out some use case scenarios based on identified scientist/author/repository workflows. It’s the use case scenarios we will concentrate on here (Table 1).

Represented on this panel, ultimately, are scientists at the University of Southampton from a number of disciplinary areas – archaeology, chemistry and materials science, as well as representatives of different institutional repositories, notably EdShare, which presents teaching and learning materials, and ePrints Soton, the university’s main institutional repository, which focuses on research papers and presentations. Table 1 shows feedback from a meeting of some from this panel held on 21 January.

Table 1. Use case scenarios leading to deposit for sciences and repositories

What does Table 1 reveal? It confirms that scientists are creating a variety of digital content and formats, not just text, using different applications but noting that Word remains in wide use, which is good for our project approach. Prior to publication this content is shared informally between team members using a range of methods. In terms of sharing, Dropbox emerged as the joker in the pack. It was suggested that this service is popular among the colleagues of our scientists. We shall investigate this service further in a later blog post, but one feature to be commented on is the use of Windows Explorer as a file deposit tool for use with Dropbox. A file management interface is on the agenda of our project developers.

Table 1 also shows that the repository requirements are not the same as those of the authors, and that by virtue of their different collection requirements, so the requirements of the two repositories will differ. These all have implications for the design and functionality of the proposed deposit interfaces, which connect authors with their chosen repositories. One requirement not recorded here is for single-click deposit to multiple repositories – that is already a design requirement and one of the original promises of SWORD – but perhaps not a straightforward task given even the brief repository findings here.

The need to find and list works by an author for later update has already been identified as a developer requirement, but mention of ResearcherID introduces a specific service providing author identification.

From Table 1 we can expand a possible use case: etheses. One of the problems, we are told, in making etheses available open access via repositories is the need to embargo sensitive or commercial content. It is usually the case, however, that not all the text need be embargoed, just certain sections, but because the thesis typically exists as a single document the embargoed material cannot be separated from the rest. It was suggested that a deposit approach might encourage a thesis to be deposited in sections, or ‘chunks’, allowing an embargo to be set for affected sections but with access to the rest.

BTW, in view of our emerging table of requirements an additional case study might be drawn from a recent paper by colleagues at Southampton (and elsewhere; 16 authors!) which describes scientists’ workflow, reuse, and publication in virtual research environments (VREs) such as myExperiment (rather than repositories): Why Linked Data is Not Enough for Scientists.

We shall return to the task of building a test plan at the next meeting of the user panel. Watch this space.

I am grateful to Kate Walker, Mark Scott, Debra Morris and Simon Coles for their contributions to this work.