Posts Tagged ‘tasks’
collaboration and cursing racers in google docs
July 25th, 2011 • 1 comment library, tech
Tags: basecamp, collaboration, computers, design by committee, games, google docs, google wave, layout, libr559m, libreoffice, module 3, planning, rapid prototyping, road trip, school, separate, tasks, workflow
The best collaboration tool I’ve used so far in library school is hands down Google Docs. I use wikis at work and we used BaseCamp for planning the NetworkEd UBC project, but nothing beats the big G on this.
The best part about it is when you’ve got five people collaborating on a document and everyone has it open on their respective laptop and everyone is editing the text at once. There’s a bit of give and take on that, since it is annoying to be working on the exact same sentence as someone else, but when something like deleting typos becomes a race that’s a fun tool.
When Google Wave came out I got in on the open beta, but there wasn’t a lot to do with it. My friends and I created a Wave to plan a road trip to Chicago, and while it worked, there wasn’t anything about it that was fun or useful. Integrating the best bits of Wave into Google Docs was a great step forward.
I think part of the appeal of Google Docs is that you are producing something, not just talking about producing something. I mean, it’s fine to use tools to chat and plan and such, but if it’s not integrated into the actual production, it’s just another step being pushed into your workflow. If you can collaborate directly on the work that’s a huge deal. You don’t have to reproduce your notes or people’s good ideas into the thing you’re producing, because it’s all right there.
Now, so far I’ve only handed in assignments straight from Google Docs for in-class types of things. Getting them out into LibreOffice is important to get the layout as right as I get fussy about. But separating out the layout/final touches kind of work seems far less onerous than separating the collaboration itself.
That’s what I want out of collaboration: actual work being done rather than having a separate step to talk about the work we want to do. I hate meetings that are just about assigning tasks when you could just be getting to it, right there. The rapid-prototyping model is built into this kind of collaboration. A person writes a sentence. It doesn’t work and gets rewritten right there. There’s chatting in the sidebar about why it doesn’t work and what would be better. “How about this?” someone can ask and you can see if it works or not. There’s no separate step of coming together to pull words apart and then going back to work on it again. Everyone sees the sausage being made, and that’s a good thing.
In my mind this also deals with a bit of the design by committee problem. You aren’t coming up with innoffensive ideas that’ll make it through, you’re putting stuff down with the knowledge it could get zapped straight off but if you delete something you’ve actually made a hole in the project that you need to fill. Maybe that’s not how it works for other people, but that’s the kind of collaboration model I see as a worthy goal, suggested by Google Docs. Collaboration can’t be a separate step, because that makes it easier to ignore.
Really though, I just like racing cursors.