Search a title or topic

Over 20 million podcasts, powered by 

Player FM logo
Artwork

Content provided by Larry Swanson. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Larry Swanson or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://podcastplayer.com/legal.
Player FM - Podcast App
Go offline with the Player FM app!

Michael Priestley: Creator of the DITA Structured-Content Standard – Episode 192

31:06
 
Share
 

Manage episode 424640633 series 1927771
Content provided by Larry Swanson. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Larry Swanson or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://podcastplayer.com/legal.
Michael Priestley Twenty-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 LinkedIn Video Here’s the video version of our conversation: https://youtu.be/1BGNQx1wcSU 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,
  continue reading

134 episodes

Artwork
iconShare
 
Manage episode 424640633 series 1927771
Content provided by Larry Swanson. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Larry Swanson or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://podcastplayer.com/legal.
Michael Priestley Twenty-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 LinkedIn Video Here’s the video version of our conversation: https://youtu.be/1BGNQx1wcSU 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,
  continue reading

134 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Copyright 2025 | Privacy Policy | Terms of Service | | Copyright
Listen to this show while you explore
Play