This is an argument I often make with the Academic Outreach team of my STC chapter, especially considering that 3 officers were History majors as undergrads.
Information literacy is a big part of content strategy. Understanding what is truly important is a huge chunk of us helping clients decipher what is needed moving forward.
This is a great article about information literacy, which goes well beyond technology.
Okay, first of all, get your mind out of the gutter. It’s not that kind of discussion.
But it is a discussion about content strategy–because, you know, this is a tech comm blog.
Here’s where I’m going with this. I had a situation at work that prompted my thinking and further discussion with several other people about this topic, because I’m trying to explore how content strategists approach, well, content strategy.
For me, the way that I approach content strategy is starting with the big picture. You need to start with what are you trying to achieve as the end goal. Then, I look at the “adverb” questions to determine if that end goal answers them. What I mean by the “adverb” questions are:
Who is your audience? Who needs this content/information? Who is going to use it?
What content needs to be included? What is the goal of the person who wants to use it? What are they looking for?
Where are they going to find the content?
Why do they need the content? Why would they come to this site for that content?
When would they need this content?
How would they obtain this content/information?
How much content do they need to absorb to be satisfied? How much content is actually necessary for their needs to be remedied?
This doesn’t just apply to marketing content, which is usually the “model” for this. When working for my last job, I worked on a lot of repository-type sites for departments that weren’t internally selling anything. They just needed that right-info-right-here-right-now experience. That’s what all websites–or any content that’s put out there–needs to address.
But I slightly digress. So anyway, at work, we’re in the process of figuring out how to deliver some internal content that’s not really been formally organized, at least by modern standards. There’s lots of internal documentation, but for one topic I was researching, there were distinctly four pieces of content on the same topic, all written within the last two years, all of them correct, but no cohesion or indication that perhaps one was based off of another. When looking at the big picture beyond my own project, I realized that this would be a great project to apply DITA XML and create content chunks to start reusing information, provide consistency, easy updating, multiple outputs, etc. If you know about DITA stuff, you know why DITA is good for certain kinds of documentation, and I saw this as an opportunity.
Speaking with my colleagues, there have been two trains of thought. The first way would be to look at things the way I’ve usually looked at creating a content strategy–looking at the big picture, and breaking down things until you got it down to granular level, retrofitting current content as appropriate, weeding out what’s not needed anymore, reworking items, and doing a gap analysis to identify what additional content is needed. It makes sense, right?
The alternative view is approaching the strategy from the bottom up. Other colleagues suggested that we need to create and reconfigure all the detailed, smaller pieces of content, and build upwards towards that “big picture”, creating the “buckets” as we create and reconfigure the content we have. And if we happen to identify a content gap along the way? We’ll compensate or fill in the gap as appropriate.
Somehow, that latter just hasn’t sat with me very well. The latter, while it could be done, is a short term answer, in my opinion. It’s putting a bandaid on a wound rather than treating a condition that needs better control and having a long term treatment plan. The long term plan is “remission” and maintenance that can be sustainable and controllable. That’s only done when understanding the big picture and drilling down.
But maybe I’m wrong. Maybe I’m not seeing things clearly for that other perspective. For now, we’re working with the short term, bottom up strategy, with the goal that once we can get past the short term stuff, we can try to concentrate on the long term stuff (top down). Now, I understand that there are circumstances where the bottom up approach does work. For example, in knitting, it’s usually pretty common to knit a sweater from the bottom and work your way up. But even then, it’s about building the foundation. So, in my content top down, we start with the foundation, and figure out all the details.
I don’t know. My brain is topsy-turvy over this in trying to sort this out and make some sense out of the best approach. What does the tech comm and content strategy hive mind think? Include your comments below. Let’s discuss!
This is a big part of my job right now, and this is an excellent way to clarify the difference between what a thesaurus is and taxonomy is. Taxonomy really is about the organization of the content so that the hierarchy makes sense.
Another analogy that I’ve used–which I got long ago from Val Swisher of Content Rules is how one can organize a closet. You can put the pants together, the shirts together, and the jackets together, but you could put all the red clothing together, all the blue clothing together, etc. Neither way is wrong, as long as it makes sense and others can follow the flow.
Except with me these days, it’s more about pharmaceutical departments and procedures. Still, even with those topics, we need to scale it back all the way to what are the objectives of the website we’re building, and how do we structure the website so that users can find what they need quickly and easily. Start with the foundational basics, and build from there.
I highly recommended this article if taxonomy isn’t your strength. It shows that it’s not as hard as it seems.
Blogs provide great insight and are a helpful educational tool. But did you know the act of blogging can teach us something, too? Danielle Villegas explains.
Thanks to Phylise Banner, Jennifer Hofmann, and InSync Training for the opportunity to write this article for InSync Training’s blog, Body Language in the Bandwidth.
I based this article on the many years I’ve been writing here on TechCommGeekMom and other blogs I’ve written over time. I hope there’s helpful information for you here! It’s a quick read, and I enjoyed writing it.
Really, Father, my only sins are beer, donuts, beer, donuts, not knowing DITA, beer, donuts…
“Bless me, Father, for I have sinned! I am a failure in technical communications.”
OK, perhaps in many eyes, I haven’t been a failure in technical communications. It will be five years this spring since I graduated with my Masters degree in Professional and Technical Communication from NJIT. In many ways, that feels like it was just yesterday, and I’m still a “new graduate”. But with the change this year in my STC Membership that’s moved from “Student” to “New Professional” to “Classic”, I supposed I’m not anymore.
While graduate school gave me a good foundation to move forward, I learned very quickly that I needed to continue to educate myself. As I attended conferences and presentations, and paid attention to discussions in social media, I found out that graduate school lessons barely cut the surface. I’ve tried my best to continue my studies by attending as many webinars, conferences, and presentations that I can. I even took another university graduate certificate course on digital marketing, hoping to get some insight that might help me going forward.
However, in the end, I failed to do one thing that might actually boost what I’m doing as a fledgling content strategist, and thus, my confession: I needed to learn DITA.
For those of you who don’t know what DITA is, it’s the acronym for Darwin Information Typing Architecture, and it’s a commonly used method for creating structured authoring using XML coding. The idea is that documentation done using DITA methods will allow for single-sourcing for content elements, and equally make it easier to integrate that content into print or digital outputs in a super-organized, modular way. It’s a standard that helps because it’s generic to almost any system out there. Any system that can read XML can read a DITA document, for the most part. When moving from one system to another, the content can stay intact if done using DITA/XML methods.
I don’t remember learning much about DITA in grad school, other than understanding what it was in general as I explained it above. I never learned the details. In my work life so far, I haven’t needed it. It’s always been unstructured authoring. I try to take some small steps to create some single-sourcing content when possible in content management systems, but that was hard to do sometimes. One of my recent jobs made me realize that we needed some sort of structured authoring done, but I didn’t know how to go about it. We created our own coding tags to describe things going on in copy decks. It wasn’t the best, but it was better than nothing.
In the past year, I’ve tried to figure out ways to continue to improve my skills, and make myself more marketable as a content strategist/content manager. I talked to the leading experts in the field. (It’s one of the benefits of getting involved with the STC and attending STC events–you get to know these people personally.) And the one thing that seemed to come back to me again and again was that I had a good resume, and I have some great skills under my belt, and they knew that I was a good writer from this blog. The biggest sore spot in my skill set was that I lacked an important skill–knowing DITA and using it. And while I looked for jobs in my area that included DITA practices (I think I’ve only seen one listing in three years), I’ve been assured that if I could learn DITA, the remote/telecommuting possibilities could be much better for me. And since remote opportunities are my best bet right now, I have to do what I need to do to make that happen.
So, as the saying goes, I bit the bullet. Fortunately, the STC was promoting a course about DITA Essentials taught by Bernard Aschwanden, the Immediate Past-President of the STC, and the proprietor of Publishing Smarter. Bernard’s a great instructor, and he’s taking it nice and slow. One of the best parts of the course is hands-on experience, even if it’s in the simplest ways. That’s the way I tend to learn best–learn the logistics of how something is done, then I need to learn to do the work through trial and error. Last week’s assignment was particularly challenging for me. While I understood what I had to do conceptually, since I was also trying to familiarize myself with a few XML editors at the same time while applying what I wanted to do with my assignment, I got very frustrated. I sent in my assignment, along with notes about where I was getting frustrated and needing some guidance. Bernard assured me that all would be well, and asked me if he could use what I had turned in for my assignment for the most recent class. He also warned me to have a glass of wine ready while taking class, because I’d be needing it. Yikes!
I was told to prepare for the onslaught of big corrections to my DITA homework with a glass of wine. I took the suggestion seriously, thankfully.
The glass of wine was done by the end of the class, and yes, he ripped my assignment apart, but it was okay in the end. I knew there were problems with it, and he showed me where my original thought process was correct, but I didn’t know how to execute it properly. One of the mistakes I was making was my use of XML tags, particularly using the correct ones. While the XML editing apps all have guidance features to help you with using correct tags in certain situations, I still wasn’t using the best choices. Most of that was because I’m not familiar with what these XML tags mean, so I was using them at face value. For example, I was using a step example tag in part of my content, and Bernard understood why I used it, but felt that the way I used it was incorrect, and didn’t allow for cleaner coding. Okay, I can deal with that, especially when he demonstrated the correction.
So, as much as I’m struggling with DITA, I do understand the essential concepts behind it now. My biggest problem is learning how to use it beyond the most elementary tasks. I haven’t had any “real world” scenarios to date when I could implement and learn how to use the XML editors and use DITA practices in writing or rewriting content. I need to figure out how to find content and start having a way to truly play with something so that I can get the full experience of that trial and error to master DITA.
After the STC course that Bernard is teaching, I plan to follow-up with Scriptorium’s DITA tutorials as well, and see if I can learn some more about XML coding. I have a lot to do to figure this out, but I know that in the end, this will be a big skill that will make a lot of difference in how I approach content. The content strategist skills I already have acquired have helped me frame DITA much more easily than if I learned this with no prior knowledge. But, I can tell that I still have a long way to go before I feel that I’ve mastered this.
So, this ends my confession. I have needed to learn DITA. If it’s not taught in university classes in technical writing, it should be. I think it would have saved me a lot of frustration, and provided more opportunities for me sooner. If I can get a better handle on this, I’m hoping that I can start exploring how XML Editors can integrate with CMSs, like Adobe CQ. I’m not an Adobe AEM developer (I’m not a developer at all!), but I know how to create websites and pages with AEM, and hopefully I can start figuring out how to integrate those skills with DITA skills. I was told by one mentor, that would make me a very desirable job candidate, and I think she’s onto something. Of course, I need to brush up on my AEM skills, since it’s been a couple of years since I’ve used them regularly, but with all things, once you master them, it’s like riding a bicycle. You might be a little unstable at first, but you never quite forget how to do it once you get started back into it again.
Here’s hoping that in 2017, DITA will become a “bicycle” skill for me. I’ll go say a few rounds of the Rosary in the meantime for my penance.
(What do you think? How important is DITA in technical writing? I’ve heard some say it’s a passing trend, and others say that its usage continues to grow. Include your comments below.)
TechCommGeekMom 
You must be logged in to post a comment.