Papers and Essays
Conference trip reports
CHI+GI'87 trip report
|
useit.com
Papers and Essays
Conference trip reports
CHI+GI'87 trip report
|
| The conference proceedings can be bought online |
The DataGlove had three applications at the moment. The first was to substitute for medical measurements of finger-movement ability of people who have certain diseases. Measuring how much people can flex their fingers is currently done with fairly expensive and awkward equipment. Instead the patients can just put on a DataGlove and let the computer make the measurements.
The second application was probably the most interesting: Direct manipulation of 3-dimensional objects. They had a 3-D CAD program running on the Macintosh where the user could use the DataGlove to grasp a 3-D object (e.g. a box) and move and rotate it by moving and rotating the hand. You would then let go of the object by spreading your fingers, and the object would be in its new position. The 2-D computer display showed a projection of the simulated 3-D space in which the DataGlove operated and the position and rotation of the user's hand was represented by a (somewhat sinister) skeleton hand on the screen. The real advantage of this system is that introduces as direct a manipulation as possible without 3-D holographic projection of the data space. In current system using a mouse or other 2-D locater device, 3-D operations are somewhat indirect.
Finally, the third application was to use hand- and finger-motion tracking as an input device. The demo showed a finger-painting system where you painted on the screen by moving your finger. The screen was cleared by spreading your fingers. This was not all that impressive since it was somewhat like the Videoplace system.
The problem with this approach is that it probably does not teach the child algorithmic thinking or any general problem solving. The advantage is that the computer feels very responsive since you only get immediate feedback and no delayed programming effects. It is also an open question whether Noobie would motivate children for extended use. Certainly the children (of all ages) present during the demonstration had great fun. It could be used to generate positive feelings towards computers and of course it could probably also be used for more advanced interaction techniques. Certainly the concept of having the entire animal as the input device for a computer is both novel and challenging.
(Now, in 1997, we are starting to see commercial products of the type pioneered by Noobie; e.g., Microsoft Barney. Unfortunately, these products are not as innovative and interactive as Druin's prototype from ten years ago.)
Noobie is implemented using a Macintosh which is buried inside the stuffed animal. The screen is visible in its stomach. The squeezing input is implemented with sensors throughout the animal which are connected to the Macintosh as though each sensor was a key on the keyboard. This has the advantage that the Macintosh does not have to be modified but it also means that a squeeze is simply sensed as an on-off action (i.e. not pressure-sensitively).
In some sense I feel that Tufte is too much of a fanatic in his opposition to fancy graphics (made by computer or otherwise). Often it is a good criterion to maximize information contents in graphs, but attention-getting "business graphics" surely also has a place. Sometimes you simply get in a good mood by seeing a flashy graph. But of course there is no excuse for misleading graphics where you e.g. use the size of two-dimensional objects to depict changes in a one-dimensional variable (as in the figure where B is two times as large a number as A but looks 4 times as big).
On the other hand, Tufte was not so worried about the classical problem How to Lie with Statistics since he felt that our "lie detectors" are probably better for graphics than they are for words. The preoccupation with showing the Truth has sidetracked the design of statistical graphs-e.g., the principle of always showing the 0-point on the y axis may lead to less informative graphs.
The basic challenge of graph design is escape the 2-D Flatland of paper and the computer screen to represent the multi-D richness of our complex world. We need to add dimensionality. One approach advocated by Tufte is micro-macro reading-the ability to read a graph from the macro view to grasp the total picture and then to look at selected details from a micro view. As an example, Tufte distributed a reprint of a tourist map of Manhattan: One of these maps where all buildings are drawn as they look rather than as colored squares. The macro view of the map gave you an idea of the New York skyline (you could never mistake this kind of map of Manhattan with a similar map of Copenhagen) while the micro view allowed you to identify your own office window or your favorite news stand.
The first solution to the interface problem has been to use the extra CPU-power available in modern computers to be more generous with help and other interface features. ("Burn cycles, not people" a quote from Daniel Nachbar). We also have to get away from the egocentric intuitive fallacy of believing that everybody else can see what you see and that they therefore will be able to use your "obvious" interface design with no problems. These changes are taking place, and examples were presented in other talks at the conference. We are also getting design guidelines as a distillation of our user interface experience.
So now we know how to solve a number of user interface problems. The next step according to Landauer is to make computers useful to do things people could not do before: Focus on providing service to the user rather than just on the surface of the system in the form of the user interface. We should do synthesis by analysis since once you know what the (real) problem is, the solution is normally easy. Landauer presented the following three methods to achieve this goal:
Computer tools for reading has not been any good as reading from computer displays until now has been slower than reading from paper. Maybe better displays will alleviate this problem. We are also getting new reading tools such as hypertext which has been discussed for many years but has not seen much use until now. The problem here is that we lack an analysis of what people really want/need to read.
Another tool (mostly for internal use among CHI researchers) was the scenario method presented by Phil Barnard. Barnard views a scenario as an idealized, simplified description of a specific instance of user-computer interaction: An established phenomenon in human factors which is exemplified in a was that allows researchers to take the scenario into account when discussing new models (e.g. cognitive models). A proposed model must be able to account for the events in the scenario by some sensible explanation. This is a way of saving researchers lots of time in going through experimental tests of their new models: First try the encapsulated essence of previous experiments and see if your model can stomach them. As Barnard put it: "We can turbocharge the tortoise of science" (referring to the keynote talk by Allen Newell at CHI'85 who said that the race is between the tortoise of cumulative science and the hare of intuitive design).
What we are now waiting for, is an annotated catalog of good interaction scenarios to really speed up our respective tortoises. It even seems to me that this method could be of use to practitioners too (maybe it will not speed up the hare-but it could get it to run in the right direction): It is well known that examples are much more easy to understand than abstract guidelines, so maybe a good set of interaction scenarios could show designers some of the things to take into account.
This year Rob Kling from the University of California had this ungrateful job. He discussed the familiar automobile metaphor for user interfaces and noted that in the world of real cars, it is not enough to optimize the individual car. Even if he owned a Porsche, he could still not get to work much faster if the freeway was jammed because of other people. And this problem would not even be solved if everybody drove Porsches. Cars operate in a world of rules and regulations: As soon as we leave our own driveway, we see streetsigns.
As a conclusion to his discussion of the car metaphor, Kling recommended that we use urban design as our metaphor for building computer systems rather than architecture which is the most common current metaphor. On the other hand, Kling did not want the audience to conclude that he felt that good user interfaces were not useful. The point was simply that they are not sufficient since computerization is socially mediated and takes place in an interaction among many people and groups. An example of this is the ZOG computer system at the USS Carl Vinson: It was a failure in real use because the system assumed that all Navy personnel was committed to total data validity-and some were not.
Another concrete example where the social context determines the user interface is the use of text processing in university departments. The secretaries view is as a "text factory" and don't want unneeded complexity such as in UNIX and TEX while the faculty members (especially in a computer science department) want flexible and programmable systems.
Mary Beth Rosson (IBM Yorktown) presented the results of a study of design practice in the real world. It would be extremely useful to know more details about how what aspects of user interface design results in usable interfaces and what aspects are a waste of time (or possibly harmful). But unfortunately she did not have such clear-cut results. This is not surprising considering how hard a problem this is to study and considering how few other results are available. So this project represents a step forward from knowing very little to actually knowing a little bit.
They had interviewed 22 designers about their experience. It seemed that about half had used a phased design model while the other half had used an incremental design model of letting the system evolve during the design. There was very few cases of early user testing. Most empirical work had been done to evaluate designs rather than the possibly more important point of learning something about users to drive the design. Most designers expressed the following opinion about working with human factors people: "Yeah, it seems to be useful but it was too late..." Furthermore, many designers had difficulties separating the user interface and the functionality. For them, the user interface is "what the user does" and not just the form of the dialog.
Allan Cypfer (Intellicorp) would prefer that we keep intelligence out of the user interface and put it in the application itself. One example from Intellicorp was a structure editor for molecules: It knew about molecules in a way a simple graphics editor could not do and it would e.g. show 4 different views of the same molecule on the screen at the same time. The interaction techniques did not show any signs of intelligence but the system had semantic domain knowledge.
John Seely Brown (Xerox PARC) advocated three design goals:
Ben Shneiderman (University of Maryland) commented that the panelists had talked about intelligence in the design of interfaces but not about visible presentation of the actions available to the user. Many systems show the objects visibly on the screen but users still have to remember the commands (what you can do with the objects). Shneiderman thought that we could do better than just menus.
Frank Halasz (who was with MCC during the conference but is now back working at PARC) presented the NoteCards system which was intended as a vehicle for studying the idea processing task. The research goal was to assist analysts of the CIA kind in writing better reports on the basis of lots of collected information. They used the following model of authoring: 1) Collecting sources from databases (computerized tools available) and from brainstorming (currently no tools). 2) Extracting ideas (currently no tools). 3) Analyzing and structuring ideas (currently no tools). 4) Organizing the presentation (tools: outlining processors). 5) Writing the document (tools: text editors). 6) Producing the document (tools: page layout programs).
NoteCards is intended to address the question of the missing tools. Since they did not have experience with existing tools for these tasks, they had to change the way the system worked as their understanding of the task changed. Currently NoteCards is used by about 70-100 users. Most users actually find NoteCards hard to use, first of all because playing with ideas is hard work! Other reasons are that most tasks really do not need the full power of computerized idea processing and that the current system has limitations such as screen space (not big enough to display the full graph of ideas). Another problem is that NoteCards is too general a system which does not include specialized support for special tasks such as legal reasoning. But to support the way a lawyer works, you have to now how a lawyer works! The current system can be tailored by the user but this is not good enough for non-programmers.
NoteCards requires the user to explicitly segment ideas into separate notecards which must be given a title and a classification. Often this is hard to do in the early stages where people do not yet know what they are analyzing. Another problem with the computerized representation of ideas is that they all look the same (typewritten cards). There are no coffee stains, paper clips, or other small reminders of the context in which the idea was generated.
Stu Card and Austin Henderson gave a collaborative talk in which they took turns presenting the theoretical issues and implementation issues of the Rooms concept. The general problem is that the metaphor of personal computer desktops is somewhat mistaken. One real desktop corresponds to 42 Macintosh screens. So a single display cannot hold all the information we want to use. Instead they introduced the concept of a room which is a full display holding certain windows which have been grouped for use in some task. When you shift task, you move (through a "door") to another room which has the windows useful for that other task.
This presentation showed a creative use of a videotape to accompany the talk itself. Interactive systems are often hard to describe using words only: You have to see them. So the video program is an important part8 of every user interface conference. More and more of the traditional paper presentations also include short video clips, but the Rooms presentation was illustrated throughout by a videotape instead of by overheads or slides. This of course meant that the speakers had to synchronize their talk with the tape, but they did that with no problems.
Steve Boies of IBM found three problems with human factors people: 1) Many times behavioral people ignore economic constraints such as the need to market a product before it becomes obsolete. 2) Often their recommendations are difficult to implement compared with their importance. 3) Sometimes the quality of human factors recommendations is too low and opinions are confused with expertise. In one case the first human factors person to be consulted in a project recommended shifting a key from the right to the left on the keyboard. And later, a second human factors person recommended that the same key (which was now on the left) be shifted to the right. But in spite of these problems, Boies (who has a user interface background himself!) said that human factors was so important for computer companies that they should fund it at the same level as e.g. CMOS. Also, he suggested that cheap but good results could be gained from instrumenting systems to measure how they are used in real life.
Charles Grantham from Pacific Bell recommended that human factors should be placed at the corporate level in a company because this is the only place with the overall view required to balance all the tradeoffs. The individual project managers want their product out the door and are tempted to suboptimize user interfaces by choosing solutions which may work in their specific product but which destroys the commonalty between system thus impairing transfer of user learning. John Whiteside from DEC commented that the problem with this approach would be that the higher you are placed, the more thinly you are spread as you touch more and more projects. Grantham's answer was that the value of going to a strategic view of user interfaces would outweigh that disadvantage.
Dennis Wixon discussed the DEC experience with the concept of Usability Engineering Development Cycle which usually in their experience results in a 30% improvement in operationally defined usability indices and the solution of about 80% of the usability problems. They simply iterate user interface development and measure usability until reasonable goals are achieved. At some point they reach the point of diminishing returns, but they showed a nice curve of their experience with interface improvements as the result of their method. Two comments to this method was: 1) [Boies] A company like IBM will not switch technology from proven traditional systems unless at least 100% improvement can be shown. Otherwise it is just relatively insignificant tuning. 2) You cannot develop measurable usability specifications in the case where you try to get people to think of totally new systems.
Other comments were that human factors is a legitimate part of engineering and than you only do good engineering if you take human factors into account (Rubinstein, DEC) but that we just don't have the same track record of performance as other engineers at the moment to prove a steady level of improvements as the result of our human factors work (Boies, IBM).
A lot of discussion centered around how to trick management and/or developers into doing what we want: "whoever gives the best demo wins" - so give a really neat demo if you want to convince management to things your way. Let the developers feel collective ownership of the user interface solutions-the case where a user interface expert is the only person who "owns" the user interface will often end up as "you can write the HELP-messages;" Unless human factors is an item on the development team's agenda, it will be ignored.
Surprisingly, nobody mentioned the possibility of having the users put pressure on computer companies to develop usable products. It could be a real possibility that big customers got together with a team of user interface experts to develop requirement specifications for user interfaces as well as for other aspects of computer systems. It could also be a job for labor unions to require better user interfaces as part of their quest for better working conditions. Unfortunately, the major trade union for office workers in Denmark is currently focusing its efforts in the computer field on the non-issue of radiation from terminals. They will probably succeed in getting even lower low-level radiation in the workplace but at the cost of poorer working conditions as effort and money is spent on terminal radiation rather than on e.g. graphical workstations allowing a more varied work situation.
I only attended the tutorial on documentation graphics. This is an area which is growing in importance as desktop publishing is spreading to more and more places. Just a few years ago, terms like font and kerning were only used by very few, specialized people and now they are part of the everyday language of both computer scientists and many ordinary users. Chuck Bigelow emphasized that there are very few artifacts in use that are the same today as they were 500 years ago-except letters. So Bigelow wanted us to use the long tradition of typeface design and use-of course taking into account the present limitations of screen and output resolution. Sometimes only small improvements in technology can lead to quite large improvements in readability. One example mentioned by Bigelow was that 100 dots per inch would be a significantly better screen resolution than the 75 or 80 dots per inch now common in most graphics displays.
Much of the tutorial was spent discussing the two page description languages, InterPress and PostScript. These languages are fairly hard to read (I don't think that the designers could have taken the Psychology of Programming tutorial!) which may not be a problem as long as they are only used as an internal representation which is shipped over the network from the computer to the printer. But now more and more applications are being marketed which require the user to write or edit PostScript programs directly. So maybe a new and more readable language is required for presenting a page description to the user. We can still use the standardized PostScript for transmission to the printer.
Several other, more technical issues were covered at this tutorial [i.e. graphics programming]. But one that I would like so single out was the AI-based illustration design system by Jock Mackinlay from Stanford University (now Xerox PARC). This is a system with at the moment 200 rules that knows about good layout and data presentation. Some fairly nice examples of output from the system were shown though it is still far from perfection (and of course is no good at "creative" design such as that done by good advertising agencies). Anyway this kind of system is promising in three ways: 1) It could be used for totally automatic generation of graphics in situations where the underlying data changes so rapidly that the intervention of a human designer is not feasible (e.g. foreign exchange rates). 2) It could be used to generate better first drafts of graphs than those suggested by present "business graphics" systems. A human designer could then refine the graphs if necessary but with far less work than is currently necessary. 3). The system could alleviate the problem of having people (such as myself!) design documents without a sufficient graphics background. We very often see awful designs of reports produced on desktop publishing equipment. If an AI system could design the layout (or critique a human designer), much would be gained.
CHI'85 on the other hand was not nearly as exciting with mostly predictable papers. Not too many really new ideas or methods were presented. Even the video tape program was rather dull. The enthusiasm (or at least my enthusiasm) was back at CHI'86 which made you feel part of a field with plenty of action. As Ben Shneiderman said in his keynote talk: We are not just fooling around in small labs just to write yet another paper but we are changing the way people work and relate to computers. Maybe there was a tendency to having each of several established research groups work in refining their kind of special methodology rather than having new and exciting methods come up.
This last tendency was even more true at CHI'87: Certain people work in certain set ways, and there are not too many surprises. Maybe this is a sign of a rapidly maturing field.
The quality of the demonstration program has changed a lot over the years. Maybe I liked the format in 85 best with demonstrations being given as real talks to a large audience: I still remember the cheers and thundering applause after the demonstration of the Pinball Construction Set. In 86 I did not have as much time for the demos but I still attended a few good ones (e.g. Javelin) shown using a video projector. Also, Myron Krueger's Videoplace game room was one of the aspects of CHI'86 that gave me a morale boost as a user interface researcher. This year I was too busy (literally running from one meeting to the next) to spend very much time on the system demonstrations which were somewhat uninspirational: Just a bunch of Suns etc. in a big room [some funny quotes at the Siemens exhibit, though]. On the other hand, this new format does offer more opportunities for audience participation during the demos which I enjoyed talking to Allison Druin, the creator of the furry computer mentioned above.
Last year, the theme was the change from looking only at the interaction between one user and one computer to looking at computer-supported cooperative work. I am not sure whether CHI'83 and '85 had any such themes running through a number of conference events. If any, it must have been the need for and success of empiricism at CHI'83 and the existence of rigorous research methods at CHI'85. But in any case, of course each conference has been so rich that a single theme cannot describe it in full. It just seems to me that every year there is one subject that underlies a disproportionately large share of conference presentations and informal discussions among participants.