In this post, I stray slightly outside my normal tech comm focus to explore strategies for personal optimization, specifically with biohacking your glucose with AI. Some of these techniques could apply to tech comm, such as in analyzing user analytics, but that isn't something I've tackled yet. In short, I'm experimenting with using AI tools to adopt healthier habits so that I feel better and am more productive throughout the day. Specifically, I'm exploring ways to hack your glucose using AI to analyze logs.
In this Q&A post, Frank Blome, co-founder of adoc Studio, discusses this new Mac-based documentation tool designed for technical writers. Learn about their choice of AsciiDoc markup, the native Apple platform strategy, unified stylesheet publishing workflow, and how the tool aims to simplify documentation processes for both docs-as-code and topic-based writers. adoc Studio is one of the latest authoring tools to emerge on the tech comm landscape.
In this Q&A about Paligo, I chat with Rasmus Petersson, VP of Product at Paligo. We talk about structured authoring, how Paligo makes component content management more accessible, collaboration features for documentation teams, and upcoming AI-powered enhancements to the platform. The Q&A covers Paligo's evolution as a modern CCMS, how it compares to traditional HATs and DITA-based solutions, and why organizations might consider adopting structured authoring for their documentation.
Bluesky, a social media platform similar to Twitter, has been trending post-election due to disappointment with X. In this post, I reflect on social media platforms in general, especially online spaces for technical writers, and what benefits and tradeoffs they have. The TLDR is that Slack and Reddit offer compelling spaces for tech writers to interact in. I'm still not generally sold on social media. In my experience, the more I scroll social media, the fewer books I read.
We constantly hear that AI will free us up to work on more complex, strategic tasks. One of those tasks is building a landing page for docs. Why is this task difficult? Landing pages require familiarity with the entire doc set, not just one part of it. You have to make decisions about message priority and information hierarchy. You'll need to identify the product story and main features. Most significantly, you'll need familiarity with visual style guides, including approved colors, styles, graphic assets, and tools. In this tutorial, I'll try to break down some strategies and techniques for approaching landing pages. We'll use AI, but not with quick one-and-done prompts.
We frequently hear about AI freeing up bandwidth so we can focus on more complex, strategic tasks. For me, one of those tasks has been to work on a landing page for one of our products. It's something I've been meaning to get to for months. I'm not sure why I don't naturally gravitate toward designing landing pages. If you already have comprehensive documentation, creating the landing page should be simple: gather section overviews and arrange them logically in an appealing layout. Still, landing pages can be challenging, not just in designing the content and flow, but in tackling the visual and graphical elements of the page. This post includes my rambling thoughts on landing pages and why they're challenging for technical writers.
As Lavacon wrapped up last week, I've seen a few posts from attendees sharing their thoughts, including Alan Porter's Am I the AI Luddite? and Fabrizio Benedetti's How I'm using AI as a technical writer. Alan's post echoed some other sentiments I've heard from others in the industry expressing ambivalence about using AI. In fact, many of my colleagues share this ambivalence, unsure which scenarios warrant AI's use or whether it truly helps. Having been an AI proponent for more than a year now, I remain as convinced as ever about AI's usefulness in tech comm. But let me concede a few things.
Although this post by Michael Lynch titled Why I Quit Google to Work for Myself was published in 2018, it trended on Hacker News last week. It caught my attention because I recently underwent a similar promotion process, though with a positive outcome. Lynch, an engineer, highlights a couple of points relevant to technical writers: writing documentation doesn't support an engineer's demonstration of technical complexity, and the projects you work on might matter more than the quality of your output.
Janette Sadik-Khan served as the Transportation Commissioner in New York City under Mayor Michael Bloomberg from 2007 to 2013. During this time, she undertook one of the largest attempts to incorporate pedestrian- and bicyclist-centric changes to the city's roads and transportation system, rather than maintaining a car-dominant approach. Her book, Streetfight: Handbook for an Urban Revolution, authored by both Sadik-Khan and Seth Solomonow, recounts their strategies, attempts, and outcomes across many different projects and initiatives.
In this prompt engineering series, I've often focused on a specific technique one at a time, but in this tutorial, I'll show how multiple techniques can work together successfully. Techniques such as the following: the interview and transcript as a way to gather information, proceeding through chain of thought reasoning steps, switching between editorial and writer hats, and more.
Mark Wentowski has a six-week course on 'Mastering API documentation' that blends theory and practice, includes tools and workflows, hands-on assignments, projects, and more. You can learn more about it here: Mastering API documentation.
The University of Strasbourg, in collaboration with Louisiana Tech University, is holding a Symposium on Usability and Design in France April 24-25, 2025. The focus is on 'Addressing Access and Accessibility Through Usability and Design: Ideas and Approaches for Web Communication, Technical Communication and Localization.'
Some people dream of reaching inbox zero; I have a similar dream for doc bugs: I want to get my doc bug count to zero, or close to it. To try to achieve this, I've started focusing my energy on analyzing why some doc bugs aren't actionable.
The following is a guest post by David Kowalsky exploring some productivity and time management topics based on his reading and experiences with Oliver Burkeman's Four Thousand Weeks. The book encourages you to escape the efficiency trap and focus on what really matters in your limited time.
NotebookLM can automatically generate podcasts about any content you provide. In exploring these podcasts this week, I think they might complete a piece that was missing from the GenAI picture with tech comm: these podcasts can help you understand and learn the content you're working on, even when other AI techniques might shortcut that learning.
