Microsoft Word - Final2.doc Biodiversity Informatics, 4, 2007, pp. 27-36 ONLINE BIODIVERSITY RESOURCES – PRINCIPLES FOR USABILITY S. H. NEALE, M. R. PULLAN AND M. F. WATSON Royal Botanic Garden Edinburgh, 20A Inverleith Row, Edinburgh, EH3 5LR U.K. S.Neale@rbge.org.uk Abstract.—Online biodiversity portals and databases enabling access to large volumes of biological information represent a potentially extensive set of resources for a variety of user groups. However, in order for these resources to live up to their promise they need to be demonstrably useful to the communities they are intended to serve. We discuss a number of principles that can be applied to portal development that assist in defining the scope of user communities, determining their requirements within the context of the data available and establishing realistic goals for a portal or portal development tools. We highlight a lack of user involvement and formalised requirements analysis in biodiversity portal projects to date, and compare this with a similar project in the Astrophysics community. It is concluded that the poor understanding of both the users and their tasks that arises from this lack of analysis makes it difficult to assess the success of a portal and increases the risk of the portal being judged to have failed. We suggest that a change in the way large biodiversity portal projects are managed, presented and funded could lead to an increased perception of success with minimal change in the underlying infrastructure, yet enhancing the life expectancy of such projects. Key words.—portal, user interface, requirements analysis, end-users Online portals enabling access to biodiversity information are intended to increase both the amount of, and ease of access to data, and are claimed to have potential value for a great variety of users. They are intended to facilitate the investigation of complex biological questions and to allow researchers to develop new insights through the agglomeration of large data sets and provide access to appropriate analytical tools. For example, it has been reported that studies of the effect of climate change on flora and fauna (e.g., Root et al. 2003, Parmesan and Yohe 2003) and the identification of priority areas for conservation (e.g. Williams et al. 1996) will be enhanced through access to larger integrated datasets. Biodiversity portals may also hold the potential for enabling better informed planning and policy decisions (Sánchez-Cordero and Martínez-Meyer 2000, Jones and Thornton 2003, Peterson and Shaw 2003). However, it is easy to overlook the risks involved with the development of such resources. A major study of over 8000 software development projects found that only 16% were considered successful in that they were completed on time, within budget and with all the features and functions as originally specified (Standish Group 1994). A more recent study indicates that this situation is improving but still only 29% of projects are considered successful (Standish Group 2006). The major factors responsible for this were found to be inadequate capture of user requirements and insufficient user involvement. There is no reason to believe that the development of biodiversity portals should be considered as being different from other software development projects. Poorly designed biodiversity portals are just as likely to be perceived as having failed and to remain under-utilised. In this paper we therefore aim to investigate the extent to which a set of well known user–oriented principles for designing successful systems have been applied to the development of online biodiversity information resources, and suggest ways in which such projects could be better managed and presented so as to enhance their chances of success. USER-ORIENTED SOFTWARE DESIGN PRINCIPLES A large body of research exists within a set of overlapping disciplines (e.g. Human Computer Interaction, Requirements Engineering and Usability Engineering) which discusses principles and methods of elucidating end-user requirements and incorporating them into design. Although portal development is a relatively new phenomenon, many of these ideas and techniques still apply (Waloszek 2001, Zazelenchuk and Boling 2003). The ultimate aim of understanding end-users and their requirements is to develop a product that is both useful and usable, the combination of which determine the usability of a system (Löwgren 1995). The International Organisation NEALE ET AL. – ONLINE BIODIVERSITY RESOURCES – PRINCIPLES FOR USABILITY 28 for Standardisation (ISO) has provided the following definition of usability: “The extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.” (ISO 1998). The basic concept of usability has been used as the basis for establishing a set of principles that can guide a user-oriented design process (Gould and Lewis 1985, Hewett and Meadow 1986, Gould et al. 1991, Mulligan et al. 1991). Whilst these principles, outlined below, appear rather intuitive they nevertheless provide a logical path through the design process. Unfortunately they are not frequently applied to product development (Gould et al. 1991, Kujala et al. 2001). Early and continued focus on users and tasks The involvement of users in portal development, including obtaining an understanding the tasks that they undertake and how these can be supported, is clearly important for the development of usable resources. Indeed, users have been shown to be more satisfied with software design arising from thorough requirements analysis (Kujala and Mäntylä 2000; Kujala 2002), and lack of user input has been cited as one of the major reasons for the failure of software development (Standish Group 1994). Various techniques for acquiring this type of information have been discussed in Goguen and Linde (1993). Empirical design Early on in the development process potential users should be exposed to simulations and prototypes and asked to carry out tasks using the prototypes. The reactions, comments and performance should be observed and measured in order to identify problems and errors. Feedback can then be incorporated into the design relatively easily, and improvements made before a project is committed to a full implementation. Iterative design Once user testing has been carried out using a simulation or prototype, improvements should be made and the product re-tested on the prototypes before full implementation begins. As much as possible the iterative phase of design should be confined to prototypes. MEASURING THE SUCCESS OF A PROJECT Ascertaining a measure of the success or failure of a project is not an exact science and depends largely upon the subjective assessment by its users. Nevertheless, once a project design has been implemented it is important that the degree of success is measured since this will help to inform future developments. The success or effectiveness of commercial portals is usually measured in terms of user acquisition and retention (Clarke and Flaherty 2003). There are, however, a number of alternative ways in which success can be measured: Achievement of requirements/goals set by project This involves identifying and describing user tasks that will be supported by a portal and using the results to establish a set of system requirements and deliverables prior to undertaking any development. The progress and success of a project can then be measured against this list of targets. Usability tests These measure the usability of a portal by asking a number of users to complete a particular task and measuring their response. This is distinct from the iteration process, as described above in that it is carried out on the final product and should not be considered as part of the design process. Nevertheless the results of such tests can be used to inform the design of future versions of the software. Extent of uptake and use by potential end-user groups Although this is the most commonly utilised method of measuring success (usually because it is easy to gather the necessary data) establishing a meaningful measure of success using this method is not straightforward. Firstly, the number of potential end-users is clearly variable between portals, depending on the number and size of different user groups to be served. To overcome this it is possible to consider the number of users of a portal as a proportion of the potential number of users. This of course requires that a sensible assessment of the potential end-user base has been established during the design phase. Feedback This is a passive and therefore easy to implement mechanism for obtaining information regarding the success or failure of the project. Reliance on this mechanism is, however, likely to be less informative than the other three mechanisms. Users are only likely to comment on negative aspects of a system although failure to NEALE ET AL. – ONLINE BIODIVERSITY RESOURCES – PRINCIPLES FOR USABILITY 29 receive any feedback is as likely to indicate user dissatisfaction as it is to indicate success. An important point to note here is that the ability to measure and demonstrate the success of a project is highly dependent upon a thorough and appropriate initial design and the documentation thereof. In effect appropriate early design provides the context within which an entire project can be managed. ASTROGRID: A PORTAL FOR THE ASTROPHYSICS COMMUNITY – A ‘MODEL’ EXAMPLE OF PORTAL DEVELOPMENT We consider this project to represent a very good model of the way the development of an information portal can be managed. We will therefore use it to set the baseline against which biodiversity projects can be measured. AstroGrid is a £10M project funded by UK's Particle Physics & Astronomy Research Council (PPARC) and the European Commission. It is aimed at building a working virtual observatory for UK and international astronomers, and is one of three large world-wide virtual observatory projects (The Astrogrid Consortium 2002). The following sections examine the development of Astrogrid in the context of the user-oriented software development principles detailed in the previous section. THE DEVELOPMENT OF ASTROGRID Early and continuous focus on tasks and users At the start of this project, prior to any technical development, an extensive consultation exercise was undertaken. Contributions to this were made through a number of routes; from consortium members, from research carried out by the project scientists, from consultation of documents detailing the results of requirements surveys from other projects, calls for input from the wider community at academic meetings, online and in journals, as well as from visits to laboratories, all of which are clearly documented in publicly available project resources (The Astrogrid Consortium 2002). Through this exercise science problems that were of interest to the UK astronomical research community were identified. Ten of these problems were then selected as priority objectives for the project based on the breadth of end-users showing interest in each issue. Each science problem was then formally constructed as a use case, broken down to show a flow of events decomposed into tasks for each process and sub-process. The results of this analysis were made publicly available as a project resource. User input was maintained throughout the project through online testing, development workshops and an online forum. The use cases were used to define the project deliverables both generating measurable targets and maintaining a focus on the user tasks throughout development. In the Astrogrid2 project, user involvement has been taken a step further with the development of an innovative process whereby users suggest functions that they would like to see developed. A number of projects are selected on a quarterly basis and then delivered during the Astrogrid2 development cycle. The proposer of a new function becomes part of the development workgroup. The user community is therefore actively involved in dictating the direction of the development of the project thus creating a sense of community ownership. Empirical measurement and iterative design User testing of the portal was carried out online as new versions and functions became available. Potential end-users were actively signed up to conduct the testing and a three month cycle of development and testing was established for new functions. User workshops were held at the end of each iteration cycle. Measuring the success of Astrogrid A good indication that Astrogrid has been perceived as a success is that it has received £4M for a second phase. This perception of success is no doubt attributable to the fact that a set of clearly defined project goals and concomitant functional deliverables was established and documentary evidence of the accomplishment of those goals is readily available. Furthermore, as of 2005 the number of active users of Astrogrid was measured at 1000. Although this is not a large number it is nevertheless far in excess of their prediction (The Astrogrid Consortium 2002). COMPARING BIODIVERSITY PORTAL PROJECTS WITH ASTROGRID The Astrogrid project arose from a drive by the astrophysics community for resources to utilise and explore rapidly expanding astronomical datasets and the Astrogrid project advertises itself as a virtual astronomical observatory. At the broadest level this makes Astrogrid and many biodiversity portals directly comparable. Indeed it might even be helpful to regard biodiversity portals as virtual biodiversity observatories. NEALE ET AL. – ONLINE BIODIVERSITY RESOURCES – PRINCIPLES FOR USABILITY 30 When comparing biodiversity data portals with Astrogrid we have opted to take a broad brush approach. As such, this paper is not intending to provide a direct critique of individual portal developments which we would consider to be unfair. Rather it is aiming to draw out the common features and failings of biodiversity portal development in order to highlight where improvements could be made when future biodiversity portal developments are being initiated. Given the current existence of large biodiversity data portals, it could of course be considered that putting these arguments forward at this point would be a case of closing the stable door after the horse has bolted. This would, however, be a short-sighted position to take. GBIF is still under development and even now the data access portal is only being described as a prototype (GBIF 2006a). When moving towards full implementation it would be highly advantageous for them to take a closer look at their end-users and their requirements. There is also a continuous stream of new projects very similar in nature to GBIF being proposed and seeking funding. The EU funded EDIT programme is an example of a newly funded portal style project1. We also know of two other major biodiversity project proposals that are currently seeking funding, one concerned with the development of an archive for DNA Barcode data (M. Watson pers. comm.) and the other to create an on-line Encyclopaedia of Life (R. Hyam pers. comm.) all of which could no doubt benefit from undertaking a user-oriented design analysis. During the course of our research for this paper we have in large part concentrated on studying GBIF and BioCASE. However in order to more fully develop our arguments we have studied the available documentation from a wide range of biodiversity portal projects (AlgaeBase, BioCASE, BioCISE, CABI Species Fungorum, EMBL reptile database, ENHSIN, ENBI, ERMS, ETI-WBD, ETI-WTD, Fauna Europaea, FishBase, GBIF, SpeciesBank, ILDIS, LINNE, NatureServe, Natuurloket, NBN, Species 2000 Europa and WADSIS). We have also been able to garner considerable information from two recent reports on user requirements analysis in biodiversity portal projects in which the design processes for a wide range of projects were obtained directly from the portal developers (Neale et al. 2005, Schalk and Heitmans 2005). 1 http://www.e-taxonomy.eu/. It was during this process of information gathering that the first obvious contrast with Astrogrid was observed. For most of the biodiversity projects the level of publicly available documentation regarding requirements analysis and design strategies was so low as to be almost non-existent despite the fact that many of them had substantial online documentation. In contrast, from the outset the Astrogrid project appears to have been driven by well defined, clearly documented and publicly available user needs established early in the course of its development. Early and continuous focus on tasks and users The users of the larger biodiversity portals are potentially very diverse. This can make it difficult to accurately predict exactly who will use a service before it is operational and its use can be monitored (Kujala and Kauppinen 2004). As stated above the Astrogrid project overcame this difficulty by identifying the scientific questions to be addressed by the grid and thus the end-user community and the functional requirements become self-defining. No such specific context exists for biodiversity portals and therefore it is interesting to examine how the scope of these projects has been determined. For most projects it appears that a list of potential end-users was generated by brainstorming during preliminary design meetings (Neale et al. 2005). Often the participants in such meetings were either limited to the site developers or were expanded to include potential data providers. As a result, the lists of potential users generated often appear over-optimistic and represent more of a wish list than a realistic assessment of the potential user base. The brainstorming process of identifying potential users should only be considered a preliminary step towards a more fully fledged requirements analysis. Unfortunately it appears that the majority of biodiversity portals have stopped their initial requirements analysis at this point and moved straight onto technical design and implementation. Where evidence of requirements analysis has been published, the resulting analyses appear to have been rather unfocussed – providing no mapping between the tasks that the users wish to perform and the data and functions required to support those tasks (Calabuig et al. 2001; Larsen et al. 2004; Robinson 2005). A recent study for the BioCASE project served to highlight this problem (Neale and Pullan, 2005). One of the preliminary development tasks NEALE ET AL. – ONLINE BIODIVERSITY RESOURCES – PRINCIPLES FOR USABILITY 31 for BioCASE project was to establish a list of potential end-users. This was generated by a combination of brainstorming and by consolidating similar lists produced by other related projects (Neale et al. 2005). This final list of potential end-users covered 43 diverse user groups which were split into the following five categories: 1. Biological systematics and university research 2. Private research and industry 3. Public services and administration bodies 4. Commercial services 5. General public Immediately clear from this list was a probable decrease of interest in unit level information in favour of an increased interest in complex synthesised data from category one to category five of these user groups. The BioCASE portal provides access to unit level data, and is therefore clearly less likely to be of value to users as you move from category one to five. This was tested by attempting to match the data requirements of the potential users from each group with the data available and was achieved by conducting a series of face to face interviews with representatives of the groups. Without reference to the BioCASE portal, users were asked to identify the tasks and data required to support those tasks that they perform as part of their day to day work. Each task and its associated data were then ranked by the interviewee in order of importance. A mapping was then made between the data required for a task and the availability of that data in the portal. The results of this study reinforced the initial suspicion that the data accessible through the BioCASE portal was unlikely to directly satisfy the requirements of the non-taxonomic groups of potential users and that for future development of the BioCASE portal the interface design should concentrate on supporting the tasks most commonly undertaken by taxonomists and a more realistic set of objectives for the portal was established (Neale et al. 2005). The effectiveness of this effort was however compromised by the fact that the requirements analysis was conducted in parallel with the portal development and so by the time the analysis was complete a large proportion of the portal had already been built. Empirical measurement and iterative design Biodiversity projects appear to fair better in this area than they did with regard to their initial requirements analysis. Most of the biodiversity portal projects are iterative in the sense that new versions are released periodically, presumably incorporating elements of user feedback as and when deemed appropriate. However, compared with Astrogrid, the feedback mechanisms appear to be somewhat unmanaged. The most frequent mechanism for gathering this feedback was through the rather passive mechanisms of online discussion and comment (e.g. FishBase). In some cases more active means of obtaining feedback were established such as online surveys of invited participants (e.g., GBIF 2006b), conferences (e.g., ENBI 2003, GBIF 2005) and face-to-face user testing (e.g., Pendry 2004). Measuring the success of biodiversity portal projects In terms of the mechanisms for measuring success discussed earlier there was a lack evidence of either clear requirements goals or usability testing in the documentation of the projects examined. This lack of a structured framework and clear goals makes it very difficult to measure the success or progress of these projects. Although some do monitor the number of visitors and associated statistics, meaning that they could obtain an assessment of who is accessing their services and for what. It was, however, noted in an ENBI report that many online biodiversity resources do not take advantage of the ability to do this (Schalk and Heitmans 2005). DISCUSSION In this paper we have highlighted that during the initial development of many electronic biodiversity resources there appears to be a lack of adequate research into potential users and the tasks they are likely to want to perform. While there is undoubtedly a huge potential in these resources this lack of understanding represents a risk to their potential productivity, usefulness and perceived success. One possible reason for the lack of appropriate requirements analysis, aside from the fact that such analysis can be somewhat tedious and time consuming to undertake, is that when a project is funded it is taken as read that a definite requirement for the project has been established in the application for funding. If this were to be done properly, rather than simply relying on assertions, a full user requirements analysis would have had to be undertaken by the applicants prior to the application and at their own expense. Projects that incorporate elements of user analysis into the application risk being rejected on the basis that NEALE ET AL. – ONLINE BIODIVERSITY RESOURCES – PRINCIPLES FOR USABILITY 32 funding will not be granted to projects that can’t already demonstrate their usefulness, a classic Catch 22 situation. We would like to suggest a change in funding attitudes such that it is possible to apply for research money to properly establish the appropriate scope and probable usefulness of potentially interesting projects prior to application for full funding. This would not only reduce the risk of money being wasted on ‘white elephants’ but would provide the framework within which the success of a project could be measured were it to eventually receive full funding. In this vein a great deal can be learnt from the success of the Astrogrid project. Moreover, because funding bodies do not appear to value requirements analysis as part of the grant assessment process a perhaps unexpected consequence is that once a grant has been awarded there is no external pressure to perform such a study. We would therefore also suggest that funding bodies should start to consider user-oriented requirements analysis as being a fundamental part of their pre and post award assessment processes. This will not only ensure a greater level of attention to design during a project but will give the awarding body a far more objective framework within which to assess the outcomes of a project. When we have found evidence of user requirements analysis this process appears to have been somewhat limited. Little attempt has been made either to define the high level tasks to be supported by the resource, or to map the data available to the tasks that can be supported by that data, or even to identify the tasks that will need to be supported by the resource for individual user groups. The design and implementation of the resource cannot therefore be informed by an understanding of the relationships between users, tasks, content and functions/capabilities, even though such an understanding would be likely to increase the probability of developing a truly useful resource. In addition to the finding arguments, it is possible to identify a number of other possible causes for the lack of focus on users. Firstly, at least in the case of larger portal projects such a GBIF, there appears to be a perception that the portals will themselves generate requirements. This will, however, defer the acquisition of essential requirements data until well down the development path and is therefore a risky strategy to follow. The lack of focus on users may also be related to the fact that the larger portals have such a potentially wide-ranging group of end-users that to look at the needs and tasks of each group is considered too complex. One way to approach this may be to attempt to break down the complexity of the user base by changing the design emphasis of the projects. If portal providers focus on developing flexible infrastructure architecture, the plumbing so to speak, they could then support user-groups in the development of their own specific interfaces, tailored to support the tasks of these groups. The primary output of a project like GBIF would then be a set of tools allowing portal interface developers to hook into the GBIF infrastructure. This allows the interface development paradigm for the portals to be closer to that for the smaller more specific resources that already exist as stand alone data resources. Many of the successful smaller sites are in fact developed by their end-user community (e.g. ETI- WBD). Their success is undoubtedly linked to several factors: 1. The interfaces are developed by the end-user community, the developers therefore have an inherent understanding of the tasks they need to perform, and the interface functions required to support those tasks. 2. Such interfaces will only be developed when the end-user community positively identifies a requirement for such an interface onto the resource. 3. Because the user community obtains clear ownership of the portal, the development and enhancement cycle of such interfaces is therefore likely to be enduring. In addition to providing a clearer set of design goals, adopting the approach to design suggested here would also have the advantage of clearly separating the design pathway of the portal infrastructure from the design pathway of the interfaces. Figure 1 illustrates the process by which a set of use cases can be developed by considering the relationships between users, tasks and the available data. Figure 2 shows where the design process illustrated in Figure 1 fits into the overall design process that could be applied to a portal and its interfaces. In Figure 2 it can be seen that the design goals for the portal and its interfaces are clearly separated. This leads to a different selection of end-users when starting the user requirements analyses, thereby keeping the end-user groups smaller, more tightly defined and therefore less complex. Interface developers focus their requirements analysis on the end-user community they wish to serve and the infrastructure developers focus their requirements analysis on the interface developers they intend to support. Rather than a single set of use cases for the entire system this will lead to the development NEALE ET AL. – ONLINE BIODIVERSITY RESOURCES – PRINCIPLES FOR USABILITY 33 AIMS / SCOPE OF PROJECT AVAILABLE DATA POTENTIAL USER GROUPS TASKS THAT CAN OR WILL BE SUPPORTED USER TASKS USE CASES SYSTEM DESIGN Once potential user groups have been identified the tasks they perform and which could be supported can be identified – this should involve input from actual users The potential users of a portal will be influenced by both the aims of the project and the available data Identify which tasks can be supported through the portal Deconstruct the individual tasks Requirements can be determined from the use cases The scope of the project is in part determined by the data which are available and vice versa. The data which are available will impact on the tasks which can be supported by the portal. Figure 1. A process by which use cases can be developed considering users, tasks and available data. of a set of use cases for the infrastructure and a separate set of use cases for each interface to be developed on the infrastructure. Having said this, the use cases for the interfaces are likely to be somewhat dependent on those developed for the portal infrastructure. It may at first glance appear that this is indeed the approach that GBIF has taken. The project has been broken down into a number of operational categories each with a controlling committee. There are three operational categories that are directly relevant to the accumulation, indexing and access to data – DADI (Data Access and Database Interoperability) and ECAT (Electronic Catalogue of Names of Known Organisms), DIGIT (Digitisation of Natural History Collections; GBIF 2003). However, examination of the work programmes associated with these efforts reveals little concern for the ultimate end- users and an overriding emphasis on developing tools and mechanisms for the accumulation and indexing of data at the expense of providing tools to access the data. While the data accumulation and indexing tools are undoubtedly essential elements of a portal project, because there is no clear understanding of the ultimate use of the accumulated data there is no guarantee that the data indexing and exchange systems developed will satisfy the user requirements as they emerge. Indeed only now, seven years into the GBIF development programme are we starting to see evidence that users are beginning to show an interest and looking for services, and consequently it is only at this point that the system can be tested (GBIF 2006a). It is, therefore, very likely that, as intimated at the start of the paper, a considerable amount of the infrastructure will have to be redeveloped (“enhanced”) due to lack of timely focus on end-user requirements. Moreover, although there are two demonstrator projects designed to show the utility of GBIF the primary public output from the project currently appears to be the GBIF data access portal. This approach is again problematic since in essence it creates a single point of failure for the system, i.e. regardless of how well the infrastructure has been developed GBIF will almost certainly be judged on the success or failure of this interface. Altering the design model such that the interfaces and the infrastructure are conceptually separated, means that the success of the portal infrastructure can then be measured independently of the success or failure of any of the interfaces developed on it. Responsibility for design and implementation of the interfaces can be delegated to the end-user communities giving all the advantages of NEALE ET AL. – ONLINE BIODIVERSITY RESOURCES – PRINCIPLES FOR USABILITY 34 AIMS / SCOPE OF PORTAL INFRASTRUCTURE USE CASES USE CASES INFRASTRUCTURE IMPLEMENTATION INTERFACE IMPLEMENTATION AIMS / SCOPE OF PORTAL INTERFACE SYSTEM DESIGN SYSTEM DESIGN . The system for determining users, tasks and use cases shown in Figure 1 can be applied at this point. In the portal interface design the actors will mainly be end users, and the tasks high level e.g. identify pest species in garden The requirements for the interface are specified by the use cases and form a measurable set of deliverables for the system design The design of the interface will be in part determined by the design of the portal infrastructure Some use cases will have overlapping sub elements The requirements for the interface are specified by the use cases and form a measurable set of deliverables for the system design The system for determining users, tasks and use cases shown in Figure 1 can be applied at this point. In portal infrastructure design the actors are likely to be machines ‘talking’ to one another, and the tasks lower level ones for example ‘retrieve data’ Figure 2. An illustration of the design process for portal infrastructure and interfaces showing how, although the two processes are interlinked and interdependent, they can also be separated so that end-user groups could generate individual interfaces on top of a single portal infrastructure. community-lead interface development discussed earlier. The only potential argument against this is that it is politically more difficult to sell a project intended only to develop infrastructure rather than high visibility public interfaces. It would appear that within both GBIF and BioCASE there is indeed a move towards this approach. GBIF provides a portal development tool based on the software it uses to drive its web site although this software does not provide tools for accessing GBIF data. They also provide a UDDI registry of web services which may be useful in data portal construction. GBIF are also beginning internal discussions on the development of a Universal Data Bus intended to provide just the kind of interface independent infrastructure we have been describing (R. Hyam pers. comm.). BioCASE now provides the BioCase and TAPIR protocols plus the PyWrapper data provider, and ‘unit loader’ software2 which allow third parties to develop their own collaborative networks using a common architecture and a couple of prototype demonstration interfaces are available3. However, this approach is only just starting to emerge after 2 http://www.biocase.org/. 3 http://www.biocase.org/products/portals/. five to seven years of development in which, as far as can be judged from the project documentation, the primary focus appears to have been providing a single access point to distributed data. The developments described at the beginning of the paragraph therefore appear to have arisen as useful by-products rather than as the products of primary design goals. They have therefore involved adapting their software to the broader aim of infrastructure provision rather than designing for this from the outset. It can only be concluded that a move towards this truly useful kind of tools development could have been achieved much more quickly and efficiently had the appropriate user-oriented design analyses been undertaken from the beginning. ABBREVIATIONS BioCASE – Biological Collection Access Service for Europe BioCISE – Resource Identification for a Biological Collection Information Service in Europe EMBL – European Molecular Biology Laboratory ENBI – European Network for Biodiversity Information ENHSIN – European Natural History Specimen Information Network NEALE ET AL. – ONLINE BIODIVERSITY RESOURCES – PRINCIPLES FOR USABILITY 35 ERMS (MarBEF) – European Register of Marine Species (Marine Biodiversity and Ecosystem Functioning) ETI-WBD – World Biodiversity Database ETI-WTD – World Taxonomist Database GBIF – Global Biodiversity Information Facility ILDIS – International Legume Database & Information Service LINNE – Legacy Infrastructure Network for Natural Environments NBN – National Biodiversity Network WADSIS – Transnational Wadden Sea Information Service ACKNOWLEDGMENTS This work was funded by the Network Activity D of the EU Synthesys project contract number R113/CT/2003/506117. We thank Prof. David Mann and Dr. Colin Pendry for valuable comments on the manuscript. LITERATURE CITED Astrogrid Consortium, The. 2002. Astrogrid phase A report.4 Bias, R. G., and D. J. Mayhew, eds. 1994. Cost- justifying usability. Harcourt Brace & Co., Boston. Calabuig, I., C. Dieguez, I. Izquierdo, N. Scharff, and H. Enghoff. 2001. ENHSIN – European Network of Biodiversity Information – Report on results from Questionnaire to Assess User Needs. Annual Report 2001. Zoological Museum, University of Copenhagen. Clarke, I., and T.B. Flaherty. 2003. Web-based B2B portals. Industrial Marketing Management 32:15- 23. ENBI. 2003. First ENBI E-conference: Open Access for Biodiversity Information. Zoological Museum of Amsterdam, Amsterdam.5 GBIF. 2003. Global Biodiversity Information Facility Strategic Plan October 2003. Global Biodiversity Information Facility, Copenhagen. GBIF. 2005. Building SpeciesBanks: How Shall We Shape the Future? Global Biodiversity Information Facility, Copenhagen. GBIF. 2006a. GBIF Strategic and Operational Plans 2007-2011: From Prototype towards Full Operation. M. Lane, ed. Global Biodiversity Information Facility, Copenhagen. GBIF. 2006b. Survey result summary: Feedback and Requirements for Use of GBIF Data Portal. Global Biodiversity Information Facility, Copenhagen. Goguen, J.A., and C. Linde. 1993. Techniques for Requirements Elicitation. Pp.140-152 in Thayer, R.H. and M. Dorfman, eds., Software Requirements Engineering (2nd ed.). IEEE Computer Society Press, Los Alamitos, California. 4 http://wiki.astrogrid.org/pub/Astrogrid/PhaseAReport/redbook.pdf. 5 http://www.enbi.info/. Gould, J. D., S.J. Boies, and C.H. Lewis. 1991. Making usable, useful, productivity-enhancing computer applications. Communications of the ACM 34:75- 85. Gould, J.D., and C. Lewis. 1985. Designing for usability: Key principles and what designers think. Communications of the ACM 28:300-311. Hewitt, T.T., and C.T. Meadow. 1986. On designing for usability: An application of four key principles. Pp. 247-252 in Human Factors in Computing Systems conference proceedings. ACM Press, New York. ISO. 1998. 9241-11: Ergonomic requirements for office work with visual display terminals (VDTs), Part 11: Guidance on usability, 1st ed., 1998-03-15, International Organization for Standardization, Geneva. Jones, P.G., and P.K. Thornton. 2003. The potential impacts of climate change on maize production in Africa and Latin America in 2055. Global Environmental Change 13:51-59. Kujala, S., and M. Kauppinen. 2004. Identifying and selecting users for user-centered design. P.p. 297- 303 in Proceedings of Nordic Conference on Computer-Human Interaction, Tampere, Finland, 25-27 October 2004. ACM Press, New York. Kujala, S., M. Kauppinen, and S. Rekola. 2001. Bridging the gap between user needs and user requirements. P.p. 45-50 in Avouris, N., and N. Fakotakis, eds. Advances in human-computer interaction I. Proceedings of the Panhellenic Conference with International Participation in Human-Computer Interaction (PC-HCI 2001). Typorama Publications. Kujala, S, and M. Mäntylä. 2000. Is user involvement harmful or useful in the early stages of product development? Pp. 285-286 in Computer Human Interaction 2000. The Hague, Netherlands. Kujala, S. 2002. User Studies: A Practical Approach to User Involvement for Gathering User Needs and Requirements. Acta Polytechnica Scandinavica, Mathmathics and Computing Series No. 116. Finnish Academies of Technology, Espoo. Larsen, F.W., I. Calabuig, and H. Enghoff. 2004. Report on Non-European User Needs for Biodiversity Data. ENBI Report. WP13_D13.3_9/ 2004. Zoological Museum, University of Copenhagen, Copenhagen. Löwgren, L. 1995. Perspectives on Usability. Institutionen för Datavetenskap IDA Technical report LiTH-IDA-R-95-23. University of Linköping, Sweden. Mulligan, R. M., M.W. Altom, and D.K. Simkin. 1991. User interface design in the trenches: some tips on shooting from the hip. Pp. 232-236 in Robertson, S.P., G.M. Olson, and J. S. Olson eds. Proceedings of the Computer Human Interaction ‘91 Human Factors in Computing Systems Conference. ACM Press, New York. Neale, S., M. Pullan, and M. Watson. 2005. User requirements and interface testing documents of natural history collection and biodiversity online NEALE ET AL. – ONLINE BIODIVERSITY RESOURCES – PRINCIPLES FOR USABILITY 36 portal projects. BioCASE/ Synthesys Report. Royal Botanic Garden Edinburgh, Edinburgh. Neale, S., and M. Pullan. 2005. User interface requirements analysis for the BioCASE/Synthesys biological information portal. Synthesys Networking Activity D Deliverable D 3.4.1. Royal Botanic Garden Edinburgh, Edinburgh. Parmesan, C., and G. Yohe. 2003. A globally coherent fingerprint of climate change impacts across natural systems. Nature 421:37-42. Pendry, C. 2004. Final report: Testing the BioCASE user interface at RBGE, April to July 2004. Royal Botanic Garden Edinburgh, Edinburgh. Rauterberg, M., and O. Strohm. 1992. Work organization and software development. Annual Review of Automatic Programming 16:121-128. Sánchez-Cordero, V., and E. Martínez-Meyer. 2000. Museum specimen data predict crop damage by tropical rodents. Proceedings of the National. Academies of Science USA 9:7074-7077. Schalk, P., and W. Heitmans. 2005. Conclusions from an inventory of end-user forums and user feedback of biodiversity projects. ENBI Report WP12_D12.2b_12/2005. University of Amsterdam, Amsterdam. Standish Group. 1994. The chaos report. West Yarmouth, MA: The Standish Group International, Inc.6 6 http://www.standishgroup.com/sample_research/chaos_1994_1.php Peterson, A. T., and J. Shaw. 2003. Lutzomyia vectors for cutaneous leishmaniasis in Southern Brazil: Ecological niche models, predicted geographic distributions, and climate change effects. International Journal for Parasitology 33:919-931. Robinson, N. 2005. User aspects breakout group, GBIF Species Bank Workshop, Amsterdam 2-4 March 2005. Global Biodiversity Information Facility, Copenhagen. Root, T. L., J.T. Price, K.R. Hall, S.H. Schneider, C. Rosenzweigk, and J.A. Pounds. 2003. Fingerprints of global warming on wild animals and plants. Nature 421:57-60. Roth, C. 2002. Top 10 portal pitfalls - and how to avoid them. Special Report on Portals, META Group.7 Standish Group. 2006. The chaos report. West Yarmouth, MA: The Standish Group International, Inc. Waloszek, G. 2001. Portal usability – is there such a thing? SAP Design Guild Editions. Edition 3: Portals. SAP, Walldorf, Germany. 8 Williams, P., D. Gibbons, C. R. Margules, A. Rebelo, C. Humphries, and R. Pressey. 1996. A comparison of richness hotspots, rarity hotspots, and complementary areas for conserving diversity of British Birds, Conservation Biology 10:155-174. Zazelenchuk, T. W., and E. Boling. 2003. Considering user satisfaction in designing web-based portals, Educause Quarterly 26: 35-40. 7 http://techupdate.zdnet.com/techupdate/stories/main/ 0,14179,2867254,00.html. 8 http://www.sapdesignguild.org/editions/edition3/portal_usab.asp.