e-Science Central Online Editorhttps://escoe.wordpress.com
Usability improvements to the e-Science Central SDKMon, 19 Mar 2018 04:57:48 +0000enhourly1http://wordpress.com/https://s2.wp.com/i/buttonw-com.pnge-Science Central Online Editorhttps://escoe.wordpress.com
Lessons Learnedhttps://escoe.wordpress.com/2012/03/09/lessons-learned/
https://escoe.wordpress.com/2012/03/09/lessons-learned/#respondFri, 09 Mar 2012 13:27:46 +0000http://escoe.wordpress.com/?p=38Although the project has been a success there were a number of issues that made the project more difficult than originally perceived. These can be broken down into the following broad categories: HCI techniques, personal time and technical.

HCI Techniques: Although we did have a HCI expert on the advisory side for this project this person was overloaded with other tasks and was only able to provide minimal input into the project. This meant that certain techniques such as personas; Focus groups or task-based evaluation was only discovered at a late stage in the project.

Personal time: It turned out to be far harder than expected to obtain time with researchers using e-SC than expected. The original plan had been to hold a workshop in which users could provide input as to how we could improve the SDK. However, as it was almost impossible to get all people together in the same place at the same time we eventually had to change this to one-on-one discussions with users of different abilities. In future work we would seek to hold one-to-one interviews to develop personas rather than attempt a full workshop.

Technical: A number of technical issues caused problems during the project. The variation between Web Browsers plagued us during the project meaning that significant amounts of time were used to ensure that layouts and styles worked across platforms. On completion the wizard tool dropping the user into the expert view at the end, which was not the original intention. Users, however, saw this as a benefit, and as such we decided to keep this as part of the design.

In general we feel that this project not only allowed us to develop a better SDK for e-SC but also helped us to discover the merits and techniques required for improving usability and learnability. Something that we will now be applying over the rest of e-SC.

Advertisements

]]>https://escoe.wordpress.com/2012/03/09/lessons-learned/feed/0stevemcgoughSuccess?https://escoe.wordpress.com/2012/03/09/success/
https://escoe.wordpress.com/2012/03/09/success/#respondFri, 09 Mar 2012 13:26:32 +0000http://escoe.wordpress.com/?p=36The project has been a great success based on the original goals of replacing the original SDK with a new integrated online tool as part of the rest of e-SC. This we feel has increased the usability of the SDK significantly. Before this work the development of new blocks for e-SC normally required intervention from the original development team to set up the SDK for the user and then work with them for the development of new blocks. Changes to the core of e-SC and network issues regularly broke the SDK and required further intervention, which often decreased the chances that users would pursue the use of e-SC.

In terms of the learnability of the new SDK, the introduction of the wizard support has greatly reduced the barrier to entry for this work. Allowing users to progress with less need to have significant support from the e-SC development team.

As the development of this new SDK was such a step-change from the original SDK it was difficult to derive quantitative metrics to mark its success. Such metrics could only be defined in terms of the number of users who develop their own blocks or the reduction in help requests for block development. In the short scale of the project this was not possible to observe, especially as the new SDK was only available towards the end of the project. However, more qualitative results have been possible by demonstrating the new SDK to users of the original SDK and those whom we surveyed originally about the SDK. The feedback about the new SDK was very positive.

Advertisements

]]>https://escoe.wordpress.com/2012/03/09/success/feed/0stevemcgoughRecaphttps://escoe.wordpress.com/2012/03/09/recap/
https://escoe.wordpress.com/2012/03/09/recap/#respondFri, 09 Mar 2012 13:25:33 +0000http://escoe.wordpress.com/?p=34The intention of this project was to remove the main drawback with e-Science Central (e-SC) – the fact that the Software Development Kit for integrating new workflow blocks into the system was still an independent stand-alone application with a completely different user interface to the rest of e-SC. The rest of e-SC is provided as an online (Web 2.0) style application in which the user requires nothing locally installed other than a Web browser. This was in contrast to the SDK which presented a different Java based GUI containing large amounts of superfluous information and options (only applicable to the developers of the SDK) such as deep hierarchical tree structures for where elements needed to be placed.

To use the SDK created a steep learning curve for any potential user, as they would first need to install a number of software dependencies, including Java and Maven, before they could install the SDK. This was further complicated as updates to the core e-SC software base would often require equivalent updates to the SDK. Communication between the SDK and the core e-SC often failed due to networking problems and proxy issues. We were also aware that a number of users preferred to develop their code in their own IDE before importing it into e-SC as a workflow block.

The new SDK has been developed as part of the online e-SC Web based application. This has immediately removed the need for local software installation, software versioning issues and network issues. The presentation style of the new SDK is now more in fitting with the style of the rest of the e-SC application. All of these help reduce the learning curve for a user who wishes to move from developing workflows with pre-defined blocks to developing their own blocks.

The SDK now supports two usage modes those of expert and wizard support. The expert user interface allows access to all of the features that a user needs to have access to in order to import pre-developed code as a block within e-SC. The wizard support interface guides a user through a set of screens allowing a less experienced programmer to install a new workflow block within e-SC. On completion of the wizard the user is dropped into the expert mode where they can either save the new block or tweak the block before saving. Although this was not the original intention, though after showing the new SDK to the existing user base it was decided to keep this as it was felt that it allowed more of a transition from using the wizard to using the expert mode.

Documentation for using the new SDK has been developed though as the coding of the new SDK took more effort than expected the integration of the help information into the SDK – providing interactive help – was not completed during the project. This will be added at a later date.

Advertisements

]]>https://escoe.wordpress.com/2012/03/09/recap/feed/0stevemcgoughBudgethttps://escoe.wordpress.com/2011/07/28/budget/
https://escoe.wordpress.com/2011/07/28/budget/#respondThu, 28 Jul 2011 16:13:28 +0000http://escoe.wordpress.com/?p=30The 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.

Budget

Advertisements

]]>https://escoe.wordpress.com/2011/07/28/budget/feed/0stevemcgoughbudgetRiskhttps://escoe.wordpress.com/2011/07/28/risk/
https://escoe.wordpress.com/2011/07/28/risk/#commentsThu, 28 Jul 2011 16:10:54 +0000http://escoe.wordpress.com/?p=28Because 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.

Advertisements

]]>https://escoe.wordpress.com/2011/07/28/risk/feed/1stevemcgoughTimeline and work packageshttps://escoe.wordpress.com/2011/07/28/timeline-and-work-packages/
https://escoe.wordpress.com/2011/07/28/timeline-and-work-packages/#respondThu, 28 Jul 2011 16:09:48 +0000http://escoe.wordpress.com/?p=23The 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.

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.

Advertisements

]]>https://escoe.wordpress.com/2011/07/28/timeline-and-work-packages/feed/0stevemcgoughflowGanttProject Teamhttps://escoe.wordpress.com/2011/07/28/project-team/
https://escoe.wordpress.com/2011/07/28/project-team/#respondThu, 28 Jul 2011 16:00:24 +0000http://escoe.wordpress.com/?p=20The 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.

Advertisements

]]>https://escoe.wordpress.com/2011/07/28/project-team/feed/0stevemcgoughImproving the Usability and Learnability of the e-Science Central Service Development Kithttps://escoe.wordpress.com/2011/07/21/improving-the-usability-and-learnability-of-the-e-science-central-service-development-kit/
https://escoe.wordpress.com/2011/07/21/improving-the-usability-and-learnability-of-the-e-science-central-service-development-kit/#respondThu, 21 Jul 2011 09:10:47 +0000http://escoe.wordpress.com/?p=12e-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.