Page completed and frozen

Note that detailed notes exist on private pages at UserEvaluation (project team only).

This provides a user's perspective on the Bridges Portal created by NeSC, see NeSC_Shibbolized_Resources.

Interview

In February 2006 Alun Edwards (ESP-GRID) interviewed one user of the BRIDGES web portal, Dr. David P. Leader, Senior Lecturer, Biochemistry and Molecular Biology, University of Glasgow. We would like to thank Dr Leader for his contribution to our project. Alun emailed a set of more than 35 questions to Dr Leader, and then telephoned him to record his response to these. The questions were designed to enable the project to understand how Dr Leader uses the Bridges web portal (the interface that has been created at NeSC for users like him to access grid resources in his field of study). However, the primary focus of many of the questions was about the user's experience in accessing the Bridges portal. E.g. does he use a digital certificate to gain access? Does he use a username and password? For users like him what issues can be imagined relating to access to the Bridges Portal?

This was not intended to be a structured-formal interview and some questions were skipped over (already answered), as well as questions being introduced (as they cropped up during our conversation). So although the list emailed before served as a prompt, the discussion ranged around these questions for about one hour. With Dr Leader's permission the conversation was recorded.

Dr Leader's contact details were confirmed at http://doolittle.ibls.gla.ac.uk/leader. He has used the BRIDGES portlet to access BLAST software to interrogate a multitude of genomic data sources including ensembl (rat, mouse, human), MGI, HUGO, OMIM, RGD.

Research

To assist his colleagues Dr Leader writes computer programs (in PERL) which allow scientists to work on genome profiles (such as the human genome project, or certain bacteria which include pathogens responsible for causes of disease etc.) The programs allow the scientist to see data from a genome project, essentially a visualisation of the data (i.e. a graphical presentation) which they are then able to navigate. For the BRIDGES project he used the BLAST service via the portal for the same work. Although the BLAST script was not written by him it was written in close consultation with him.

The search for similarities or differences of interest between one protein and another or one compared with 2,000-4,000 proteins, or even comparing 4,000 proteins in a particular 'bug' might take more than 1 hour on a stand-alone Unix box. The Unix-box is an unattractive alternative to using the grid via the BRIDGES portal. There would be a real disincentive for the average scientist (biologist) to use the Unix-box solution, e.g. for a start they would have to write the PERL script themselves, or find someone to do it. Using the BRIDGES portal to access the grid means that results may be returned in less than 5-10 minutes. As the same results might take 60+ minutes this demonstrates why there is a need to use the capacity of computing power offered by the grid for the research undertaken by his colleagues.

Dr Leader is not an experienced grid user, in fact he has never used the grid other than through the BRIDGES portal. His first contact with the grid was in 2005, in response to the work with the NeSC team and the BRIDGES project. Since then he has used the portal about 8 times, to assist with the technical/user interface developments. (For those 8 occasions he has never failed to access the BRIDGES portal.)

Using the portal interface

For his colleagues Dr Leader has addressed some usability issues associated with access to the grid via the BRIDGES portal in a document due for publication: BugView: A Tool for Genome Visualization and Comparison by David P. Leader (Word document 100k to download). The author confirms it has not been published yet (as at 18 May 2006). This primarily guides the user through the interface and covers how to find the link to login, for example. In terms of his own use of the portal Dr Leader very confidently and accurately described the steps and processes involved for the user trying to access the BRIDGES portal, from the point where he opens his Internet browser. Not surprising, seeing as Dr Leader has been contributing text for user orientation! However, the process of user registration has not been explained to him, so he does not know how his users e.g. in Glasgow, or in MIT (USA), or whereever, will register to gain access to the portal. Therefore our interview did not explore further any issues relating to authorisation or authentication. Dr Leader did think though that the on-screen assistance and print documentation available on the portal was sufficient for him and for his 'less-technically' proficient colleagues.

Type of grid user

Just to re-iterate, as Dr Leader has never used the grid before this project he is not in a position to explain how access via the portal is a different user-experience from how one might previously have accessed the grid e.g. Internet browser or command line entries, username and password or digital certificates, remote access to the grid and via the portal. However Dr Leader did provide his observations which compared the performance of the portal against the stand-alone Unix-box approach. e.g. he has noticed no difference in the time taken for jobs to commence so there is no significant delay from using a resource which is not directly under his control, but results are returned via the BRIDGES portal significantly faster than via the Unix-box.

We discussed the different user types for a 'future-grid' (see ESP-GRID's UseCasesPaper) and we agreed that Dr Leader is a "user requiring specific grid resource nodes". He agrees with ESP-GRID's suggestions of a typical user that will develop programs and data but does not care where processing takes place. He has the platform etc. dependent expertise and some sysadmin expertise. He does have a more direct relationship with the owner of a specific grid node. Although this almost matches the project's suggestion of a "power-user requiring specific grid resource nodes" the power-user of the grid is not relevant. All other attributes apply, but power-user was a real sticking-point.

Dr Leader explained that his colleagues/students would almost all be classed as end-users of services provided by another party involved in the grid, (ESP-GRID: typically you will have little or no computer programming expertise, you rely upon a service provider in a kind-of customer-service relationship. An end-user is agnostic as to whether a grid is being used to assist them in their research.). Although one of Dr Leader's students did once make use of the standalone Unix-box solution this is just one example in all his teaching experience. Dr Leader explains that "Biology is not a mathematical science and seems therefore not to find that level of technical [computing] expertise in-house. Even large expensive groups of European or US biologists will out-source this expertise from the bioinformatics community."

Some technical issues

Dr Leader accesses the BRIDGES portal only from his desktop computer ¹] at work, but occasionally he has accessed it from his Mac at home. Although the portal provides access to a standard tool that his colleagues rely on for their research Dr Leader anticipates that they would not be tempted to check results from anywhere other than the lab/office. Dr Leader considers his use of the computer at home for research is unusual amongst his 'less-technically proficient' colleagues. During the interview we discussed issues related with accessing the BRIDGES portal from a computer other than the work desktop machine. For example:

• broadband access and bandwidth is essentially irrelevant for the submission and delivery of the jobs, as although the data returned is more than 5-10 Mb in size Dr Leader runs a parser to remove the redundant data irrelevant to the specific needs of the scientist. The result delivered then is about 50-100k of data.

Guest book entry

As well as checking if a user would recommend the service the ESP-GRID project wanted him/her to complete a guest-book entry in the hope it would generate an interesting response. The comment would be something they would like readers of the 'guest-book' (other users and the developers) to know about. E.g. would he leave a request for technical support or a request for additional information or a comment about the BRIDGES project and/or its products? Or would he leave feedback about the website of the portal itself? Here is Dr Leader's audio-guest-book entry, any errors are the fault of the transcriber:

• The grid saves time but some annoying things - just the nature of the beast, e.g. Megabytes of output file for the parser to pick up but it does not supply the unique identifier of the genome (a 'RefSeq number') so the user has to find this number themselves in the number before the data is of use. Not an indication of the grid failing, rather wanted the process to be improved when the BLAST program was created, but it was not done for resource reasons.

  Also, on one occasion I submitted a job but the resource was down and there was no indication that the job was not running!

This final point is one which the BRIDGES portal developers have been aware of - possibly after Dr Leader's experiences.

Recommending the service to colleagues

Dr Leader could not see a reason for secrecy for the University user at least (i.e. the portal might be used in an open situation like a library computer or a lecture room). Obviously strictly restricted access would be relevant in a different research setting such as in a private company. Dr Leader would like to see wider access being made available (less restrictions, less access control) as he wants more people to use his program. He is aware of 6+ users of his BLAST script, and has briefly glanced at the logs. He has also received some feedback requesting technical fixes. So there is a small take-up of his program via the portal. Dr Leader answered the question "Would you recommend accessing the grid via the Bridges portal to a colleague?" with a resounding "Yes". His work to publish a usability guide for his colleagues shows his pro-active support of the portal. From this and from other questions the ESP-GRID project was pleased to note that our sample of one user wants a research tool (e.g. a Web-based application where you can upload queries/questions to receive data for your research), the user does not want more security.