Replies to This Discussion

Permalink Reply by Mark Baker on January 8, 2012 at 1:33pm

Sarah,

I've been blogging a fair amount about collaboration lately, so I'll begin by referring to two posts on my blog:

• In How Content Producers Get Collaboration Wrong I argue that content creators make a mistake in assuming that collaboration has to be done by making everything available to everyone. A better way to do collaboration is to use constraints to segment a project so that people do not have to know what is going on outside their own segment of the project. This cuts down the overhead of collaboration and allows people to be more productive.
• In Do Structured Writing and Crowdsourcing Mix? I argue that the best way to get content from the crowd is not with a generic interface, but with highly specific and highly structured interfaces that guide the contributor to provide precisely what is wanted.

With these ideas in mind, let me go through your list of requirements and comment:

• Low barrier to use. People must be able to dip in, make a quick change, add a page, do a quick review, then carry on with their day job. These people may be subject matter experts, support engineers, product managers, CEOs, community authors, even customers. The tool must be easy enough to use, at the high level, for people who only use it once or twice a week and spend their day elsewhere. Of course, the tool must also allow sophisticated things like version control, customisation of look and feel, and all the things that are necessary to make perfect documents. A big ask.

This list of requirement is a perfect illustration of why it is better to segment a project. As you say, it is a "big ask" to make a system with a low barrier to use if everybody using it has to be concerned not only with content but with version control, conflict resolution, and publishing. The way you make a collaborative system easy to use is to isolate each contributors activity from each other. Free form systems are not the way to create a low barrier to use when you have strict publishing requirements. Rather, a forms-based interface that supports contributors while preserving structure so as to ensure consistent publishing.

• A permission scheme that is flexible enough to differentiate between roles (authors, document administrators, community authors, customers) and the things they can do (view, edit, add, delete) to different content types (pages, comments, metadata, and so on).

Certainly you need to be able to differentiate between roles, but the differentiation needs to go much deeper than permissions. Each role should have a separate interface that guides them through what they need to contribute and isolates them from all the details of the system or the activity of other people. (There are few things more maddening than to be able to see something, but not change it.)

• A centralised authoring environment that people can access from all over the world.

A centralized repository, certainly. But there is no need to centralize the authoring environment. In fact a highly distributed and heterogeneous authoring environment may make it easier for diverse contributors to contribute in a way that is most appropriate for them.

• Instant publication, when required, so that everyone can see everyone else's updates.

This assumes that you are using a total-integration model of collaboration where everyone needs to see everything. Your system will be much more efficient if you construct it so that no one feels the need to see anyone else's contributions.

• Change tracking, the ability to compare different versions, and rollback to a given version.

Certainly this is needed by the system managers, but it is a level of complexity you probably do not want to expose to most contributors.

• Author tracking, so that we can see who did what.

Again, for the managers, yes. But if your project is properly segmented none of the contributors should need to know what anyone else did.

• Monitoring of and subscription to updates.

Only needed in a collaboration model where everyone needs to see everything.

• Concurrent updates by two or more authors, with conflict resolution where necessary.

If your project is properly segmented, this should rarely happen.

Most collaborative projects in business and industry use the segmented constraint-based model of collaboration. I plan to blog more soon on how content creators can do the same.

• ▶ Reply

Permalink Reply by Sarah Maddox on January 8, 2012 at 8:02pm

Hallo Mark

Great comment. I've read the blog posts that you linked with great interest too. This is an area of content development and content strategy to watch!

I largely agree with you on many of the bullet points. Here are some points of difference:

• Instant publication, when required. I think that everyone will benefit from the fact that an author can make a change immediately visible to all readers, when necessary, without having to wait for a lengthy publication process.
• Change tracking. It is useful to all to see what changed between different versions of a document. Rollback would of course be limited by permissions.
• Author tracking. This is essential in building community spirit and reader engagement.
• Monitoring of and subscription to updates. Many people need to know when the content of a specific document changes.
• Concurrent updates. The tool should be able to handle this, whether it be via segmentation of content/permissions or by other means.

I'll be very interested to read more about the segmented model of collaboration, and the types of organisation and documentation to which it is suited. Looking forward to your next comment/post.

• ▶ Reply

Permalink Reply by Mark Baker on January 9, 2012 at 2:19pm

Hi Sarah,

Ah, in a lot of these points you are addressing the reader experience and the publishing system. I was not touching on those areas, and in the publishing context, I agree with most of what you say.

In a Wiki context, of course, the authoring interface and the publishing interface are one and the same, so I suppose that if you are talking about wiki-style collaboration, it is very natural to freely mix the two. From a structured authoring perspective, however, it is vital to separate them strictly.

On you points specifically:

• Instant publication, when required. I think that everyone will benefit from the fact that an author can make a change immediately visible to all readers, when necessary, without having to wait for a lengthy publication process.

Agreed. The interesting question here is, what are the sensitivities around instant publication in the organization, and what can you do to address those concerns. The basic choices seem to be either to accept messiness (as Wikipedia does, for example) as the price of wide participation, or to structure each author's contribution to minimize the amount of mess it is possible for them to create. Both models clearly have a place. It is important to remember that both models are possible, since many organizations get hung up on the mess and simply kill instant publication.

• Change tracking. It is useful to all to see what changed between different versions of a document. Rollback would of course be limited by permissions.

It may certainly be useful for a reader to see a change history. I regard this as entirely orthogonal, though, to the issue of whether any particular author or role has the ability to see a change history or to perform a rollback.

• Author tracking. This is essential in building community spirit and reader engagement.

I'm not sure I know what you mean by author tracking or how it contributes to building community spirit or reader engagement. Can you elaborate?

• Monitoring of and subscription to updates. Many people need to know when the content of a specific document changes.

Agree. But this is purely a publishing function. It is not, in itself, a collaboration feature unless you have a system in which authors need to know when other authors have updated something, which is a situation I would work very hard to avoid because of the overhead it introduces into the authoring environment.

• Concurrent updates. The tool should be able to handle this, whether it be via segmentation of content/permissions or by other means.

But this can only occur when two authors have separate and uncoordinated access to the same resource. That is something I would prefer to avoid. I agree with you, though, that if it cannot be avoided, it must be accommodated.

• ▶ Reply

Permalink Reply by Richard S. on January 9, 2012 at 1:11pm

I wonder if the term "collaboration" is too fuzzy to qualify as a use case or as the advertised function of a tool? What do you understand by the term, and what should a tool be able to do to support collaboration?

It's not fuzzy, it's abstract, therefore it isn't a use case itself, it is just a mode of working. It may be an attribute of a use case (you can be working alone, or working with someone else), but it isn't a use case all by itself. 

Think of it this way... I can collaborate with my wife on a ham sandwich. The sandwich doesn't need version control, change tracking, nor access control (thankfully though, the mustard jar ensures thread safety due to it's small size and ability to fit only one knife).  ;-)

A ham sandwich may be an intentionally trivialized example, but it highlights the important point that collaboration isn't something that people do, rather it is how they do something. This is why requirements are all over the map. Even for document collaboration (which is probably what you meant), it might be a mistake to assume that people just want to create a document, they want to communicate something to an audience. Subtle distinction perhaps, but it's why wikis get stretched in all sorts of directions such as charting, media, social apps, etc. It's why you, Mark, and I might disagree on what's important in a document collaboration system. Tools need to be flexible enough to accomodate a variety of different needs and modes of interaction. 

• ▶ Reply

Permalink Reply by Mark Baker on January 9, 2012 at 2:28pm

Richard,

I agree with almost everything you say, but I don't agree that tools should be made flexible enough to accommodate a variety of different modes of interaction. A constraint based model of collaboration depends on hiding as much as possible from each person and offering them a highly restricted view that only encompass their task. This is essential to cutting down collaboration overhead and allowing people to be productive.

Of course, you could argue that a tool could be flexible in allowing an administrator to create as many inflexible interfaces are required for people in different roles, and I would have no argument with that. But usually when flexibility is cited as a product requirement, the result is a lack of strictness and a lack of data hiding. This means that process restrictions end up being enforced by policy rather than by tools, and it generally also means that the tools do not provide sufficient guidance and verification of input to allow authors to contribute confidently without feeling the need to check the output constantly.

A few small, strict, to the point tools is my preference over one big one-size-fits-all tool.

• ▶ Reply

Permalink Reply by Richard S. on January 9, 2012 at 5:17pm

Of course, you could argue that a tool could be flexible in allowing an administrator to create as many inflexible interfaces are required for people in different roles, and I would have no argument with that.

That's pretty much what I meant, and very similar to how we use our collaboration tools here.  

• ▶ Reply

Permalink Reply by Milan Davidović on January 10, 2012 at 1:34pm

Could you offer an example of what does not fit your idea of "working together toward a specific end"? It seems to me that any form of work involving more than one person could fit this definition.

• ▶ Reply

Permalink Reply by Dennis Divine on January 15, 2012 at 9:19am

In technical writing, I see "collaboration" as the workflow cycle for getting a project from concept to finished product. Communication is the fundamental underlying principle, & that requires 2-way interaction with multiple individuals. But this also invites bureacracy to bedevil whatever you're working on.

If I could offer advice to any budding technical writer, it's to try to be as self-sufficient as possible. Yes, you will have to collaborate & others will get to make decisions on your work, for better or worse. You need to rely on your own resourcefulness & intuition though. I think relying on teams is increasingly flawed because of the tendency to filter out things that deviate from the path of least resistance--it's possible to have an independent viewpoint & still be a meaningful contributor.

Along these lines, today's New York Times has an excellent opinion piece on the drawbacks of "groupthink" in today's businesses & society in general:  http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-ne.... Worth a read! Of interest is how electronic brainstorming (via internet) creates a surprisingly happy medium between individualism while negating problems that are routine with the typically poor results associated with office work groups.

• ▶ Reply

Permalink Reply by Mark Baker on January 15, 2012 at 3:59pm

Denis, you describe exactly the kind of approach to collaboration that I describe in my post on How Content Producers Get Collaboration Wrong. Everybody talking to everybody else and nobody finding any time to get actual work done.

But not collaborating is not always an option either. In the old days when we delivered disconnected books, you could get away with it, but not today, when we are building integrated on-line information sets that are constantly being updated. These are too big for any one person to create, and so we must collaborate. The question is how.

Wozniak may have worked alone, but the Apple would not have been possible without chip designers, software developers, and  a host of others. But all of those people who contributed to it did not have to work round a big table in Wozniak's garage constantly gabbing at each other because they built and described interfaces for the components they were working on so that their collaborators could sit alone in their own garages making pieces that complied with the interfaces of the other components. Thus they could work alone, be creative, and still have their bits work together at the end of the day.

Content creators need to learn to work like this too.

• ▶ Reply

Permalink Reply by Dennis Divine on January 15, 2012 at 8:42pm

Mark: You do indeed raise some excellent points, both here & in your piece on collaboration.

I guess my point was that there's a certain mindset in the corporate world that seems to think nothing of value can be accomplished unless it's done in a jammed conference room with an overhead projector--the stuff that Dilbert is made of. I like to think of collaboration as ideally being something you can do with smaller numbers of key players in more informal circumstances.

• ▶ Reply

Permalink Reply by Sarah Maddox on January 15, 2012 at 10:36pm

Hallo Mark and Dennis

Great points from both of you!

Here's further grist to the mill. In a technical documentation workflow, we take a document through the stages of draft, review, approval, publication. (That basic workflow may have some ins and outs, but it's fairly typical to most environments.)

We could talk of collaboration at the draft stage -- many authors contributing to the draft. Typically this would be a small set of known authors. Similarly at the review and approval stages, we have a known set of contributors. Publication is initiated by yet another known party.

In the environments that many of us work in, the life of a document doesn't finish at publication. And the collaborative aspect becomes extended, both in time and in the potential authors. In my environment (wiki-based documentation) people can drop in and update a page at any time, provided they have permission. So yes, it's a known group of people, but it's a much larger group than during the initial document development stage. In my company, that group is around 400 trusted people. The technical writers will review the changes, but only after publication.

Extended collaboration. :) And we need tools that make this both possible and safe.

Cheers, Sarah

• ▶ Reply