Chapter 1: Table of Contents
1. General Concepts & Principles
Understanding the process of designing interactive systems requires an appreciation of the types of "users," their "needs," and the reasons why they want to use a computer. Secondly, it requires knowledge of the task and the ability to decompose the task into those components that are best done by the computer and those that are best done by the human. Only with this foundation can the resulting system become a true symbiosis between human capabilities and machine capabilities.
The objective of this chapter is to define a number of fundamental concepts. These are necessary to understanding subsequent chapters that focus on a "how to" approach to the design and evaluation of interactive systems. A number of the observations in this chapter are key to understanding the various dimensions of interface design dealt with in the next chapter. Other concepts provide an initial framework for categorizing the design process and knowledge about it. Later in the book some of these concepts will be more fully justified, as we explore the underlying foundations for them.
1.1. Interactive Systems vs. Human Computer Interface (HCI) Design
The common term used today to denote this area is "Human Computer Interface (HCI)" design. We have chosen to go back to the earlier term "Interactive Systems" because it is more consistent with our view of this subject. An Interactive System is the total combination of the user, the task, the operational environment, the computer, and the interface. Focusing only on the interface implies that one can design interfaces without any need to concern oneself with the application, humans, and/or the environment within which the system operates. After all humans are very messy and unpredictable and cannot be easily modeled by algorithms. The belief that there is one perfect or optimum interface approach for all users is one that appeals to vendors and many academics. This is certainly a very popular view, but not the one that forms the basis of this book. It is becoming increasingly clear from current research in the area (e.g., Mental Models, Metaphors, and Artifacts) that good design requires an understanding of the total system environment. You cannot separate "what" a system does (functionality) from "how" the user invokes these procedures, and, perhaps most importantly, the user's knowledge and expertise about the task.
Because of the cost of developing software and the general lack of computer literacy among initial users, the past decade has seen a tendency on the part of organizations to buy "off the shelf" software when possible, rather than to develop software. When new software is developed, a cookie cutter approach to designing the interface is almost always used. With the growing sophistication of toolkits to support development and the growing level of computer literacy, it is likely that there will be a swing back to more highly tailored software for individuals, groups, and organizations. The canned templates for lower level interface functionality have almost given people the impression that there is no need for originality or creativity in this area. However, what is really happening is that the need for originality and sophisticated design is being raised to higher level design issues and considerations associated with the nature of specific application domains.
We believe that the Design of Interactive Systems requires a thorough understanding of the application or task, the user or user group and the user’s psychology or the group’s sociology, and the environment in which the system is operating. As a result, the designer must also master some of the basic techniques and methods that can be used to gain an understanding of users and tasks. This user centered understanding (Mantej & Theorey, 1988) also applies to the process of evaluating operational systems for the objective of improving or evolving them. For this reason, the book includes sections on the techniques of protocol analysis, participant observation, interviewing, survey design, controlled experiments, and field trials.
Almost from the start of the field of Computer and Information Science, the commercialization of computers and information system meant that applications were implemented and developed on guts and intuition. There was very little concrete scientifically validated knowledge to guide the design process and knowledge in such areas as Cognitive Psychology had to be re-interpreted in the context of interactive systems, usually based upon a leap of faith. For the first decade and half (i.e., the mid sixties to the beginning of the eighties) very few attempts were made to apply formal evaluation research methods from the social sciences to the study of this area. A few earlier exceptions with respect to the systems and the individuals involved will be discussed later in this book.
As a result, the vast majority of the early writings on interface design were what can be termed as case studies and wisdom synthesis. Typically, someone who designed a "successful" system would write it up along with personal reflections on what factors made the system successful. If enough different designers came up with the same factors, these items became generally accepted wisdom, even though there was no systematic validation of these self-reports.
Since the early 1980's there has been an intensive effort to understand the reasons behind wisdom in interface design and the scope of its validity. There has been a literal explosion of new journals, books, and conference proceedings. It is the objective of this book to integrate the relevant material into a pragmatic text book on design and evaluation.
The proliferation of scholarship on HCI has gone hand in hand with the recognition that today the costs for computer technology are relatively cheap compared to the cost of the time of the people who use the technology. This was not true in the early days of computers and explains the early lack of attention to improving the lot of the user. However, the technology still advances at such a rapid rate that the large gap between knowledge and subjective wisdom about design will remain in existence for some time to come. As a result, this chapter and many parts of the this book contain material that has to be considered as "wisdom" or lore. This means that there is always a possibility of exceptions, cases or situations where the particular classification scheme, guideline, design rule, or approach is not necessarily applicable or desirable.
What makes an outstanding or professional designer is the development of an understanding of the difference between wisdom and knowledge in this field, and the ability to recognize the limitations of guidelines and/or exception situations and how to deal with them. The process of innovation in interface design is often a result of the ability to recognize which current wisdom and guidelines should be discarded or violated in the context of a particular situation.
There are really only a small number of reasons why a person should or would use an interactive computer system. There are also reasons why an individual should NOT use an interactive system in a specific instance. Obviously, understanding which of these objectives dominate or are important in a given system or part of a system is crucial to the design process.
In addition, there are reasons why certain individuals have a predisposition to be negative about having to use computers. Many of these reasons are actually valid and a function of the organizational environment in which the systems operate. While the student might think this is not a concern for design, when they are trying to evaluate their systems they need to understand the difference between criticism based upon design problems and criticism based upon attitudes about computers. Furthermore, the successful implementation of a system requires understanding how to overcome, insofar as is possible, attitudinal problems by policies and practices governing the implementation. We will explore these phenomena in the evaluation and management issues sections later in this book.
The following valid reasons for manipulating a task directly provide the designer a check list against which to ask which of these objectives are best served by the possible functionality he or she can put into the system.
1.3.1. Saving Time
The most commonly used justification or criterion for a well-designed Interactive System is that it saves time for the individual relative to other alternatives for accomplishing the given task. This criterion has other representations that may be utilized in a given organizational situation. For example, it is quite common to reformulate this as how many fewer employees are needed to accomplish the same amount of work or effort. Another common alternative formulation of the same property is to what extent hiring needs can be reduced by providing current employees computer support that increases their productivity with respect to the amount of work done. Not having to spend $50,000 a year on a new employee would allow one to spend $5,000 for providing computer equipment to each of 10 current employees. If the resulting productivity gain per employee is only 10% or more this becomes the preferred management choice. This sort of tradeoff is no longer limited to lower level employees but applies equally to managers, professionals, and even programmers and systems analysts.
Certainly no user is going to wish to use a system that takes longer to accomplish a given task than it takes to do the same task manually. However, there are countless examples in organizations where systems are implemented which add to the workload of the user (Clement, 1994) are implemented. Often this results from the fact that the requirements for the system are not generated by the ultimate keyboard users. Other times it results from the fact that the time users spend learning and using a system is not part of the development budget for the system. If a system gets into trouble during development one can sacrifice functionality that will cost the user added time without having to pay for it.
Unfortunately, the planning and development of many organizational systems do not consider either the immediate impact on the direct user of the system or the long term (secondary impacts) that may result from decreased morale, higher turnover, and the accuracy of the resulting data. Even in 1997 there is estimated to be a 33% complete failure rate for implementations in the average company.
There are many tasks at a computer keyboard and screen that do not necessarily take less time than the manual equivalent. Marking an event in a calendar or a drawing a picture can very well take longer. Reading a large document or a large amount of text still takes longer on computer screens than in hard copy form. Therefore, for some tasks, there must be some added benefit of having the results in electronic form in order to make the effort worthwhile. In the case of a drawing or calendar entry it is the new things you can do with the results or the ease of change that makes people use the computer.
1.3.2. Unpredictable Tasks
This is the most fundamental of the benefits of utilizing an Interactive System. What the user is going to do is dependent upon what results from his or her initial interaction. Even for repetitive type operator tasks, such as "data entry," there is no way of predicting exactly when the operator is going to make an error. The results of the error may well necessitate a change in the user's interaction in order to get it properly corrected. Straightforward tasks, such as composing a memo, can produce the need for rewrites of earlier sentences at any point in the interaction. More sophisticated tasks, such as searching a data base or performing a numerical analysis, are obviously dependent upon initial results in order to determine future user interaction sequences.
The ability of the user to manipulate the sequence of activities in various tasks is the key benefit of the computer in aiding task accomplishment. In light of this, it is strange that many systems make the mistake of imposing a fixed sequence of operations for many specific tasks. But perhaps this is not so strange, when one realizes a single sequence of operations is usually easier to implement. An explicit concern here is how well the computer system can be adapted to match the user's problem solving process, and that it does not force the user to change his or her cognitive processes to fit the programming of the computer. Allowing for a large variation of cognitive problem solving processes in a population of users is a desirable goal. It is made possible today by added computer power to support a richer interactive system functionality. Too often computer professionals assume that the logical process they are taught for decomposing problems to turn them into computer programs is the same process that all human problem solvers should be using for all their complex problems.
1.3.3. Memory Enhancement
Clearly the computer can remember much more explicit information and data than can a human being. It can also take a given structure for relationships possible among the data and quickly examine a large mass of data to determine those instances that match the structure.
Data presented in physical form, such as a telephone book, is usually constrained to one structure (e.g., alphabetical listing by name). However, in the computer we can quickly impose and manipulate the data by any variety of structures appropriate to the task (e.g., reorganization of the phone book by location).
The abilities of the computer to remember large masses of data exactly and to quickly reorganize, summarize, filter, and structure that data as the user needs it represent a direct enhancement of an individual's memory. This property leads to many applications of Interactive Systems that were unthinkable before the introduction of computers. The search engines on the WEB are an excellent example.
The resulting challenge is how to provide to the user the facilities and functionality that makes the system behave as a direct extension of the individual's memory. While one can appreciate the benefits of the search engines on the WEB, probably no one is completely satisfied that they have adequate control in conveying a perfect description of what they are seeking to the engine. In the literature this is a significant part of the fundamental "information retrieval problem." The current efforts to develop general purpose Hypertext systems are a specific instance of attempts to create a better "match" between the users and the masses of data contained within computer stores.
The fact that personal computers now have much larger memories and the ability to handle graphics have opened up the new approach of "visualization" to aid the information retrieval problem. However, this is a problem that will never be completely solved and always open to innovative approaches as will be discussed in a later chapter.
The ability of the computer to dramatically reorganize a large mass of existing data into a completely new view provides the user the chance to apply the cognitive technique of changing the problem representation. This is considered one of the fundamental approaches to creative problem solving. It is because of the computer's ability as a tool to aid cognitive processes that we are now able to provide direct aids to humans for the improvement of problem solving skills.
The concept of memory enhancement includes the ability to enhance the memory of a group. At one time this concept was called "community memory," and today it is called "organizational memory" (Walsh & Ungson, 1991). As we shall explore later in this book, the concept of a group or collaborative memory extends our design concerns to understanding the complete range of social interactions of a group. In the organizational setting we are talking about the ability to capture the lore of the organization.
1.3.4. Quantity and Speed Enhancement
The processing power of computers leads to the observation that an obvious benefit is to allow individuals to greatly increase the quantity of a given task they can do, or to considerably speed up the completion time for a given task. While this may seem obvious on the surface, the realization of this benefit for users is not quite as simple as it sounds. Users who develop "programming" skills can teach the system what it is they want it to do in a repetitive manner. Preferably, one would like to have systems that are able to learn and accumulate the micro tasks that users undertake into macro routines. To date, the only widespread instances of this type of capability are where there exists a well-understood model and structured representation of the user's task (e.g., spreadsheets to support accounting and statistical calculations).
The processing power of the computer also changes the nature of the work we do. A hundred years ago it was quite acceptable for an applied mathematician to spend years calculating a new numeric table of a function (e.g., logarithms) needed for some application. In fact, the task for which one of the first US computers was built was to generate the firing tables for artillery pieces. Today, such tasks can be done very easily by a high school student using a personal computer. Because computers change the nature of the work one must view an interactive system as an instrument of change that will impact upon the environment for which it is produced.
It is still very much an open challenge to designers to bring the processing power of the computer under the control of the user. Consider the user who has everything he has ever written stored in his personal computer. Can we provide facilities that will allow him to teach the computer how he likes to organize material about a given subject and to automatically carry out that reorganization as a single operation? This requires not only the incorporation of a structure for the task, but one that is tailorable by the user on an evolving basis.
1.3.5. Tool Flexibility
From a global perspective one can view a computer as a toolbox of capabilities provided to the user. The potential size of this tool box is so vast that the metaphor begins to break down when one considers both the implications and the challenge. For the user, this ability to provide a large host of tools to augment mental abilities means that the user can undertake a significantly greater variety of tasks and efforts than he or she could otherwise contemplate. This, in itself, is not usually obvious to users and is only realized as they begin to evolve their work environment over time. It is one of those hidden benefits that is rarely used to justify the introduction of systems, but often has the greatest long term benefits to the users and the organizations that employ them.
The first few generations of computing in organizations produced an increasing trend of specialization of jobs (Mowshowitz, 1976). The era of mainframe computing and systems analysis led to the fundamental reduction of processes to those that could be done by computer and those that could be done by humans. In order for humans to keep up with the machine they had to be re-organized in their work environment to do more narrowly specialized tasks. The lower costs of computing and the Personal Workstation now make possible the generalization of work processes, because employees can be provided a general tool kit for performing a wide variety of tasks. Whether or not organizations which have evolved for two decades in a direction of increased job specialization and centralization of authority can recognize that a major shift of direction is possible, is a very open question.
The challenge that results from this benefit is the need to integrate these tools and to allow the user to master them both on an individual basis and on an integrated basis. More typically today, the user is faced with a wide range of different interfaces for each tool and different internal data structures for each tool. The relative success of windowing and of associated "cut and paste" capabilities results from a growing recognition by users of the need to transfer work between different tools. However, we have only begun to scratch the surface with respect to the need for integration facilities to support interactive systems.
1.3.6. Collaboration & Coordination
Computers have become communication systems and their ability to act as communication and exchange facilities has become as important as their abilities to process and remember data. Increasingly, networks of workstations and computers allow groups of individuals to collaborate in order to carry out their task objectives. As a result, the designer must now also be concerned with understanding tasks at the group level, as well as at the individual level.
The literature on interactive systems and Human Computer Interfaces often refers to the problem as one of designing a communication process between a human and a computer. However, the usual scope of interface design rarely treats communication as an explicit or primary objective of the design. It may very well be that the primary focus of interface design should be to focus on communications and to treat the functionality of communicating with humans and with various computer resources as a consistent and integrated functionality. A communications-oriented metaphor should probably be the foundation for improved user interfaces to operating systems. The computer can become an active "agent" keeping the user informed of those transactions occurring which might influence what the user wishes to do. These transactions can be the result of the actions of other programs, other computers, or other humans.
1.3.7. Doing the Impossible
There is a growing recognition that we can do things with the computer that would have otherwise been impossible. Creating a model of a complex organic molecule and viewing it as it interacts in a chemical process is one example. Another is the example of building a model of an assembly line and the ability to modify it to examine different configurations and their impact on production. The computer allows us to model and simulate complex situations so as to improve our understanding of those situations and the alternatives involved (Rubinstein, 1975).
We can go an important step farther and create environments within the computer that have no existing or potential counterpart in the "real" world. We can deal with data and models in a multidimensional context. When we take something we think we understand and move it to the computer environment, it can behave very differently than its real-world counterpart. This realization has become general enough that the current term for this phenomenon has become the creation of "Virtual Realities." Games are only the first widespread instance of this concept and computer based ability.
In the commercial world, the growing emphasis on "strategic" applications of computers is a recognition of the same phenomenon in more conservative terms (Clemons, 1991). It used to be that the only types of systems that could be implemented in organizations were the ones that could be sold as an automation of what was already being done. Today, the pendulum is swinging in the other direction, and the basic question is how can the computer allow us to do things that have not been done before and which will improve the competitive situation. The result of this shift of management perspective is an ability of designers to break out of the straight jacket of systems that merely improve the efficiency of what is already being done, to be able to consider new and very different applications that have never been done.
The more general concept operative here is the concept of "virtuality" (Turoff, 1997). Today it is impossible to separate interactive systems from their user communities. Over the long run the computer imposes a template on its users and encourages them to change their behavior. This property of taking the virtual model in the computer and using it as a template to modify the real world so it becomes like the virtual one, is the property of computer systems that we refer to as "virtuality." It is the potential the computer system has to modify the real world.
1.3.8. Enjoyment
There is no reason why an interface should not be fun and enjoyable to use. Every designer, at least implicitly, wishes that his or her interface design would become the first "Pac-Man" for that particular application. Certainly, even such things as how one words error messages can influence users' feelings about the system and whether they consider their sessions a pleasurable or discomforting experience. User satisfaction is an important dimension for the evaluation of interactive systems which will be treated in depth later in this book.
There is always a clear and present danger that a system could be designed to be so much fun that it detracts from the user concentrating on his or her task. Some of the underlying dimensions that govern the properties of games (i.e., competition between the user and the computer) are not necessarily a desirable dimension for the user accomplishing a specific productive task.
For some users a system that is too easy is not considered enjoyable because there is no challenge. Games are not easy but the more successful ones usually the user to set a level of difficulty or challenge and there may be an analogous approach for other types of systems.
1.3.9. Sublimation
People utilize computers as a mechanism for escaping from the "real" world. People who work in environments where it is very difficult to accomplish anything meaningful and where considerable human communication problems exist often find the computer to be an escape from the problems of the organizational environment. The psychological feeling develops on the part of users that they are accomplishing something. The computer is responsive and interacts with them, whereas their fellow employees and the organization do not. In a larger context this phenomenon can provide the impression of a successful design that is merely a sublimation of deeper problems with the organizational climate and the effectiveness of the application. The virtual world of the computer is more pleasing and easier to deal with than that of the organizations they are in.
Independent of the above or in conjunction with it, many individuals do ascribe human properties and values to their computers. Just as cars can become a psychological extension of the individual, so can computers (Turkle, 1984). The computer can become, in the mind of the individual, a helper, a boss, a magician, an ogre, an accomplice, a supervisor, a slave, or just about any role fostered by a combination of the system design and the application environment. Users can easily become digital "hot rodders" or "hi-fi technology buffs." This includes managers, as well as professionals, who may come to appreciate the colorfulness or artistic value of their computer presentations more than the content.
On the other hand, there is no reason why a computer should not be fun to use even when accomplishing productive work. For example, organizations that have policies that prevent the use of systems for socializing (e.g., personal electronic mail) do not understand that socialization is an important component in building cohesive teams that work well together. Making an interface that is fun to use is the unspoken goal of most designers. All designers would like users to become addicted to their design, even if they don’t explicitly realize this. The incorporation of hidden "secrets" by developers is one personification of this phenomena.
1.3.10. The Satisfaction of Being Busy
Interaction with a computer is definitely a physical reality. A person manipulates symbols on a screen and can see things actually happen as a result of the effort. Also, the sense of accomplishment is fairly immediate. It is concrete, rather than abstract. As an example, direct manipulation of a problem at a micro level may be more satisfying to the user than using an abstract macro command to accomplish the same functionality in one operation. The computer can provide the same sort of satisfaction an artisan obtains in creating a physical object or that a gardener perceives in the sprouting and growth of a cultivated plant. Personal preference of an individual about how to accomplish something is fine, even if the method chosen takes ten times as long. However, when the individual is part of an organization and being paid for time and effort, it is not quite so clear cut that this is consistent with the goals of the organization.
On a more global scale, the issue is one of whether a manager or professional, costing an organization a hundred thousand dollars a year, or more, should be spending considerable lengths of time at such tasks as text editing. Users do not necessarily do things the most efficient way possible but compromise this objective with feelings of satisfaction based upon a sense of accomplishment, real or imaginary. The design of the system can certainly influence these types of tradeoffs. The computer can be a siren that entices the user into an affair that is so intense that the rest of the world is lost from focus. It might take an executive a week to build a model that a professional programmer could have done in a day, but it is the executive's creation from start to finish.
In one of the early experiments it was found that managers preferred looking at large amounts of raw data even when they made the decision just as well when they looked at only summary data. The difference was that they had more confidence in the decision using the raw data. It is not really the prerogative of the designer to preempt the choice of the user in such tradeoffs.
1.3.11. Solving the Wrong Problem
Vendors tout the computer as the solution for any organizational problem which may exist. Computers are likely to be counter-productive if human and social problems are the primary cause of an organization’s inefficiencies or lack of performance. In one long term study of industrial productivity it was found that companies that were both the most productive in a given industry and who invested heavily in computers became even more productive. However, companies that were the most unproductive and also invested heavily in computers became even more unproductive (Strassman, 1990). The primary measure of productivity for a single industry was the amount of revenue relative to the cost of managerial salaries (i.e., management productivity).
Computers create a virtual world that MAY or MAY NOT actually correspond to reality. Moreover, many organizations have not been terribly successful at validating the reality of the virtual world they have created in their management system. The result is that many organizations base their decisions on virtual representations of the real world for which they have no measure of validity.
There are times when faith and a belief in progress are a reasonable approach to deciding to invest and obtain improved computer and information technology. Providing more power and capability can open the doors to new applications and can enhance the morale and effort of employees. However, computers should never be justified on the basis of being a solution to human or organizational problems. For example, introducing improved electronic mail systems will not improve communications among organizational units that do not want to communicate.
1.3.12. Quality Improvement
Productivity is the product of the amount of work times the quality of the work. Too many times we talk of productivity as quantity changes because this is easier to measure. Being able to generate more text lines as a measure of word processing is not the real question. The real question is whether we are turning out higher quality documents. Providing individuals the ability to improve the quality of what they do is the highest goal obtainable for a designer. This is the goal that should always be in the mind of the designer as he or she seeks to define the design of the system.
All the factors that explain why we use interactive systems can be examined by whether they improve user processes, goals, or flexibility associated with specific user tasks. Process changes are the easiest to measure and therefore have had the most attention. Designing to improve user flexibility or goal attainment usually has to be taken on faith, as these are far more difficult to measure.
For example, it is possible with the use of computers to support design work to capture and play back the sequence of design creation process. This is almost impossible to do when using paper to do design. A finished painting cannot be used to determine the creation process. Does the ability to capture and exhibit the design process allow for the creation of support systems that will improve the quality of the design?
1.3.13. Summary & Strategies
Throughout the book we will be discussing different design strategies. Some examples of those which are directly responsive to the above objectives are given in the following table.
|
Objective |
Strategy |
| Saving time | Reduce user actions, creation of macro capabilities |
| Unpredictable tasks | Richer reactive action sets |
| Memory enhancement | Application oriented data structures, information retrieval techniques |
| Quantity & speed enhancement | Higher abstraction level control |
| Tool flexibility | Tool box and tool kit orientations, Flexible subtask sequencing, understanding of problem solving strategies |
| Collaboration & Coordination | Task tracking & prediction, communication structures and protocols |
| Doing the impossible | New functions and tools, understanding of application and cognitive processes |
| Enjoyment | Novelty, Challenges, and flexibility |
| Quality improvement | Combinations of above, higher level aids for data and decision analysis, no sure fire approach |
Our problem is basically one of how to establish a communication process between a human being and a computer. On a relative basis, the two exhibit very different "cognitive" behavior:
Communication Atmosphere
| HUMAN | COMPUTER |
| Slow | Rapid |
| Sloppy |
Rigorous |
| Forgetful | Precise |
| Implicit | Explicit |
| Inductive | Deductive |
| Brilliant | Stupid |
It is hard to conceive of a greater mismatch between two communicating entities. If these were the properties of two humans the only solutions would be to avoid the need to communicate or to make the first one the master and the second one the slave. This is the approach that is usually taken and is the most common one for providing satisfaction for the human user. However, there are certain instances where it can be desirable to make the computer the master or facilitator. This has been the case for lower level work such as data entry. Unfortunately, that approach has carried over to higher level work and many users end up feeling like slaves to the machine. As we shall see throughout the book, many of the principles and guidelines for the design of the interface revolve around overcoming this mismatch.
As users gain in "computer literacy," they also gain an implicit awareness of the above properties of computer systems. Along with this comes a healthy mistrust for non-understandable "intelligence" on the part of the computer. This explains the reluctance to utilize many of the more elaborate expert systems that do not provide any insight into the process whereby they arrived at a result. The more expert the user the less likely he or she will trust an expert system unless the solution process is made explicit. There is a healthy mistrust of solutions that do not appear explainable to the user. In the early days of computers, most vendors and even some professionals tried to convey the atmosphere that computes were too difficult for average mortals to understand. Some of this trend toward enshrining the computer can still be found in the commercialization of intelligent systems. It was an early selling technique that is unfortunately still utilized.
In the earlier days of interactive systems, the limitations on equipment were quite severe. Today the capabilities available in personal workstations are almost unlimited relative to the vast majority of potential applications. The exceptions are in such areas as high resolution animation, engineering design, large scale numerical work, high resolution multimedia integration, and large scale integrated and shared databases. There are still very significant applications for larger mainframe computers and centralized hosts.
The designer can expect (at least in organizational situations) the Personal Workstation to include many megabytes of core, many MIPS (Million Instructions Per Second) of processing power, high resolution color monitors, and broad band communications among the workstations and between the workstations and larger computers. The one major change to expect in the near future is the availability of low cost writeable optical disk units that will impact on multimedia applications and personal storage capabilities.
No matter how powerful the technology, a rule of thumb is that there will always be some applications that are too demanding for the available technology. Today it is graphics, virtual reality, animation, and image processing which are pushing the demands for more powerful systems.
Furthermore, there are user behavior patterns that further saturate available hardware. For example, the tools to help users "forget" (delete) information are not yet available and thus users are unlikely to delete old files. As result, no matter what amount of memory you provide users, they will eventually fill it up. The problem of helping users forget is still a very open research issue.
1.4.2. Stages of User Evolution
New users of a particular system go through a number of phases in their interaction. The following four phase model (Bennett, 1972) is not the only possible classification but does serve to illustrate a number of points about the evolution of a user when learning a system. The designer and/or the evaluators of a system need to understand which phase a user is in to be able to accurately interpret the reactions of the user.
1.4.2.1. Uncertainty Phase
The uncertainty phase represents the first reaction to the possibility of having to deal with a new system. It is characterized by the fact that the user does not yet know enough about the system to accurately judge the degree to which it will be useful or not useful. Hopefully, a user realizes this and does not have a prior bias brought about rumor or inaccurate claims about the system.
Only when a user determines that a system is potentially useful will they expend the effort to learn how to use it. The designer's objective is to insure that this phase will be as short as possible. If users run into trouble before they are positive the system is useful, they are likely to give up on it. Therefore, the designer wants to be sure that he or she understands what are immediately useful tasks for the user, and to make it clear through the interface that these can be accomplished by the system. Unfortunately, too often the system is oversold and the user expects it to be useful, goes through the effort of learning and then discovers it is not. The result of such a scenario is significant mistrust about future systems provided by that unit of the organization or by that design and development group.
In this phase the users are unlikely to complain if they run into problems. They will just turn their backs on the system and walk away. There is a lack of motivation to make the effort to complain. Any complaints that do emerge are very likely to be verbal excuses to others, not the designers, for deciding not to learn or utilize the system.
The first decision a user has to make is whether the system is worth learning. The degree of potential value the users perceive will determine how much effort they are willing to make to use it. If they do not immediately perceive potential value from learning to use the system they will say it is "nice" and then walk way because things that are "nice" are not often interesting.
1.4.2.2. Insight Phase
The insight phase begins with the user reaching the informed conclusion that the system will be valuable or not valuable. If the system is judged as valuable users are willing to expend some level of effort to learn how to do what they wish to accomplish. This is the phase where the user will invest a lot of time and effort in learning those parts of the system associated with the tasks they wish to accomplish.
In this phase it is actually a good sign if the user complains about some problem or discomfort with the interface. It takes effort to complain and that effort is a sign that the user feels the system is sufficiently valuable to try to get it corrected. Obviously, the problem for the designer is to determine if complaints are arising from beginning users in the uncertainty or in the insight phase. The users to be concerned about in this phase are the ones who provide no feedback, and some form of evaluation has to be utilized to correct the situation. Automatic monitoring that lets you determine what functionality a user is using and what errors are most frequent would be the most informative. Hopefully extensive protocol studies of the pilot system users would have caught and minimize most difficulties. In that case the major difficulties that emerge later have to do with the learning process and on-line aids.
It is in this phase that it is critical that the system be "easy to learn" for the tasks of interest to the user. As we shall see in the next chapter, this phase is measured by the degree to which a user obtains a state of "comprehension" for the system.
1.4.2.3. Incorporation Phase
The incorporation phase occurs when users have made the system a regular part of their information processing behavior. The system has become a tool of the user. While there may be many different modes of behavior or types of users, in this phase the use is regular and consistent. It sometimes surprises designers how nonchalant or blasé users are about the systems they use. They often view interactive systems as if they were another type of telephone or hammer. They definitely have no appreciation of the effort it might have taken to produce this new tool, nor the care that may have gone into the design. It is the regular and willing use of the system that is the sign of success and that must satisfy the designer, even though it may seem unappreciative. The more invisible or transparent the mechanics of the interface can become for the user, the better. During the incorporation phase, the users can evolve into a very diverse population of user types.
Studying the different patterns of usage that characterize this phase provides useful information for determining the evolution of the system and the next phase of any iterative type development process.
1.4.2.4. Saturation Phase
The saturation phase is the point in the evolution of the use of the system where it no longer provides all the functionality the user wishes to have. In any population of users there is always a small percentage of users that reaches the saturation phase long before the rest of the user population. It is critically important to the long term success of the system to identify those individuals and to utilize their inputs in planning the evolution of the system. When a significant portion of the user community (like 15%) reaches this stage, it is often said that the system is starting to "die." Monitoring of individual usage and the functionality being used together with regular surveys of users can be used to systematically identify users entering the saturation phase. This does not mean that just adding any new functionality is the answer. One still has to identify the functionality that these advanced users will find useful.
Once about a third of the users reach saturation it is probably going to be too late to do an incremental development and a major revamp or new system development becomes necessary. The system is already dead but doesn’t know it. At this point one can expect a lot of users to consider those they think responsible for the situation to be fairly incompetent. In many organizations it is not always easy to have accurate accountability for such situations. Most good designers can recognize such situations and desire to improve their systems but they do not control the budgeting of the resources. But some organizations are more than willing to let them take the blame. This will be discussed much further in the chapter that deals with management issues.
In the earlier days of Interactive systems it was common for the designer to formulate a stereotype of the user to represent the entire population for which he or she was designing. This was driven by a number of factors. First, it was going to be a major software effort to develop a single system and anything that added requirements to the software development effort was taboo. Secondly, there was an implicit belief that there was a single model for human behavior that could be developed and understood to determine the ideal design for all users at the same basic level of aptitude. Everyone wants to design the universal "model T" that will be used by all. Third, it was felt that in an organizational environment one expects all the individuals in a given job category to be required to perform at an expected common level. The training of technical people in the computer field tended to idealize the existence of optimal solutions, with little accounting for human diversity. Furthermore, many early systems for single repetitive job types like data entry clerks or reservation operators. The great efficiencies of these early systems help solidify this attitude toward design.
The earliest classification of user types was the concept of a scientific user versus a business user. Later, this was expanded to talk about users by their application (e.g., data entry operators, secretaries, word processing operators, managers, executives, etc.). It is still rather popular to try to imply that executives require uniquely different systems (EIS = Executive Information Systems). This application-oriented approach has become a dead end in conceptualizing users. Human diversity cuts across any single application area. No one executive, manager, or engineer has exactly the same way of utilizing and viewing data as any other executive, manager, or engineer. However, the industry still seeks the singularly perfect design in a manner analogous to the myth of the Holy Grail.
While there was early recognition of human cognitive differences, the general attitude that prevailed was one of: "So what, we don't have the resources to develop systems to handle that!" With the emergence of the Personal Computer and a marketplace in application software, those who develop systems for this market can no longer afford to have such an attitude. As a result, there is considerable recognition that the interface must provide for a variety of types of users. There are certain functional classifications of users that have survived the test of time and need to be considered in the design of most systems. These are the user types that exist in any large population of users: novices, casual users, experienced users, intermediaries, frequent users, operators, etc.
1.4.3.1. Novice Users
The Novice user is the person who is new to the system or to a part of the system he or she is trying to learn for the first time. The novice who is already using other Interactive systems faces the problem of inconsistencies between these other systems and the new one. It is quite easy to learn to use a text editor when it is the first you have ever used, and very difficult to learn a text editor when it is the second. In many situations the designer is forced to adopt conventions from existing systems so that the interface will be more easily learned by the existing user population, and thereby more readily accepted.
This can occur even when the conventions are not the best way to do something. The most obvious example is the standard keyboard layout that was originally created to slow typists down so they would not foul the mechanical parts of the typewriter. While keyboards designed to even out the distribution of keystrokes among the fingers and thereby increase throughput do exist, no one would force employees to convert to them. This is just one of many examples where the environmental constraints impose limits or constraints on the design process.
Novice users who are new to computers are one of the most difficult of the user population groups in the sense that those individuals in organizations who are not already computer users probably already have a bias against the direct use of computers. Some of these biases are justified and will be explored later in this book.
Given a reasonably well designed interface, the interface becomes secondary to the issue of motivation. It is the motivation of the novice user that is critical to whether or not she will expend the effort to learn the system. The degree of motivation will be dependent upon how the system was presented to the user before she or he ever began to use it. While lower level employees can be ordered to utilize a system, this is not true of the professionals and managers who are the major audience for the systems being designed today. The result is that one has to pay very careful attention to the "marketing" effort and to the initial involvement of the users in the design and development process. In many evaluation studies the expectation of the user with respect to the promise of value from the system that the user perceived before using the system, was a strong determinant of ultimate usage (Hiltz et. al., 1984). Those who thought it would not be valuable never used it and those who thought it would be useful become active users. This is true even if the interface is poorly designed. The actual interface influences only those who do not have strong negative or positive motivations before beginning to learn the system. Madison Avenue knows what it is doing to promote a product but the staying power of the product ultimately depends upon actual performance.
1.4.3.2. Casual Users
Casual users use the system only a few times a week or less. In effect they are continuous novices, in the sense that they will not retain much of what they learn about the system during these interactions. It is extremely critical to provide an interface that is very straightforward and clear so that these users can accomplish their tasks with a minimum of knowledge. It is also critical that casual users can easily get on-line help that is specific to any single response they may be required to make. For them help has to be very specific and very concise.
Casual users do not have any ambition to master the system and may often prefer to be led by the hand to accomplish what they need to do. They may feel more comfortable with the computer in control of the interaction. Casual users may undertake a wide variety of tasks in an unpredictable order.
1.4.3.3. Experienced Users
Experienced users are those who come to know the system well and use it on a regular basis. Their view is most important when it comes to determining what can be done to improve or evolve the system. Experienced users are highly concerned with what can be done or utilized to make their interaction more efficient.
Experienced users seek to master the mechanics of the system so that it is second nature to them. Hopefully they find that their concentration, while using the system, can be applied to their task, and not on how to go about doing it. They usually cannot tolerate the same sort of interaction style that the novice or casual user would prefer. They require a concise form of interaction that provides an operational goal of maximizing output relative to minimizing input.
An important subclass of experienced users are those who understand all the facilities available to them within the system and have discovered things they would like to do that the system cannot accommodate. These are the things that point to how the system can be evolved to be more useful to its community of users.
1.4.3.4. Intermediaries
These are the users who are doing a job on the system for someone else. Typically a manager tells a subordinate to do something such as find some data in a database. From one view, this is a sign of failure in that those who have designed the system would prefer the end users to be the direct users. From another point of view, if the task requires a lot of time spent in exercising the mechanics of the system, it is not a system for use by higher level employees.
Intermediaries usually have no direct concern with the task and would like to accomplish it in the easiest and quickest possible way. They usually also have no interest in mastering the system. As a result, the intermediary has attributes and requirements similar to the casual user. Furthermore they often do not want to gain any mastery of the application itself. The data they are gathering or the analysis they are doing will be meaningful to someone else and not to them. They would prefer some degree of intelligence about the task present in the interface. They do not want to design or tailor a report, they want to get a report that has already been designed by others. Any help they need has to be very specific and very concise.
1.4.3.5. Frequent Users
Frequent users utilize a system as an everyday part of their information handling activity. They are the ones who most need to discover the most efficient way to do specific tasks and to automate the mechanics of carrying out those tasks. They are willing to experiment, learn, look at new parts of the system that might aid their tasks. They will gradually over time extend their knowledge of the system. Frequent users have some number of tasks that are done very often; as a result they will appreciate any facility the system provides to cut down their effort. This follows from what some believe is a general principle of human nature (Zipf, 1949) on both an individual and collective basis:
The more frequent the task, the more the human tendency is to evolve a minimum effort to carry it out.
Frequent users may understand only the part of the system they need to use and may not seek to evolve into experienced users.
1.4.3.6. Operators
Operators are those who do a high degree of repetitive work for long periods of time. These are individuals whose primary job function is to sit at a keyboard and deal with repetitive tasks. Classically, a data entry clerk is a canonical example of an operator. Interfaces for operators can be highly specialized and tailored to the specific task. Operators can be put through training programs which eases some design problems. Usually, the designer is trying to minimize the time and/or effort needed to do the task with the constraint of encouraging error free operation. Operators should be assured the best possible human factor conditions with respect to such things as lighting, furniture, etc. Those with bifocals should be provided trifocals and wrist supports should be mandatory for anyone who spends a majority of the day on a keyboard.
1.4.3.7. Routine Users
Routine users settle into regularized use of the system for a specific set of tasks. Beyond that point of mastery, they show no inclination to learn more about the system. They have found a plateau of utilization and lack motivation to learn more about the system or employ it for other tasks. Whether this is good or bad, depends on the sort of understanding that can be obtained only by a careful evaluation of the behavior of the users in this category. For certain tasks and job environments, mindless routine may represent an entirely proper response to the situation. Routine users are not necessarily frequent users of a system. It is sometimes difficult for designers to realize that there will be users who will have little appreciation for the system or for learning more than is absolutely necessary for carrying out their job. The most sophisticated computer system may be viewed as only another form of a piece of paper and pencil.
1.4.3.8. Problem Solvers
These are individuals who are dealing with relatively complex problems that require the solution or execution of a multitude of sub tasks in unpredictable order. These users are characterized by a very high degree of cognitive variability in the tasks that they do. The way this type of user can engage system can be highly unexpected. As a result, this type of user can end up doing a task in a highly inefficient manner because the designer did not (and usually could not) predict what type of task or sequence of tasks would be done. In an otherwise well designed system one common way to detect this user is to look for individuals who are making notes on paper as they use the system. This usually indicates that the designer did not place the information on the screen that is crucial to the user at that point in the task. Any type of note taking while interacting with the system is a sign of a potential limitation in the interface that should be investigated.
Problem solvers are actually harder to detect then "saturated" users because they may not realize they should be complaining about some of things they have to do in order to accomplish their task. This type of user does not necessarily have to be computer literate. Rather, they are very task literate and are often considered experts in their application area. Users can be so pleased at having achieved a solution to their problem that they will not perceive difficulties they encountered as possible shortcomings of the design. Solving a problem is a valuable experience and even though the system may have an inappropriate interface, the user may still perceive it as better than other options for dealing with the problem. Typically, problem solvers accomplish on computers entirely new ways of doing things with a system.
1.4.3.9. Power Users
These users have considerable experience and knowledge of computer systems. Their primary interaction style is to master the whole system and to make use of any advanced features that allow them to carry out what they want to do in a more efficient manner. Their typical learning mode is trial and error learning and the user considers it an affront to their self esteem to have to open a manual. On the other hand, some power users will insist upon reviewing the whole manual before using a system. They often prefer a reference style manual that presents the system as one would a programming language.
Power users typically believe they know as much about interface design as the designer and will insist they know how the system should have been designed. The designer has to be able to explain the reasons behind design choices to be able to gain the respect of this user group. These are also users who are very likely to reach saturation and are individuals whose cooperation will be extremely helpful to the designer in the future evolution of the system.
Those power users who also can program, will often work around problems they encounter by programming a solution to it. As a result, they may not ever report the "problem" to anyone. These are the users who literally change the interface to suit their needs and preferred interaction style. Since the majority of users are unlikely to fall into this category, it is important to track down these improvements and determine if they should be incorporated into the base system for the benefit of the other users.
1.4.3.10. Real Time Users
There are users who must interface with a computer during their efforts to monitor and control a real time process. Airline pilots, nuclear power plant operators, flight controllers, and assembly line controllers or inspectors are examples. Interface design in this environment can have many added complications due to the conflicts in attention that the user has and the possibility of having to operate under high stress situations. The user is working with a process occurring in real time and is under time constraints to make certain observations and act on them if necessary. The design of such interfaces is extremely demanding in terms of the user testing that is needed prior to real operation of the system. One has to be able to mock up and test all stress producing situations and the final system cannot tolerate any critical errors.
Certainly a person playing an action game is acting in this user mode. The technology of virtual reality and animation is reaching the point where the users of such systems may also be classed as real time users. For a long time this technology was too expensive in terms of personal computers and could only be found in commercial trainers for such technologies as planes and ships. People have a natural cognitive ability to make a trade off between speed of action and number of mistakes made. Understanding this tradeoff is very critical to designing interfaces for this user mode.
1.4.3.11. Concluding Observation
It should be clear at this point that a population of users for any given system is usually quite heterogeneous with respect to skill levels, mastery of the system, and types of functionality utilized. It is almost impossible to conceive of a single interface approach or style that will satisfy this multitude of user types. As a result, most systems that are reasonably "rich" in functionality will offer a variety of interface approaches. The typical mixture chosen is some form of menu interface to satisfy novices, casual, and intermediary users, and some form of commands to satisfy frequent and routine users. To satisfy power users one usually has to provide at least some limited form of programming such as the ability to tailor personal macros.
Before the advent of personal computers, it was quite common to design systems that were considered to be only for highly skilled professionals. Most operating systems were designed this way, and one that is always criticized for user unfriendliness is UNIX, a system specifically designed for the professional programmer. The following is short story that was circulated over the ARPA network in 1983 by an anonymous source. It conveys the classic difficulties of systems designed for professional computer people:
Subject: A UNIX nightmare
From: A. N. Onymous <Unknown@SU-Score.ARPA>
Last night I dreamed that the Real World had adopted the "UNIX Philosophy."
I went to a fast-food place for lunch. When I arrived, I found that the menu had been taken down, and all the employees were standing in a line behind the counter waiting for my orders. Each of them was smaller than I remembered, there were more of them than I'd ever seen before, and they had very strange names on their name tags.
I tried to give my order to the first employee, but he just said something about a "syntax error." I tried another employee with no more luck. He just said "Eh?" no matter what I told him. I had similar experiences with several other employees. (One employee named "ed" didn't even say "Eh?," he just looked at me quizzically.) Disgusted, I sought out the manager (at least it said "man" on his name tag) and asked him for help. He told me that he didn't know anything about "help," and to try somebody else with a strange name for more information.
The fellow with the strange name didn't know anything about "help" either, but when I told him I just wanted to order he directed me to a girl named "oe," who handled order entry. (He also told me about several other employees I couldn't care less about, but at least I got the information I needed.)
I went to "oe" and when I got to the front of the queue she just smiled at me. I smiled back. She just smiled some more. Eventually I realized that I shouldn't expect a prompt. I asked for a hamburger. She didn't respond, but since she didn't say "Eh?" I knew I'd done something right. We smiled at each other for a little while longer, then I told her I was finished with my order. She directed me to the cashier, where I paid and received my order.
The hamburger was fine, but it was completely bare... not even a bun. I went back to "oe" to complain, but she just said "Eh?" a lot. I went to the manager and asked him about "oe." The manager explained to me that "oe" had thousands of options, but if I wanted any of them I'd have to know in advance what they were and exactly how to ask for them.
He also told me about "vi," who would write down my order and let me correct it before I was done, and how to hand the written order to "oe." "vi" had a nasty habit of writing down my corrections unless I told her that I was about to make a correction, but it was still easier than dealing directly with "oe." However, at one point I said something wrong and everything "vi" had accumulated for me disappeared.
By this time I was really hungry, but I didn't have enough money to order again, so I figured out how to redirect somebody else's order to my plate. Security was pretty lax at that place.
As I was walking out the door, I was snagged in a giant Net. I screamed and woke up.
END
UNIX has often been characterized as user unfriendly. This is not the point. UNIX typifies a system well designed for sophisticated computer experts who understand the application functionality of operating systems and wish a very efficient set of keystrokes to control and manipulate the operating systems. Names of commands in UNIX were chosen to minimize keystrokes and to exercise relative specificity of terminology rather than using familiarity. However, for people who do not know basic operating system principles it is easily seen as a nightmare.
Given sufficient resources it is possible to design systems with a wide variety of interface alternatives that can cater to the rather large range of user types we have specified above. The real challenge today lies in the difference between experts and novices in a given application area. A novice musician can play music effectively given a CD player; on the other hand, an expert musician needs an instrument such as a violin. It is the range of the user's knowledge of the application area that is the designer’s greatest challenge. Too much "successful" software today is designed for the people who are not experts in the application area. They make up a much larger market than the application experts. In an organization the quality payoffs will be made by the experts in an application area, not by the novices. We will confront this problem in many different ways throughout the book. The designer always has to realize whether he has to create a CD player or violin. In the real world to day, he or she has to often be doing a both to various degrees for the same system.
1.4.4. Information Domains of Users
In the design of systems it is useful to have some way of categorizing the information processing objectives likely to be undertaking by users. The following types of tasks are presented in order of roughly increasing functionality or "richness" of the system that must be made available to the user in an "integrated" manner to effectively deal with the particular information domain.
1.4.4.1. Single Function Tasks
These are very simple, directed, and limited tasks such as performing a small calculation, making a specific query of a data base, sending a message, or writing a memo. They are usually well defined and often represented as "strategic" choices available in the starting menus. Users engaged in carrying out this level of utilization can usually be satisfied with very clear and limited interfaces that focus on tasks at the macro choice or command level that corresponds to the users' view.
1.4.4.2. Structuring Tasks
These are tasks involving the restructuring of information, such as sorting, merging, organizing, filtering, and summarization. These processes usually require a combination of facilities available in the given system. Most of the time they cannot be handled by a single function or choice, but the system needs to allow different users to sequence the same set of functions in different ways. Composing a tabular report in a spread sheet, or separating the messages to be read from the junk mail are typical examples. Structuring tasks require more micro level capabilities which can be combined in many different ways to carry out specific user tasks.
1.4.4.3. Status Briefing
This is the process of obtaining regular reports of data that are useful to the user or various groups of users. Report generation is probably the single biggest application of computers in organizations today. Allowing users to tailor report generation usually requires some form of scripting or limited programming capability. When there is an existing mental process such as spread sheets in accounting, a form of mimicking can be utilized to replace the scripting operation. Specifying reports to be regularly generated by a data base is an example of the type of task a user might carry out at this level. The composition of the document is included in this function.
1.4.4.4. Tracking Tasks
This is the process occurs tracking some occurrence and its various changes of status over a period of time. It is a level of application where the computer is an implicit or explicit part of a collaborative process. In most organizations even an item as simple as a purchase order will pass through different organizational units and has a significant number of different status changes possible. Providing this level of support usually requires an underlying transaction processing system and/or a model of the process being tracked. The user, in this case, must be provided the facilities to deal with the dynamic and temporal nature of the information.
1.4.4.5. Exception Reporting
Exception reporting is when the computer system provides only the information that is an exception to what is expected. A simple form of exception reporting is to notify those who are concerned when a budget line allocation has been exceeded. A more sophisticated example is determining when sales in a given locality are above or below the expected range of sales for that locality and that time period (e.g., seasonal variations).
The primary difficulty with the creation of an exception reporting system is that it requires the establishment of what is considered to be normal. Many organizations do not have the understanding of their environment to be able to define and quantify normality. The user who tries to establish these quantities requires appropriate modeling tools and the ability to integrate the results into the operational environment. However, a simple example of this level of information handling would be allowing users to set up filters on incoming messages to determine which ones need immediate attention.
The vast majority of organizational applications are represented by the prior user information domains. Exception reporting and the following information domains represent the application areas with the greatest current potential for new and useful systems in organizations. This and the other following areas represent the frontiers of Information System applications.
1.4.4.6. Creation
This is the level of utilization of a computer where the user is creating new information. For example, composing a new report is far more than a word processing task, it is a creative task. The tools that allow a user to correct typing, grammar, and spelling errors are not supporting the creative part of the composition process. The simplest tool to do this is the introduction of the ability to outline one's thoughts. Other examples of creation tasks are the use of a spreadsheet to create a budget plan or a Hypertext system to form a relationship diagram of concepts. Developing a new marketing plan that has some reasonable high probability of increasing sales is an example of a creation that may require the use of all sorts of differing computer based facilities. To day most of these are not integrated in a manner to make such task mechanically simple to carry out.
Creation task interfaces usually need to account for a high degree of cognitive variability among the users. These interfaces should also provide support tools that are extremely flexible and well matched to an understanding of the mental processes that a user exercises. To support creativity, the interface can not impose any restraints on the sequence of functions that a user wishes to apply to a task. The simplest approach to creativity is providing the user the appropriate set of primitives and allowing the user to "program" these. Many statistical packages are designed in this manner to allow for creativity in the data analysis process. Surprisingly, there are still many areas of creative processes where the computer is far from providing significant support.
1.4.4.7. Diagnosis
The ability of a computer to support a user's diagnostic investigation is quite a challenging ambition. If, for example, there is a sudden decrease in the sales from a given geographical location (provided by a good exception reporting capability) the obvious question that the concerned users will have is: Why did this change occur? This could be the result of one of the salesperson being in the hospital, the loss of a particular big customer, a local strike by the delivery company, etc. Diagnostic capabilities require a highly flexible system that can integrate information under user control from a wide variety of unpredictable sources. Integration of systems in an organization is still a major design challenge.
Diagnostic abilities usually imply a fairly sophisticated and rich system based on large scale data bases that are truly integrated. The integration usually requires that potential links between data elements are already in existence in the data structure. They also require the diagnostic and statistical tools to allow lateral investigations of the data across the existing data structures. In essence, diagnostic investigations could benefit from the types of computer technology inherent in such areas as knowledge bases, Hypertext systems, and semantic data models. For example, when a user views resulting data they should be able to branch to such things as an explanation of how the data was created and how good or accurate it is. If the data is an estimate there might be alternative estimates based upon different assumptions and or models that can be called up to review if needed. A good diagnostic data base structure would start with an internal structure that provided source, confidence, and temporal information before imposing other relationships.
Often diagnosis, especially of unexpected situations, are highly coordinated group activities and this gets easily into the requirements for collaborative systems. Most complex problems require a heterogeneous group to be able to pool their knowledge and establish or build a model of the situation. Computer support for collaborative model building is largely an undeveloped area of computer support.
1.4.4.8. Discovery
Whereas diagnosis is the process of verifying an occurrence of an existing known relationships by examination of data, the process of discovery is one of developing new relationships that were not previously known. Such a process implies even more sophisticated tool support than that of diagnoses. Typically today, those who have mastered large statistical packages and the manipulation of data files have the ability to accomplish the discovery process in the statistical sense. There are other types of tools such as various simulation languages that allow discovery through the building of models. One recent rediscovery of this process is referred to as "data mining." The scale by which modern powerful computers can carry out this process is truly new but the basic concepts and techniques come from data analysis and pattern recognition work.
Most of the current generation of discovery tools available on the computer are not easily utilized without prior training and mastery in the theory and application of these techniques. The challenge in this area is two-fold. The first is how to build the learning of theory and application as part of the interface support. Second, how to encapsulate these tools for specific applications that may not require the same degree of mastery by all the users. Some of the financial investment (trend regression) analysis packages are an example of repackaging general purpose statistical tools as specialized, easy to use toolkits for specific applications.
The fundamental design tradeoff is how a general purpose function can service a wide variety of applications as opposed to placing it in a very specific application context to make it easy to use by a more limited user community.
1.4.4.9. Hypothesis Testing and Analysis
Hypothesis testing and analysis are the processes of validating a new relationship once it has been discovered or demonstrated as plausible. Most people think of this as a quantitative process. In the broadest sense it can also be a subjective process in which the recognition of the relationship requires awareness and agreement of other individuals in the organization (validation by consensus). Most of the efforts in Group Decision Support Systems are really efforts to establish human consensus on the validity of new hypotheses or concepts. Any new organization plan or product design is the result of this sort of process. The design of Collaborative Systems tends to be an application that falls into this level of information domain.
Another aspect of this level of information processing is the need to integrate new relationships in existing operational systems. In the past this was the task of systems analysts and programmers. Today, one can consider designing systems that allow the user to accomplish this integration directly. Tools that allow users to develop their own models and simulations (e.g., Structural Modeling; Lendaris, 1980), without having to learn a programming language, are an example of systems that can be designed to directly support users for carrying out analysis.
1.4.4.10. Planning and Resource Allocation
The process of planning requires integration of information at all levels in an organization. Plans have to be translated from strategic level objectives down to operational actions. Engineering and construction projects may have thousands of elements that have to be related and integrated to formulate a plan for the project. The scope and magnitude of planning problems may cross the responsibilities of many different individuals and groups in an organization. This area involves the design of systems to support group interactions. This sets those problems above the prior areas in terms of the challenge for the design of the system.
Another critical factor in this particular area is the need to deal with large amounts of subjective data (e.g., estimates of budget items, time and effort to complete tasks, relationships among projects, goals, objectives, and relative weights). In the future the techniques to deal with subjective data and to make sure that groups can deal with underlying ambiguities will be part of the interface aids and tools.
1.4.4.11. Command and Control
A true command and control system would impose the right sort of models, filters and analysis aids upon the day to day flow of data and information in an organization. The objective of such a system is the recognition of what is taking place and what actions or decisions are needed to control the process. The timeliness and accuracy of the data in the system are critical to the successful operation of such a system. Such a system implies the mastery of all the other information domain levels.
Command and Control systems require large scale integration across all the reporting systems within an organization and the monitoring of the reliability of the data. Providing users the ability to understand the total scope of such a system and to obtain what they need from it is a considerable design challenge. They require transactional based processing and some sort of solution, or at least an approach, to the distributed database and processing problem.
A significant problem is the presentation of complex information to the user in order to allow his/her perception of the situation and the understanding of the consequences of potential actions. This is no small feat and is, of course, inhibited by such aspects as limited screen space to present complex situations. Look at the display and control requirements necessary to regulate a nuclear reactor and one will realize that for an organization it could be even more complex.
Command and Control Systems can include animation and virtual reality applications. Note that the classical use of virtual reality has always been to show properties of the physical world that can not be observed by the human senses. For example, by correlating stress to color in a bridge design the engineer can actually see how design changes effects the performance of the structure under different loads and environmental conditions. However, it is only the expert in bridge design that can make significant use of such a virtual reality.
1.4.4.12 Summary
The following summarizes the key functionality required to support each level of information system objective. It should be clear that each area requires much of the functionality in the areas preceding it in this list.
| User Information
Domain
|
Required Functionality |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1.5. Sources of Evaluation Methodology
Without the introduction of formal evaluation methods, the process of system design, development, and evolution is reduced to the use of the designer's intuition and reaction to the "squeaky wheel." Even though a designer may be very experienced, it is impossible to deal with the tradeoffs and constraints of the design process without reliable feedback from the potential or current user population. Furthermore, many of the most important inputs will come from users who will normally not volunteer the information. The evaluation process also plays a secondary, but very important role, in preparing the expectations and motivation of users to make use of the system. As a result, the designer of interactive systems must achieve some mastery and understanding of evaluation methodologies.
Approaches to the evaluation of interactive systems have roots in a wide range of disciplines. The earliest work in this area began in the field of Industrial Engineering as a logical follow on to Human Factor studies using physiological response studies, "time and motion" studies, and controlled experiments. Most of our knowledge about physiological properties still comes from this field.
From the field of Psychology comes our understanding of human cognitive processes and human problem solving. The method of Protocol Analysis, developed in this field, is a basic tool for the evaluation of interfaces. Our understandings of human psychology and mental abilities and their measurement are also contributed by this field (Lachman, et. al., 1979).
From the field of Sociology comes our conceptions of technology and its interaction with social and organizational systems. Our understandings of group processes and behavior also derive from the research in this area. The primary methods borrowed from this discipline are interview techniques, focus groups, survey techniques, field trials and longitudinal studies (Rosenthal and Rosnow, 1984).
From the Management Sciences we have the classical Cost/Benefit approaches and considerable effort to develop improved measures of user satisfaction, efficiency of use, and the quality and effectiveness of the application. Also, from this area we have input into the management or operational practices that influence the performance of Information Technology in the organization (Strassman, 1990).
A great deal of early work on interface design was done in the field of Information Science as a result of the prior studies on large text data bases. The sub field of Information Retrieval is a rich reservoir of useful material (Walker, 1971).
From the field of Anthropology, the evaluation of Interactive systems has actively borrowed both Participant Observation and the concept of the metaphor as a way of understanding the resulting culture of the user. The metaphor model has become the bridge for understanding the relationship between cognitive processes and cultural adaptation. They also provide important insights into the human learning process with respect to interactive systems.
More recently the field of Archaeology has provided techniques for the "study of artifacts" as a method for understanding Interactive Systems as a collection of tools. Users of modern systems are able to tailor their systems to such an extent that they become individualized tools, much like stones were shaped into a wide variety of implements in primitive cultures. From the artifact viewpoint we can learn a great deal about human tasks from the study of the resulting tools. Even the way different users choose to layout their windows and icons can be very informative about their information handling approaches. The growing ability of users to tailor their own interface is making this viewpoint extremely relevant to the evaluation process.
Finally, the newest entry is the field of Philosophy with the view of the potential for interactive systems as a "virtual reality." Virtual reality gloves which can be worn by a user, allows them to place their hand virtually within the screen and manipulate the objects displayed. Goggles allow a user a three dimensional view of computer output. These are technical personifications of the virtual reality concept. Using colors to indicate velocity in a turbulent flow simulation on the computer provides the user with an ability to perceive insights not otherwise possible. However, the very basic property that users can create their own universe within a computer system that is unconstrained by the physical laws of nature, is at the heart of the virtual reality viewpoint. Finally, the virtual systems created in the computer can become a template for changing the real world (Turoff, 1997).
Only in the last decade has the field of Computer Science (Shneiderman, 1981) begun to incorporate many of the above approaches to make the subject of interface design a very rich field of study. Prior to that time, most of the work within that field could largely be classified as expressions of wisdom by designers. That wisdom was useful in providing general guidelines; however, it did not provide insight into the limits of wisdom as a function of rapid changes in both technology and applications.
Each of these areas provides not only evaluation techniques, but also very different viewpoints on interactive systems and how they fit into the human environment. They each provide unique and important contributions to our understanding of this area. We will be borrowing from this diverse set of fields throughout the book.
There are actually only a limited number of ways in which a designer can gather the required information to come up with the ideas for his or her design. A good designer will try to take advantage of all possible ways because they all provide significant differences in the perspectives they offer. The major danger is trying to rely on only one of these approaches, as they all have their limitations when used in isolation.
1.6.1. Differentiation and Comparison
This is one of the most common approaches to design. In essence, it is the process of looking at other systems with the same or similar objectives, and determining what features and functionality the designer could incorporate in his or her design.
In any industry or application area there are always individual organizations somewhat ahead of the others with respect to the implementation of computer applications. Many managers and users often come up with requirements for computer services they see in similar organizations. The use of professional meetings to exchange ideas is a very common approach. Many organizations are anxious to show off their accomplishments to others representing non competitive companies.
This process consists of the development of requirements and designs by gathering intelligence on what already exists. This is certainly a useful way to gather ideas. However, rarely can one get data on how useful and valuable the features of such systems are to their user communities. Even if evaluation studies are done, they are rarely made public. Therefore, one cannot take the existence of a feature as final evidence that is valuable. The design must be influenced by other considerations as well.
There are situations where this approach is taken to the extreme. Many commercial magazines publish so called analyses of similar systems such as word processors, communication packages, etc. These reviews usually amount to long tables that list every possible feature and check off which systems have which features. The unfortunate implication to many readers is that the best system is the one that has the most features. As a result, creators of software often try to maximize their feature list. Many application designers get the feeling that the most important way to justify their system is to have the longest possible list of features. A system designed this way, with little thought for the overall integration and understandability of the features within the context of a total design, can easily lead to a complete disaster.
Although a system might be initially well designed, the pressure to add features leads a gradual breakdown of the original consistency and clarity of the design. When the new features that were not a part of the original design are added, the result often is a very messy and inconsistently structured system. This problem can only be overcome if the designer has some sense of the potential evolution of the system and can lay the foundation to support future additional features in the initial design. In the context of typical applications development in organizations the designer is often under pressure to bring in the lowest possible cost in the development of the system.
1.6.2. Enhancements and Evolution
The most successful process for the design of interactive systems is to introduce limited but valuable features that are designed to accommodate expansion and change. Then, by carefully observing and evaluating the user community, one can evolve the system based upon user feedback. From this point of view feedback and evolution are the major driving variables for the design.
Even commercial software packages go through major changes every few years, which are, in effect, the response of the vendor to requirements coming from the user community. There is no doubt as to the importance of this approach. However, it is almost impossible to develop the external metaphor or the internal implementation model of a system to accommodate evolution, unless the designer has some understanding of what the design might evolve into. Without this, the basic system, which might have been well designed to begin with, starts to take on an atmosphere of many features dangling at the end of the twigs of the interface tree, with no rhyme or reason that gives any sort of overall perspective to the new user. Such interfaces, like trees, fall over when they get too top heavy to be supported by the original foundation.
In the evolution of a system, the designer is often faced with the hard choice of making a radical change in the current interface or adding new functionality as a sort of patch to the existing interface that does not provide an integrated design. Making a radical change to an existing interface means that the users have to unlearn what they are used to in order to use the new version of the system. Unlearning is much more difficult for a user than learning. To appreciate this, try using a word processor different from the one you currently use. The user must perceive a high degree of added utility to a new system, to be willing to unlearn an earlier one that does a similar task.
Systems that don't evolve begin to die, but evolution alone as the design objective is not sufficient. There must also be the insight by the designer as to where the system is headed years into the future. The farther in the future the designer can foresee the longer will be the lifetime of his or her design. Unwillingness, at some point in the evolutionary process, to make fundamental changes in the interface can lead to an early death for a system. The ability to foresee the future depends upon the designer's knowledge of the application domain and how the computer could introduce modifications to the way the application is handled in the organization.
1.6.3. Requirements Development
In the classic systems analysis literature the typical advice is to find out what the user wants and implement that. This is often called "requirements development;" however, that is not what we mean here. Users may know what they want today, but they do not know what they will want a year from now. If they are not knowledgeable about computers, their requirements may be limited in scope. Furthermore, the requirements from users often come in very specific micro terms that reflect current tasks. It is the obligation of the designer to take differing requirements and determine if there is a functional level of design where the same common functionality will service a wide range of user requirements.
The fallacy of the classical systems analysis approach is that it often assumes that the requirements developed by the users can be taken at face value. Too many of the solutions offered by the field of Computer Science always seem to have the implicit axiom that eliminating humans and their creativity from the process or application is desirable. It is almost a bias of the field that accomplishment involves replacing humans rather than aiding them.
The designer must go beyond the scope of the requirements as the users state them. To do so, the designer needs to master four separate areas of understanding.
1.6.3.1. Understanding the Task
From the earliest days of interactive systems design, the commonly repeated wisdom was that the designer must understand the task. Even today many research laboratories seek programmers who have a bachelor's degree in the discipline of concern to the laboratory (e.g., chemistry, physics, etc.) and a Master's in Computer Science. They believe this type of individual is the one best suited to be working on applications for the researchers in the laboratory.
In today's environment, where much of the application development is for highly cognitive and variable tasks, it is very necessary that the designer gain as good an understanding of the task domain as is possible. Many of the tools for evaluation of interactive systems (e.g., protocol analysis, participant observation, interviews) can also be used directly for gaining that understanding. This also means that the objective of the designers in their early contact with a user community is to focus on understanding their work rather than only on gathering requirements.
Understanding the task is what can give the designer considerable insight into what future demands for system functionality may result from the evolutionary process. The result should be the ability to construct a more comprehensive design that will accommodate future developments and changes. Task understanding usually leads to a macro level of functionality for the design. As a result they may limit the flexibility of the system to adapt to new tasks because there is no way to piece together new functionality from micro level components.
1.6.3.2. Understanding the Human
Knowledge from human information processing and Cognitive Psychology will allow the designer to establish general interface functionality to accommodate a wide range of differing requirements. For example, how people categorize and index information, and what type of general indexing approach might be best suited to a particular application? For indexing approaches a great deal of knowledge already exists in the Information Retrieval field. A later section of this book will deal with that particular example.
This is actually a rapidly expanding area, more attention is being paid by Cognitive Psychologists to the issues directly related to interactive systems design. It is an area that designers should actively monitor for the potential of obtaining new design ideas. This type of understanding usually leads to a micro level specification of functionality. As a result, the user may have difficulty in perceiving the way he or she can put together functionality to accomplish specific tasks. There is always, in any system, a basic tradeoff in the level of functionality provided. Is the garden design system designed for the average gardener or the master gardener? Is the interior design system designed for the average homeowner or for the interior decorator?
1.6.3.3 Understanding the Group
With the introduction of computers as a mediation and communication tool between humans, it becomes important to understand the behavior of groups, if one is going to design systems to support group activities. Also, there are certainly many who believe that an understanding of organizational behavior is a key to the successful introduction of any type of computer system in an organization (Keen, 1981).
Even for standard information system applications, the long term impact of a given system can change the nature of how an organizational unit (or group) operates. Usually these considerations are not an explicit part of the design process. However, some perceptive members of the organization may induce conflict and difficulties related to these hidden considerations. These long term impacts are often more significant than the original objectives of the system. They are often recognized as having implications for changes in the authority and power structure of the organization.
The concept of group can be the small working group, homogenous or heterogeneous, cooperative or conflictual, etc. The group can be a larger organizational unit, the organization as a whole, or the society as a whole. The design of systems are dependent not only on the application but the nature of the group it is serving because the user community is really an integral component of the total system.
1.6.3.4 Understanding the Technology
A good designer has to have a fundamental understanding the technology. In the old days and still today as practiced in many organizations this is still what is considered to be the knowledge necessary for design. The common application developer is still the individual who started out as a programmer. There is no doubt as the importance of this area of knowledge but if it is the only foundation for design it will definitely lead to poor designs. However, the designer has to stay current in his or her knowledge of the technology.
1.6.4. Normative Visioning
Normative visioning is trying to understand the long term objectives for a system. Then one attempts to identify the type of functionality will encourage those objectives. Such functionality may not be a part of the established requirements, especially when those requirements arise from current user views. Users usually cannot conceptualize the value or applicability of functionality if they have never experienced it.
This is the area where the designer goes out on a limb with respect to his or her beliefs about the future of the system and the impacts it can have on the user community. It is often a result of their experience and confidence as to how far they are willing to go with this type of designing. It certainly requires as good an understanding as possible of the application, the users, and their environment.
The current and growing emphasis on the use of information systems as a strategic resource for the organizations is an alternative formulation of the need for normative designing. The success of a strategic information system is extremely dependent upon how far into the future one can accurately view and determine the objectives of the strategic system.
Over the long term an information system can lead to changes in the behavior of its users, changes in the nature of the work, and changes in the structure of the organization. While such changes occur slowly they may turn out to be the most important of the impacts such systems can have. The designer has to be aware that an interactive system can create a social system (Turoff, ??).
This is the process of consciously designing to encourage planned and desirable changes in the users, the way they solve problems, and work together as a group and functional unit. Organizations continually try to bring about social change by such mechanisms as a reorganization and formal redefinition of work functions. Most have not yet realized that the computer environments they have created accomplish the process of change in a continuous and currently unrecognized manner.
1.7. Views of the Design World
Any design effort involves a number of different representations or models of the situation. To a great extent the design problem can be understood at the highest (macro) level of design as the problem of dealing with the differences in these representations. Very often a specific difficulty needs first to be addressed in terms of which of these representations are the source of the problem. These models are:
1.7.1. Mental Model
This is the model of what exists in the head of the user. Clearly not all users have quite the same model. With very heterogeneous populations, the designer may have to consider a number of different mental models.
The user gains his or her mental model by experience with the real world. Users learn over time and which causes changes in their mental model. The process of designing a system is not one of trying to perfectly match the user's mental model. It is one of designing a system that can easily be incorporated into the user's mental model by a process of learning. This means the Interactive System can be designed to cause or evolve changes in the mental model.
1.7.2. Implementation Model
The implementation model is the way the system is designed internally and operates in the computer. There may be a very large gap between the processes used in the computer to carry out a task and the representation of the task in the mind of the user.
The advancement of computer applications is very often tied to the ability to develop virtual computers that are closer to the application area. For example, FORTRAN is a virtual computer for doing numerical analysis. It allowed scientific users to view the computer in terms closer to their mental model. However, suppose a person is dealing with a large input/output matrix from economics (400 by 400 variables) and the core available is not sufficient to hold the whole matrix at once. If the FORTRAN compiler stores the data a row at a time and the user chooses to do a calculation by processing each column, the resulting calculation will take a long time as each single element is brought in from the disk. What this indicates that even with the virtual representation of FORTRAN, there are some situations where a lack of understanding of the internal operations can cause users significant problems or limit their ability to accomplish something.
This problem can be even more serious today as the pressure for "easy to use" interfaces encourage designers to close off or hide the full functionality available in the implementation of a system. This may very well inhibit new or unpredictable applications of the system.
1.7.3. Interface Metaphor
The interface metaphor is the representation or model that mediates the communication process between the user and his or her mental model and the implementation model. One would like the interface metaphor to be close to the mental model so that it is easy to learn and master. On the other hand, one would like the interface model close to the implementation model so that the user could maximize their ability to utilize the full set of capabilities that the implementation model offers. For example, a user who is dealing with a generalized data base system and is provided only a basic retrieval capability as an interface metaphor, will never be able to formulate a tailored data structure.
One cannot move the interface close to the mental model without having to move away from the implementation model, and visa versa. This leads to the following conflicting problems:
* Functional Opacity is the inability of the user to translate what he or she wants to do into the interface metaphor, because the interface metaphor is too far from his mental model.
* System Opacity is the inability for the user to understand what the computer has done internally because the implementation model is too far from the interface metaphor.
As a rule, the more sophisticated the application, the more likely that system opacity can be a serious problem. For example, it is almost impossible in the current state of expert systems for a user to understand how the expert system reached its results. The same may be said of many complex simulations created on the computer. The current trend has been to focus on reducing functional opacity, but as the systems being supplied to users become more sophisticated, we will run right up against this other limitation. For example, WINDOWS provides an interface with higher system opacity than MS/DOS. As a result many people who have mastered MS/DOS prefer to continue to use it because they feel more comfortable with it as a representation of the technology they are using.
The designer has the very crucial problem of trying to decide where to place his or her interface metaphor in the usually large mental distance between the implementation model and the mental model. This is usually the first or highest level tradeoff that the designer has to wrestle with. The closer to the mental model, the more "easy to use" is the system; however, the closer to the implementation model, the more powerful is the facility provided the user and the more likely it will serve new and innovative applications. The long term solution to this dilemma is the development of implementation models that are closer to the mental models of the experts in a given application area. This approach is usually the realm of research in interactive systems and not a viable approach for the typical applications designer in an operational organization.
1.7.4. The Development Process
The classical development process is one in which a systems analyst develops a requirements model. The requirements model may be handed over to a system designer to create an implementation model or specification for the programmers. Somewhere after that point a person may be asked to consider the interface problem.
This is really a very backward approach for trying to get a well-designed Interactive System. The requirements model should be input to the development of an interface metaphor well before the implementation model is finalized. In fact, the interface metaphor can be tested on the user community even by the use of mocked up screens on a screen editor. The interface metaphor can be reasonably well defined before an investment has to be made in a single line of code. The interface metaphor should be included in the initial feasibility study for a new system and should be the driving force in the system design process (Carroll and Thomas, 1982; Neisner, 1968).
The success of an interactive system is tied to the interface metaphor and it should be the driving force behind the implementation model, rather than the other way around. It also provides an opportunity to deal with the system and functional opacity problems at the beginning of a development effort rather than at the end.
The interface to an interactive system should not be an afterthought, it is what makes the whole system hang together. However, it is not easily separable from the task, the user, the user community, the implementation, or the long term objectives of the system. The process of design has to be based not only on what the users wish to accomplish today, but what the designer foresees users will want to accomplish in the future. The designer has to be the "architect" of the system. The purpose of this book is to help those who wish to take on that role.
1. For any reasonably rich interactive system you are familiar with, identify functionality that came about by the different methods of getting design ideas: Differentiating, Enhancing, Requirements Development, and Visioning?
2. For any interactive system you are familiar with, identify both functional opacity and system opacity difficulties?
3. For any interactive system for which you have some knowledge of the user community, identify different user types and differences in functionality they make use of?
4. For any reasonably rich interactive system, identify the functionality that would support different information domains of use?
5. Give examples of interactive systems whose primary values represent the different objectives for using interactive systems?
6. For a system you are familiar with describe the most likely functional usage that would characterize each of the user types.
7. For any reasonably rich interactive system, represent differences for a specific task in the user's mental model, the interface metaphor, and the implementation model.
8. For a personal financial system, describe an example of application functionality specifically for each different level of the information domains of users.
We will provide key references to each chapter at the end of the chapter. These will be items that were referenced at specific places in the chapter as well as general references that are applicable to the chapter as a whole. References included with the chapter are also considered as sources for further investigation of the chapter topic. There will be a further general bibliography at the end of the book.
The primary journals for recent papers are considered to be:
ACM Computing Surveys
ACM Transactions of Graphics
ACM Transactions on Information Systems
ACM SIGCHI Bulletin
Behavior and Information Technology
Communications of the ACM
Human Computer Interaction
Management Science (TIMS)
Information Systems Research (TIMS)
Cognitive Science
Ergonomics
International Journal of Man-Machine Studies (Academic Press)
International Journal of Human Computer Interaction (Ablex Press)
Human Factors
IEEE Computer
IEEE Computer Graphics and Applications
IEEE Transactions on Man, Systems & Cybernetics
Journal of Applied Psychology
Journal of American Society for Information Science (ASIS)
Journal of Visual Languages and Computing
Banbassat, I., and Taylor, R. N., Behavioral Aspects of Information Processing for the Design of Management Information Systems, IEEE Transactions on Systems, Man, and Cybernetics, SMC-12(4), July/August, 439-450.
Bennett, John L., (1972), The User Interface in Interactive Systems, in Annual Review of Information Science and Technology, ed. C. A. Caudra Vol. 7, ASIS Press, Wash. DC, 159-196.
Brown, John Seely, and Newman, Susan, E. (1985), Issues in Cognitive and Social Ergonomics: From our House to Bauhaus, Human-Computer Interaction, 1(4), 359-392.
Carroll, J. M., & Thomas, C., (1982), Metaphor and the Cognitive Representation of Computing Systems, IEEE Transactions on Man, Systems and Cybernetics, SMC-12, March-April, 107-116.
Clement, Andrew, (1994), Computing at Work: Empowering Action by 'low level' users, CACM, 37(1), January, 52-63.
Clemons, Eric K., (1991), Evaluation of Strategic Investments in Information Technology, Communications of the ACM, 34(1), January.
Collins, W. Robert, Keith W. Miller, Bethany J. Spielman, and Phlip Wherry, How Good is Good Enough? An ethical analysis of Software Construction and Use, CACM, January 1994, 81-91.
Hiltz, S. R., Kerr, E. B. & Johnson, K. (1985), Determinants of Acceptance of a CMCS: A Longitudinal study of four systems, ??
Hiltz, S. R.; Kerr, E. B. & Johnson, K. (1985) Determinants of Acceptance of a CMCS: A Longitudinal Study of Four Systems. CCCC, NJIT, Research Report N. 22, Newark, NJ
Lachman, R., Lachman, J., and Butterfield, E. C., (1979), Cognitive Psychology and Information Processing, Lawrence Erlbaum Associates, Hillsdale, NJ.
Lendaris, G., (1980), Structural Modeling: A Tutorial Guide, IEEE Transactions on Systems, Man & Cybernetics, SMC-10(12), December, 807-840.
Mantej, M. M., & Theorey, T. J., Cost Benefit Analysis for Incorporating Human Factors in the Software Lifecycle, CACM, 31(4), April 1988, 428-439.
Martin, Thomas H., (1973), The User Interface in Interactive Systems, in Annual Review of Information Science and Technology, editors: C. A. Cuadra & A.W. Luke, Vol. 8, 203-219.
Mowshowitz, Abbe, (1976), The Conquest of Will: Information Processing in Human Affairs, Addison-Wesley, Reading, MA.
Neisner, Ulric, (1968), Computers as Tools and Metaphors, in Conversational Computers, Ed. W. O. Orr, 206-217, Wiley, NY.
Rosenthal, Robert, Rosnow, R. L., (1984), Essentials of Behavioral Research: Methods and Data Analysis, McGraw-Hill Book Company, NY.
Rubinstein, M., (1975), Patterns of Problem Solving, Englewoord Cliffs: New Jersey, Prentice Hall.
Shneiderman, Ben, (1981), Software Psychology: Human Factors in Computer and Information Systems, Little, Brown and Co. Boston, Mass.
Strassman, Paul, (1990), The Business Value of Computers, The Information Economics Press, New Canaan, Connecticut.
Turkle, Sherry, (1984), The Second Self, Simon and Schuster, NY
Turoff, Murray (1997), Virtuality, CACM, September.
Walker, D. E. ed., 1971, Interactive Bibliographic Search: The User/Computer Interface, AFIPS Press.
Walsh, J. P., & Ungson, G. R. (1991), Organizational Memory, Academy of Management Review, 16(1), 57-91.
Zipf, George Kingsley, Human Behavior and the Principle of Least Effort: An Introduction to Human Ecology, 1949, Published by Hafner Publishing, 1972, NY.