This article was first published on 7 January 2005.
Introduction
Conversation analysis is simply the analysis of conversations. Coming from fields such as sociology and discourse analysis, it delves deeply as a qualitative method of investigating how people interact. The data produced are extremely rich, and may shed light on communicative interaction that could help in the design of interfaces for collaborative software (which has recently acquired the name of “social software").
Interfaces to collaborative software
The problem with collaborative interfaces is that a lot of the richness of human communication disappears. We take a lot of this for granted, and without social cues, it is easy for anyone to misunderstand the context of another persons discourse. The ideal collaborative software would allow the full and natural expression of other peoples non-verbal communication. The most obvious solution is video which presents an enormous amount of information, but there are problems in terms of access to technology (do people have cameras?), the efficiency of the technology (are the pictures good or choppy?), the effectiveness of the technology (does it really work as well as face-to-face interaction), and so on.
However, much against the field of usability, I don’t think it is necessarily a bad thing for humans to adapt to computer systems. Text messages (SMS’s) and their awkward interface show that people will adapt their behaviour if they can see a benefit in doing so. Very effective collaborative software might be the same if it offers benefits.
[As a side-point to this, I find it interesting that many people easily develop artifacts of expression in a constrained interface. Emoticons ("smileys") are an example: In a strictly text-based interface, people still managed to express their emotion in a very simple and yet non-textual fashion. Again, this shows how people adapt to constrained situations by developing new methods of communication.]
Therefore, it is quite probable that new methods of truly collaborative software will require humans to develop new behaviours that allow them to express at least a part of the richness of emotion.
But what is this richness, and how can we find out about it?
Conversation analysis
Conversation analysis offers a possible way forward. It was based on work by Harvey Sacks and has branched into discursive psychology, a study of the real world use of language.
Charles Antaki has written a very readable introduction to conversation analysis which I recommend reading. The interesting point is the difference between the first, purely textual transcript made of a simple conversation, and the final transcript ready for analysis. The gaps in time between each persons responses are noted, as well as interruptions, shortened words, intonations and the such like. This gives a clear example of how much information a purely textual transcript would miss.
A good analyst will be capable of picking up on the important but subtle nuances of the communication between people that would otherwise go unnoticed.
Charles notes that great care must be taken during both the transcription and analysis stages, and here, the experience and skills of the analyst really come into play. A good analyst will be capable of picking up on the important but subtle nuances of the communication between people that would otherwise go unnoticed. These findings can then help to inform the designers about what might be expected in an interface. For example, in the conversation, both of the women laugh and that is noted in the original. However, the type of laugh might also be important: is it a sneer, a belly laugh, a conspiratorial giggle, or what? Such things characterise the way in which people communicate, and collaborative oftware may need to provide a full account of them to be fully effective.
Conversation analysis and collaborative software
However, very often such things may not be needed. This is where a good user requirements document is worth its weight in gold. One that was drawn up by a team of analysts (including usability / HCI analysts) will know exactly what the communication needs are (i.e., does the receiver of a communication really need to know the senders intent, or is it obvious from the text or work context? Customer facing workers would probably have to have as much information about the customer as possible (for example, a very angry customer might be dealt with differently from a happy one), whereas two people sharing an office can easily rely on real world cues simply by asking their colleague.
I would recommend that the developers of collaborative software observe how users perform the task in the same room. Analysis of the communicational cues (verbal and non-verbal) would inform the developers as to the extent to which the software needs to allow expressive communication or not. With this analysis, any essential communicative components can be built in to the interface.
A nest of links:
Conversation-analysis.net - a “national resource for scholars and students of conversation and interaction analysis in Denmark".
Loughborough University has an introduction to conversation analysis.
The International Institute for Ethnomethodology and Conversation Analysis.
University of Amsterdam’s Paul ten Have has a detailed discussion of methodological issues of conversation analysis [available from archive.org].
The University of Indiana has a list of articles.
Conversation analysis and collaborative application interfaces
Introduction
Conversation analysis is simply the analysis of conversations. Coming from fields such as sociology and discourse analysis, it delves deeply as a qualitative method of investigating how people interact. The data produced are extremely rich, and may shed light on communicative interaction that could help in the design of interfaces for collaborative software (which has recently acquired the name of “social software").
Interfaces to collaborative software
The problem with collaborative interfaces is that a lot of the richness of human communication disappears. We take a lot of this for granted, and without social cues, it is easy for anyone to misunderstand the context of another persons discourse. The ideal collaborative software would allow the full and natural expression of other peoples non-verbal communication. The most obvious solution is video which presents an enormous amount of information, but there are problems in terms of access to technology (do people have cameras?), the efficiency of the technology (are the pictures good or choppy?), the effectiveness of the technology (does it really work as well as face-to-face interaction), and so on.
However, much against the field of usability, I don’t think it is necessarily a bad thing for humans to adapt to computer systems. Text messages (SMS’s) and their awkward interface show that people will adapt their behaviour if they can see a benefit in doing so. Very effective collaborative software might be the same if it offers benefits.
[As a side-point to this, I find it interesting that many people easily develop artifacts of expression in a constrained interface. Emoticons ("smileys") are an example: In a strictly text-based interface, people still managed to express their emotion in a very simple and yet non-textual fashion. Again, this shows how people adapt to constrained situations by developing new methods of communication.]
Therefore, it is quite probable that new methods of truly collaborative software will require humans to develop new behaviours that allow them to express at least a part of the richness of emotion.
But what is this richness, and how can we find out about it?
Conversation analysis
Conversation analysis offers a possible way forward. It was based on work by Harvey Sacks and has branched into discursive psychology, a study of the real world use of language.
Charles Antaki has written a very readable introduction to conversation analysis which I recommend reading. The interesting point is the difference between the first, purely textual transcript made of a simple conversation, and the final transcript ready for analysis. The gaps in time between each persons responses are noted, as well as interruptions, shortened words, intonations and the such like. This gives a clear example of how much information a purely textual transcript would miss.
A good analyst will be capable of picking up on the important but subtle nuances of the communication between people that would otherwise go unnoticed.
Charles notes that great care must be taken during both the transcription and analysis stages, and here, the experience and skills of the analyst really come into play. A good analyst will be capable of picking up on the important but subtle nuances of the communication between people that would otherwise go unnoticed. These findings can then help to inform the designers about what might be expected in an interface. For example, in the conversation, both of the women laugh and that is noted in the original. However, the type of laugh might also be important: is it a sneer, a belly laugh, a conspiratorial giggle, or what? Such things characterise the way in which people communicate, and collaborative oftware may need to provide a full account of them to be fully effective.
Conversation analysis and collaborative software
However, very often such things may not be needed. This is where a good user requirements document is worth its weight in gold. One that was drawn up by a team of analysts (including usability / HCI analysts) will know exactly what the communication needs are (i.e., does the receiver of a communication really need to know the senders intent, or is it obvious from the text or work context? Customer facing workers would probably have to have as much information about the customer as possible (for example, a very angry customer might be dealt with differently from a happy one), whereas two people sharing an office can easily rely on real world cues simply by asking their colleague.
I would recommend that the developers of collaborative software observe how users perform the task in the same room. Analysis of the communicational cues (verbal and non-verbal) would inform the developers as to the extent to which the software needs to allow expressive communication or not. With this analysis, any essential communicative components can be built in to the interface.
A nest of links:
Conversation-analysis.net - a “national resource for scholars and students of conversation and interaction analysis in Denmark".
Loughborough University has an introduction to conversation analysis.
The International Institute for Ethnomethodology and Conversation Analysis.
University of Amsterdam’s Paul ten Have has a detailed discussion of methodological issues of conversation analysis [available from archive.org].
The University of Indiana has a list of articles.
No comments:
Post a Comment