Recommendations for team co-authoring process

[jeanettew83275945]

My team consists of two technical writers (and will grow to three soon). We use a shared drive, but cannot have the same FrameMaker document open at the same time, so our current process is:

1. Create 30 or so blank Word documents (one for each new piece of functionality).
2. Divide the Word documents among ourselves.
3. Write the new content in the Word documents.
4. When all the Word documents are complete, one writer copy-pastes the content into the FrameMaker document, applies the paragraph and character tags, and imports screenshots.

I was wondering if other technical writing teams have a more efficient co-authoring process and would be willing to share? Ideally, the process would not involve a second application (Word), or as much pressure on a single writer in step #4.

Thank you in advance for your help!

[Jeff_Coatsworth]

Sounds workable, but a little bit redundant IMHO.

Why not structure your FM docs so that each author just works on the topic that they’ve currently got open. Then the major work would just be when you’re ready to produce some output – make sure all topics are “checked in” and freed up and then build or update the books to which they belong. The only issues I’ve run into is when you need to make a cross-reference to another FM doc that someone else has open. We just coordinated that amongst ourselves to temporarily stop work, release the lock & let the other person open it up for xref-ing.

[jeanettew83275945]

Thanks for your reply. I suppose I wasn't clear in the original description, but we are working on a single FrameMaker document, not a book. We hadn't discussed converting the document into a book because, when complete, the output is only 30-50 pages. Would you recommend using a book rather than a single document?

[Jeff_Coatsworth]

Wow – if you’ve got two (soon to be three) authors working on only 30-50 pages of content, I would suspect that it’s fairly heavy technical stuff! That seems to reinforce my point of busting it up into separate chunks so that simultaneous parallel authoring can be done and only reconstituting it into one block when it’s time to generate output.

[jeanettew83275945]

This document is only one of several we produce (although it seems to take up a disproportionate amount of our time). Thank you for your suggestion - we will look into converting our single document into a book.

[cudspan]

I would definitely recommend using a book.  Divide the content into meaningful topics, and assemble them in the book.  You don't need to think in terms of "chapters" in order to use a book.  Think in terms of topics.

[Lynne A. Price]

A book is certainly one of the first designs I would consider. Remember, though, that every file in a book starts on a new page. If topics may start in the middle of a page, consider text insets instead.

   --Lynne

[cudspan]

Or since you're already "merging" Word docs into a single Maker file, just merge these separate topics into a single Maker file.

Actually, you should use DITA for your topics, and then create a composite document out of all the topics when it's time to publish.  But that's another topic for another day...

[jeanettew83275945]

To clarify, when you say "merge these separate topics into a single Maker file" do you mean (1) implement standard FrameMaker book functionality, (2) copy-paste the content from separate topics/chapters in a single FrameMaker file, or (3) something else?

DITA has come up briefly in our conversations, but neither one of us is terribly familiar with it. Can we use DITA with unstructured FrameMaker, or would we need to convert our document to structured FrameMaker? Would you recommend structured FrameMaker for a small team with (relatively) small documents?

[Arnis_Gubins]

The merging that is being mentioned refers to importing the content into FrameMaker, never copy & paste [way too much work and sometimes there's hidden cruft moved on to the clipboard that doesn't always agree with FM].

If the Word content is tagged systematically by the various authors and you have the corresponding style names defined in a FrameMaker template, then importing is a fast, seamless operation - especially with FM2015, where you can now save Word style mappings for re-use.

DITA is for a structured authoring environment only. When properly set up, it can work very well for a small team and you could use the FrameMaker  XML Authoring tool for most of the content creation (and not need multiple, full FM licenses). However, trying to do the initial set-up for this type of workflow without experienced help could create a very negative impression of the capabilities of DITA; for some it would seem like getting a great deal on a car - but as sold by IKEA. Better to go the "dealership" route and get it ready to drive [unless you really enjoy the assembling/customizing to your requirements].

Structure can work very well for small teams, as it imposes rules and controls over the content relationships that must be followed. You can also work in a structured manner with unstructured FM - as long as everyone is on board and follows the rules. Structured FrameMaker pretty much ensures that everyone will have to follow the rules. There's still a lot more to structured FM - whose going to define the document architecture/structure, what sort of rules are required, etc. ? It's not something that you can always immediately define and impose on a team - as with DITA, experienced help makes the transition easier and helps you avoid many pain points.

Either way, it's a long-term commitment with initial costs.

[jeanettew83275945]

Thanks for your reply. I didn't realize we could directly import Word documents into FrameMaker which, I agree, is much better than copy-pasting. I also appreciate the warning about DITA set-up. We'll cross that bridge if/when we get to it!

[drbotkin]

Let me continue this interesting discussion

I have two Technical Writers in the team. We use unstructured FM 2015 documents (no Word). We would like to work on several chapters (separate files) within a book simultaneously. We use SVN to synchronise our work.
When it comes to chapters - everying goes well. However, every time we update a book, the collision appears.

Will anybody assist please?

Thank you in advance

[Jeff_Coatsworth]

You just need to coordinate with the other writer that you've got the content checked out & that you will do the update; when it's done, check it all in again and continue working.

[TomSchenck]

I'm also adding writers to the team through acquisitions. We also work in unstructured Frame and are now sharing a few "common" files. We are now spread out around the world.

Does anyone have any suggestions for a file management/control system?

Eventually we would like to all work together on a single book at the same time.