M. Stefik, D. G. Bobrow, G. Foster, S. Lanning, and D. Tatar 

Strict WYSIWIS requires that all users see exactly the same display at all times. The authors propose that strict WYSIWIS needs to be relaxed for some (if not all) real applications, since strict adherence to WYSIWIS principles often conflicts with the usability of the system. There are also many cases where strict adherence to the principles conflicts with the goals of the group and of individual users. In the authors experience designing CSCW applications, they found it necessary to relax WYSIWIS principles in the following ways: allowing both public and private windows on individual displays, allowing delay in broadcasting operations, allowing shared viewing to apply to subgroups (instead of strictly to the full group), and allowing individual views of shared objects. The paper reports in some detail on the authors experiences with the design of two CSCW applications: Boardnoter, which is a "whiteboard"-type application, and Cognoter, "a meeting tool for organizing ideas for a presentation".

Positive Points: I thought this was a very good experience paper. The presentation of "Issue/Design Solution" when discussing their experience with the two applications was clear and interesting. It focused attention on the design process, rather than on the final result, and thus their discussion is relevant to design of applications outside the specific domain in which they were working. For example their use of thumbnails to deal with the issue of wanting to present more information than the display is capable of is applicable to lots of different kinds of applications. Their discussion of various ways to indicate changes to information that is not the information currently in focus (say, the information currently represented only by a thumbnail) is similarly applicable to other sorts of problems.

Criticism: It is not clear that "strict WYSIWIS" is an interesting enough concept to merit the attack leveled upon it by the authors. It seems like nobody would ever try to build an application that adhered to "strict WYSIWIS", so perhaps their argument against it is a straw man argument.

Positive points: The tools proposed for Data Collection (Talking Aloud, Guided Tour, Structured Observations, Written Artifacts, Focused Interviews) are a good set of tools for non-intrusively observing real users in their real environments. When contrasted with, say, focus groups, I think these methods would reveal more about the real needs and practices of the user population

Criticisms: The paper never makes the connection between the results of the Data Analysis and the design specification, even though it is claimed in the introduction that the goal of this method is to produce usable design specifications. There is also little discussion of how exactly a particular conceptual model of a work environment is generated from the data collection and analysis phases, and there is little discussion of how exactly to apply the data analysis techniques to particular data. The paper is very short, so it is not surprising that it leaves a lot to the imagination. If the goal is to sell a new technique for designing applications, however, I think more detail is needed.