Tag: XML

What do we want?

At TCUK12 this year, I chatted with several people about authoring tools. Vendors, other technical writers, managers, I asked the same two questions, again and again.

What authoring application do you use, and why do you use it?

The answers were illuminating, interesting and always useful. There are many, many options out there, catering to many different needs, and all of them have a different set of strengths and weaknesses. Alas, no matter how hard I tried, regardless of how many ways I tried to bend our requirements, all of those conversations led me to the same conclusion.

No-one out there builds what we want so we may have to build it ourselves.

As part of improvements to our content, one of my team has led the charge to restructure our information. She has a passion for information architecture and devised a three pronged approach to our content. You can either navigate in by role, by product area or… by something else we haven’t yet decided upon.

We’ve audited the topics we have and applied some simple structuring decisions and it is looking good so far. The problem we will soon have is that we will need to build this new structure and make it usable by our customers.

What we would like is to be able to tag our topics, and use those tags to present a default structure to our information. The tags would also allow users to filter the topics they see and, either by addition or subtraction, create a unique set of information for their needs. Ultimately this would lead to personalisation of content in a basic form, but that could easily be enhanced to provide a smarter take on content for each user.

Alas it seems that, without doing a lot of customising of an XML (most likely DITA) based system we won’t get near that and even the products that get close require a compromise somewhere. Most of the time it would be, for the team of writers, a step back to a less friendly interface, and more exposure to the underlying technology of the tool they are using. At present Author-it provides a simple authoring environment that allows the writers to concentrate on writing content.

But perhaps that is the point. Maybe it’s time to try a different set of tools, adopt new working practices, take on a the bigger challenge.

Tagging

Last night on Twitter I asked “Looking for a way to tag topics in an authoring platform. Not part of Author-it, does any app do it?” and a few helpful people gave me suggestions.

I later clarified and thought I’d expand on that here. My clarification was that “Re tagging: we want to tag topics in the authoring tool so whatever the output, the user can filter on tags eg, v1.0/email or v2.3/document”, it was at this point I realised I needed more than 140 characters to explain what I was looking for…

Our product is in the throes of moving to a modular/component delivery. We will no longer have one installer to install one big product with everything in it, instead you will likely (it’s still being figured out) get a core application which you can then enhance with additional modules.

The challenge to our team will be to document this product in a way that is useful to both the people who might use the application and to those people who customise the application for specific customer needs (which may or may not involve customising a module or creating a bespoke module for a customer).

One idea that may help us in this would be the ability to tag all of our content with module/component/functionality tags, and a version tag. There may be more tags required but we can figure those out later.

However, the authoring product we currently have, Author-it, doesn’t offer this functionality. We have looked into a way of manually doing it by hacking XML files but it’s less than ideal.

So what I was asking for, badly, on Twitter was a native application that includes tagging of topics on the authoring side, with the tags then available in the output. Ultimately we want to be able to build dynamic sets of information AND allow the users to change the view of the information based on the tag(s) they’ve chosen as well.

MadCap Flare comes closest as it at least has a notion of ‘tags’ in the product but not sure if that allows a dynamically built output, and Robohelp allows tagging of returned search results but no way of producing that content dynamically.

Does such a product exist? It  feels like it should, that it’s not a million miles away from what a lot of technical writing teams would want… but I don’t think it does. Prove me wrong!

Technology vs Emotion

Random thought: Has the rise of (talk of) emotional content (affective assistance) been driven by the concentration, over the last few years, on technological solutions?

Single sourcing, XML, DITA, DocBook, and all the rest have (rightly) taken our profession forward, so I guess it’s natural that the general trends, as well as refocussing on the content itself, are looking for how to better engage with a modern audience.

The evidence suggests that that modern audience is Facebooking, Twittering, and blogging, and wants content in easily digestable chunks.

That plays nicely into the hands of single sourcing (chunks) and the idea of emotional content through connecting to the user, using friendly language to make the content easily digestable.

So, if you’ve already got your technology sorted out, why aren’t you looking at how your content is presented?

Conference Connections

I’m still tweaking my presentation for the Technical Communications UK conference, Thursday morning is looming larger and larger in my view so I’m distracting myself with considering the other good things that happen at conferences.

For me people are the primary reason for attending a conference. Don’t get me wrong, the value can be measured by the quality of the speakers and the information provided, but that tends to be transitory, so it’s the connections you make that count in the longer term.

I’m lucky that I’ve met some of the people I know through this blog, and I’m hoping to add to that tally this week. Part of me did consider trying to organise a little “meetup” of bloggers in attendance but I think I’ll leave it down to fate, I’d hate to NOT meet someone because I was concentrating on one small part of the crowd.

At times attending industry conferences can be a bit of a guilty pleasure, it’s only after the first hour or so you realise that yes, you CAN make jokes about the kerning on the dinner menu, or laugh at yet another example of Microsoft Word being helpful. It’s also acceptable to spend your entire lunch discussing whether audience surveys are a good thing, and whether you actually need to learn XML or not.

Obviously the presentations will drive some of the topics of discussion, but (and admittedly this is usual over dinner and a small beverage or two) conversation with your peers can lead to all sorts of other things. Chess boxing being one memorable conversation from a couple of years ago at TICAD.

So, despite still not being quite sure what the final form my presentation will take (I may also adapt it on Wednesday evening to reflect back on the speakers of the day) and not being 100% sure how I’ll get from the airport to the hotel (bus? taxi?), I’m starting to get a bit excited.

There will be a blog post published here on Thursday morning to coincide with my presentation, and I’ve no doubt I, and several others, will Twitter our way through the conference.

If you see me at the conference (I’m kinda hoping at least one or two people turn up for my presentation!) then rest assured, as long as you have either a coffee or a Guinness in your hand for me, I’m very likely to welcome you with a big smile.

Does single sourcing content work?

One of the more popular posts on this blog is titled DITA is not the answer and, whilst things are certainly moving forward, it’s a little sad that it is still valid.

A recent comment on that post suggested that it’s not just DITA that is lacking, it’s the working realities of single source that is flawed.

Well, that and the fact that I keep referring to single source when I am actually meaning content reuse (for you can have one source for everything but not reuse the content anywhere).

You can read the full comment yourself but the relevant bits are:

I have never seen single sourcing work. Maybe a single author who knows the topics thoroughly enough to reuse, or a tightly knit group of writers synched up at the same level.

The only place we are going to reuse content is in web mashups using semantic markup once the content is in the cloud.

It’s an interesting view and one which touches on something that has been on my mind these past couple of weeks as we are in mid-migration towards our single source solution.

Just how do you coordinate a team of writers, working in discrete areas of the documentation, with a large number (3000+) topics?

There are a number of ways we are tackling this and only time will tell if they are successful. Firstly we spent some time discussing how best to structure the source topics. Do we group them by product area? By topic type? Or some other arbitrary method?

We decided to group at the highest level (the top level folder) by user persona, and below that we grouped topics in accordance to how they are viewed from the product, so development kit wide ‘Events’ are stored in single folder, where as topics for a specific piece of functionality in the development kit are stored in their own folder. Your system will be different, of course, but this method suits our needs.

After that we need some way of knowing both what type of information a topic contains, as well as where that topic is used. We are not authoring in a DITA specific environment but decided to model our topic types on the DITA model to future proof us as much as possible (we are using Author-it which will export to DITA XML should we need it in the future). We have different templates for each type of topic (Concept, Procedure, Reference and so on), primarily to allow us to identify a topic (by default, Author-it shows which template a topic is using).

That leaves the final piece of our puzzle. How do know where a topic is used? This is more than just a list of which deliverables the topic will appear in, it also has to hint at the context of how the topic is being used.

Does any of this mean that we are more likely to reuse content? Not necessarily but it should give us a fighting chance, and once we’ve updated the content plans for all of our deliverables we will start to really see the benefits. Those content plans were the very things that suggested we could reuse content across multiple deliverables and I’m certain that, with a bit more analysis, we’ll get further gains.

Can single source and content reuse work? Of course it can. There are plenty of good examples out there and they all share one thing in common, something that isn’t really broadcast by the vendors; content reuse from a single source takes a lot of hard work.

But it is possible.

How do we move to single source?

I’ve waffled on about single source and our plans for long enough so, as we are finally starting the process itself, I thought I’d capture some information as we go along. However, it’s probably good to set the scene, so I’ll cover that stuff first. Over time you’ll be able to see all the posts related to this work here.

How? – how do we do it?

Once we’d agreed that single source would provide us with a good solution (it’s still not ideal, but nothing ever is..) the next question was “How?”.

Having followed the technologies in this area quite closely over the past few years my immediate thoughts went towards a DITA enabled solution. The basic topic types and methodologies fit well with an Agile environment so there would be fairly immediate benefits once we got the system up and running. We spent some time investigating our content and planning how best to leverage DITA to our advantage and once we were happy that it would meet our needs (with less over head than adopting DocBook) we looked at the technological challenges of adopting a DITA based system.

And that’s where we hit the biggest block. DITA is an excellent methodology but still lacks simple/cheap tooling support (it would take upwards of several thousand to fully implement a DITA solution, whereas a bespoke solution could cost considerably less). Other considerations (we have JavaHelp as our online help format) also came into play and, after some investigation of other XML based tools we decided to go with Author-it and base our working practices around the DITA methodology and topic types.

We did consider upgrading our legacy applications (FrameMaker and Webworks) and configuring them to give us a solution that would meet our needs but even the rough estimates for that work took us beyond the cost of our chosen solution.

One caveat to this is to note that I have used Author-it previously and, whilst it is not without its foibles (which application isn’t) it hits the sweet spot of functionality versus cost. None of the rest of the team have used it but that would be the same for any other new tool and was considered as an upside to keeping the FrameMaker + Webworks solution.

A second caveat is that I’m fully aware that, in due time the tool vendors will get on top of this problem (MadCap already seem to be ahead of the others in this area), but alas the timescales don’t suit us. Worst case scenario is that we ditch Author-it in a few years, export the content to DITA XML and import to a compatible tool that meets whatever needs we have at that time.

Thoughts on HATT Survey thoughts

Tom Johnson has had a look at the survey recently published by the HATT matrix website on help authoring and, by pulling in the results of some other surveys in the same area, has extrapolated some good conclusions from them.

He rightly points out that surveys need to be taken with a pinch of salt (he goes into the detail of why this is so), and that whilst the numbers involved would seem to be high enough it’s likely that the questions themselves need further consideration in future.

That said, there are two things I took from his post.

1. Know the problem before picking the tool
You may not be in the position to switch authoring tools, but if you are and you have investigated the market then please make sure that you are buying a tool that addresses the problems you have.

The presumption here is that if you have a legacy tool (like we currently do, FrameMaker 7.1) and it still works and meets your requirements then there is no good reason to upgrade. I’ve been victim of buying into the ‘keeping up’ frenzy that software manufacturers like to generate but once a product is reasonably mature it is likely it has most of the features you need already.

I’d offer Microsoft Word as an example here, I could probably still use Word 2.0 for the few documents I maintain in that format as the newer versions add functionality I don’t need (and which has ended up intruding on my workflow at times!).

The X-Pubs conference a couple of years ago had a common, if not publicised theme. Almost all of the presentations included the advice to figure out what problems you had, before deciding IF single sourcing (using XML as the base format) will help and that’s even before you consider the tools themselves.

2. DITA is still a theory
Whilst it is true that the number of people leveraging DITA for their content is rising, the numbers remain low.

Partly that will be due to the fact that few organisations/teams/people are in a position to quickly switch just because a new technology has come along, but and I’ve said this before (in fact I’ve said that I’ve said this before!) rollout of DITA remains harder than rolling out a bespoke authoring tool.

When costing an implementation of a new tool there are various factors and it’s very easy to see that you can get MadCap Flare up and running quickly, where as a DITA based solution takes investment in developing the environment. This is beginning to change but, as yet, the phrase ‘DITA support’ really only means that you can output to a DITA formatted XML file. The tools aren’t constructed around the DITA concepts, so you immediately lose a lot of the benefits that DITA can bring.

Until there is a tool that fully leverages DITA, building it into the workflow of using the tool, and helping the concepts become part of your daily working practice then it will continue to be a marginal player.

Which, in a way, is how it should be. DITA is not a tool, it is a technology and methodology. It is there to support the toolset and the writer. It’s just a shame that tool vendors continue to believe that THEIR format is best, refusing to budge from that position and shoe-horning ‘DITA-esque’ features into their software.

Anyway, the rest of the survey write up is interesting and worth a read but, as Tom says:

“I do love these surveys, though; if for no other reason than they give us something to talk about”

Back to DITA?

I’ve mentioned DITA a few times on this blog, and my DITA is not the answer post is still attracting attention. As I’ve said, I think the DITA standard is an excellent one for software documentation and the DITA movement is slowly catching up to the hype. I’ve never given up on DITA and had always planned to use it as the basis for the next stage of our content development, and as it happens the switch to a full DITA/CMS based solution may be closer than I had anticipated.

We have been considering how best to publish up to date information in keeping with patches and minor releases, and if we can tidy up and publish useful information from our internal Wikis and support system. The nature of the product we work with means there are a lot of different usage patterns, not all of which we would document as they fall outwith typical (common) usage.

So, how to publish formal product documentation, in-line with three versions of the product, in PDF for ‘printed’ manuals, JavaHelp to be added to our product, and HTML to be published to a live website alongside other technical content (ideally maintained in the same system as the product documentation). Storing the content as XML chunks also allows us to further re-use the content programmatically (which can be tied into our product in a smarter, dynamic, fashion).

The obvious answer is single source using DITA to structure the content, storing the content as XML to give us the greatest potential avenues for re-use. Nothing particularly startling there I know, but it’s a switch from the direction we had been considering. So I’ve been catching up on what’s new in DITA-land and have to admit I’m a little disappointed.

We already have FrameMaker and Webworks in-house, although both are a couple of versions old, and thinking we might keep using those applications I’ve been hunting about to see if I can find a solution that offers a coherent, end-to-end, story. There are several CMS solutions which require an editor, editing solutions which require a CMS, and a few products that straddle both CMS and editing but then require publishing engines.

I understand that it would take a collaboration between vendors to be able to offer a simple, seamless solution

In addition to that there does seem to be a tendency for any DITA focused solution to remain the remit of the overly technical. Don’t get me wrong, I’m quite happy delving into XML code, hacking elements, or running command line scripts to get things done. But surely I shouldn’t have to resort such things? Now, I’m sure there are many vendors who will tell me that I don’t need to worry, but I’ve seen several demos and all of them miss a part of the FULL story.

Come on then vendors, stick your necks out. If you are a CMS provider, then recommend an editor. If you sell editing software then talk nice to a CMS vendor and start promoting each other (yeah Adobe, I’m looking at you!).

And yes, I’ll happily admit that maybe I’m just not looking closely enough. If only there was some sort of technical community website that I could join, perhaps with a group or two on DITA? That’d be great.

Ohhh wait. There is! (not the most subtle plug in the world, was it? I think the new Content Wrangler communities could be a big hit, do check them out).

Have a got the wrong end of the stick, are there really gaps in the market in this area at present or is it just my imagination? I guess I’ll be running a fair few evaluations over the coming few weeks and, of course, I’ll post my thoughts and findings here.

Recently Read

Another week (and a bit) has passed. Time is tight for me at the moment, and I’m not posting here as often as I’d like so, for now, here’s a quick roundup of everything that’s zipped past my inbox in the past week:

Resources on presentation design

… advocates an assertion-evidence design, which serves presentations that have the purpose of informing and persuading audiences about technical content

Needless to say, with my first ever conference presentation looming, I’m fairly focussed on both topic relevant stuff and anything that will help make my presentation better.

An XML CMS is simple as 1-2-3

Creating an XML-based Content Management System to single-source technical publications is as simple as 1 – 2 – 3. Rather than focusing on any single tool or solution (and thereby forcing users to change to match the tool), this article describes one possible three-step process for using XML to single source your content deliverables.

A rather simplistic view of things, but if you are a bit flummoxed by the raft of information available in this area, and you aren’t really sure where to start, have a quick look at this. Short, simple and easy as A-B-C.

Make your writing east to scan

… the acid test is looking at your information as your reader/user would see it, and asking yourself “can I find what’s important without reading the whole page”?

You can format your text in a variety of ways, but it pays to take a step back and view the format of your content from the point of view of your readers.

Getting to the web-first mentality
Interesting to read that other professions are struggling to embrace the internet. Ultimately I think it’s getting to the point where we just need to take the plunge.

Start putting the web content management system into the workflow at the front end. This could be as simple as using Google Docs as a word processor instead of the bloatware that we know as MS Word.

Collaborate or fail
Titled “Building a Collaborative Team Environment” the opening couple of paragraphs kept me reading:

Technical communicators work hard to meet deadlines and value the standards inherent in the profession. At the same time, they value their personal creativity and the responsibility for developing a complete publication on their own. They tend to enjoy doing everything from writing, editing and page layout, tographics, technical content, and more.

Working as part of a team to create a single set of deliverables, handing over responsibilities to fellow team members, and trusting the work produced by others does not come naturally.

It’s an excellent article, looking at a variety of ways in which we, as technical communicators, can adapt how we work. It will no doubt prompt some posts here as I digest it further.

And on that, somewhat culinary note, I’ll thank you once again for stopping by.

Explosions: keeping ahead of the blast

Is it just me, or are we seeing a notable growth in the tools and voices linked to our profession? Are we, the technical communicators (writers, authors, designers, whatever..) finally clued in to the internet and making the best use of the global space? Are the tools we use starting to touch other areas of our organisations, thus raising our profile, which raises the bar for the tools, which expands the reach, which raises the profile…

It’s just me, isn’t it?

I’ll happily admit that, a couple of years ago, I was growing apathetic with this industry. I dreamt of working in a zoo, tending to cute fluffy animals and having nary a worry in the world (and likely not enough money to pay the bills). Since starting a new job in January this year I’ve rediscovered my vigour and enthusiasm, and that seems to have been matched by the tool vendors. I would also try and lay claim to the growth in technical communications focussed blogs and websites but that’s a little generous of me I fear.

FrameMaker has launched a new version and a new suite, AuthorIT has launched a new version, MadCap blazed onto the scene (geddit) and ruffled some feathers, and the XML focussed single source arena seems far more active than it was. Now, I’m happy to admit that it may just be that I happen to be more aware of what is going on, but the coincidences are a little too high to ignore.*

Of course what this really means is that, at some point in the near(ish) future, people are going to start to select a tool. The XML guys are reasonably future proofed in that respect for, as they all share a common file format/standard, the choice of tool isn’t the locked in choice it once was. In a way, AuthorIT is in the same boat as they can roundtrip through XML, even though they store their information natively in a database.

But our dear old FrameMaker, despite the new version and a seemingly re-invigorated development team, now sits as the odd one out. When I heard that Adobe had launched a Technical Communications Suite I presumed, instantly, that it would mean “instant single sourcing”. Possibly a simple CMS backend, from which you could pluck topics and edit them in FrameMaker or RoboHelp. At the very least a proper roundtrip between those two tools and, as we now know, we don’t get any of that. In fact Adobe have introduced even tighter coupling between their two applications and I’m still trying to figure out if that is a genius move, or a final throw of the dice.

Regardless of which tool you choose, or which blogs you read, this profession is growing. Links are being established between other groups, and as software continues to increase in complexity the understanding of the need for good documentation is continuing to rise. I’m certainly spending less time explaining both what I do, and why it is needed and that can’t be anything but a good thing.

The ability to self-publish has created millions of “writers”, and an astonishing change to the way people view the written word, in a very short time. Some of those people write about technical issues, indulging themselves by sharing their hobbyist knowledge and, as such, they are both the subject matter experts and the technical writer of their niche.

As a profession, our ability to collate, filter, sort, and organise information, tailoring it for the right audience, providing that information at the right time, in the right place, will be the key differentiator. The playing field is levelling out, but we have some tricks up our sleeve yet.

* I’m deliberately ignoring the HATT arena, if you have any insights there I’d love to hear them.