View source for Talk:Tools for collaborative editing of documents

{{E-Discussion - Talk Header}}

{{Centered Box | text=[http://dgroups.org/ViewDiscussion.aspx?c=038278af-a7cd-4c4e-bed0-ac8ea0b7b57f&i=b770790f-d833-4407-980a-497e91795dc4 part 1] , [http://dgroups.org/ViewDiscussion.aspx?c=038278af-a7cd-4c4e-bed0-ac8ea0b7b57f&i=ee52c2c7-c677-4d99-92bf-fef91b5648b7 part 2] See the original thread of this E-Discussion on D-Groups }}

== Jean Blaylock, 2009/03/17 ==

Does anyone know of any tools like Word's 'track changes' that would facilitate displaying changes from more than a few people?

Situation: a strategy document for a network of around 50 member organisations which they are receiving for comment in order that eventually we get a document to which they all sign up. A working group of twelve people has drafted the strategy document and will need to receive and take account of all the comments made.

Technically they could all be put into one Word track changes, but the document becomes incredibly hard to follow (although at least the areas where there is absolutely no dispute stand out).

Realistically this probably has to be a tool where one person compiles the comments into some form that the working group can then go through.
Ideally it would be lovely to have some kind of online tool where the network members could see others comments as they make their own; this would help to build understanding of the range of positions and easier acceptance if their changes are not all taken on. But my main wish is to make sure as many as possible do give their comments, and I don't want to create extra barriers through unfamiliar software.

We have looked at [http://www.textflow.com TextFlow] , which looks to be developing into a nice tool, but it is really designed for one person to assess multiple comments and accept or reject. There is no way to save the document in its multiple comment stage and then share this with others. 

== Stephen Bounds, 2009/03/17 ==

Hi Jean,

It's a little clunky, but [http://www.quicktopic.com/10/D/9hmkxh7US2d?inline=1Quick Doc Review]

== Jaap Pels, 2009/03/17 ==

Hi jean,

My advice is to chop / chunk the text up and make wiki pages of it. All changes will be recorded and kept as revision. Further people can only edit / annotate / comment on text they really want to edit (and not the whole document). Also with a wiki / chunking approach people do not have to wait for
the whole document to be commented etc.

== Rahul Dewan, 2009/03/17 ==

We've started using https://www.getdropbox.com/ recently to work on common project document files across teams. It's turning out to be a great productivity tool for us. Maybe this helps you as well.

== Pete Cranston , 2009/03/18 ==

hi

I agree with Jaap that wiki's are very flexible for the early stages (divergent?) of collaborative document except that people do have habits. I'm just completing a longish document, built from research in five places, and while several people used the wiki well some people just don't: they don't like the openness and are used to constructing ideas and reporting in a linear fashion. It's no problem, just increases the workload of the coordinator, but important in terms of team dynamics to allow people to use their favourites.

Thanks everyone for all the tips, but at the last stages now, when I want to embed graphics and pictures, use tables and play with formatting (boxes,
indents etc) to a long document - 50+ pages - I am not convinced there is a viable alternative to Word, or probably open office (I know, shame on me)

== Matt Moore, 2009/03/18 ==

I think there are actually 2 activities going on here:

One is the ability to add comments to chunks of existing text - what might be called a "diverging" activity.

The other is ability to collaborate on a final version of the document - a "converging" activity.

I would treat these as two separate phases.

For phase 1, I would use a discussion forum with each chunk of text as a separate topic and allow discussion around those chunks to occur.

At some point either people will reach a consensus, agree to disagree or else you will have to step in and call time.

For phase 2, you parcel out the writing of the document and use a wiki or Google Docs to cocreate.

IMHO if you try to mix the 2, it will be a mess.

== Sam Lanfranco, 2009/03/18 ==

I think I would take Matt Moore's "2 activities going on here" one step further and differentiate between three dissimilar activities.

1. "Diverging activity": multiple stakeholders are all over the map in of formulating something like a strategic plan, project proposal, or position paper. Here breaking up the sections and working on them in something like a wiki space is ideal. I have found that trying to use the editing options in MicroSoft Word is a nightmare at this stage of the game, even with only two or three participants.

2. "Converging activity": general agreement as to where the task is going but still the need to refine that into a coherent whole. Again, sections in wiki space works well, unless one is down to only a few people doing the "converge". I still find the Microsoft Word editing options risky here.

3. "Wordsmithing": the final product with the task is down to shorting item lists, sharpening focus, finding just the right phrase to make the point,
staying within word limits, and marketing ideas. Here MicroSoft Word's collaborative editing tools can be used to advantage.

However, I must confess that even at this final stage I prefer the simpler approach of using the "highliner" option in any word processor and assign
highliner colours to each of us so we can "highlight" our suggestions and wording, and use "un-highlight" and "delete" as simple editing tools. 

== Matt Moore, 2009/03/18 ==

Sam,

1. "Diverging activity": multiple stakeholders

Nice move into 3 parts! For Part 1 I would use a discussion forum rather than a wiki (or even post each chunk as a blog post and allow lots of comment threads underneath).

You could use a wiki but then you risk participants overwriting each others' text. Depends on how feisty the discussions are going to get...

== Sam Lanfranco, 2009/03/18 ==

One last comment on collaborative document construction:

Peter Cranston mentions having to resort to a word processor (or publishing software) for "..embed graphics...pictures...tables...formatting...etc".

I agree and share a lesson I learned long ago from a professional editor. Have all of the preliminary work done in minimally formatted plain text, with simply place holders for the tables, graphics, etc. Store them for separate but convenient access (wiki space is good for that). As the very last stage, do the formatting and merge the tables, graphics, etc.

There is nothing more maddening when producing the final polished document than trying to edit out a wide variety of formats embedded in a collaboratively constructed document. Keep it "plain vanilla" until the last step.

== Kim Tucker, 2009/03/18 ==

Hi all,

[http://www.wikieducator.org/OER_Handbook/educator WikiEducator] includes threaded discussions on the "discussion"tabs.

(click on "discussion")

In that exercise we [http://www.wikieducator.org/OER_Handbook/educator/issue_tracker used an issue tracker]

(another example is given below as this one has been cleared) and [http://www.wikieducator.org/OER_Handbook/educator/Style_guide style guide]

We also captured some of the [http://www.wikieducator.org/OER_Handbook_Development lessons learned]

The printable result(s) (pdf) are available from [http://www.wikieducator.org/OER_Handbook Lulu via this pag]

Kim

PS Another example issue [http://en.wikiversity.org/wiki/Portal:Social_entrepreneurship/Issue_Tracker tracker]

(though this exercise is not leading to a single printable document)

== Paul Mundy, 2009/03/18 ==

Sorry, but as a "professional editor" I disagree with this advice.

I find it much better to have a document that already has a _limited number_ of styles built in. In Word, I use Body Text (or Normal) for all the text,
plus Heading 1, Heading 2, etc. for the headings, and a small number of other styles for other types of text: eg, Table body, Table heading, Caption, and so on.

It's important to keep the number of styles small and not to add extra formatting without good reason (eg, bold for emphasis, italics for foreign words).

Using Word's Heading styles has three big advantages:

* It keeps your headings clear. A big problem with many manuscripts is that it's hard to know what level a particular heading should be. Labelling something as Heading 2, for example, makes it obvious.

* It lets you use Word's Outline View (one of the little buttons at bottom left of the screen) to view only certain levels of headings (eg, all the Heading 1's). Outline View lets you reorder sections of the manuscript just by moving headings around, so lets you structure your manuscript logically. You can also promote and demote headings easily.

* It lets you generate a Table of Contents (on the menu, select Insert > Reference > Index and Tables).

If an author has used Styles, then it's easy to convert from one to another.

Unfortunately most Word users do not know how to use these particular features. They format each word or paragraph separately by visiting the Format menu, rather than by merely selecting a Style. In which case, Sam is right - plain vanilla is better.

I use Styles so much that I've created my own toolbar and buttons for the styles I use most often. Let me know if you'd like to know how to do this.

== Paul Mundy , 2009/03/19 ==

In response to overwhelming demand :-) (that means you, Samantha), I've just developed two new PowerPoint guides on how to use Word These guides cover:

* Using Styles in Microsoft Word - Make structuring and editing manuscripts easier
* Toolbars and buttons in Microsoft Word - Create your own toolbars and buttons

To find them, visit my website [http://www.mamud.com/techniques.htm Training materials] and scroll to the bottom of the webpage.

== Paul Neate, 2009/03/19 ==

I agree wholeheartedly with Paul Mundy on this -- using styles makes the editing process so much more efficient and effective, as he has
described.

In contrast to Paul, I have a very extensive collection of styles in my Word template that are based around a detailed analysis of the elements commonly found in technical publications. (This includes itemized lists (bulleted lists) and ordered lists (numbered lists) to get away from Word's apparent random formatting of these elements!) The analysis was used to develop a Document Type Definition that covers our organization's publications needs. This was intended to allow us to go over to a 'media-neutral publishing' set up, i.e. repurposing content for different media without endless cutting and pasting. We have InDesign templates that have styles with the same names as those in the Word template, so when we import the text it is automatically formatted
according to the publication template.

A big problem I have encountered is authors not liking the 'style' of the styles and wanting to change them. I keep trying to explain that the key issue is the name of the style, not what it looks like, but no luck so far!

== Sam Lanfranco, 2009/03/19 ==

Since I kicked off the comments from Paul Mundy and Paul Neate with regard to minimal formatting in the preparatory stages of document development I
think a sentence or two in response are in order here.

I fully agree with what the two Pauls have said about using the style sheets embedded in various word processor templates, but BUT that applies best
when (a) one has relatively firm centralized command of the document construction process, and (b) it is particularly useful when one wants to keep a consistent style based on an institution's projection of a consistent image, or one is producing a certain type of product (manual, novel, evaluation report, etc.).

I would still argue that it is premature when doing the initial brainstorming around a document that is quite ragged in its initial stages, and where there are participants scattered around the globe (or the community), participants who will be dipping in,and opting out, of the document creation process at various stages in its development. Getting everyone to use the same word processor and adhere to the same style sheet makes the ultimate editor's job easier, but makes managing the front end process (like herding cats) much more difficult and off putting.

== Paul Mundy, 2009/03/19 ==

There's an option in Word to restrict the formatting of a document. Never used it myself, but might come in handy for the sort of thing Sam describes.
For details, search for "Restrict formatting" in Word's Help menu. I very much agree with the "herding cats" difficulty. It's sometimes useful to give authors clear instructions about using styles (though some of them will cheerfully ignore the instructions anyway).

== Ephraim Freed, 2009/03/18 ==

Hi folks:

I created a graphic presentation summarizing this conversation - see [http://dgroups.org/file2.axd/1f6dfde3-0460-44f1-a105-adbea4fa51f7/Collaboritive%20writing%20process.ppt Collaboritive writing process.ppt]. I hope I got all the important elements and presented it in a useful way. 

== Ephraim Freed , 2009/03/18 ==

Hi folks:

Just learned I can't send attachments to this list...

Please see my SlideShare graphic presentation summarizing this conversation:

Overview of the [http://www.slideshare.net/EphraimJF/collaborative-writing-process-proper-tools collaborative writing process]

== Lucie Lamoureux , 2009/03/19 ==

Hi Ephraim, all,

Just so you know that the platform has a limit of 10MB on attachments so larger messages will bounce. Using Slideshare was a good call.