Dourish, P. and Bellotti, V. (1992). Awareness and coordination in shared workspaces. In CSCW ‘92: Proceedings of the 1992 ACM conference on Computer-supported cooperative work, pages 107-114, New York, NY, USA. ACM Press.

In this article, as the title says, the authors talk about awareness and coordination in shared workspaces, specifically in the context of collaborative writing.  By collaborative writing, we mean in this case that a team of people work together to write a single document.   By awareness, we’re talking about one team member’s awareness of what the other team members are doing, and what they have done.   This awareness has two aspects: the awareness of the character of another’s actions, and the awareness of the content of another’s actions.

Character refers to the kind of actions a person might perform in the context of the collaborative work: are they an editor, a reviewer, an author; what sections of the document are they responsible for; what part are they working on?   Character in this way is like the role that a person plays in the collaboration, although we should be careful when using the word “role”, since character and role are fluid, and can change as the collaboration progresses.   A person can use their awareness of the character of another’s actions in order to structure work and avoid duplication of effort.   The content refers to the work that a person has actually done: comments and annotations made; text written.  A person can use awareness of the content of another’s work to enable “fine-grained shared working and synergistic group behavior” (p. 112).

The purpose of awareness mechanisms within software is to help users see the character and content of their colleagues’ work, presumably without having to look over their colleagues’ shoulders or ask them what they are doing or have done.

Prior models for providing awareness

Previous attempts at building awareness mechanisms into collaborative editing software concerned informational mechanisms via which collaborators explicitly inform each other of their actions (e.g. RCS, CVS, subversion, etc. commit logs) and role restrictive mechanisms which in some way associate a set of possible actions and activities with roles built into the system, and then assign people to roles.

Dourish and Belloti say that informational mechanisms are inherently problematic (cf. subversion commit logs): the posting user gets no benefit from the update; the posting user determines what information to convey;  the posting user determines (in some cases) how to convey the information; and the posting user has to do extra work now in addition to the work of actually producing the work product (p. 109) .  About roles: don’t enforce roles, because roles are fluid (in collaborative editing anyway), and hard to define.   People may be reviewers in one minute and authors in the next.   Secondly, different people may have different ideas about what a particular role should do.   Some may take “reviewer” to mean purely annotation, others may want to edit the document (p. 108, 113).

The shared feedback model

Instead, Dourish and Belloti propose a shared feedback model, which makes “information about individual activities apparent to other participants by presenting feedback on operations within the shared, rather than the private, workspace” (p. 109).  We want the following things (reactions to things in the above paragraph):

• to collect and distribute awareness information passively, with low overhead for sender and reciever (no added work load)
• to make information available as and when needed as a context for individual activities, allowing participants to extract the awareness information most relevant to them
• to avoid  strict roles
• to present the awareness information within the shared workspace alongside the shared object, so that users can see the information and object concurrently, and find the information most relevant to the object

Some benefits of the shared feedback approach are that

• one can peripherally monitor other’s activities and comment on them, so that one is constantly both communicating one’s activities and allowing the opportunity for others to comment on them or observe them for themselves.
• users can tailor their contribution to convey collaboration and coordination information and solicit responses

Shared feedback is all about allowing users to see other’s work and actions as they occur, allowing them to interpret, contribute and coordinate more efficiently.

Shared feedback in semi-synchronous systems

What most of the article is talking about is everyone working simultaneously within the same document space, like sharing one single Word window, as opposed to using subversion to check out a working copy of the document, making your changes and then committing the changes.  This is synchronous editing  rather than asynchronous editing.  However,  “we can certainly imagine asyncrhonous awareness information presented in the same workspace as the work object” (p. 113).  For example: “change bars,” which highlight the area changed by the last editor, which may also include who did the changing, when, and the nature of the changes.   We can present past information of activity within the shared workspace at different levels of granularity.

The experiment with ShrEdit

Dourish and Belloti studied a group of designers using an application called ShrEdit, a synchronous multiuser text editor, to solve design problems.   ShrEdit allowed people to have both shared and private windows.  Shared windows shows a view onto the shared document, and each user has an edit cursor within their shared window.  Shared windows show text as it is being input by any of the participants in the shared document editing session.   Private windows are like typical text editors and show a document that only the user can see.  These were used for notes or for creating text which would later be pasted.  One user could see which other users were editing the shared document, and find the current location of their edit cursors.  ShrEdit provided some of the shared feedback model that Dourish and Belloti promote, but had some notable lacks: such as that one could not see one’s colleagues edit cursors.

The authors studied groups of three designers (all with previous experience of working together), each placed in a separate location and linked via audio and/or video to the others.    After a a training period, each group was given a specific design problem to solve collaboratively in 90 minutes.

“The shared workspace provided a focus for the designers’ work and discussions” (p. 110).   Talk was used  heavily to maintain awareness of activities, as well as to discuss design ideas.   Participants moved between nearly independent work and tightly focused group consideration of specific elements or passages, relying on awareness to know when to do what.  The activities of each group member varied continuously and opportunisitically as things changed.

The problems with ShrEdit concerned how much of other’s activities were viewable.   Participants preferred to ask where others were, or construct special indexing schemes to refer to, rather than use the provisions built into the software.   Having others be aware of what one was doing was very important, and was accomplished through speaking aloud.

Comments

First, I am struck by how subtle the shared awareness in ShrEdit is; I could not really see it the first time through the paper and ended confused.  I realize that I expect an explicit, orthogonal mechanism which provides awareness information.  But it was in fact the very core of ShrEdit that provides the awareness: that everyone has a window on the same live document and that everyone can see each other’s edits as they occur.  That’s the awareness mechanism that ShrEdit provided, primarily.  It also provided some explicit mechanisms, but they ended up not actually being used because they were too much work.

Secondly, Dourish and Belloti build voice/video links right into the experiement, and so much awareness information is communicated in speech, with the shared workspace providing shared context so that speech can be very efficient and contextualized.   And people universally used the voice/video link to do much of the coordination and awareness maintenance.   So they’re not assuming that the software replaces human interaction completely, which is an extremely interesting choice to me, because I’m assuming (in the world of wiki) that I have no direct human interaction but that all awareness information must be communicated via the system.

Third, I’m also struck at how related Cockburn’s osmotic communication, erg-seconds and shared workspaces (Cockburn, 2002) are to the provision of awareness information via software.  They’re really trying to solve the same thing.  Well, similar things.

There were two incidental take homes for me: try not to add to people’s workloads in order to supply awareness information (p. 109, 112);  people tend to want to respect authorship (p. 111).

Parnas’ essay is a plea to computer science/software engineering researchers to be more relevant to practicing developers by doing research the way he does it — essentially, by doing design science research.   He explicitly mentions the rigor/relevance dilemma (or failure in this case) as why he is so concerned: software engineering researchers write papers that are not useful to practitioners.   In this case, it is in the first sense that Straub and Ang (2008) describe: that the choice of topics or themes that researchers tackle are not helpful to practitioners.

He was influenced heavily in his outlook on research by two things: his engineering colleagues and a particular experience in an industry setting early in his career.  He describes engineering research as follows:

“The majority of those papers begin by describing a problem that is frequently encountered in connection with product design or production.  They proceed to develop a model of the essential or fundamental parts of the problem, abstracting from facts that they consider irrelevant, and then proceed to analyse that model  Finally, they show how the results of their analysis can be applied to solve, or improve the solution of, the original problem.  Somewhere in the paper, there is a survey of alternative approaches, including those in the literature and those in use in other industrial environments” (p. 64)

This is very close to the seven necessary parts of a design science study proscribed by Hevner et. al.   The only thing lacking from his descriptions are explicit rigor and scientific contribution, and (due to the nature of engineering as being about physical objects) deals with only mentions one of the four kinds of IT artifacts: models.

What is interesting about Parnas’ paper in contrast to Hevner is Parnas’ emphasis on close ties to the practitioner community, emphasizing personal interaction with actual developers to learn what real problems they encounter instead of considering software engineering from an academic distance.   In a critical experience earlier in his career, Parnas was fortunate enough to be embedded in a company among developers and was able to observe them at close hand and inspect their code and other work products.  This had profound impact on the way he chose problems to work on, and in the kinds of solutions he finds.  It was from this experience that he developed the now commonly used (but then nearly unthinkable) idea of information hiding in software design.

He describes some promising areas for research which yet have very little activity: inspection methods (allowing code inspectors to “proceed systematically, carefully considering all cases in a way that provides confidence that nothing has been overlooked” (p. 66); and documentation (studying ways to make documentation not be “unclear, incomplete, inconsistent or inaccurate” (p. 66).

He ends by giving advice to researchers: keep close to practitioners — read their code; look for causes instead of symptoms; look for problems that are longer term/bigger problems, not ones that developers are likely to solve themselves; ask why practitioners don’t use the ideas from software engineering research; be wary of fads and buzzwords.

References

• Hevner, A., March, S., Park, J., and Ram, S. (2004). Design science in information systems research. MIS Quarterly, 28(1):75-105.
• Straub, D. W. and Ang, S. (2008). Readability and the relevance versus rigor debate. MIS Quarterly, 32(4):iii-xiii.

Brooks, Fredrick P., “No Silver Bullet: Essence and Accidents of Software Engineering,” Computer, Vol 20, No 4 (April 1987), pp. 10-19

This is the famous article by Brooks which Cockburn referred to in Agile Software Development.  In it, Brooks defines some concepts relating to software development in order to help people see what makes software development hard in an effort (possibly) to dissuade people from believing that there is yet to be a silver bullet which will make software development easy enough for anyone to do well.   He says there are two classes of qualities of software: essential qualities, and accidental qualities.  The essential  qualities are extremely difficult to address or improve, while the accidental qualities can be improved via tool support.

The essential qualities all have to do wth the design of software: understanding the problem and designing and testing the conceptual contstruct.   The accidental qualities have to do with implementing the construct in code and testing it.

The essential qualities are these:

• Complexity: software design is complex: understanding domain concepts to the extent that one can define them and the relationships between them exactly is hard; this definition is essential if we want to translate those concepts into code.  Unlike physical objects, no two parts of a software construct are alike.  Scaling up of  a software entity necessarily means a scaling up in components and complexity.   The problem associated with complexity are: difficulty of communication of design among team members; difficulty in enumerating all possible states of the program (which brings unreliability); makes programs hard to use; makes programs hard to change without inducing unwanted side-effects.  The complexity makes overview hard (seeing and tying up loose ends), and the tremendous learning burden means turnover is costly.
• Invisible: can’t see it all at once as you would a physical piece of something.  It is also very difficult even to visualize since there are many ways to look at the same design: “the reality of software is not inherently embedded in space.”  This inhibits communication of structure and design.
• Changeable: we’re just pushing bits around in the end; changing ideas.  Therefore it is always possible to change a piece of software.  Software is inherently flexible where physical products are not. (McConnell , pp. 19-20).    Change comes in two ways: people use the software in ways not originally forseen in the design and want better support for that; and the physical machine/OS changes underneath us.
• Conformity: software must conform to external constraints (particular hardware, legacy systems and data, regulations) that make it difficult to reduce complexity.    Much of the complexity of interacting with human systems is arbitrary, and since software is percieved as changeable, it is most often seen as the thing which should conform, not the human system.

The accidental qualities are all about implementation and testing, and these have been solved almost as well as they are likely to be solved, so don’t expect many more breakthroughs.   Here are things that Brooks says have helped to reduce the impact of the accidental qualities (keep in mind he’s writing this in the middle of the 1980s):

• High level languages (including object orientation).   High level languages allow programmers to express implementation with concepts closer to that which we use in design.  We’re reducing or eliminating the translation step between data models, operations, sequances and communication and registers and bits.   This eliminates a lot of the translation complexity.   But Brooks says that “the most a high-level language can do is to funish all the constructs that the programmer imagines in the abstract program” and although our level of thinking about those constructs is improving, it does so at an ever decreasing rate.
• Time sharing and better OS support:  Time sharing is contrasted with batch processing, and it helps because we spend much less time in the code and test cycle.  By better OS support, I mean the difference betweeen DOS (which has no library and almost no system call support) and UNIX (which contains many libraries and a vast system call set, allowing you to not have to implement display code, disk drivers, filesystems code, etc.).

He then talks about hopes for the future, and discounts all as being silver bullets: Ada and other high-level languages, object orientation, AI (both in the idea of software solving problems that were previously the domain of human intelligence; and in expert systems), expert systems, automatic programming (we specify the requirements and the software writes code for us); graphical programming (a la LabVIEW), proof based  design verification, better tools, and workstations.

He identifies three promising areas that may help promote obtaining (note: not necessarily building) better software:

• Buy versus build. Remember that in the mid 1980s, the software market was still small.
• Incremental, iterative development with feedback from end users: because this helps to refine requirements, prove the design, and improves morale
• Identify, retain and coddle great designers: some people are just better at software design than others.  Try to identify them, retain them in your organization, and coddle them so that they get the skills and compensation that they need.

This paper is about devising a measure of interestingness of patterns.  Early on in knowledge discovery research, researchers realized that knowledge discovery systems can easily generate a huge number of patterns from a data set, most of which may be of no interest to the user of the system (p. 970).    And so researchers began to work on the problem of interestingness.   How do we know when a pattern found by the knowledge discovery system would be of interest to the user, so that we can only present such patterns to the user?    Researchers have taken two approaches towards developing interestingness measures:  objective measures, and subjective measures.

Objective measures are based only on the structure of the pattern and the underlying data used in the discovery process.  Such measures can be useful in some cases, but largely fail to capture the full complexities of the pattern discovery process, and can generate patterns that are objectively interesting, but which are still of little interest to the user.  Subjective measures of interestingness consider patterns from the point of view of the user, as well as the structure of the pattern and underlying data.     Prior work in subjective measures were limited in scope to a particular domain of patterns.

The measure that the authors propose, and the scientific contribution that they hope to make, is a domain-independent subjective measure of interestingness which can be used on patterns revealed by a knowledge discovery process.

They start by saying that there are two characteristics of a pattern that cause it to be interesting to a user: unexpectedness (it is “surprising” to the user) and actionability (the user can act on it to his advantage).   They go on to say that they believe that the majority of unexpected patterns are actionable, and  conversely that the majority of actionable patterns are unexpected.  Thus actionability and unexpectedness act as viable approximations of each other — we can look for patterns which exhibit one of those two characteristics, and assume that it also has the other.

It is hard to determine the actionability of a pattern for several reasons: we need to associate an action with each potential pattern (or pattern cluster, if we can partition the pattern space into subsets of similar patterns), which can be difficult or impossible (we may not know the full pattern space); and the mapping of actions to patterns may change over time, which means we have to do this difficult mapping over and over again.   Thus the authors chose to develop a measure of unexpectedness of a pattern.  Thus, this paper is about a domain-independent measure of subjective interestingness of a pattern which is a function of the unexpectedness of that pattern (p. 791).

The authors want to determine unexpectedness by examining the effects of new data on a person’s belief system: the more the new data changes a person’s belief system, the more unexpected it is.   A belief system is made up of one or more beliefs, which they define  as logical statements with an associated confidence level given prior evidence.   If b is a belief, then this confidence level or degree of belief based on previous evidence ? can be expressed as d(b??).  People have two kinds of beliefs:  hard beliefs, which are unchanged by new evidence (we suspect the evidence to be faulty instead); and soft beliefs, which can be changed by new evidence.

A pattern which contradicts hard beliefs is always unexpected and thus is always interesting (p. 975), so computing interestingness of such data is trivial.  Thus, much of the rest of the paper is dedicated to devising a measure of unexpectedness in relation to soft beliefs.

The authors provide four potential measures of degrees of soft beliefs and how they are affected by new evidence.  They eliminate three of them as impractical or too limited in applicability and propose a Bayesian approach (p. 973), which updates the degree of belief in a particular belief given new evidence by using Bayes rule.

They then write an expression which uses this result to express interestingness as how much degrees of belief within a belief system were changed as a result of new data.  They then show how, with this definition of interestingness, unexpected patterns do indeed cause more change in degree in beliefs than expected patterns.   Since we’re already saying unexpectedness as a proxy for interestingness, we can use this measure to estimate subjective interestingness: the bigger the measure, the more interesting the pattern.

They conclude by describing a general procedure for how one would use these concepts to look for interesting patterns in a database that gets updated with new data:

“When new data arrives, degrees of all the beliefs are revised based on new data.  If some of the degrees change above predetermined threshold levels, this means that there are some interesting patterns in the data and that the discovery processes to extract interesting patterns should be launched” (p. 974).

They call this belief-driven discovery.  The authors then say: see our upcoming paper, in which we describe those discovery processes.

Critique

In terms of Hevner et. al. (2004):

• The artifacts that the paper describes are constructs: interestingness, unexpectedness, actionability.   Those constructs are intended to address a real business problem that knowledge discovery systems have: knowledge discovery systems can easily generate a huge number of patterns from a data set, most of which may be of no interest to the user of the system (p. 970), which makes the system not very useful.
• The artifact could definitely provide utility if implemented correctly.
• They do evaluate their concepts (mathematically) to show that they do solve the problem they set out to do.
• Their measure does offer scientific contribution, because it is a domain-independent measure of interestingness, which had not yet been devised.
• They certainly are rigorous in defining and representing their artifacts by deriving mathematical metrics for estimating them.
• They do detail their search space for potential metrics for the effect of new data on belief systems (part of building the interestingness measure).
• They obviously communicate their results to a technical audience.

The only potential failures to stick to the seven characteristics of good design research as described by Hevner et. al. (2004) is in direct utility and in communicating to a managerial audience (they might have done this in another venue).

Utility

I see two issues around instantiating these metrics: defining beliefs, and computing prior and conditional probabilities.

Defining beliefs seems tricky.  Clearly, in order to use the metric they provide on p. 973, one has to express a user’s belief in a mathematically testable way.   One must also be able to quantify the degree to which one holds a belief (for soft beliefs).   It seems like both of these could be hard for most people.   I am guessing that how you might implement a belief is as a function or set of functions on a feature vector extracted from the dataset (p. 973).  Your belief is about what you believe the normal range of the output of that function should be given the data you’ve already seen.   Then you state how confident you are in that range of values.

In Bayes rule, computing appropriate prior probabilities and conditional probabilities (likelihoods, or posterior probabilities) can be hard (especially the likelihoods), and yet doing it correctly is critical for successful use of Bayes rule.  If you do it wrong, you still may end up finding uninteresting patterns.  For prior probabilites, you also clearly need some experience with the data before you can even have a belief ?and begin getting a good estimate of your prior probability P(?| ?).  For the conditional probabilities, they do seem to address this on p. 973.    In both cases, you need to know what aspects of the data to look at, which goes back to defining beliefs.

Of special interest to me are the technical aspects of how they did their work: figuring out the sequence of replies and attempting to deal with what they call email alias unmasking.   In the email archives of a traditional firm, one can trace back each email address to a real person (one can look in the organizational directory to figure out who corresponds to what address) and each person typically only has one email address.  Not so in such public forums as are used in OSS projects:  in such spaces, a single person may use many aliases (foo@gmail.com, bar@yahoo.com, foo.bar@abccorp.com may all be the same person), and discovering that those aliases all belong to one person is important for discovering the true social structure.

Summary of

Bird, C., Gourley, A., Devanbu, P., Gertz, M., and Swaminathan, A. (2006). Mining email social networks. In MSR ‘06: Proceedings of the 2006 international workshop on Mining software repositories, pages 137-143, New York, NY, USA. ACM Press.

The authors looked at the Apache developers mailing list archive and CVS repository commit logs, considering messages covering period of four or five years. They did so with the goal of studying communication and collaboration technologies (C&C) in software projects, particularly in open source software development. They are specifically interested in how activities in C&C correspond to development activities in the source code: what are the social properties of the developer network; do active communicators also make a lot of source code changes; do developers and non-developers play different social roles; and do the most active developers have the highest status among developers. They examined an open source project because most/all communications are purposely publicly available.

The authors looked at each participant in the mailing list, and divided the group into developers (those who contributed code or documentation changes to the CVS repository) and non-developers (those who didn’t). For each participant, they looked at how many messages the person sent, how many of their messages were replied to, and three social networking measures: in-degree (the number of edges connecting to a node in a directed graph; in this case, the number of different people to whom a person has replied), out-degree (the number of edges emerging from a node in a directed graph; in this case, the number of individuals who have replied to a person) and betweenness (the number of shortest paths that go through a node; high betweenness indicates that a person acts as a gatekeeper or broker, playing a role in many interactions). They also presented a directed sociogram of the Apache mailing list archive in which the arrows indicated who responded to whom more often (but didn’t do much with it).

They found that messages sent, messages replied to, in-degree, and out-degree follow a Pareto distribution (a power law probability distribution; a few people send a lot, but most people send a little), the latter showing a “long tailed degree distribution, characteristic of small world networks” (p. 141). There was a strong relationship between the number of messages sent by someone and the number of distinct people that respond to them (p. 141). They found a high correlation (Spearman rank correlation of 0.80) between messages sent and number of source changes made, indicating that C&C activity is correlated with development work (p. 141). There was a lower correlation between messages sent and document changes.

Developers do act as brokers or gatekeepers more than non-developers (p. 142), and generally have higher status (computed as what?), and developers who do more source code changes play more significant roles in the mailing list. Higher activity in source code changes is strongly correlated with higher activity in the mailing list; document changes are less so correlated. Generally, high in-degree, out-degree, and betweeness are correlated with status (how?) and source code change activity.

Data extraction

They used the Reply-To: address and Message Id: of each message to which a message is a reply (if any) to determine who replied to whom, and suggest that you could look through the contents for quoted text attributions. The sender of a reply is “one who found the initial message of interest” (p. 139).

One of the few groups to deal explicitly with e-mail alias unmasking: many people have more than one e-mail address, and ensuring that we count all the e-mail from those different addresses as belonging to that person is not trivial. They used a clustering algorithm plus manual inspection to develop a lookup table of e-mail addresses to names. The similarity measure they used for the clustering is based on the fields in the From: line.

They compared the normalized names to names and e-mails to e-mails using the Levenshtein distance, compared names to e-mails, and took the max scoring of the three (p. 139). They did this for all pairs of <name, e-mail> tuples. They used a similar method for unmasking CVS aliases.

Social networking measures

They comment on connectedness, but don’t use it except to say that the most highly connected people in the Apache network are, in fact, the most productive developers (p. 140), and that they are doing further research into that.

The “small world network” is a statement about mean shortest path and clustering of the network. Small world networks exhibit a power-law distribution of degrees of its nodes (few people are highly connected, and most people are not highly connected).  Scale-free networks follow an exponential distribution.

They used messages sent and out-degree to make the statement about number of messages sent vs. number of unique repliers. They’re doing further investigation into this.

They used betweenness with in-degree and out-degree to show that developers do act as brokers more than non-developers (p. 142), and generally have higher status (computed as what?), and that developers who do more source code changes play more significant roles in the mailing list.

Tufte’s article is really a critique of poor presentation skills, and a plea for better reasoning skills about information.  He asks that presenters and audiences do not simply accept PowerPoint’s default templates and modes as the proper way to conduct serious presentations of evidence: “The evidence indicates that PowerPoint, compared to other common presentation tools, reduces the analytical quality of serious presentations of evidence.”  He ends his article with a suggestion for how such presentations should be carried out: “serious presentations might well begin with a concise briefing paper or technical report (the 4-pager) that everyone reads (people can read 3 or 4 times faster than presenters can talk).  Following the reading period, the presenter might provide a guided analysis of the briefing paper and then encourage and perhaps lead a discussion of the material at hand” (p. 30).

Note that Tufte is specific about the kind of presentation he means: a serious presentation, “with explanations ot understand, evidence to evaluate, problems to solve, decisions to make, and in several examples, lives to save” (p. 27).  Kinds of presentations that Tufte is not talking about:

• the performance (David Byrne), Machine Project presentation
• the interactive demonstration (computer education)
• the marketing pitch (Steve Jobs at MacWorld)
• the political speech (offshoot of marketing pitch)
• other?

Five steps to better serious presentations

He gives these maxims as what should guide good, serious presentations.

Assume that your audience is intelligent, and found your presentation in principles of respect for them.   Use the core ideas of good teaching: “explanation, reasoning, finding things out, questioning, content, evidence, credbile authoirty not patronizing authoritarianisim” (p. 7).
Strive to be as clear as you can.  Be precise.  Use enough words (spoken and written), images, and information graphics in the right combination to clearly and precisely convey the information.   Give people all the data they need to make evaluations and decisions; don’t let the medium dictate how much you give.
Be honest and accurate.  Don’t distort the data.  Be respectful of human strengths and weaknessess.  For example, it is hard for humans to compare areas of objects (so pie charts are bad), but we’re good at  being able to compare sets of data (e.g. images) with our eyespan).
Allow your audience to explore, evaluate and discuss the information.
Use appropriate media to support the level of detail you need to do this.

Properties of computer projected presentations

Intrinsic characteristics:

1. LCD projectors have low resolution, hence low data density.  This determines the total amount of information we can convey on any one slide, and it’s not much.  This makes text and information graphics on slides be of limited usefulness.  High information density images, however, are worth it.
2. Projected things need to have large type so that people in the audience can read it.   There are only so many words we can expect to fit on a page and actually have people be able to read them.
3. Slides are presented sequentially and transitions are driven by presenter, not the audience.   The audience can’t go back to previous slides to review (without interrupting the presentation) or go forward to reconnoiter.  They can’t explore the information that’s being presented, and so they are put into the role of passive receptors rather than active learners.

Accidental characteristics:

• bullet lists
• hierarchies
• bad graphics
• transitition effects
• templates
• wizards
• etc.

All of the accidental charactersitics are avoidable, while the intrinsic characteristics are not (without much effort), and so it is those intrinsic characteristics that determine the cognitive style of PowerPoint.  That accidental characteristics caused serious problems as well in the Columbia slides are more a function of social consensus, lack of skill and lack of effort.

My critique

Much of what he complains about as the product or fault of PowerPoint I think is the lack of skill in the presenter in organizing information and presenting it.  He addresses this particular critique with a paraphrase of George Orwell: “PowerPoint becomes ugly and inaccurate because our thoughts are foolish, but the slovenliness of PowerPoint makes it easier for us to have foolish thoughts,” (p. 27) and “To make smarter presentations, try smarter tools.” (p. 28) implying that simply using PowerPoint can make you a bad presenter.

I think that skilled craftsmen can make quality work even with poor tools, while poor craftsmen can’t make quality work even with good tools.  Presenting at all is a skill, something that requires natural talent, training, a lot of practice and a lot of self-reflection.   You need to be able to organize information into a story that can be told sequentially (in time) and still make sense; you need to be able to tailor that information to your audience; you need to tailor your presentation to your goal — teach, inform, persuade, entertain;  you must be able to entertain your audience even if your goal is something else.   I think that if a skilled presenter is conscious of the intrinsic limitations of computer projected media, and can avoid or use to her advantage the accidental qualities, she can use PowerPoint (or Keynote, etc.) to advantage.

Secondly, I think he over-simplifies the kind of data one might need to convey in a serious presentation (video and images and sound, websites, technical demonstrations, visiting websites) and ignores how valuable a common focus is when doing collaboration.

Edward Tufte

Edward Tufte is a primal force in information visualization, and his books are referenced commonly in papers which propose or use visualization tools or techniques.  Google Scholar lists 2208 cites for The visual display of quantitative information, 1395 for Envisioning Information, 800 or so for Visual explanations.  Prof. Tufte (he is professor emeritus at Yale University) has made a mission of educating people on how to honestly, clearly, and effectively present information.

The Medium is the Massage was written in 1967 (two years before I was born) and in it McLuhan discusses voice, writing, and “electric” media (esp. television) and their effects on individuals, cognition and society.   The graphic design of this book is said to have been the basis for the design of Wired magazine [1].

He says “Societies have been shaped more by the nature of the media by which men communicate than by the content of the communication” (p. 9).   The book seems to be at least partly a reaction against the printed word, with its rationality and linearity, with its emphasis of the visual at the expense of the auditory and tactile, and with its encouragement to people to go off and be individuals and abandon the company of their fellows as opposed to electronic media’s global village.

I think McLuhan is strongly emphasizing the participatory role of information technology (primarily electronic communication) in some cases, and its mass media broadcast role in others.

• Electronic communication technology lessens distance (by reducing the time it takes to talk) between people and thus weakens social boundaries. McLuhan is believed to have coined the term “global village,” [1] meaning this is both in the sense of community (p. 10) and in the sense of “it takes a village to raise a child” (p. 13); electronic data storage and communication allows people to access information that their peers, family and locality don’t have.
• Different media use our senses (sight, sound, touch, (smell, taste?)) in different ways, and this in turn affects the way we think and view the world, which in turn affects the environment we build for ourselves.  That’s the “massage” in the title.
• The environment we live in is invisible to us, embedded in it as we are.  One purpose of art is to draw our attention to the world we live in.
• Disruptive technologies can be incomprehensible to an established environment.  People try to use the new technologies to keep doing what they did with the old one (p. 74) (single loop) while not seeing that the new tech fundamentally changes what can be done (double loop).
• New media emphasizes a holistic rather than reductionistic way of living: roles rather than goals.
• The printing press helped bring about individualism in ways that the copied book (copied by monks) or the oral tradition (bards) could not. Printing technology created copyright, and electronic media may change how that is implemented. He says that the idea of copyright came with the advent of printing technology (p. 122), because the effort of copying texts was so great that there was no public readership, no public.   Texts were shared among a small group of scholars and there was no commercial aspect.   Printing technology created public readership, and suddenly you could sell your books.  Fighting piracy became important, and thus copyright.  He starts to consider the effect of cheap reproduction (Xeroxing) on copyright and how it becomes easier to get around it (p. 123)

References

1. “Marshall McLuhan”, wikipedia.org, http://en.wikipedia.org/wiki/Marshall_McLuhan , retrieved Sep 21, 2008.