At the time of writing the first edition, I didn't fully appreciate the harmony between the idea of "communication as touching into shared experience" and the articles in Appendix B by Pelle Ehn and Peter Naur. (New readers may want to skip this section until they finish reading Appendix B. I am writing this section as though you have read Appendix B and have come back to this point.) Within the last five years, people first applied the idea of "communication as touching into shared experience" to project documentation. Teams are being more creative in using alternate forms of documentation to serve as markers and reminders for other team members.[1] They are separating what is needed as "reminders for the people who were in the room at the time" from what is needed as "catch-up information for people who were not in the room at the time."
This is, of course, very much in line with Peter Naur's article "Programming as Theory Building" in Appendix B. Naur describes designing a program as creating a theory of the world (we might say model instead of theory today) and another theory of how the program operates in that world. To remind someone about a conversation in which he participated, we point into his theory (or model) and point as directly as possible into his shared experience. For this purpose, it is desirable to keep the original, messy, handwritten flipcharts. If we rewrite them into clean computer text, we lose the exact referencing mechanism we want to utilize. It also works out, handily enough, that keeping the original flipcharts is fast and cheap, whereas rewriting them online is relatively time-consuming and expensive. So using the original flipcharts as reminders is both cheap and effective. However, it is quite different when the purpose is to bring someone else up to the team's current state of understanding (their theory, in Naur's terms). The same messy flipchart that is so effective as a reminder is unlikely to contain the cues necessary for the new person.[2] Most of the time, the team will choose to use a completely different approach to documenting their current state of understanding to help the new person catch up with them. However they approach it, a great deal of information is inevitably lost, just as Naur describes in his article.
In the second article in the appendix, Pelle Ehn describes the difficulty he and his programmers had communicating with their computer-näive users in the 1970s. Surprising most people (including me), he wrote that complete communication is not necessary:
His insight is relevant again today, when ethnographers and user experience designers still try to understand the work habits of users and from that understanding construct a good user interface. At a time when we work so hard to understand our users, it is good to be reminded that complete communication is not possible. . . but it is also not required. What is required is to play the language-game, acting and reviewing the feedback over and over in never-ending cycles of improving utility. You can apply the lessons of "touching into shared experience" in your own environment:
|