http://lavacon.org/sessions/seven-steps-to-dita-adoption-across-the-enterprise

If you are in Austin and can’t swing attending the whole conference, there is a special  workshop-only registration page.

Session description:

Long before “user generated content” became a buzzword, tech pubs strategists knew they needed subject matter experts to be more engaged in the documentation process. Attempts to capture SME knowledge have varied from Word to Wikis, but they have all resulted in technical writers struggling with unstructured content that lacks the intelligence needed to make the process work.

DITA solves this problem by design—with an architecture well-suited for enterprise implementation, enabling content to flow smoothly from SMEs directly to tech pubs. And this is just the beginning. DITA is unique in its ability to enable content to be created collaboratively by departments that exist as silos today, for example Marketing, Engineering, and Tech Pubs.

This workshop is designed as a step-by-step guide, using a Pilot Project as both an example and as a roadmap for attendees who are ready to get started. We will examine seven practical steps that run the gamut of analysis and planning, available tools and techniques, project approaches, and organizational buy-in. The material is equally relevant to all types of wide-spread DITA authoring, whether it be to collect content from SMEs or to create intelligent content in other departments.

Workshop participants will learn how to:

1. Assess pain points and DITA’s fit
2. Build a business case
3. Gain organizational buy-in
4. Understand the tools and techniques
5. Design a “failure proof” pilot
6. Implement and manage the effort
7. Effectively report the pilot results

Who should attend:

• Content Strategists who want to capture intelligent content
• Documentation managers who need to optimize business processes
• Technical writers and editors who contribute to content strategy

http://opendita.drupalgardens.com/

open DITA Code Sprint

Following the DITA Europe conference in Prague, we are planning an open DITA code sprint. This is an event you should not miss if you are interested in getting some hands-on experience working with open source tools for DITA. Anybody is free to suggest topics but we’ll most likely have at least a few people working on Drupal tools for DITA and on the Open Toolkit.

If you are around after the conference but had not planned to take one of the post-conference workshops, this event might be worth your time.  If you are interested, please visit this site and sign up! I hope someone might find this alternative post-conference opportunity useful.

Creating documentation using wikis or wiki-like software is inherently all about collaboration between various parties: programmers, testers, technical writers, and even informed users.  More than any other form of cloud-based collaboration, wikis are a natural way to enable your extended “team” to collect and organize their respective contributions to the knowledge already documented. This would be an ideal picture, except that users are typically not under your management or your company’s IP agreements; they have their own goals, and they tend to go after loose ends in the documentation in their own way. A strategy of “good fences make good neighbors” can help keep user-contributors engaged in your goals for improving the knowledge in your wiki-based documentation.

The legal approvers in your organization are probably most nervous about how to maintain a clear distinction between “warranteed” or standards-based information (that which has been through a formal approval process for intellectual property clearance and technical accuracy that the company will stand behind) and “user-generated” information (for which the IP rights may be unclear, or for which the information has not been approved by the programmers as technically sound or recommended).

One approach is to show both forms of information on a wiki page that clearly defines the authority of each set of content. Comment facilities are the obvious mechanism for getting and presenting the user contributions. Implementations can range from very simple, unmoderated posts to highly interactive discussions with product moderators involved in helping to guide towards best practices. Ideally, the implementation would have a way to encourage and recognize top contributors and to float the community-approved solutions into higher visibility, either by ratings or by active curation of the discussion into gems of knowledge.

A good example of this separation of standards-conforming content from user-generated content can be seen in the PHP programming language documentation. Although PHP is not a commercial product, its documentation interfaces are neatly differentiated–a model, in fact, for many commercial products! This function description is just one example:  http://php.net/manual/en/function.fopen.php . Note that the user-contributed notes are clearly separated from the approved content, which itself conforms closely to a standard template for the formal properties and interfaces of each language construct. Those parts don’t change except by an apparent internal and formal update process, whereas the users often challenge each other and offer alternative use case examples for other users experiencing similar issues.

In a quick look at other approaches, I see that the Perl Programming Documentation community (http://perldoc.perl.org/) seems to embrace direct user contribution with peer review, whereas the Ubuntu Documentation Team (https://wiki.ubuntu.com/DocumentationTeam) has a more central writing team but engages users extensively in forums. In both cases, a foundation or other formal governance structure represents “where the buck stops” on approving content that comes from user/contributors. The Mozilla and Eclipse foundations are also examples in kind. [And here I wonder, Have there been any studies of governance models for various software documentation efforts? It would be fascinating to see at a glance how the various compliance requirements of each such group affect the policies on how user contributions are handled.]

Coming back to the PHP example (which I like quite a bit, obviously), it is immaterial whether the authoring tool used by the tasked writers behind the public interfaces was a wiki or a traditional XML-based source and production system. User contributors interact only through a comment form provided for them, maintaining the separation of their contributions from the main reference material. The system is responsive, easily searched, and hugely popular among that community. Thinking about this model, I suppose that valued contributors who are not primarily tech writers could be allowed to interact directly in the source authoring application. One could acknowledge their authority and trustedness by granting them authenticated access to the governed content (probably requiring signed agreements as well). But other than the fully open Wikipedia system, I can’t find any example of products with warranteed information that permit direct user interaction with content.

So for content does not require legal/formal approvals for release, an open access wiki model like Wikipedia’s may fit your needs well enough, given enough eyes on the content to keep it trustworthy. But a well-implemented comment mechanism can  still make your customers feel connected and valued while keeping provenance in the content that you’ve put effort into reviewing, validating, and approving. If you can maintain a good separation between this approved content from whatever users may contribute, then the choice of how your trusted/extended team creates the governed content is more a matter of business strategy (for example, using XML standards like Docbook or DITA for content lifecycle management and for multiple outputs) and of company culture (providing wikis for programmers who utilize Open Source tools or Agile methodologies).

And there is no fundamental reason why a wiki-like interface can’t host XML-based content, for that matter. But that is another story…

Related readings:

1. I hate “content”, http://www.janetswisher.com/?itemid=227
2. DITA and wiki hybrids: they’re here, http://justwriteclick.com/2008/02/27/dita-and-wiki-hybrids-theyre-here/
3. Creating DITA content with a blog or wiki, http://learningbywrote.com/blog/2011/04/creating-dita-topics-with-a-blog-or-wiki/
4. What do you think about using a wiki for technical documentation? http://technicalwritingworld.com/forum/topics/what-do-you-think-about-using
5. Building Exceptional Product Help Communities, http://www.slideshare.net/mindtouch/building-exceptional-product-help-communities
6. and of course, Alan Porter’s book, WIKI: Grow Your Own for Fun and Profit

Markup features

Simplified doctype: The former XML-informed rigor for the XHTML doctypes is strongly eschewed in the HTML5 ruling class.  They felt that the burdens of invoking validation and requiring browsers to stop working on invalid content were frankly draconian (and from an end-user’s perspective, I agree). Users should not have to bear the error messages normally meant for developers. So the two-pronged approach now is to define how parsers should deal with invalid content (the subject of one of my previous blogs) and to relax the doctype so that standard XML-based validation is not invoked, yet with enough structure to still turn on standards mode in the browser. So for now, the doctype in HTML5 is just <!DOCTYPE html>. If authoring HTML5 directly, you should still perform XML validation on your saved content (an XML DTD exists, although disdained by the ruling class), and, if generating HTML5 as output from DITA or other XML source, I believe that you should still use XML-compliant markup traits in your output transforms to HTML5 (closed singleton tags like <br/>, and proper nesting). It hurts nothing, and makes your generated content more consumeable by XSLT-aware web services.

Simplified attribute markup (no quotes required): This is a concession to content writers who use flat editors and create tag soup unthinkingly. If you are following the previous recommendation to generate standards-compliant XHTML conventions, you will be creating quoted attribute value declarations, so this non-progressive markup relaxation should not apply to you, and your standards-compliant markup certainly won’t harm any end-users or content consuming services.

Enhancements to forms: Several features relate to providing handy new features for forms, such as native syntax checking for email addresses, providing placeholder text behaviors within input fields, sliders for representing progress or ratings (3 out of 5, for example), and denoting required fields with browser-based checking (reducing the reliance on JavaScript for such input validation). These features should appeal to HTML5 app developers, but it’s not clear to me that DITA today has any direct representation for such markup (unless through a forms specialization, which is not out of the picture).

Inherent support for video and audio inclusions with brower-generated controls: For developers, this simplifies some of the former need to encode all such multimedia references using the <object> element. For DITA authors, nothing changes on the authoring side, but the transforms may now produce the simpler <video> markup with must less accompanying code for managing the UI aspects of that content. All current browsers support this markup, which puts pressure on IT organizations to urge their users to get with the latest browser versions.

Interactive content markup: <mark> (for applications to insert highlighting for search terms in context, for example), a “data-” prepend value for recognized user-declared attributes (use data-outputclass=”myspecialvalue” when preserving aspects of DITA meta-information in your HTML output, for example), <output> (sort of an Eval() placeholder for JavaScript dynamic result values such as timestamps), and more. Insofar as the spec is still under design and active beta, features may come or go, so this list may vary. Again, I see these as more for app development, but could be represented by appropriate DITA specializations at some point.

Depending on how you categorize markup, some of these could be viewed as semantic inline elements. I’ve chosen to call them “interactive content” markup because they tend to cause behaviors on the page vs actually representing the semantics of the content (other than a new <time> element whose behaviors are still being worked out).

Interoperability with other standards and web features

While interoperability with web standards is generally expected of browsers, Web developers have had to encode browser-specific overrides for including SVG or MathML snippets, for example. HTML5 does not specify interoperability practices, but the rollout is expecting all players in Web standards and services to play nicely together. Among the kinds of best practices that you’ll see emerging within the HTML5 ecosystem, watch for emphasis on:

• SVG and MathML, some XML content fragments that are commonly embedded in HTML pages
• CSS3, which enables many of the expected presentational aspects of what is considered to be “Web 2.0-ish”features–rounded corners for boxes, for example.
• CSS3 is even providing some AJAX-like behaviors for dynamic content, enabling lighter solutions, even some degree of game-like behaviors using canvas and other graphic properties.
• Geolocation capabilities should certainly be available within HTML5-class browsers. This is not an HTML5 capability, per se, but with HTML5, you can certainly build location-aware behaviors.
• Local caching is also mentioned as if it were an HTML5 feature, although it is actually more of a browser feature that happens to make better use of what are now accepted web development techniques for making best use of bandwidth.

One of the most exciting capabilities that we’ll see emerging as a result of this increased interoperability of standards and services will be for creating interactive content on small-form-factor and touch-operated devices such as mobile phones and tablets.

Support for mobile form factors

HTML5 for mobile content may revolutionize pushing DITA content more easily to mobile devices. Most of the interoperability capabilities will apply directly to how you generate DITA content for use on mobile devices (geolocation, caching, UI features, and more).

HTML5 for mobile web content is basically the focus on generating DITA content into a form that provides more agreeable user experience, both in formatting for a small screen and for how links and controls, tables, and other problematic content are used in that context.

HTML5 for mobile apps on the other hand is more of a Web developer focus on creating mobile interfaces to major web sites (or for locally cached data for offline use) that are expected to revolutionize the cottage industry of app development. I’m speaking beyond my experience here, but I understand that instead of installing (and continually updating) an app to interface to my favorite world news site, a mobile web site will be able to provide the same behavior through the browser.

Impact to the DITA Open Toolkit

Here are some things that can be done now by developers who are interested in extending the DITA Open Toolkit’s capabilities with HTML5:

1. It is time to move on from the frame-based navigation shell provided in DITA-OT. Rather, include your individual result pages in the content pane of an HTML5-based structural shell, using the <header>, <footer>, <article>, <nav>, <aside> and other structural block elements per emerging best practice.
2. Devise alternate shells that specifically address best practices for mobile devices (cell phone and tablet buttons and layouts, for example)
3. Combine these HTML5 shells (the overall structure of your web site or content-rendering environment) with the appropriate use of CSS3 for layout control and to replace former box and image hacks for rounded corners, shading, offsets, etc..
4. Prefer the use of PNG for your graphics formats. JPEG and GIF formats are reliable, but have their quirks. PNG images are generally light, offering the best compromise of pixel accuracy vs compression artifacts of both other formats, and brands your site as using progressive standards.
5. Help write HTML5-specific overrides and documentation for best-practice use of the <object> element to represent HTML5′s video and audio function.
6. Provide support for inserting user-generated attributes (prefixed with “data-”) for outputclass and other DITA-specific metadata values we might push into the generated HTML.
7. HTML5′s structural markup works wonderfully well with CSS3 for creating various layouts for delivering transformed DITA content in exciting new ways. I’m looking forward to discussing some work I’ve done and to seeing the work of others in this area. DITA’s plain-Jane days are nearly past–HTML5 and CSS3 are about to put lipstick on this pig!
8. We can start with structure–that part of the design work seems well-cooked for now–, but add other element behaviors only if they seem ready and have customary usage in the wild. Some demo sites are very slow for browsers that lack fully optimized behaviors for advanced HTML5 features. If a particular HTML5 or CSS3 feature appeals just because it looks nifty, weigh its value against its impact to the user’s experience. This goes for anyone creating direct HTML5 content as well as for Web content generated from XML source formats like DocBook or DITA.

Summary

I am certain that I’ll need to revisit this discussion in a year to see if I still assess things the same way. But it is clear to me that browsers already make use of a great deal of these capabilities that beg to be put into use as appropriate!

Note that since HTML5 is intended to become Business As Usual on the Web, the “5″ part of the name will eventually go away, and we’ll be talking about these as “latest HTML” features.

Already by popular request, it looks like I’ll be posting a follow-up demonstrating the use of multi-column layouts based on the HTML5 structural elements. Stay tuned!

Related topics:

1. A Preview of HTML5, http://www.alistapart.com/articles/previewofhtml5
2. How HTML5 Will Revolutionize the Web,  http://www.technewsdaily.com/how-html5-will-revolutionize-the-web-100202-0154/
3. HTML5 is Here Now: HTML5 Benefits for Users and Developers,  http://janderson99.hubpages.com/hub/HTML5-is-Here-Now-HTML5-Benefits-for-Users-and-Developers
4. The Benefits of HTML5,  http://www.g2k.igot2know.com/the-benefits-of-html5
5. HTML5-Opportunities for Mobile Devices,  http://www.learningsolutionsmag.com/articles/681/html5–opportunities-for-mobile-devices/page2
6. Mobile development with HTML5,  http://www.engineyard.com/blog/2011/mobile-development-with-html5/ (some recommended tips for HTML transforms that exploit HTML5 features intended to improve mobile performance and interaction)
7. Present State of HTML5 in Mobile App Development,  http://martinkou.blogspot.com/2011/06/present-state-of-html5-in-mobile-app.html

Applying HTML5 (related to DITA transforms):

1. Dive Into HTML5,  http://diveintohtml5.org/
2. HTML5 Doctors,  http://html5doctor.com/article-archive/
3. A Basic HTML5 Template,  http://www.sitepoint.com/a-basic-html5-template/
4. Real World HTML5 and CSS3 in Internet Explorer 9,  http://www.sitepoint.com/real-world-html5-and-css3-in-internet-explorer-9/

The “secret ingredient” in the HTML5 specification is not even any new markup. Rather, it is a chapter devoted to defining a standard way for all conforming browsers to approach the resolution of various “tag soup” parsing issues (as in English grammar, “parsing” is simply the picking apart of the parts of text–separating the markup from the readable content before handing the pieces off for rendering). In short, if you hand the same malformed document to each vendor’s conforming HTML5 browser, the parsed view of that document will be identical in each browser. This parsing algorithm is described in the HTML5 specification, http://dev.w3.org/html5/spec/parsing.html (“Parsing HTML documents).

This applies to DITA in several key ways:

• Because weird tag soup structures are decomposed more consistently, the resulting view of the document is more like Well Formed XML. This algorithm effectively does much the same cleanup as the handy TIDY tool at Sourceforge (http://tidy.sourceforge.net/). In theory, you could now apply an XSLT stylesheet to this internal model and get more consistent migration from this formerly toxic mish-mash into a handy structure like DITA.
• For in-browser editors, this inherent cleanup can simplify the usual HTML cleanup steps for content being written back out to the saved format. I have not tested exactly how the parsing algorithm affects content that is rendered and then saved out from contentEditable contexts, but it bears looking at by in-browser editors that could reasonably require HTML5-compliant browsers as their hosts. Most users who have upgrade options selected for their browsers are already getting this capability since it is now in all major browsers, so it is worth putting into a feature road map.
• The algorithm is described so that it can be implemented in standalone tools as well as by the parsers integrated into browsers. I expect that we will soon see “HTML5 well-formed mode” as a parsing option in popular XML parsers. In short, rather than sending an HTML document through the initial TIDY step to coax it into a well-formed state, the parser can take that input directly and do much the same, bypassing an admittedly klunky part of a normal HTML conversion pipeline.

These outcomes may seem theoretical and might not tangibly benefit DITA writers or content owners right away. But I expect that the effect of this normalizing behavior on the world’s HTML content will create more efficiencies in the tools that normally handle HTML flows in and out of our DITA writing and production services. At the very least, wouldn’t it be nice if the task of converting “HTML tag soup” to “delectable DITA topic” were at the kitchen recipe level instead of the Iron Chef challenge it is today?

I’ve seen several Javascript utilities that attempted to represent HTML headings in the browser as presumed ToCs, but the tools cannot distinguish between the use of headings for figures vs headings for hierarchy. With no standard in the language for separating the presentational usage of headings from the structural usage, each implementation was different.

The designers of HTML5 recognized the need for consistent representation of structural hierarchy in HTML by introducing 1) some very DITA-like markup (<section> and <article> in particular), 2) a wrapper for intentional presentational usage (<hgroup>), 3) and, like its GML inspiration, a formal ability for the browser to infer a Table of Contents from the indicated structural markup. This outlining algorithm is described in the HTML5 specification, http://dev.w3.org/html5/spec/sections.html#headings-and-sections (Headings and sections).

This so-called “HTML5 outlining algorithm” encourages markup usage that an HTML5-conforming browser can represent in a formal ToC right on the web page:

<article>
 <body>
  <h1>Apples</h1>
  <p>Apples are fruit.</p>
  <section>
   <h1>Taste</h1>
   <p>They taste lovely.</p>
   <section>
    <h1>Sweet</h1>
    <p>Red apples are sweeter than green ones.</p>
   </section>
  </section>
  <section>
   <h1>Color</h1>
   <p>Apples come in various colors.</p>
  </section>
 </body>
</article>

In a sidebar, this might appear as:

Apples
  Taste
    Sweet
  Color

Other than element names and sequence differences (easily handled by basic XSL-T techniques), this structure now  maps quite cleanly to structures in a composite DITA topic:

<topic>
 <title>Apples</title>
 <body>
  <p>Apples are fruit.</p>
 </body>
 <topic>
  <title>Taste</title>
  <body>
   <p>They taste lovely.</p>
  </body>
  <topic>
   <title>Sweet</title>
   <body>
   <p>Red apples are sweeter than green ones.</p>
    </body>
   </topic>
  </topic>
  <topic>
   <h1>Color</h1>
   <body>
    <p>Apples come in various colors.</p>
   </body>
   </topic>
  </topic>
 </topic>

Another common HTML pattern of use is for various heading combinations to represent formal titles with “kicker” subheadings (as in <h1>Blog title</h1><h4>Tagline</h4>). A kicker is not a formal part of the hierarcy, but it can be kept out of the structural outline by placing both elements within an <hgroup> container. The outlining algorithm now selects only the higher-level heading as the structural heading, and ignores the subheading as a misleading indicator of hierarchy:

<hgroup>
 <h1>Blog title</h1> <--structural in this context
 <h4>Tagline</h4>  <--presentational in this context
</hgroup>

These capabilities are exciting to see, but I expect it will take some time for the larger world of HTML content creators to reliably embrace these outlining conventions. I foresee these implications:

1. Migration tools for HTML-to-DITA can now mimic the same outlining algorithm in order to infer a DOM that is structured in the way the browser sees it. From there, the migration tool may apply more appropriate final output restructuring, but at least there is no guessing about the basic input model–it will be a reliable starting place across browsers. All migration tools should try to provide “HTML5 outlining” as one of the available modes for disambiguating the apparent structure in original HTML content.
2. Schema-driven writing tools for HTML authors cannot directly enforce these structures at the point where they might be desired, as these containers are optional in the HTML5 content model. Tools will need to offer explicit assists to help writers create a properly nested structure for outlining. Of course, DITA authors get this structuring guidance by default since nesting is such a strong design pattern in DITA’s topic orientation. The ability of DITA editors, even the “baby DITA editors,” to guide in creating properly nested structure is a marketable benefit for using DITA tools for creating structured web content.

Can web content strategists expect brighter days ahead for well-structured content that can be reused somewhat more interoperably with their DITA counterparts? Could the HTML world recognize the value of creating such structures initially in DITA editors? Could DITA take over the world? I have no crystal ball clues for any of these, but I expect at least “an improvement in diplomatic relationships” between these two formerly estranged markup relatives.

If you are coming to HTML5 from an unstructured content background, the talk about “semantic tags” can be confusing. For example, whether to use <aside> within or outside of the <article> depends on the semantic relationship of the marginalized content to the article or to the site itself. In a poorly information-typed language like HTML, these distinctions are indeed not very clear to most people.

Users of DITA, however, probably see some clear associations of these HTML5 elements with structures in both DITA topics and DITA maps. Topics, in DITA parlance, are directly equivalent to the content of the HTML5 <article> element, and maps are pretty clearly equivalent to the content in a <nav> element. But I was delighted to understand that there is a greater type of synergy as well between HTML5 and DITA: that topics and maps each have an almost-by-design relationship with the recommended layout of a web page based on HTML5 principles.

Most web page content, even that generated by the DITA Open Toolkit, is expected to be viewed in the context of some larger environment that provides affordances like navigation, site terms and conditions, “About” and “Help” pages, and more. The key thing about HTML5, as I see it, is that it formalizes the organization of these disparate types of content into the cohesive end-user view. Earlier versions of HTML could do that as well, but only by using <div> and <span> elements with a good deal of CSS to effect the visual arrangement of the parts, or by the more discouraged techniques of layouts based on <frameset> or <table> markup. The “semantics” of HTML5 now enable each of these page artifacts to be arranged within markup that better clarifies the intent of the content in each location, whether it be a set of navigation links or a list of categories off to the side. Most particularly, the oft-presumed header and footer regions of a displayed page now have formal markup identifying those respective chunks of content. The full set of new structural elements in HTML5 are: header, footer, section, aside, nav, and article.

---

“HTML5 authoring communities now have a reason to care about structure…”

---

And this plays well for DITA output rendering because these page layout regions correspond to overall DITA structures, both those implied by nested topics and by aggregated maps. Moreover, an emerging HTML5 feature called the “Document Outlining Algorithm” now enables browsers to infer map-like structure from HTML that has been properly constructed using fully nested sections with titles. Voila! Now the top-down processing normally generated for DITA content has a convergent browser capability that pushes HTML5 content creators to honor good principles of topic orientation and chunking. In other words, HTML5 authoring communities now have a reason to care about structure, and this portends greater future interoperability for tools like structured editors that can insert the best-practice wrappers for conforming HTML5 content.

HTML writers new to the idea are often confused about the role of these new structuring elements. HTML5 authors must make a conscious decision about how to designate various parts of the content as articles, sections, asides, or navs. Meanwhile, DITA authoring provides the proper structures (the design patterns missing in HTML) by default because XML editors auto-generate all wrapper markup needed for nested content in DITA. So basically, any “Simple DITA” authoring tool automatically becomes a boon for someone who needs to create semantically well-structured HTML5 because DITA provides the validated structure that maps directly to the HTML5 structures that for now can be enforced only by adhering to guidelines.

I’m not saying that the semantic names added to HTML5 have the same meaning as similar terms in DITA. <article> and <section> may have decidedly different meanings, and a topic can be either an article or an aside depending on context. How are you to know? It depends on your high-level information architecture and how it maps to the user’s view of the finished product, to some extent. I prefer to think of the HTML5 structural elements as a form of page-ordering language like XSL-FO rather than as author-guiding structures as enforced by DITA’s schemas. In this sense, it is now possible to organize and play back any DITA-based web page for better quality to other outputs such as ebooks and PDFs by viewing these HTML5 elements as formatting objects in their own right, upon which you can now differentiate your ultimate rendering, whether it be in a browser or to a CSS3-styled PDF page.

In this world of potentially good possible outcomes, I foresee:

1. Replacement of the tri-pane layouts of DITA Open Toolkit by style-based layouts that internalize the layout into the display context. In other words, simpler site maintenance.
2. More use of DITA as direct-to-browser based content, particularly when either the map or the outer topic of a composite topic is used to organize the user’s view of that content architecture.
3. The increased use of CSS3 printing stylesheets and corresponding transforms enabling HTML5-based output to print beautifully and without the transform headaches usually associated with XSL-FO based PDF generation.
4. New DITA specializations that exploit these capabilities. Eliot Kimber, for example, has started looking into HTML5 output from his DITA for Publishers specialization–I can see this as a basically new toolkit specifically for commercial publishing workflows for all types of original DITA content. Another exciting use would be a composite/aggregated DITA structure that plays well into the more general case of business oriented documents–creating single-file whitepapers in a Word-like SOHO or SMB environment, for example.
5. Perhaps the increased recognition of the power of DITA’s organizational design patterns by the HTML5 working group, with some future intersections becoming possible in time for DITA 2.0 to accomodate them.
6. Enabling more consistent inclusion of videos, images, and other non-text content as titled exhibits within an HTML page. I’ve seen this as one of the most frustrating things for writers to maintain in the absence of guidance from the editing tools.
7. And most exciting from my viewpoint, potentially seeing the vision of DITA being used by web content authors because of the guidance it provides for the structures they need to generate for their published HTML5 blogs and site pages. I’m still pushing for the basic free DITA editor that can lead Web authors into this structural Nirvana, but I’m very hopeful for the future of the commercial tools that are already at hand for these future consumers.

I’d like to hear your thoughts on how DITA relates to HTML5 and how both can be exploited for mutual benefit!

Related topics:

• HTML 5 and CSS 3: The Techniques You’ll Soon Be Using
• Aside Revisited
• Designing a blog with html5
• Coding a layout in HTML5 and CSS3
• HTML5 Guidelines for Web Developers: Structure and Semantics for Documents

The standard recipe for a mashup is to find several songs with common beats and harmonies and blend them into an overlapping whole, while the goal of crossover is to take a song in one genre and play it using another genre’s stylistic norms or key signatures. Walter Murphey’s “A Fifth of Beethoven” is a classic example of crossover, as is “Lover’s Concerto” (“How gentle is the rain…”) based on a Bach minuet. Relating these two different musical editing approaches to documentation might take a stretch, but let’s try.

One of the premises of topic-oriented information is that various topics might be assembled like a conventional mashup, informed by some logic of order and nesting that puts the information architect in the role of the mashup master. These are the map/topic collections with which DITA users are familiar. The crossover approach is more like applying a different stylesheet or even different branding to a set of content (which might itself be a new aggregation/mashup). This is common for OEM-rebranded DITA information or for internal infocenters that need a common, corporate look and feel.

In the document world, crossover (style) and mashup (reorganization) techniques have been the tools for writers and information architects for updating content and creating new product versions. Increasingly, content aggregation tools are being provided for product users to customize and manage their own views of product docs, at least for some major installed products.

The next big turn of events will come when DITA content can be made more globally accessible on the Web–open source content for open use, as it were. With the right open source tools in the hands of users, any open DITA content could be managed into new forms just as easily.

One recent scenario for this kind of collaboration came with the release of the Google+ social service. As is all too common for new agile releases, the Google+ rollout came with very little documentation, and users quickly organized to create cheat sheets, fan sites, blogs, videos, and other scattered versions of helps for new users. Imagine how reliable and consistent that content might be if contributors could collaborate on a common version in an open repository and users could access open aggregation tools to build their own custom versions of the parts they needed?

In general, mashups or crossover performances are easy if you have tools that meet you halfway with knowledge you need to complete the task. What would that ideal documentation tool for creating blended content styles and streams look like?  I am fairly certain that DITA will be part of that picture!

The argument is essentially this: the document-oriented Web, accessed by search, is ceding ever more user time to the social network Web, which is comprised of personal commentary, relationships, memes, and ratings. Content publishers who want their products to remain relevant need to pay attention to making their content increasingly discoverable within the social network mechanisms. In short, “Likes” are now competing with “Links” as the primary reason why someone might visit one of your content pages.

How would you really put any of this talk into practice?

1. The analytics for SEO trend (how you increase search rankings for static content) is maturing towards analytics that augment business intelligence (how you improve your awareness of market trends and business opportunities–see “Data is the new platform, and social is the intelligence“). While you might still use analytics to drive search traffic to your site, you should also be using analytics to refine your actual product design and your strategy for raising brand awareness and reputation on social networks. Your brand’s importance in the social network is becoming your most valuable Web asset–it’s about ratings over rankings!
2. People are now competing with documents in the way the Web is being used. So if you want to make your site or even individual topics more visible, figure out how to “friend” or “follow” them and get “likes” for them (see “Can Documents Become More Social?“). Facebook has already been enabling this for business or interest pages on its ecosystem; news networks and other content publishers are now using that API to enable “liking” stories on their sites, thereby creating lists of friend-recommended articles on their home pages.
   Taking the idea further, in traditional online reviews for product documents, the review workflow management system typically pushes out schedule-driven news about progress through the review cycle. Now imagine the “follow” equivalent, where a social network capability uses tweets as the messaging system to keep you (and others on the interest list) abreast of all new activity with the document, including a better sense of how the approval ranking of the content is going (even the prospect of early signoff if the cognizant approvers are already in agreement). It’s a heady thought, but this is about innovating to make better use of social networking trends.
3. As this title indicated, “Likes” are the New Order’s equivalent of “Links” in the Web. Whereas you might bookmark an article that YOU want to get back to, you “like” an article that you want OTHERS to get to. By so doing, you are raising the ranking of the article, not necessarily on the searchable Web, but on the social Web, where your friends or customers are apparently spending more time.

You might think of your DITA-based content on the Web as being used in these ways, then:

• Searched, for someone engaged in a specific task, to get quickly to specific procedural, conceptual, or reference endpoints (usually the output of DITA Open Toolkit). They might bookmark this content if it is worth getting back to apart from using the search intermediary again.
• Read, for someone engaged in the content, whether out of interest, to gain knowledge, or even just reading a novel (DITA for Publishers fits this role). I think of this as being typically “rated” by readers.
• Socialized, for someone engaged with news or trends relating to the content (the domain of some of the emerging collaborative DITA tools). Content is typically tagged as notable by a “Like” button.

Given the well-documented growth of social networks and how they impact the use of content on the Web, how are you preparing for the change? Is your DITA content still only Linked, or can it be Liked?

Having watched DITA’s growth from the beginning, I’ve never believed that DITA was just for Tech Pubs, although that scenario certainly informed on DITA’s design. But given the current maturity and power of DITA editing tools for Tech Pubs (or Information Development–ID), I feel that now we can move DITA beyond the fringes of that community, where as a web-oriented standard, there are whole new markets for DITA’s use.

For full-on technical writing, the standard, best-of-class DITA editors are absolutely what is needed. Those are the only tools for that level of job. It’s just that the technical writing job requires more than average knowledge of XML, DITA elements, conditionality strategies, content reuse goals, build and publishing skills, and the procedural know-how to help steer effectively through the full life-cycle tasks that define the job, and these tools typically integrate your access to all those job functions.

For those domain specialists in your company who create content that you wish to bring into a smart corporate strategy, and whose job description does not include “DITA,” these power tools are just not a good fit, obviously. They’ll keep on using what they know and have access to unless you can give them something that they can agree makes sense for them as well as for the strategy. Not that they’ll have to love the new tool, but they shouldn’t have to hate it!

Content from across the enterprise is not only technical, it can come from marketing, business, site news, specifications, HR, company P&P, and more, very often NOT requiring information typing or technical domains. Much of that content has limited intersection with Tech Pubs. But when the directive comes to start implementing DITA across the company, or just anywhere beyond Tech Pubs, the need for simpler and seductive DITA editors becomes much more justifiable, in licensing cost, in training, in centralized IT provisioning (assuming the use of corporate collaboration tools), and more.

I can’t say that my experience using any of the heavy-hitting DITA editors has ever been particularly agreeable or in any way seduced me from other editors. But I’ll bet the business plan for the Codex team is based strongly on providing a compelling, low-barrier experience for these non-ID writers. Once you can get them into DITA, your existing DITA infrastructure can start providing more benefits: federated content sharing via common back ends, consistent appearance thanks to shared production tools and stylesheets, the option of reuse by reference for ID (in that generic DITA generally can be conreffed into any information type, which solves the typing problem), and more.

The full, easy end-to-end functionality for those users is still evolving, but I believe that the need for such tools for non-ID writers is greater than ever, and I look forward to more growth and better definition for the marketable uses for DITA beyond ID.

As the use of DITA grows for content across the enterprise, there are adjustments to make, of course. These tools are not for power tech writers. As many have observed, the features and functionality for working with standard DITA content is just not in these lower-cost tools. Therefore you must resist the thought of turning programmers and sales people into surrogate ID team members–they have their own jobs to do, and using DITA may never be in their job descriptions. But if you can give them a tool that just happens to ease the harvesting of their knowledge in a progressive way, you just might be working smarter rather than harder.

Editors in this category exist for several preferred content architectures:

• Browser based that you integrate into your own Cloud strategies, for which Xopus and DITA Storm are fairly full-featured examples. I’ve used the open source expeDITA Content Collaboration project as a demonstrator for what is possible using native, in-browser editing capabilities (at the Rich Text level).
• SaaS-based offerings, for which easyDITA is a good example. I don’t understand the role of  Codex well enough to say that it fits here for certain, but I think it is poised to grow in this space.
• Desktop-based offerings, in which collaboration is through the back end. These are close to full-featured, although not often seen in the high-end lists. Among them are Syntext Serna and XMLMind XML Editor which support DITA collaboration via the WebDAV standard. DITALabs does so via the CMIS standard. And Quark XML Author and Simply DITA for Content Mapper are Word-based add-ons aimed at “seducing” users with deep Word experience (which number in legions, I’m told).

Conventional DITA and XML editors for ID-level use can provide interface customizations that can help simplify the experience somewhat as well.  But there is a crossover point where the requirements for seductive user experience and non-expectation of deep DITA awareness drops into the realm of cost and function that the cheaper echelon of tools can provide.

And I have to mention as well my recent series on “Creating DITA” using the flotsam and jetsam of our connected lives–if you caught without your favorite DITA editor, you are not necessarily out of options for still getting your drafts into DITA for the longer haul.

Several years ago, we just didn’t have many lower-cost DITA options to press into beyond-ID usage. Now I’m looking forward to where this larger sea of DITA uptake can take us!