Repository usability - take 2

OK... following my 'rant' yesterday about repository user-interface design generally (and, I suppose, the Edinburgh Research Archive in particular), Chris Rusbridge suggested I take a similar look at an ePrints.org-based repository and pointed to a research paper by Les Carr in the University of Southampton School of Electronics and Computer Science repository by way of example.  I'm happy to do so though I'm going to try and limit myself to a 10 minute survey of the kind I did yesterday.

The paper in question was originally published in The Computer Journal (Oxford University Press) and is available from http://comjnl.oxfordjournals.org/cgi/content/abstract/50/6/703 though I don't have the necessary access rights to see the PDF that OUP make available.  (In passing, it's good to see that OUP have little or no clue about Cool URIs, resorting instead to the totally useless (in Web terms at least) DOI as text string, "doi:10.1093/comjnl/bxm067" as their means of identification :-( ).

The jump-off page for the article in the repository is at http://eprints.ecs.soton.ac.uk/14352/, a URL that, while it isn't too bad, could probably be better.  How about replacing 'eprints.ecs' by 'research' for example to mitigate against changes in repository content (things other than eprints) and organisational structure (the day Computer Science becomes a separate school).

The jump-off page itself is significantly better in usability terms than the one I looked at yesterday.  The page <title> is set correctly for a start.  Hurrah!  Further, the link to the PDF of the paper is near the top of the page and a mouse-over pop-up shows clearly what you are going to get when you follow the link.  I've heard people bemoaning the use of pop-ups like this in usability terms in the past but I have to say, in this case, I think it works quite well.  On the downside, the link text is just 'PDF' which is less informative than it should be.

Following the abstract a short list of information about the paper is presented.  Author names are linked (good) though for some reason keywords are not (bad).  I have no idea what a 'Performance indicator' is in this context, even less so the value "EZ~05~05~11".  Similarly I don't see what use the ID Code is and I don't know if Last Modified refers to the paper or the information about the paper.  On that basis, I would suggest some mouse-over help text to explain these terms to end-users like myself.

The 'Look up in Google Scholar' link fails to deliver any useful results, though I'm not sure if that is a fault on the part of Google Scholar or the repository?  In any case, a bit of Ajax that indicated how many results that link was going to return would be nice (note: I have no idea off the top of my head if it is possible to do that or not).

Each of the references towards the bottom of the page has a 'SEEK' button next to them (why uppercase?).  As with my comments yesterday, this is a button that acts like a link (from my perspective as the end-user) so it is not clear to me why it has been implemented in the way it has (though I'm guessing that it is to do with limitations in the way Paracite (the target of the link) has been implemented.  My gut feeling is that there is something unRESTful in the way this is working, though I could be wrong.  In any case, it seems to be using an HTTP POST request where a HTTP GET would be more appropriate?

There is no shortage of embedded metadata in the page, at least in terms of volume, though it is interesting that <meta name="DC.subject" ... > is provided whereas the far more useful <meta name="keywords" ... > is not.

The page also contains a large number of <link rel="alternate" ... > tags in the page header - matching the wide range of metadata formats available for manual export from the page (are end-users really interested in all this stuff?) - so many in fact, that I question how useful these could possibly be in any real-world machine-to-machine scenario.

Overall then, I think this is a pretty good HTML page in usability terms.  I don't know how far this is an "out of the box" ePrints.org installation or how much it has been customised but I suggest that it is something that other repository managers could usefully take a look at.

Usability and SEO don't centre around individual pages of course, so the kind of analysis that I've done here needs to be much broader in its reach, considering how the repository functions as a whole site and, ultimately, how the network of institutional repositories and related services (since that seems to be the architectural approach we have settled on) function in usability terms.

Once again, my fundamental point here is not about individual repositories.  My point is that I don't see the issues around "eprint repositories as a part of the Web" featuring high up the agenda of our discussions as a community (and I suggest the same is true of  learning object repositories), in part because we have allowed ourselves to get sidetracked by discussion of community-specific 'interoperability' solutions that we then tend to treat as some kind of magic bullet, rolling them out whenever someone questions one approach or another.

Even where usability and SEO are on the agenda (as appears to be the case here) It's not enough that individual repositories think about the issues, even if some or most make good decisions, because most end-users (i.e. researchers) need to work across multiple repositories (typically globally) and therefore we need the usability of the system as a whole to function correctly.  We therefore need to think about these issues as a community.

Comments

[Jonathan Rochkind]

"The 'Look up in Google Scholar' link fails to deliver any useful results, though I'm not sure if that is a fault on the part of Google Scholar or the repository? In any case, a bit of Ajax that indicated how many results that link was going to return would be nice (note: I have no idea off the top of my head if it is possible to do that or not)."

It would probably violate the Google Scholar ToS even if you were to hack it in. Google Scholar quite notably does not give you any sort of API (almost alone among google search offerings), and the Google Scholar ToS are quite restrictive. Google doesn't want you doing much with Scholar that's not using scholar.google.com itself.

[Owen Stephens]

Interestingly the reason the Google Scholar link doesn't work seems to be because the repository and the Journal of Computing seem to disagree about the title. The Journal (and the paper itself) omits the final part of the title given by the repository "in Military Operations Other Than War"

I have to admit I'd be inclined not to throw the whole title at Google Scholar anyway - it's just speculative, so why not use the first word of the title and first author surname?

[Chris Rusbridge]

I did try two author surnames and AktiveSA on Google Scholar. It did give me the Computer Journal article (number 7 on the list, which surprised me) but not the repository version, as far as I could find, which surprised me even more. So of course it didn't manage to conflate the two, as it did with my article we were looking at yesterday.

So again, I'm not sure if this is a case of repository reducing Googlejuice or not!

[Chris Keene]

Will probably regret saying this, and it comes out of nothing but my own ignorance, but have always found eprints far nicer than dspace, and with additional useful features (eg easier to customise look, dspace has only recently made it easier to do so). (though I think dspace spends time getting the data structures right, plus setting up a long term organisational structure - the foundation).

eprints uses simple and short URLs and this is very good.

moving away from eprints/dspace comparison.

One thing I note is that many repositories, especially those set up more than a couple of years a go, used a hostname of eprints (eprints.myuni.ac.uk). I did the same (http://eprints.sussex.ac.uk) and now regret this.
I agree that something like research would be better. I may look at add that (if allowed) while still ensuring the eprints name works, urls not breaking being a good thing.

I'm not against extra metadata, including bits which not everyone will understand. The 'performance indicator' you mentioned is a RAE thing. The important thing is to separate the main/general stuff (author, title, journal) and the other (specialist) stuff which needs to be less prominent.

Two more things:
- I've seen mention of plans to include links to related deposited items, either through user data (those who looked at this also looked at), or similar metadata.
- Im interested in the idea of embedding a player/viewer of the doc, to really hit home how important the fulltext is. eg embedded pdf reader (like this one http://sdu.ictp.it/openaccess/book.html ), flash video player, etc.

Oh, and on another note, really important to embed metadata (RDFa Coins) so that tools such as zotero can understand it.

Chris Keene

[Talat Chaudhri]

Does this mean that EPrints does not give items a permanent handle in the same way as DSpace?

In DSpace, the permanent handle does not contain the name of the repository so, provided people do quote them rather than the repository-specific alternatives, nothing would be broken if the domain or subdomain were changed. Basically the URL contains a repository identifier number and a running number. The latter are never re-used even if an item is completely withdrawn.

Example from my former repository:

http://hdl.handle.net/2160/1875
http://cadair.aber.ac.uk/dspace/handle/2160/1875

These are equivalent. This appears to be a "cool URL" to me - comments? Does EPrints use such a method?

[Chris Keene]

Talat, See Andy's previous post (looking at Dspace), the use of a URL/hostname different to the one used by the browser was questioned (and I pretty much agree) as something that could be confusing and users were more likely to use the URL of the page they were at, especially with bookmarking tools etc.

Chris

[AndyP]

@Talat - As Chris says, there is nothing inherently uncool about Handles in their http URI form (i.e. as shown in your example). The problem lies in the way they function in usability terms in current browsers. Basically, they are not in the location bar at the point where bookmarking takes place and therefore the 'wrong' URL gets bookmarked.

[Les carr]

I have posted a response to Andy's helpful crit on my blog at
http://repositoryman.blogspot.com/2009/02/eprints-evaluation-assessing-usability.html

@talat some EPrints repository managers choose to coin DOIs for their eprint records, but no, EPrints per se doesn't automatically use specific persistent URL schemes in it repositories. Our take on this issue is that fly-by-night URLs are a policy issue that technology doesn't solve. The reason that Cool URIs don't change is because they are issued by Cool Web Managers. And if your web management isn't responsible and professional about information management then it is just as likely to foul up a handle as a URL.

@chris don't waste too much sorrow on your choice of domain name. It's always wrong. Call it research.sussex and in 2 years your institution will start putting teaching resources in it as well.

@chris Coins is very disappointing. It doesn't have sufficient metadata to give a useful bibliographic transfer. Zotero works pretty well on standard EPrints pages - at least it did on the ones I tried.

@andy Any chance of an educause repository interoperability standard? Certification for those repositories that support Google + Feed Reader + Yahoo Pipes + Zotero + Slideshare + Delicious +
whatever? Give us all something practical to aim for. You just tell us what the Practical Powell Portfolio is :-)