Steve Wiseman, Client Engagement Specialist at Paligo and experienced technical writer and information architect, had a conversation with David Toth about the challenges and future promises of technical documentation today.

David Toth is an experienced Customer Enablement Manager, having worked with developing documentation and communication platforms for many years in a variety of businesses from banking to telecommunications to high-tech startups and more.

Not only does he understand the documentation field and structured authoring very well, he also has a much broader knowledge of the whole perspective of the benefits of good documentation management for a business.
David is also a highly knowledgeable and respected director, mentor, and trainer for team members at various organizational levels and levels of technical competency.

In this interview, David speaks about the challenges of moving to structured authoring, what some of the pitfalls are, and how he sees the move to the cloud as changing the future of technical documentation.
Read the article below or listen to the full interview in the audio version in the player.

Steve:

David, you’ve used a number of authoring tools in the past, can you tell us some of the pain points you’ve seen?

David:

Absolutely. The last 10 years have definitely changed. I was actually talking to somebody the other day and we talked about how we used to go to our vendors and say “I’d like to connect System A and System B”, or “I’d like to take some content and get it somewhere else.”

They used to roll their eyes and go “that’s going to be very expensive and so difficult you should probably not even try”.

Now the systems support us, rather than the reverse where we had to spend 80% of our time trying to make the system deliver what we wanted

Fast-forward 10 years and now we have got this variety of cloud applications that allow us to start gluing together all these pieces. It’s completely changed the way I look at the work we do. Now the systems support us, rather than the reverse where we had to spend 80% of our time trying to make the system deliver what we wanted.

Now we can actually spend our time authoring structured content and making it easier for our authors to contribute that.

Steve:

You mentioned “structured content”. For those who are not familiar with the term, it might need some explaining. So what is structured content, and why is it a big deal? So you have XML documents, for instance, but what does that actually give you?

David:

Well, that has changed over the years. I remember when we were just guided by the fact that structured content would give us reusability. And that is a fantastic, amazing feature you get with structured content.

But to the business, that’s not always what drives these decisions. You have marketing departments that want to know, are we generating enough leads, customer service that want information about their customer satisfaction. How do the values of structured content really propel those other metrics in the company forward?

Hey, we can put out our content to a variety of channels now…

I’ve found over the years that we’ve developed the opportunity to align those goals together. The authors can make better use of their time due to the time savings of structured authoring, more efficient production with content reuse.

But also, the businesses begin to realize that “hey, we can put out our content to a variety of channels now”. It’s not just producing that one document. It’s also getting it on the web. And also reaching out to new devices, like Alexa, and other platforms where we can take this content, repurpose it, not just within the document, but also get all these other values from structured content.

Steve: 

Tier Zero: helping customers help themselves

When you talk about channels: I heard a very interesting expression recently I really like. A few years ago the concept of self-service came about. You have support channels like phone, chat, email. But the most effective channel for the company…is the content. It’s the self-service channel.

The expression I heard was “Tier Zero”. We know customer support talk about “Tier One”, “Tier Two” for the levels of support provided. And now I’ve heard the self-service content called “Tier Zero”.

Have you heard this expression?

David:

I haven’t actually heard it, but I absolutely recognize that companies are really trying to deflect calls and tickets. They can’t really handle the volume of customers asking about simple things like, say, password reset.

Companies also say the love when the customer calls because it gives them time to talk about their product too and get a connection with the client. But they don’t want to spend that time with the simple questions. What the self-service, or “tier zero” does is it gives them the chance to deflect those issues, and spend more quality time with the customer.

Steve: 

But how many companies have you seen that are actually doing this?

David:

Well, I bet there are these enormous enterprises that already do it. They’ve spent millions of dollars getting there. But now, going back to the cloud topic, this is becoming available to small and medium-sized companies at a price point that’s more acceptable.

Steve:

Yeah, let’s just take a figure: 60% of support tickets that come in to a company are generally just tickets where the agent sends a quick link to something, and they’ve found the answer. If the customer could find the answer themselves they’ve saved all that time.

By the way, something that I found quite astonishing, is that many companies, both small companies and enterprises, are using authoring technologies that were created in the 80’s, 90’s or the beginning of 2000. Most of the common and tools still used today, especially the help authoring tools, or “HATs”, were built on technologies from a long time ago.

On the other side, there are all these “Tier Zero”, the support platforms, and you ask many technical writers: do they put their content into “Tier Zero”, or a term they’d be familiar with, and the answer is no. I found that quite astonishing, that most authoring tools are not making the most of modern delivery tools.

What’s your experience with that, David?

David:     

Yeah, I think that if you were an enormous enterprise with a million-dollar budget to build customized connectors, maybe you could move things over but, for the smaller companies, it’s just been cost-prohibitive with the tools that have been available at that price point.

Steve:

In my experience, even the enterprise companies aren’t even using the latest and greatest tools. A lot of them are still using those tools that were created 20 years ago. So I think the enterprises also have a lot to learn from these ideas.

David:

Sure. The good thing is that people are now rapidly changing the way they look at how they solve problems. The days of vendor lock-in are quickly evaporating. It used to be, “we bought this new content system and it’s going to have a life span of 7 years”. Now everything is from a year to year basis. We’re looking at these things and ask what’s going to happen next. And it’s getting a lot more flexible in the way that we can address these issues.

The days of saying “we’re on this because it’s too painful to change” is becoming a less and less palatable answer for a lot of leaders.

Steve:

It is, once they move to the cloud, which is integral.

I wanted to ask you, what kind of change do you think the cloud is making to technical authoring? There aren’t many products in the cloud for technical authoring, apart from Paligo, maybe one or two others. There aren’t many.

So is the cloud going to make a big change to the way writers author and deliver?

David:

I think it’s going to be huge.

I think it’s going to change the way we do technical authoring just the same way it’s changed other things in our lives.

In the cloud we can do authoring in a collaborative fashion.

Cloud solutions for technical authoring is going to be like night and day

When you think about how it’s been before, you had to try to put it together from your publishing software, you had to have some version control in there, some way to check in and check out content, and so on. And in the cloud we expect all these things to be wrapped up into a single piece. On top of that we want to have workflow, and assignments, see what’s been worked on, when it’ll be complete… All these things that, if you try to stitch them together on your own, it becomes incredibly complex to manage and incredibly expensive to purchase.

For this type of solution the cloud is going to be like a difference of night and day.

Steve:

Maybe I’m using too strong a word here, but don’t you think it’s a little embarrassing, that the technical writing world is only now beginning to talk about cloud, whereas most other technical industries moved there a long time ago?

 

David:

I think part of the resistance for why people still use old tools is because they have mastered the old tool, like “I know how to make this thing do back flips” and I don’t want to replace it with something I’m not a real expert on. But you still have tremendous value in the organization, and that’s not as a platform manager, it’s as a technical publications expert. You just get a role that’s more focused on what’s really valuable to the company, like getting the most out of this content.

I know a lot of people who are heavily entrenched in these old tools have no interest in leaving them, and they will thumb their nose at the cloud, saying cloud applications can never do what we do.

Part of the resistance to new solutions is you know the old tools so well.

It’s sort of like back in the 90’s when people said virtual servers will never happen. But virtual servers got faster, and now, put things on Amazon Web Services, where we can inflate our infrastructure to 20,000 computers, and then shrink it down to 2 computers the next day when we no longer need it. That flexibility is invaluable, instead of having to set up 5 data centers for 2 days a year.

But, as long as there was no good solution to move to, the resistance made absolute sense. And that’s where we are now starting to see some viable products that do what we expect them to do, and even offer some additional features on top of that.

And now we’ll be able to be even more efficient in our authoring. Like what we are looking at now is to be able to publish out to our support site. This is an enormous barrier that we’ve been able to remove, to be able to publish directly from our cloud publishing system to our support, or “Tier Zero”. It opens up whole new possibilities for us to rapidly deploy content to our end users.

And one thing I want to add to that is that these days, especially for software companies, you’re going to have releases coming out, sometimes monthly, some do them quarterly, but there’s a constant releasing. There is no one-year, or even 6-month, breathing period. It’s constant.

Redistributing content quickly to different channels will be one of the metrics driving the adoption of structured authoring

So you have instantly to be able to check the content you have and output it to all these channels, and you need to do it very quickly.

And I think that’s going to be one of the metrics that quickly drive the adoption of structured authoring – the ability to quickly redistribute that content out to those channels.

Steve:

Very interesting, and I agree with you.

I think our last point is this: I’ve come across people who are using something now that’s not structured authoring, products they’ve been using for years, and they want to move to structured authoring.

But I think some people might be scared because it has traditionally been very expensive, and sounds like such a large job and such a large investment to move into a CCMS and structured authoring environment, such as Paligo. 

Do you have any opinions on that, to maybe ease the door to people wanting to move into a better and more thorough authoring solution for them?

David:

Well, I think there are some experience barriers that still exist. Technical publishing with structured authoring still requires a good amount of knowledge of how to logically structure information, and how to get the most out of reuse. And I think that’s the remaining challenge for people who still find it daunting. But I think the tools now help release some of that burden.

And in a licensing platform, it makes it easy for people to get their toe in, see what is it to build something small, and then build it into something bigger.

It’s like a current project I’m working on, that started in a technical publications way, but this is something that, with an easy authoring environment, we could see grow out to other teams that usually wouldn’t do structured content. And they probably wouldn’t even know they are using a structured authoring environment, because they’ll be using the simple markdown interface: just structure their thoughts, and then the tech writer team can go in and make their updates, and then push it out to our different channels.

Steve:

Right, and it’s like I often say to people, that Microsoft Word might be a good application for writing documents at a basic level. But it doesn’t make you a good author.  You have to know how to write.

It’s the same way with a good cloud-based platform like Paligo. Like you say, it’s giving you the right tools, but you still need to know how to organize and structure content.

But my point is, in the past just the tool question in itself was a nightmare. Now that nightmare is being removed, and the authors are down to the core tasks, which is organizing and writing the content. And because workflow, translation, assignments, and all that is all integrated, it frees up the writers to do a lot more useful work to them.

Regarding structure, I had a discussion today about how importing and migrating is not the same thing. Importing can be a very quick task that could take no more than 15 minutes. Migrating is making that content useful. Working out what can be reused, what conditional filtering to use, what should be the size of my topics, and all that. But it’s not such an awesome task like it was previously, because the tool is going to help you do a lot of it.

David:

With an integrated tool for technical authoring, we’re getting technical knowledge straight from the horse’s mouth

I completely agree. And I think the possibility of being able to distribute this responsibility is going to make everybody a little bit happier. That the person doing the technical writing doesn’t have to be the person bearing the brunt of all this, that you can share content, and distribute authoring and the parts of the business to the people that know is best. Where the subject matter expertise is, and that’s an important part of it too. We’re getting it straight from the horse’s mouth, as they say. And then to bring that in and apply structure and reuse to get the most of the content for publishing.

Steve:

That’s right. Thanks David, you’ve made some fantastic points. I think there’s been a lot of positivity in this conversation. I really think we’re at a crossroads, a positive crossroads. I remember hearing things in the past where they’ve been claiming new ideas changing things, but I really think we’re there now. Cloud-based tools for technical authoring, integrations with delivery platforms like support help desks. I think it’s a positive crossroads where the tools and methodology of technical writers will increase their effectiveness, enabling them to write better, produce better, with better information for customers, at the least effort, which is ultimately good for the business.