Content Rules Inc. was kind enough to extend their invitation to have me blog for them again. This time, it’s on a subject that’s near and dear to their hearts as well as mine.
This article talks about my own personal experiences in trying to use standardized language. Whether you use standardized language in your personal or professional life, it’s something that one needs to keep in mind as a writer, especially when writing for a global audience, and even more so if you are writing for a digital format that is easily accessed through the Internet. It’s not easy to do, but it’s something that should be tucked in the back of every writer’s brain.
I will admit that there are a lot of content strategists who have been doing content strategy for a much longer time than I have. Val is one of those people, and she’s someone I consider to be one of my many wonderful tech comm mentors. So you can believe me when I say that it’s been a great honor to be asked by Val Swisher of Content Rules to do a guest post on the Content Rules Blog that will also be in the Content Rules Newsletter soon. I’ve learned from her and many others over the last few years, and I have some experience under my belt as well now, which has culminated in this article. I hope you enjoy it!
We definitely didn’t hear this panel say to any of us, “I’m afraid you’re just too darn loud!”
I apologize for my blog coverage of the 2014 STC Summit edition of Adobe Day being delayed–it’s been a busy month! But hopefully, you’ll feel it’s been worth the wait, and you had a chance to see my live Twitter feed as it happened.
The STC’14 Adobe Day felt a little bit different this year. One of the things I noticed was that as much as Adobe says that these Adobe Day events are Adobe-product free, lately, they haven’t been. HOWEVER, they are still not one big, in-person infomercial either. Adobe products are not brought up much, but if they are, it’s to show that they can be tools to use to create solutions to common tech comm issues. So, it might be an inadvertant infomercial in that respect, but it’s not done in a blatant way that screams, “YOU NEED TO BUY ME!!!!!! PLEASE BUY OUR PRODUCTS!!!” Adobe continues to do a good job in showing what tech comm issues are out there, and as leaders in the software field, they are tuned into these issues and are creating products that benefit the technical communicator. I think that’s fair enough. The talks, overall, were broader topics that in some instances used Adobe Tech Comm Suite tools to provide solutions. And you have to remember, while these talks are aimed to be product-free for the most part, it’d probably look pretty bad if you had someone declaring all the glories of a competitive product when Adobe is hosting the event. Y’know?
With that out of the way, I observed some other things that made this a little bit different. First, there were fewer speakers this year. I felt that was a good thing, because in the past with more speakers, each speaker would be racing to get his/her presentation completed in a very short amount of time, and there would be little time for questions or discussion. Since there were fewer speakers this year, each one could elaborate more on their topic, which allowed for more time for questions and discussion. More networking time during the breaks was also a benefit from having less speakers.
The other difference I saw dealt with the speakers themselves. While they were all familiar, established voices in the tech comm world, it wasn’t the same crowd that one usually sees at Adobe Day events. All of them have participated in Adobe events or other tech comm events before, but in the past, it usually is most of the same speakers up on the podium. While I like all the “usual suspects” very much, and consider them my mentors and have become friends with several of them, seeing these new “players” was actually refreshing to me. I hope that Adobe continues to change up the speaker lineups with future Adobe Days, as all the speakers I’ve heard have a clear voice that’s worth listening to, and hearing as many of those voices as possible provides both variety and fresh perspectives going forward. As I go through each presentation in forthcoming blog posts, hopefully you’ll see what I mean.
But as tradition in this blog dictates, I always start with the panel that capped off the Adobe Day event. I find that these panel talks bring an umbrella perspective to where we are as a profession through several points of view, and seeing where there are agreements and disagreements in the issues at hand.
The Adobe Day Panel L to R: Matt Sullivan, Bernard Aschwanden, Joe Welinske, Marcia Riefer Johnston, and Kevin Siegel
Matt started with the point that tech comm is more than tech writing now, so what do we need to improve short-term and long-term? Kevin responded first, saying that we need to do more with less on smaller displays and adapting the content appropriately for mobile. Marcia added to that, saying that using less can mean writing tighter as well. (She has a technique she taught during the STC Summit, in fact!) Joe agreed with Marcia, adding that technical communicators need to put in the time to make concise content meaningful, and to look at simplified English as part of that objective. Bernard felt that attending workshops and demonstrations were important, because technical communicators need to continually learn and adapt in this industry! He added that SMEs (Subject Matter Experts) should contribute to content, but technical communicators should control it. Kevin also agreed with Bernard, saying that SMEs are writing content more often now, so teaching them to write tighter will help. Marcia chimed in that many people are now being required to write, but don’t have the skills. We need to help with that.
Moving onto topics about how technology affects technical communication, Kevin said that new technology, like Google Glass and other wearables, is emerging, and we need to understand how these work. Joe pointed out that the Pebble watch now is starting to have user docs now, and more will be emerging. Bernard added that gesture based technology similar to the Xbox Kinect will need documentation.
Matt then asked, “What should we look forward to in the next five years?” Bernard felt that less specialization will be needed so that the right people write the right content, such as an engineer who can write. Specialized writing will be very important. Joe added that we need to agree on taxonomy and terminology, and use style sheets more often for consistency. Marcia believed that topic-based writing will be emerging more as a growth area. Kevin explained that in e-learning, there is a need to develop learning for new devices that responds to user displays, thus accomodating multiple screens.
The next question asked about how to help educate and help with adapting certain generations adjust between print and digital writing/designing. The consenus was that we just need to adapt. The panel encouraged the audience to get to know your UX/UI people, as they will help you learn to adapt, especially if you aren’t as tech-adaptive.
The last question centered on customers customizing their content–is this a trend? Bernard leapt into a response with, “GOOD! DO IT!” He encouraged us to help customers to start doing personalized help, or personalizing any information, for that matter! Moderator Matt closed by saying that rich media that engages users is going to be about content strategy, but it will also be about content marketing. The group agreed that personalized, concise information going forward will be best!
“I guess you guys aren’t ready for that yet–but your kids are going to love it!”
And that was it! The session went by quickly, but as you can see, there was a lot of great information that many technical communicators can take and use going forward in their own work. While it might take some time to adapt, sure enough, it will bring the field forward as technology and the way we access it moves ahead.
Coming soon: The individual presentations at Adobe Day #STC14 Edition!
An ENIGMA coding machine, found at the Computer History Museum (photo credit: TechCommGeekMom)
Technical communicators truly do have skills that most others don’t have, and it’s a simple set of skills. We take for granted that we can display writing and documentation clearly.
What brought this to my attention most recently–as if I didn’t know this fact already–was dealing with emails from work. I was trying to interpret emails from several educated, fairly influential people from the company, and I didn’t have the faintest idea what they wanted because of unclear directions. Granted, it didn’t help that the email system that we are forced to use at the moment (Lotus Notes) is not exactly user-friendly when it comes to formatting content within an email. Even when I could wade through the quagmire of formatting fogginess, what was being requested of me was not completely clear, and I had to send emails back clarifying the requests.
Although we are often required to work on reducing the number of words used to relay our messages and act as translators of content, it shouldn’t be at the cost of miscommunication. Sometimes having more is less, because more detailed directions can provide less back-and-forth of emails, thus more efficiency in getting the work or task done. From a customer perspective, having accurate documentation–even if it’s long–can reduce call centers help requests significantly.
A great example of making sure that content–whether it’s an email or any other documentation–is efficient is when I worked at the Princeton University Press. The CMS I had to use was an in-house Frankenstein monster of an application, but it worked for better or worse. There was no printed documentation, so when I first started working for the company, I took lots of detailed notes to make sure I understood how to do tasks on the system. I left the company after a few months, but left my notes for my successor. About two years later, my successor left, and my former manager asked me back to fill in temporarily, since she knew my contract had ended, and my ramp-up time wouldn’t be the same as if a new person was coming in during the pinch of getting the new fall catalog posted online. Sure enough, the two-year-old notes were still at the desk, and I could still follow them clearly. (This was when I knew that techcomm was truly my calling!) This reduced the number of times I had to ask my manager to refresh my memory on how to do certain tasks. As a result, the fall catalog information went up quickly, and everyone was happy. Mind you, the documentation I had was pages and pages long–all handwritten, no less, but it was accurate enough that I didn’t need much help in re-learning the system. My second successor was able to use these notes as well, since they were so accurate.
As I said, we take for granted that we have the ability to write cogently and clearly since we all do it on a regular basis. It’d be nice if more people can get the basics of this skill down so that we technical communicators can do our jobs more efficiently. The fact that we can decipher and clarify messages better than anyone should put us in the same ranks of ENIGMA coders, in my mind!
You must be logged in to post a comment.