The budget for the project is illustrated in the following figure. As can be seen the major part of the £39,905 will be spent on staffing to achieve the results of this project. The remainder will cover fixed costs with a small amount to cover a workshop at the end of the project and attendance of meetings during the project.
Archive for July, 2011
Because we have the original code used to create and package services in the desktop application, the level of risk in migrating to a web based system is greatly reduced. The fundamental focus of our development plan is to extract this service packaging code from our desktop application and deploy it as a server-side component in one of our application servers. The role of the web UI then becomes one of document management and editing – a scenario for which a great many open source tools and components already exist. The project will be undertaken by existing members of staff this removes the time necessary to recruit new staff and bring them up to speed.
The project is sub-divided into five work packages outlined below. There interactions are illustrated in the figure below and then timelines presented in the figure after that.
WP1: Analysis of current system
1a) User Trials: Trials of the current software system, both as part of this project and from previous work will be used to analyse the key requirements for this project.
1b) Analysis of interface (4 people)
WP2: Server Side Design and Implementation
2a) Evaluation of Tools for server side
2b) Design of server side
2c) Development of server side implementation
WP3: Client Side User Interface
3a) Design of Client Side User Interface
3b) Development of ‘novice’ User Interface
3c) Development of ‘expert’ User Interface
WP4: Usability Assessment
4a) Month 0 Assessment (4 people)
4b) Month 3 Assessment (6 people)
4c) Month 5 Assessment (8 people)
5a) e-Science Central Workshop focused on developing your own workflow blocks
The interaction of these WPs can be seen in the following figure:
The timelines for this are illustrated in the following Gantt chart:
The project will follow an agile development model with the key deliverables being direct consequences of the outputs from tasks T2.3, T3.2, T3.3 with all other tasks either aiding these tasks or dissemination.
The team of people who are working on this are:
Hugo Hiden is one of the developers of e-Science Central. With a background in Chemistry and a PhD in Computing Science Hugo is well placed to understand the needs of the user.
Stephen McGough is the PI for the project and has experience in working in many large scale e-Science projects where presenting computational ideas to users requires carefully crafted interfaces.
Patrick Olivier is a professor of HCI at Newcastle with a keen interest in user interfaces.
Paul Watson is a professor at Newcastle and is the lead in the e-Science Central project.
Simon Woodman is one of the developers of e-Science Central. With a background in data management and workflow enactment Simon is well placed to develop core infrastructure for this project.
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.