Sometimes it's worthwhile to let my "toblog" folder on del.icio.us marinate a bit. Posts I recently ran across on two different blogs illuminate the same point so well that they deserve their own post here!
Off the Map offers Huffman's Three Principles for Data Sharing, which are really principles for data-collection and -display applications:
- Create immediate value for anyone contributing data.
- Make contributors' data available back to them with improvements. (emphasis mine)
- [Urge users to] share derivative works back with the data-sharing community.
Absolutely. These three principles boil down to "Offer value for effort." We can build the biggest, most bulletproof disk and the shiniest audit trackers and the most knowledgeable data-curation staff the world has ever seen, but if researchers do not perceive value, or if the effort necessary to realize that value is excessive, they will stay away in droves.
We know this already. How we know it… well, that's the second post, this one HangingTogether's discussion of the popular paper-sharing service Mendeley. Why is Mendeley popular? According to the post:
- Its appeal is intuitive.
- It is instant.
- The demands it makes are low compared to the benefits it provides.
Do click over to read the whole post, which provides considerably more detail about Mendeley's featureset and why it is attractive. (Lack of bias alert: I am not a Mendeley user. You will pry my Zotero out of my cold dead fingers. Go Patriots!) The paragraph I want to address here is this one:
If it realises the potential many people are now predicting, the library community is bound to ask why a web application based on an entertainment model should have proved so much more attractive than the painstakingly built repositories we have been holding under the noses of our academic authors over the last several years?
Speaking as a librarian who's been running institutional repositories for nearly five years, I'm not asking. I think we know already. Mendeley offers low effort and high perceived value. IRs demand high effort and return negligible perceived value. If you know IRs, go back over the two lists above and think about how IRs rate. For myself, I will say that I try to add value to items in IRs when I can—sometimes it's as simple as name deduping so that an author browse or search works predictably—but I am under no illusions otherwise.
We cannot, must not repeat this error as we design data-curation systems. (Systems are more than technology, let's not forget; the human-resource aspect of service design matters too.) We cannot. If we do, the next Mendeley will eat our lunch—and then go under, taking all the data stored there with it. (Wonder what wakes me up at night in a cold sweat? Now you know.) Think it can't happen? Say, did you hear the news about Geocities? And ou sont les ebooks d'antan?
Perhaps the title of this post is better stated: "Bad user experience is not an option."
- Log in to post comments
More like this
Thanks--great way to put these, Dorothea! A related thought is "personal value precedes network value".
Another excellent way to phrase it, thanks!
Nice post. I find issues about data storage/repository/accessibility very interesting, so I appreciate your blog.
Thanks very much! Please do take a look through the blogroll as well.
Hi Dorothea, it's Jan here, from Mendeley.
Thanks for your interesting thoughts about Mendeley. I would like to add to this discussion that our aim is not to replace IRs (aka "eat your lunch"), but that we would like to work together with IRs in some way, making the content within IRs more easily accessible and transparent to users.
If you would like to discuss further, just let me know.
Best wishes
Jan
The way I think about it is simple - users don't really care how whiz-bang your technology is. Talking about your team of expert curators and redundant servers and independent foundation funding support mostly only gets other librarians excited, but it's the same kind of issue faced by every development project - how many features are we going to expose, how many options are we going to give to the user, etc. Techie people like developers just have a much higher baseline tolerance for complexity because the understand the importance of each thing and why it's there. The average user gets bewildered and confused way earlier. Case in point, I hear people all the time say something like "I should start using twitter, but it's just so complicated." When I hear that I think, "How complicated can it be to type words in a box and press submit?"
There's an XKCD-style graph that shows the usefulness of a program on the Y-axis and the number of features on the X, with a parabola going from the low end, annotated with "I wish I could do X" to the high end, annotated with "Where the f@&! did they put that feature!" The point it that almost everyone overshoots the apogee, especially as versions develop.
Jan, I would very much like to discuss this further. Feel free to contact me at my work email: dsalo at library dot wisc dot edu.
Mr. Gunn, "yes but." I tend to believe in the tenets of task-driven usability design. I've been reading a lot of Robert Hoekman lately, and I've read plenty of Alan Cooper and the "persona" school of design as well.
IRs simply failed to do any of that initial thinking-through of tasks, rewards, and usability. We all suffered for it! We need to think this time, before we code -- and we shouldn't be thinking in terms of "features and options" but in terms of "tasks and rewards."