Erevnametrics: Research Object Builder User Feedback

So, for the first time, I gave the RO Builder some real live testing, and here I’ll discuss some of the difficulties encountered during this. Generally the problems encountered can be divided into conceptual limitations, or bugfixes and minor features that ought to be added, the conceptual problems are what’s interesting here.

To begin with, our user decided to create a RDF representation of his PhD. The way he went about this is he added himself, and then searched for the papers he had written, which were hosted on a number of different sites, and then for other components of his PhD. This is different to how I had assumed the tool would be used, in that I had (foolishly) assumed that people would have all their papers in one place, or know where to find them. Furthermore, some difficulty was encountered as it wasn’t obvious what a bnode actually was, or when to use them.

From these two initial problems, a couple more arose: as papers may be spread out, many sites must be supported. To support a large amount of different sites, if a generic solution cannot be made (and there are several reasons why it might not be possible), then we may end up with a large amount of shims, and this would quickly become unusable – or at the very least, unpleasant to use. To resolve this, a couple of changes to how the shims are handled and selected could be implemented: At the beginning, the user merely selects a type (Person, Article, AVdoc … None of the above), and then the tool tries to either treat it generally (easy for links that point straight to RDF, and well constructed HTML) or tries to match it to a specific shim (e.g. if the URI given starts with arxiv.org, it’s safe to assume that it’s a link to an arxiv article, thus use the arxiv shim), and if those methods fail, or a nonsensical answer is returned, then ask the user to try and select a shim. A simpler solution might be to keep the current system of having the user select a shim each time, but reorganise the interface such that the shims are better organised, and easier to find / select, this would likely take up much more space on the tool, and still not be as pleasing for the user as the first solution though.

To ensure people use parts of the tool for the correct reasons, a concise, user-targeted, expandable glossary, or something of the sort, at the top of the tool should help. Due to the fact that people may not know exactly where their resources are, some form of search integration would be helpful, e.g. a wrapper for Google Scholar that allows you to search and then import results of the search directly into the tool.

Most of the other comments and things were little bugs or features which didn’t really represent any conceptual change: It would be good to easier support copying/saving the generated RDF, it would be good to support inline renaming of resources, it would be good to support deletion of resources / relations after they have been added, it would be good to allow users to reorder resources and relations by simply drag/dropping their resource boxes. These features are all good examples of things that really ought to be in the tool (and most will be added shortly) but are things that simply got overlooked in the design process.

The final point here is that this RO Builder is not actually something that specifically builds Research Objects; at the moment, it creates a more general user-defined RDF construct – it might be useful to automatically have a bnode for the particular object that the session creates, and then automatically link all added resources to this: this was a process that happened manually in our user test, and it was both time consuming and unclear that it had to happen. To remedy this I think I will add an option (with description at the top) which will allow a user to toggle using a central object, with all other objects in the builder as parts of this object (of course, with relations that are editable in the relations section).