GISdevelopment.net ---> GITA 2001 ---> A Tangled Web of Pure Opportunity

Usability as an approach to Designing Web based GIS applications

David Firman
Graduate Research Group
School of Communication
Simon Fraser University
Usability Consultant
Pacific Alliance Technologies
Suite 505 Ś 1168 Hamilton St,
Vancouver, British Columbia
Canada V6B 2S2
Email : dcfirman@sfu.ca


GIS data has traditionally been in the hands of highly specialized professionals who have either been responsible for collecting and developing the data, or are planning operations based on the data. As more and more institutions invest in digitizing map based data the obvious question of how to maximize utilization of GIS based information throughout an enterprise has come to the fore. Browser based map viewing software has the potential to solve two major difficulties associated with enterprise-wide availability of GIS data. One, the per-seat cost of making GIS data available is drastically reduced. Two, HTML and Java based applications afford direct customisation according to the needs of specific job categories and organisational cultures. This latter concern is especially significant given the intention of making map data easily accessed and understood by people who do not have the same level of experience and expertise as the GIS professionals that have historically worked with it. This paper is an account of the development of iVAULT, a browser based map viewing application for the telecommunications industry. This project is interesting in how it adapted Usability methods to inform product design.

Introduction
Web-based geoengineering data publishers present exciting possibilities for maximising the utilisation of GIS databases. Internet and intranet publishing of graphic and attribute data allow almost universal accessibility at a fraction of the cost of purchasing additional seats of more complex GIS software. In addition, the client-server model permits the transfer of up-to-the- minute data, so users can be confident that they are working with current data. Equally intriguing is the potential for expanding the range of personnel who might productively exploit map and associated data without incurring the costs of training in the use of complex software environments.

This last point is key. Web access increases the potential for GIS dissemination exponentially. The opportunity is clear. The design challenge is to develop approaches that lead to browser- based GIS applications that find ready acceptance and productive utility in the hands of a diverse user population. This goal demands a hard look at current design practices that have evolved to meet the needs of a very specialised expert user base who have been brought up in a particular environment of software conventions and working patterns specific to the field of GIS in its current context.

How are we to make sense of such a broad and varied group of potential users? Some of them have a technical connection to map data that might make it possible and efficient to bring them into the GIS fold by training them in current conventions of GIS software. However, if this is the extent of the commitment to spreading the utility of GIS, then the scope of our ambition falls far short of the opportunity in front of us. To overstate the obvious, maps have been around for along time and the vast majority of those who work with them on a daily basis have no direct connection to GIS generated maps and attribute data. Beyond those who work directly with maps there are countless others who work within some kind of mapping paradigm, in no small part because maps are a powerful metaphor for organising all manner of spatial concepts. Clearly, if we are to extend GIS capabilities to this wide and capable population, then we must be prepared to embrace design techniques that transform digital mapping into something that looks and feels natural to those who want to work with it, no matter what their technical background or working environment.

Usability engineering is one design approach that is based on the assumption that design immersed in the context of use has a very great potential for developing software that will reflect the reality of use. Put simply, the idea is that the software needs to first adapt to already productive work practices if it hopes to enhance efficiency and productivity. While Usability has often been included as a part of the software development process (particularly in the design of user interfaces), the sheer complexity of traditional development practices determined that representative user groups were either very specifically defined, or were generalised to an extreme. The growing family of programming languages created for the Web have shifted the field of user based design in dramatic fashion. It is now possible to make changes in the look, feel, and functionality of applications almost overnight. Further, it also seems possible to develop design standards that adapt the front end of software directly according to use patterns. For that matter we can put fundamental design decisions directly in the hands of individual users who can immediately evaluate the results of their decisions based on subsequent task completion.

User involvement in design not only promises the maintenance of productive work practices, but it invites user acceptance of new technology by including them as de facto members of the software development team. When new software blends almost seamlessly with existing work flow, there is the potential that instead of user resistance, users will exploit new software functionality to improve productivity in the specific context of individual use.

This paper recounts the development of a browser-based GIS viewer. The design process included a relatively detailed Usability component. The methodology employed is described and evaluated. This is followed by a discussion of the role that Usability has played in the ongoing conceptual and technical development of this particular product and then concludes with some thoughts about how the opportunity of Web-based GIS demands a rethinking of current industry wide development practices and the relationship between core software manufacturers, resellers, and clients.

In the spring of 1999, Pacific Alliance Technologies of Vancouver began work on a browser- based viewer for the second largest Canadian telecommunications enterprise. The goal was to develop a simple, effective and cost efficient application that would make technical data accessible to a broad range of Telus employees in widely dispersed locations. Anticipating the challenges inherent in designing a product that would be used in so many different kinds of job tasks, the Project Manager Bruce Campbell requested that a Usability study be included as part of the development process. The following is a description and evaluation of the development of iVAULT focusing primarily on the role Usability methods played in the design process.

The purpose of a Usability study is to improve system functionality by observing and consulting with those who will ultimately use it as fundamental part of their job activities. The ideal is to direct software development implementation, and user training, so as to realise tangible cost benefits by tailoring the software to achieve maximum efficiency in the hands of those who use it. The usefulness of any application can be divided into two subcategories: utility and usability. Utility is a measure of how well the system's functionality accomplishes those things for which it was designed. Usability looks at how well the users who actually use the system can manipulate the functionality (Nielsen, 1993). While usability must clearly be a concern in all system design, it become a pressing issue in the development of applications that will provide complex technical data to users who have a limited relationship to that data, and probably no background in using the software that has created the data.

The Product
Developed by Vancouver's Pacific Alliance Technologies, iVAULT is an innovative application designed to serve the telecommunications industry. iVAULT takes advantage of the client-server environment to access graphic and attribute data on demand, and publishes the information for instant viewing and redlining via a Web browser.

The Process
Usability testing usually combines two or more accepted usability engineering strategies (Spencer, 1985; Nielsen, 1993; George, 1996). This study used observation, Usability testing sessions, evaluation according to proven software design standards, and follow-up questionnaires as the modus operandi.

Observation
Observing users performing the job tasks that involve geoengineering data is an integral step for developing a task analysis that both informs prototype design and the construction of more formal Usability testing. In most cases observation is performed on the job site by the Usability Consultant. In this case the Application Engineer, who was responsible for customising the software, decided to participate. Representative users of six job categories were observed at their desks as they worked through actual tasks using existing systems. The observations were conducted at the users' desks so as to duplicate as much as possible actual job conditions. Conversations were taped and extensive notes were kept.

The value of conducting work observations should not be underrated. While meetings of representative users might go a long way to creating the big picture of work flow and enterprise wide functionality expectations, it does not have the same potential for ferreting out more context specific work situations. The sheer flexibility of browser-based design suggests that we can extend software utility beyond the compromises inherent in a design by consensus model.

Usability Testing Sessions
The observation data informed a preliminary task analysis and a working prototype was produced. When these steps were complete a technical dry run of the Usability testing was done in order to ensure that the application was reasonably reliable and that the data collection technologies for recording the Usability sessions were working. The Usability testing was conducted in a meeting room at the so as to minimise distractions and facilitate recording. A direct video feed was taken from the computer monitor through the use of an AverKey. In addition a video camera with audio pick-up recorded hand movements and conversation. A separate audio record was made both as a back up, and to ease the task of transcribing the sessions. During the testing the Usability Consultant kept notes.

After explaining the process for the usability sessions the Usability Consultant acted as a silent observer. Limiting interaction between the user and the Usability Consultant is necessary to ensure that the observer not say anything that would lead the user to concentrate on particular aspects of the application functionality. In contrast, the Application Engineer was available to coach the participants. He was careful not to actively direct users through the interface, but intervened if anyone was completely stumped, and he helped the users work around any bugs that became apparent. He also participated in user initiated conversations about potential interface redesign, development issues and software limitations. These exchanges were invaluable for teasing out user concerns and expectations. The representative users were asked to work through a task similar to those demonstrated during observations. They were also asked to "think aloud," a Usability term for verbalising the actions of working with the interface and data.

The "thinking aloud" technique is an invaluable aid and deserves explanation. One of the difficulties with current approaches to task analysis and user consultation is that they do not address enough the issue of tacit knowledge. In a sense, the hardest things to learn about a particular user task are those that are done so well and so efficiently that they are invisible to both performer and observer. The danger to not including a strong sense of these tacit operations is that software functionality, while perhaps effectively improving on visible task inefficiencies, ultimately fails to achieve a higher purpose, namely supporting already existing effective and productive work and decision making practices.

Data Analysis
Once the Usability testing was complete, the video data was reviewed, and transcripts were made of the audio recordings. A series of analytic categories (codes) was created guided by standard Usability heuristics (assessment standards based on proven software design attributes) and informed by a preliminary review of the data. The coding was revised continuously throughout the analysis phase and various hierarchies of inter-code relationships were developed. The coding is the key element for a systematic inquiry into Usability issues.

An analysis of software functionality and interface effectiveness was done in an iterative fashion. For example, coding counts within and across Usability sessions were noted and used as a guide for examining specific interface components. Standard Usability heuristics were then used as a measure of design completeness, and with this in mind the data was reviewed to ensure accuracy of interpretation and to see if users had provided direct or indirect suggestions for redesign. The final stage of analysis involved working through each element of the interface functionality in order to assess it according to the various layers of analysis already developed.

Redesign, report, and presentation
Once the analysis of the usability sessions was complete, iVAULT underwent a thorough redesign. While the usability analysis was done exclusively by the Usability Consultant, and technical design was the responsibility of the Application Engineer, design decisions were made in a collaborative fashion which included informal consultation with almost everyone working at Pacific Alliance Technologies. It was always the intention of the design team to have the final design directed as much as possible by the end users, so the redesign was more of an attempt to create a polished prototype to present for further consultation than it was an effort to create a final product.

The Usability Consultant produced an extensive report that detailed design issues for every element of the interface in the order they would most probably be encountered during task completion. With the inevitable tendency to concentrate on the software itself, the Usability report often does not receive the attention it deserves. In order to maximise the effectiveness of the report, careful consideration went into its content and organisation. Each layer and element of the interface were discussed in the context of how actual end users had assesses their utility and usability. Design issues were subdivided into three categories: training, customisation, and development. The prototype and report were taken to a meeting with the Telus project management team. Although Telus had asked for a brief presentation of the Usability study, the meeting turned into a thorough and energetic design consultation during which design decisions were made on almost all the outstanding design concerns. This meeting was the source of a major redesign before the phase-in stage of the iVAULT implementation process.

Evaluation
The ultimate measure of the usability process is the usefulness of the software design it informs. Feedback from the client company indicates that iVAULT is proving to be a very effective enterprise-wide geoengineering solution. From the standpoint of the development team at Pacific Alliance Technologies it now serves as an invaluable base from which to build other enterprise specific telecommunications applications.

We also re-examined the Usability process itself in order to refine it for future projects. Involving the Application Engineer in all phases of the usability process worked very well, and it should probably be at least considered for most Usability studies. For the Application Engineer, site observation provided invaluable insights into situated job activities, which informed appropriate design solutions. The observation period also cemented the working relationship between the Usability Consultant and the Application Engineer and it provided an opportunity to develop a design semantic so that they could communicate clearly across their different backgrounds and expertise. In addition, the representative users were able to engage the technical experts on the users' home turf, thereby beginning a process through which they became more and more confident that they were contributing critical expertise as an essential part of the design effort. The empowerment of users serves double duty in that it makes for better software, and the sense of ownership the user has over a design in which they played an integral part eases acceptance of the new software when implemented.

The technology used to record the usability testing session represents a somewhat new approach to gathering data. Usability studies have traditionally made extensive use of video cameras, but the strategy of taking a direct feed off of the monitor provided a clarity that a video take could not possibly reproduce. This facilitated a degree of analysis that was able to evaluate in some detail factors like variations in data entry techniques, and patterns of cursor movement as the user navigated the interface. Employing a split screen recording technique so that all of the video views are precisely co-ordinated could increase the depth of analysis further. It was decided to abandon the usual practice of taking a direct video recording of users' faces, and the users were palpably relieved at this decision. There is always the question of whether it might be more useful to conduct the testing sessions at the users' actual work-stations. The trade-off here is between creating a testing situation that mirrors as closely as possible actual job conditions, and the problem that those very conditions will provide a level of distraction that compromises the sessions. In any case there was an attempt to use actual company data in the sessions. This proved to be an effective choice as the users were able to focus on the software rather than on becoming used to unfamiliar data formats.

From our experience in this project we have concluded that whenever possible, future Usability testing will be done at users™ desks. It is only in the actual situation of work that all of the possible elements affecting productivity come into play. Testing done in any other setting isolates a particular piece of software and makes invisible important factors in the technical and social working environment. Noting how users work within an existing environment (phones, intercoms, specific hardware configurations, existing software, collaboration patterns etc.) offers important clues as to how software will work in the real world of work and this should inform effective design.

Conducting the study across a range of job categories did not prove as problematic as expected. There were clearly design issues that were shared by all the users tested, and confronting the challenge of making browser-based software useful for widely disparate operations is central to developing useful applications for viewing GIS graphic and attribute data. Indeed the authors were reminded often that the same map is seen very differently by different users according to how map representations related to particular job responsibilities (Wood, 1992).

Usability studies are still in their infancy as a credible design strategy and clients are not accustomed to making room for the various stages of conducting a Usability project. This project would have benefited from more detailed communication with the client so that they could be more definite about the necessity of dedicating the necessary time and resources to the process. The Usability report presentation, which turned into a design scrum, proved so successful and enjoyable that it reinforced the effectiveness of the process for the client who, through experience, have become quite cognisant of the co-operation required to successfully complete a Usability study.

Although in many ways an afterthought, the report format was a major success. Subdividing the design issues into training, customisation and development highlighted concerns so that various managers were able to focus their contribution according to their particular expertise and responsibilities. In effect it put the focus on the design process as much as on the design product and so made visible the relationships between these aspects of design. For example, there is a productive tension between training solutions and programming solutions. If use is intuitive enough, training need only be minimal. By the same token, unwieldy programming might be made unnecessary if a simple training technique will take care of the issue. In any case usability does point to often overlooked training demands. For example this study showed that even quite sophisticated computer users are not necessarily aware of the choices they have for configuring a browser so as to maximize its capabilities for hosting a technical data viewing session.

Towards a Heuristics of usability

Implications for application development
As already noted and demonstrated, a Usability approach has great potential for informing design at the level of the user-interface. It also can do so much more. As iVAULT has moved through various design versions the emphasis on Usability has had a profound impact on the general structure of its design, and Usability promises to profoundly influence its future development as well.

Buoyed by successful implementation of the product, the iVAULT development team has determined that effective and individual applications of the software will be enhanced by using guidelines garnered from the Usability approach as essential standards for the design structure at both the front and back ends. In other words, the flexibility demanded by a high sensitivity to multiple users and contexts of use needs to be supported by command structures, data movement and data publishing that are themselves adaptable to relatively specific work practices in a broad array of circumstances.

To this end the development team has adopted, and are currently implementing, several design heuristics that aim to maximise the inherent flexibility of the product so that particular client implementations are smooth, cost efficient and themselves amenable to constant redesign as clients find ways to spread GIS capabilities throughout their enterprises.

The following is a list of some of the standards (heuristics) directing current design efforts:
  • The product should be as modular as possible.
  • The product should be platform independent.
  • The user-interface should be separate from the content generation.
  • The product should allow access to virtually any tabular or spatial data source.
  • The product framework should be able to adapt simply to legacy systems and equally to the introduction of new technologies.
  • The product should encourage direct user involvement in front-end design
  • The product should contain mechanisms that recognise patterns of individual use.
  • The product should be designed so as to acknowledge the software administration process as itself a Usability issue.
Implications for current industry development practices
The above design standards inevitably separate much of the product framework from the map- viewing applet that must ultimately be the core layer of the product. In order for web-based technical data viewers to fully exploit the vast market that could benefit from their use it seems desirable to take a critical look at the relationship between the developers of core software and the VARs and implementation teams that will ultimately be responsible for expanding the client base for GIS technologyand services

While there is no doubt that the major manufacturers listen closely to those who sell and service their products, it seems necessary to radically refine the nature of the design response to that communication if manufacturers are going to be able to respond in the kind of time frames that actively support the reality of dynamic design at the client sales and service level. If viewing applets are themselves designed on a truly modular basis, then VARs and implementation teams can pick and choose functionality and interface conventions suitable to particular and multiple client needs. The modular development model would be best supported by systemised communication between designers on the front lines and core development teams that respond to individual project input by developing appropriate functionality modules that can then be offered to the market as a whole. In this manner, case by case adaptability would lead to general availability of design modules that would quickly make the core software attractive to a wider and constantly expandingarray of users within current client enterprises as well as open up new and exciting market possibilities.

Conclusion
Usability analysis is a much underutilised tool for software design. The experience of developing iVAULT is a clear indication of the value that Usability studies can play in developing effective and efficient applications for viewing geoengineering data. This is especially true now that the Web expands exponentially the potential user base that can access GIS information. For GIS professionals and academics to fully realise the communication possibilities inherent in map based representation, innovative design techniques such as Usability analysis should be embraced.

References
  • George, Helen. (1996). The Good Usability Handbook. New York: McGraw-Hill.
  • Nielsen, Jakob. (1993). UsabilityEngineering. New York: AP Professional.
  • Spencer, Richard, H. (1985). Computer Usability Testing and Evaluation. New Jersey: Prentice- Hall.
  • Wood, Denis. (1992). The Power of Maps. New York: The Guildford Press.

© GISdevelopment.net. All rights reserved.