10 thoughts on “Structured Writing FOR the Web”

  1. There’s a lot of content in wikis that you might call body of knowledge content, and there’s still demand to offer that in pdf format. As evidence we can look at the number of downloads for the Scroll Pdf plug in – this enables you to create multi page pdfs from Confluence. It currently stands at 11,100 downloads. It’s a chargeable plugin btw.

    1. Good point Ellis. Wikis do seem to the the one Web platform where there is also a demand for PDF output.

      What I always wonder about Wikis is, did people buy them because they wanted to produce Web content as their primary output or because they wanted the collaboration features.

      For whatever reason, Wikis do seem to have more traction in Tech Comm than standard WCMS.

  2. Boy, Tom set off a firestorm with his recent blog. I’m not sure there’s a definitive right answer. I only know what my readers need–or, at least, that’s my delusion.

    I write for sys admins, cloud users, and cloud admins. We’ve found that the sys admins and cloud admins like the PDFs. I’m sure it’s because of the installation and configuration tasks that require off-time when the machine isn’t available to refer to digital doc on the web.

    It seems to me that end users of an app or product like web docs better. They’re usually not reading a lot or sequentially.

    We generate webhelp and PDFs from XML. I’m not sure what the deal is with structured vs. web. I don’t see these deliverables as being incongruous at this point. Maybe because we don’t use a CMS. Or maybe because I’m just not smart enough to see the nuances in the debate here.

    1. My experiences are similar to yours, Scot. I think when you have hardware, an installation, or both involved, folks prefer paper (or electronic implementations of paper like PDF or EPub).

      The Web does not seem to me to be the best delivery mechanism for a project like building a data center from scratch. I guess it goes without saying that this is not “every page is page one” scenario.

  3. Similar to Scot’s experience, when I was managing a doc wiki most of the requests for PDF came from internal users who wanted an offline version (while traveling), or from the sales team who wanted to present some documentation to prospects. The latter request disappeared when we were able to open the doc site so it was no longer locked behind the product’s login requirements.

    This was also documentation for a SaaS product, so users wouldn’t be doing any work with it while offline.

  4. Essentially, Mark picks up a topic here, that I’m going to use for am essay for my certification. Single sourcing – especially in context of web vs. paper vs. mobile output simply doesn’t work in most cases. The different media is always asking for different source content. Linking doesn’t work in paper output. Large topics won’t work very well on mobile devices.
    But essentially structured authoring is key to a workable solution.
    Function design is one of the attempts to generalize information in a way, that separates content from design completely, but in most cases the reality of function design is a nearly incomprehensible conglomerate of myriads of XML elements.
    Actually I don’t think you have a truly workable solution to deliver your information in the same quality for each output, yet. And every attempt to get everything covered may ultimately fail.
    At the time being, all we can do is to decide for one or two main output media and write for them specifically.

  5. You don’t have to implement structured authoring all at once. Author-it has a business logic layer that can be applied as appropriate to legacy or new content.

Leave a Reply

Your email address will not be published. Required fields are marked *