Ryan: Welcome to 10-Minute Tech Comm. This is Ryan Weber at the University of Alabama in Huntsville, and I’m pleased to welcome today’s guest.
Julia: My name is Julia Pond, and I am currently working as an information architect for Trilyon, whose client is Deloitte, on a content migration project from a legacy XML to data XML. So that’s why they hired me, because I have expertise in data. And I started out with DITA when I was working as a technical writer at Oracle, and I started sort of following it and trying to apply it to my current assignment there, which was really kind of where my interest in IA started. And since then, I have implemented DITA in a small company. That’s how I became an information architect.
Ryan: I invited Julia on the podcast to talk about her work as an information architect, about the way that she organizes huge sets of data, about how she understands the ways that content moves through organizations, and how she uses tools like XML and DITA in order to improve her work. I really hope you enjoy the conversation.
BEGIN INTERVIEW
Julia, welcome to the podcast. I am very excited to have an information architect on so that we can hear about your work, what you do, and your role. And you know, you briefly mentioned this in your intro, but I would love to know a little bit about your current position as an information architect and what that role looks like.
Julia: Yeah, great. You know, they hired me because I had expertise in DITA. But actually, this role doesn’t demand so much new architecting things in DITA as sort of understanding DITA as a target and how to migrate content from another legacy XML schema to DITA.
And they have a lot of content, auditing and accounting content that’s used by those practitioners. And they’re putting it into a new CMS, SDL Tridian Docs, which is DITA, out of a couple of different older CMS systems. And also the website where they’re displaying it for use is new. So everything is new.
So this has been a really good assignment for me. It involves new learning because when you get in a business setting and you see a content pipeline and everyone who’s gathered around it from the developers to the content owners to the ultimate end users, it gives you a good insight as to what really goes on in the real world.
And so, you know, they have a content transition system that we use to bring the content into the new system. But as IAs, we create content samples so that the developers on the front end can test. Sometimes there are new structures that we devise in the DITA architecture. We write specs for the developers to tell them what their code needs to do to bring it into DITA properly. And then sometimes there are problems with content that we troubleshoot. And that’s tricky because someone will see it at the front end, but it could have actually happened in the source content, how it was authored.
And in fact, I’m in the midst of debugging a table display issue that I believe originates in the authoring, but I have to prove that in order to tell the vendor, here’s what you need to do. I mean, it’s interesting. It’s very, more so than I thought it would be. And sometimes, of course, you know, it’s a drudgery. As an XML jockey, you know, you find out that a lot of it is things that you can’t script away, that you have to kind of woodshed and get your head down and, you know, look at a lot of content for one certain thing or another. But, you know, in all, it’s interesting.
Ryan: One of the things that you mentioned was this idea of, it sounds like you get as an IA, kind of this like global view of the content and the content pipeline that maybe individuals in that system don’t get. Is that one of the things that your role brings? Yeah. Can you talk a little about that?
Julia: As IAs, you know, we’re kind of, we are the ones that see everything and can anticipate everything. So we’re kind of, when it comes to debugging and fixing things, we are the rockstars. And, you know, it having that view, not only for that reason, is essential as an IA, because the content that you’re working with gets consumed by people and systems all throughout the pipeline. And so the systems need certain metadata. The people need for it to look a certain way or to be able to manage it a certain way. And that’s the other thing.
Bob Boiko, who was one of my professors at the iSchool, he taught the XML XSLT class. He always looked at content and IA in terms of three things, collect, manage, publish. And so you need to be aware of all of those things as an IA.
Ryan: And how does each of those things, like what does each of those roles look like as an IA? Because I like that. It’s collect, manage, publish.
Julia: Collection involves bringing the content into the system, either authoring or in an automated way with a script, you know, kind of getting it there. That’s a bubble or a bucket that you could put a lot of activities.
Manage is things like versioning, translation, you know, all the things that the business needs from the content. And then, of course, publish is, and of course, the power of XML is that the content is separated from the publish. So with publish, you have all of your different ways that the end end user looks at it. And sometimes that’s multi-channel for different uses, PDF, HTML on a website. You kind of have to have a hand in all of those things or be aware of all of those things, I guess I would say.
Ryan: Well, and you have, related to this idea of kind of getting the global picture, you have a variety of audiences and users, it sounds like, including, you know, internal people and external users, but also, you know, the systems, which we don’t always think of as kind of like an audience or a user of this data. So how do you kind of accommodate the needs of all of these different stakeholders?
Julia: Well, you know, this company has been very, very good about the user experience of the website. And so, fortunately, we don’t have very much to say about that. But there are things that we do in the XML in terms of output classes and whatnot to appease, so to speak, the consuming systems. When there is trouble with content, even in the beautiful UI that they have on the website, the end users will see that and they want us to find out, you know, why that is. So, I mean, is that a good answer?
Ryan: Yeah, that’s exactly what I was asking. And that leads to another question, which is, do you have any kind of interaction with those end users, either directly or indirectly?
Julia: Sometimes directly, particularly on the project that I’m on now, content owners who worked with the prior systems for external standards content, in other words, content that isn’t authored within the company. And so, it’s coming in from a third-party vendor. And what we want is to be able to bring it in pretty much untouched by human hands.
So that means that all the things that we fixed before with the old systems, we need to push those out to the pipeline. And so, like in the past, when I would have told them how to fix this table or whatever, we now have to tell the vendor, we have to specify, you have to transform it this way because the users are seeing it, you know, this way and they don’t like it. So, we’re working with them, different other things about devising a system for linking content together and providing access at the paragraph level using what they call a friendly ID. That is an ID that they can author by section number dot paragraph number. We find ways to inject that into the XML, stuff like that.
Ryan: So, finding ways for all this content to kind of get along and be uniform in particular ways that are useful.
Julia: Right. And to, yeah, to make it useful for the practitioners.
Ryan: What kinds of strategies do you use? I mean, you’ve got data coming in or content coming in from the outside. You’ve got an internally authored content. You’ve got a lot of different content that all needs to kind of make sense together. And what sorts of approaches or strategies do you use for organizing and managing such a huge range of content?
Julia: Well, this content, that question has kind of already been answered in this organization. And I’ll briefly touch on how that is.
There are the two broad categories are auditing content and accounting content. So, that’s two big groups of practitioners. And so, those are shown in separate places on the website. And that kind of shows you how, if faced with a complete ground floor architecting of a huge mass of content, how you would start to think about it and think about it in terms of lines of business, who’s going to use it, how it will be used.
I mean, let’s face it. That is daunting, but it’s never as new as you think it is because that business has been going on for a while and they did something with content. Look at what was done in the past. Look at people who design huge databases. They model that with entity relationship diagrams.
And, you know, database design is actually a very instructive thing to look at as an IA practitioner, because, I mean, there’s nothing new under the sun, right? You need broad categories. You need to define relationships. And so, that’s been done in the past.
Ryan: So, looking at the work that other people have done in terms of defining both the content and the relationships between it.
Julia: Right. You know, think about how content moves through an organization. In the past, we didn’t have a lot of the automation and the things that we have now, but content has always done that. Moved through the organization. And of course, I think always, always, always, always talk to people first. Study what people do first. And you’ll never go wrong.
Ryan: Well, great. This is, you’ve been kind of hinting at one of the questions that I wanted to ask. You mentioned, you know, studying database management. You mentioned studying how people use information. What kinds of skills are important if you want to get into information architecture?
Julia: I think a lot of technical writers really have these skills. I mean, this is sort of the career path. We all know that. But no matter what you’re writing about, it would be good to, you know, be interested in scripting or programming at some level. Understand how content is transformed. XSLT. Things like that. You know, be curious about everything. That’s kind of more of a trait than a skill, I guess.
And here’s what I always did as a technical writer. Look at the employment ads and see what skills people are asking for. And make sure you get those skills.
Ryan: So start at the end goal of, you know, what do these people want? And then how do I get from where I am to there? Yeah.
Julia: Exactly.
Ryan: Yeah. So you’ve talked about this and I’d love to hear just a little more because you came from tech writing and you moved into IA. Can you talk a little more about that relationship between tech writing and IA?
Julia: Oh, sure. When I worked for Oracle, my big assignment, I did a lot of different things, but my big writing assignment was to document a three tier data center architecture that we used to customize for different clients. And so of course, with each configuration, we gave them a custom manual. And so there were things that didn’t change, right? The database, the middle tier, which was a Java and a listener and things like that. And then the, you know, the identity management piece.
So there were things that didn’t change, but there were things that did. And that meant that we were sort of repackaging and re-archiving the same pieces of information again and again. So that meant too, that if something changed in one of those so-called unchanged pieces, you had to go back and find it and make the change with the database, you know, just different things about the database offering could change and you would then have to, you know, go back. And so when did it came out in 2005, I started looking at that and thinking, man, that would be a great thing to be able to reuse pieces stored in one place in all the forward-going publications. And so I started to study that and kind of, just kind of seeing what the promise of DITA was. And, you know, to me, it was always, well, it makes technical writers lives a lot easier. Of course, that’s not a way that you can sell it to the C-level, right?
Ryan: Right. Sure.
Julia: That was why I was excited about it. And then around that time, I was looking for something to do or learn. And I became aware of the MSIM program at the UWI school. And they had an executive program that you could do that on the weekends for two years and get a master’s degree. And so Oracle had a education reimbursement program. And so I signed up and did that. And I used to drive or ride the bus from Portland to Seattle every weekend for two years. And so I did that.
And, you know, and of course, that was, as I told you before, I would have taken that program, you know, just for the curriculum alone, because it was so interesting. And so that was a lot of fun. And so after that, I kind of, I would always be willing to do technical writing and writing skills are important in all of these. I was real popular because I was the technical writer. And when you had to write a group paper, I was always a good one to have on the team.
Ryan: The other classmates were like, we need her. We need Julia in the group so that she can write our paper.
Julia: Yeah. So, you know, that was kind of the turning point for me. And I thought of myself as an architect from then on. And I left Oracle because I wanted to implement data in a business setting. And so I took another technical writing job at a different company. The management in place at that time was interested in doing something different with documentation. And I was hired to document an API offering. And so I did that in DITA, concept, task and reference.
I customized the DITA toolkit to use the code highlighter that I wanted to use and, you know, modified the CSS and the output to create branded output. And then, kind of as time went on, it became necessary to version that. And there were different, you know, different reasons to have different versions. They did a mobile SDK for, oh, I don’t know, iOS, Android and another platform. That was a case to use filtering and always keeping the underlying information that didn’t change the same.
And they also had a set of query parameters that I created a little schema in the reference topic domain for. We were able to reuse those query parameters in marketing and engineering docs, both. That was what I did with DITA.
Ryan: So you really are like a DITA success story in a way it sounds like. Like the promise of DITA was realized in your life.
Julia: Yeah. And it’s sort of funny because my whole career was really like that. I got the opportunity as a technical writer. My very first technical writing assignment was, I was a data entry clerk at a public utility that ran a nuclear plant. And I got into the technical writing group from there. And I was lucky to be mentored by a human factors analyst. And I got to retrofit the user interface of one of the systems I had used. Then too, I was on that team when they tried to stand up a database at the nuclear plant, a master equipment list database. That’s where I learned about kind of database design. So really everything I got to do in my career, just by virtue of where I was, was sort of a charmed life in terms of learning and doing more.
Ryan: Well, and it sounds like a very interdisciplinary, multidisciplinary career. You mentioned tech writing, databases, human factors, IA, like a lot of these things sort of coming together to inform your work.
Julia: Yes. Yes. It’s all been very, very interesting. And so I would say to technical writers now, take all those opportunities to see what user interface designers are doing nowadays. At the very minimum, get familiar with a set of heuristics like Nielsen publishes. Just a set of do’s and don’ts. And do things like prototype on paper, interactions with systems, and even content. So yeah, get familiar with those processes. And I would say also, don’t get unduly focused on tools. Use paper prototypes, use a spreadsheet for whatever you can.
Ryan: Tools come and go, but sort of the basics are always similar or can always serve you well.
Julia: Exactly.
Ryan: All right. Well, Julia, this has been great. It sounds like a really interesting journey, and I appreciate all the insight you’ve offered us. Thanks for coming on the show today.
Julia: Oh, thanks for having me. It was fun.