Technical writing courses are popular ways for people transitioning into technical writing careers to build their skills, become familiar with the technical writing profession, and ultimately transition into jobs as technical writers. I had a chance to chat with Bobby Kennedy, a professional technical writer based in New York, who recently created a technical writing course called Become a Technical Writer.
I updated (almost entirely rewrote) the tutorial for using Stoplight Studio. This is one of the centerpieces in my API doc course because it provides an easy way to create an OpenAPI specification document, without having to be familiar with the OpenAPI syntax or YAML.
I'm switching from Skype to Zoom for podcasting tools. Skype seems to be part of another era. The switch to Zoom opens up opportunities for another type of content -- one where participants share their screen more.
In this videocast, I chat with Kate Schneider about micro content and Flare. Kate shares micro content examples from her current documentation and explains the strategies she considers when creating micro content. She shows specifically how to leverage analytics in determining micro content topics.
I revisited the original page on glossaries in my API doc course -- see API glossaries -- and expanded the content with many technical examples about how to single source glossary content from a single YAML file. I added examples for integrating tooltips and popovers as well, added more discussion, analysis, additional reading, and other updates overall. Although this page appears within my API course, the content could be applied to non-API docs and sites as well.
The paths I took in life depend in part of the family dynamics of my childhood, my interest in writing, and a career in tech. In this post, I try to trace the lines from my childhood to present day to understand what pulled me in the directions I took.
Podcast 104 - Fixing broken developer portals, in Ellis Pratt's Cherryleaf podcast, is well worth listening to. Ellis explains a strategy of analyzing developer portals by looking at the developer journeys within the portal and identifying gaps or friction points in that journey.
In my API course, I defined intake processes for large documentation projects and small requests. However, I recently realized a major flaw in the process for small doc requests -- who can make the documentation request. In a nutshell, if you let anyone make doc requests, you can end up saddled with tasks to create documentation for which you lack information. If you instead require product teams to make the requests, you're more likely to get the information you need upfront.
During my transition time between Amazon and Google, I decided to create a brief list of some good decisions and minor mistakes during my five years at Amazon. This is a brief list, without much elaboration, but I think it's still valuable.
I recently published a comprehensive checklist for evaluating documentation quality (the section starts here). In this section, I noted that my perspective is more evolving and experiential, which was good to note because when I tried to actually use the checklist, I realized a few shortcomings that I needed to address. Here are my 10 observations.
Recently I received feedback from someone saying that they couldn't tell when my API documentation quality checklist article was published. This was embarrassing to me because printing timestamps on pages was one of the quality characteristics in the checklist. So I decided to add last-modified timestamps to every page. Unfortunately, this is a much harder task than it initially seems.
I recently re-wrote the article about product overviews in my API docs course, giving the article much more depth and discussion. I also included a survey to gather your feedback about my viewpoints with the product overview.
A few years ago, I posted an article about Xeditor titled Xeditor, a CMS editor for XML content. In this post, I follow up about Xeditor with a Q&A with the founder, Matthias Kraus. The exchange here goes in-depth about Xeditor's origins, audience, latest enhancements, roadmap, and more.
Write the Docs Podcast episode 33 is available. In this podcast, we chat with Anton Bollen from Techsmith about using simplified user interfaces with screenshots. A simplified user interface reduces the unimportant elements so the user's attention focuses only on what matters.
At the beginning of each year, I update my site analytics information (pulled from Google Analytics) and analyze traffic trends, user data, and any other information for my site. These analytics sometimes influence what I focus on for the upcoming year. This year, not much changed in terms of site analytics (which is a good thing). I also have a few simple thoughts on the year ahead.
