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.

surface

a tablet and a laptop are two conceptually separate things which will probably have to evolve separately as long as keyboards are our primary method for entering text data. on a laptop, writing is possible, even easy (we do it all the time). on a tablet, regardless of the quality of the attached keyboard, writing is a pain. a tablet is primarily and optimally a device for consuming content, not for generating content. a laptop or desktop is relatively better for generating content and is okay for consuming it.

the tablet's native text input device is a virtual keyboard and other interactions occur through a touch-screen interface. this pulls the hand away from the keyboard even for minor navigation, as anyone who's ever tried to move a cursor in a block of text knows. worse, as implemented in the major tablet operating systems, virtual keyboards don't persist when users switch applications or views (nor should they persist, given the size of current virtual keyboards relative to tablet display sizes).

when entering and editing text is a major use case, both a keyboard touchpad (as on a laptop) or a mouse next to the keyboard (as with a desktop) are superior to touch interfaces for non-text entry interaction. i've brought only an ipad and a keyboard with me on several trips of various lengths, leaving the laptop at home. if i have to do any real work at all—writing, editing, really anything more than reading feeds and emails that require only short responses—the combination of ipad and keyboard is intolerable: it remains a tablet that needs you to touch its screen to navigate, except with a keyboard attached.

now, how about a tablet (with exclusively touch-oriented interaction) that might convert under some conditions to a keyboard- and touchpad-oriented tablet device? (such conditions being: a keyboard + pointer combination being attached, whether directly or over the air.) this would work, but only if the OS successfully switches interaction logics completely, from virtual keyboard+touchscreen to keyboard + pointer device. something like this is probably unlikely to come from accessory manufacturers, since it requires significant OS integration.

this means that surface is potentially quite interesting. but i am ready to have my heart broken again by technology and dumb UX decisions.