Should You Ever Have To Make Up Your Mind?
By Richard L. Hamilton, special to The Content Wrangler
Did you ever have to make up your mind?
Pick up on one and leave the other behind? — The Lovin’ Spoonful
The current situation in the technical communication world reminds me of this great old song from The Lovin’ Spoonful. We’ve got two attractive technologies competing for our attention: social media and structured, intelligent content (PDF).
We were getting all set to start a long-term relationship with structured content, when along came social media and we lost our heads.
We’re attracted to both for good reasons; each addresses a set of significant problems. Structured content and XML are so far unequaled for manipulating, reusing, combining, and publishing content. And social media, especially wikis, satisfies the need for humans to interact effectively and efficiently.
The dilemma is that even though they address distinctly different sets of problems, with little overlap, it is surprisingly difficult to take advantage of both methodologies with a unified set of tools.
The Case for Structured Content
Structured content arguably improves overall productivity, but it does so by focusing almost exclusively on production, not writing. You should be able to write less content overall if you’re really good about reuse (PDF) and re-purposing, and that is a production gain. And, you can gain productivity in your back-end processing through single-sourcing.
However, you are not likely to increase “the amount of useful and unique content created in a given amount of time.” That is, your writing productivity is not likely to increase and may even decrease. This is likely to be the case even if you’re moving from a WYSIWYG environment, and writers no longer need to worry about formatting.
The Case for Social Media
On the other hand, social media, especially wikis, directly address writer productivity. Consider how much easier it is to author content with multiple writers, review and edit content, and bring in collaborators, when you’re using a wiki. And, most wikis are much easier to use than even the best structured XML editors.
However, with the current technology, wikis are not particularly good at structure; in fact, in my experience they are miserable at structure. If you’re lucky, you can export HTML, and if you’re really lucky, you can export XML (I’m working with one right now that looks promising), but I have yet to find a wiki that will handle XML in a native form (NB: There are lots of wikis around, and I would really like to be proven wrong on this point, so please post a reply if you know of a such a beast). That means that with current tools there will be an “export break” between your editing environment and your production environment.
What’s a Writer to do?
At the moment, we are forced to make up our mind and say yes to one and leave the other behind. But, it shouldn’t be that way. Unlike the dating world, there is no inherent reason to force a choice. The two approaches are complementary and could be combined with the right tools. It just hasn’t happened, yet.
There are workarounds. XML Press has been successful at developing publications using an HTML-based wiki with a DocBook XML back-end, but we still have an export break as we move a publication from wiki-based authoring to XML-based processing. And there are encouraging signs with the development of browser-based XML editors like Xopus and DITA Storm, but we still could use a true integration of an XML content management system and a capable XML-aware wiki front end.
About the Author
Richard L. Hamilton is Founder and Publisher of XML Press, which is dedicated to producing high quality, practical publications for technical communicators, managers, and marketers. Richard is the author of Managing Writers: A Real-World Guide to Managing Technical Documentation, and editor of the 2nd edition of Norm Walsh’s DocBook: The Definitive Guide, published in collaboration with O’Reilly Media in 2010.
Similar Posts:
- Wikis For Documentation? Anne Gentle Provides Some Examples
- Using Wikis as Project Documentation Tools
- Creating DITA Content: Who Says You Can’t Use Microsoft Word?
Great article Richard. I love how you described the problem, esp the long term relationship with structure content. The anecdote is so true.
At easyDITA (http://easydita.com) we have been working on a solution to this. A marriage of content management, authoring and review in a completely web based, socially accessible platform. We will soon be showcasing an integration of easyDITA and WordPress to form a live content portal, that’s pure DITA on the backend and social on the front-end.
The goal being to Harness the power of a social wiki/portal, but incorporate governance so it does not grow out of control.
I’d love to pick your brain about it sometime.
Cheers,
Casey
Like you Richard, I want both — in fact, I want it all. I want to eliminate production insanity by using structured text. I want collaboration. And I want a wiki to gather public response to what I write.
And why should these be a contraction? They’re not. Managed collaboration relies on structure.
You hint that the tools aren’t ready yet — but they are. Structured editing and collaborative authoring work together in easyDITA. Author, manage, review and publish in one web-based application. As a service.
It’s being done now. I do it every day.
And soon, a wiki will be just another publishing output of a DITA document set. Wiki responses will end up back in the DITA documents.
As one of our founding developers recently said, “Wikis are a jungle, DITA is a farm.” I want to walk in the woods and harvest the potatoes.
I think is was Oscar Wilde who said that the sign of high intelligence was holding two CONFLICTING ideas in one’s mind… and still being able to function
Ivan
Thanks for the comments on the article. I’m really glad that Casey and John responded to the call for tools. I’ll check out easyDITA, and I’d be glad to talk with you about the topic any time. I like the quote about wikis and DITA, though I hope we don’t have to mow down the jungle to get the benefits of structure:-).
Ivan, I agree with you, especially on the coda; “still being able to function” is the key:-).
Richard
Another recent product that moves the DITA XML source closer to the user is Mekon’s DITAWeb (http://www.mekon.com/index.php/pages/services/DITAweb-Dynamic-Content-Service/systems_integration). For the record, I have to mention my own one-person effort to demonstrate the principles of direct-DITA-on-the-web, expeDITA (which I’m currently rewriting to be based on more RESTful web addressing for API-based access to intelligent content). And I’m an advocate for the drive to integrate native DITA handling in the popular Drupal collaboration platform. Some work at OASIS on a “basic DITA profile” should enable many innovative new solutions to bring structured writing to areas beyond traditional Tech Pubs, where completely different expectations and economies exist. And across my network of connections, that’s not all!
So, I think we could talk about aiming for an ebook-writing sprint using expeDITA in a few months, with native DITA as the only content currency. With a bit of back-end prep, I think we could expect to let users test-drive collaboration cross all of these front ends on the same common content, perhaps by the time of one of next spring’s DITA conferences. Worth a try?
“Watch the skies, everywhere, keep looking! Keep watching the skies!”
Thanks for the mention of DITAweb, Don! Though it’s a service… I’m not a fan of the ‘product’ idea. Results may vary.
Anyhoo – re the original article, I’ve got to take a bit of an issue with the ‘Case for Structure’ part.
Structured content (as we recommend implementing it, and as I think it should be implemented in DITA) should be focussed very much on good, concise and relevant writing. It should be a explicit goal to to increase the amount of useful and unique content being created by focussing authors on creating the *right* content.
Some writers may feel offended by the idea they’re creating the ‘wrong’ content today. I’m not trying to say that. I’m simply saying most teams can be aided by a formal programme of user-centric, minimalist, consistent writing – the kind that’s implied by reuse systems. This gets them moving more quality, less volume.
If certain writers are really offended, maybe they’re actually the golden stars on their teams, writing reuse-ready, easy-to-skim, well marked-up content. But the chances of the entire team sharing a combined style and sensibility – one that can’t be improved upon by the unifying effect of structured processes – is rare indeed.
We’ve had a customer say flat out, “We don’t care about ‘DITA’. It’s just a good way of working”.
When designing systems I favour the approach of “social enablement”. That is addition social features to traditional tech comms. This includes things like bringing “WIKI-like” functions to a controlled and managed CCMS single-sourcing environment. We tend to implement starting from a socially-enabled single-sourcing platform and adding “WIKI-like” features, not starting with WIKIs and working backwards.
—
Noz – http://lessworkmoreflow.blogspot.com // @nozurbina // http://www.mekon.com