Steps to structured content (podcast, part 1)
Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Amazon Music | Email | TuneIn | RSS
In episode 85 of The Content Strategy Experts podcast, Gretyl Kinsey and Bill Swallow talk about the steps to structure, how to move from unstructured content to structure, and what each level of maturity looks like.
“It’s important to keep in mind when you move from step two to step three that your authoring tools may change. The writers might have gotten used to working with one set of tools in steps one and two. But as you move to structure, the tools that you’re using for unstructured content may not support the underlying framework for the structure that you’re moving forward with.”
– Bill Swallow
Related links:
- Moving to structured content: Expectations vs. reality (podcast)
- The challenge of digital transformation
Twitter handles:
Transcript:
Gretyl Kinsey: Welcome to The Content Strategy Experts podcast, brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way. In this episode, we talk about the steps to structure, how to move from unstructured content to structure, and what each level of maturity looks like. This is part one of a two-part podcast.
GK: Hello and welcome everyone. I am Gretyl Kinsey.
Bill Swallow: And I’m Bill Swallow.
GK: Today we’re going to be talking about structured content and all the different steps it takes to get there. Let’s just go ahead and dive right into what is the first step or the baseline when we’re talking about moving from unstructured content to structured.
BS: Well, I guess the very first step that you’re on is that you have content.
GK: Yes.
BS: Congratulations. You have content. It exists. It’s probably written well. It is probably being authored by a bunch of different people or authored by people using a variety of different tools. Basically there’s no general rhyme or reason as to how the content is being produced, but it looks good, it serves its purpose, it’s published, it’s out there, people are reading it, but there’s generally no underlying structure. You might be using Microsoft Word and various other tools, no actual templates involved, all the formatting is kind of ad hoc and all hand produced.
GK: Yes. I think this is what we consider as the baseline or the bare minimum when it comes to content. It’s there, it’s well-written, it’s usable and you have it and it’s working, but you’re not really able to leverage it necessarily and do a lot more sophisticated things with it, and so you may have some limitations if you’re at step one. For example, with how you publish your content if everything is very manual in the process of creating it, then that’s probably true on the publishing side as well. So you’re not really getting mass automation there. You may also be limited in your ability to share content across maybe different departments, different types of documents. A lot of times when we see companies who are in what we would consider the step one, they tend to be in silos with unstructured content, and so you’ve got sort of different types of unstructured content all over the place and none of it is really connected or working together.
BS: Right. With regard to being able to share the content, there’s also that issue of copy paste that we ended up seeing a lot. This happens a lot in this first step where if you need to share content or you need to reproduce the same content in multiple formats, or in multiple documents, there’s a copy and paste going on, which then just adds to the whole snowballing effect of being able to manage to your content. If you need to make an update, you then have to find where you’ve copied and pasted that information throughout all of the documents and deliverables that you’ve produced.
GK: Yeah, and sometimes this can really have a snowball effect where if you do have different departments that produce content and let’s say maybe you don’t have as much of a problem with separate silos, but you do have this issue where there’s no connectivity. So let’s say you’ve got some folks over in training and they need to reference information from the official technical documentation and their training materials, and they go over and don’t necessarily grab the latest and greatest version, but they copy and paste some of the documentation from somewhere and then that gets into the training materials. And so there’s not really any sense of version control. There’s not really a sort of enterprise level sense of how the content is being used and maintained. That can really become a big maintenance issue over time as you need to grow and scale.
BS: Yep. With regard to growing and scaling and with regard to leaving this first step behind, what is, I guess, the next level that we’re going to; step two?
GK: Step two is when you’re using templates and a consistent style in your content. This is where for example, if you are working in something like Microsoft Word, Framemaker, InDesign, you actually have templates set up. So you’re not just kind of ad hoc creating different styles all over the place. You’ve got something that can not necessarily enforce that style, but at least give you a guideline to work within and some parameters to use as a starting point. That can really help improve that consistency of your content, can make sure that everything follows a more not exactly structured, but approaching structured pattern. This is something that I tend to refer to as implied structure because it’s not actual enforced structure on your content yet, but it’s kind of that intermediate step to getting there.
BS: With that implied structure, there’s also usually a style guide that will go along with it that will further help people follow the same structural composition when they’re authoring. So it’s not just the templates that are in place that they always use heading one for the first level heading in a document or use a particular note style if they need to produce a note in their documentation, but there is also a style guide that says, this is how the content should be arranged. Not only going through and saying these are what all the different styles afford, but this is generally how you approach building documentation. This is the type of content that you want to put in this type of section in whatever you’re writing.
GK: Yeah, absolutely. I’ve seen some company style guides also address things like branding consistency. So if you do have a lot of different departments creating content, there is something that says here is the logo you always use, here is the official way that you refer to the company, here are the official list of product names, that sort of thing so that there’s not an inconsistency there that just makes your company look unprofessional. We also can see it sometimes if your company is doing any kind of localization, if your content is being translated and there are particular things to avoid or ways that you want to phrase things that help make translation easier, that can be included in a style guide as well.
BS: Yep. Really, it also comes down to that level of organization of content within the documents you’re putting together. So if you’re putting together training materials or some kind of repair guide or something that’s very procedural, you generally want to have a section that says, “Okay, we’re going to start with a heading. We’re going to introduce the topic using these types of paragraphs. Then we’re going to break into a subheading and perhaps give a list of all the parts required, if you’re doing some maintenance or all of the things you need in order to complete a particular procedure. And then jump into the procedure itself, perhaps with another heading or with some other section delineation there.”
BS: That way the style guide allows the writers to understand when they’re going to write something for a particular audience, that they have this structure in place that they can follow. Again, it’s an implied structure. There are no set rules against it, other than the style guide and whoever enforces that coming down on the writers and saying, “No, you must do it this way.” It at least gives you a starting point to be able to start making your content look and feel the same, regardless of who’s authoring it, regardless of what tools they’re using to do it.
GK: I think that’s a really important foundation to get in place before you move on to step three. What is step three in this process?
BS: Step three is actually using structure. So being able to identify that there is a need for this level of consistency and these level of rules and adopting a framework that builds those controls in. So structure, we’re talking something like XML or DITA, which is a flavor of XML, SGML, that’s an old school one that’s still around to some degree, but it’s essentially a technological framework that says, “Here are all of the types of content that you have, and this is how they all play together. This is where they’re allowed. This is where they’re not allowed, and this is how they all flow together as well.”
GK: Yeah. So this going from step two to step three is really the break point between unstructured content and structured content or between that implied structure we talked about and an actual structure. I think that’s why it’s so important that if you are going to move out of your unstructured content and get into true structure, that you do have that intermediary step one to step two, because if you try to go straight from step one into step three it’s probably not going to be a very clean migration over into structure. So if you’ve already laid that groundwork and you have that implied structure in place in step two, it puts you in a much better position to go on to step three.
BS: Yep. Not only do you have the content aligned so that you can convert it to some kind of structured format, it makes that conversion process a lot easier. If you have step two in place and you have these solid templates that you use, and you have this consistent writing format that you’re using, you can automate that process to some degree, or if not completely to get it to a structured format. But it’s also important to not skip step two, because you want your authors to be able to acclimate to now writing in a structured format. If they’re used to just doing whatever they would like as long as the end product looks good and reads well, they’re not going to come around to the idea of authoring in a structured environment very willingly.
GK: Yeah. This is, I think the biggest challenge that we do see when a company goes from unstructured content to structured content, is that big mind shift that has to happen. That’s why I think it’s important to have that step two, so that people get accustomed to working in something that’s like a structure, even if it’s not a programmatically enforced actual structure that that mind shift does not have to be as big, because that is where you see a lot of resistance to change that can just really get in the way of your progress.
BS: Yep. It’s important to keep in mind when you move from step two to step three, that your tools may change, your authoring tools. The writers might have gotten used to working with one set of tools in steps one and two, where they were unstructured but perhaps following a style guide, perhaps using different templates, but as you move to structure, the tools that you’re using for unstructured content may not support the underlying framework for the structure that you’re moving forward with.
BS: Often we see a little bit of reluctance among the authors to move towards structure because the tool set is going to change. And what they’ve been accustomed to using perhaps for many years, they need to abandon, and they need to adopt a new tool with a new user interface, with a new underlying file format that they are just not accustomed to. Things may look a little strange, especially when you’re moving to structure using XML or so forth, that doesn’t have formatting necessarily applied to the content itself. They’re not accustomed to seeing a different representation of what they’re authoring than what will be delivered to the other people. So what they’re authoring in and what it looks like to them is not what it’s going to look like to the person who’s reading the finished produced deliverable.
BS: That’s a little jarring for some people. A lot of care needs to go into making sure your team is aware of these changes and that they have the training and the support necessary to make that leap.
GK: Yeah, absolutely. I think it’s a really intimidating thing because suddenly you’re going from, like you said, something where you can actually see what the finished product will look like as you’re working to something where you really have no idea. If you are moving to structure for the purpose of automating your publishing processes, for example, then you’re going to have one tool for authorizing, you’re going to most likely have some other tool or suite of tools for content management and then another tool or suite of tools for publishing, and all of those pieces are separate. So if you are used to everything all being in one tool together where you write everything, you review everything and then you just export it directly to publish from that same tool, and then suddenly you’re in this very different framework, it is a shift in not only the tools themselves, but how you work.
GK: It’s really, really important to make sure that nobody feels like their concerns fall by the wayside or that they’re getting left behind, but that instead they are supported because really there are a lot of benefits to this. I think that’s the main thing is just you convincing people here is how your life will be so much easier if you’re not dealing with all of those problems. We talked about earlier with copying and pasting, and not knowing where your content lives and not knowing what version is up to date. Going to structure can really help fix all of that. But it is that big change that you have to get people over that hurdle.
BS: Right. If they’re accustomed to producing multiple different types of deliverables, for example, a PDF and some HTML from a particular content source, it’s going to make their lives a lot easier on the publishing side, because that can be done automatically. At that point, you’re really removing the writer from the process of publishing, and their job is to make sure the content is structured appropriately and written correctly. At that point then automation takes it to the publishing stage.
GK: Yeah. Another thing that you get at this stage that I think it’s important to call out is that you get to leverage smart reuse. So instead of copying and pasting information, instead of finding workarounds to share it, you can actually have a single source of content that gets used in multiple places. That again is another shift in mindset, right? But that’s also a major benefit that you get out of going to structure. That’s something again, that should be a major part of training for writers.
GK: On a lot of the client projects I’ve worked on, we end up doing a split where we start with basic structured authoring training, and then we usually do a separate training session or series of sessions specifically on reuse for each company because each organization is going to have its own reuse strategy and its own reuse requirements. Being able to leverage that finally is a really powerful thing, and it’s important to have that as part of the training that you do to support the authors.
BS: And of course, once you hit the structured stage, there’s nowhere else to go. Step three is the final step, right?
GK: Oh no. There’s much more. We will be covering that in part two of this podcast. For now, thank you so much, Bill.
BS: Thank you.
GK: Thank you for listening to The Content Strategy Experts podcast, brought to you by Scriptorium. For more information, visit scriptorium.com or check the show notes for relevant links.
About the author
