Enjoy Fiona Hanington’s debut as a member of the TechWhirl SWU, Can I Be an Agile Technical Communicator When My Team Is Not? (Hint, her answer is yes, with lots of good how-to advice). Stake out your territory in the three-way debate (that would be Tom Johnson, Sarah O’Keefe and Mark Baker) by voting and posting a comment to this week’s poll which asks whether structured authoring and web content delivery can co-exist. And Roger Renteria has an answer for anyone looking for ways to improve their use of tables and graphs, with his STC Summit Summary.

And you can close out your week by seeing what everyone else has to say about tech comm, content strategy, user experience, and customer experience management by way of Craig Cardimon’s Tech Writer This Week.  Some of those folks like to ask and answer their own questions, but it’s always fascinating and educational.

Take a few minutes to complete the Adobe WYSWYG survey.  Then safe travels as you enjoy the holiday here in the US. And just enjoy your weekend no matter where you are.

-Connie and the gang at TechWhirl

	Tech Writer This Week for May 23, 2013 I enjoy working in technical communication, so why not stretch my skills a bit for marcom? There must be more to this than I thought, because Sarah O’Keefe (scriptorium.com) is hosting a webcast on the Cold War between techcomm and marcom. I signed up because a good writer should be able to tackle any kind of writing. Then I went looking for more tech comm and related goodness for Tech Writer This Week. I found lots…
	Technical Communication Poll: Can Structured Authoring and Web Content Delivery Co-exist? Three of the most respected names in technical communication, —Tom Johnson (I’d Rather Be Writing), Sarah O’Keefe (Scriptorium), and Mark Baker (Every Page is Page One) – have been having a spirited online discussion over the role of structured authoring and the World Wide Web. Now mind you, it’s been is a very respectful disagreement with each of them acknowledging each other’s insightful comments along the way. Essentially, their arguments boil down to the choice of one little word: Or, And or For… inserted between structured authoring and web content delivery.
	Summit Summary: Jean-luc Doumont on Conveying Messages with Graphs Ever want to learn how to make better graphs? Check out a Jean-luc Doumont presentation sometime. In this STC Summit presentation, based on his book “Trees, Maps, and Theorems, about ‘effective communication for rational minds’”, he discussed how to choose the right graph and optimize the display to send the right kind of message.
	Can I Be an Agile Technical Communicator When My Team Is Not? I work for Ericsson, a large multi-national company, and we’re in the process of moving the software development framework in our business units to what is known as Agile development. Some units are there already. Others, like ours, are just starting to look into it. I don’t know exactly when my team will make the transition, but I recently went through some training and was inspired to begin the journey towards being an Agile technical communicator.

Technical Communication News:

• Xyleme Updates Industry-leading LCMS with New Publishing Tools
• Etteplan | Tedopres and MadCap Software Partner for Simplified Technical English Single-Sourcing

Social Media and the Chance to Follow TechWhirl:

• Our Google Plus Page – what’s happening behind the scenes | http://goo.gl/SO0R4
• Will you be our Friend? Please, you know you want to click | http://goo.gl/tDrW7
• Want all this TechWhirl goodness a few characters @ a time | http://goo.gl/itjDg
• Updates from TechWhirl delivered to your email in box | http://bit.ly/tjshxU
• Or, try our RSS feed (great on Flipboard) | http://goo.gl/msLzu

Editor’s Note: For readers who want to enjoy Tech Writer This Week for May 23 via RSS without all the formatting issues, we’ve made it a bit easier by posting the introductory content here, and a link to the Storify curated content.

As a technical writer, I take most jobs that come my way, as long as they enrich my career path. One such task that I sought out and volunteered for involved marketing communications (marcom). I enjoy working in technical communication, so why not stretch my skills a bit for marcom? There must be more to this than I thought, because Sarah O’Keefe (scriptorium.com) is hosting a webcast on the Cold War between techcomm and marcom.  Attendance is free but registration is required. I signed up because a good writer should be able to tackle any kind of writing.

Elsewhere in Technical Communications, Bill Kerschaum (intextwriting.com) shares a great cheat sheet chock full of false phrases and style slip-ups. Mark Baker (everypageispageone.com) closes this section with a intriguing suggestion on how to do structured writing especially for the web.

In Content Strategy & Curation, Margot Bloomstein (uie.com) shares an excerpt from her book, “Content Strategy at Work,” discussing how companies prioritize their content initiatives. Tatiania Liubarets (writtent.com) lists 15 facts about content curation. Ron VanPeursem (business2comunity.com) discusses five definitions of content curation, courtesy of Nathan Weller, that I hadn’t read before. Sara Wachter-Boettcher (www.sarawb.com) recaps a slideshow on how to design around existing content. And we close out with Susan Silver’s (circquedumot.com) approach to content strategy research, using a funnel analogy.

To kick off User Experience, the UX Magazine Staff, Christopher Noessel, and Nathan Shedroff (uxmag.com) tell us what interaction design can learn from Star Trek. Nick Switzer (uxmag.com) shows us how to create a better user experience. Joseph Dickerson (uxmag.com) reveals the greatest secrets of UX, some of which were a surprise to me. Bo Amidor (ux.walkme.com) closes this section by giving us three UX objectives to consider.

In Customer Experience Management, Jeff Hora (cmswire.com) explores the concept of a customer pilgrimage, rather than a customer journey. Then Sarah Reedy (lightreading.com) points out that support techs are the face of the company, and Mac Wheeler (customercentric.info) gets inspired about the customer experience maturity model.

Career and Life offers nifty tricks of telling if you should use “its” or “it’s,” courtesy of Techritesolutions (techritesolutions.wordpress.com). Rhonda Bracey (cybertext.wordpress.com) shares a writing tip regarding “that” versus “which.” The archives of “Corrigo” (www.stc-techedit.org/tiki-index.php?page=Corrigo+Archive), the newsletter of the STC’s Technical Editing Special Interest Group, are now available online. This what nerds like me do on Sunday afternoons! Writing Assistance (www.writingassist.com) closes this section with commentary on taking risks as a writer.

Continue to Tech Writer This Week on Storify.

Three of the most respected names in technical communication, Tom Johnson (I’d Rather Be Writing), Sarah O’Keefe (Scriptorium), and Mark Baker (Every Page is Page One), have been having a spirited online discussion over the role of structured authoring and the World Wide Web. Now mind you, it’s been is a very respectful disagreement with each of them acknowledging each other’s insightful comments along the way. Essentially, their arguments boil down to the choice of one little word: Or, And or For… inserted between structured authoring and web content delivery.

Never one to miss a controversy, we thought this would be good fodder for his week’s poll question so that you can weigh in on their discussion.  After all, you deal with decisions on output (PDF, web, EPUB, etc.), workflows (collaborative authoring, approvals and production), and creation style (voice, tone, approach and purpose) every day.

To begin with Tom blogs about some key questions and issues he has with choosing structured authoring as an approach when output is web content, after having listened to Scriptorium’s webinar on the state of the tech comm industry. Structured Authoring Versus the Web? asks whether the advantages gained from structured authoring can make up for its apparent lack of a web-friendly output format. He believes that print outputs are fast becoming obsolete; that with the advent of cloud-based subscriptions, versioning of online help is also on the wane; and that structured authoring can diminish the natural flow of content.

Sarah takes issue with a number of Tom’s premises in Structured authoring AND the web. She questions whether any significant number of companies are producing SaaS only, and suggests that an agile methodology is irrelevant to the underlying question of whether a company chooses a print output. In rebutting Tom’s points about SME collaboration, platforms, browser-based editing and such, she makes her key point: overall business requirements should drive authoring approach, outputs, tools AND formats, rather than an author-centric case for web-only outputs that might negate the need for structured authoring methodology.

Finally, Mark weighs in suggesting that they’re looking in the wrong direction when asking the question, and frames his position in Structured Writing FOR the Web. Mark recognizes that structured authoring as an approach arose from the need in many organizations to single-source or to reuse content (or both), in a document/print-centric paradigm. Most companies who move to structured authoring do so for the benefits of single-sourcing and reuse, thinking of the web as a secondary medium, after all the print and PDF considerations are fulfilled.  Current structured authoring solutions (DITA, DocBook, etc.) work from this premise as well. Mark sees that most users today look to the web first, and a new approach to structured authoring will have to focus on the requirements of web-ready content first.

So what do you think? Is structured authoring too restrictive to integrate with the dynamic requirements of web content today? Will the tools evolve to allow a model that makes structured authoring easier in web-only environments?  Will we ever truly move away from print and app-based help?

Please vote in our poll and then post a comment and let us know what kind of environment you’re working in currently, and how this discussion impacts your tools and workflow decisions. What’s the practical implication for you now, and two years down the road? Both the vendors and the pundits are paying attention, so make your voice heard.

Jean-luc began by showing us how we can be visual instead of verbal with graphs by stepping back and analyzing how we use the wrong graphs for displaying data. He suggested that we don’t give graphs a structure like we would give papers and speeches, but to use labels, legends, and colors correctly. For example, using proximity when adding labels to lines, charts, and bars and avoid legends or sequential order when possible.

He explained that graphs have to be intuitive for the reader to understand quickly and easily. Show the reader the information, rather than asking the reader to decipher color codes, shapes, or confusing labels to then understand the data. Give them the data. To Jean-luc, a best practice for graphs and charts recommends that we keep only the relevant labels and avoid mentioning the color in the caption. He repeatedly emphasized that technical communicators should not use 3D scatter plots because it isn’t humanly possible to chart a specific point in space on an X,Y,Z graph. Again, the intent is to design the graph to show a message.

He provided some excellent tips for fixing graphs when using PowerPoint. Most column charts can be easily converted to bar charts, which can be a better way to compare lengths. Also, along with comparing numbers in a bar chart, the bars must start from 0. When you chop the axis numbers, you can greatly confuse readers—who may think that one set of data is extremely different than another, when the difference is really minimal, and more obvious if the bars were not cut.

Jean-Luc concluded with some frank commentary on examples of what to avoid, and frank guidance on how to can create better graphs without misrepresenting the data. His book Trees, Maps, and Theorems, about “effective communication for rational minds,” can be ordered online at http://www.treesmapsandtheorems.com/. I highly recommend visiting his Facebook page at https://www.facebook.com/principiae, on which he shares his witty opinions about signs, graphs, and interfaces.

My question after the training was this: Do I need to wait for the rest of my team to go Agile before I can? Or are there aspects of the Agile methodology that I can incorporate into my work now, as an individual?

What Agile is

Agile is a customer-focused approach to developing software that emphasizes iterative development, responsiveness to change, rapid turnaround, cross-functional collaboration, lightweight processes, and communication and transparency. Perhaps surprisingly, the Agile methodology creates heated debate in the technical communication community. Because Agile upends familiar development practices, many technical communicators wonder how just how we fit into the model. We hear many asking if it’s possible to be an Agile technical communicator.

The Agile Manifesto

The main values of Agile development are set out in the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The Typical Agile Development Process

The typical Agile development process presents challenges to the technical communicator

The actual implementation of an Agile project varies from place to place. In a fairly typical model, the cycle begins with a prioritized set of customer requirements. These requirements are usually written in the form of user stories, which take the simple form: “As a [user], I want to [x].” For example, “As a system administrator, I want to change my password.”

A cross-functional Agile team forms, which typically includes the product owner (who represents the customer), a project manager, one or more developers, one or more testers, and—maybe!—a technical communicator. An Agile team ideally has no more than 10 members.

The team takes the highest priority stories into a sprint, which is a time-limited development cycle that typically lasts no more than a month. Remaining stories become the product backlog, to be addressed in future sprints.

Each sprint begins with a planning phase that breaks the stories into manageable tasks that can be assigned to team members. After this, the team gets to work, meeting briefly every day to assess progress. Most Agile teams do test-driven development, where the testers work closely with the developers to ensure that the functionality is working properly right from the start. When tasks aren’t progressing, the regular meetings make this immediately clear. Work is reassigned, reprioritized, or even removed from the sprint altogether if necessary. And because the product owner, who represents the customer, is a key part of the small team, everyone hears immediately about any changes to customer priorities. Likewise, the product owner sees when there are roadblocks in the development environment and can reset customer expectations as needed. Constant communication eliminates the chance for surprises for anyone at the end of the sprint.

After the sprint, the team holds two important meetings. First, the team holds a review meeting in which they demonstrate working software to stakeholders—those outside of the Agile team. This meeting is usually when funding decisions are made for upcoming sprints. Finally, the team holds a post-mortem meeting, where they discuss what went well and what did not during the sprint. This retrospective allows the team to learn for future sprints. For this reason, it’s ideal when the same people can continue working together on the same Agile team from sprint to sprint.

In my slight exposure to Agile at my workplace, I have not yet seen a technical communicator assigned solely to one Agile team (unlike developers and testers, who tend to be dedicated to one team at a time). Working with multiple development teams is not new for most of us, of course. What is new, however, is the regular, close communication with all relevant parties throughout the cycle.

What Agile is not

Many techniques, tools, and buzzwords are associated with Agile: pair programming, stand-up meetings, cross-functional teams, burn-down lists, scrum masters, and so on. But these simply represent ways to work toward the values in the Agile Manifesto — they are neither necessary nor sufficient for Agile. So even though I can’t yet attend stand-up meetings or participate in a cross-functional Agile team, I have plenty of opportunity to become more Agile-esque and therefore work more effectively.

How do we fit into the process?

The prospect of moving to Agile development can raise a lot of questions for technical communicators:

• How will we manage without the usual project artifacts, like in-depth feature specifications, that we rely on to plan our work?
• How do we balance workload and handle context-shifting if we are assigned to more than one Agile team?
• How do we participate in the stand-up meetings if we are not in the same physical location as the rest of our team?
• If we’re constantly working in sprints, how do we schedule the maintenance and general quality-improvement work required for the upkeep of any documentation library?
• When do we work on documents that are not tied to user stories?
• How do we budget? If we’re not estimating by estimated page count at the outset and instead are allocating a percentage of our time to the Agile team for the number of days in the sprint, how do we account for varying amounts of content required?

I haven’t yet seen Agile in practice and so am not going to attempt to answer these questions now. They are important questions, however, and ones that my publications department is considering as we prepare to enter the new development environment. We hope to have answers in the next few months.  In the meantime…

Can I be Agile if my team isn’t there yet?

As a technical communicator, I follow the development environment I work in. In my unit, we currently work in a traditional “waterfall” environment: first requirements, then design, then execution, then testing, then bug fixing, then beta release, then more bug fixing, then a commercial release. I absolutely must adhere to this structure. I have certain deliverables due at the various stages along the way, and — likewise — I rely on planning documents and other artifacts from other groups. I can’t ignore this structure even if I want to. For the most part, then, I must wait for my unit to become Agile before I can truly be an Agile technical communicator myself.

Even if my team follows a waterfall development process, I can be an Agile technical communicator

But even though the milestones of the waterfall schedule rule my project and therefore dictate my activities, I can adopt several practices to become more Agile, on my own. Many of these are really simple, common-sense ideas.

1. Remember the customer

Because Agile requirements are written in the form of user stories, everyone on an Agile team is focussed on the customer needs.

Customer focus, or user advocacy, is hardly a new attitude for many technical communicators. Certainly, I have colleagues who complain of being the only user advocates on a development team, a feeling shared by many throughout the tech comm community. Most of us welcome such an approach to defining requirements!  For example, we may ask: “Is the customer better served by a description of each and every widget on the user interface, or by instructions on how to complete the essential tasks?” Technical communicators already ask such questions every day, questions that align perfectly with the Agile philosophy.

2. Divide work into small tasks

In the planning phase, Agile teams break the user stories into smaller tasks that can be completed within a sprint. Tasks too large for a sprint are subdivided. This approach:

• Gives greater visibility into the work to be done
• Helps reveal which tasks might be blocking other tasks
• Allows work to be divided among team members
• Makes estimates more accurate
• Gives the team a sense of accomplishment as tasks move from “in progress” to “done”

Whether or not I am on an Agile team, such a strategy helps me stay on track, be transparent, and more easily hand-off or reschedule tasks when I am behind schedule. I have already started looking at my work this way. For instance, instead of a large task called “do peer reviews,” ( which might be 8 hours, 24 hours, or 72 hours of work—who knows?!), I now list the individual documents I have to review. And I list them publicly and have only one or two on the go at a time.

3. Use a task board

The task board is the single most important information radiator that an Agile team has.              – Tom Perry

A public, tangible (that is, non-electronic) task board plays a key role in many Agile development environments. In its simplest form, the board shows task progress. Team members consult the board every day to move sticky notes, evaluate progress, and adjust estimates.

Because the board is public and updated daily by those doing the work, it increases the project’s transparency and the team’s accountability, and it clearly shows when tasks aren’t progressing. Unlike a project file that lives on the project manager’s computer, with sporadic updates and weekly reviews, a task board on public display is more likely to be accurate and up-to-date. Moreover, a task board is lightweight: tasks are described by a word or phrase that fits nicely on a tiny sticky note (some people joke that 3-M invented Agile). No heavy-duty specifications are needed.

The Agile task board promotes transparency and accountability, and keeps the Agile technical communicator on track

We all have to-do lists: in a notebook, online, or scribbled on a napkin. A task board is really nothing more than a physical, public, up-to-date, to-do list. And it’s something that I, as an individual, can adopt right away.

4. Improve communication

My team is distributed across four countries on three continents, so interaction in-person is rare. If I need to contact someone, I tend to send email rather than picking up the phone. But Agile emphasizes individuals and interactions. One of its key principles is: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” This lets people work in the same direction and quickly respond to change. Face-to-face isn’t often possible for me, given the geography, but picking up the phone is something that I can and will do.

 

5. Respond to change over following a plan

This is my favorite value from the Agile Manifesto. In the past, I have sometimes spent far too much time carefully planning my work only to be waylaid by circumstances. Despite careful effort, again and again I find that that my estimates are off, that I haven’t anticipated or mitigated the right risks, and that I don’t always end up in the same place as the software developers because requirements change without enough communication. So it was good to hear our Agile trainer say that perfect long-term planning is impossible in the inevitable “cone of uncertainty” at the beginning of any software development project.

The Cone of Uncertainty: Estimates at the outset of a project are likely to be off.

The cone of uncertainty describes how our knowledge improves our estimates as time advances on a project. At the outset, we know very little, and our estimates are almost certain to be off. (Whether we over- or under-estimate may be a function of job title more than anything.) Only as the project progresses do we learn more and make better projections based on that knowledge.

The weakness of the traditional waterfall method of planning and executing a project lies in the requirement that we make long-term projections precisely when our estimates are going to be most inaccurate. If we instead make estimates for the shorter term and regularly revisit and adjust them, our plans evolve more effectively, and accurately. As distinguished engineer Dr. Barry Boehm noted more than 30 years ago:  “The further a project progressed, the more accurate the estimates for the remaining effort and time became.”

 

Practically speaking, this means I will:

• Plan less (if I can get away with it!), and focus on the short-term.
• Beat myself up less when I “get it wrong.”
• Fail early, communicate, and readjust.

6. Timebox

Many Agile projects fix deadlines firmly but allow adjustments to the scope, an  approach known as timeboxing. Timeboxing focuses team members on the most important deliverables: if you must finish on a certain date, you’ll likely work on the top-priority items first. Contrast this with a project that has a flexible deadline. In such a project, you can choose to work on the easiest items first, perhaps negotiating a new deadline if necessary. Important items are crunched at the end of a cycle where quality may suffer, or the deadline shifts far enough to dissatisfy the customer.

Prioritization is the key to successful timeboxing. In the sprint-planning phase, Agile team members work together to prioritize tasks.

As an individual, I can use timeboxing to limit effort on my own work so that I don’t have things hanging out on my to-do list forever. Instead, I focus on the high-priority work in my queue, which helps me overcome some of my weaknesses: procrastination, perfectionism, and over-commitment.

7. Limit work-in-progress

Another of my weaknesses is a tendency to work on several tasks simultaneously. That may sound like a virtue, but researchers have shown that humans aren’t so good at multi-tasking. When we have a lot going at once, we miss details and take longer to get things done. And only things done by the end of a cycle can be considered “done” — work-in-progress doesn’t help us if we’re not finished when the deadline hits.

Kanban (a form of lean programming related to Agile) recommends limiting the number of in-progress tasks to two. So this means that if there are already two sticky notes in the middle column of my task board, and I want to start on another, I have to finish one first. This sounds good to me.

Conclusion: I Can Be An Agile Technical Communicator Now

While I look forward to eventually being part of a full-fledged cross-functional Agile team, I don’t have to wait to get started. Even in my traditional waterfall environment, I have started to bring some of the principles of Agile into my day-to-day working life. Ironically perhaps, the steps I have taken so far have made me feel more a part of the team than I did before, even though I am borrowing from a different model. The task management techniques and the emphasis on communication that I learned in my Agile training are already making a difference.

References:

• Agile Manifesto. http://agilemanifesto.org/principles.htm
• Boeme, B. W. 1981. Software Engineering Economics. Englewood Cliffs, NJ : Prentice-Hall, 1981 (http://csse.usc.edu/csse/TECHRPTS/1984/usccse84-500/usccse84-500.pdf)
• Hallowell, Edward M.. Crazy Busy: Overstretched, Overbooked, and About to Snap! Strategies for Handling Your Fast-Paced Life. 2007. Ballantine Books.
• Perry, Tom. 2007. Agile Tools: Tools for the Agile Practitioner. http://agiletools.wordpress.com/2007/11/24/task-boards-telling-a-compelling-agile-story/

If you’d rather lurk and read than debate, we had lots to choose from on the magazine and portals as well. Ryan Minaker is getting rave reviews for his rave review of Content Strategy: Connecting the Dots Between Business, Brand, and Benefits (authored by Rahel Bailie and Noz Urbina). Jacquie Samuels offers a Getting Started guide to Topic-Based Writing, and Craig Cardimon serves up some great commentary on content strategy, tech comm, customer experience management and user experience (be sure to check out the high school tech writers and their cardboard boat) in Tech Writer This Week.  When you’re finished with those, take a few minutes to vote in the new poll, where I resurrect a classic argument—is content or structure more important? The terminology and the technology have changed, and we’re wondering if our direction should as well.  So do add your own opinion to the discussion.

So much to do and read, so little time… or so it seems when you’re doing your thing as a technical communicator. Grab some coffee, or tea, or maybe a mint julep, and relax with all the tech comm goodness you can handle.

Have a great weekend!

-Connie and the gang at TechWhirl

	Tech Writer This Week for May 16, 2013 In my job as a technical writer, one of the decisions I wrestle with every day concerns topic length. Is the topic short enough to retain readers but long enough to cover the material? If the topic is too short, should I merge it with another? If the topic is too long, should I break it into two topics? This is a lot of what I think about. So does Tom Johnson (I’d Rather Be Writing). Tech Writer This Week gives you other stuff to think about: research, content strategy, taxonomy, customer journey maps, UX, CXM, and cardboard boats… huh?
	Getting Started with Topic-Based Writing Think for a minute about how you would like to see your writing described by a critic (say for the New York Times): sensible, understandable, logical, resonating, compelling, interesting…topical? Writing content that works for your readers, especially when it covers something technical and complex, doesn’t just happen. It takes some thought and planning to structure it, both to be usable and relevant to the reader, and to be reusable and effective for your organization. Enter: Topic-based writing.
	Technical Communication Poll: Is Compelling Content or Robust Structure More Important? Technical communicators are, and probably always have been, a passionate bunch willing to debate the merits of their favorite points of view with anyone who has access to a keyboard and a connection. And at least as far back as the turn of the century, one of those classic debates has turned on content versus structure. Back then it was “Structure vs. Substance.” It’s also been technical versus writer. You could even argue that it’s about logic versus intuition. Today, we ask the question as our weekly tech comm poll: is compelling content or robust structure more important?
	Book Review: Content Strategy – Connecting the Dots for an Epic Win I have a habit of relating most things in my life to video games and board games (some people call this gamification). I find that this way of thinking is especially relevant on a professional level. My quest—as someone who produces and manages content within a content lifecycle—is to overcome obstacles, to complete these tasks, and to achieve my epic win. Content Strategy: Connecting the Dots is the strategy guide that gets me closer to the epic win.

Technical Communication News:

• Quark Joins EMC Information Intelligence Solutions Partner Program 
• The Rockley Group Licenses Rockley Strategic Method to Content Rules

Editor’s Note: For readers who want to enjoy Tech Writer This Week for May 16 via RSS without all the formatting issues, we’ve made it a bit easier by posting the introductory content here, and a link to the Storify curated content.

In my job as a technical writer, one of the decisions I wrestle with every day concerns topic length. Is the topic short enough to retain readers but long enough to cover the material? If the topic is too short, should I merge it with another? If the topic is too long, should I break it into two topics? This is a lot of what I think about. Tom Johnson (idratherbewriting.com) offers two interesting posts relevant to my dilemma. In the first post, he asks if short topics make information more findable. This is my current school of thought. In the second post, he takes the position that long topics are better for the user and explains why. As a lone tech writer, I love this stuff. Closing out Technical Communication, Column McAndrew opines that bad help breeds contempt. After all, if your dining experience at a restaurant isn’t memorable, are you going to return? Or will you avoid the place and tell your friends to do likewise?

Linda Newman Lior (uxmag.com) kicks off User Experience with tips on creating a successful information experience for your users. Bo Amidor (ux.walkme.com) follows up with three UX goals to keep in mind. And Thomas Wendt (uxbooth.com) ponders what matters more, intention or interpretation.

In Content Strategy & Curation, we start with a primer on enterprise taxonomy from the good folks at Siteworx. Then John Waghorn (koozai.com) details the importance of research to building a content strategy (including all the same great reasons we do research in tech comm) On the curation side, TishiaSavesTime.com shares seven content curation tips for you  to follow. I was pleased to note that I am already following several of them. Jason Miner (curationsoft.com) closes this section with his take on the benefits of content curation.

The world of Customer Experience Management opens with David Ashton (SDL.com) encouraging us to unthink six sacred cows of CXM (and we’re wondering if unthinking is anything like cow tipping… but I digress). Writing in CMSWire, Ian Truscott gives us four superb reasons to be working with customer journeys, and Marisa Peacock explains what the customer journey is and how to use customer journey maps.

If you’re at all like me and could use a good online technical dictionary, I found one offered by Computerlanguage.com. Elsewhere in Career and Life, Vic Laurie (www.TechSupportAlert.com) tells us about Process Explorer, a powerful and free Windows system tool. Bill Kerschbaum (intextwriting.com) follows up with a “cheat sheet” for better writing. Gotta love those cheat sheets. And we close out with a great story about high school tech writing teams and cardboard boats. Who knew deadlines and design could have such a soaking outcome?

Continue to Tech Writer This Week on Storify.