Kate Mueller: [00:00:05] Welcome to The Not-Boring Tech Writer, a podcast sponsored by KnowledgeOwl. Together, we explore topics and hear from other writers to help inspire us, deepen our skills, and foster our distinctly not-boring tech writing community.

Kate Mueller: [00:00:23] I am so excited today to welcome to the pod, a man who has just a delightful sense of humor and engaging personality, and I must admit, creates some of the most engaging visual content of most tech writers I know. And if you have viewed any of the sketchnotes for Write the Docs Portland talks for the last few years, you are familiar with his work. So I'm very excited to welcome to the podcast, Dennis Dawson. Dennis, thank you so much for joining us.

Dennis Dawson: [00:00:53] Well, I couldn't resist this invitation, sent as it was over six months ago.

Kate Mueller: [00:01:01] [Laughter] Yes, yes. We sometimes get a little excited around Write the Docs time to invite people to be on the show. It's a great problem to have. I'm told that some podcasts really struggle to find guests, and instead, we've had to be like, oh, maybe let's stop booking people six months out and only do like 1 to 3 months. But we just get really excited about folks.

Dennis Dawson: [00:01:22] It was all I could do to stop the other people from talking to you.

Kate Mueller: [00:01:26] You had to beat back the hordes. Let's be real. It's a highly sought-after opportunity, I guess. So, Dennis, for folks who don't know you, can you tell us a little bit about your tech writer villain origin story? How did you get into this field in the first place?

Dennis Dawson: [00:01:46] Well, that was nigh on 40 year'n ago that I started in this technical writing stuff. The fact is, I graduated with an English degree, which prepares you for everything and nothing.

Kate Mueller: [00:02:01] As the proud owner of two English degrees, I completely understand that statement.

Dennis Dawson: [00:02:07] So I got an editor job at an accounting firm, Arthur Young, and I found out that the typists made more money than I did. And I said, well, wait a second, I can type, one of the few things that I learned in college. And they put me on the ABDick word processor, this big thing, it looked like the console of the USS Enterprise with all the buttons, everything. Then I found out that secretaries made more money than I did. And I said, I can also answer a phone. And so my second promotion was to Secretary, and it happened to be in the Management Consulting Group, which is the group that did consulting for companies like Apple Computer.

Kate Mueller: [00:02:54] Oooh. Fancy.

Dennis Dawson: [00:02:55] I'm sitting there at my desk. I got a Macintosh 128K original computer. Someone looked at the serial number and said, “oh, that was the seventh one ever produced.” And I also had an IBM PC at my right hand. So I went to the first Macworld convention in 1984. I saw a demonstration of MacWrite and MacPaint. Went back to the office, and I was the Macintosh expert and started teaching the other secretaries what I had learned by going to Macworld. Before you knew it, it turned into a job as a desktop computer support role that hadn't existed prior to that because desktop computers were pretty new in 1984.

Kate Mueller: [00:03:45] Yeah. I mean, yes, not long before that, computers took up entire rooms, if not entire buildings, so desktop was a pretty big deal.

Dennis Dawson: [00:03:52] It was. Yeah. So that's where my technical training career began. I eventually went to work for startups, and startups in those days, I was doing the training, but that meant I was also writing the manuals to go along with it. And I didn't know it at the time, but I was doing quality assurance as well because I was the person at the front lines figuring out how to use stuff. And so that turned into my technical writing career. So it was a very unique time where someone who had no skills and no intelligence could get in and start working with this amazing new technology. So it was just fun. I was doing BASIC programming, as in the language BASIC, not, well, it was pretty basic programming. It eventually led to working at Oracle, working on JBuilder. JBuilder is the product that we stole from Borland, and we eventually turned it into an Oracle product. Eventually, they actually completely replaced the software. But Java kept me going for 25 years. And then, more recently, it was JavaScript. And then a couple of years ago I had to learn Python and writing for developers.

Kate Mueller: [00:05:19] How far into that transition before you actually got the moniker of “technical writer” or something that involved the word “writer” in the title?

Dennis Dawson: [00:05:30] Yeah, so I was at the startup and they hired me as the technical writer and the technical trainer. Prior to that, I'd been doing mostly training. I worked at a company called Computerware. That was all Mac, and I did all of the training on all of the different products. So at that time, I was an expert in Adobe Photoshop. I was an expert in Quark because the programs didn't do much, and it was easy to know everything they did.

Kate Mueller: [00:06:04] The perk of getting in early, I suppose. And are you still a Mac guy at this point? Still heavily using Macs?

Dennis Dawson: [00:06:12] I am, but I've used both Mac and PCs. Like I said, early on, I had both at my hands, so I just use whatever I happen to get hired into.

Kate Mueller: [00:06:25] So there we go. Some good old “I have an English degree, I'm going to be a little bit of a shape-shifter and just agree to do whatever.” And then suddenly you ended up kind of shifting from editing into a variety of stuff to training, to then writing and training. Is it still a combination of writing and training for you, or is it now mostly writing?

Dennis Dawson: [00:06:48] Mostly writing, but I've been doing educational video to go along with it. So it always starts with the manual or the online documentation or what have you. But whenever possible, I throw in a nice educational video because it's fun to make video and it's also really effective.

Kate Mueller: [00:07:11] Mhm. Mhm. Multimedia definitely helps, I think. The visual elements help. Some folks definitely learn a little bit better, being able to hear some of the thing and see some of the thing in addition to reading it. So you kind of hit a lot of those learning modalities all at once, which is great. I like it. There's a lot of versatility in what you've done then, Dennis.

Dennis Dawson: [00:07:31] What's funny to me right now, because I am between jobs, although I'm 66, so it could be that I'm retired. I don't know yet. It's up to the market to decide. But you apply for a job and they often ask you, “Why are you excited about working with AI and computer security?” I said well, because you have a job listing and I want a job. This is what excites me about your software. Because the last few years I've, let's see, I worked at VMware and I was doing documentation for distributed virtual machines. So this was software that would monitor the virtual machines. Then I was at Cloudera. I'm writing about Hadoop, big databases. I moved on to Omnisci. I'm writing about data visualization. Moved on to Autodesk. At Autodesk, I was documenting proprietary software they used to connect software. And most recently, I was working at Ripple, writing about cryptocurrency. So whatever the technology is, it doesn't matter to me. I go in...

Kate Mueller: [00:08:47] Yeah, you'll learn it and dig into it and create content around it, right?

Dennis Dawson: [00:08:53] That's the job. And I guess some people just don't know what the job is when they're hiring you.

Kate Mueller: [00:08:58] Especially in startup land, but not only in startup land—I've seen a really wide range of what people think tech writers do, like some folks who think we're just kind of docs monkeys, and some folks who think that we're very strategic, and some people think that we are a combination of like QA or product management or sometimes even customer success, customer support. And I'm not sure that any of those is necessarily good or bad. It's just kind of trying to feel out what the organization thinks they want, and whether that's a combination of skills that you either have or you're interested in having.

Dennis Dawson: [00:09:34] Yeah. When I was at VMware, people were all excited about Agile at the time, and I would go in, and they would have a user story that was something like the Wing Bat—no, as a user, I want to use the Wing Bat to bat the wing. So in self-defense, they paid for it. God bless them. I became a certified Scrum Master and a certified Scrum Product Owner. This is so that they couldn't BS me. And I actually started getting them to write full user stories that included the why. And then, when I moved on to Omnisci a couple of jobs later, I actually was a project manager for a period of time when they needed somebody with an Agile background to rope the team in. So yeah, I've done these things.

Kate Mueller: [00:10:25] Very often, we, you know, we get people who reach out like, “I'm just starting to get into tech writing. What are the skills I need to focus on?” And often I want to say, honestly, being able to be flexible and adapting is one of the biggest skills you can have, because different places will need different things from you, and you need to be able to kind of step up and adapt. [In] our most recent interview with Fabrizio Ferri-Benedetti, he mentions the concept of tech writers as shape-shifters, and I think that's really true. What we have to bring to different roles is really different over time. And it's that, more than anything, that cultivating both your ability to learn but also your ability to adapt that will serve you well in the field.

Dennis Dawson: [00:11:07] Well, I still haven't decided what I want to be when I grow up.

Kate Mueller: [00:11:11] You’ve got time. You’ve got plenty of time, Dennis.

Dennis Dawson: [00:11:14] That's right.

Kate Mueller: [00:11:15] Obviously, the podcast here is called The Not-Boring Tech Writer. We do get a lot of people on who identify as tech writers. We also have some folks [who] prefer documentarian or other labels. What is your preferred label?

Dennis Dawson: [00:11:28] Well, right now I'm a boring non-tech writer. I guess that's the label I'll have to wear, but I'm keeping busy.

Kate Mueller: [00:11:38] Now, one of the reasons I wanted to have you on the show, that I was really excited to pick your brain about, was really kind of a two-fold thing. One, that I think your sense of humor often comes through in the work that you're doing. And two, that you do think about the visual elements there. And I think this is a) totally fits within our not-boring theme, because neither of those things is boring, and it does tend to kind of liven up documentation. But I would love to get you to talk a bit about, I mean, first of all, you've been in the field for a long time. Have people always been supportive of having visual elements or visual callouts within documentation?

Dennis Dawson: [00:12:21] People have never been supportive.

Kate Mueller: [00:12:23] There we go!

Dennis Dawson: [00:12:24] Using my amusing visuals and the jokes that I put into my training. I've always had to fight for them, but I have been using those techniques way back to 1985. There was a program called Slideshow Magician, which, ooh, you could take bitmap graphics and it would put a transition between each one.

Kate Mueller: [00:12:49] Fancy. 1985, that's fancy!

Dennis Dawson: [00:12:52] It was a fancy, fancy thing. I used that to create some amusing tutorials that amused me. That's always been sort of the bellwether, my yardstick, if you will. Am I amused by it? I, as the lowest common denominator, I assume other people will be amused by it as well. And I thought that it was effective because it would just be more engaging, that people would say, “Oh, it's funny, okay, I'll watch it.” But in the last couple of years, I've, and starting in fact with Write the Docs Portland in 2023, I saw Caitlin Davey’s talk that introduced me to the Multimedia Learning book. And then I read that book, and I said, “Oh my God, there are some things I'm doing wrong!” Putting music underneath the narration is a bad idea because it's interfering with the audio channels. But the use of video, the use of graphics, the way I was using graphics, the simplification that I put into my graphics, it turned out that I was doing a lot of things right, and I had been throughout my career. Now add on to that, more recently, I've been reading Barbara Oakley's work, which is Learning How to Learn, A Mind For Numbers, and Uncommon Sense Teaching.

Kate Mueller: [00:14:21] Oh, I'm not familiar with that one. We will link, in the show notes, we will link to all of these things, folks, don't worry.

Dennis Dawson: [00:14:27] She makes the point that the use of colorful metaphors, the use of humor, the use of graphics, and unexpected graphics really helps to embed things in your long-term memory. She compares dual statements, putting those in long-term memory is like trying to put toothpaste back in the tube. It's really hard to jam them in there. But visual information is like sticking pictures up in your locker at school. It's just boom, it's there. And the visual information sticks. Now this can be for good or ill. There were some illustrations in the past that someone else had done. And, you know, I don't want to call anybody out. But in this particular thing, it was a flowchart. And it showed three flowcharts in red and one in green, and the red meant a process was being stopped and the green meant that it was able to proceed. What was confusing about the diagram [was]: what you wanted to do was stop the information from going through. So the three in red were correct, and the one green was the one that was wrong. This confused all of our customers for a period of at least five years, until I went in there and tried to understand it myself. I couldn't. I redid the graphic with only one flow, the correct flow [laughter], and suddenly everybody could understand that concept. So this is the power of really effective graphics.

Kate Mueller: [00:16:10] Yeah. This is also a, I don't even know if this is a thing that's easy to answer, but like, how do you decide what needs a graphic and what does that process look like? Not just the decision point, but as you're trying to come up with what graphic you're going to use. Because, Dennis, I am so interested in this. So whatever you can spew out at me right now, I'm here for.

Dennis Dawson: [00:16:33] I put in a graphic anytime there's a process that it's just helpful to see how it progresses from one step to the next. Very important. If there are many steps, you'll see sometimes people put in a diagram that's got 15 steps to it, and maybe they've got a legend underneath, and that's where they list the 15 steps, and now you're looking back and forth between the graphic and the steps. And all that does is add to confusion. For example, one of the things I do is, in my printed documentation, in effect, it's all online, of course, but the book-style documentation, I will use builds the same way I would in a slide presentation. So here's step one in the diagram. Now here's step two, three, and four, adding on the information so that it comes in one chunk at a time. They call that scaffolding in the common sense teaching. So you build the concepts gradually and give people the space to understand it. So it's the same thing with writing in the Hemingway style, where you use shorter sentences that complete a thought, and then people have just this, this breath of air at the period where they can let the information soak in before they move on to the next one. You'll see in technical documentation, very often you read a sentence, and by the time you get to the end, you forgot what was at the beginning, and you have to go back and reread the sentence. Okay. That's when you're writing like an academic, and it's a style that what you're saying to people is, look at how smart I am. I sound like an academic. But if you write in short, concise chunks, people read it. It flows easily into their brain. And what they're thinking is, “wow, I'm really smart, I understand this.” That's what I want people to experience. I don't want them to think I'm smart. They can think I'm dumb as a post if they like. But I will tell them everything I know, and I'll do it in a way that I can understand it, which means anybody else can. I am the lowest common denominator.

Kate Mueller: [00:18:49] So I have worked largely in the software documentation space, which means that a lot of the visual elements that I'm being exposed to in the documentation I interact with are screenshots rather than illustrations or diagrams, or it's very often just here's a picture of the UI, maybe with an arrow pointing to whatever the relevant thing is. And there's been a lot of debate, I would say, in the greater tech writing community about how much visual content do you include? Is there such a thing as too much? Screenshots certainly are very awkward to maintain, and it feels to me like what gets lost in some of that conversation is the utility of visual assets, period. Because we get very hung up on the screenshot element of it. And it sounds like part of what you're doing here is stuff that's independent of screenshots per se, and is more like, here's a process or a thing that I want you to understand the whole of. Here are some visuals that are going to help line that out without it being, here's a screenshot of each field in the UI, for example. Can you just talk a little bit about what kinds of visuals you like to use here?

Dennis Dawson: [00:20:08] Well, the first thing I'll do is mention someone I'm sure you've never heard of. His name is Manny Silva.

Kate Mueller: [00:20:16] [Laughter] Nope. Never heard of him. Never interviewed him, nothing.

Dennis Dawson: [00:20:20] Yeah. Ubiquitous Manny Silva. He's absolutely everywhere. The most helpful person I've ever met, certainly. He's just a gem. His product, which is free, Doc Detective, out there will let you script to take your screenshots, and as long as the UI doesn't change, then the screenshots are going to be the same, and you just drop them in. But if the UI changes, because of the way Doc Detective works, it will still run the software. It will still take those screenshots for you, and all you have to do is go back and adjust those arrows that you talked about. So if you're working in Gimp or a similar product, working in layers, you can just replace the underlying screenshot, and all you have to do is adjust the arrows that you have in the different layers. You don't have to go back and redo things, so the screenshots are much easier than they used to be. That's fantastic. Screenshots, as long as you're not using them in the way where you say, “look at this picture of your screen, make your information look like that.” That is the lowest ebb of technical writing. You don't ever want to do that. The only reason to put a screenshot in is if the UI is confusing, if it's going to be difficult for people to find things. But if you put Select File > Save and you put a screenshot in of the File menu and you're selecting the save command, that is a waste of everyone's time.

Kate Mueller: [00:21:58] I like to think of them as these are sort of signposts around things that might be confusing to you. So it's valuable to me to give you a screenshot if there is something really confusing about the way that this UI works, or if you haven't done something correctly up to this point, it's going to look very differently. So I want to give you a little bit of a sense of what it should look like in case the two paths diverged in the woods and you took the wrong one somewhere back there, I want to give you a screenshot, maybe really early on in that point, that reinforces what the text is saying. Make sure you select this so that you have this option. And then maybe I might show you what the option looks like so that you have that signpost to be like, “oh, that's not what my screen looks like right now.” Or “yep, that's what my screen looks like, I can continue.” Rather than having it be, let me convey a whole bunch of information that really should be written text rather than visual here.

Dennis Dawson: [00:22:57] Now, the other nice thing about graphics is that when you're reading, you get into focused mode and you're really intent on absorbing the content. But there is a focused mode of thinking, and there's a diffuse mode of thinking. And again, this comes from Barb Oakley in the Uncommon Sense Teaching. In focused mode, you're really intense. Your working memory is just trying to soak this stuff in. But it's the diffuse mode where you're not thinking about what you just read at all, where you're thinking about something else, where you go get a cup of coffee, and the ideas are just kind of bouncing around in your head loosely. And what they do then is create new connections. This is where creativity comes in. And deep understanding comes from connecting ideas that were already there instead of the very specific things that you're trying to learn from reading the book. So even that short respite from reading the text, where you look at a picture, is something that lets your brain relax a little bit and let the ideas percolate, bounce together, find new connections. And so I like to break up my documentation with graphics, especially if it's going to be introductory material. Every paragraph or so, I'll put in, if the paragraphs are concise and I'm doing a good job with the writing, then a graphic is a nice respite after a good, solid paragraph.

Kate Mueller: [00:24:43] I like that. So do you find that you use more graphics for that more introductory material, or maybe more conceptual or complicated material rather than, I don't know, step-by-step guides, for example, like how-to documentation?

Dennis Dawson: [00:25:00] So for step-by-step, I'm going to use screenshots in the way that you talked about. Generally, I'll say do these 14 steps, and now your screen should look like this. And what I like about that is that at that point, they can decide whether they need to actually load the software and run it in order to see what's going on, or if they just want to read about what the steps are and see what the result would be, then they're fine. The same thing with video. If I can demonstrate for you in a video what it looks like when you do something properly, you don't necessarily have to download the software and run it in order to understand what you're trying to do. I believe I got off the point of that question.

Kate Mueller: [00:25:48] [Laughter] Let me re-ask it. I kind of asked two questions in one there, so that's totally my fault. Do you find that you use illustrations or graphics more heavily in what I would say might be introductory, but I'm also guessing sort of conceptual documentation might really benefit from that. Where do you use them the most? That's probably the easier question.

Dennis Dawson: [00:26:10] What was great in my last position is, and again, this came from going to Write the Docs. Ryan Green did a presentation about three layers of documentation, and he talked about the middle layer. So we've got the 30,000 feet introductory information that's got a lot of graphics in there. And then you've got the reference documentation, which is just information thick. And so I would never put illustrations into reference documentation. It's really not necessary. But that middle layer is another opportunity when you're doing use cases to put in some graphics to demonstrate the practical workflows. And one of the things, and this is something I did a while back in the 1990s. I was working at a company, Metropolis Software, and we had a sales engine, which eventually was part of the seed that became Salesforce. Half of the team that started Salesforce came from Metropolis Software. The application had no user interface. It was all command line, right? And so there were these processes. There was a writer, there was a reader, there was a referee. And what I did was illustrate that with a different robot character. It would do each of these steps, and then I could create flowcharts that showed the interaction between these seven different units that were distinct software elements that you could combine in a bunch of different ways. And by creating a whimsical, you know—the writer was using a feathered pen, and the referee had the striped shirt and the whistle and the whole thing.

Kate Mueller: [00:28:14] That's what I was imagining. Striped shirt and whistle. Yep. [chuckle]

Dennis Dawson: [00:28:18] So you've got these things, then when people are looking at the flowchart, they say, “oh, I get who that is. I see what the process is between those.” You don't have to explain everything about whatever that process is in order for them to understand the flow.

Kate Mueller: [00:28:34] This is great. I feel like this is a great time for us to take a little break, and we will be back momentarily.

[00:28:40] This episode is sponsored by KnowledgeOwl, your team's next knowledge base solution. You don't have to be a technical wizard to use KnowledgeOwl. Our intuitive, robust features empower teammates of all feathers to spend more time on content and less time on administration. Learn more and sign up for a free 30-day trial at knowledgeowl.com.

Kate Mueller: [00:29:03] And we are back. So, Dennis, I mean, I'm really excited about this, but I will admit that I have a bit of the like, “oh my gosh, this sounds fantastic, but I have no idea how I would get started actually adding cool little visual elements into my documentation.” I, you know, I'm not an artist. I don't necessarily know the toolsets to use here. Can you tell me a little bit about where you begin with this? Are you drawing stuff by hand? Are you using tools for it? What does it look like?

Dennis Dawson: [00:29:35] All right. So you mentioned that I do the sketchnotes for Write the Docs. Those who have seen the sketchnotes realize that I am much more a funny guy and less of a serious artist. I draw well enough to get the ideas across, but mostly I'm going for the humor that makes these things memorable. So I actually volunteer at a local school. I draw with the kids, fourth graders, once a week, but I wouldn't say that I'm an art teacher, and I would never say that I'm an artist. What I'm willing to do is draw and let other people see what I've done. That's the first thing. Now: Get over yourself. Get over your reticence. Realize that if you draw a picture, you're doing better than 7 billion people who did not sit down and draw a picture today. So that makes you an artist. And I believe everyone is an artist. [It’s] not a question of talent, it's just a question of time—how much time you spend fiddling with it. So very often, yes, I certainly start with hand-drawn sketches. Now, if you want to get your graphics into your professional technical documentation, the first thing you want to do is make real good friends with anybody who is responsible for the graphic look of your products. So at Ripple, we had a terrific graphic design team. I drew my sketchy little pictures and showed them the idea of what I was going for, and I was very fortunate to be working with some very talented designers who took my sketches and turned them into something entirely different that had the same vibe.

Dennis Dawson: [00:31:27] That was the beauty of it. What was nice is that they created these graphics in Figma. Like any other application, I didn't know how to use Figma, but that's what they were using. So I went in, and I still recognize Bezier curves. I still recognize what I expect the tools to do, and with a little fumbling around, I was able to manipulate the graphics that they gave us as the starting point. If I needed the little guy with the fedora hat to be pointing up, or I needed to add a cabinet behind him or something like that, I could use the tools well enough to do that. So my first piece of advice, yes, get them to sign on. You don't want to turn all of the graphics over to someone else, if you can avoid it. There's two reasons for that. One is that they're not always going to get the vibe that you're going for. And the other is that you've just added a bottleneck in your development process. So to the extent that you can do all of your graphics yourself, or at least do the first draft, show it to the design team and let them pat you on the head. “Oh, Dennis. Oh, yeah. Good try.” And then they help you, then that's the best of both worlds.

Kate Mueller: [00:32:50] Yeah. And then it sounds like also: do a little bit of learning about whatever tool those folks are working in, so that you can make some small changes here and there to fit the exact placement you want to use, right?

Dennis Dawson: [00:33:04] Yeah. I mentioned Gimp earlier. That's the graphic image manipulation program. It's a price point that I particularly appreciate, which is free. Yeah. And Inkscape is the equivalent to Illustrator. I love Adobe products—like I said, I was an expert on Illustrator and Photoshop 40 years ago when they didn't do as much. Now they do absolutely everything, and you can go out of your mind learning all of the things that these tools can do. But as a technical writer, I need just a little bit of what these things do.

Kate Mueller: [00:33:46] Yes, I don't need the entire universe. I just need the corner store down the street. Thank you. [laughter]

Dennis Dawson: [00:33:53] Yes. And so that's what you're going to get from Inkscape, and that's what you're going to get from Gimp. For the animations I like to use, it's nice that Keynote comes with my Macintosh, kind of built in. You can use PowerPoint if you don't have either of those. You can use Google Slides, which is free for everybody. And the nice thing about Keynote is that it's got some really cool little animations that you can do, like things catching on fire and things crumbling to dust, which are great metaphors for most of what I do in my writing.

Kate Mueller: [00:34:32] Catching on fire and crumbling to dust?

Dennis Dawson: [00:34:37] That's right. So, having these cool effects—it's nice, but it's not really necessary. You can use the simpler animations that come with Google Slides and use it to create visual excitement in the things that you're doing.

Kate Mueller: [00:34:52] I love the idea of being able to use tools that all of us kind of have access to that might be less intimidating to use initially, just to get your toes wet before you jump full bore into the thing. I always like training wheels for a little bit at a time, and that sounds potentially helpful. Now, the one thing that we haven't talked a whole lot about, but you brought up really early on, is using video components rather than just purely visual graphics or even animations. And video is one of those interesting things because it adds an additional layer of maybe maintenance woes, depending on what you are using your video for. I remember, so I have a mentor who's an instructional design specialist, and I have met with her a few times to talk through some of the strategy in my documentation, and every time I bring up videos, she's like, “Kate, you don't want to do a lot of video that involves the UI because you will find yourself updating that video constantly and it's going to be a nightmare. But what you do want to consider is stuff like concepts or processes that might be really hard for people to wrap their heads around, just seeing them in text form.” So I'm curious, Dennis, how have you used video? Where do you think it adds the most to documentation?

Dennis Dawson: [00:36:18] One of the nice things about the video that I produce is I do it as cheaply and basically as I possibly can. I don't go for any—I certainly don't show myself on the videos. I thought that it was just because I would scare people, and so it's a good idea not to. But again, as it turns out, Multimedia Learning, again, Richard Mayer's book, he talks about the fact that having your face in a little circle on the screen is not only unnecessary, it's distracting from whatever it is you're talking about. So inadvertently, I was doing that right by keeping my face out of it. That means that I don't have to worry about lighting. I don't have to worry about the audio setup. I can just record things directly onto my little Macintosh here and everything turns out fine. I do create my videos with an eye toward what happens if the UI changes. Now again, one of the nice things about using Doc Detective or a similar tool: if the UI changes, you can actually record video using Doc Detective, not just take the static screenshots. And in fact, I was working on tutorials for Doc Detective that are currently up there. People can go visit them. Something had significantly changed. I was just able to run the same script. It redid the video for me. I copied that video into my editing software, and because it used the script, everything happened at exactly the same time. So I was able to update the video using exactly the same voiceover, and I just again had to move the arrows into the correct spot, if anything moved, and bing bang boom, that video was done.

Dennis Dawson: [00:38:17] So I would not be—I would be really afraid of creating videos where you have to bring in someone to do the voiceover, where you have to have someone do on-camera work, and you have to coordinate with that person, the whole thing. But the videos I produce are really narrated Powerpoint slideshows, is what they are, with the cool animation and everything that goes along with it. I can knock out one of these videos in a couple of hours. Certainly, in an afternoon I can do a one to three-minute video, no problem. I mean, one of the tricks I discovered is you can create a video, say you're doing a demo, you can record yourself doing the voiceover, and every place you say, uhhh, I mean, duuuh, you know, the whole thing, you're going to edit those out. Well, if you upload it into Slack, Slack automatically creates a transcript of what you just did. And so I upload it to Slack, I get the transcript, I clean up the transcript, and turn it into an actual script. Then I go back and record it again, and I do everything exactly when it needs to be done. And I say exactly what I meant to say, but that saves me the trouble of working all of that out in my head before I sit down to do the recording. I know what I want to do, I don't know exactly how I'm going to describe it, so I just record myself doing it, then go back and pretend that I'm a real person.

Kate Mueller: [00:39:59] [Laughter] So you're not actually writing a script first and trying to follow it. You're kind of doing what you think you want to do, and then creating the script from the transcript of that, in essence.

Dennis Dawson: [00:40:13] Yes. For the element of the video that is the demonstration of the software. I certainly script the introductory piece and the outgoing piece, but yeah, I am talking specifically about the part where I'm demonstrating the software.

Kate Mueller: [00:40:30] Yeah, which is the part that I think people get the most hung up on, trying to script or trying to follow a script or whatever. So yeah, I think that's useful advice. I hadn't ever thought of doing that. I've certainly used tools that will remove my ums, uhs, and other filler words, but I've never thought of: let me run through the process once, record that, get the transcript of that, and then build my script from that. That's smart, that's clever, Dennis. This is why you get paid the big bucks, right?

Dennis Dawson: [00:41:01] I used to. [laughter]

Kate Mueller: [00:41:04] Now, how do you decide what you are going to make a video of?

Dennis Dawson: [00:41:08] Again, anytime there's a process that's going on behind the scenes, what's nice is you can illustrate the information, say, have it appear on screen as a string, and then show it going into a server. The server processes it and sends back the response. So those things that are going on in the background, it's nice to illustrate them so people can get a good mental model. I was talking about escrows in one of the recent videos, and I actually, I had heard the term before, but I didn't really know what escrow was all about. So I learned it. “Oh, okay, now I understand it.” And I needed to—I figure if I'm confused by it, then other people might not have heard exactly what the process is. So I just added 30 seconds at the beginning of the video and showed someone ordering escargot from Bordeaux and putting it in an escrow so they could get Bordeaux escargot on the go. But in that 30 seconds of humor showing snails, showing Bordeaux, the whole thing, I was able to explain what an escrow is. So anybody who is unfamiliar with it would know that. And then I could go on and demonstrate how to do an escrow in our software.

Kate Mueller: [00:42:31] Now, one of the things I've heard folks say, kind of in the anti-humor camp, is that humor is one of those things that is somewhat culturally dependent. So if you've got a lot of, maybe international users engaging with your documentation, [then] you might run the risk of that not translating really well between cultures. And I know you've used humor quite a bit. Is this a thing that you've run into? Has it been a hurdle or a stumbling block for you? Are there any experiences or words of wisdom you can offer as a counterpoint to this?

Dennis Dawson: [00:43:10] As an example, when I talk about the Bordeaux escrow escargot, it doesn't matter if you speak English or not, you're going to hear the rhyme, and you're going to get that “oh, it's funny because it's rhyming.” But I would never do anything that is dependent on turns of phrase. You have to be careful about jokes that rely on idioms that are particular to America. Generally, visual humor works really well. So, I was talking about using the things burning up and the crumbling—so, sort of slapstick visual things are going to translate into any language. But because I'm really cognizant when I'm doing my technical writing of writing in a way that is bare bones English, that's easy to translate, I end up, I don't really focus on that. I don't have to think about it when I'm creating the videos, because the source material is already something that is going to be easy to interpret [by] someone if English isn't their first language.

Kate Mueller: [00:44:12] Yeah. If you're already using good plain English conventions, then the place you're starting from to generate ideas for that is already somewhat simplified. And certainly, avoiding things like idioms, which are highly culturally specific, even for folks who are native English speakers but are from different countries, idioms can be really hard to unpack.

Dennis Dawson: [00:44:32] Some o’ them weirdos talk weird places.

Kate Mueller: [00:44:37] [Laughter] Very much so, very much so. So, Dennis, you've shared a whole bunch of tips, tricks, different tools people could use, are there any other resources that you want to be sure people walk away from this conversation with that we haven't already covered?

Dennis Dawson: [00:44:52] I will reiterate, so we have already covered this, Multimedia Learning by Richard Mayer. Read this because it gives scientific explanations for why the kinds of whimsical illustrations that I use work. Again, the works by Barbara Oakley, Learning How to Learn and Uncommon Sense Teaching, these concepts translate directly into technical writing. I would encourage anybody to start thinking in terms of how am I going to make this more engaging? How am I going to make it stick in the reader's brain? You don't have to be a comedian. You don't want that. You don't want people—one of the worst documents I ever read…it was for a database product, and in the introduction, the writer says, “Now here's the difference, I'm going to be funny.” And he made a couple of lame jokes in the introduction, but someone must have talked him out of that. If he had just taken that sentence out, the documentation would have been much more palatable. But those few times when he tried to be funny, it simply didn't work. And I will say this about myself: there are not many things I will claim as great superpowers, but the one thing I will say: I don't try to be funny. I'm just funny. And if you ever try to be funny, then you're not funny.

Kate Mueller: [00:46:22] There's a Zen quality to it, right? Like, yes, the harder you try, the worse you fail. For some reason, this reminds me of one of my graduation ceremonies. The keynote speaker from wherever that they got, he started off his speech by saying, “Don't worry. What I'm not going to give you is the world's longest, most agonizing graduation speech. This is going to be short, sweet, and to the point.” And then he talked for like 30 minutes, and I was like, “dude, don't set an expectation you can't deliver on.” My goodness. Nothing about that was short, sweet, and to the point. Very much like your “but I'm gonna be funny” guy. Oh my goodness, don't tell me you're gonna be funny. You're not gonna be funny. Nothing will live up to the expectation that you've just set, at all. Okay, great. So that's a couple, like a nice little plug for a few resources that have come up already. Dennis, maybe also to this, maybe I could almost count what you just said as this, but what is a great piece of advice that you've been given? Doesn't have to have anything to do with writing, illustrating, just like a great piece of advice, period.

Dennis Dawson: [00:47:33] Only thing that ever comes to mind is something that the Prince Consort told Prince Harry, and that is never pass up an opportunity to use a toilet.

Kate Mueller: [00:47:47] [Laughter] That is an excellent piece of advice. I love it, I love it.

Dennis Dawson: [00:47:51] And actually, I learned a new one just this past week. It was on the television show The Rainmaker. It was: if two people tell you you're drunk, you should sit down.

Kate Mueller: [00:48:04] [Laughter] Important life advice here, directly from the horse's mouth.

Dennis Dawson: [00:48:08] That definitely applies to technical writing. If two people tell you that your paragraph is confusing, then you need to rewrite that paragraph. If one person is confused, maybe you can laugh at them and talk about them at happy hour, and laugh at them and what have you. But now, if two people give you the same feedback, it's valid feedback.

Kate Mueller: [00:48:31] Yeah—at least feedback you should consider and see if there's something you can do about that. I like that. And last but not least, Dennis, if people want to connect with you after listening to this because you are a delightful human being, what is the best way for them to do that? Are you on LinkedIn? Are you on Slack? Do you have a personal website? Smoke signals? Carrier pigeons? What's the best way?

Dennis Dawson: [00:48:54] You can always reach me at dennis.s.dawson@gmail.com.

Kate Mueller: [00:49:01] Beautiful.

Dennis Dawson: [00:49:02] I do have a website, but it's kind of a, I'll give you the link. You can share it.

Kate Mueller: [00:49:07] We'll toss it in the show notes for sure. And your email address. We will put it in the show notes.

Dennis Dawson: [00:49:11] Yes. And I am on LinkedIn: dennissdawson, one word, easy to find. I'm very happy to come to your company and work and provide you with all of my—it kills me, seriously, that I've got these amazing skills that I've built over the past 40 years. Yes, I'm 66, but I certainly am at the top of my game. I play the games on LinkedIn every day, and I usually beat other people's scores. I have been playing mind games to be sure that I'm still up to snuff. And so far I still am. So I think I've got 4 or 5 productive years left in me, and then I'll just be tired of the whole thing. But for the moment, even in my retirement, I'm doing Coursera courses daily, knocking those out and volunteering as the drawing teacher. But I'll also be a volunteer reading tutor for adults who don't read English. I'll be going up to the local PBS station to learn about AI and how it's used in teaching. I do have my substitute teaching credential now, sadly a little too late. I applied for it in July, and I received it in September after they'd hired all the substitute teachers for the year. So it may be a year before I get to be a substitute, but I'm looking into all these ways that I can still be of use. And one of the best ways I could be of use is, yes, one of the people listening to this say, “Oh my goodness, I like the cut of his jib. Let me put him to work in our documentation team.”

Kate Mueller: [00:51:02] Yes, yes. And we will keep fingers crossed that that ends up happening. All of your contact information will be in the show notes, should anyone listen to it and get that feeling. And it will be easy to reach out to you and pull you in and get you on their team. So, Dennis, thank you so much for your generosity with your time and your knowledge and your humor. I appreciate you.

Dennis Dawson: [00:51:25] I appreciate being asked. I love the sound of my own voice.

Kate Mueller: [00:51:29] [Laughter] Maybe you should be a podcast host because I hate the sound of my own voice. I find the editing process to be arduous and awful, but I love listening to other people, just not so much myself. Thank you so much.

Kate Mueller: [00:51:48] The Not-Boring Tech Writer is co-produced by our podcast Head of Operations, Chad Timblin, and me.

Post-production is handled by the lovely humans at Astronomic Audio with editing by Dillon, transcription by Madi, and general post-production support by Been and Alex.

Our theme song is by Brightside Studio.

Our artwork is by Bill Netherlands.

You can order The Not-Boring Tech Writer t-shirts, stickers, mugs, and other merch from the Merch tab on thenotboringtechwriter.com.

You can check out KnowledgeOwl's products at knowledgeowl.com.

And if you want to work with me on docs, knowledge management coaching, or revamping an existing knowledge base, go to knowledgewithsass.com.

Until next time, I'm Kate Mueller, and you are the not-boring tech writer.