Posted in Uncategorized

Plain language always wins. Always.

Businessman Midair in a Business MeetingI love it when I’m inspired to write a blog post due to something that I read through social media. In this case, this morning I saw a Facebook post written by Jack Molisani, author of Be The Captain of Your Career, executive director of the Lavacon Conference, and technical recruiter that intrigued me. His post is listed below with his permission. It stated:

Just read this in a resume:

“Sophisticated, results-driven Program Management professional with a demonstrated ability to successfully lead business or technical initiatives with demonstrated experience in IT Governance, cost and schedule management, leadership, cost estimating, and infrastructure management covering full life-cycle application development & integration, data management, strategy & IT architecture implementations/roll-outs.”

First thought: Sophisticated? He wears shirts with frilly cuffs and drinks tea with his pinky up?

Second thought: Run-on sentence. Can’t communicate well in writing.

Oh candidates, why must thou shootest thouselfs in thine own feet?**

I definitely agree with Jack’s assessment. The run-on sentence is particularly bad.

The thing that caught my eye even more was the language used. As Jack alluded, it initially implies some sort of sophistication or high-intelligence level.  But in the end, couldn’t this candidate have simply said, “I am a successful and reliable project manager with experience in X, Y and Z”?   I mentioned to Jack that I would not be surprised that the candidate wrote this way because many job descriptions for openings are written similarly.

One of my greatest frustrations when I did job searches in the past was getting through wordy job descriptions, as they were written in the same gobbledy-gook language used by this candidate. WHY? Is this done for the purpose of weeding out candidates from the get-go, as if to say, “If you can’t read this, then you must be too stupid for this job”? I’ve often gotten that feeling.  Or, I’ve read many job descriptions that sound much grander than they are–again, much like this candidate’s description of himself–only to find that it’s a basic job with several steps, and it’s not that hard to do. The job description was only made to sound like more than what it really is, which is what this candidate was trying to achieve, I’m sure.

This made me think about plain language use, and how it’s starting to take hold in technical communications. I’m really glad about this shift. Why? To be honest, I’m an idiot. While I have a solid education, and can speak and write fairly well, how often will you hear me using the $10 words? Rarely. The use of “fancy” language alienates people, and in my case, it overwhelms me. My brain can’t always process it sufficiently. I find that technical writing is similar to translating complicated English into simplified or plain-language English.  Since I’ve learned how to do that over many years, it’s become a little bit easier for me to process. But, most people don’t have that internal filter. They hear or read, “Blah, blah, blah,” as Jack implied in his reaction above.

A follow-up comment to Jack’s post by one individual pointed out that this is how business people are taught to write. That’s a good point. I would also point out that legal professionals have the same issue. Have you ever tried to read “legal-ese”? It’s just crazy. I remember an early assignment in grad school required us to look up the local legal codes in our towns, and “translate” the legal mumbo-jumbo into plain language. I remember mine clearly, as it directly related to my house. Put into plain English, the particular housing code from my town stated that if you have a pool in your backyard, you have to have a fence around it for legal and insurance purposes; if you didn’t, you’d be fined. Simple enough, right? Not if you read the original language.

Why are business and legal professionals still writing as they did a century ago? Who are they trying to impress? In our current digital age, it’s a pointless endeavour.  We are a society of instant gratification. We need people to get straight to the point. This is most evident with the proliferation of mobile devices. We need information to be short, fast, and quickly comprehensive.  Writing in the “sophisticated” language used by that the job candidate above isn’t going to help anyone anymore.  We need to be able to communicate with customers and citizens in a way that everyone can understand. This is not the dumbing down of language as we know it, necessarily. As I said earlier, using grandiose language alienates the reader, especially if the reader is trying to find out basic facts. All Jack wanted to know was whether this person qualified for the job.  Instead, he had to translate what the person was saying before he could determine that, and that act in itself turned Jack off to this candidate. It’s not a good reaction to have.

Plain language is not simplifying language for the less-educated. It’s a simplification of content at its best. Technical communicators and universities (and yes, I’ll even say it, all schools in general) have to start teaching their students to have a full understanding of rich vocabularies, yet choose words wisely to communicate the best message possible. Tech comm does that in aces. We need to get the business schools and law schools (among others) on board with this concept.

So, Candidate, if you want to get in Jack’s good graces (or anyone’s good graces for that matter), you’d be better off writing in plain language. If you pick up a copy of Jack’s book, too, you’ll get some other hints that will make you a more viable candidate. Get to work!

**Update: a few hours after I originally posted this, it appears the either Facebook is hiding the post, or Jack took it down. I know that some of the comments he got showed that people misinterpreted his intention and purpose of the post, and perhaps it got too heated to keep the post up, which is a shame. I definitely did get his permission first before I “reprinted” it here.  I support Jack’s intention in sharing the information, because I know that he didn’t publically humiliate a specific person by name or inference, and his purpose was to show how a recruiter really does react to a poorly written resume. Jack’s business, and by extension his recent book, are meant to be guides to helping anyone get a good job. Jack has continually pointed out that many of the steps needed are so basic. This is what he was trying to point out in the post he wrote above. I suppose I understand his position because I’ve been the candidate enough times that I actually know that the smallest things–like what Jack pointed out with this candidate–have made the difference as to whether I got an interview or not. The other perspective I understand is that as a recruiter. While I’m not a recruiter, my mother owned her own agency for years, so I learned a lot from her about what that business entails, and it’s not an easy job. So for that, I understand where Jack was coming from. He wasn’t being antagonistic, but rather it was a remark of frustration. –techcommgeekmom

Posted in Uncategorized

Writing Mobile Documentation: Rewrite or Cut — with Neil Perlin

After a few years of talking through social media alone, I had the pleasure of meeting Neil Perlin in person at the STC-PMC conference a couple weeks ago. I attended one of his presentations as well at the conference, and throughly enjoyed listening to him talk about mobile and other emerging technologies. I also enjoyed talking with him directly about these topics as well. He gave me some great personal advice along the way, and look forward to receiving more of his advice as time goes on. I’ve been a fan of his work, and I can understand why he’s a very popular speaker.

Neil gave a great presentation online through the TC Dojo by Single-Sourcing Solutions about writing for mobile, and it ties in very nicely with the presentation that I gave at the eLearning Conference 3.0 at Drexel University last week as a follow-up.  Here’s Neil’s presentation–I highly recommend watching it to get some great ideas about how to approach writing for mobile, whether it’s for technical communication or m-learning:

Posted in Uncategorized

Get your motor runnin’…Head out on the [mobile] highway…

Peter-Fonda-and-Dennis-Hopper-in-Easy-RiderWhen I first read the title of John Daigle’s Adobe Day presentation, “Enjoying a Smooth Ride on the Mobile Documentation Highway,” guitar riffs by Steppenwolf echoed in my mind thinking of the song, “Born to Be Wild” and scenes of Peter Fonda and Dennis Hopper riding down the information highway. OK, maybe not the information highway, but with mobile, it’s an open road right now that is waiting to be explored.

While I hadn’t heard John speak before, I was familiar with his “rock star” status due to social media–mostly through Twitter (you can find him as @hypertexas)–in my e-learning and m-learning forums.  It turns out that John is a big RoboHelp and Captivate expert, so being tied into the mobile highway scene makes sense!

JohnDaigle
John Daigle

The premise of John’s talk was that there are shifts and trends in mobile, and we need to look at organizations as early adopters, figure out the mobile landscape, and look at how user assistance is used on mobile as compared to how reference documentation is used generally. He pointed out that writing and designing for a mobile audience is very different from traditional methods (I agree!), and that he would be offering some hints on how to approach technical communications for mobile.

John pointed out that fellow speaker, panelist Joe Welinske, created the “bible” for Windows Help,  and now has created the “bible” for mobile apps, referring to Joe’s book, Developing User Assistance for Mobile Apps, which talks about the “screen wars” between the smartphones and tablets of various size. These various sizes produce a challenge for technical communicators. John went on to point out that e-readers, such as Kindle and Nook, are still alive and well and doing well as compared to other tablets such as iPads and Samsung Galaxy Tabs.  The initial conversion of print text to Kindle ePubs was a big change in electronic documentation. He also stated that at this stage of the game, Windows Surface and Windows Phone are a little late in the game, but they are catching up rapidly.

Following some of the comments of keynote speaker, Charles Corfield (the post on that talk is forthcoming!), John explained that other products including voice-activated devices, such as those found in some cars these days, are becoming more prolific. Google Glass, which is getting a lot of press right now, is a new game changer in mobile devices, and time will tell what kind of impact it will have.

John told us that as of February 2013, there were one billion smartphones and 150 million tablets worldwide–proof that mobile is becoming more widespread! Corporations are even getting more involved in mobile by buying mobile devices for employees, but many companies are also allowing BYOD (Bring Your Own Device). Companies are starting to embrace the idea of BYOD a little more lately.

Finance and healthcare industries are quickly adopting mobile delivery of information because of the portability of the devices. Mobile devices are being used more in industry and shop floors because they allow users access anytime, anywhere. John informed us that many of the same technical communications skills and experiences needed to write standard information apply to mobile. QR codes are gaining popularity as a  part of the movement of accessing documentation through mobile. John quoted Jakob Nielsen saying, “Killing time is the killer app of mobile.” With that in mind, John advised that technical communicators should learn to use more economic words for mobile, such as  “extra” instead of “additional.”

John also quoted John Caroll, who said, “Minimize the extent to which the systems and the information get in the way of what the user’s really interested in.” Progressive disclosure is key in writing for mobile. It allows one to gain information by revealing what’s needed when it’s needed. Ways to show this in mobile interfaces could be drop-down navigation or overlays. This allows a user to not leave the page, but he or she can still get to information quickly. In this sense, mobile can go right to the source or the heart of information needed.

So the question is, are huge documents (such as what’s in those big company binders) going mobile too? The answer is that technical writers can’t just dump desktop layouts and information onto mobile. This is where technical communicators need to work with developers to do what they do best–help “champion the end users.”

Going mobile is about flattening navigation–but not going button crazy, and getting back to context sensitive help. Technical communicators need to tap into social media to keep content current and accurate, thus becoming curators of user generated content.

It helps to prototype mobile layouts with rapid wire-framing tools, like Balsamic Mock-ups as a popular example. There are many specific tools on the market that are available to assist the developer in facilitate context-sensitive help.

However, there are several design controversies involving the need to upgrade browsers, progressive enhancement, adaptive design and responsive design. Some argue that responsive design is not the best because it makes a device’s CPU works harder, thus it becomes a virtual memory hog when resizing images as needed. Yet, responsive web design can adapt layouts to the appropriate viewing environment with fluid, proportion-based grids.

John suggested using the site, http://HTML5test.com , to help test how compatible your site is with mobile interfaces. He also pointed out that help-authoring tools can do much of the work with single source layout concepts, as different settings in authoring tools can help determine how to make user outputs work properly. Another such tool he recommended was Adobe Edge, as it helps writers to preview and inspect web designs on mobile devices directly ON the devices. For additional tools and information, John pointed us to his website, http://www.showmethedemo.com .

I particularly enjoyed John’s talk, as I’ve been following many of his posts on Twitter for more than a year now. He’s very good at explaining the power of mobile in technical communication, and I think John put this perspective well into view for the Adobe Day attendees.  As many know, I’m a big believer in the power of mobile, and the mind-set for writing for mobile isn’t that difficult if you understand the basics. So, it’s good that Adobe continues to include information about technical communications in the mobile world, as that’s where a lot of change is coming in the future. Adobe made a good choice when asking John Daigle to present information about mobile documentation.

John, if you are reading this, please feel free to add any comments or corrections in the comments! 🙂