In episode 112 of The Content Strategy Experts podcast, Elizabeth Patterson and Bill Swallow discuss content scalability.

“As you start approaching a greater percentage of bells and whistles in your process, the more work it takes to get each bell or whistle in place.”

– Bill Swallow

Related posts:

• Content scalability: Removing friction from your content lifecycle
  

Twitter handles:

• @billswallow
  
• @PattersonScript
  

Transcript:

Elizabeth Patterson:                   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 content scalability. Hi, I’m Elizabeth Patterson.

Bill Swallow:                   And I’m Bill Swallow.

EP:                   And we’ll go ahead and kick things off today with a question. Bill, what does it mean if your content is scalable?

BS:                   Well, scalability basically means that you can increase the volume of your content, deliver to multiple different channels and add new channels as needed, translate into more languages and extend other facets of how you are developing and using your content without really bottlenecking the entire process of content production.

EP:                   Great. In order to have scalable content, you have to remove points of friction from your content life cycle. How can you go about identifying those points of friction?

BS:                   Well, one point is whether or not you have things essentially locked down, so things like templates or some kind of underlying structure that is enforcing rules on how the content is being developed. Otherwise, just making sure that you have some pretty rigid and… I shouldn’t say too rigid, but rigid, yet allowable processes in place and things that are repeatable.

BS:                   So that when it comes to developing a new piece of content, that you aren’t necessarily starting from scratch, that you have a game plan from getting from point A to point Z without stumbling and without adding any additional things that are unhandled by someone else in your content chain. Another area to look at is how reusable is your content and how smart is your reuse process? Are you copying and pasting across places, or do you have some kind of intelligent reuse via some kind of reference?

BS:                   In the former situation where you’re copying and pasting. You have to kind of guarantee that any time you reuse that content, that it is written in a way that is reusable. If you modify that language, then you suddenly have a discrepancy between where it’s used in other places. Likewise, if you have to then update the information, you have to update it in every single place where you’ve reused it or copied and pasted it. If you’re using intelligent reuse, that gives you a lot more flexibility.

BS:                   You can essentially reference one piece of content exactly how it’s written and use it wherever you want it to appear. You can also do a little bit of work with conditional text variables and other types of things to make the content unique for where it’s being used in any one instance, but you’re still reusing a singular written piece of content across multiple places. You’re are not duplicating it. Another one is to look at the publishing process and how hands-on that process is.

BS:                   If you are manually creating page flows, if you are doing some really high dynamic changes between different pages, moving images around, and so forth, your production schedule is likely, or your production process is not terribly scalable.

EP:                   Make it a little more difficult.

BS:                   Exactly. It makes it a lot more difficult. It takes a lot more time to produce. You might have something that looks extremely polished in the end, but it takes you many, many, many hours to get there.

EP:                   Right.

BS:                   On the flip side, if you have something that’s completely automated, as long as there are rules in place as to how the publishing process goes and how things are formatted as the publishing process is going, it’s a completely push button operation, in which case your content velocity for publishing has skyrocketed.

EP:                   Right. You might not have all the bells and whistles if you are taking a more hands-off approach. But if you’re doing everything yourself manually, it’s just not scalable.

BS:                   It isn’t. No. It’s not to say that you won’t have the bells and whistles, but there is. In any kind of automated situation, the more you bake into the automation, the… Basically as you start approaching a greater percentage of bells and whistles in your process, the more work it takes to get each bell or whistle in place.

EP:                   Right.

BS:                   Another area where you can remove a lot of friction is in your localization process, and that really comes down to how content is translated, how content is made available for translation, and essentially how you’re baking internationalization practices into your content development. The more that you have baked in at the beginning using good internationalization practices, the easier the localization stage and the translation stage… The localization process, including translation will be.

BS:                   This way, you are setting yourself up to use a lot of reusable factors and being able to reduce the overall number of words and so forth that you need to translate in a unique setting.

EP:                   Right. Identifying these points of friction and removing them is going to take a little bit of time, but it is essential to give you that scalable content. I want to shift focus now a little bit to web publishing. Are there any scalability issues when it comes to web publishing?

BS:                   Well, in terms of scalability, especially when it comes to technical content, web publishing can get a little hairy. The sheer volume of content that you’re producing could pose some problems. The technical content that you’re publishing through to let’s say a web CMS is highly templatized, highly standardized usually, and it’s very massive in scale. It’s kind of like drinking from a fire hose at that point. Traditionally, when you’re publishing on the web, usually pages are crafted one at a time or in small batches.

BS:                   Let’s say you’re doing a small support site, or what have you. Those pages, they might be templatized and you may have some ways of importing content into them. But by and large, they’re created manually. But when you’re talking about publishing a massive reference, for example, some kind of an API reference or product manual or what have you, you could be talking about hundreds, if not thousands of generated pages.

BS:                   It takes a very different approach to staging that content for the web than using a traditional web development mentality. The entire web system for that particular guide, for example, is generated all at once. There’s really no way to go in and hand massage things on the fly. It’s all being generated at once and ready to go.

EP:                   Okay. When we’re talking about scalable content, how exactly does the review and editing process work?

BS:                   Review and editing happens way behind the scenes. Taking a page by page review is fine, and you can certainly do that with the output that’s being generated from this collection. But you’d be looking at hundreds or perhaps thousands of pages at once to do this type of review. A lot of the review and editing really needs to happen on the source side and needs to be fixed before any publishing begins. Once any fixes are implemented, then the output can then be regenerated.

BS:                   This is true for really all output types when you’re talking about pushing out especially to multiple different channels at once. Whether it be PDF or web or some kind of API related repository, or what have you, all of that content is generated at once. If you need to fix it, you go back to the source and do a review cycle within the source before you get to that publishing stage.

EP:                   Okay. You mentioned earlier drinking from the fire hose. I want to come back to that for a minute. How do you best prepare for the fire hose of content?

BS:                   I like how you phrased that. When I talk about the fire hose, I mean, yes, there’s a lot of content going through. It’s not really an issue as far as publishing things like PDFs. Because in the end, you may have a fire hose of content going through this publishing process. But in the end, you still get a PDF file. But there are some big considerations for publishing to the web. You really have to have a framework for publishing a massive amount of content all at once available. You have to have the right targets lined up.

BS:                   Where is this content going to live? Is it going to get pushed to a staging area, and that’s going to get moved out into some kind of published area? Do you have a direct published pipeline? As soon as you click the generate output button on whatever you’re using, it generates the output and you can then go online and view it on your website. You need to think about how that’s going to work and what the pieces are that need to happen in order to get the content to the right place for that web server.

BS:                   You also have to have the right metadata in place, both in the content and in the web CMS, to make sure that as content is being received, as it’s being generated, that it’s being assigned the right metadata, both for search, for personalization, and really any other way that the content is going to be used on the site. If you have let’s say a customer portal and everyone has their own login, they’re probably assigned a certain user group. They’re probably assigned other metadata, such as what their client name is.

BS:                   You can provide easy access to perhaps the products that they have versus the products that they don’t have, so that they are free to just search your repository and pull back all the results that pertain what they own versus what somebody else owns. And other things that facilitate how the content is going to be used on the web. You also have to make sure that where this content is being published and where it’s being shown on the web, that it has all the right UI elements built around it. You might have some kind of…

BS:                   Frameset is a bit of an old word, but some kind of a wrapper UI that might have certain type of branding around the content in addition to the content itself. Perhaps another layer of UI elements, buttons, fields, so forth that they can use perhaps to refine a search or even to provide a search console that they can use to search through the content that’s being provided to them. There are a lot of things to really think about, and you need to line all of that up before you push that content out to the web.

BS:                   Otherwise, you might have a rather unruly mess of files to then go ahead and wrangle and apply each metadata piece and each personalization piece and assign other aspects of the web experience to each individual piece of content.

EP:                   Right. Definitely take the time and make sure you have those elements in place and things set up correctly so that you’re prepared for this.

BS:                   Exactly. Measure twice. Cut once.

EP:                   I think that is a really good place to wrap up. Thank you, Bill.

BS:                   Thank you.

EP:                   And 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.

The post Content scalability (podcast) appeared first on Scriptorium.