e-Science Central is a widely used tool by e-scientists allowing them store, exchange and manipulate data in a secure environment. A single web portal is provided allowing access to (almost) all of the functionality, the one exception being the Service Development Kit (SDK), which still requires the user to download a desktop application. The aim of this project is to address this restriction by porting this SDK to a web portal and providing a more useable and learnable interface.
The overall goal of this project is to bring the e-Science Central Service Development Kit (SDK) into alignment with, hopefully surpassing, the usability of the rest of the e-Science Central. e-Science Central provides a web-based access model for users to collect, analyze and exchange data with collaborators which can be used from anywhere in a secure manner. Users are provided with a single web portal view of all their data and analysis which allows them to upload data to the system, annotate it, analyze it and make it available to other uses of the system using a social networking metaphor. Analysis is achieved by building workflows of blocks, which interact to achieve the desired analysis.
At present although the workflow itself can be developed within the web portal it is not possible to add new workflow blocks (services) into the system without using an application which needs to be installed on the users own computer. This is a significant bottleneck to the usability of the overall architecture, often requiring users to seek support from the e-Science Central developers to deploy new blocks.
In essence the measures of success for this work will be the ability for a non-experienced user to take some existing code that they have and deploy this as a new workflow block within e-Science Central. Both a simplified interface and an expert interface will be provided for this purpose, allowing most users with a simple method for deployment whilst more experienced users can take advantage of the power of e-Science Central.
This improvement for e-Science Central was seen as the best performance improver as it removes a significant bottleneck which users have requested in the past and also moves the whole of e-Science Central to the next level of usability by removing the last link with the installed desktop environment.
In order to achieve the goal of this project the development of the workflow block building tool needs to be developed in a manner which is usable and learnable and in-keeping with the user interface style of the rest of e-Science Central.
The baseline for current user performance of this part of e-Science Central will be determined through interviews of existing users who have attempted to use the current tooling and their experiences of the tool.
The success of this intervention will be measured in two ways. First, the ability of users to develop new workflow blocks without the need for external support (excluding online documentation), second user views of the new tooling will be captured through structured interviews to determine if the new intervention meets the user needs. This will be assessed at two stages during the project at both month 3 and month 5. The analysis at month 3 will be to determine if our approach is better and how we can improve it before the end of the project, whilst the analysis at month 5 will be to assess the achievement of the project along with ‘small’ improvements, which can be made before the project, ends.
We see this as the most appropriate method for achieving this level of functionality for our user base as it provides a scalable solution to the problem along with a low impact for both the user and the developer of e-Science Central. Alternatively we could have packaged up the current SDK into an auto-install process and attempted to provide a more usable interface to this tool. However, this would have lead to a barrier in usability for the user as the installed application would not look or feel the same as the rest of e-Science Central. It would also cause significant development issues to support all the different user environments. Another alternative would have been to integrate the SDK within an existing IDE used by many of our users. The main drawbacks with this approach are due to the different interface that would be presented to the user, producing a significant learnability curve, and the selecting an IDE that all users would be familiar with. We would end up providing an interface that some users could easily associate with whilst others would be completely lost. Maintaining such an interface, with the development of the underlying IDE, would require constant development effort.