Id Rather Be Writing Podcast Feed

I'd Rather Be Writing Podcast Feed

Synopsis

A technical writing podcast about the latest trends and practices in the field of technical communication. Technical communication includes topics like technical writing (software help), information architecture, usability, API documentation, information design, web design, illustration, DITA, structured authoring, visual communication, and more. If youre a technical writer or interested in technical writing, this is the one of few podcasts in this niche. I also have a blog at http://idratherbewriting.com where the podcasts and other blog topics are published.

People who listen this also listen:


Episodes

  • Podcast: Dealing with Project Overload -- Strategies to Manage Overflowing Documentation Tasks
    Podcast: Dealing with Project Overload -- Strategies to Manage Overflowing Documentation Tasks
    02/10/2019

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. I was reading a post on the technical writing sub-Reddit community about dealing with project overload and thought it would be a good topic for a podcast. The Reddit post is In over my head - service docs, user docs, and localization (requesting advice). In part, the topic resonated with me because I’m sort of overloaded myself right now, so I thought it would be good to think through some of these challenges. In the post, “keyboardqueen90” describes how she’s buried in work, her manager doesn’t understand what she does, others underestimate the time required to write docs, requests for more support fall on deaf ears, she doesn’t have time to ramp up on tools/tech or influence design because the docs fully occupy her time, she lacks any champion or advocate at the leadership level, she’s a team of one, and more. My podcast is short, but here’s an even shorter summary. To manage incoming work, especially when it’s spilling over, you need a system or framework. Kanban is one system that attempts to manage flow by limiting the number of incoming items by a fixed amount. This approach seems sensible but doesn’t entirely work for tech docs because not every task is equal nor requires equal time. Scrum, an agile methodology used by engineers for much the same purpose here, is a more common framework for managing the flow of tasks. I described the process for managing tech docs with Scrum in Following Scrum with documentation projects. In short, with Scrum you start by prioritizing the most important items in your backlog. You assign some of the items to a two-week sprint. You assign only as many items as your sprint capacity can handle. In your sprints, try to mix in some “quick win” tasks that are easy to accomplish (because they take an hour or less) but which might not be high-priority. When people scream at you for docs with deadlines the next day, tell them you’ve assigned the work to an upcoming sprint. Thi

  • Podcast: 10 myths about API documentation
    Podcast: 10 myths about API documentation
    29/09/2019

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. 10 myths about API documentation Here are the myths I address in the podcast. You must read source code to write docs. You’ll need to extrapolate sample code from one language to create code samples in another. You must be a former engineer to be competitive in the API doc space. Technical writers usually create the reference material (e.g., OpenAPI spec, Javadoc). Almost all job interviewers care about, when it comes to API doc jobs, is technical know-how. Developers can and will write if you implement a docs-as-code process. Because their role aligns with the audience, with API docs, developers are most suited to be the ones writing for other developers. API documentation and developer documentation are synonymous. Docs that look good are good. People will respect you more if the word “writer” isn’t in your job title. In the podcast, I mentioned this NY Times article: In the Salary Race, Engineers Sprint but English Majors Endure. Your Feedback Here’s a short survey to see if you think these myths are generally true or false. (It would be best if you listened to the podcast first.) You can view the ongoing results here. EMBED_PARAMS = {}; EMBED_PARAMS.surveyID =6879040; EMBED_PARAMS.domain ="//www.questionpro.com"; EMBED_PARAMS.src ="//www.questionpro.com/a/TakeSurvey?tt=WStg1A8jzgU%3D"; EMBED_PARAMS.width ="100%"; EMBED_PARAMS.height = "1200px"; EMBED_PARAMS.border = "hidden"; var contents=new Array() contents[0]=' Sponsored message:Over 40,000 API developers use SwaggerHub to design and document APIs with Swagger (OpenAPI). Learn how SwaggerHub can help improve your team’s API documentation workflow. >Get started for free.' contents[1]=' Sponsored message:SwaggerHub was built by the team behind Swagger to help organizations collaborate on their API design and documentation from one centralized platform. Find out why SwaggerHub is the platform for design and documenti

  • Recording of Tech Comm Trends Presentation (STC Puget Sound chapter)
    Recording of Tech Comm Trends Presentation (STC Puget Sound chapter)
    08/06/2019

    Video Audio Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Slides Presentation description Tech comm trends: Providing value as a generalist in a sea of specialists Trends in technical communication can be hard to decipher, even when looking at data. But one underlying trend is that technology seems to be getting more specialized and complex. This trend toward specialization is driving up the value of technical knowledge, making it more prized than writing skills. To handle the complexity, technical writers may find that they are playing increasingly collaborative roles with engineers to create the needed documentation. To drive up their value in organizations, technical writers should look for ways to collaborate more skillfully with engineers in creating content. Takeaways: The growing complexity in the technology landscape is ratcheting up the importance of technical knowledge in organizations, overshadowing writing skills. Creating documentation is becoming more of a collaborative effort with engineers due to the increasing level of complexity and specialization in the technology landscape. Documentation processes are moving towards docs-as-code tools in part because engineers are more involved in the authoring processes, and they prefer to use tools they’re familiar with. Venue Details about the event from STC Puget sound are here. Date: May 21, 2019 Time: 6:00 pm - 8:30 pm Venue: University of Washington – The Tower 4333 Brooklyn Ave NE Seattle, WA 98195 var contents=new Array() contents[0]=' Sponsored message:Over 40,000 API developers use SwaggerHub to design and document APIs with Swagger (OpenAPI). Learn how SwaggerHub can help improve your team’s API documentation workflow. >Get started for free.' contents[1]=' Sponsored message:SwaggerHub was built by the team behind Swagger to help organizations collaborate on their API design and documentation from one centralized platform. Find out why Swagge

  • Crash course in API documentation -- a one-hour video
    Crash course in API documentation -- a one-hour video
    16/05/2019

    I mentioned in my STC Summit slide links post that I recorded my “Intro to API documentation” presentation using the on-board mic on my laptop, and that STC let me post it on my blog. The sound in the recording isn’t great, but if you’re interested, the video is available below. Someone who recently watched the video wrote me to say, Btw, the one hour crash course was great. I just watched it. This will be my go-to-link to send people interested in the space. It’s a lot of content for a beginner, but its variety and your talking more holistically about the workflow/mindset made it a great introduction. Bravo! In this introductory presentation, I explore Sendgrid as a good example of API docs. For more API documentation recordings, see Video recordings of API doc workshops. I also rendered this video as a standalone audio file in case you prefer it this way: Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. var contents=new Array() contents[0]=' Sponsored message:Over 40,000 API developers use SwaggerHub to design and document APIs with Swagger (OpenAPI). Learn how SwaggerHub can help improve your team’s API documentation workflow. >Get started for free.' contents[1]=' Sponsored message:SwaggerHub was built by the team behind Swagger to help organizations collaborate on their API design and documentation from one centralized platform. Find out why SwaggerHub is the platform for design and documenting APIs with Swagger. >Get started for free.' contents[2]=' Sponsored message:SwaggerHub brings together all the power of the open source Swagger tooling into one integrated platform for designing and documenting APIs with Swagger (OpenAPI). >Get started for free.' contents[3]=' Sponsored message:SwaggerHub is an integrated API design and documentation platform, built for teams to drive consistency and discipline across the API development workflow. >Get started for free.' contents[4]=' Sponsored message:Documenting APIs with Swagger? SwaggerHub lets

  • Corporate exodus narratives: A close look at the tension between the corporation and academia
    Corporate exodus narratives: A close look at the tension between the corporation and academia
    01/03/2019

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Going to an academic conference Last year I started a project aimed at bridging the gap between practitioners and academics, and after a number of conversations with one academic, I was invited to speak at the Symposium for Communicating Complex Information, which is a small conference (held in Louisiana this year) that consists almost entirely of academics. I’m always intrigued at opportunities to attend conferences I’ve never been to before, especially to interact with people I’m not accustomed to interacting with, so I thought a two-day immersion with academics might be fun. I agreed to present on trends in technical communication. The conference took place in Louisiana Tech University’s Academic Success Center in Bossier City (just outside of Shreveport), LA. Presenters followed a format where they spoke for just 15 minutes and then transitioned to 15-minute Q&A with the audience. The presentations demonstrated the breadth of the tech comm discipline, and covered topics as varied as establishing credibility on Facebook to Burkesian dynamics in collaborative writing to wayfinding in hospital emergency departments and more. There wasn’t much time to socialize during the conference, but as the day ended and dinner plans were made, a large group ventured over to a nearby Mexican restaurant where, I soon learned, as is the case at most dinner events at conferences, when the right people get together offline, the real conversations would begin. During a lengthy dinner that lasted two-plus hours, I sat next to academics from various institutions and in different phases of their career — some tenured, others associate, others adjunct, others just embarking on their own PhD journey. Overall, I found a greater understanding of academics that I hadn’t grasped previously. If I can paint a few broad strokes here, it might help more practitioners get a better understanding of the tech comm academic — their chal

  • Recording and slides for my trends presentation at the Symposium for Communicating Complex Information (SCCI)
    Recording and slides for my trends presentation at the Symposium for Communicating Complex Information (SCCI)
    24/02/2019

    About the Symposium for Communicating Complex Information You can view the conference program and schedule for the Symposium for Communicating Complex Information here. My presentation on trends My presentation was a keynote on tech comm trends called Tech Comm Trends: Providing Value as a Generalist in a Sea of Specialists. You can view my slides at trends-growing-disproportions. The recording of my presentation is available here: If you just want to listen to the audio, you can listen here: Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Latest thoughts on trends Although I’ve written and spoken about trends several times this year, I shifted focuses a bit in this presentation. I abandon the argument that technical skills are in such high demand because the technology landscape is getting more complex. (It might be true, but it’s a hard argument to make, and I’m not so sure about it anymore given some responses in my ongoing Engineers writing docs survey.) Instead, I argue that technical writers are supporting increasing numbers of engineers. I dig out more specific employment data from the BLS showing that the job growth between 2010 to 2016 for software developers was 37%, but for technical writers was just 6%. Additionally, in informal surveys, 76% of tech writers agree that the ratio between engineers and tech writers is getting more lopsided each year in favor of engineers. Together, this data presents an alarming trend where tech writers are becoming dwarfed by the explosion of engineers. This trend also aligns with my own experiences in the workplace where I seem to be getting spread thinner and thinner. What happens when tech writers must suddenly start supporting twice the number of engineers or more? First, I think tech writers will play more project management roles, orchestrating publishing workflows for other authors, including engineers. Engineers who contribute to docs are also much more likely to use docs-as-code tooling and

  • How to become a 10X technical writer in the workplace
    How to become a 10X technical writer in the workplace
    07/02/2019

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Background The term “10X engineer” (pronounced 10-ex) is sometimes used to describe engineers who are ten times more productive than other engineers. It describes someone who is simply more efficient, capable, and accomplishes more than others. The Silicon Valley Dictionary explains: “10X-engineer”: A concept sometimes used in Silicon Valley to describe an engineer that is 10X more productive than an average engineer although the 10X metric is figurative. Sometimes referred to as “Ninjas”, these engineers are highly sought after by all tech companies Jim: You gave me 100 resumes but none of these guys are 10X engineers. Why hire a few of these guys to slow us down when a 10X engineer is so much more productive? For more on this term, see 10X Engineer Series. What has prompted my interest in becoming a 10X technical writer? Well, lately I feel like I’ve let my edge slip a bit at work. I don’t feel as influential and effective in the workplace as I feel online through my blog and podcast. I’ll return to this idea a bit later in this post (in Tip #5), but to get moving towards the 10X goal, let me throw out a few simple strategies first. (Note: In an earlier version of this post, I used the term “rock star” instead of 10X, but some commenters pointed out that “rock star” is a gendered term that is somewhat problematic. I like 10X better anyway, as it more closely gets to my larger desire, which is increased productivity, not increased notoriety. In the revision of this post, I expanded the content in many places, approximately doubling the length and replacing a tip.) Tip #1: Record your meetings with engineers to listen again later With developer doc projects, engineers can quickly jump into excessive jargon and assumptions about your technical knowledge and familiarity with the code. This can be like a firehose of information that is too overwhelming to comprehend fully at the time (at least not t

  • How to motivate users to provide feedback: Show that youre listening to their input
    How to motivate users to provide feedback: Show that you're listening to their input
    01/02/2019

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Our original feedback form A few months ago, we added a feedback form to our Appstore docs at work. Right below the title on every page, we added an easily visible button that says “Submit Feedback.” The button opens a Qualtrics form where users can submit ratings and comments. This initial feedback form looked like this: Not a lot of feedback came in through this form — maybe one legitimate comment a day on average. Our metrics say about a thousand people visit the docs a day, so why weren’t more people leaving feedback? I doubted they were all finding exactly what they needed and leaving happy and satisfied. Designing for feedback I wanted to tweak my feedback form to maximize the number of responses. I considered questions like these: What factors influence whether users decide to leave feedback? Are there design implementations that might double or triple the responses? How could we ramp up the percentage of people who leave feedback? I was reading some research by Donal Kavanagh on this subject. Kavanagh is a student in an MA program at the University of Limerick (Ireland). I’ll publish a lengthy guest post from him next week (stay tuned). One point in his research is that users are more apt to provide feedback if they feel their feedback is listened to and acted upon. Donal writes, … a feedback feature should engender in the user the belief that their feedback will be acted upon. … A lack of acknowledgement of users’ feedback and even less communication as to how it will be used to improve documentation mean that users will not believe that their feedback is valued and will not understand their place in a process that is ultimately for their benefit, i.e. the continuous improvement of the online help. In other words, the more users feel that their feedback is listened to and acted upon, the more likely users are to give feedback. This point hardly needs to be argued, as we confir

  • Recording for Menlo Park API documentation workshop now available -- and some thoughts on using cardioid versus omnidirectional microphones for recording
    Recording for Menlo Park API documentation workshop now available -- and some thoughts on using cardioid versus omnidirectional microphones for recording
    04/12/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. I published the recording of the API documentation workshop that I recently gave in Menlo Park (on Nov 8, 2018). You can view the recordings on my API documentation site here: Recorded Video Presentations. This API documentation workshop (which I mentioned earlier) was a full-day workshop, so there are more than 5 hours of recorded material here. If you’re really into workshop recordings, you can also listen to the Denver API workshop that I gave earlier this year (March 2018). Notes on recording – cardioid versus omnidirectional For the Denver workshop, I used a Movo cardioid lapel mic. However, I think cardioid was the wrong choice because it requires you to have a consistent distance from the mic. When you’re presenting, you might turn your head from side to side or up or down. Cardioid mics are very sensitive to changes in position like this, and the volume fluctuated a lot as a result. Also, the audio sounded flat to me (though I fixed that somewhat in post-production following this technique). For the Menlo Park workshop, I used a Shure omnidirectional lapel mic. Omnidirectional worked a bit better, I think. The sound capture was more of a consistent volume, and my voice didn’t sound as flat. I also applied some post-production enhancements to the audio. However, for video I mistakenly chose to capture the projector rather than my own computer screen, so the resolution isn’t as good as I hoped. Both the Movo and Shure lapel mics have XLR inputs that I attached to a Zoom H4n Pro recorder, which I then put in my pocket (the setup is bulky). The microphone I use to record my blog posts (like this one) is a Shure RE20 cardioid microphone, commonly used in broadcasting. While it is a cardioid microphone, it’s fine because when you’re sitting at a desk recording something, you can keep your mouth a consistent distance to the microphone. And close-up cardioid capture is superior to omnidirectional anyday.

  • New post in Simplifying Complexity series -- Principle 11: Be both a generalist and specialist through your technical acuity
    New post in Simplifying Complexity series -- Principle 11: Be both a generalist and specialist through your technical acuity
    30/11/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. You can read the essay here: Principle 11: Be both a generalist and specialist through your technical acuity. How exactly does the topic of being a generalist or specialist tie in with simplifying complexity? Here’s an excerpt: Do technical writers, who are typically only familiar with the subjects we write about, need to become engineer-like specialists, focusing in on a couple of domains in depth, so that we can write, edit, and publish more knowledgeably in these domains? Is specialization the only way to handle complexity? Will I need to become a specialist to survive as a technical writer in the future? Note that this content has undergone multiple iterations: First version Second version Third version In this third version, I expanded the research in places, provided better organization in my analysis, and tried to integrate some more personal stories in places. I also narrated it as a podcast. Overall, this still remains a challenging topic, and the length of the article probably shows. Also, if you’re viewing the essay on my Simplifying Complexity site, you’ll notice that I increased the font a bit. I don’t know if my eyesight is getting worse or what, but while reading it I kept squinting and decided to simply make the text more readable. I feel like I’ve let this essay occupy quite a bit of attention on my blog lately. With each iteration, I’ve gathered feedback from you through surveys and used the information to write the next version. I don’t always push content through multiple revisions like this. Many blog posts are one-and-done efforts. But this particular topic has been the focus of multiple presentations this year, so it receives continual attention and improvements.

  • How to avoid being a secretary for engineers
    How to avoid being a secretary for engineers
    19/11/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Critical inquiry versus vocational knowledge Lately I’ve been thinking about two types of knowledge: intellectual knowledge versus vocational knowledge. Or rather, critical inquiry versus technical how-to. Or theoretical knowledge versus practical knowledge. In short, asking why versus asking how or what. I’m not entirely sure how to characterize the differences, but the difference in focus has contributed to some angst in my tech writing career lately. Rewind a bit to my previous posts on trends (such as this one or this earlier one), and you’ll find that I’ve been wrestling with the question of whether to be a generalist or specialist. Regardless of any generalist/specialist outcomes around research and what employers want, etc., it’s hard to escape this one critical fact: you can’t write without knowledge. Unless you have a more solid technical grounding, you just can’t write much about those topics. Consequently, in order to be a rock star technical writer (rather than just a supporting editor/publisher for SME contributors), you have to move into the technical knowledge domain to some extent. Not necessarily becoming a specialist, but you have to accrue more understanding of the subject than a generalist might have. With this realization, I decided to sink some dedicated time to simply learning tech every day. For a week at work, I decided that I would do 3 tech pomodoros at the start of each day (a pomodoro is a 20 minute session of focused learning — it’s my approach to learning). Given the many interruptions and needed emails to respond to or meetings or fires to extinguish, etc., I often wouldn’t finish my 3 tech pomodoros until noon. After a week of this, I found that my productivity plummeted at work. It seemed I wasn’t accomplishing nearly the same as what I did previously. So I decided to put the tech learning on pause for a bit to catch up and make more progress on some high-priority document

  • Upcoming full-day API documentation workshop in Menlo Park
    Upcoming full-day API documentation workshop in Menlo Park
    31/10/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. You can learn more about the API documentation workshop on eventbright here. The workshop will be held from 8am to 5pm at the Quadrus Conference Center. The workshop will follow my API documentation course closely. In fact, I’ve been updating my workshop activities a bit in preparation for the course. If you’re interested, be sure to sign up. Let me know if you have any questions. var contents=new Array() contents[0]=' Sponsored message:Over 40,000 API developers use SwaggerHub to design and document APIs with Swagger (OpenAPI). Learn how SwaggerHub can help improve your team’s API documentation workflow. >Get started for free.' contents[1]=' Sponsored message:SwaggerHub was built by the team behind Swagger to help organizations collaborate on their API design and documentation from one centralized platform. Find out why SwaggerHub is the platform for design and documenting APIs with Swagger. >Get started for free.' contents[2]=' Sponsored message:SwaggerHub brings together all the power of the open source Swagger tooling into one integrated platform for designing and documenting APIs with Swagger (OpenAPI). >Get started for free.' contents[3]=' Sponsored message:SwaggerHub is an integrated API design and documentation platform, built for teams to drive consistency and discipline across the API development workflow. >Get started for free.' contents[4]=' Sponsored message:Documenting APIs with Swagger? SwaggerHub lets you generate API documentation that’s securely hosted and fully interactive. Import an existing Swagger definition, or start a new API project from right within your browser, no setup required. >Get started for free.' var i=0 //variable used to contain controlled random number var random //while all of array elements haven't been cycled thru while (i

  • Preferring technical acuity over specialized knowledge
    Preferring technical acuity over specialized knowledge
    24/10/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. The unresolved debate between being a specialist or generalist After I gave a recent presentation on trends, some of the attendees felt I left the dilemma between being a specialist or a generalist unresolved. Some said, “So, should I be a specialist or a generalist, and if I specialize, what should I focus on?” Others were incensed that I wasn’t considering language expertise to count as specialized knowledge. I knew this was a controversial subject, and I would no doubt anger people off because to suggest that their writing expertise doesn’t count as specialized knowledge in the same light as engineering specializations. So there are a few loose ends that I’d like to resolve in this trends presentation before I give it again. Overall, in the Q&A after my session, attendees seemed to come to the conclusion that technical acuity was more important than specialized knowledge, and that it was better than being a generalist as well. In hindsight, my portrayal of the dilemma between being a specialist or generalist was an either/or fallacy. A third option — “technical acuity” — wasn’t something I weighed and considered. What is technical acuity? What do we mean by “technical acuity”? Someone with specialized knowledge might know Python in and out, but someone with technical acuity possesses a technical mindset. With this technical mindset, he or she might be inclined to look at system inputs and outputs, at algorithms that drive application logic, or more. Maybe he or she has a systematic patience for troubleshooting by comparing working code against broken code in a line-by-line fashion, or other troubleshooting insights. In other words, the person with technical acuity might not know Python (perhaps what a hiring manager wants), but his or her in-depth knowledge of C# and, say, big data analysis might have prepared the person with the technical mindset needed to grok the Python info that’s needed in a p

  • If writing is no longer a marketable skill, what is?
    If writing is no longer a marketable skill, what is?
    09/08/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Site metrics gives insight about the skills people want The other day I looked at site metrics for my two sub-projects: API documentation and Simplifying Complexity. The traffic on my Simplifying Complexity site is only about 1.73% of the overall traffic on my site — here the traffic for Simplifying Complexity for the past 3 months: In contrast, the traffic on my API documentation site (for the past 3 months) is about 60% of my site’s overall traffic: How do you interpret this disparity? It seems pretty clear that one type of content is sought after more than the other. Granted, the API doc site has more pages (96 instead of 11) and it’s been around longer, and I’ve given lots of API doc presentations referring to it. But I think it’s more than that. People seek to learn about skills they lack. API documentation is one of these sought-after skills; simplifying complexity isn’t a skill people search out. Further, I’m guessing that most of the traffic to that API doc site involves developers looking for tips on how to document their API, not technical writers. This is because the traffic is outpacing the regular traffic on my blog. Also, I get regular requests to teach workshops and even classes on API documentation, but almost nothing on simplifying complexity (though granted, I haven’t marketed it or even finished that site). But if I were to try to package up the content I have so far about simplifying complexity, I’m not sure how I would market it. Workshops seem geared towards teaching specific skills that can be packaged and sold. Is simplifying complexity a skill that fits into that category? Workshops tend to focus on more concrete tasks, whereas the topics in simplifying complexity align more with critical thinking and higher-level analysis. To give you an idea of the skills focus in workshops, here are some titles from workshops at the recent STC Summit, Lavacon, and other conferences: Str

  • My conflicted thoughts about the decentralized web (while taking the Census of Technical Communicators survey)
    My conflicted thoughts about the decentralized web (while taking the Census of Technical Communicators survey)
    06/08/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. About the Census Survey Researchers at Concordia University (including Saul Carliner) are conducting a “Census of Technical Communicators.” The survey takes a while to complete (20 min.), but it’s well worth the time, and I’m fascinated to see the upcoming results. You can take the survey here: Census of Technical Communicators Survey. Some of the census questions will prompt some serious reflection. For example, these two questions: As a technical writer, where do you feel the most pain or friction? How do technical writers in your organization feel the most pain or friction? There’s also an entire section about resources you consult for professional development, including blogs. The survey names several blogs specifically, including the one you’re reading: Advertising’s impact on the web’s original ideals I’m excited to see blogs listed as sources for professional development here, because in my view it celebrates the decentralization of the web. The very fact that I would be listed among other sources such as peer-reviewed journals, formal conferences, or other trade magazines for professional development suggests that the dynamics of the web have destabilized the hierarchy of information in interesting ways. Given that a Decentralized Web Summit just ended (I didn’t attend but there are recordings), it’s worth making a few extra notes on decentralization. In a post summarizing highlights from the conference, Computing summarizes takeaways from two key speakers (the speakers were Mitchell Baker from the Mozilla Foundation and Brewster Kahle from the Internet Archive). Computing explains: The ideology of the web’s early pioneers, according to Baker, was free software and open source. “Money was considered evil,” she said. So when companies came in to commercialize the internet, the original architects were unprepared. “Advertising is the internet’s original sin,” Kahle told the packed room.

  • Articulating stories that influence product adoption (new article in Simplifying Complexity series)
    Articulating stories that influence product adoption (new article in Simplifying Complexity series)
    31/07/2018

    Listen to this post: You can download the MP3 file, subscribe in iTunes, or listen with Stitcher. Here’s a summary: In any documentation scenario, there are usually at least two competing stories: the company’s story about their product, and the user’s story. The two stories don’t always align. For a product or feature to be successful, the overall story about that product needs to align with the user’s story. These stories aren’t always apparent, and learning to see them constitutes a complex task, since you have to reduce a sea of action and noise down to its essence. The misalignment of these stories often explains why products fail. Continue reading: Articulating the invisible stories that influence product adoption or rejection

Informações: