At a quick glance it seems full of useful stuff, along with some familiar things if you've followed blogs with the word "social" in the title.
The bit that grabbed my attention was the stuff in Chapter 9 about the making of the book. As someone whose job it is to make sure people can use the tools provided, some things struck me about their choices and the problems they had. (It's good to see such honesty in the first place too!)
The group was, as a whole, pretty technology savvy – or at least that was the assumption. This assumption led to the first major mistake [emphasis theirs]: not enough thorough evaluation of each participant’s level of social media competency and experience.
...
We ended up defaulting to e-mail quite quickly for two reasons:
firstly, because everyone was definitely using it; and secondly because we trusted it to give us our own record of what had been said that we knew we could rely on.
...
The project wiki was useful for collating content together, but it became cumbersome and ineffective for editing the final document together: it was too text-focussed and wasn’t useful for showing layout and graphics to the designer, and also it wasn’t appropriate for delivering to the client at NESTA and inviting formal feedback and signoff. We ended up collating the final handbook in Microsoft Word and using e-mail and tracked changes – which worked very efficiently but broke our collaborative approach in favour of getting the job done.
I'm not surprised they ended up using email. Even though it's not very good for collaboration, there's no obvious replacement (I wonder how they would have got in with Google wave?). Wikis are very text orientated, so you can see why they wanted to use Word for layout. But multiple copies of a document with track changes is still a bit clumsy. There must be a need for a good tool to do that sort of thing.
It's worth reading that chapter to hear what the other three major mistakes were.
2 comments:
You could use the Plutext Word Add-In. With this, each author can be in the document at the same time, and the versions of each section in the book are tracked separately, completely dispensing with the need to email around copies with tracked changes.
I'm a little surprised that the wiki didn't work well enough for them. Unless the book had to have complex relationships between graphics and text it would seem a two part process would work: 1. get agreement on content and graphics on a chapter by chapter basis; 2. have a page layout person pour content into final book form w/o changing content. It's what we do for our workbooks that we build in a wiki
Post a Comment