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.

computational literacy and the gibsonesque present

January 26th, 2011 • library, tech
Tags: bruce sterling, burning chrome, computational literacy, computer science, design, education, eric meyers, future, google docs, gui, informal, infrastructure, instruction, interaction, libr535, metacognition, michael twidale, programming, school, sf, skype, social learning, special effects, touchscreen, twitter, unintended consequences, unix, video, vimeo, william gibson

After an 8am class on instruction in which we started to learn about treating lessons as products to be designed, I attended a colloquium by Michael Twidale about Computational Literacy & Metacognition (here are my rough notes).

It was a pretty excellent talk about the way we teach people how to do computery things. What I liked best about it was that Dr. Twidale was coming at this from what he called an Engineering point of view as opposed to a Science point of view. The idea that rapid prototyping in research might be more useful than studying precisely how things work at a point in time is something I’m very sympathetic to. I especially loved how he discussed the unintended effects of different technologies that go beyond what their designers had in mind, such as Twitter revolutions and large touch-screens enhancing learnability and interaction because of their poor usability for one person. I couldn’t help but be reminded of the famous William Gibson line from Burning Chrome “…but the street finds its own uses for things.”
Read more »