<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>I'd Rather Be Writing - Tom Johnson</title>
    <description>Technical writing blog focusing on the latest trends, news, and other topics in the field of technical communication.</description>
    <link>http://idratherbewriting.com/</link>
    <atom:link href="http://idratherbewriting.com/feed.xml" rel="self" type="application/rss+xml"/>
    <pubDate>Thu, 09 Feb 2017 22:34:36 -0800</pubDate>
    <lastBuildDate>Thu, 09 Feb 2017 22:34:36 -0800</lastBuildDate>
    <generator>Jekyll v3.3.1</generator>
    
      <item>
        <title>Write the Docs Podcast #3 - Trends for 2017</title>
        <description>In this episode of the Write the Docs podcast, we discuss top technical writing trends for 2017. Chris Ward discusses how more technical writers are interacting with support groups, and even being embedded within support departments. Jared Morgan discusses how docs are being planned for earlier in development cycles, as more product managers are seeing the value of docs. I talk about how more technical writers are treating documentation as code, and the challenges inherent in developer tools and workflows.  <a href="http://bit.ly/wtdpodcastepisode3trends">Read more >></a> </description>
        <pubDate>Fri, 03 Feb 2017 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/02/03/wtd-podcast-trends-2017/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/02/03/wtd-podcast-trends-2017/</guid>
        
        <category>support</category>
        
        <category>docs as code</category>
        
        <category>podcast</category>
        
        
        <category>api-doc</category>
        
        <category>podcasts</category>
        
        <category>stitcher</category>
        
      </item>
    
      <item>
        <title>Technical Writing Trends and Predictions for 2017</title>
        <description>My 2016 technical writing trends/predictions turned out to be pretty accurate. For 2017 technical writing trends, I'm predicting that more technical writers turn to Github in their documentation workflows. This trend applies mainly to companies where programming technical writers work with engineers to create developer documentation.  <a href="http://bit.ly/2017techwritingtrends">Read more >></a> </description>
        <pubDate>Sat, 28 Jan 2017 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/28/technical-writing-trends-for-2017/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/28/technical-writing-trends-for-2017/</guid>
        
        
        <category>api-doc</category>
        
        <category>general</category>
        
      </item>
    
      <item>
        <title>Simplified Technical English and HyperSTE</title>
        <description>Simplified Technical English (STE) is an approach to writing developed by the aerospace and defense industries to simplify technical documentation. STE consists of a dictionary of about 900 allowed words and a set of 65 writing rules. Together, this controlled language is formalized into a specification called ASD-STE100, which many regulatory industries must follow to ensure clear, consistent content. HyperSTE is a plugin offered by Etteplan to check your content for adherence to the rules and grammar of the ASD-STE100 specification.  <a href="http://bit.ly/asd-ste1000hyperste">Read more >></a> </description>
        <pubDate>Wed, 25 Jan 2017 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/25/hyperste-simplified-technical-english-asd-ste100/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/25/hyperste-simplified-technical-english-asd-ste100/</guid>
        
        
        <category>api-doc</category>
        
      </item>
    
      <item>
        <title>Recording: Modern Technical Writing, by Andrew Etter (STC Silicon Valley chapter)</title>
        <description>Andrew Etter presented about his book, Modern Technical Writing, to the STC Silicon Valley chapter on January 24, 2017 in Santa Clara, California. In the presentation, Andrew talks about the strategies he implemented at Palantir to change to a new way of doing docs. This new way includes having a smaller team, using text editors, writing in plain text, processing pull requests instead of bugs, and more. He dives into lightweight markup syntax, static site generators, version control tools, and more, as well as challenges he has faced.  <a href="http://bit.ly/ettermodern">Read more >></a> </description>
        <pubDate>Tue, 24 Jan 2017 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/24/modern-technical-writing-andrew-etter-presentation/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/24/modern-technical-writing-andrew-etter-presentation/</guid>
        
        <category>andrew etter</category>
        
        <category>lightweight markup</category>
        
        <category>static site generators</category>
        
        <category>modern technical writing</category>
        
        <category>palantir</category>
        
        
        <category>api-doc</category>
        
        <category>podcasts</category>
        
        <category>stitcher</category>
        
      </item>
    
      <item>
        <title>Recording: Writing tech docs like a hacker with Jekyll</title>
        <description>I recently gave a presentation titled Writing tech docs like a hacker with Jekyll to the to the Southern Ontario STC chapter (on Jan 18, 2017). In the presentation, I introduce reasons why we started using Jekyll, how static site generators differ from content management systems, how to get started with Jekyll, and challenges involved in using Jekyll for technical documentation sites.  <a href="http://bit.ly/writetechdocshackersoc">Read more >></a> </description>
        <pubDate>Wed, 18 Jan 2017 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/18/writing-tech-docs-like-a-hacker-with-jekyll/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/18/writing-tech-docs-like-a-hacker-with-jekyll/</guid>
        
        
        <category>jekyll</category>
        
        <category>podcasts</category>
        
        <category>stitcher</category>
        
      </item>
    
      <item>
        <title>My top 3 posts of 2016 are all Swagger-related -- lessons learned from 2016 analytics</title>
        <description>This past year the stats on my blog showed some surprising results. From about mid-2016 on through the present, there was a notably upward trend in page views. I attribute the upward trend primarily to some posts on Swagger. The larger trend is that all top posts on my site could be classified as documentation content.  <a href="http://bit.ly/2017swagger">Read more >></a> </description>
        <pubDate>Tue, 17 Jan 2017 12:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/17/trends-2017-swagger-all-the-way/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/17/trends-2017-swagger-all-the-way/</guid>
        
        
        <category>api-doc</category>
        
      </item>
    
      <item>
        <title>Swagger presentation recording -- Harnessing the Chi of Swagger in your REST API documentation</title>
        <description>Recently I gave a presentation on Swagger as part of the TC Dojo webinar series. If you missed the presentation, you can view the Swagger recording here.  <a href="http://bit.ly/swaggertcdojorecording">Read more >></a> </description>
        <pubDate>Tue, 17 Jan 2017 11:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/17/swagger-presentation-documenting-rest-apis/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/17/swagger-presentation-documenting-rest-apis/</guid>
        
        
        <category>api-doc</category>
        
      </item>
    
      <item>
        <title>FrameMaker and the mobile web: Evaluating Adobe FrameMaker's responsive HTML5 output</title>
        <description>If you look at the surveys and other data collected about tool usage and priorities in the technical communication field, it's impossible not to acknowledge FrameMaker as one of the most common tools. Year after year it appears at the top of the charts, and print publishing remains a high priority. Although commonly known for its print publishing capabilities, FrameMaker also has an excellent responsive HTML5 web output. Getting responsive design right is difficult, particularly with documentation websites that have robust navigation sidebars. FrameMaker's responsive output is both mobile-friendly and impressively designed.  <a href="http://bit.ly/fmweboutput">Read more >></a> </description>
        <pubDate>Mon, 16 Jan 2017 10:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/16/adobe-framemaker-html5-mobile-responsive-view/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/16/adobe-framemaker-html5-mobile-responsive-view/</guid>
        
        
        <category>general</category>
        
      </item>
    
      <item>
        <title>MadCap Central -- a first look at MadCap’s new cloud-based collaboration and publishing solution</title>
        <description>MadCap Central, recently released in early January, is a new cloud-based collaboration and publishing solution for tech docs from MadCap Software. MadCap Central allows you to configure and deploy Flare builds from a central server. You can also manage tasks, teams, users, and other details related to each of your projects in MadCap Central.  <a href="http://bit.ly/madcapcentralreview">Read more >></a> </description>
        <pubDate>Mon, 16 Jan 2017 09:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/16/madcap-central-review/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/16/madcap-central-review/</guid>
        
        
        <category>general</category>
        
      </item>
    
      <item>
        <title>How much code do you need to know to create API developer documentation?</title>
        <description>With developer documentation roles, some level of coding is required. But you don't need to know as much as developers, and acquiring that deep technical knowledge will usually cost you expertise in other areas. </description>
        <pubDate>Fri, 06 Jan 2017 10:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/06/how-much-code-do-you-need-to-know/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/06/how-much-code-do-you-need-to-know/</guid>
        
        
        <category>api-doc</category>
        
      </item>
    
      <item>
        <title>Attend my upcoming TC Dojo presentation on Swagger on Jan 9, 2017</title>
        <description>I'm giving a TC Dojo presentation this Monday morning (Jan 9) on Swagger. If you're interested, you can register and attend for free. The event will also be recorded.  <a href="http://bit.ly/tcdojoswagger">Read more >></a> </description>
        <pubDate>Fri, 06 Jan 2017 09:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/06/upcoming-swagger-tc-dojo-presentation/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/06/upcoming-swagger-tc-dojo-presentation/</guid>
        
        
        <category>api-doc</category>
        
      </item>
    
      <item>
        <title>TC Camp in Santa Clara to be held Jan 21, 2017</title>
        <description>TC Camp is holding its annual free unconference for Tech Comm on Jan. 21 in Santa Clara. TC Camp starts with morning workshops given by experts in the field for a nominal fee. The unconference follows, where attendees vote on the topics to be discussed. It's a great event for networking and exchanging ideas, and I'll definitely be there.  <a href="http://bit.ly/tccampsantaclara">Read more >></a> </description>
        <pubDate>Fri, 06 Jan 2017 07:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2017/01/06/tc-camp-coming-up-santa-clara/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2017/01/06/tc-camp-coming-up-santa-clara/</guid>
        
        
        <category>beginners</category>
        
      </item>
    
      <item>
        <title>Generalist versus specialist: What should you focus on with knowledge building in your tech writing role?</title>
        <description>I've been thinking about how I should focus my time with knowledge building in my tech writing career, especially given my context in a large organization. Lately, rather than primarily writing content, I've been playing more of a content curator / tools developer / publisher role. I'm okay with this. But sometimes I feel like I have to choose between acquiring deep technical knowledge versus acquiring deep tech doc tools/publishing knowledge.  <a href="http://bit.ly/generalistvsspecialist">Read more >></a> </description>
        <pubDate>Tue, 20 Dec 2016 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2016/12/20/changing-roles-of-technical-writers/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2016/12/20/changing-roles-of-technical-writers/</guid>
        
        
        <category>general</category>
        
      </item>
    
      <item>
        <title>Write the Docs Podcast Episode 2 (which Focuses on Findability) Now Available </title>
        <description>Episode 2 in the Write the Docs podcast is now available. The topic of episode 2 is findability: How do you allow your users to find what they're looking for in your documentation? We talk about various tools for findability: search, tags, faceted filters, sidebar navigation, inline links, related links, terms/glossaries, and breadcrumbs. In this post, I also share a few more details about Lunr search.  <a href="http://bit.ly/wtdpodcastep2findability">Read more >></a> </description>
        <pubDate>Sun, 18 Dec 2016 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2016/12/18/write-the-docs-podcast-episode-2-exploring-findability-in-documentation/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2016/12/18/write-the-docs-podcast-episode-2-exploring-findability-in-documentation/</guid>
        
        
        <category>general</category>
        
      </item>
    
      <item>
        <title>Updating a single page versus updating the documentation as a whole</title>
        <description>This past week I made some contributions to the Jekyll documentation, and in making the pull requests, I realized why technical writing is often so difficult. Making a request to one documentation topic often requires you to adjust other topics as well. So often we place the bar for contribution at whether someone can write. In reality, it's not just whether someone can construct clear, grammatically correct sentences. It's whether the person can integrate the information into a larger documentation set.  <a href="http://bit.ly/singlepageversuswhole">Read more >></a> </description>
        <pubDate>Wed, 14 Dec 2016 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2016/12/14/higher-level-technical-writing/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2016/12/14/higher-level-technical-writing/</guid>
        
        
        <category>general</category>
        
      </item>
    
      <item>
        <title>New podcast from the Write the Docs community</title>
        <description>The Write the Docs community now has a podcast available. The podcast follows a discussion-based format with several co-hosts talking about recent articles or topics related to tech comm. The podcast is available on almost every podcast platform.  <a href="http://bit.ly/wtdpodcastepisode1">Read more >></a> </description>
        <pubDate>Wed, 23 Nov 2016 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2016/11/23/new-podcast-write-the-docs-community/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2016/11/23/new-podcast-write-the-docs-community/</guid>
        
        
        <category>general</category>
        
      </item>
    
      <item>
        <title>Recording of Open Authoring -- Collaboration Across Disciplines presentation, by Ralph Squillace</title>
        <description>Ralph Squillace, a senior content engineer for the Microsoft Azure Infrastructure team based in San Francisco, California, recently gave a presentation to the STC Silicon Valley chapter (on November 14, 2016) on &lt;i&gt;Open Authoring -- Collaboration Across Disciplines&lt;/i&gt;. In the presentation, Ralph talks about Microsoft's approach to scaling their authoring and publishing efforts across the company by embracing Markdown, Github, open source tools, and other processes that allowed everyone in the company to write and contribute to Azure's documentation.  <a href="http://bit.ly/ralphsquillacestc">Read more >></a> </description>
        <pubDate>Tue, 15 Nov 2016 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2016/11/15/recording-of-open-authoring-collaboration-ralph-squillace/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2016/11/15/recording-of-open-authoring-collaboration-ralph-squillace/</guid>
        
        <category>developer documentation</category>
        
        <category>open source</category>
        
        <category>collaboration</category>
        
        
        <category>api-doc</category>
        
        <category>podcasts</category>
        
        <category>stitcher</category>
        
      </item>
    
      <item>
        <title>Review of Coding for Writers course by Peter Gruenbaum on Udemy</title>
        <description>Peter Gruenbaum has a new course on Udemy called Coding for Writers. Overall, this course takes a unique angle in not only teaching you the basics of coding (in this case, mostly JavaScript and Java), but also teaching you how to document the code, such as focusing on parameters, responses, and data types. He even talks about style conventions in the documentation, including verb tenses, code formatting, and sentence structures.  <a href="http://bit.ly/reviewcoding4writers">Read more >></a> </description>
        <pubDate>Sun, 13 Nov 2016 00:00:00 -0800</pubDate>
        <link>http://idratherbewriting.com/2016/11/13/review-of-coding-for-writers-peter-gruenbaum-udacity/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2016/11/13/review-of-coding-for-writers-peter-gruenbaum-udacity/</guid>
        
        
        <category>api-doc</category>
        
        <category>beginners</category>
        
      </item>
    
      <item>
        <title>Should you ever apologize for something product-related in your documentation? Looking at Apple's dongle documentation</title>
        <description>Apple's recent dongle fiasco raises an interesting tech comm question: Is there ever a time when you, as a technical writer, should apologize for something product-related in your documentation? I looked at Apple's end-user docs about their ports but didn't see any acknowledgement that they were inconveniencing their users in an extreme way. Instead, the tone was merely straightforward and factual about which adapters you would need. When an issue is controversial or obviously of deep concern to users, documentation should address the issue head-on. You don't need to try to communicate about the issue in an emotional way (though that tone might be  welcome to users), you just need to &lt;i&gt;include&lt;/i&gt; the information, mostly following Redish's documentation-as-conversation model.  <a href="http://bit.ly/apologiesindocs">Read more >></a> </description>
        <pubDate>Sun, 06 Nov 2016 00:00:00 -0700</pubDate>
        <link>http://idratherbewriting.com/2016/11/06/when-should-you-apologize-in-your-documentation/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2016/11/06/when-should-you-apologize-in-your-documentation/</guid>
        
        
        <category>general</category>
        
      </item>
    
      <item>
        <title>How to avoid becoming extinct in your technical writing career</title>
        <description>In contrast to other non-IT professions, the rapidly evolving pace of technology means that our experience a decade ago is practically obsolete. With new platforms, programming languages, workplace methodologies, and other changes coming on the tech scene every year, IT professionals must implement an approach of continual learning to survive.  <a href="http://bit.ly/avoidextincttccareer">Read more >></a> </description>
        <pubDate>Sun, 06 Nov 2016 00:00:00 -0700</pubDate>
        <link>http://idratherbewriting.com/2016/11/06/how-to-avoid-extinction-in-your-technical-writing-career/</link>
        <guid isPermaLink="true">http://idratherbewriting.com/2016/11/06/how-to-avoid-extinction-in-your-technical-writing-career/</guid>
        
        
        <category>general</category>
        
      </item>
    
  </channel>
</rss>
