What the Cleaning of the Old Manuals Produced

As part of my therapy for hoardism, I assigned myself the cleaning of the old documentation. Normally, the cleaning of the old documentation would be a tedious and fruitless exercise. However, I stumbled upon a little treasure of years gone by. In 1990, Monty Python licensed a video game ( that you can downloaded here). This game was a side-scrolling good time in which you play DP Gumby as you try to find parts of your brain whilst shooting fish from your hand toward your enemies.

Apparently I'm so much of a hoarding bastard, I kept the little game's little manual and crammed it in a time capsule, set for the 2010 post-apocalyptic landscape. When it appeared it begged me to scan it so the rest of the world could also waste several hours reading random, meaningless drivel that will become the next inside joke at hipster parties.

Download a PDF of this file: monty_python_user_manual.pdf

Related articles

• Monty Python and the Holy Grail Censorship Letter (laughingsquid.com)
• Daily Dialogue: Monty Python week! (gointothestory.com)
• Monty Python Still Funny In Perfect Dark [Video] (kotaku.com)

Bill Swallow (a.k.a. @techcommdood ), the renaissance man of technical communication, has posted some tips on going from Framemaker to Robohelp. Working still on the Framemaker side of a similar project, I am singing on a hill that is alive with the sound of music. Go forth and read: Using Conditional Text in Adobe Technical Communication Suite 2 and then thank Bill for the fine writeup.

Also note one of the linked articles below. Dear Adobe, if you have to put the word "demystifying" in any headline related to your own product on your own blog, it's time for you to bring in the UX guns. Seriously. You can demystify stuff on the back end and save us all the trouble of hating on you later.

Related articles by Zemanta

• RoboHelp content now playing on EPUB devices, including iPad and Nook [SIMULATION] (blogs.adobe.com)
• Demystifying mapping file(setting.isf) and TOC generation (blogs.adobe.com)
• Using the right tool in Adobe Technical Communication Suite 2 for the job: Recording (blogs.adobe.com)

Hat tips to @valeskaUX, @willsansbury, & @jasonrobb

Twitter Stream for STC Summit

The third day of the STC Summit proved to be all about the sessions. As a result, the #stc10 tweet stream improved in overall positivity. There were so many accolades for great presentations. Don Moyer ( @foglifter ) attracted high praise.

I don't think speaker evaluation forms are obsolete. However, there is real value in relevant tweets from any given session. While still picking on Don, I searched Twitter for relevant tweets; there were 21 tweets about his session. Within those, only nine where from different people. 100% of those were positive tweets. I hope STC pays close attention to the STC tweet stream. I believe analysis of the tweets will compliment the evaluations forms.

Brian Sullivan ( @brianksullivan) wrote up a quick review of his session with Scott Butler (@OvoStudios ):

Scott Butler has over 19 years experience as a Usability Engineer. Scott's talk about how to conduct usability evaluations was primarily a course aimed for beginners. Yet, there were alot of nuggets for experienced usability people.

Scott walked a room full of 50 people at the STC Summit through a very good overview of the step-by-step process to conduct a Usability Evaluation. Peppered within his presentation were stories from Scott's own experiences (pitfalls, tips, tricks). Scott explained about the importance of being relevant, quick, and iterative. From his experience, there can be a desire to be thorough and complete, which does not get more heavily a part of the process. in fact, the thoroughness of some of the "big thinking reports" gets usability analysts excluded from the process.

Lunch!!!!!!!

Had an awesome lunch with these people:

Lunch at the Angry Dog

After Party

I couldn't go to the after party. This is completely unacceptable and I will take action against myself. I have written a formal complaint and submitted it. I've yet to get a response from myself. Hopefully this post will make me respond.

I did receive lots of blank stares about last night. I was told: "We all agreed there were no stories! who told you I was trashed?" I was also told: "It was better than the tweetup." Finally I was told: "Uhhhhhhhhhhhhhhhh."

If anyone has any of the reported karaoke video, please send me a link or I'll happily upload the video for you with full credit (unless you want to remain anonymous).

I'm in so much trouble for not taking me to that after party.

Related articles by Zemanta

• STC 2010 Day One Super Summary (mkanderson.com)
• STC Day Two Super Summary (mkanderson.com)

Whitney Hess Schools STC Members in Being Human

So the day starts out like this: I got home way too late to make the morning session. But apparently the opening presenter didn't open. It was more of the business status, which was a repeat of yesterday. This started at 9:00 am, so I eventually didn't worry about being late. However, from what I understand, Erin McKean did a great job in  her presentation. However, on my way from Fort Worth to Dallas, I received text messages like "Just kill me now" and "OMG where are you? This is hell." This was all before Erin spoke.  Later I found out it was yet another rehash of the current state of business of STC.

Digression: The current state of business was, by this time, in the 3rd proclamation. However, many members complained about this. My overall problem with the the overall state of STC and the "we're still around" message is the disconnect between the message and the reality. There was a lot of "you're still relevant" rhetoric spoken to an audience of at least 500 people who somehow paid and traveled to the STC 2010 Summit; obviously they feel they are relevant enough to invest in a $700 to $1000 conference to expand their educations and meet other technical communicators. The next, and most important, issue I had was the message the economy was somehow linked to the decline in membership and the overall contribution to STC issues overall. I was membership manager at the Chicago chapter and noticed a drop in membership as early as 1999. When I became membership manager, there were between 1000 and 1200 Chicago STC members. When Chicago membership dropped below 800, we were worried. Now, I think that chapter is fewer than 200. This is an overall trend that doesn't track directly with the economy. STC should stop correlating membership decline with the economy. While a decline in employment and income may contribute to a lack of willingness to pay for extra-curricular activities, there is no data directly correlating economic issues with decline in membership of STC to as far back as say, 1995. An increase in cost of membership, changing technologies, cultural changes, and other factors don't seem to be part of the message. Therefore, the continual cheer-leading for still being around in spite of things is kind of depressing to those of us who believe technical communication is relevant and actually work in the field daily.

All Whitney All Day

I attended all sessions outside of the opening keynote. It was all Whitney all day long. @whitneyhess did a presentation on UXD misconceptions. In true technical writer, traditional, 3-ring binder mentality, she was grilled durin her Q&A. One attendee went so far as to question why she was even presenting. He also wanted to know where UXD fit into the software development life cycle (SDLC). Sadly, I felt Whitney's pain. However, she hit her stride in the Q&A portion. About a third of attendees left during her presentation and didn't stay for the Q&A where Whitney batted tough questions. I've already decided that Whitney is better off-the-cuff than presenting. Considering the circumstances, I don't know how she didn't open fire on some of the questioners except she didn't have a gun handy.

Whitney Quesenbery ( @whitneyq ) spoke at the next session on story-telling as part of the UX process. I can't say more than this: somebody who gets UXD and tells a story to technical communicators about story-telling gets an excellent rating. She knows her material and @whitneyq completely lured the audience into learning how important narrative is to learning for both user and developer.

The final session from today went back to @whitneyhess. She presenting on evangelizing yourself. First of all, considering she had a somewhat hostile audience in her first session, she didn't know anyone in STC to begin with, and she was discussing ways to put yourself out there, she kicked ass. Her material wasn't ground-breaking, but more relevant to old-school-3-ring-binder STC old-guard than she realized. She asked, for example, how many people in her session where NOT on Twitter; over half the room raised hands. Her message was relevant. I also respect she wasn't afraid of dropping the f-bomb. I loved it. To those leaders who will read any complaints about that: don't let the fact that Whitney was relevant and trying to wake up the attendees keep anyone from putting that presentation online.

Finally, I have one word for Whitney Hess: INFECTIOUS

After meeting her in person, I know why she is a rising star. She is naturally infectious and  bright. If you dismiss her because of her youth, then you need to get a life.

The Gator's Awkward Men's Room Corner

After Session Dinner and Tweetup

I attended the Tweetup. @Ninety7 did a fantastic job of putting things together, in spite of the fact that Gator's employees are apparent idiots and lied about the Shiner keg being empty. I'll say this: getting served in plastic cups is a little too frat-house for me. And a staff that lies about what beers are available from kegs sounds like the employees are covering for somebody else being opportunistic, like the dude who took the sponsor dollars from @Ninety7 and put it in his pants and then served us Bud Lite as apposed to Shiner Bock, which they continued to serve all night to those willing to pay. To that dude I say: Robert (@Nintey7) will find you and eat your rotting corpse.

At the tweetup, I spoke to my favorite peeps which led me to being home so late. However, I will never, ever, ever  trade time with @chris_oh, @techcommdood, @AngelosTzelepis, @rachelhpeters, @whitneyhess, @willsansbury, @kirstyt, @yina_li, or @afox98 for any STC business presentation or even anything else. It was awesome.

Finally, @techcommdood and I figured out the awkward corner in the bathroom was too weird not to mock. Check it out to the right. Also note that from now on, we declare the new hashtag #fraternitykitchen to apply to all drunken philosophizing. We were trapped by a guy with cool tats, but he apparently didn't understand that I'm immune to drunken philosophizing.

Related articles by Zemanta

• STC 2010 Day One Super Summary (mkanderson.com)
• Meet you at STC! (blogs.adobe.com)
• Bodies of Knowledge for Technical Communication: Paradigms and Possibilities (tc.eserver.org)
• Embracing Social Media: Presentation Slides (blogs.adobe.com)

What? No Usher?

First day of STC Summit at opening session I was surprised by the ginormous stage stuff. I was all, "Yay! Usher's playin'!" But alas, no Usher. With some sort of mix up, the opening speaker, Molly E. Holzschlag (@mollydotcom), didn't appear. Doing what anybody in that situation would have done without access to Usher, they broke out the business meeting. Cold, hard pie charts followed by excitement of certification vagueness. There were chills in the room.

Other hastily prepared presentations proliferated the platform pimping products and placating the people with promises of improvement and partnerships. Indeed the awesomeness of the opening session gave me these take aways:

• OH: If you are at the STC Summit and you need to be introduced to Twitter, you may not need to actually be at the STC summit.
• OH: Who are you people and why am I listening to this?
• OH: Where is Usher?
• OH: Does anyone understand that Adobe guy? Anyone? Anyone at all? Bueller?

More disorganization followed by a general lack of interest in nutty trail mix or chips with exotic dips. Decisions were made and lives were lost, we decided on the Ginger Man. Only about 2.5 miles from the hotel. And by "we" I mean:

@chris_oh, @whitneyhess, @antdavey, @rachelhpeters, @afox98, @willsansbury, @Paul_UserAid, @techcommdood, @AngelosTzelepis, @KristinKirkham, @Ninety7, and @kirstyt

First of all these are brilliant people. My intellect was stone frozen from fear and disguised itself stoic aloofness. Lots of STC business was gotten down:

• OH: When people just ask me where I'm from, I just pull up my shirt.
• OH: When you think Southern Baptists, think Amway Convention gone horribly wrong
• OH: 127 Southpark references
• Witnessed beer splatter patterns across the table
• Important note: My 40-year-oldness is not a snazzy as @AngelosTzelepis, who is a golden god

Conclusion:

All penis jokes were not entirely any one person's fault since the conference is being held in the Dallas Phallic Memorial Tower a.k.a Reunion Tower.

Related articles by Zemanta

• Going to the STC Summit for the First Time? (tc.eserver.org)
• Meet you at STC! (blogs.adobe.com)
• Usher's Ex-Wife UNLEASHES On His Fans Via Twitter!! (perezhilton.com)

For me personally STC was of great benefit when I was living in Chicago and growing as a technical writer. Somewhere along the way having an STC membership became less of a relevant issue when finding work. I was no longer asked if I was a member when interviewing and being the Chicago chapter's membership manager burned me out as a volunteer. When I relocated to the Dallas/Fort Worth area I needed some personal time for health issues and to find my next career move. (Side note: my move was in 2003 during the telecom recession and I couldn't find work with benefits in Chicago.)

By the time health issues were dealt with and I had gainful employment again, a few years had passed. I attended a couple of STC meetings here and there. The Lone Star chapter is a great chapter with friendly people, but I presentations covered things I already knew from reading or previous conferences and chapter meetings in Chicago.

Now I'm not claiming I know everything. I'm actually kind of  a generalist. However, my career has evolved to such a point that technical writing was a skill I used to help me perform other functions not covered by the STC umbrella. I am doing user-experience (UX) projects. This realization and introduction to the UX community was my career's second wind.

2009 was a tough year on STC. I know none of the decisions made by the STC leadership to save the organization has been easy. I also criticized STC's value overall. Sarah O'Keefe's "A Mercenary View of STC" is a great article defending the decision to remain in STC in spite of current issues. But I'm not an independent consultant anymore and her reasons don't apply to my situation.

The "value" I want is local interaction and to learn UX. The UX community in D/FW is fantastic and I have so much to learn. You probably know the 2010 STC Conference is in Dallas. I wanted to get back out and start speaking again, like my good-old Chicago days. So I submitted two proposals and told myself if I can speak at the conference and have the cost of the conference covered, I'll give STC the chance in 2010.

As it turns out my proposals were not accepted. Looking at the cost of the conference and the dues increase, I can't justify membership any longer. The Big Design Conference in 2010 is where I will volunteer and focus my attention as I get to know more people in the D/FW creative community. For me, it's about going in a new direction and redirecting career growth funds toward a place where I can get more in return for my investment.

My tiny pool of disposable income won't get any bigger this year and I've already raided my kids' piggy banks.  So to STC I want to say thanks for years of helping me learn. I hope the organization survives 2010 better and stronger. I also hope the conference in Dallas is one of the best in the country for 2010. If somehow I can swing registration through some sort of cash windfall I will be there.

To other STC members, thanks for your friendships over the years. I will continue to be involved in the technical writing community but I will also be increasing my network to related fields who are doing the work I love so much. Let's all learn from each other.

Related articles by Zemanta

• Technical Writers in the Corporate Structure (tc.eserver.org)
• The Value of The Society for Technical Communication (tc.eserver.org)

Non-scientific observation: many technical communicators think their microcosm is global. If only the rest of the world would just learn to do things their way there would be candy puppies for everyone. Over the years I've read article after article defining what technical writing is and what it should be. If there was really a hard and fast definition of technical communication, there would be no debate, just a formula.

However, I think the world has moved on past what is considered traditional technical communication. Or at least things have changed enough because of social networking and advanced Web technologies that technical communication is at a critical change-or-die moment. By this I mean the people who own the creation, collection, and distribution of content may not be the same people in the very near future.

I've always defined technical writing as this: the process of taking complicated, scientific, or technical information and presenting it for a specific audience. I wrote that definition in college and still stand by it, fifteen years later.

I also believe technical communication is part of information architecture and user experience design. While the technical communication community, specifically many STC members, also work in usability or information design, the culture of the user has changed faster than the culture within the tech comm community. Web designers have been fast and flexible in accommodating users and are now also becoming the default content strategists.

Information is Not Chaos

I've heard the future of information described as chaos. Calling information chaotic and complaining how users still need "the manual" has been a way for technical communicators to avoid adapting to the realities of the savvy Web user. Chaos is in the eye of the beholder. I would argue information cannot be chaotic by the very nature of interpersonal communication and rules of language. If you dig deeply enough, you will find order in every seeming pile of chaos. For example, Twitter seems like a mecca for chaos, but it's not. There are rules: 140 character limits, each tweet must come from a registered user, every tweet goes into a searchable database, etc. Twitter opened the doors and asked for people to come and post. In the meantime, users have naturally added their own metadata (hashtags) and have learned how to make it meaningful for them with relatively unsophisticated tools.

The success of Twitter and FaceBook alone are enough to make anyone who writes content re-evaluate how information is delivered to their users. I'm not saying all content is appropriate for social networks, but I am saying that patterns in user behavior send signals technical communicators should pay attention to.

The Content Creator Approach

Traditional technical communication has made the technical communicator the center of the solar system. Ever since I started in this business, I've been fascinated with single sourcing, the process of taking multiple sources and pooling them together so you can create multiple output types. The first time I heard the term was in Oklahoma City at a regional STC conference in the mid-90s; someone from Doc-To-Help presented on the shiny new concept of single sourcing  and I also became an InfoAccess HTML Transit beta tester (I still have the floppies!).

(Holy Crap!) Vintage Single Sourcing Workflow I made in 1999 for my boss

Single-sourcing is a concept created completely around the content creator, whose position is the center of an information hub. At the risk of being burned at the stake, I think the Earth actually revolves around the sun. While these approaches are about making the job easier, more efficient, and more automated, I'm afraid the user has been left from the equation. A lot of technical communication concepts are that way. Darwin Information Typing Architecture (DITA) is another example. I've yet to see a DITA presentation where the presenter didn't claim it was the future of all technical documentation. You'd think the "D" in DITA was for deity.

The User Experience Approach

A user-centered approach to technical communication requires your starting point begin with the users themselves. How do they want to receive information? How are they actually reading information? How specifically are they using your information? JoAnn Hackos' seminal work, Managing Your Documentation Projects, was instrumental in helping me build an understanding of audience analysis. But I would argue that today's technical communication culture is not obsessed with users/audience. It hasn't been for a while. I firmly believe this to be one of the many reasons STC is feeling pain right now. STC sets the cultural tone for the technical communication industry and users have with information technology. Through their actions, users have been telling us they like finding things quickly via Google.com or Amazon.com and they like social networking. Our community should pay attention and follow them.

In addition to focusing on users, having cultural awareness of other industries and working with people who represent them is part of product development overall. This in itself can be a lofty topic, but it's important to point out because positive user experience (UX) should be the goal of any product or service. Technical communicators are part of a team creating the UX. They are not stand-alone product creators; they work for companies producing products. Technical communication is not about the lone writer mentality anymore. As a community, technical communicators need to add to the UX conversation so they know where to swim in this workflow, for example.

I personally believe you can argue the merits of DITA or single sourcing all day long, but the dirty little secret of our industry is simply that users don't care. They just don't care. They do know what they want information for and will consume the information in ways that are comfortable or familiar to them. I'm not saying DITA is a bad thing; I'm saying users are the first consideration and the process works backwards from there.

Information Types

User needs and usage actually help us define types of content and how we create it. This can be directly opposed or complimentary to our own needs for process or expediency. Information types can range from casual to controlled, again dictated by the users. Casual information is the most informal. Controlled is the most structured. Then there are many flavors between. On the casual side of things, there's not a lot of structure. Think of casual information as blog postings with tags, release notes, or a larger works without metadata. Casual information is consumed by users who need to know how to a do a job, but these jobs do not involve physical safety, legal requirements, or even standards compliance.

Controlled information must comply with a series of standards that are absolute. From the content creator's perspective, the standards are imposed by the user. For example, engineering drawings may need parts in diagrams tied to the part numbers in a logistics system. This is a user requirement, even if it's imposed by the company because it's necessary for the delivery of a positive user experience. Controlled information requires metadata and the development process is extended depending on the granularity of your control.

The Modern Technical Communication Environment

If I had a dollar for every time I've heard "nobody reads the documentation anyway", I would have had this article written by Zombie Hemingway.  Instead those dangerous words have made it into corporate culture and people actually believe it. So technical communication exists in many places for its own sake. In order for technical communication to contribute to the user experience, the environment must be conducive. The ground rules for this environment are:

• Technical communication is part of a team working together to produce a product or service
• The afore mentioned team understands each other's part contributes to the overall user experience
• A positive user experience is the goal
• Users read documentation and want information especially for products or services they've paid for
• Individual users consume information in many different ways, but that should be addressed in the overall user experience
• Users don't know who created what within your organization; they only know your brand and their own user experience

Finally With the Sheep Metaphor

Content is Sheep as imagined by Cecily Anderson

Think of sheep in a field. The sheep are as controlled as you need them to be. You can let them wander for miles and you can round them up when you want. If you need to control them tightly, you can tag their ears and track each sheep individually.

It's hard work watching the sheep all by yourself, so you get some herding dogs. The dogs have to learn your boundaries and will keep the sheep together based on your training and your commands. Think of the herding dog as the automation you use to track content. It can be a content management system, for example. You need the automation to enforce the rules defined by you.

The point of the sheep metaphor is to communicate content can be controlled and you can exercise control depending on your situation. But the overall user experience is bigger and relies on your judgment and shepherding skills to help make metaphorical wool coats and socks.

So There

After watching the STC's slow motion Chevy Chase-esque prat fall for a few weeks I've come to the conclusion that there are technical communicators who get the UX movement and there are technical communicators worried about keeping things exactly like they were in 1995. Obviously I'm in the first camp. I actually started this article months ago as a simple metaphor exercise and grew into a general technical communication article because the STC has unknowingly asked us all how relevant technical communication is.

So how relevant are we? STC hasn't been the architect of any of the major movements in user information technology. DITA is a good example of something that happened outside of the STC. I saw today that STC is dropping W3C membership to save money. If STC doesn't participate in the conversations related to the future of technical communication, who will?

I recommend technical communicators begin to rethink their relevancy to their organizations and how they can retool themselves to contribute to the user experience. I want everyone to rethink what technical communication actually is. I also want everyone to understand different types of information and apply standards to their work set forth by their own users. Is this too much to ask? Whether or not STC survives, the work must be done.

–

Thanks to Chris Hester for helping me pull my thoughts together.

Third, to shut the forum down and not capture the content herein for use in the replacement service if/when it’s available is short-sighted. The Board has decided to leave it to chance that any useful information in the Forum will be found and captured by a concerned member before taken offline.

And this also is clearly not what technical communicators should do in the real world. Deleting without archiving is just not good information management.

Tech Writing Tradition is Gone

Many months ago, prior to this year's annual STC conference, I had been privately expressing my displeasure with STC. For many personal reasons, I was not getting value from the organization. I've been a member for 14 years or so, previous membership manager, web master, and volunteer. During my time as membership manager for the Chicago chapter, I noticed a decline in renewals and overall difficulty in maintaining willing, happy volunteers. This was 1998 through 2001. Chicago went from well over a thousand members down to just over 800 and then fluctuated from there. Out of all of those dues-paying members an average of 40 would appear at the monthly meetings.

This was not isolated to Chicago. I was hearing from other chapters that meeting attendance and membership retention were top issues of theirs. I would first argue that our current economic situation was not where STC began to experience a disconnect with members. I also noticed that certain topics were recycled at every conference and STC participation in the most cutting edge Web technologies was minimal.

Maybe I was crazy, but I thought, why wouldn't tech writers be the ones driving new user interaction technologies? But for the most part, they weren't. The topics tech writers gravitated toward were software tool demonstrations and how to build website seminars. I saw Jared Spool speak at the 1998 conference in Anaheim, but it was to a relatively small room and the after session hallway conversation questioned his wisdom. I was hooked on user experience, but others were obviously not as they complained they should have attended another session.

I moved to D/FW in 2003 and have only been to a couple of local STC meetings. I haven't been able to get my enthusiasm for the organization peaked enough to drive 40 miles to a monthly meeting. It was until recently I figured out why. I was renewing membership simply because I had been a member since college. I have been paying dues from a place of sentiment.

After a long personal illness (which I will discuss in a future article), I emerged onto a scene in Twitter filled with UX (broad use of the term) professionals. I realized what they were doing was what I had been doing myself as a tech writer, but didn't realize it. Yes, I wrote user, hardware, and procedure manuals. Yes, I made online help. However, here are some examples of what I've been doing since I took my first job:

• Project management
• Requirements collection and writring
• Project documentation
• Software architecture design
• Software interface design
• Usability (without labs and even calling it that)
• User workflows and how they apply to the software they're using
• Presentations on product ROI based on user feedback
• Database design
• Wireframes and prototypes
• User training

I'm sure I missed some. I also know I'm not the only tech writer to take on these tasks because good tech writers are writers as a starting point and continually take on tech because it's fun and relevant to progressive tech-oriented organizations. So I figured out that a group of STC members have circled the wagons around certain expectations of what tech writing should be in their minds. Meanwhile, other people who make documents and end up in the interaction design world have moved on. They have no use for boundaries that no longer apply to today's world.

Today's world is all about the user experience. If you avoid user-based design, you need to board a time machine and go back to a time when AS/400 was da bomb. User experience is about a whole experience. Content must support the product consistently, no matter who wrote it. Do the terms of service match the actual product behavior? Does online help actually explain what the user is trying to do? Does online training actually track results? Do analytics provide a mechanism for change to any content? Does user feedback make its way to everyone involved in product design? Are developers, writers, project managers, testers, and system administrators all working together to produce a single, wonderful user experience?

STC represents two conflicting groups: academics and actual business world employees. These are complimentary roles for building theory but they are conflicting for actual execution. User-based design does not start in a classroom. User-based design is reverse engineering what users want to find an efficient way to provide an experience. Academics should study user ideas, feedback, and environments rather than coming up with processes that are centered around how document creation methods should be. Users don't care about SGML, XML, DITA, or anything else related to how content came to be. They like to tag their photos their way on Flickr or organize their Twitter streams their way. Users are showing the world right now what they like and don't like by their very actions. Our job is to figure out how to help the companies we work for give them what they want so they stay loyal to us and the business is viable.

See Also:

Wither STC? by Sarah O'Keefe

Lifelines to the STC by Tom Johnson

Does the STC Deserve to Survive? by David Farbey

How Would You Resolve the Financial Crisis in STC?

It's the STC Not the STW by Alan J. Porter

Update (06/21/2009)

This article is getting more attention than the one I did way back on Japanese swim suits. To answer a couple of questions already asked, I did not address the financial issues of STC as, in my opinion, they are secondary to the value dues-paying members receive from the organization. Many organizations have faced devastating financial hardships and survived. However, STC will not survive if the members who are left (including myself) do not receive real value for their dues and active participation.

For example, I attended the Big Design Conference in Dallas and I walked away with more value for $50 in one day that I have for the last three years in STC. My personal value was a collection of new, challenging ideas, a fist full of cards from people who work in comlimentary fields, and a real sense I could apply much of what I learned to my job.

SMU and UTD both contributed to the Big Design Conference, offsetting an otherwise enourmous cost for facilities. For all of STC's ties to academia, I've yet to attend a local STC event at an actual school. There is a lot to learn from other organizations and professions. It's time STC top acting as if it's the only place for technical communication.

Mmmmm, breadcrumbs

This website is my cobbler's child. As much as I want to get to it and fix the stuff that annoys me I have to put paying projects first. I just finished one of those projects and was giving breadcrumbs a lot of thought.  Breadcrumbs are the text that supposedly tells you where you are in the a particular website. Normally located at the top of a web page, they are supposed to be a way out if you're lost, like a map kiosk in a mall with the "you are here" dot.

Bread crumbs were originally designed for websites constructed with frames. In the case that you stumbled onto a page within a site constructed around frames, the breadcrumbs would help you figure out how to get to top-layer pages.

I would argue that breadcrumbs really don't correlate to anything meaningful anymore with the possible exception of content that is part of a linear set of pages. This thought occurred to me as I was tidying up a Joomla website that automatically placed breadcrumbs on each page. The breadcrumbs are generated from the link structure. So the breadcrumbs are simply another representation of the main navigation.

Like a lot of automation built into CMS frameworks, breadcrumbs used to be something that was a pain to implement but served a function; now it's easy. So the question is, do breadcrumbs really enhance the user experience? I'm leaning toward "no". I'm also thinking I should step back and take a look at other taken-for-granted automatically generated GUI elements with a new eye.

After fourteen years, I hear the same arguments, but it's as if the tech writing gods performed a find-and-replace to substitute "three-ring binder" with "online help".

Instead of fighting the concept of going online, online help proponents are fighting anything that moves user documentation out of the software system help paradigm. An argument presented to me yesterday claimed users don't want their help to look like Amazon.com. Amazon is very usable and most people can find what they want within seconds. I'm not sure the same could be said for many online help systems.

Whether help writers want it to happen or not, online information continues to evolve. Users are used to searching and accessing what they want quickly. Information must be accessible in every conceivable way. Web technology can help information be all things for all people.

The future of online help will be in "help hubs". These will be websites that converge wikis, social networking, Google-quality searches, linking to related content based on behavior, integration with user communities, and anything else that gets information to the users. Users don't limit themselves to the same constraints that help writers want them to have. They get their information from a lot more places than a help file.

First thing I did was read the Flare Transition Guide for FrameMaker Users. From the beginning, I knew MadCap understands technical communication. The manual is well written and the concepts are based on sound principles.

Now keep in mind that I have used RoboHelp and FrameMaker since they were babies. Flare is completely new to me and I have not read much about it until now.

I put my manuscript in a new folder and I had Flare import it. No problems. A nice little CSS was built based on the Frame style sheet from the document.

Flare Project Example

The Page Layout Editor has replaced the concept of master pages from FrameMaker. I played with those and created my start page and my subsequent pages without much fuss.

Like RoboHelp, Flare saves content in topics. So my short story was translated into a single HTML file. I was able to successfully export my short story to a PDF for submission without a lot of trouble.

Now the idea of storing things by topic is really a tech writing concept. Not many other people do it. An adjustment to working with "topics" exclusively is something I won't have an issue with since I think in topics.

An initial criticism I have of Flare is, since there is a lot to it, the interface appears clunky on my laptop, which is maxed out at 1280 x 800 resolution. My desktop is 1900 x 1200 and Flare is much more usable there. So I found myself on the laptop a little frustrated with juggling "windows" and "explorers", but I'm still learning the tool. I will note here that most affordable laptops come at 1280 x 800 these days and running most software in that environment can get frustrating. I have a Pentium III Sony Vaio I still use periodically for remote desktop access because it has 1600 x 1024 resolution. The widescreen laptop really is a step backwards.

As for authoring, Flare is comfortable and fast. Styles are easily accessible via the Style Window and I love that I can switch layout modes on the fly. I found the placement of toolbars to be well thought-out. Flare is most certainly a tool created by tech writers for tech writers.

I already see where Flare can be used as document tool for everything, which is my goal. When I'm done, FrameMaker and Word will be ignored. There's much more to come as I get my hands dirty.

Michael Anderson Resume Infographic

Michael Anderson, who is not me, has made a completely kick ass résumé in the form of an info graphic. Every once in a while, somebody does something like this and it makes me want to rethink everything (see
Résumé / Infographics).

Out of habit, I've been capitalizing "president" in that context since then. Today it struck me that nobody is anymore. A few Google searches later, I saw where the style for many news organizations is to only capitalize a political title if it's Speaker of the House. Okay, that seems kind of random.

Fortunately, there's an entire book on this topic; see "President of the United States" or "president of the United States"?: An Historical Analysis of the Evolution of the Presidency (or presidency).  The authors are Richard J. Hardy, Ph.D., Department of Political Science, Western Illinois University and David J. Webber, Ph.D., Department of Political Science, University of Missouri-Columbia, so the focus of the paper is on the political reasons for the change. It's almost as good as the angry debate I had with other tech writers at the 1997 STC conference in Anaheim regarding if there should be one or two spaces after a period (one space naturally–you're not using a Selectric anymore).

Anyway read the whole thing. It's fascinating. From the Abstract:

The data clearly reveal that before the Nixon Administration, the vast majority of publications employed the uppercase referent to the "President." However, beginning with the Nixon Administration and accelerating in the late-1970s, this near universal standard changed dramatically. Moreover, our study suggests that, contrary to popular belief, it was neither journalists, grammarians, publishers nor politicians, but prominent presidential scholars (viz., Thomas E. Cronin and George E. Reedy) who led the nation's intellectual charge to make the lowercase "president" the rule rather than the exception. We believe this grammatical relegation represents, to a large extent, both a desire by leading political scientists to make the office appear less "imperial " and a significant symbolic reaction to presidential transgressions concerning the Viet Nam War and, most importantly, the Watergate Scandal. These alterations, we contend, thus redound more from the desire by prominent political scientists to "de-imperialize" or "de-glamorize" the office than any concerted effort to establish "grammatical correctness."

The book is a style and grammar guide. Rickard was an editor for "Engineering and Mining Journal" , "The Mining Magazine", and "Mining and Scientific Press". According to the front matter, he delivered lectures at universities in an effort make engineers aware of good writing. If he had only known back then that 80 years later engineers would still write horribly, he may have given up after the first edition. From the first chapter:

It has been stated, by Sir James M. Barrie, that "the man of science appears to be the only man who has something to say, just now—and the only man who does not know how to say it". The friendly jibe of the novelist contains enough exaggeration to make it humorous to the followers of Huxley and Spencer; but could any litterateur poke similar fun at the exponents of the avowedly utilitarian branches of science—the men of technology—without suggesting an unpleasant truth?

Indeed the engineer does bungle language deplorably. He makes a fetish of efficiency, yet he shows no regard for the effective use of one of his most important tools—the pen; he believes devoutly in accuracy, yet he employs an instrument of precision as carelessly as a small boy handles a gun.

This book is better than most modern books on tech writing.

Words cannot describe how much I love FrameMaker. I use(d) it to write everything, including mundane office dribble because I love structured documents and Microsoft Word has turned a once usable interface into tabbed hieroglyphics. RoboHELP on the other hand is now just Robohelp and hasn't changed much in years. It's not the best documentation solution, but it beats many others and has some cool features strapped onto it by Macromedia before Adobe ate them too.

Why People Hoard Violent Hostility Before Driving Home

Last August, I noticed that my installed, and perfectly functional, Adobe Technical Communication Suite 1.0 was working fine one day and the next day the serial number stopped working. This was because some update made Adobe Captivate reject my serial number. This happened on both my desktop and my laptop.

I thought I would call Adobe support. Looking back, I now see the folly of my youth and inexperience. I miss the old carefree me who doesn't cook blood-boiling hatred for Adobe's customer support methods and people.

Naturally, the support is in India. I'm okay with Indian support as long as the company they represent actually empowers them to do things. From what I've experienced, Adobe has empowered their Indian call centers to say "no" with various inflections as well as transferring me back and forth between customer service and technical support.  I have been told I need to pay for support. I have been told I need to completely reload all of my Adobe software. I have been told that I should know why my serial number doesn't work.

And Time Flies

Starting in August I called several times to kick-off a mind-numbing cycle of ignorant troubleshooting. My complaint is the serial number stopped working. I upgraded to Tech Comm Suite 1.3, hoping for a new serial number and never received one.  I'm told the old one will work for 1.3, but alas, it's not that easy. Adobe support's response to all of this is to have me uninstall and reinstall everything over and over for the next few months. Seeing how this is a suite of products, I spend more time following "Steve's" broken English instructions than I do getting real work done.

So now it's January 2009. Obama will be sworn in soon. Yet I am not getting Hope or Change from Adobe. We're still going back and forth on the phone. People say they will call me back and never do. I can't even guess as to how many call-backs were promised to me that just didn't happen.

I used to sing Adobe's praises for all to hear. InDesign is my publication designer. Dreamweaver is my prototyping and quick site building workhorse. However, FrameMaker is the ultimate documentation tool for me. Robohelp is a great addon that helps me just give customers what they want.

It's not like I don't want to be an Adobe customer. It's more like they resent that I still live and breath after I buy the product. This particular problem, from what I understand, is not uncommon. Damn that man who keeps calling and whining about his serial number.  Damn him back to FrameMaker 5.5 and don't let him upgrade again, they say.

You Can't Fight City Hall

With every call, I'm polite and I understand that each person at Adobe tech support is special in their own way. I'm sure "Ron", who was kind enough to hang up on me "accidentally" just needs a hug. And there was "Annona" who was very stern in insisting I had to pay for support to fix my serial number.  I don't yell at these people. Special people need a special place so they aren't operating machinery.

If I could affford it, I'd move to MadCap Sofware. They seem to have some interesting products. I would like to try their Robohelp and FrameMaker killers, Flare and Blaze.

But the expense of software conversion for small independents like me is enough to cause marital problems.

I'll stay with Adobe, but I'm angry with their support and I'm more angry that they know their support sucks and they are not taking steps to correct it. Maybe they're jonsing for a future bailout. Who knows.

I just know that after 6 months, I have an unresolved issue with a serial number for a product I've purchased and then upgraded. I've been treated as if I don't matter to Adobe and I can't use the software I purchased.  Thanks Adobe! I can now have a blog post about it.

The cliches where never really pushing up daisies, they were laying in wait, popping their heads up like gophers during meetings here and there. In the 90s, the cliches were taken to a new level as they infiltrated board rooms in the form of incoherent babble. So the dawn of a new cliche age is upon us, fueled by the "new new economy". Without further adieu, I present some of the new new economy's new new cliches:

• Consumerize: To make a product or a service ready for consumers versus business customers.
• Burn all boats: Refers to a military decision to burn the boats after crossing some water in order to force the troops into fighting at all costs; I've heard various speakers using this term in reference to Spanish, Revolutionary, and Viking historical battles. Unfortunately, this is one of those annoying military cliches people want to apply to business.
• Any military analogy: Now that I think about it, the military analogies are too far gone. They are more violent than ever with the talk of bodies and the killing. I thought the whole Sun Szu discourse died in the early 90s. Please stop before somebody gets hurt.
• Sweat equity: To work without pay for future rewards in a company. This isn't the worst one, but it's becoming overused.
• Optimize: Now everything can be optimized. You'd think it was the only way to say "improve".
• Company DNA: Assuming the company is organic and each employee and resource is so insignificant as to be microscopic, or that's how it comes across anyway.
• Convergent technologies and/or processes: "Convergent" is the new "synergy".
• Value-added: An oldie but still a goodie from its integration into every other sentence when it comes to product marketing.

That's the start of my list. As I get more, I'll post them on this site. I might even create a special section since I'm inundated with cliches with every turn.

Also check out A VC's Cliche of the Week for some excellent examples and comments.

The survey highlights three behaviors that representatives do not execute, but which customers would like them to: speaking clearly and slowly, respecting the customer's right to say no, and providing customers with advice. "It's important that the customer service representatives speak in a clear and understandable manner so the customer can follow them, and also not rushing through the call," Atkinson says. "Service reps often feel pressure to get off the phone quickly, but customers feel like their needs are not being attended to when that happens."

Let's take each issue separately with sarcasm engaged.

Speaking Clearly and Slowly

That right there is enough to stop most call centers in their tracks. When I consulted at Montgomery Ward, I worked on a call center project for them. Their call center fielded the calls related to appliance repair. They had 400% turnover. Four–hundred–percent. That's like each person quitting before their first smoke break. With that kind of turnover, you can only imagine that the person answering the phone was . . . how shall I put it delicately . . . stupid. One of Wards' problems we were trying to solve was they needed training for a new computer system and the average employee there read at a third grade level.

I don't know if you noticed, but Wards is not in business anymore. Their call center didn't break the company, but it was an example of where training ranked in their priority list.

Here's another tip for companies, if speaking clearly is important, don't send your work to India. Need I say more?

Respecting a Customers Right to Say No

My god, if it were only true. I don't think this will sink in since the entire model of a sales office is built on commission and those who don't pull in the sales are let go. Ironically, this study points out that the company does better when customers can pick what they want when they want. I can hear management synaptic explosions trying to figure this out:

Okay, each sales person is responsible for bringing in x amount each month. If not, they are fired. If we tell them to not push the customer, sales will go up for the whole company. Naturally, we know when sales go up, but how can we attribute increased sales to customers saying "no"? So how do we hold the sales rep responsible for individual sales? Hey, do you smell that burning? My head feels hot.

Providing Customers with Advice

Like this would actually happen. You see, management sees "advice" as cross-selling. In reality, advice is directly related to good training, and, trust me, companies do not spend money on training the front line people. Sure, they send their top performers to seminars every once in a while. But training for everybody, including that weird guy near the water fountain who picks his nose? Not gonna happen.

Actually, this whole thing comes down to training. I believe that you get what you put into it. Companies that skimp on training will have a negative impact on sales and customer service. This study doesn't come out and talk about training, but the three key recommendations of the study underscore the importance of having well-trained individuals working with customers.