Dropbox: lessons for repository deposit

@CameronNeylon Dropbox solves problem scientists know they have. Repositories don’t 4 most part. Ideal would be eg SWORD app against dropbox API (24 Jan 2011)

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.