New title; broader mission

New year's upon us and it's time for some changes. I'll be starting a new assignment in 2010, as a user experience architect embedded into a development team for managed security services. I've moved somewhat from what my focus was when I first started this blog. Then my focus was on user assistance; now I have much broader responsibilities for shaping the total user experience. Of course user assistance stays a part of those broader responsibilities.

I now get to concentrate on an old passion of mine, going back to my CheckFree days, and that is how to integrate user experience design into the technology design and development process. I like being embedded in the design and development team, a model I worked in at CheckFree. I have a basic disagreement with Jabob Nielsen who measures the maturity of a user experience presence in a company by how independent its practitioners are organizationally. It takes me back to my old manufacturing days where we felt that Quality had to be managed by someone outside the production chain of command. Later thinking changed to putting it back onto the shoulders of those who made the product. I feel the same way about usability and user experience design--it is an intrinsic part of the product and should not be separated from the measure of good code writing. Code that works well but renders a lousy response time would not be regarded as good code; nor should code that renders a bad user experience.

I'm not naive about the implications that producers, anxious to meet due dates, will push out bad product if not overseen by third-party watchdogs. Well, that's the challenge that fascinates me. I think the solution is in well-defined processes and well-written requirements, not in separating functional requirements from non-functional.

The new Blog title is a bit of an homage to Jeff Raskin who wrote The Humane Interface. My focus will be on understanding how we as humans interact with technology and how to design technology to accommodate that.

Happy New Year, everyone.

Important message

Click cartoon to enlarge.

Click cartoon to enlarge.

Useful Web Site

Check this new site out:
http://www.indoition.com/index.html

It's a vendor web site with all kinds of useful links to get you to bookmark it and send other folks there. Doh! Got me!

Contest Results

See the contest.

OK, here's the official explanation, and then I'll reveal the winner.

First off, thanks to everyone for not challenging which character was Kitty and which was Maria. One person tried to at work, and I hit him. (Duh, the one's that's a CAT is Kitty.)

Panel 1 has Kitty citing Fitts Law, which basically asserts that the time to move to and click on an object is a function of the size of the target and the distance the user must move the mouse. Kudos to EagleSongs for recognizing the law, but that would make Kitty the UI layout designer, someone who would be interested in things such as button location and size.

Panel 2 has has Maria citing Hicks Law, which asserts that the time it takes a user to choose among options is a function of the number of choices the user is presented with. That would make Maria the Information Architect. (Note the base 2 logarithm, on the assumption that choices are binary and the search can take advantage of a decision process that progressively cuts the available options in half.)

Here is a UI that is optimized for both laws:


Panel 3 is, as several pointed out, the opening of Hamlet's soliloquy expressed as a Boolean formula. A more graphical representation would be:



That would imply that the two met while taking a course in English Literature.

Technically, Siska provides the right choices, but her linking Maria with Fitts Law is wrong.

Anindita provides the most elegant explanation of the layout designer and information architect rationale, and although her answer to the third question is different from mine, I'm going to accept it and name her the winner!

Congratulations, Anidita. Send me your mailing address and I will send you your very owned signed copy of Iron Hoop.

Geek Fight!

I'm doing the comic early this week and throwing in a contest.

Click to enlarge comic.

Click to enlarge comic.

Here's the contest

The first to answer the following questions correctly and sufficiently explain their answers (no guessing) wins a signed copy of my novel Iron Hoop [shameless self-promotion].

Kitty and Maria both work in the UX department and went to the same geeky school. They have a lot in common, but take two different looks at UX design.

1) Which is the Information Architect?

• Kitty
• Maria

2) Which is the UI layout designer?

• Kitty
• Maria

3) When they first met and became friends in school, what elective were they both taking?

• World History
• English Literature
• Economics
• Technical Communication

Submit your answers as comments to this blog post.

Elegance

If you think quality and craftsmanship are dead, and you think that design is a lost art, look at these two working pieces of equipment from Shubb. They are both accessories for playing Dobro. Santa's bringing me the capo (I already have the slide). If you think the slide looks nice, you should heft it and position it in your hand. Ooooh, makes me all goose-bumpy.

The Gary Swallows slide


The Shubb capo

Dominant and Passive

This one is too weird, don't even read it. I'm only putting it in a blog so I can find it later if I need to ask my doctor to up my meds.

I don't count sheep when I can't sleep. Instead, I try to visualize Dobro licks and how I would notate them on a treble staff. I had a couple of aha! moments the other night:

1. The middle three lines on a staff are the same as the G tuning on the dobro: GBD. This is important because I am a reaaaallllyy sloooooooowww reader of music. I usually have to start at the bottom and say Every Good Boy Deserves Fudge or spell FACE. I also have a hard time remembering what order the letters of the alphabet are in, so if I'm looking up a word in the dictionary, I have to sing the ABC song to figure out where in the dictionary to go. Fortunately, I can start with elemenopee if I know the letter is in the second half of the alphabet and that saves some time. Now, I can read the middle lines of the staff without having to start at the bottom. That's handy in much the same way as being able to start the ABC song at elemenopee.
2. I've been trying to decide in a certain song (Shenandoah) how many frets down to start a slide at "A-a-way you rolling river." I was doing it starting a half-step below the G and also a full step below the G. As I tried to notate the variants in my head, I realized that the choice was between going to the 7 note (F#, one half-step below the 8 note, G) or the flatted 7 note (F, one full step below). As I did the notation in my head, I realized that the full step, taking it to the flatted 7 note, was really establishing the dominant chord (G7) and setting up a nice transition from the I to the IV chord (G to C in this case). I would not have noticed that had I not been notating the phrase instead of just playing it by ear.

I've been rereading Orality and Literacy by Walter Ong in which he examines the assertion that literate societies think differently from oral ones (where there is no written language). It made me ponder, at point 2 above, if literate musicians (those who read music) think differently than folk musicians (those who have an oral tradition for learning and passing on music). I thought differently about the phrase when I read it than when I played it.

Then that led to thoughts about the dominant chord and its role in establishing transitions and the various ways we deal with transitions in written language. Joseph Williams in Style: Toward Clarity and Grace talks about using the given-new rhetoric. Make the thing or concept that is already known to the user (the given) the subject of a sentence and then make the new thing or concept the predicate or object. Then in the next sentence, you can take the concept that was the object in the first (the new) and make it the subject (the given) in the second.

For example, "The traditional newsletter is giving way to the blog. A blog (web log) allows readers to comment openly. These comments can validate or challenge the writer or even other readers."

This technique leads to an often overlooked use and justification for the passive voice: It allows us to make something the subject of a sentence (so it can occupy the "given" slot) that would normally be the object of the sentence in an active voice construction. Example, "The computer generates a configuration file. This configuration file is saved to the local disk drive at the end of the session."

One more observation about transitions. We often signal transitions with "metadiscourse," that is, discourse about discourse. For example, in the examples above (as well as in this sentence--gawd this is so surreal) I have used the phrase "for example" to signal the user what the role of the sentence is. Other metadiscourses are "On the other hand" (signalling that a contrast is coming) or "Consequently" (signalling that a conclusion is coming). I have become a firm believer that since these are signals for a shift in meaning, they should always come at the beginning of the sentence. Look at the following.

Different roles will expect different information. Engineers, for example, want to see....
Different roles will expect different information. For example, engineers want to see...

I like the latter, the metadiscourse is at the beginning of the second sentence and does not separate the subject from the verb. Not true in the first case. It seems a little less stylistic and dramatic, but technical communication is about clarity.

I'm thinking Ambien, large doses of Ambien.

Life with Mike

Click cartoon to enlarge it.

Click cartoon to enlarge it.

The new magic number

Miller's famous study on the ubiquity of 7 in short term memory aside, I have my own candidate for a magic number:

1/√ 2

The decimal equivalent is approximately .707, which is a kind of cool looking number (it's approximate because the square root of 2 is irrational, another cool aspect). But its real significance is that if you square it you get 0.5 or ½.



OK, why the math today? I'm trying to figure out how to cut my work in half. Why? Because if I get laid off I will hire myself out as a documentation consultant with my specialty being that I can reduce documentation by half. Hey, in a bad economy, sell hamburger and beer.

So here's my radical (pun intended for my mathy geek friends) approach:

1. Look across the breadth of what's being produced and reduce it by 30%. A 30% reduction is not that hard to find.
2. Look at the depth of what's left and reduce it by 30%.

The net result is that you're left with half of what you started with (actually a little less because of rounding).

Gotta run and get a copyright or a patent or something on this.

Editor Fight!

Click cartoon to enlarge

Click cartoon to enlarge

Reverse Engineering SIGs

This blog is very STC centric (as it seems a lot of my life is these days). I just got off a strategic planning call where we were discussing ideas for expanding our income base. I noticed that several of the areas that had been identified involved taking what we already have, e.g., webinars and training, and marketing them into other professions. Part of an action item I was assigned was to help identify what those other professions might be.

As I thought about how to go about doing that, it occured to me that many of our Special Interest Groups (SIGs) are really focal points for larger professions. Our SIGs, in those cases, focus on the technical communication application. For example, Usability and User Experience is a large profession outside of technical communication. Our Usability and UX SIG focuses on the technical communication specific applications of that field as indicated by their mission description: "The Usability & User Experience SIG focuses on issues related to the usability and usability assessment of technical communication..."

So SIGs are like areas where outside professions insert specialized instances of their expertise into our profession. But what if we could reverse that gateway?


Our SIGs could be an excellent outreach channel to market our specialized knowledge into those other professions.

For example, my "official" professional education is in instructional design and technology. As I was getting my PhD in that field, I found a great formula for getting published. I would specialize ID topics for technical communication, and then I would specialize technical communication topics for ID. Instructional designers are pretty smart folks, but you know, they don't know a lot about writing manuals! Look at the raw .doc file that a "classically trained" ID person does and you will not find a style tag anywhere in it. And what ends up in headers and footers is any body's guess. So I was able to use my technical communication expertise and spin it to meet what I knew their needs were, i.e., how to design and develop student manuals.

Our SIGs are a great opportunity for us to do the same as a Society. Look at the list of the current STC SIGs:

• Academic
• AccessAbility
• Canadian Issues
• Consulting and Independent Contracting
• Content Strategy
• Emerging Technologies
• Environmental, Safety, and Health Communication
• Europe
• Illustrators and Visual Designers
• Information Design and Architecture
• Instructional Design & Learning
• International Technical Communication
• Lone Writer
• Management
• Marketing Communication
• Online
• Policies and Procedures
• Quality and Process Improvement
• Scientific Communication
• Single Sourcing
• Technical Editing
• Usability & User Experience

Some, like the geographic specific ones don't meet this model, but most of them represent professions that could use training or other resources around technical communication expertise aimed at the specific needs or contexts of their industries.

So I'd like SIG folks to start thinking about what it is about technical communication that could be of value to the professions at large your SIGs represent. How can we reverse the star gate and insert ourselves into their worlds? Specifically, what are the professions and what would be good topics?

Dip Management

Make sure the chip is thick enough to scoop the density of...oh wait, it's not about that kind of dip. Today's blog is about managing technology acceptance and the negative dip in user performance and proficiency that occurs when the user must learn a new tool or new technology.

The figure below illustrates a phenomenon known as the "j-curve." Dotted line "x" represents the user's current state of proficiency using the current tool or technology. Dotted line "y" represents the user's potential new level of proficiency with a tool or technology innovation. Hooray, look at how much better the innovation will make us!!!



Uh, what's that nasty little dip at the beginning all about? What's up with that? Well, that's the reality of the j-curve; it reminds us that we go from one moment being very proficient with our current tool or technology to being pretty stupid with the new one. This is why I hate doing upgrades, I go from smart to stupid in the time it takes to click "Install Now." They might as well relabel the button:


How bad the dip gets is indicated by the distance labeled "A." I am working on a current project where one of the managers named that area "the valley of suck." How much better the new proficiency (or user experience will be) is indicated by the distance labeled "B."

So the basic question every user ends up answering is Was the improvement labeled "B" worth the pain and humiliation labeled "A?"

Example

I recently sat through a presentation where Tom Gorski, STC Director of Communication, demonstrated what the new electronic version of our magazine Intercom would be like.

My first reaction was "bright and shiny, cool" but then very quickly as I watched Tom click this, mouse over that, and a variety of other user interactions, I felt a dip in my enthusiasm--along the lines of "Gee, ten seconds ago I knew how to read a magazine, seems I don't any more."

Then I began to realize that with this new kind of magazine came a new level of power, due to new ways to navigate, search, drill down, and email snippets to friends that did not come with Intercom as I know it and love it today. I also saw how advertisers could provide links in their ads. Hmm, double thrill here. As a board member my first reaction was, great! added value to advertisers (more STC revenue), and as a reader I was equally pleased. As with most professionals, I find vendors to be a major channel of professional education. That's why the Expo hall has become such a mainstay of professional conferences. Being able to click over to their web sites would be a positive for me.

In short, as I better understood my potential new value distance of "B," I became more willing to tolerate "A."

Take-aways

A couple of lessons come out of all of this:

• As technical communicators, we need to help users understand the improvement represented by distance "B." This means overviews of upgrades and new technologies must be benefit-oriented and situated in user contexts. Help make that formula B/A more acceptable by making B bigger.
  
• As technical communicators, we need to minimize the pain represented by distance "A" through good user assistance. Once again, make B/A more tolerable but this time by making A smaller.
  

And as users ourselves, we should try to understand better what the new proficiency level "y" is and accept that some effort is required to get there. As I think back on all of the innovations I have opposed, most of them I would now fight for to the death if you tried to take them away from me.

OK, Twitter I would only fight for to near-exhaustion, but you get the point.

Edit my Wiki, please!

Click cartoon to enlarge.

Click cartoon to enlarge.

Comic Relief

As part of a project I'm working on, we are going to develop a comic-style collection of user scenarios to help communicate best practices around a security service we are offering. This is just experimental at this stage, mainly doing a concept piece to see 1) will it work and 2) will stakeholders buy into it. The model I am using is Google's Chrome's Googlebook for web app developers.

There can be a number of advantages to using a comic-style treatment:

• Overcome traditional disinterest in "User Guides"
• Allow a friendlier, instructive tone
• Use line illustrations of screen areas to focus user attention on critical details
• Use "illogical" shifts, such as going from a "white board" type overview to the narrator standing in front of a large UI pointing to an area of interest
• More easily translated than screen cam tutorials
• Can be randomly accessed for review purposes (something hard to do with video-based training)

The coolest part, though, is this gives me a legitimate reason to be playing with comic styles while at work and on the clock. How cool is that? Actually, I have a real by-gawd graphic designer assigned to the team, but I need to get more familiar with the genre...yeah, that's the ticket; I'm doing comics at work to get more familiar with the genre. Actually, my next column in UXmatters does deal with how I use comics in an internal Wiki-based status report.

So for a while, Fridays will be "Comic Day" in this blog. Just trying to get immersed in the genre--all work and profession related. I'll try hard not to enjoy myself :-)

Veterans Day

I am sitting in my cube in my "Army Strong" baseball cap and my khaki green fatigue-style jacket with my sergeant pins on my lapels. I was a patriotic draft-dodger of the late sixties: Low draft number so I enlisted and became an Arabic linguist for the Army Security Agency. It got me to Ethiopia and out of Viet Nam.

Actually, my tour was fun--more like a PG-13 Hunter Thompson episode--so I take the opportunity today to thank those who have truly served and who are serving by going into harm's way.

Thanks

\:-| (lame emoticon of a salute)

Energy in; energy out

OK, be prepared for Dante's 6th inner ring of metaphor Hell.

I broke down and took a by-gawd Dobro lesson this week. I figure it's time to get serious about my music so I paid this guy $100 for a three-hour Vulcan mind-meld of Musical Theory 101. Never touched my guitar. (He got interrupted, though, so I did get to play his $5000 Dobro for about 20 minutes while he handled a domestic emergency.)

So I go home with his two-sided yellow legal page on which he had scribbled the sacred code that explained the chromatic scale, all of the keys, and the how to construct every major, minor, and dominant chord. I was overwhelmed and stunned. Had I just gotten the deal of a lifetime or did I just flush five Andrew Jacksons down the toilet?

The next day I pick up my Dobro and start experimenting with the different patterns of the chromatic scale notes on the fretboard and playing around with the chord construction schemes he had taught me. It got interesting when I started playing around with a G9, one of the dominants. It was a different sound and I started putting a bit of a riff around it and pretty soon was playing a jaunty little latin-sounding thing I ended up calling "Tijuana Roller Coaster" because it had an unbalanced feel caused by the G9 and then resolved nicely to a slide up into the 1st inversion of the root chord (C) with a pause and then a final C note on the bass-most string.

OK, a little of that intro is just me showing off the new stuff I learned--but heck, I paid a hundred bucks to be able to write that paragraph, and it's my blog so humor me.

But it reminded me of the importance of grounding the energy out of a system. I used to be an electronics technician, and one of the electrical components we dealt with was the capacitor. A capacitor stores energy, and after you take one out of a circuit it can still give you a bit of a shock if you don't short the two terminals and get rid of the charge. If it has a big charge stored, you might have to do that a couple of times.

I've noticed that a lot of music does a similar thing. Notice how many symphonies end with a big chord that the orchestra repeats a couple of times? Ta Dah!.. dah...dah. Well, it's like the symphony has the musicians and the audience all worked up and the composer is trying to ground them at the end. Leave them someplace comfortable. And as much as I hate the practice of rock musicians trashing their instruments and amps at the end of a performance, I understand that they are trying to ground all of that energy so the performance leaves them and the audience back at sea level and not soaring up in the clouds.

So my slide to the root chord was to ground the listener, get him or her back to a safe place. But a 1st inversion chord is still a tad unsettling. A root chord is like having three singers harmonizing with the notes do, mi, sol, respectively. The first inversion would have them sing mi, sol, do with do being sung as the highest note. Still safe and stable, just a wee bit top heavy because the root note is on top instead of at the bottom. So that's why I throw in the root C on the bass-most string at the end, sort of like the second touching of the capacitor to fully discharge the energy. It kind of simulates what happens when a roller coaster stops; it leaves you leaning slightly forward in your seat from your forward momentum for a second, and then you settle back comfortably into the seat. Ta dah! ...dah.

Working with teams has a similar requirement, every now and then you have to ground the energy and bring everybody back into a safe comfort zone. Steven Wright has the line, "You know how you feel when you're leaning back in a chair and then you start to tip backwards? I feel that way all the time." Team work involves a lot of energy as new questions disrupt old, comfortable theories, agendas collide, etc. Periodically you need to ground the team--nobody wants to feel like they're tipping backwards in the chair all the time.

So how do you ground team energy?

In music we emphasize root chords and root notes. Playing in the key of C? End on C, E, G. Safe, predictable, comfortable. Working on a team? Get back to basic assumptions around which the team members can feel safe and comfortable. Weekly summaries are great grounders. Here's what we did this week and what we learned. Chronological descriptions of what happened or what happens are great grounders. Can we all agree that we saw A happen and then B? This is one of the reasons usability tests are great team builders, the team has equal access to the same data: what they saw the users do. As a test facilitator, when teams would start getting edgy over a point and I wanted to ground them, I would get consensus on the sequence of events. "Did the user click Add first or did he type the variable name first?" Direct observations are a safe common ground around which a team can safely discuss and agree on basics.

Other grounders are getting team members to agree again on the high level goals of the project or restating the criteria by which we accept or reject design decisions. C, E, G.

But... There is always a big but...sometimes you need to put energy into the team. The whole reason I like Tijuana Roller Coaster is that it starts on a G9, the musical equivalent to leaning back in your chair right at the tipping point. You energize a team by pulling them out of their safe, comfortable places. As you could well imagine, there are good ways to do this and bad.

When dealing with conflicts (the ultimate energizers), avoid dis-chord, i.e., out and out wrong notes being put together. Emphasize constructive tension. (A G9 introduces constructive tension into a song in the key of C.) Look at the differences in these statements in terms of dis-chord vs constructive tension:

• You're wrong.
• I disagree with you.
• I have a different perspective.

The last one is the rhetorical equivalent to a G9. It gets the tune going and you sure can't leave it there, but it's a pleasant enough tension. The first statement is fingernails on a chalk board.

Enough. The point I wanted to explore is the creative management of energy, when to infuse it and when to dissipate it. I can't wait to see what my next Dobro lesson brings.

Talk Your Walk

I know the title of today's blog seems backwards, but that's the point I want to make. It is not at all unusual to find situations where a person says one thing and does another. In Action Science, that is called a gap between a person's stated beliefs and their theories in use. In common practice we say that someone isn't "walking the talk" with the implication that the problem is in the walk.

Sometimes that's true, but often the reverse could be true, we're walking a particular walk because it works for us and it is the talk that is out of place. Action Science recognizes that and spends as much energy trying to align the message with the reality as it does on adjusting the practice to the preaching.

For example, if you ask writers how to write, they often say, "I start by making an outline." I taught technical writing and I often said "I start by making an outline." Most writers don't actually do that and if you corner them they will say things like, "I really should but..." Maybe, but the alternative is to just quit saying "I start by making an outline." In my case, for instance, I often just start writing. That's my way of exploring the content space. My friend and mentor, Carol Barnum, often says "Writing is thinking." So I start by writing, which gets me thinking about content, theme, and sequence. Interestingly, when I'm about a third of the way into an article, I turn on Outline view in Word and view only headings 1, 2, and 3. It lets me see where the flow is wrong or the appropriate ideas are not getting grouped.

I'm not saying that's the right way to write, but I have been successful with it so I need to quit telling people "I start by making an outline." I need to say, "I just dive in initially as a way of dumping what I already know and getting a feel for the content."

We confuse people when there is a disconnect between our stated beliefs and our theories in use. When managers say they demand teamwork but evaluate employees based on individual accomplishments, they do a disservice to the person who puts the team's overall needs ahead of his or her specific goals. That person gets punished for believing what the boss said and acting on it. The same applies to spouses, kids, friends, and all.

But don't be so quick to blame the disconnect on your behavior--It could be you are reciting scripts that describe what you think you should do. Actions speak loudly, and we are getting something that works for us from our behaviors or else we would have abandoned them (compulsive behavior aside).

So there is absolutely nothing wrong with the following talk:

• I start writing by just letting the firing of every synapse go to my fingers and then I organize and clean it up later.
• Although I value teamwork, I will evaluate each employee on his or her individual achievements first. It's my job as manager to make sure that your individual goals add up to a team achievement.
• We are not all equal here, I am more mindful of engineers' time than writers' time. That's just the reality of it.
• I'm going to ask if these jeans look good on me because I'm feeling fat, but I'm just fishing for some positive stroking.

It's kind of like using turn signals when you drive. It's easier for others to avoid hitting you if you share where you're going.

Moron Holes

My buddy, Miranda, is a gamer, and she showed me a new one that allows the participant to shoot a hole into a wall that sort of bypasses normal space and time limits and lets the player emerge, for example, on the the other side of an otherwise uncrossable chasm. Cool.

I think a similar device explains how some people can jump from assumption A to a logically inaccessible conclusion B--they're traveling through moron holes.

Classical logicians were unfamiliar with quantum concepts such as wormholes, so they had to explain such leaps from A to B with phrases such as non-sequitor or post hoc ergo propter hoc, without any explanation about how the speaker had accomplished such a feat.

No longer. We now have a scientific explanation: The speaker fell through a moron hole.

So at your next meeting when the project manager suggests that the doc can be ready on the same day coding the UI is done, you can glibly reply, "What moron hole did you fall through?"

Uh, bring cookies to the status meeting.

Screen Shots in Documentation

Sometimes someone gives me documentation that "so and so" put together for his IT group that tells them how to install our product. Generally, the purpose is to show me how "real users" want to see documentation. Invariably it is a 32-step procedure with a screen shot in every step.

Well, obviously, the writer in not familiar with Robert Horn or the demands for accessibility and globalization that I must deal with, so I have dismissed it.

But it just keeps coming back, so I'm going to ask myself, "What if they're right?"

First, so I can be more open to new thinking, let me purge myself of all the reasons I have traditionally rejected screen shots in documentation:

1. Every time the UI gets modified, screen shots must get updated.
2. Every time the UI gets translated, new screen shots must be generated in the new language and coordinated into the translated text.
3. Information in the screen shot (like button selection or entries) must be documented in the steps anyway so the information can be rendered by adaptive technologies like screen readers.
4. Many screen shots just show the reader what the user is already seeing.
5. Users may be overly attracted to the visual and miss important points in the explanatory text.
6. It makes the document bigger.

Now let me changes hats a bit a take a critical look at my traditional positions.

Objection 1 (updating screen shots) seems writer-centric. Essentially it is saying "It makes my job harder." Well if it does make the user's job easier, it would make sense that it makes my job harder--nothing's free. OK, Objection 1 is bad.

Objection 2 (translation) is just an instantiation of Objection 1. Therefore, Objection 2 is bad.

Hmmmm, I don't like how this is going so far :-(

Objection 3 (information still has to exist in words) has some substance. Information in a screen shot cannot be used to substitute for information in the steps. Unless of course, you're not worried about accessibility. Now that's an entirely different blog!

Objection 4 (what good is a picture of what the user can clearly see) has always resonated with me. Here is an example:

This example is particularly problematic for me since the UI text is actually pretty explanatory.

It also can get fairly tedious. consider the next steps that follow the example above:


But it seems that this by-the-numbers, picture-by-picture aspect is the attraction for this type of documentation. As in "So easy a..." well you get the picture.


So am I hearing from users who want this type of documentation, or am I hearing from technicians who think users need this level of hand-holding?


Objection 5 (visually distracts from useful text) has merit. Although it's true that a picture is worth a thousand words, it did take seven words to express that concept, and I'm not sure how you would get that across as well in a picture. Also, I think it is easier to wrap context around an example if the example is in words. For example, in the following shot, is the value 10240 an example or is it the value the user should enter?


And in the next example, the screen shot visually contradicts the step.


Objection 6 (document size) should be evaluated based on the merit of the document. If the screen shots make the document better, no one will care about bigger.

So where does this leave me?

I am going to be more open to including screen shots where they do the following:

• Help reassure the user that where they are in the UI is the right place to be
• Help call attention to a specific area of a complex UI
• Support an example that is hard to visualize otherwise, e.g., setting up a desktop configuration
  

So where they add value, I'll be more willing to tackle those aspects that make my job harder (e.g., documentation maintenance). But just as I would with words, I'll cut out the obvious and whatever does not add value. I prefer an additive approach (put it in only when the words seem inadequate) over a subtractive approach (take it out if it seems superfluous). In other words, I'll be more open to screen shots in the future, but they have to work themselves into the document, not just be their by entitlement until expelled.

State of the Ark (part 2)

As I said in an earlier blog, "state of the ark" is my phrase for when I think I am on the leading edge of technology when in fact I'm back among the late majority or laggards.

One of the problems with playing a Dobro all by yourself is that the instrument is really suited to provide accents and solo snippets. But I'd look a bit stupid standing in my den tapping my foot doing nothing then occasionally playing a "twinky twang."

So I thought I should get some bluegrass CDs so I could get used to playing in the context of a band. If you need a visualization, see this classic Andy Kaufmann bit from SNL.

I decided to go to Amazon.com to look at what was available. I thought to myself, "Wouldn't it be cool if when you bought albums online, you could actually hear bits of each track?" What a great, innovative idea. I could get RICH!!!!!


So, how long has Amazon been doing that, and why haven't I taken advantage of it before?

We probably don't think of music clips as user assistance, but this feature helped me make an informed choice (Patty Loveless, Mountain Soul II), and that's the ultimate goal of UA.

Job well done, Amazon.

New Media: Transparency vs TMI

A couple of interesting web sites hit my radar today:

This one is an article about some thrashing at the New York Times and the Washington Post about what staffers can appropriately blog and tweet about:
http://www.niemanlab.org/2009/09/is-transparency-the-new-objectivity-2-visions-of-journos-on-social-media/

This site links to 100 organizational policies on social media:
http://socialmediagovernance.com/policies.php

As a blogger and tweeter, I worry a bit about if I ever cross the line of "what happens at work stays at work" (or my other life--STC--where we have a strong code of "the board speaks with one voice").

I often blog about projects at work or insights I have gained from my interactions with fellow workers. And recently, I blogged about the internal debate I have had with myself over some STC issues.

The issue is when does transparency become TMI (too much information)?

On one side, I am a trained and committed Action Scientist who holds that ideas and assertions get better and more accurate when subjected to public scrutiny. In short, thinking stupid thoughts in private won't make you any smarter, but sharing those stupid thoughts lets you benefit from feedback--and you thereby get smarter. (Apologies to Chris Argyris for that over-simplification)

On the other side, companies need to keep proprietary discussions private, and colleagues need to be able to express themselves frankly without fear of having their personal positions show up in someone's blog.

Lacking a well thought out philosophy, I have jotted down the following principles for myself.

• Never put anything in a tweet/blog that could strengthen your company's competitors.
• Never put anything in a tweet/blog that would embarrass a colleague.

I also stay mindful of the following hierarchy of risk (from lowest to highest):

1. Reporting facts--The main risk in reporting facts is that you must make sure the facts have been released for public consumption. For example, it is low risk for me to say in a blog that STC has a task force looking at certification. However, it would be risky to talk about a decision we have made but have not communicated.
   
2. Illuminating the issues (identifying pros and cons)--I think this is the safest and most responsible space for thought leaders. Using the certification example again, it would be useful to articulate what are the issues around certification, helping readers make more informed decisions on their own.
   
3. Advocating a position--Advocating a position has higher risks in so far as you might be in public disagreement with a standing policy or with another colleague. That's not necessarily bad. Action Science holds that we worry too much about avoiding conflict rather that opening up the deliberation for public scrutiny and feedback. Still, it needs to be handled with tact and respect for others' positions.
   
4. Attacking a position --Same caveats as above, and this one carries higher political risk if you are attacking an official position of your company or association. For example, if I started a series of blogs and articles attacking DITA, I would soon run afoul of IBM's goal to promote DITA. (I'm a big fan of DITA, by the way, but it provides a good example.)
   
5. Attacking a person--Always a bad idea. I've learned as a blogger and public speaker that if I need a butt for a joke, it needs to be me.
   

So in short, I think it is OK to openly discuss current topics that are still in the formative stage and it is OK to attack legacy positions whose founders are long forgotten. It's not so good to attack positions that have recently been made (if you have any association with the organization or person who has taken that position).

And when advocating a position, maintain enough public humility so that you can gracefully support the opposition should you lose the debate. By the way, a useful pattern is "Yes, I had concerns over certain issues, but I think so and so has addressed those concerns and will be sensitive to them should they arise."

The Deployment Project: Defining the Deliverables

I had the kickoff meeting yesterday with my multi-disciplinary team working on the Deployment project. As project leader, one of the first things I have tried to do is define the deliverables we will create as a result of this project. By the way, this is no small task, we have been wrestling with this as a UX department for some time now.

As preparation, I established a team Wiki in our Lotus Connections site. The thing to remember about a Wiki is "Build it and they will ho-hum." So you really need to hold meetings periodically where the Wiki is the visual tool. So I used the Wiki to collect my own thoughts, provide background info, and to present a table of the recommended deliverables. I then opened it up in edit mode during the meeting so we could incorporate team thoughts in real time. BTW, that is a trick I have learned from two colleagues who use it well (Miranda Bennett and Christie Davis), that is, use the work product and edit it in real time during the meeting. Two advantages come from this:

• You don't need to take detailed notes and then write them up after the meeting (not to mention the additional task of implementing them)
  
• You get immediate feedback about the change, as in, "Oh no, that's not what I meant."

Part of the preparation I did for the deliverables exercise was to review IBM's recommended design artifacts (from a couple of IBM sources), some of my own work on use cases, and the artifacts from a process ISS adopted about four years ago--Rapid Contextual Design. This background gave the team a box of tools so to speak to choose from.

At any rate, we have decided that we will produce the following artifacts as our design package:

• User roles and profiles
• Use case diagram
• Use cases
• Product vision (a visual/narrative representation of design ideas that emerge from our user interviews, interpretation sessions, and affinity analysis that are part of our Rapid Contextual Design process)
  
• Conceptual wire frames
• Scenarios (like use cases but more contextual and UI-specific)
  
• Deployment Guide
  
• Service Requirements Document (SRD)

The Deployment Guide will actually describe current state. This allows us to address a present gap in user documentation (I'm all about early wins that the internal client will value) while letting us hitch-hike on the user analysis and use case work the Information Developers will do as part of developing this document. It will also establish the infrastructure and information architecture that will support the future design.

The Service Requirements Document is a new deliverable we have not done before and one that was suggested during the kickoff meeting. (We have product requirement documents, but it has been my experience over several companies that PRDs come from product marketing and lack a user experience focus.) Since we have developers on the team, we can collectively define a document that puts our research and conceptual design recommendations into a format that can be easily consumed by those who must develop the design. We have long wrestled with how much detail should a design document have and how much leeway should the developers have as they work in "rubber meets the road" land. This aspect of the project could become the most exciting for me.

An interesting outcome of the meeting was the decision to remove the Due Date column from the project plan. Huh? I've argued for that for a long time--See my blog You Can't Handle the Truth. But as soon as I was made the project manager for this, wham, I was thinking dates. Part of the problem--as it was pointed out to me--was that the deliverbles would happen iteratively, for example, some use cases early, others later, etc. The other problem is that we are largely in discovery mode and must be open to follow the data when and where it takes us.

OK, no dates.

Instead, as we identify activities, I am assigning an owner and asking that person to start maintaining the Wiki page(s) that tracks activities and progress for that activity. We'll see how that goes.

Ready, Fire, Aim

It's not what you think, I'm actually in favor of that sequence as a development strategy.

At its core, it's the heart of Agile development, rapid prototyping, and all kinds of good things that get people engaged.

There's an old technical writer joke (i.e., a joke told by an old technical writer).

Instructions for getting unlost in the woods:

1. Pack a user guide with a typo in it.
2. Pack two loaves of bread and some cold cuts.
3. Sit and wait for the dozens of people who will find you to tell you about the typo. (The bread and cold cuts are so you can have sandwiches for them when they come calling.)

The point is that people don't get very engaged over abstract ideas or plans, but put some kind of a design stake in the ground and man do they come alive! In short, give them something to criticize or disagree with as early as possible, then make the sandwiches and wait for the crowd.

A problem we have as traditional technical communicators (designers all around probably) is that we are reluctant to show early designs that we know aren't very good. We all want to clean the house before the housekeeper shows up.

I was at the UA Europe conference in Cardiff earlier this month, and one of the presenters, Leisa Reichelt, talked about her experience getting the Drupal.org community actively involved in redesigning their web site. One challenge she had to overcome was her own discomfort at posting "the worst wire frames I had ever done," as early design concepts. But she did it to get early feedback and involvement--and it worked.

Some pointers:

• Don't be afraid to show preliminary work early
• Don't over design--early documents, for example, can have just bullet points capturing the key talking points the topic will address
• Use low-fidelity prototyping tools. If it looks like it was drawn on a napkin, people are less inclined to criticize its lack of polish and more inclined to comment on the essense of the design's objective (check out Balsamiq Mockup).
  
• Use collaboration tools like Wikis. Then if someone points out a typo, quickly answer, "Oh, it's a Wiki, you can correct that any time you like."
• Respond quickly and incorporate suggestions.

These pointers work for all aspects of design: UI, user assistance, and even project plans.

Note: You can substitute pizza for the bread and cold cuts.

Exciting New Assignment

Work is actually fun these days! Of course, when the bar is set by floods and STC meltdowns, "fun" is a relatively easy state to achieve.

I'm lead on a multifunctional team that is tasked with reshaping the user experience for the deployment phase of a SaaS-type application. We have the following types of folks on the team:

• Information developers
• UI developers
• User researcher
• Visual communicator
• UX specialist

Wow! That's some collective horsepower.

I'm also experimenting with some new collaboration tools. This will be my second time using Lotus Connections to manage a project team. It's a nifty piece of collaboration software, combining blog, forum, and wiki technology. I'll also be using some other tools, such as Balsamiq Mockup (wireframing), The Brain (mindmapping), along with a proprietary tool for doing affinity wall type of analysis, and of course, my old standby Visio.

And even though I am no longer officially on the Information Development team, it gives me an opportunity to bring that group into the upstream design process in which I have long argued they belong. See my column Use Cases for User Assistance Writers.

I see a case study if this works; I see some self-pitying blogs down the line if it doesn't. Meanwhile, I'll use this blog to maintain a loose journal as I share what seems to work and what doesn't as I go along.

How High's the Water, Mama?

Any time your life can be described by lyrics in a country-western song, things aren't going so well. As I write this, I'm pretty well landlocked from any place useful, like work or grocery stores, by the Yellow River overrunning its bridges. Oh yeah, I live on the Yellow River, or what used to be the Yellow River; it's now the rapidly moving Yellow Lake. My woods are under water and the river has stabilized a few yards short of my house. I could fish from my deck (if I chose to ignore that I am downstream from a water treatment facility).

I think I'll write a country-western song. I've got the opening down:

I got two cigars and half a bottle of bourbon
How 'm I ever gonna make 'em last all day?

Think I'll start a group-write on Twitter. Join me at @michaelhughesua and contribute.

STC: Quo Vadis?

As long as I'm laying on the gravitas, I'll continue with O tempora, o mores, ubinam gentium sumus?

The times, the manners, where among associations stand we?

I need to figure out where I am with all the STC stuff going on, and blogging will help my introspection. Also, it will let me share with you some of the background and complexity that surround the current state of affairs with STC. My e-mail tag line reads "Anyone who is sure of the answer doesn't understand the question," and this blog is an invitation to join me in understanding how we got here, where we are, and where I think we need to go. And this is social media, so feel free to comment in and share your perspectives back with me.

How we got here

Cindy Currie, our STC President, has already provided the answer in her article in News and Notes:

As I have previously mentioned, the shortfall is primarily due to the negative impact the recession has had on our two main sources of revenue—membership dues and the annual conference. But going forward, we have to solve a problem bigger than the recession. For years STC has been adding and expanding services and activities to benefit members and the profession without taking a hard look at how to sustain those activities. And with only periodic, modest increases in fees, the costs to sustain those services and activities have outpaced our dues and total revenue such that the Society has actually been subsidizing these activities.

A little more backstory.
We have been seeing a decline in membership going back roughly to the technology meltdown of the dot.bomb. Many costs to service members are relatively fixed, that is, rent doesn't go down, we don't pay less for legal services, it costs the same to design and edit a magazine issue for 10,000 as it does for 20,000, etc. So what happens is that as membership declines, the costs to serve individual members go up. But the board has historically been reluctant to raise dues. Part of the reason is that members complain when dues go up-duh!

But part of the problem on our part was that dues and budget discussions were not as tightly linked as they should have been. We were not asking the appropriate question when we discussed dues, namely, "How much money do we need in order to do what we want to do?" We focused too heavily on member reaction.

Another problem is that we often debated programs at the line item level based on their merits. Questions like "Should we get rid of this?" were answered with "No, it's a good thing to do." We missed the "But we can't afford to do them all; something good has to go."

In short, we weren't putting all the pieces on the table at the same time.

Another interesting thing about membership is that even though we get a healthy number of new members every year, we lose more than we gain. Hmmmmmm. Is that saying something about perceived value? Of course it is, and that has not been lost on the leadership team. We tend to keep a core of loyal members (I love all of you), but that has created a demographic problem: A lot of us are older and will be retiring in the coming decade. We are losing our "next generation" of STC members. The upshot is that decisions about how to grow the society are being made by those who often lack the perspective of what the target population wants. Ouch!! OK, that one hits this sixty-year old boy too, so hold off on the flames. (See How Not to Update Your Look and Feel)

Where we are today

OK, so we are in some interesting times:

• We have a significant shortfall in income caused by the same economic crisis that deflated our reserves that were supposed to get us through just such a predicament.
• We have a dues structure that can't cover costs of basic membership.
• Our alternative revenue engine (the conference) has become a big question mark as we try to guess how well it can perform in this economic climate.
• We're out of step as a society with where the profession is going and who the emerging professionals are.
  

So if you're wondering what we chowder-heads on the board are doing, welcome to our world :-) No excuses, but we didn't make this world. It is what it is; we're just the ones who must lead during these critical times.

Three things have to happen in the following order:

1. We must deal with the shortfall.
2. We must restructure how we manage the finances so our model is based on sustainability.
3. We must reinvent STC so that it is not only relevant to where we are going as a profession, we must be THE place where the voices who are shaping that direction are heard.

My ship analogy is that the storm has blown us on the reef; here's the drill:

1. Bail so we don't sink.
2. Fix the damage and restore physical integrity to the ship's structure.
3. Set a new course.

As everyone knows, part of the current solution to "we're sinking" is to transfer surplus reserves from the chapters. Wow, that has a lot of problems associated with it, so why are we taking such a controversial and difficult route?

Because those are the only pockets deep enough and liquid enough to solve the problem in time.

By the way, the shortfall is $1.2M, and we are handling all but $470K through cost reductions, debt rescheduling, and negotiations. What we need from the chapters is the $470K we won't be able to cover without their help.

We can do quick things that kind of translate into "Let's have a cake sale." Great, but we need $470K. That's a lot of cakes.

We can offer big programs; our certification task force thinks the potential revenue there could get into millions. Great, great, great, but it will take longer than we have.

So we've gone to the chapters. Not fair, some of that money has come from their own independent efforts (Atlanta still has some great cookbooks, by the way). Not fair! But a necessary sacrifice if we are to survive. I just don't have anything else I can say on that.

Point two, we have created a zero-based budget that looks at the whole picture: revenue, dues, and expenses as an integrated whole. We have a model that will be sound and sustainable. It is built on the principle that members should pay based on the level of services they receive. I can't get into the details, but if you watch those great Progressive Insurance ads (with Flo) and pay attention to the "Build the policy you can afford" one, then you'll get an idea of where we're going.

But dues will go up! The reaction we've already gotten is "How can you raise dues when part of your problem is you don't have enough members? Lower dues and get more members!"

The truth is that we could make it up in volume, but we cannot get to the volume it would take. Not in this economy, not with our current "curb appeal." Step two, then, is get a revenue/expense model that makes financial sense.

Politically, this is a hard sell. We want our national politicians to get rid of our deficit-bound economy, "Balance the budget, you idiots!" Then if one runs for office saying "I'll raise taxes and reduce services," we run him out of town on a rail. You see, he didn't understand that we wanted him to balance the budget by lowering taxes and increasing services.

Where are we going?

Phase 3: We must reinvent STC so that it is not only relevant to where we are going as a profession, we must be THE place where the voices who are shaping that direction are heard.

We need to be about content that helps professionals keep pace in a profession that measures how current you are in the dot releases of the tools you use.

• We are on the verge of releasing the Body of Knowledge Portal--a critical step in being THE resource to start with with any question related to technical communication
• We are moving into social media to help connect professionals into communities and resources.
• We are defining how a certification program will make us the defining group in our profession and draw new members and employers to us.

There are still some glaring shortcomings, not the least is we still do not have a good strategic marketing strategy for moving forward. That WILL come, but we must first solidify a modern value proposition that gives us a compelling message to market.

Conclusion

I hope this didn't come across as whiney--but I want folks to understand the true complexity of the problem space. I'm not standing here saying "Trust us," I'm saying "Help us." But for you to be helpful, you need to understand the full backstory and complications we are dealing with.

Finally, many heartfelt thanks to all who have Ninged and Tweeted with your support and with your criticisms. Stay with STC, be part of the exciting future we are building together, and support our programs as they roll out. Think Dallas 2010 and tell your bosses NOW to budget for it. Hint: Lloyd is working up some sweet early bird deals.

Bad Help

I just encountered the worst Help file I've ever seen, and that includes student projects from my days teaching Online Documentation at Southern Poly.

The content pane and the pane for displaying the TOC, Index, and Find (Find? as in can you say WinHelp.exe?) are two separate panes, and the TOC pane is modal!

Click to see enlarged version.

Not only that, but the Help is written at the microtask level--no insight as to how do I use this product to do something useful.

OK, so maybe this is some restaurant management software or some other application written by someone with no concept of user experience.

NO! This is a product designed and distributed by a company in the usability business--one whose product is meant to help you design usable software.

In all fairness, the product is way cool and works pretty well, but why do usability companies get all the way down to the user assistance level and then suddenly get usability stupid?

Dots is important

So I get an email from my IT guy saying that if we haven't already upgraded to WhatEver ver 8.02 we would be vaporized or something. Not being particularly anxious to get vaporized or something, I start to feel a little angst. I click About WhatEver and I see that I am at ver 8.0.2.

Hmmm, 8.0.x would be older than 8.02, but I've never seen a version number incremented with a leading zero after the point.

Am I OK because IT guy is sloppy about version numbers, or am I a candidate for the poof-mobile? Or am I just an anal-retentive technical writer?

I made a screen shot of my version splash screen and sent it to IT guy and asked if he really meant 8.0.2.

A DECENT human being would have responded, "Oh, my bad, I got sloppy and caused you unnecessary angst," and then he would have sent out a new e-mail clarifying his error to the rest of the company, but NOOOOOOOOOOOO. I got "You can ignore the notice."

You'd think folks who work with software day in and day out for a company that develops software would get version numbers better than IT guy.

So what did I learn today?

I'm an anal-retentive technical writer.

Myyyy Eyeeeeees!!!!

OK, I'm tired of being thrown into epileptic-like seizures as I sit through demos and walk-throughs of user interfaces.

I'm referring to speakers who twitch and jiggle the mouse, or who do a mad paint of the screen with the pointer as they search for the target they want to click.

Tip for anyone doing software training or demos:

Don't touch the mouse until you have made eye contact with the target. Then tell the user what you are going to click, and then go there smoothly (and directly) and click.

Thank you in advance.

Change is good

Well, not always. I'm tempted to rant about a recent experience at a bagel joint where I got short changed three times in the same transaction!

But other kinds of change are good. My role at work is changing, for example. Instead of being a User Assistance Architect in the Information Development group, I will be an Information Architect in the Usability group. Same boss's boss, but different boss and peer group.

Sad to be leaving old boss and old peers, but excited about the new boss and new team. Real excited about doing UX design again. It's one thing to look at a UI and noodle how to explain it; it's pretty scary when the page is blank and you have to lead the design.

I intend to continue this blog and its theme of user assistance. My focus will shift to embedded assistance and contextual assistance, that is, I will focus on user assistance that is delivered directly through the application UI. It will be interesting to see how my new found interest in Social Media plays out in my new role. I can already envision links that would have said "Tell me more about this option" now saying "Let me chat with others who have used this option."

How to make me stupid

Technical communication is essentially story telling on one hand and sense making on the other. I've noticed (suffered at the hands of) several patterns involving numbers that obscure both.

Consider the following question, "How much does widget A weigh?"

Bad answer: "You have to understand that it will be different in different situations. If it is the blue techno-widget, it will be 30 pounds, but if it is the red techno-widget, it can be as low as 20 pounds depending on if it is a model D, which is 20 pounds or a model C which weighs 25 pounds because it has the heavy duty battery."

Huh?

Better answer: "Twenty to thirty pounds depending on the model and battery type."

Common mistakes when talking about numbers

Here are common mistakes I see when people talk technical with numbers:

• Combining numbers with conditional statements. That's the mistake in the previous example. I'm having to hold too many variables in my head before I can get closure on a declarative sentence. Lead off with a simple declaration followed by exceptions. Another acceptable answer would be "About 25 pounds." That relates a bit to the next common mistake.
• Not rounding to a reasonable level. I sit in a lot of budget discussions where we are essentially discussing estimates and guesses and I am forced to comprehend and store numbers like 23,462 when 23,000 or even 20,000 is sufficient. Many people do not understand the rule of significant figures, that is, an answer cannot have more significant figures than are warranted by the input accuracy. For example, 10 volts divided by 30 ohms does not result in a current of .333333333333 amps. It results in .3 amps.
• Giving algebra problems instead of answers. "Q: How much does widget A weigh? A: Ten pounds more than widget B." Great, widget A weighs x + 10, solve for x.
  

There is a scene in Othello where the generals argue about how many ships are in the approaching armada. The bottom line, stated more eloquently by Shakespeare is "It's a shit-load of ships." In other words, providing the exact number is less important than contextualizing the impact.

I qualify as an offshore resource

Gasp! I can't live with the scandal anymore. I WAS BORN IN KENYA! I'm not a native US citizen.

Social Web: This old dog finally gets it

I think there should be a "Get Out of Purgatory Early" card for folks my age who try to keep up with Social Media. I signed up for Twitter and Facebook a while back to see if I was missing anything. I must admit I was pretty baffled by it all for a bit.

Tweets like "Just turned the computer on, man am I tired," left me wondering why the tweeter felt that the world was waiting for that update. Facebook people were poking me and taking quizzes that told everyone what kind of Simpson character they would be.

Huh?

A sliver of light

My first inkling that there could be something useful lurking here happened at the Atlanta STC Summit. As the host chapter, we arranged for the Atlanta Braves to have someone at our hospitality booth one morning to sell block tickets for a Braves game that night. The day he was to arrive, it occurred to me that we had not publicized this in any way. I asked Lisa Pappas, who is way cooler than I am when it comes to social networking, if she could tweet that the rep was coming on the #tag we were using for the Summit (I barely knew what a #tag was). She did. At one point I took a break from the board meeting to step out and apologize to the rep for the lack of advance publicity and found him packing up early. He had sold the allocated block!

Hmmm. That was useful.

More illumination

I then started to notice that I was using Twitter like a news aggregator because people I was following would recommend interesting Web articles they had just read. I recently noted the following pattern of tweets, going from great to lame:

• Great: There an interesting article on such and such at http:...
• Good: There comes a time in the lifecycle of a document you have to shoot the writer and publish the damn thing.
• Lame: I had oatmeal for breakfast.

I had been judging the social Web based on the abundance of "oatmeal for breakfast" tweets and posts I had been seeing.

Let there be full light

Recently, however, the major light bulb went on for me. I was starting to feel a lot more connected with contacts I usually saw once a year at a conference. The odds that I would pick up a phone or shoot an email to someone like Phylise Banner or Brenda Huettner if I needed help on something was now an order of magnitude higher than if I were not following them on Twitter or friends on Facebook.

It's as if I were linked into a social network! [a Mikey major Duh! moment]

I also found that I could link with folks I was having somewhat adversarial relationships with in STC. As an officer, I've taken quite a bit of heat over some unpopular decisions and problems lately from well-meaning and articulate critics. Twitter and Facebook have given me the opportunity to interface with some of these critics at the level of home-brewed beer and love of musical instruments. Their confrontations have been reduced from my total perception of them to being just part of a broader understanding of who they are. Hopefully that has gone the other way as well.

Suddenly the faceless and voiceless critics have become people who brew beer and play music. Does that make me now more willing to listen to them? You know, I think it does! At least it makes it easier.

I've said it before, "Oh brave new world..."

You Can't Handle the Truth

I was in a staff meeting recently where the topic was "What do you need to know in order to do your job better?" I can summarize the general theme in one word, "Truth." What is the real schedule, what are the real priorities, how is the project really going?

It seems truth is a rare commodity going both ways on the communication chain. People were equally concerned that they weren't getting the truth from management and that management wasn't being told the truth.

I'm not telling stories out of school; namely, because this is the same discussion I have heard at every software company I have ever worked at. I suspect it transcends industries as well.

• I was at an international conference in Leeds, England, on Learning in the Workplace where the keynote speaker asked "Have you noticed that the purpose of a project status meeting is to hide the status of the project?" He got a standing ovation.
• I used to teach project management at Southern Polytechnic State University and I would tell my students, "If you say the project will be six months late, you will be fired, but you can be one month late six months in a row and nobody bats an eyelash."
• Projects stay in green status until a few weeks before release and then go into red--all of a sudden the code doesn't work.
• Projects change status or iterations end not because criteria have been met, rather, because their due dates have arrived.

Part of the problem is an inherent dislike for delivering bad news. Partly as CYA and partly because genuinely we want to please others. We accept the pleasant fiction for the very reason that it is pleasant.

Part of it is that we treat mistakes like crimes and punish those who make them. Therefore, mistakes become things we must cover up.

But I think a major contributor is the whole myth of project management. We estimate dates and resources when we know very little about the problem space, let alone the solution, and then those dates become holy unto themselves. We beg others to lie to us (sometimes even insist on it). "How long will this take?" "Three months." "Not good enough, give me a better estimate!"

Let me offer a radical proposal: What if projects were open ended? What if a product didn't ship until it was ready? Instead of dates, we had feature and performance specifications, resource allocations, and release criteria. "Nothing would ever ship," might be a reasonable rebuttal. That is pretty telling in and of itself.

I know the devil is in the details, but it might be time to rethink our current model of design and development.

Lost in Space(s)

The APA has returned to its requirement that two spaces follow a period. See the first bullet in Chapter 4 in the Chapter-by-Chapter section or their "What's New" page.

The technoscribe blog-o-sphere is a twitter!

Those who have insisted on keeping two spaces in spite of the fact that ALL modern word processing technology accommodates the necessary spacing, take heart. Once again you are right.

Those currently getting therapy from a psychologist take warning--those who direct and publish the research of that practice are apparently still doing their work on typewriters. Expect the following edgy articles to be showing up in their journals:

• "The Steam Engine: Advance or Anxiety?"
• "Being Gay in America: The Role of Happiness in a Modern Culture"
• "Media Overload: Do We Really Need All Three Channels?"
  

Time for a new look

Some days a blogger just needs to feel pretty. Seems I'm into changes these days. My wife and I went to the movies this weekend. You need to understand how my wife and I go to the movies. We go and leave together, but rarely actually sit in the same showing. She saw "The Ugly Truth" [chick flick] and I saw Public Enemy (Johnny Depp with a way-cool scar on his face; did I mention I have a scar on my face?). Hers started about 30 minutes before mine so I hung out in the mall for a little before going in. Walking around, I saw it, the perfect hat--kinda a mix between a pork pie, a fedora, and a golfer's hat. Of course, they had the brim all wrong, but I was able to rework that (turned up all around). I bought it and sat in my theater feeling its soothing karma settle over me as if it were a wet towel wrapped around my head on a hot day. I've started growing my goatee back with a thin mustache (gratis to some skin cancer surgery this winter) and I was feeling "edgy." Well, my wife came into my show after hers let out and looked for me. She sat down next to me, looked at the hat, and all I got out of her was "I left you alone for twenty minutes."

I'm celebrating by changing the color scheme of my blog site. For those of you wondering what life is like when you reach 60; this is it.

G2G

A genre of technical writing that doesn't get a lot of attention is Geek-to-Geek (G2G). In that genre, highly technical people are communicating to other highly technical people. Most of the discussions in technical communication deal with transferring technical knowledge from experts to the average Joe.

Professional technical communicators need to be very careful when inserting themselves into G2G scenarios. Some examples:

• I had an intern once work on a specification document our engineering group had written so that customer IT folks could configure their applications to exchange data with our application. She took out the word "argument" everywhere it occurred because it sounded confrontational.
• I had a layout/graphics designer make a training manual I had written more "user friendly" by changing "120-volt (AC) solenoids" to "120-volt air conditioned solenoids."
• I was reviewing a document a software developer had written that was to be sent to other software developers in the company and found his excessive use of multi-layered indents to be distracting. I was just about to comment on it when another developer looked over my shoulder and said, "Cool, he's using FORTRAN formatting rules; that makes it so much easier for me to follow."

By no means am I saying that professional technical communicators have no role to play in G2G, but I do think our role changes a bit, and I think some of the rules we normally follow need to be modified.

I was recently involved in a G2G situation, and I noticed some differences between that genre and G2J (Geek-to-Joe). A developer in my company had written some documentation about how to use an open standard reporting tool to issue reports from one of our products. The readers would be developers who worked for our customers. Some differences:

• Technical writers (uh, me) like to write in generalities; geeks like specifics. We talk about how to change parameters, they describe how to change a specific parameter.
• Geeks want to show how things work--often describing what goes on under the covers; technical writers don't feel they need to prove the procedure does what we say it does, or even explain why it does. For example, in his discussion of parameters, the developer told the reader to run a specific report, then had the reader change a specific parameter, and then run the report again to see the effect.
  

Seeing how the developer wanted the reader to run a report, make a change, and run the report again reminded me of an experience I had years ago when I was a trainer at Nordson Corporation. Nordson is a company that makes glue applicators for packaging equipment (a hardware environment completely on the opposite end of the spectrum from the software world I now live in, but geeky none-the-less). We had a new product that glued cartons with a "sift-proof" seal--very useful if you're packaging powdered products like laundry detergent. The only problem was that we had only one field technician who seemed to be able to install one of these things correctly. So they sent me into the field with him to learn what he knew and to pass that on through training to the other technicians.

We got on site and the technician got the glue guns and sealing bracket all bolted on. He showed me a bolt that affected alignment of the sealing surfaces and explained: "Here's how I adjust this," and he turned it fully clockwise and ran a carton. The resultant sealing job looked awful. He then turned it fully counter-clockwise and ran a second carton. It too looked awful, but in a different way. He smiled and said, "See, now I know what effect it has, so I can now adjust it." Well he went on in this way through about three other alignment controls and in half an hour had this machine cranking out perfectly sealed cartons.

Hard to put into a training module, but a good insight into how geeks think and work.

Some things to consider when intervening in G2G:

• Geeks need to know underlying principles that will let them predict cause and effect.
• Geeks like examples.

Places we can add value:

• We know how to write instructions.
• We know our company's legal and style requirements.
• We know how to produce and distribute documentation efficiently.

It might feel a little secretarial, in so far as we should give the SME a little more leeway to dictate what information is important, but we still add a lot of value when we help make these G2G documents more "customer-facing."

But don't just roll over and play dead--for example, I took out the parts where we were telling users to run reports to see that changing the parameter really did affect the report--but in G2G, the geeky writer probably understands the geeky user better than we do. Be aware of that and try not to break what could be a perfectly clear explanation by recrafting it for the average Joe, who will never read it.

Cop vs Consultant

As a member of the STC certification task force and a former member of the Body of Knowledge committee, I have been interested for a while in understanding the core value proposition for engaging professional technical communicators. The essential question is "How is a technical communicator better than an engineer who writes well?"

I've read a lot of reports, essays, blogs, and e-mails on this topic. One of the bullet points that got to me was that professional technical communicators understand the legal requirements of documentation. It's not that it didn't make sense, it's just that I have never measured up well in that category. Now that I see it as a differentiator, I'm starting to take it more seriously.

Oh did I mention I work for IBM? I wonder if they care about things like copyrights and trademarks.

The kinda good news is that IBM provides me with a ton of information on my internal employee Intranet about trademarks. The really good news is that they provide a tool that searches my documentation and tags everything that could be trademarked. The tags are read by our output rendering tools and they apply the (tm) and (r) symbols appropriately, as in first use in a topic, not in a title, etc. I just have to do a manual scrub and look for places where their use is not a trademark, as in IBM being used in reference to the company not a product. Trust me, that's a small enough trade off.

It also gives me a tool that looks at all my documentation for word usage and notifies me when I use a term that is not approved or might be used in the wrong way. Most of the suggestions are based on how elegantly certain terms are handled by translators versus other terms with the same meaning.

I mention that as a bit of self-disclosure. I'm preaching that everyone should care about this when probably most already do and many do not have the nifty tool-box my employer has provided me.

But, it's probably worth a mention. Pay attention to the legal requirements and translatability issues, not only in your own documents, but in the documents of other groups like marketing and engineering. It's an area where we add value.

The tough part is doing it without sounding school-marmish (still working on that).

Maybe I'll modify the old "feel, felt, found" approach sales people use to handle objections, as in "I know how you feel; I felt the same way, but then I found..." I'll try "use, used, uncovered".

"I see you use the word following as in '...includes the following:' I used it the same way until I uncovered the fact that most translators will interpret it to mean something like 'group of admirers' when it is used as a noun. I now only use it as an adjective as in '...includes the following features.'"

I know I am trying to move away from my "you're wrong and I must warn the others" syndrome, but sometimes there is value in warning folks when something is wrong.