Apple's new Macbook laptops include a Touch Bar that replaces the function keys at the top of the keyboard. You can program these keys with your own custom functions. I was curious to see what the documentation for the Touch Bar looked like. In looking at the Apple docs, the most interesting element is the image sizes -- the original image sizes are 4 times the size of the shown graphic. This technique helps create a sharp, crisp look to text when the large image is constrained to a smaller size in the browser. However, if you're translating your content, text callouts can be problematic.
In the deliberation about authoring formats -- whether to use Markdown or reStructuredText or DITA (or something else) -- one detail that is frequently overlooked is the importance of the accompanying tool or platform that uses that format. You almost never use these authoring formats alone but rather with a tool that stores, processes, and renders the source into an output. The tool you use with the authoring format is almost as important as the authoring format itself.
Recently MindTouch published a list of the top 25 Content Strategist Influencers. In contrast to previous top influencer lists, this year's list shifts from the term 'tech comm influencer' to 'content strategist influencer'. They also broadened their measures for determining influence, including less online presence and more offline influence, such as conference presentations. I just barely made the list this year. It got me thinking about whether I am in fact a content strategist or a technical writer.
In the latest episode of This Week in Tech (TWIT episode 585), the hosts talk about how confusing Apple's two-factor authentication is compared to Apple's two-step verification. The hosts, who are all tech gurus, had trouble sorting out the difference, and their experience with the service was even more problematic. This naming fail points to a core challenge in tech comm that happens when Marketing's choice of terms makes it difficult or impossible for tech writers to communicate plainly.
What would you do to rebuild trust in your brand after a product disaster like Samsung's exploding phones? I looked at Samsung's recall notice and newsroom articles to see what strategies they employed, but I found the communication brief, plain, and short of any detail that would help rekindle trust. If company's want to gain user trust, they must share more information and details with users, as Dyn did in their company blog posts after the recent DDoS attacks. Particularly, the information the company shares should align with the kind of information users want to see.
Although email may seem somewhat antiquated, it has by far the greatest reach of any online communication method. If you have a Jekyll-based site, here's an easy approach to sending out an email newsletter. This approach involves using a for loop to get a summary of your latest posts and then pushing the content into simple HTML formatting that you can paste into Tinyletter's email template.
Sidebar navigation is one of the more complex components of a documentation site, and it is critical for helping users understand and find documentation. I hacked together a sidebar menu for a doc site that's hosted on a somewhat inflexible platform, using Jekyll to generate the sidebar. Important features of a documentation sidebar include multiple levels of depth, expand/collapse options, accordion effects, fixed navigation, dynamic menu highlighting, and more.
Lately I've been turning my attention away from audio fiction and back into technology podcasts. I'm curious whether looking at the tech comm angle associated with technology news might provide a fruitful angle for blog posts and discussion.
In this presentation, Alisa Bonsignore, a technical communication consultant based in the San Francisco Bay area, talks about how she developed confidence and experience in consulting with clients about writing projects. In the beginning, Alisa started out by apologizing for projects in which she worked excessive numbers of hours for little pay, often trying to meet last-minute requests that required late nights and zapped her work-family balance. But project by project, she started to understand how to interact with clients in a more professional, self-respecting way. Ultimately this helped save her sanity and build a stable income through a reputable business.
Tools are an odd problem in tech comm. On the one hand, companies don't want you to spend hardly any time at all either learning or setting up authoring tools. Preferably, you should already be familiar with the company's tools before being hired. Then after you're hired, companies usually want you to focus on content, not any kind of tool configuration or setup. On the other hand, it seems like almost every company I've been at has needed extensive help with authoring/publishing tool setup and configuration. I am starting to think that my pattern of deep diving into tool sets at companies is indicative of a deeper interest in web development.
The Android documentation is one of the most interesting documentation sites I've seen. To appreciate the site, look at the left sidebar navigation. Not only does it expand and collapse vertically in accordion style, it also moves right and left horizontally into additional level hierarchies. The site authors have made a massive sidebar menu more navigable through JavaScript wizardry.
Since I've been working at Amazon, my tech comm role has shifted more to content curator and publisher than simply author. This shift in roles brings with it some new challenges and responsibilities. Some of the previous scrum methods with agile no longer seem to fit. I'm finding that kanban might align better with my workflow.
Last Monday we had a record turnout at our STC Silicon Valley chapter (with about 40 attendees). The topic was a panel discussion on how to thrive in agile environments as a technical writer. With 5 panelists all from different companies, the perspectives and practices they shared varied a bit, which showed the adaptations different writers and companies have made with agile to make the process work for them. This post contains a full description and recording of the event.
I recently published an article about Swagger in the Autumn 2016 edition of ISTC's magazine, Communicator. ISTC stands for Institute of Scientific and Technical Communicators. My article provides an introduction to using Swagger (now called OpenAPI specification) for publishing your REST API documentation.
Matt Ness, a technical writer at Splunk and a co-organizer for WTD San Francisco, recently gave a presentation to the STC Silicon Valley chapter called Let's Tell a Story: Scenario-Based Documentation. In this presentation, Matt talks about ways to integrate storytelling techniques into documentation, drawing upon his experience as a Dungeons and Dragons player and his player experience from other video game or fantasy worlds. To help users on their journeys and quests, you need a narrative to guide them and a manual to help them overcome obstacles. Video, slides, and audio from the presentation are included in this post.
