A good interface will fade into the background and the user will focus on the task at hand

Baeker and Buxton (pg. 40) state that the "beliefs and expectations with which she (the computer user) sits down at her terminal or personal computer are a direct result of her concept of what the computer is like and what the computer has become.", thus Hansen (cited in Shneiderman, 1986) states that one should "know the user". This includes all aspects of the user's experience of computerized systems as well as their personal preferences.

For example a user who has only had experience in the windows environment is unlikely to benefit from a DOS look and feel, even if the programme is functionally adequate for all their programming needs. This is vitally important when one remembers that the computer, for most users, is simply one of an array of tools that can be used to perform a certain task. If the tool is not readily accessible and easy to use it will be discarded in preference of another.

Certain images, graphics and language may be offensive to one group of users, and care must be taken to avoid inadvertently offending any one on the basis of culture, race, creed, gender or sexual orientation. Muslim users may be offended (or alienated) by popping champagne bottles, whilst indirectly comparing a Zulu user to an animal (cartoon of a monkey) would equally offend and alienate this group. Language should be inoffensive, and gender neutral.

Any computer programme may be used by people with physical challenges e.g. the blind and deaf. Even in areas where it is unlikely for the physically disabled to be accepted, there may be occasions when a user is temporarily disabled and still needs access to the equipment. For instance if a hand is in plaster cast would the user still be able to access the information. Sound should include textual alternatives, and visual graphics should have descriptions.

1. 
   Green blindness - individuals confuse greens, yellows, and reds (6.39 percent)
   
2. 
   Red blindness - individuals confuse various shades of red (2.04 percent)
   
3. 
   Blue blindness - individuals confuse blues (0.0003 percent)
   
4. 
   Total color blindness, which affects no more than 0.005 percent of both sexes."
   

The Macintosh Human Interface Guidelines also warns against this problem stating "people with color-deficient vision wouldn't recognize the use of color to indicate selection. Therefore, you shouldn't use color as the only means of communicating important information. Color should be used redundantly. It shouldn't be the only thing that distinguishes two objects; there should be other cues, such as text labels, shape, location, pattern, or sound." and suggests that all images should be developed in black and white first. (For more information about the use of colour see the section heading "Colour".)

Nelson (cited in Baeker and Buxton, 1987) stated that "any system which cannot be well taught to a layman in ten minutes, by a tutor in the presence of a responding set-up, is too complicated". Factors that lead to the shortening of the learning time include familiarity, consistency and the use of an accessible metaphor. If a user can visualize the structure of a system and is able to predict the outcome of interactions, they will have more confidence with quicker interactions and a lower error rate.

Menu systems and graphical iconic symbolization are not necessarily universally understood. Various authors point to the following guidelines when creating selection items:-

1. 
   All graphic representation should have textual descriptions.
   
2. 
   Consistency of terminology should apply to all options throughout the system.
   
3. 
   Avoid the use of jargon and keep phrasing concise.
   
4. 
   Keywords should be scanned by the user first.
   
5. 
   Group similar items in a menu map, or if this is not possible use other instinctive alternatives such as alphabetic order.
   
6. 
   Avoid multiple screen transversals for selection purposes.
   
7. 
   Avoid ambiguity.
   
8. 
   Consistency throughout is vital.
   

Pictorial literacy is not a given. Interpretations of graphics are often dependant on culture, experience and exposure to a specific medium (see Amory and Mars, 1994 and Andrews, 1994). One pertinent example is that arrows are not a universal symbol of direction. It is for this reason that most authorities in Interface design recommend that all buttons, icons etc be labeled.

Navigation issues vary between Multimedia and WebPages but the common issues include links to the first screen/page, next screen/page, backtrack facilities and every system should have a quick exit button. See the section on the use of metaphor for commonly used buttons. All applications should have short cuts for expert users.

All aspects of design should adhere to the concept of adding meaning, if there is no enhancement of accessibility for the user, then there is no need for the information, graphic or media to be added. Similarly sound should only be inserted if it enhances meaning and it should not distract the users attention.

When using a combination of media e.g. sound, text, animation and video, be careful that the users attention is not distracted by one or other of the media. e.g. animation and sound can work well together, but animation and text presented simultaneously is likely to be distracting.

Concise, brief, unambiguous, clearly visible and consistently placed on screen.

Immediate, positive and instructional

Respect for the user and subject material is imperative. Avoid slang, misplaced humour and potentially offensive insinuations.

The layout of the screen is a controversial issue; what is aesthetically pleasing to one person may be considered dull and boring or, conversely, garish to another. The following locally designed pages may best illustrate this:

Most people involved with the development of interactive course material cannot afford the expertise and skills of a graphic design artist. This is often obvious in the end results and if at all possible it is recommended that a graphic artist be included in a team of developers. However, for those that are in the unfortunate position of a "do or die" scenario the following advise may assist. Most authors suggest the use of a maximum of four colours.

Imposing a metaphor on a virtual world, allows the user to be better able to predict the outcomes of new interactions. It also allows the designer to work with a model which will guide the development in a consistency of interactions and representations. Obvious metaphors are those of the "desktop" for office automation software, and the "paint brush and easel" for graphics packages. Care should be taken that the analogy is familiar to the users' experience of the "real world" and similar enough to be incorporated without excessive explanation.

Forward	Back	Fast forward	Rewind	Stop

Interactivity has been lauded as the most promising development in CAL since the euphoria of AI collapsed. However, interactivity should be more than a simple point and click scenario. Truly interactive systems based on a constructiveness approach would include drag and drop, text entries and other forms of interaction to develop a user’s knowledge of the subject material.

Individuals typically have their own preferences in the way that they perceive, collect and process information. These methods are referred to as "Learning Styles". The Academic Skills Center at Western Michigan University offers the following breakdown of learning styles:

• 
  Print - learns through reading (Allow printouts for these students).
  
• 
  Aural - learns by listening - will enjoy audio tapes and listening to what other learners have to say. (Voice over will assist these users.)
  
• 
  Interactive - enjoys discussions with other students on a one-to-one basis or in small groups. (CMC would assist many of these students).
  
• 
  Visual - learns by looking at pictures, graphs, slides, demonstrations and films. (Colour coding will work well with these types of students.)
  
• 
  Hap tic - learn through the sense of touch. (Drag and Drop interactions could help here.)
  
• 
  Kinesthetic - learns through movement. (Animation could help students with this type of preference).
  
• 
  Olfactory - uses the sense of smell in learning. (Any ideas?)
  

Learners will not typically use only one of the above list but a combination of them, favouring one method over another e.g. some learners work well in a group environment using visual and interactive learning styles whilst others prefer to learn on their own, but still use a visual style.

Gagne (1973, p. 303) states that "control of the external events in the learning situation is what is typically meant by the word 'instruction'". He then lists these events as:

• 
  Gaining and controlling attention.
  
• 
  Informing the learner of expected outcomes
  
• 
  Stimulating recall of relevant prerequisite capabilities.
  
• 
  Presenting the stimuli inherent to the learning task.
  
• 
  Offering guidance for learning.
  
• 
  Providing feedback.
  
• 
  Appraising performance
  
• 
  Making provisions for transferability.
  
• 
  Insuring retention.
  

Importance of HCI

Users expect highly effective and easy-to-learn interfaces and developers now realize the crucial role the interface plays. Surveys show that over 50% of the design and programming effort on projects is devoted to the user interface portion. The human-computer interface is critical to the success of products in the marketplace, as well as the safety, usefulness, and pleasure of using computer-based systems.

There are a number of subtle differences between the Interface for locally presented multimedia course material and that that is delivered via the WWW.

Probably the most significant comes about as a result of the difference in response time. Locally delivered material can usually rely on a quick response and display time, whilst internet delivered material has a slow response time. As users generally do not like to wait for information, internet material should be more detailed and lengthy than locally delivered material. This has particular relevance to menu's and navigational issues; Shneiderman (page 106) states that

Problems and Promises

In this section, we will examine the relationship between the activity of designing information sites for the World Wide Web and the field of Human Computer Interactions. From the perspective of HCI, web site design offers some interesting problems that are not present in the creation of traditional, stand-alone software products. Because of the present development of the WWW's rise to prominence, HCI is only now beginning to address these new issues. A challenge for the field, therefore, will be to rigorously examine the process of web site design and offer recommendations and guidelines, as it has with the areas of software and hypermedia publishing. That such counsel is needed by web site designers becomes readily apparent when looking at the multitude of badly conceived and poorly designed sites now populating the web. As Borges and his collaborators point out, "the proliferation of pages with poor usability suggests that most of the designers of WWW pages have little knowledge of user interface design and usability engineering. This is a serious problem that needs to be addressed...". There are, in fact, any great numbers of guidelines currently published on the WWW offering advice on how to design effective and pleasing sites. Unfortunately, very few of these are grounded in the theories or empirical data that have been developed in HCI. In fact, as Morris notes, "at this point, HCI as a discipline has had a relatively limited impact upon the development of the web". It is my contention, however, that it is precisely the field of HCI that has the most to offer web site designers. Therefore, part of this paper will be devoted to examining different areas within the HCI literature that might be of most use to the individuals who are creating and maintaining web sites.

Issues in HCI design in Web Medium

Web and Traditional Software Design

The question can be raised as to how similar the activity of designing World Wide Web sites is to the design of more "traditional" software and hypermedia products. The very fact that we are doing a project that attempts to relate web design to the established HCI literature suggests that we believe there are important similarities between designing for the web and designing other types of software. Yet there are obviously some important differences as well -- differences that the field of HCI is only beginning to consider. The most obvious dissimilarities involve the levels of technical knowledge necessary for design, and the types of entities that carry out the design process. While the creation of traditional "stand-alone" software applications requires extensive technical expertise, and is the largely the province of specialized companies, designing web sites requires relatively little technical knowledge, and can easily be done by almost anyone. But such surface distinctions, while important to note, are not what primarily concerns me. Rather, we are more interested in how the medium of the World Wide Web presents a set of challenges and issues to designers that are different to those presented to creators of traditional software products. Although there are undoubtedly some similarities in the process of creating web sites and stand-alone software, there are also some significant variations that result from the distinct characteristics of the mediums they are intended for. Put simply, the WWW is a very different environment from a single computer system or limited network, and designing applications to be displayed on it presents the designer with a number of unique issues that they must consider.

Perhaps the most fundamental aspect of the web medium that designers must come to terms with is that it is platform independent, which means that materials on the web can be accessed by a wide variety of computer systems and browser software. Because the WWW is system and browser independent, and because the different systems/browsers have varying capabilities and features, the designer of a web site does not know and cannot control:

1) How their pages will be visibly rendered for any particular user (e.g., a pleasing and coherent layout on one system/browser may look terrible and be confusing on another), nor

2) What functionality of the site will be supported by the configurations of different users (e.g., important layout features like tables may not work in all browsers).

Thus, designers of web sites have to account for the fact that they will have only a limited amount of control over the interface that their site will present to a visitor. As Simon Shum notes, "there has never been a hypertext system that was so large that no-one could be sure what hardware or software the end users might be using. The user interface design community has had to get to grips with the concept of designing with this uncertainty. Creator s of sites who want their work to be accessible and usable to a wide audience either have to design it in a way that will allow all major systems/browsers to view it effectively (designing for the "lowest common denominator"), or they have to consider pro viding different versions of the same site that are optimized for different types of users]. While the former option may be unacceptable for designers who want to incorporate the latest technological advances into their sites, and the latter option requires extra work on the part of designers (who would have to present multiple versions of the same site), these are really the only options for dealing with the uncertainty caused by the independent nature of the WWW.

Level of Interface to User

A second unique feature that has to be considered by designers is that web pages represent "third-level interfaces" for a user. Above the level of the individual web page, a user is also interacting with browser software and an operating system, each which provide their own interfaces to the user. The most important levels to focus on, for my purposes, are those of the browser and of the individual web sites/pages. A web site, as it is experienced by a visitor, really has a dual-interface: one that is provided by their browser software, and the other which is provided by the site designer. Both the browser and the site levels are important, in that each provide mechanisms that determine how a user will interact with the site and how they will navigate the site. Browsers, for their part, display the individual web pages, and provide at least a minimal set of navigation options for the user. Different browsers, however, vary in their capabilities for visually rendering pages and supporting other features -- ranging from the text-only capabilities of the Lynx browser to more advanced software packages like the latest versions of Netscape Navigator and Microsoft Explorer, which support a wide variety of media types (text, images, video, audio) and features (Java, JavaScript, Vbscript, tables, etc.). Browsers also vary in the navigation mechanisms that they offer to users. While all browsers support basic backtracking and jumping movements, the more advanced browsers also incorporate features identified in hypertext literature as aiding navigation -- features like history lists, bookmarking, and footprinting]. At the level of the individual web site, user navigation is affected by the access mechanisms that are presented (e.g., site overview maps, tables of contents, navigation bars, etc.), as well as the hypertext links embedded within the pages. Because the "dual-interface" will affect user's interaction with and navigation through a web site, and because the platform-independent nature of the WWW means that site designers cannot know which types of systems and browsers will access their sites, the creators of these sites have only limited control over the user interface that will be presented to a visitor. Site designers need to carefully consider a number of issues, therefore, regarding the functionality and navigation facilities which their site provides, and how these will relate to and be affected by a variety of browser platforms.

Access Speed

A third unique issue that confronts designers of web sites relates to the question of access speed. Because assess to a web sites comes via a connection to the global Internet, and is therefore affected by bandwidth constraints and network traffic , users of the WWW will likely experience some (greater or lesser) delay in the system's response to their actions. This can cause a number of problems. Slow connections, whatever their cause, not only serve to frustrate a user -- and increase the chance that they will abandon a site if it is responding too slowly -- but it also delays feedback to the user as well. Because connections to web sites are typically asynchronous, the system will respond to a user only after she takes some action. And if there is too great a delay between action and reaction, confusion, anxiety, or frustration may result. Discussing hypermedia systems, Jakob Nielsen notes that."...the response time for the display of the destination node is critical for the user's feeling of navigating an information space freely". And if the connection to a particular site is slow, users may feel that they are not fully in control. While the need for adequate speed is largely taken for grant ed in most software application development, and in usability research on these products, it is an important issue that faces web users and designers alike. Although some of the factors that affect access time, such as user's connection speed and network traffic levels, are beyond the control of web designers, there are obviously some steps that site creators can take to minimize the potential difficulties. In general, web pages that are smaller and less graphically-intensive will load faster than those which are larger and more graphically rich. Web designers, therefore, can insure that their sites will be accessed as quickly as possible by keeping the file size of their pages fairly low. But such a solution may not always be considered optimal for designers, who might want to capitalize upon the multimedia capabilities that the WWW offers. Thus, trade-offs are inevitable, and there is no single best solution for any case. Such trade-offs between access speed and presentation are much less important of an issue for developers of other software products, and as Shum notes, "web designers must therefore priorities different criteria to ones they might use in designing a smaller scale hypertext or multimedia CD-ROM, in order to balance interactivity with acceptable speed of access".

Interface Tools

The issues of platform independence, dual user interfaces, and access time all pose challenges to web authors, who must carefully consider the issues raised by these factors when deciding how to best design their sites. Unfortunately, they are also faced with the additional problem of having a much more limited set of interface tools to work with. Compared to the range of potential tools and techniques available to authors of stand-alone software applications, the web designer has a relatively primitive set of resources to work with. According to Richard Miller, "HTML's limited set of objects and interaction styles is a step backwards for interface design compared to the growth of interactive computing over the last 30 years". Not only do web designers have fewer interface widgets as their disposal, but nature of the web medium also makes it difficult or impossible to tightly couple relationships between interface elements], or to utilize some navigation aids identified as beneficial in hypermedia research (such as multiple windowing, user annotation, zooming, etc.). Thus, web site designers are faced not only with a lack of control over their interfaces that their sites present, but they also have fewer resources to draw upon to maximize the potential of these interfaces.

Nature of the Web

The final special issue regarding web site design to be discussed is how the dynamic nature of web sites affects their creation. Whereas the first four issues that have been examined all present problems to the web designer, the dynamism inherent in the WWW may actually prove advantageous for these authors. In the case of traditional software development, the design cycle is fairly well bounded, and when the product is released to the public, there is little or nothing that can be done to change it. This places a great burden on the development team, who much ensure that the product meets all of its predefined requirements and is relatively bug-free before it can be released. If problems arise afterwards, they can only be remedied through costly and time-consuming methods, and significant changes to the product may have to wait until the next version is developed. Web sites, however, are much easier to change after they have been "released" to the public. While this does not mean that site creators can afford to be lax in their initial design efforts, it does mean that if problems with the site become apparent after it has been mounted, they are relatively easy to change. This means that the iterative design cycle for web sites can be much less bounded, and may continue after the site is implemented in order modify problem areas. In fact, because of the dynamic nature of the web medium, it is probable that a site will undergo constant revision and change. While this offers site designers a greater degree of flexibility, some care needs to be taken to make sure that the site is not changed so often or so much as to create confusion among repeat visitors.

Areas in HCI that is important to Web Design

A blanket statement such as "the HCI literature is important for web designers" is not very useful because the field itself is so broad and varied. Although arguments could be made for including many different strands of HCI into a discussion of relevant areas for web design, we will discuss only four areas that we think are particularly significant: the literatures on software design methodology, hypermedia, user interface design, and usability. Before moving on to discuss these areas, we feel that a few caveats are in order. First, given the context of the assignment and the fact that we are addressing several different segments of HCI, my review of the literature in these areas will be fairly selective. we make no pretensions of having thoroughly surveyed these four areas. Also, we have attempted to the degree that is possible include fairly recent works that are explicitly oriented toward issues involving the WWW. Finally, we have included a few relevant works that are outside of the HCI field, strictly defined. My discussion of the literature will not be formally segmented into different sections. Instead, we will examine various relevant threads in the course of proposing a method for designing web sites that is based upon my interpretation of these literatures.

Although we have spend a considerable amount of time identifying some ways that web design differs from other types of software development, the general processes involved in this activity can be similar to those employed by authors of traditional software . Levi and Conrad argue that building web sites "can and should be viewed as a major software development effort.... The life cycle of web creation is identical to that of traditional software: requirements gathering, analysis, design, implementation, testing, and deployment". Although they do not identify it specifically by name, it seems apparent that the general type of methodology that they see being suited for web design is the User Centered Design (UCD) approach. we would concur that a design effort for the web would be well suited by employing a UCD perspective, but would argue that it should be specifically tailored to take into account specific types of tasks required for authoring a hypermedia application. While t he general UCD approach is fairly generic, therefore lending itself to a wide range of projects and design sequences, we believe that it is also flexible enough to be applied different types of design efforts. Before suggesting such specifications for a UCD approach to be used in the context of web development, however, we will identify the basic aspects of the user-centered design process that we feel make it particularly valuable for web site creators. Then we will examine in greater detail the specific stages of the web design approach that we believe is most valuable, drawing on the different areas of the HCI literature that were identified above for support.

The main strength of the UCD approach, in my opinion, is that it represents a set of general principles that underline the process of design rather than any specific sequence of tasks to be carried out. These general principles include an early and continuous focus upon users and their requirements, an iterative approach that intersperses design efforts and user testing throughout various stages of the development cycle, and an that emphasis upon operational criteria for usability assessments. While such a philosophical underpinning can lend itself to different types of design-phase sequences, the UCD approach is often used with the fairly standard software design process of requirements analysis, design, implementation, testing, and maintenance. In general, this type of process can be useful to employ in the task of designing web sites. Some modifications should be made in a few areas, however, to recognize the specific challenges involved in creating a hypermedia information product, to emphasize the value of user testing throughout the design process, and to recognize that web design is often carried out in different contexts and by different types of individuals than is the case with traditional software products.

The earliest stages of designing a web site should involve a modified type of requirements analysis suggested by the basic software design model. As the general principles of the UCD approach suggest, much of the emphasis here should be devoted to identifying the prospective audience for the site and specifying what their needs may be. Given the distributed nature of the WWW, and the fact that the audience for a particular site can conceivably be very broad, it is likely that this task can be carried out only at the level of generalities. But as Shneiderman points out, even when broad user communities are anticipated, there are usually underlying assumptions about who the primary audiences may be, and it is helpful to make these assumptions explicit. After identifying potential users, it is also helpful to assess what kinds of tasks they will likely want or need to perform when visiting a web site. How this is to be done is a matter of some controversy. In the development of many traditional software products, a formal task analysis is carried out, and some authors writing about web site design, such as Rice et al., seem to favor such an approach. Other works on software development, however, believe that task analysis can be carried out in a more informal manner, utilizing methods such as user observation or imagined scenarios. I believe that a formalized approach to task analysis is unlikely to be widely practical or appealing to the web design community. As Dillon and McKnight note, "...the fact that hypermedia-based interfaces are frequently being used in novel applications renders it very difficult to perform formal task analysis, specific ally in the context of usage, or elicit user requirements to any degree of precision". While Dillon and McKnight were not discussing the WWW specifically, the extremely distributed nature of the web's user population should only amplify their sentiments. Beyond the fact that the potentially broad nature of web site audiences makes it hard of impossible to conduct formal task analysis upon users, the level of specialized knowledge required for utilizing this method is likely to be absent in many real-world cases of web design. Thus, more informal methods to identify user requirements may be a more realistic alternative.

While the identification of potential users and their tasks should be an important element of the early stage of web site development, care must be taken to also consider the goals and requirements of the site's stakeholders as well Taken in tandem with the information gained through an analysis of users and their tasks, the articulation of the site owner's purposes should help designers identify the basic information content to be included in the site and the types of features that w ill need to be incorporated into the design. Such preparatory work is important to provide a firm foundation for the subsequent design phases in the site's development.

The actual stage of design for a web site should be carried out in line with the general principles of the UCD approach. In other words, the process should be an iterative one that involves developing and testing prototypes at various stages, and the results of these tests should be fed back into the design efforts. But the generalized model of software development identified above, which portrays design as a sort of undifferentiated stage, is not very helpful here, as it provides little guidance about what types of tasks need to be carried out to effectively design a web site's architecture and interface. It is in this respect that the Object-Oriented Hypermedia Design Method (OOHDM) proposed by Schwabe et al. seems to be particularly useful to consider.

Schwabe and his collaborators contend that designing a web site is tantamount to designing a hypermedia application, and believe that their OOHDM model is directly applicable to this process. Their model is partially compatible with a UCD approach, in that the different stages of the design process are "performed in a mix of incremental, iterative, and prototype-based development styles". The central core of their methodology, however, is based upon formal modeling, and the y eschew the type of user testing that we believe is important to include in web site development. Nonetheless, the fact that this model is based explicitly upon the specific requirements of hypermedia development, and the general structure of the design process that they set out makes this method important to consider. For my purposes, the most valuable and interesting aspect of OOHDM is that it breaks the design process into separate "activities," each of which focuses on a different aspect of an application's architecture or interface: concept design, navigational design, and abstract interface design (which are followed by implementation). This general structure, and the specific types of concerns and "products" that they identify as the foci of their different "activities," are very useful to a web design process, and can, I believe, be incorporated within a generalized user-centered approach. But the specific modeling techniques which they employ are probably less practical in the context of the web design community, which seems to be largely comprised of individuals who are not HCI experts. Therefore, we would propose to keep the "outer shell" of the OOHDM model and incorporate it within a user-centered design approach, while jettisoning the methodological core of formal modeling. It should be recognized, therefore, that the discussion of the various phases of the design process that follows represent my own adaptation of the basic OOHDM structure within a user-centered approach.

The first activity suggested by the OOHDM model is conceptual design. In this stage of design, the basic topography of the web site will begin to be specified. The earlier work carried out in the requirements analysis stage should have identified the basic information content of the web site. The primary task at this stage is to organize this content into meaningful and understandable categories. General issues that need to be addresses in this phase are what types of information should be grouped together and how to organize these groupings within some coherent categorization scheme. More specific issues may involve decisions on page length (whether to divide related content into fewer but longer pages, or shorter pages) and labels to be applied to the categories that have been identified. The product of these efforts will be the identification and specification of the information nodes that will constitute the core of the web site.

Even in this early stage of design, it is a good idea to conduct user tests, for as Miller notes, "...the earlier one starts [testing], the larger the payoffs in time savings and user satisfaction". It is quite possible that the designers may have grouped information and created categories in ways that do not make sense to potential users, and their assumptions should therefore be tested. The terminology adopted by designers also needs to be examined, because as researchers like Gray have found, users often understand categories and words to have meanings other than the ones the author intended them to have. One method that can be used as a test of conceptual clarity and terminology is card sorting. According to Nielsen, "card sorting is a common usability technique that is often used to discover user's mental models of an information space",. In designing the internal web site for Sun Microsystems, Nielsen has used this method with a small number of individuals to examine how they think information should be grouped together and what labels they feel should be applied to the groupings. If users have rather different ideas from the designers about how information should be organized within the site (or how items should be labeled), the designers should reconsider their initial categorizations and redesign as they feel necessary.

As was the case with the first stage of the design process, the structural and navigational design phase should be accompanied by user testing. Basic questions that should be addressed in the testing are whether potential users understand the overall structure of the site, whether they can find information in the site, and whether they can effectively navigate between different sections of the site. The tests might be conducted in a free, exploratory fashion, in which users are allowed to determine their own course of action, and designers look for areas of user confusion, slow-down, or mistakes. Or the users can be given specific scenarios and tasks to accomplish, with designers gauging how well they performed. In either case, designers will probably want to ask that users to "think aloud" while they work so that their thoughts are made explicit. Because the site's interface has not yet been developed, the tests will likely have to be conducted through the use of paper prototypes. The use of such "lo-fi" prototypes is widely accepted as being a valid technique for usability testing, and as Nielsen points out, "for some projects, user reactions to prototypes with few or even no working features can give you significant insight into the usability of your design". When using paper prototypes, however, testers must take care to "...explain the limitations and missing features to users. Once this is clear, you can learn a lot from user interaction with what is there -- and learn what their expectations are for what's not". If users experience significant problems with the design that is presented to them in these prototypes, the creators of the site need to make necessary adjustments and test their revisions accordingly.

The final stage of the design process is interface design. While the earlier phases of the site's development have specified it's content, organization, and structure, the site still does not have a "face" to present to a visitor. Developing the "look and feel" of the site takes place in this stage. There are actually a number of different types of tasks that have to be performed here: interface elements (including things like icons, buttons, graphics, etc.) have to be created and selected, basic features of the site (forms, search engines, applets, etc.) have to be incorporated, and all of these things -- along with the basic information content -- need to be combined in detailed page lay outs. It is likely that the stage will be carried out in an iterative fashion, in which successively more detailed and specified interfaces are developed, instead of trying to produce a "final" interface all at once. As Nielsen notes, "current practice in usability engineering is to refine user interfaces iteratively since one cannot design them exact right the first time around".

In this chapter, we have examined the activity of designing World Wide Web sites and how this relates to the field of Human Computer Interaction. Although I discussed at some length the ways in which the medium of the web presents unique challenges to designers -- challenges not yet adequately addressed in the HCI literature -- we have also attempted to demonstrate that the process of developing web sites can be grounded within the existing body of work in this field. In doing so, we have proposed a method for creating web sites that builds upon the several strands from within the HCI literature. (A short summary of this design method is included below) Whether or not this particular model is useful to the people who are actually designing web sites, it is important that these individuals become more aware of what the field of HCI has to offer them. For the vast potential of this exciting new medium is being threatened by the proliferation of confusing and unusable sites. Simon Buckingham Shum feels that "...the Web, as the fastest growing interactive system in the world, offers a golden opportunity for HCI to make a difference". And as the web becomes increasingly important as a means of communication, information sharing, and commerce, we believe that HCI will begin to have a larger impact upon the web design community. The stakes will be too high for this field to be ignored.

Gesture Recognition