co-presence and collaboration

last night, we talked about the difference between services that allow users to be remotely co-present and those that allow users to remotely collaborate.

co-presence is consumption behavior: you are with someone, observing what they are doing. all get, no post, no problems with collision. collaboration is production behavior: you are with someone, working on something together. collaboration is much harder to do well, and gets harder the closer to realtime the collaboration is: at minimum, it requires good collision handling and clear attribution at close to the minimum atomic size of the content being produced. text seems to be the only content being collaboratively produced in any large quantity now and text requires sub-sentence attribution markings. gdocs does neither particularly well, while hackpad does a great job: it is a first-class collaborative document editing tool marked by economy of means. hackpad is nearly feature-complete for my use-cases.

the closer to realtime the collaboration behavior is, the more important it is to have both a way be co-present and a way to collaborate. this is not only good for the user, it is a natural way for the service to reduce collision problems: collaborators tend to avoid bits which they know other collaborators are actively working on. it is smart to build services that tacitly encourage good use. the co-presence information that supports this kind of behavior can be parsimonious and still be useful. this is the only thing that hackpad doesn't yet do which i would love and gdocs does it well: the highlight cursor that shows where someone else in the document's cursor is, to me, a lightweight and effective co-presence indicator. a richer but still lightweight co-presence implementation would be to indicate what other active users are looking at as well as where they are entering new text: viewports and cursor locations.

importantly, though, not all products need this sort of collaboration and co-presence infrastructure built in. some collaboration products need strong norms rather than technical infrastructure to support collaboration. wikis are good for large distributed production and solve the collaboration problem with human gardening; making it possible for lots of people to work on a wiki without wiki interaction norms is probably not a good idea. other products simply don't require collaboration at all. just because you can doesn't mean you should. motivations and objectives are good to think about when making things.