On distributing my office whiteboard
OK, I'm actually going to talk about the modelling user experience for the first time.
I did promise that this would be the subject of my blog and I've been a bit lax in getting around to the subject...
I think there's wide agreement that sketching on the whiteboard is one of the primary scenarios for modelling. If you're a professional software developer working in a team, I'd be surprised if you haven't spent some time in the last week clustered around a whiteboard with colleagues drawing some sort of diagram. Did you think of yourself as engaged in the act of modelling at the time? Maybe, maybe not; but there's also a reasonable chance that the diagram bore some resemblance to one of the diagrams from a version of UML, or a database model in some kind of entity-relationship form, or a system or deployment architecture diagram? How about a process flow diagram?
My colleague Stuart has a great post discussing how the design of visual languages can be influenced by an expectation of providing tool support for them. In the comments, there's a discussion of the value of group design and how tools can make that hard compared to a whiteboard. The trouble is, in today's world of globally distributed teams, the person I want to brainstorm on a design with might not be in the next corridor, the same building, country or continent. Now all of the languages I mention above could be and indeed are formalized for use in tools so there's no problem per se, the problem is in the experience. Do we swap files by email or is our tool backed by a database that we both access? If this is your interoperability, then in my experience you just don't do it. We work from several sites in the UK and across the pond to Redmond on a regular basis in my team and we've started to rely on real-time collaboration technologies. We make extensive use of Office LiveMeeting, Windows NetMeeting, Windows Messenger Application Sharing and whatever else we can get our hands on. All of these are a step up, but right now I'd say they are a pretty long way away from the whiteboard experience when using a highly graphical interactive tool.
Recently we tried the new shared workbook feature in Office OneNote. This was by far the best experience we've had so far. Now we weren't modelling here, we were just building and restructuring a document, but there were a few key experience differentiators from previous honourable technologies that I've mentioned.
Firstly there was no "baton". By this I mean that there was no concept of one participant owning the mouse pointer at any given time. We could both add to the document whenever and wherever we saw fit. Now this might sound like chaos, but actually it works. Just as with a whiteboard, you naturally don't tend to go overwriting the area that someone else is working on. That would just be rude.
Secondly the performance felt super-snappy even though some of what we were adding was relatively complex content. My reading of this is that because the comms is built right into the application then it is free to optimise the protocol. If you're using an unintegrated RTC client, then it hasn't a lot to go on other than the lowest level of screen and gesture primitives.
it was also "nearly trivial" to record the conversation we were having as well through the session. I managed to record my side of it perfectly well, but I suspect I need some sort of clever audio driver to record the mixed output from my sound-card and mic input as a single stream in OneNote.
What was less great? Well we couldn't start the session seamlessly from Windows Messenger, which is where most cross-site conversations begin.
So is this a killer feature for next generation modelling tools? You tell me. Until we all have networked LCD whiteboards (and the holographic web cams to go with them), I want it in my tools.
