Killing XML and IA with social media

Back in October 2013, the IBM editor for my writing team forwarded her enlightening observation about the meteoric rise of mobile media and the potential fall of topic-based authoring. I hadn’t created this blog yet, but I knew that her thoughts might be the seed for an intriguing post someday. Over a month after creating my blog, I still didn’t know how to frame the subject. This is, until now.

With over 20 years of IBM experience, my editor wrote: “Highly technical information that’s delivered on YouTube is widely accepted by technical users… More and more, users will be accessing our products from mobile devices. To learn something new, would you rather watch a YouTube video on your mobile phone or read several topics in an information center?”

TRIRIGAPEDIA: Hosted by the MediaWiki-powered Wikia.com

Hi, my name is Jay, and I’m an IBM TRIRIGA information developer at IBM. After publishing a dozen entries, I realized that my editor’s compact yet powerful observation overlaps my blog posts about dissecting DITA, breathing Oxygen XML, plugging into WordPress, searching Big Blue, and probably a few more. Do they collectively predict the downfall of topic-based XML authoring and topic-based information architecture? Let’s find out.

What is topic-based XML and IA?

In a previous post, I wrote the following:

“If you’re not familiar with DITA-XML topic files or topic-based authoring, then try to think of individual topic files like individual scenes in a movie screenplay. Like movie scenes, topic files are the basic building blocks that can be individually added, edited, deleted, or rearranged to create a different or more-effective experience.”

Consequently, information architecture (IA) is the practice or art of arranging these individual XML topic files into a coherent structure or experience, where the scope can range from a few topics about a specific product feature to hundreds of topics covering an entire product suite. If the output must be delivered with a topic-based hierarchical experience, then organizing its structure becomes very important.

What are the disadvantages of topic-based XML output?

In the context of producing static documents, read-only websites, and other uneditable electronic publications, there’s nothing wrong with XML-based output such as XHTML, PDF, or EPUB format. For example, over the past 4 releases in 2 years, my IBM TRIRIGA information development (ID) team has written hundreds of DITA-XML topics to generate “static” XHTML and PDF documentation in our IBM TRIRIGA information centers.

However, in the context of social and mobile media, you can’t connect to the cloud to “unlock” the published output online and directly edit the XML source from your remote tablet or smartphone. Instead, looking at the client-based XML editors from a previous post — namely Arbortext, Oxygen, and Flare — you can only edit the source XML topics on your source computer and then republish the entire XML project to generate another published version whether you edited a single topic or a hundred topics. Meanwhile, looking at web-based XML editors like FontoXML, they are unique in that they allow you to edit the XML source from your web browser, which implies your mobile browser too, but not to edit the published output.

Sadly, depending on the scope, complexity, and bureaucracy of publishing, translating, and integrating all of the different projects, releases, and languages, new versions of XML-based documentation might be released only once or twice per year, as demonstrated by our IBM TRIRIGA information centers. From this perspective, occasionally “compiled” output might describe this process more accurately than continuously “published” output.

IBM TRIRIGA information center

IBM Knowledge Center

FontoXML: Web-based XML editor (FontoXML.com)

What delivery is replacing topic-based XML output?

You might be asking, “What are you talking about? Why would I want to connect to the cloud to edit my already published output?” If so, then I’d answer, “So you could edit your content at any time or place without being tied to a single computer. Just take a look at the blogs hosted by WordPress.com and the MediaWiki-powered wikis hosted by Wikia.com. Or you can set up your own self-hosted versions from WordPress.org and MediaWiki.org.”

In the context of social and mobile media, you can connect to the cloud to log into your published blog posts or wiki pages and directly edit the source from your computer, tablet, or smartphone. If you need to simply fix a link in a particular page, then you can revise that single page without republishing a hundred other pages in the entire blog or wiki project. By being freed from the constraints of “compiled” project-level or version-level output, you are given much more flexibility as an author, editor, or architect to react to community feedback and revise your “published” output whenever or wherever you choose.

In fact, like many other ID teams, my IBM TRIRIGA ID team has already linked content from our topic-based information centers to our page-based wiki on IBM Connections. We’ve also used our post-based blog on IBM Connections to link our announcements to this same wiki. In a previous post, I also expected that “a few IBM teams might be migrating areas of their social media sites from Connections to WordPress”. So the momentum of our global documentation strategy is clearly moving toward social and mobile media.

Unfortunately, one of the biggest obstacles regarding our product documentation is translation. Like I noted in another previous post, “with over 650 hosted infocenters representing over 2500 products and over 60 million webpages in multiple languages, IBM finally recognized and analyzed the growing concerns of its fragmented information experience”. Consequently, this product-level and language-level fragmentation is also probably the biggest reason why IBM chose to “unify the hundreds of isolated IBM infocenters into a single, integrated, and consistent browser-based experience, the IBM Knowledge Center (KC)” instead of migrating them to a more-immediate social-media experience like IBM Connections, WordPress, or MediaWiki.

IBM Connections

WordPress.com

MediaWiki-powered Wikia.com

What approach is replacing topic-based IA?

Naturally, if we can assume that the topic-based XML compilations are giving way to post-based blog and page-based wiki publications, then the need for topic-based information architecture (IA) loses its significance or existence as well. Instead of delivering a hierarchical experience, blogs present a “linear” time-streamed experience while wikis present a “flatter” encyclopedia-style experience. Interestingly, these “linear” and “flatter” approaches seem to fit smaller-screened mobile-friendly approaches too.

Under this social-media assumption, not only must information architects shift their perspective from organized topics to independent posts and pages, they must also accept the ever-changing links and relationships among these posts and pages by not only authors or editors on their team but also contributors from the larger community. For example, Wikipedia, the free encyclopedia and Wookieepedia, the Star Wars Wiki are probably two of the most well-known MediaWiki-powered wikis. As a Wikipedia contributor since 2004 and a Wookieepedia member since 2009, I’ve accepted the fact that whatever I write or edit can be further edited or deleted at any time by other contributors or administrators if there is a valid reason. Usually, there is.

Wookieepedia: Normal mode

Wookieepedia: Editing mode

Wookieepedia: History mode

Once again, it’s rather unfortunate that IBM didn’t choose to migrate its infocenters to a more-immediate more-social experience like IBM Connections, WordPress, or MediaWiki, where there is a deeper potential for not only community commenting, but also community writing, editing, and architecting. Just as a Wikipedia contributor can add, edit, and reorganize articles, imagine the possibilities of giving registered clients and business partners the power to directly and immediately add, edit, or reorganize wiki-based product documentation from their computers, tablets, or smartphones, instead of asking them to wait for the next published version in 6 or 12 months. By broadening our perspective from “technical documentation” to “social documentation”, maybe the isolated role of information architect is unnecessary after all.

Wikipedia: Normal mode

Wikipedia: Editing mode

Wikipedia: History mode

Of course, based on this dynamic social-media approach, as long as the product documentation is still accurate, the translation or organization of blog posts and wiki pages in other languages won’t be required to match those in English or any other language. Instead, just as each Wikipedia version in Spanish, French, Japanese, and dozens of other languages organizes and presents its articles in its own unique way, imagine this not as a limitation but as another flexibility or freedom given to you as an author, editor, or architect to react to language-specific community feedback and revise your “published” output whenever or wherever you choose.

Wikipedia: Spanish version

Wikipedia: French version

Wikipedia: Japanese version

To personally test this wiki-based approach on actual product documentation, I created TRIRIGAPEDIA as an experimental TRIRIGA wiki hosted by the MediaWiki-powered Wikia.com. Over several days, I inserted the equivalent of approximately 50 XML topics into 5 wiki pages. But what struck me the most was the unexpected effort in shifting my perspective from a constrained topic-based hierarchy to a flatter-yet-freer encyclopedia-style experience. Just as intriguing is the fact that my Wikia.com profile displays the number of edits I made since joining — over 150. I’m not sure how useful this statistic can be, but it also impressively illustrates the immediate and dynamic nature of this wiki-based “social documentation” approach.

TRIRIGAPEDIA: Normal mode

TRIRIGAPEDIA: Editing mode

TRIRIGAPEDIA: History mode

TRIRIGAPEDIA: Mobile viewing and editing

What are my final thoughts?

Let’s go back to my original question: Do my recent blog posts collectively predict the downfall of topic-based XML authoring and topic-based information architecture? Well, if the signs I see at IBM are accurate and the global momentum of product documentation is indeed moving toward social and mobile media, then yes, I must admit that the future of topic-based XML and IA looks bleak.

When IBM chose to migrate and consolidate hundreds of its information centers into a single Knowledge Center, it aimed to address the issues of searchability, unity, and consistency. While searchability might be resolved, I still expect that the Knowledge Center will still face challenges with information unity and consistency among the thousands of its products. Moreover, by experimenting with blog-based and wiki-based approaches, I can more easily see its glaring lack of socio-mobile flexibility and community potential.

The IBM Knowledge Center is a monumental first step, but it’s far from the final step. I’ll go so far as to predict that depending on the rapid evolution of social-media and socio-mobile technology within the next 5-to-10 years, IBM will be forced to migrate its product information once again — to a more-flexible “social documentation” platform. Speaking of killing XML and IA, it’s time for me to play Assassin’s Creed IV: Black Flag! Happy holidays and happy new year! :)

Assassin’s Creed IV: Black Flag

Do I have an update?

Eight months after killing XML and IA, I wondered about killing XML authoring with IBM apples!

Apple + IBM

Two years after killing XML and IA with social media, I delighted users by killing XML robots!

STC Intercom: February 2015

Related articles

• Why developers will never adopt DITA (www.idratherbewriting.com)
• Dissecting DITA relationship tables (jaymanalotoibm.wordpress.com)
• Searching for the center of Big Blue (jaymanalotoibm.wordpress.com)
• Breathing Oxygen XML in Windows 7 (jaymanalotoibm.wordpress.com)
• Killing XML authoring with IBM apples (jaymanalotoibm.wordpress.com)
• Every Page is Page One: Topic-based Writing (www.everypageispageone.com)