Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Spotify | Android | TuneIn | RSS
Michael PriestleyTwenty-four years ago at IBM, the company’s commitment to user-focused content led to the decision to develop a standard way of structuring content so that it could be used in multiple channels.
Michael Priestley was uniquely positioned to guide the team that created the technical approach to the corporate standard that would ultimately become DITA, the Darwin Information Typing Architecture, a few years later.
We talked about:
- his current role as Principal Information Architect and Taxonomist at avalara.com
- the DITA origin story
- how his IA and writing backgrounds and familiarity with XML
- the concept, task, and reference information typing at the core of the DITA standard
- how the notion of specialization led to the addition of “Darwin” to the information typing architecture they had developed
- the role of XSLT in the development of the DITA standard
- how their focus at IBM on user needs – specifically the need for modular content organized around topics delivered in multiple formats – resulted in a standard that also permitted content to be re-used in other ways
- how the need to organize content at the topic level both serves user needs and creates an optimal content-element size for re-use
- the three C’s of DITA: content, collections (DITA maps), and classification (metadata)
- how the technical writing heritage at IBM facilitated the introduction of structured authoring there
- his happiness with the success of DITA to this point, and how the challenges going forward mostly involve people and the organizations they work in
- the wide range of content roles he held at IBM in his 24 years there
- his ongoing preoccupation with always staying connected and working with other writers and content disciplines
Michael’s bio
Michael is the Principal Information Architect and Taxonomist for avalara.com, focused on the intersection of semantic content, user experience, and SEO at the enterprise scale. Michael has experience working with and across marketing, sales, training, documentation, and support content, coordinating requirements, and delivering common processes and standards. He was named an OASIS Distinguished Contributor for his development of the DITA content standard.
Connect with Michael online
Video
Here’s the video version of our conversation:
Podcast intro transcript
This is the Content Strategy Insights podcast, episode number 192. If you’ve ever worked in or around support documentation or technical communication, you’ve probably come across the DITA standard for creating and managing structured content. Michael Priestley developed this standard during his long tenure at IBM. DITA – an acronym for Darwin Information Typing Architecture – arose from the need for Michael and his colleagues to help users of IBM products by sharing the same topical content across different channels.
Interview transcript
Larry:
Hi, everyone. Welcome to episode number 192 of the Content Strategy Insights Podcast. I am super delighted today to welcome to the show Michael Priestley. Michael is currently the Principal Information Architect and Taxonomist at avalara.com, the big tax software services company. But welcome to the show, Michael. Tell the folks a little bit more about what you’re doing these days.
Michael:
Sure. I’m reorganizing a website, which is my weirdly happy place. It’s funny. I spent most of my career at IBM in a lot of different content-related roles, but the last thing I was doing there was working on their website. It was a challenging, large website. I came up with a number of strategies. Then I got the opportunity to potentially execute them in a different space with a different set of webpages and it was a really good opportunity. It’s a really supportive team. They’re excited. They support information architecture. They support thinking about content, got a great executive team, great set of coworkers. So, yeah, it’s been an exciting couple of years just working on menus and metadata, and it’s satisfying.
Larry:
Well, I think that alone will warm the cockles of the hearts of many of my listeners, because that’s where we’ve all been a lot, building. But you’re doing it at a scale like you mentioned you were at IBM for a long time. One of your many accomplishments there was the introduction, and this is why I wanted to have you on the show today… One of your many accomplishments there was… I don’t know, is it fair to say you created or you at least codified what’s now called DITA, the Darwin Information Typing Architecture for structured content? It’s hard to say where to start, but can you do a short version of that origin story of DITA?
Michael:
Yeah, sure. So, yeah, I feel like we need one of those musical, it was a time of war, Warring Kingdoms or something. It was a really interesting time in IBM, technical documentation. We had a whole bunch of writers. We had what was supposed to be the corporate standard, which was an SGML standard IBM ID doc, but there were a lot of groups that were not using it. My group is actually one of the groups that was not using it. We had tried it for a while and then bounced off and gone to using just plain HTML, authoring directly in HTML. We had developed our own little toolkits to do extra fancy things with it, and we were very happy with it. Every year we got an exemption that allowed us to keep doing that, instead of moving into SGML.
Michael:
So, they set up a new initiative to do the next version of the corporate standard using the introduction of XML as a standard, as the excuse to revisit the architecture. I got to be the rep for the IBM at that time, Toronto Lab. As luck would have it, I also had some XML familiarity. I was working on a product that used a lot of XML internally. I had figured out how to write XSLT to do little scripts with our HTML. So, I was very excited by that opportunity and it ended up involving… I was supposed to be on there as an SME or representative of the user base because I was a writer and I was an information architect. I ended up actually leading the work group within that effort to codify the DTDs.
Michael:
So, in that respect, I can absolutely say there are key parts of DITA that I can say came out of this head as opposed to elsewhere, but I also want to be clear that there were a whole lot of really good cooks in that kitchen and also there were a lot of things that people attribute to DITA because they learned it from DITA but that pre-date DITA. The concept, task, reference thing was already a standard within IBM. People were supposed to be doing that in the SGML standard. I was part of our big book of guidelines for writing technical documentation called Developing Quality Technical Information. Yeah, it’s been a while since there’s been a new addition to that, but at the time, it was one of the really great books for technical writing.
Michael:
So, going into that teams with representatives from across IBM, all these different communities, I think I ended up being a champion for that writing mode and for the need to support that concept, task, reference information typing, but there were a lot of other pressures in there. The dawn day was I think my antagonist and then collaborator, he was not bought into that way of thinking about content and had a vision in his mind of a very simple, pure architecture of nesting divisions that allowed for some very straightforward, very scalable markup situations.
Michael:
I eventually figured out a way and I do get to clean this one, the simple model of specialization that allowed us to say, we can actually think of concept, task, and references being specialized from a common generic ancestor. We can further specialize from concept, task, and reference or from topics especially to create any set of information types we want that will all have these same basic characteristics of a title, potentially a short description that was something you could leave out if you wanted to, but then a body with content and you can use a specialization to decide what you’re going to allow and where you’re going to allow it.
Larry:
At that time, that notion, it was those three things like concept, tasks, and reference materials. Did you come up with the innovation of putting topics on top of that as an organizing way and was that kind of a way to not appease but address the concerns of your collaborators?
Michael:
Exactly, yeah. Credit where it’s due, I think I had originally gone in with the goal to do specialization, but really only thinking of the reference arm of that because I knew we had a lot of different specialized reference vocabularies for command line documentation or API documentation, various realms of reference information. So, I knew I wanted to do it there, but moving that idea up a level and bringing in the pure notion that Don had of the simple nesting but extensible nesting and saying, “Okay, let’s take that and then overlay it with a concept, a typing architecture, an information typing architecture.” That was the first breakthrough to let our two groups work together and actually have that common ground.
Larry:
Because DITA stands for Darwin Information Typing Architecture. Is that where the name comes from, was in that era?
Michael:
Exactly, yeah, it was the idea that it’s about information types, but it’s not just a set of information types. It’s an information typing architecture. There was a lot of argument, what’s that first word going to be? The notion of specialization tied conceptually to the notion of genetic or Darwinian specialization. So, we borrowed Darwin’s name and slapped it on there, and I hope he forgives us.
Larry:
That’s right. A random aside, that’s about the era when I was transitioning from college textbook publishing to digital work, and the last book I published was the General Biology book by Neil Campbell, which was the bestselling book ever in that wheel. It was many books at the time, but specifically and deeply focused on adaptation. So, it was in the air apparently in that era.
Larry:
But hey, but I want to backfill just a little bit too. You mentioned a couple of acronyms that I want to make sure some of folks who aren’t in the technical documentation world might not get like DTD. That’s just the document type definition. That’s a level above what most people see when they’re working with an HTML document, just to say what a document is, correct?
Michael:
Yeah, so yeah, exactly. I can’t remember now if there is a formal DTD for HTML, there used to be, but it is a document that lays out in a very specific syntax, the rules of a markup language. So, here’s what the root element is going to be. Here’s what’s allowed under the root. For each element, what are the attributes that are going to be allowed? What are the child elements that will be allowed? That whole set of rules and the content models of each part of the document and then building up to the document as a whole.
Larry:
Yeah. Alongside of that, you also mentioned XSLT, which is a really interesting thing because it’s a thing that’s built with itself to do recursion. So, it’s recursive all day long. Can you talk a little bit about the role of XSLT? Because Darwin Information Typing Architecture is a specific standard to format XML and the whole point of XML is that you can do stuff with it, and that’s what XSLT does, correct?
Michael:
Yeah, I want to make the distinction between the markup standard versus the processing standard, because the processing standard isn’t actually a standard really. I mean, what people think of as the processing, those set of XSLT transforms are not part of the standard. They’re part of the open toolkit or lots of people have done their own versions of them, not always in XSLT, but the core standard of DITA processing agnostic. We don’t say you got to use XSLT. We don’t say how you’re going to process this stuff. We just say this is the intent of the markup and these are the rules for the markup. There’s a few places where we talk about if you’ve got an attribute that one of the mechanisms is reuse of a single element.
Michael:
Like you say, I want to pull this paragraph from someplace else, or I want to pull this sentence or word or list item or whatever from someplace else. We say how that gets processed because there are particular rules in DITA to make sure that running that is not going to bust open a processing model and suck in some giant table into the middle of your title that will break things. So, we have some rules there, but generally speaking, it’s very neutral. Then the XSLT, we actually tried to contribute that to the same standard organization because we had developed them within IBM. The same group developed the document type definitions and the processing code, but they were like, “No, we only own the standard, not the code.” So we set up the open toolkit as a source forge project to be the recipient of that transfer of IP.
Larry:
Interesting. Yeah. So, a minute ago, I want to jump to something you said just a minute ago about reuse, and we were talking just before we went on the air about my assumption that the whole genesis of DITA was around the need for reuse. You’re like, “Well, kind of.” Can you talk about the subtle difference between what I assume that I think many people assume about the origins of DITA to be mostly about reuse, what you actually created it for?
Michael:
Yeah, sure. So, again, going back to that concept, task, reference distinction, the best practices within IBM for writing documentation as a book or as a webpage, it was the same standard and it was content needs to be modular and it needs to be built for retrieval and understanding. I saw a little screen flicker there. Am I still coming through okay?
Larry:
Yeah, you sound good. Yeah.
Michael:
Oh, good. Okay. So, our goal was to have an architecture that reflected that use model. We want to make content that is organized around topics that people are looking for and helps them solve the problem they’ve got or understand the thing they need to understand or look up the thing they need to look up. So, organizing content that way was in service of our best understanding of user needs, and then the fact that that also made content reusable was a bonus. It was an effect.
Michael:
I mean, it was a thing that we used to get into arguments at the time because there were lots of people like this is a limiting use model, this insistence that the topic in DITA, which is like your section or it’s a title and some content that describes how to do a task or explains a concept, or documents a piece of code or API or something, the idea that that has to be the primary unit of reuse. We had people with databases built to be deconstructing documents down to the sentence level, and they were like, “You are so limited. We are so much more powerful than that. You are so parochial in your focus on this meaningless unit.” I was like, “The unity use is the unit of reuse.”
Michael:
You start reusing everything at the sentence level. You’re going to have to validate every instance of reuse because those sentences don’t form the same sense in different collections. But if something at the topic level, if someone’s flipping through a book and hits that topic, it needs to make sense on its own because they’re not going to read the previous three pages to make sense of it. At least they shouldn’t have to, right? The content needs to be organized to support their moment of need, not the author’s narrative exposition instinct. So, that idea of we need the content to be organized and chunked to support the user, and once it’s organized and chunked, you can reuse those chunks because they’re carrying a bunch of their information with them.
Michael:
They’re likely to be useful in other contexts with a few simple switches like maybe we swap out a variable. Maybe there’s a sentence we need to swap out or do something, but 90% the same. There’s a lot of cases like that where you can do that, especially across channels. Like if you’re talking about content, we want to embed in a help system versus content we want to publish on a website versus content you want to publish in a book. A lot of the times, it’s the same paragraphs, it’s the same sentences. If you mess with that order, it stops making sense. But if you preserve that order, you can combine them in a lot of different ways, very usefully.
Larry:
That ability to sequence things, that’s the mapping function within DITA, right? Which is the thing that is, I guess, conceptually alongside the topical and structure stuff and the mapping assembly stuff. Is that the correct way to think about it?
Michael:
Yeah, I used to think of it sometimes in terms of three Cs. We had the content or chunks of content, and then we had the collection of that content via maps, and then we had the categorization or classification of that content using metadata. That was the three big tasks of working in DITA.
Larry:
Yeah, interesting. Hey, one thing you just said too, a minute ago, you mentioned the reuse follows use and that focus on usability. It reminds me of back in that era, what we call help stuff now was called user assistance then. I wonder, was that lingo common at IBM and is that where that notion of use as the fundamental driving principle behind this came from?
Michael:
I don’t know if that’s where the fundamental principle came from. I think we’ve been focused on the user in lots of different ways across different parts of the organization, but certainly user assistance, that was one of the names we called ourselves at one point. We were technical writers, we were information developers, we were user assistance writers, we were content developers. There were some other words. I lost track at some point.
Michael:
So, yeah, user assistance was definitely in that mix. Certainly, I think thinking about online help as one of the contexts in which your information is going to be consumed and needs to make sense was definitely like books, the web, help were probably the three main use cases for DITA as we were setting up the architecture, making sure that we could produce content that would be useful in those three contexts.
Larry:
Interesting. To have it ready for each of those, it gets back to that… I wanted to revisit something you said too about working with writers, working within these systems, the content creators, the authors. Because there’s this authoring difference that needs to happen, writing to these use-specific topical chunks versus writing a narrative script of like, “Hey, here’s how you operate this machine,” or “Here’s how you fix this problem.” Was there a lot of work to be done around working with the content creators in the rollout and adoption of this standard?
Michael:
There was, but not as much as you might think. Like I said, we already had the developing quality technical information book that was already talking about writing content in chunks organized around concept, task, and reference. So, a lot of these concepts were already familiar, and it was suddenly we were giving them a tool that supported the training they’d already been given. So, for some writers, it was very welcome. I got writers who were just deliriously happy because we were finally giving them a tool that worked the way they worked. We had other writers who had never really accepted that direction from the DQTI book. So, they were already resistant. You know what I mean?
Michael:
They were already digging in their heels against the direction they’ve been given and the old tool let them get away with it and the new tool didn’t. So, they hated the new tool, but some of them came around and some of them never did, I’ll be honest. But it certainly wasn’t a battle that we were fighting on behalf of DITA. I think it was a battle we were fighting on behalf of our corporate standards, which were genuinely in the service of our users’ needs. DITA was a tool in that ongoing education. It was a tool that was making it easier to do what we thought the right thing was and what I still think the right thing was, which was to write this content around what users are looking for and what they’re trying to do, rather than writing a big cohesive needs to be read in one piece document.
Michael:
It’s funny, that whole idea of we need to write in chunks, that felt very natural to me. I think my first job at IBM as an intern was writing online help and the idea that we need to write this stuff to make sense in the moment that it’s needed. Then most people are not going to sit down before they use a program and read everything back to front. As a matter of fact, I was told to do that at one point in my internship, and it was the worst week of my life just going into work every morning with a huge printed out manual and trying to read stuff without using it and without applying it and without going back and forth between the task and the thing explaining how to do. I could not stay awake. It was so hard. So, yeah, that really drove home to me.
Michael:
This is not the way people normally use these books. You don’t use the books separate from the system. You don’t use the help separate from the system. If we’re talking about documentation of a product, then it lives in the context of the product’s usage. There’s a small amount that will be useful before the product, but most of it is for during the product. Once I started being challenged on that, this stuff that was part of the water I had been learned how to swim in, I went back and discovered that Jack Carroll’s Minimalism Beyond the Nurnberg Funnel was all about this.
Michael:
His first example was taking the Smalltalk users guide, which was explaining to programmers who had never done object-oriented programming before and had never done small talk programming before, what object-oriented programming was. His answer was this whole huge conceptually new paradigm is best explained by chunking it out into bits and then relating them in clear progression with as little information as possible between them and the practice that will then inform their next question. So, yeah, as it turned out, we got it right, but we got it right instinctively and then found the literature that backed us up and found that other people had also gotten it right before us, if that makes sense.
Larry:
No, it does. It sounds like just being at a place like IBM in that era that it’s probably not unreasonable to trust your gut instinct about something like that. I love sharing the story of the history of this stuff, but I want to jump to the present a little bit because one of the things that proves the enduring validity and usefulness of DITA is that it’s still widely used and it’s still useful to this day. It’s grown and evolved a bit, but do you take, I don’t know, not pride, but there must be some satisfaction in seeing your baby into its adulthood out in the world now.
Michael:
Oh, completely. I’m so happy. I’m happy it’s still useful. I’m happy it’s still growing and changing. I’ve still got some connection to it, and I talk regularly with folks who are using it. I don’t use it myself. My team doesn’t use it, but I’m going to never say never, right? I would love to still see the opportunity to build some cross-disciplinary bridges, figure out how marketing and TechCom will work together, how websites built on AEM or with structured content can be working with DITA as another source of structured content. I think there’s a lot of interesting stuff and interesting opportunities there, but I’ll just be frank through all of this, I think the big challenges are not technical.
Michael:
Those are relatively solvable, and I think we’ve got a good set of all the people who are fighting for structured content are on the same side in this. DITA is just one of the flavors. When people get into fights about this standard versus another, it’s like we’re all fighting the same fight. It’s us against WYSIWYG. It shouldn’t be us against each other. If we can define the standard well enough to allow interchange, then I’m happy. But the big challenges are always political. I don’t mean that in the sense of person versus person. I mean in org chart versus org chart.
Michael:
You’ve got one set of group with a set of performance indicators and budget that are aimed at one set of success criteria and another group that’s got a different budget and a different set of reports and a different set of success criteria. Figuring out how to take success from one and lend it to the other or find where is the common benefit to the company funded, that’s a political challenge, but it’s one that’s very hard to fight from the grassroots. So, that’s I think why you see siloed content continue, not because of the inherent siloed nature of the content, but because of the siloed nature of the org charts that fund they’re funded.
Larry:
That reminds me of another thing we talked about before we went on the air. I was telling you about a meetup that we convened in Amsterdam a few months ago where we had the theme and the topic was structured content. We had somebody from your family, like the DITA person, and then we had a guy who runs a big headless CMS at Ikea. We had a marketing person from Booking.com who works with structured content in a marketing context, and then we had an enterprise content strategist also in that meeting. The funniest thing was just to what you were just saying, we need more assemblies like that, but also, you’ve done most of that stuff in your career, right?
Michael:
Yeah. I can’t say I’ve run a headless CMS, although I will say early versions of IBM’s knowledge center were basically very similar. It evolved away from that towards a static publishing model, but the initial paradigm we were shooting for was, I think, very similar in principle and in philosophy. It was just at the time, we couldn’t get the performance to scale and that wasn’t about the markup. That was about the technology at the time. But yeah, I started in technical writing as a technical writer, then an IA, then DITA came along, and I was a developer for that briefly. Then I was the lead strategist for our technology strategy across IBM’s documentation.
Michael:
Then that moved into an enterprise content role where we were trying to connect and find allies in training, sales, marketing, support, and work across all of that. Then I ended up landing out of that into a marketing role where I spent the last part of my career at IBM, including at the end, the taxonomy and IA work there that led to my IA and taxonomy work here at Avalara. So, yeah, I definitely see a lot of through lines there in terms of the things that made me like working in each of those things and the things that I was interested in each of those spaces were very similar.
Michael:
I think there’s a lot of basic principles and basic approaches that should be cross-connectable. Again, the main challenges are in the org structure of the companies involved rather than in any inherent difference between the types of content or the platforms involved.
Larry:
Cool. That’s why I brought that up because I’ve given up on silo busting, but I believe in silo spanning. I think you’re just the guy to at least model it, if not do it. But hey, Michael, I can’t believe it we’re already coming up close to time, but before we wrap up, is there anything last, anything you’d like to revisit from the conversation or just want to make sure you share before we close?
Michael:
Yeah, I guess I’ll say one thing just to make explicit, for me, DITA and my contributions to DITA came from the space of someone using tools every day to address content challenges, to try and make life better for our users. That was my driving motive. I was helping make tools that I would use myself, if that makes sense, which is always the easiest thing to do. It’s why open-source tools for developers are always so good compared to some other use cases.
Michael:
But I feel like that’s what brought me to where I am now in the marketing realm, is that urge to get back to the space where I’m learning new things and understanding new things and then hopefully getting to the point where I can start to generalize. Coming back to that basic promise, I think there’s some stuff that is common across all these different realms, and it’s an ongoing preoccupation of mine to want to connect with fellow authors, fellow content discipline people across all the different parts. We all share a part of that user’s journey. Let’s try and work together to make their life better because that’s what we all want.
Larry:
As a former book editor, I want to make you write the book, Unified Theory of Content Practice or something. But hey, one very last thing, Michael, if folks want to connect with you online or follow you, what’s the best way to connect?
Michael:
Yeah, LinkedIn is probably the best way. From a LinkedIn perspective, it’s like linkedin.com/in/michael-priestley-ca because I’m the Canadian one. That’ll find me there. There’s a lot of us floating around, but yeah. Yeah.
Larry:
One and only Canadian Michael Priestley.
Michael:
As soon as I say that, I know there’s going to be another Canadian Michael Priestley glaring at me, side eyeing me from somewhere on the internet right now, but yeah.
Larry:
Well, he won’t be on this podcast, I’m sure. So, anyhow. Well, thank you so much, Michael. This was a really fun conversation.
Michael:
Thank you. I really appreciated the chance and I love chatting with you.
Leave a Reply