DUE TO SEVERE COMMENT SPAM ON THIS POST I HAVE CLOSED IT TO COMMENTS
On February 28/29 we held a workshop on our Blog Based notebook system at the Cosener’s House in Abingdon, Oxfordshire. This was a small workshop with 13 people including biochemists (from Southampton, Cardiff, and RAL), social scientists (from Oxford Internet Institute and Computing Laboratory), developers from the MyGrid and MyExperiment family and members of the the Blog development team. The purpose of the workshop was to try and identify both the key problems that need to be addressed in the next version of the Blog Based notebook system and also to ask the question ‘Does this system deliver functionality that people want’. Another aim was to identify specific ways in which we could interact with MyExperiment to deliver enhanced functionality for us as well as new members for MyExperiment.
Perhaps the most unexpected thing to come out of the workshop was a possible name. Duncan Hull coined the term LaBlogs (I think I prefer LaBLog or perhaps LaBLoG but we can quibble about capitalisation later) which I think captures much of what we are doing (as well as perhaps pointing out what we are not doing).
Technical and Interface Issues.
Going into the workshop we knew we did not have a production system. In terms of startup time, functionality, and user interfaces there remain significant issues that need to be fixed. Some of the expected ones came up; particularly that users do not want to interact with a markup language. User interface is a key issue and a general problem for Blogs and Wikis. The fundamental problem, as I have mentioned before, is tables. These are a good way of collating information about procedures, particularly in biochemistry/molecular biology and markup for tables is awful to have to deal with. A full featured graphical interface really is a requirement here before people will buy into this. The markup isn’t hard to learn, and can even in some cases be more efficient to get into the system, but it creates a real barrier for people to get over. For many people it will be one barrier too many. There were many specific UI issues raised and I made some notes here. A particularly good suggestion was that hovering over links should get you more information, perhaps a small version of the page, about the linked post.
The other key issue we knew about was the problem we create by applying our ‘one item one post‘ approach; lots of posts that currently need to be manually created. However people were encouraged by the fact that by doing this you get catalogues of your materials as an added bonus for no extra costs (more on that later). One suprise when we started to try to input peoples experiments into the system was just how long it takes to get set up. I knew this would be an issue but we’ve never done this from scratch before, and certainly not for three groups simultaneously, so this was a new experience. A good suggestion was that there is a need for tutorials on how to set up the system and how to prepare templates etc. Also a repository of templates would be useful.
Is the overall design concept useful?
The one item-one post system is intended to provide a more information rich framework which is potentially machine readable, while avoiding the pitfalls of a semantically aware system, or a relational database. As we have discussed in a number of places, this has potential disadvantages, not least that it requires more posts. What was interesting was that several of the workshop attendees realised independently that the system gives you a catalogue of materials more or less automatically (as long as your metadata is well organised). This is really encouraging as it means that there is some readily available added value gained for the extra work that goes in. Having thought some more about this I think there is real additional potential for this and I will write about it separately. Overall I took home the feeling that the extra work is worth the effort.
Potential interactions with MyExperiment/Taverna workflows
We have known for some time that the manual posting process is unsustainable even when relatively small numbers of products or data files are being generated. What we hadn’t thought about was that, although in many ways a toy example, the automation of posting is something that can be captured well within a workflow, as long as the Blog has an API. In fact for many of the interface issues it may well be possible, or even better, to handle anything to do with automation with external services. Certainly, once it is possible to execute Taverna workflows from within MyExperiment this will be very powerful. Sophisticated systems can be setup, shared, and tweaked for individual users. A key requirement for achieving really powerful tools like this will be making the workflows configurable though a visual editor rather than the current workbench but within the current framework we can make significant advances.
So the first potential area to link up was simply to have a workflow that generates replicate posts. The first implementation of this could be a simple loop that allows the user to input a title with a variable marker, some text with the same placeholder, and then goes away and generates the posts. A slightly more sophisticated version would poll the blog so the user can choose which post the new ones should be linked to and ultimately it would be nice to automate a file upload process as well. But, for relatively little work, we can solve one of our major current problems.
A couple of other proposals were drawn up, including the quite adventuous notion of trying to abstract out of the Blog a workflow, that could then be automatically created and shared on MyExperiment. I will go through the details of some of these ideas at a later date.
Key Priorities
The requirements for development that came out of the workshop can be divided into two main categories. Small things we can get to work on straight away and big things, where we either need serious funding, or we need other developments (e.g better visual editors for Blogs and Wikis) to catch up so that they can be integrated.
They key short term goals are:
- API for the Blog
- Automation of multiple posting
- Lots of tweaks to UI, some may be more practical in the short term than others.
- Using MyExperiment/Taverna to automate data analysis
In the longer term we need:
- Complete re-write of system, ideally with integration into widely used Blog or Wiki framework
- Multiple different views for processing the underlying data in different ways (logging in compounds, network views of posts, user configurable RSS feeds)
- Integration and data portability between systems, is it possible to abstract a workflow from a set of posts, and then to use that as the basis for a protocol to be published e.g. to OpenWetWare
My notes from the end of the workshop.
Duncan Hull’s notes from the first afternoon of the workshop.