In Defense of a Populist Grammar--
My blog today will not be popular with most of my audience (ironically, given its title). I invite all who disagree to post their responses in Chaucerian English.

And that introduces my point, when is a language supposed to stop adapting itself? Twice last week I came across conversations involving transitive and intransitive verbs, specifically vilifying those (like me) who have started to use some transitive verbs as intransitive.

Quick refresher: Transitive verbs take direct objects, as in "Joe hit the ball." Intransitive verbs do not take direct objects, as in "The light shines." Some can do either, as in "Mary played the piano" and "Billy played all day." So my first point is how seriously should I take a rule when the mother tongue herself seems a bit ambivalent about it?

The issue is around transitive verbs that get used in intransitive ways, for example, "The error message displays in the status bar," or "Do not close the connection until the document prints."

This is an interesting usage and one I think has some positive aspects. It is also closely aligned with the disdain many hold for the passive voice. The trend I see is that certain transitive verbs are becoming intransitive when the logical subject (had it stayed transitive) would have been the computer. In short, we do not care about the ghost in the machine. I know the computer prints the document, but I don't care or I don't want to talk about the computer. So I make the verb "print" intransitive to mean "gets printed." Agency (whodunit) is lost, but we know (or don't care) what printed it. Same thing with error messages that display.

A positive aspect is that this construction makes it easier to treat the object of interest as the topic (subject) of the sentence. This construction is similar to passive voice (which I think writers and editors unfairly eschew). I had an editor today change my sentence from "the user's focus is distracted away from the text by the radio buttons," to "The radio buttons distract the user's focus away from the text." No big deal, but I wanted the sentence to be about user focus, and now it is about the radio buttons.

There seems to be a humanistic need to ignore the computer as doer (controller?), and this move to intransitize verbs seems to be an adaptation to that need. I think "The error message displays in the status bar" is a better sentence than the "The system displays the error message in the status bar." For one, it keeps the sentence about the error message, and secondly, we know the computer does it so no information is lost. And for purists who love active voice, it does it without resorting to the passive form, "The error message is displayed..."

Just one little problem. Display is a transitive verb (well, it does have an intransitive use that deals with birds and animals behaving in ways that tip off others what species they are). One solution is to recognize that there is a trend to downplay the computer as agent and shift agency to objects by treating heretofore transitive verbs as intransitive. A useful device. But to whom do we write in order to make that change official?

Well, I would look to the bard for that answer:
Thanne longen folk to goon on pilgrimages
And palmeres for to seken straunge strondes
To ferne halwes, kowthe in sondry londes.
Clear enough for you?

Conclusion: Let the language adapt to our changing needs and perspectives. The grammar books and dictionaries are history books after all--how the language was spoken. As long as meaning and clarity are not lost, what harm is done? Only English teachers get confused by the sentence "The error message displays in the status bar," sitting in front of the documentation asking, "Displays what? " Everybody else gets it and looks in the status bar to see if the system is displaying an error message.

In Memoriam--
I normally refrain from using this blog for personal ramblings, but this morning's news announced what is a deep and personal loss for me--the A and J Tasty Pig in Snelleville burned down last night.

Although I have lived within a mile of the A and J Tasty Pig for 25 years, I ate there only once--sausage biscuit...it was OK.

But I have always been in awe of the restaurant's name, its complete openess to what it was you would be eating if you went there. Pig.

"Pass the pig," is not a phrase you hear at a lot of dinner tables. In fact, about the only time you hear "pig" associated with the food is at a pig roast, and anyone who's been to one of those knows the futility of being coy about the animal of honor. It's there and in your face.

We're not so squeamish about chicken. We name lots of restaurants after it and use the same word whether speaking of the bird or the food. Same with fish. It would not be unusual to come across a restaurant named "Captain Billy's Fish Fry" or "Holy Mackerel" (especially in Florida where I think there is state law or at least strong guidelines from the Chamber of Commerce that restaurants must be given dumb names). We are so open about the association between creature and food in the case of fish that when eating one of the most ubiquitous of the species, the tuna, we add on the word fish just for good measure. As in "Give me the tuna FISH salad, yeah you got me right, I'm eating a fish! You hear that over there in the corner booth, I'm eating FISH!"

So why the taboo against admitting that we are eating a cow? I've never seen an A and J Tasty Cow. The only restaurant that uses cows in its ads is Chick-Fil-A, a chicken joint. They are mainly trying to remind us what we will be served if we go to MacDonalds or Burger King.

I pity the English as a Second Language teacher who has to cover this. Meanwhile, I'm real sorry that the A&J Tasty Pig burned down, even though I don't go there.

It's Aliiiiive!!--
I've recently become sensitive to an apparent fault in my writing: I'm guilty of anthropomorphism, i.e., the representation of objects as if they had human traits. I was reading someone's essay about a professor who had influenced him and the writer noted, "He taught me to think and write critically, and always nailed me for writing anthropomorphically, such as 'The data showed... when it should be written as 'Inspection of the data revealed...'".

I thought about that this morning as I wrote, "This section discusses..." Would the reader have been better served by "In this section I discuss..." or "This section presents a discussion of..."?

In short, what is wrong with anthropomorphism? We say that a machine is running. Does that send a throng of people down the hall to see this miracle of a machine that has sprouted legs and is moving speedily on them? In the same vein, what is wrong with data showing trends or a section of a document discussing a topic?

And if you disagree, I would not be in the least confused by your saying, "Your blog screamed of incompetence." (My little feelings would be hurt, but I would not be confused.)

Anthropomorphism is a little like passive voice in so far as it can obscure agency. But, also like passive voice, it is unfairly maligned. Where agency is unimportant (The data showed...) or obvious (This section discusses...), anthropomorphism allows the content or the document to be the topic. For example, when saying "This section discusses..." I prefer to be talking about the document structure rather than talking about me.

My keyboard grows weary of this topic and my monitor longs to be displaying landscapes and vistas of my screen saver. I must do their bidding :-)

Users! They've been around for centuries apparently---

The book

Has Web 2.0 made affordances like so yesterday?--
Granted, the fact that I am 57 years old might be a contributing factor here, but I am seeing what I consider to be a disturbing trend in web design.

Editable fields look like read-only until the user mouses over them. In technical terms, the trend is to reduce the number of affordances (using visual clues to communicate that objects can be acted on) and to rely instead on applying pliancy effects (changing the appearance of objects when focus is applied) to show when actions can be taken on them.

For example, if I open a meeting notice on my Google calendar, I see what appears to be a group of read-only fields, such as "What," "When," "Where," and so forth. But if I move my mouse over any of those fields, they change appearance and background color to indicate that I can edit them.

Here is my concern: If I did not know that the "What" field (for example) could be edited, why would I move my mouse there? It seems that taking away the affordance of showing the field as editable has reduced the ability of the box to show the user how it can be used.

Is this a user assistance issue at all? I say yes because the application has lost some of its effectiveness to instruct the user what information can be edited. Is the solution to cover that in Help? (must....control....hand....of....death)

If you see this happening on your applications, fight it and point out the loss of instructional content within the UI.

Progressive User Adoption (redux)--
I'm in an all-week training session learning how to do contextual design. Very neat stuff, by the way. We've done some contextual interviews and did some initial interpretation and the outstanding common observation is that the users we observed were using just a small portion of our product's functionality. As I have noted before, users typically plateau out at a sub-optimal level, and user assistance can provide tremendous value in systematically moving the user through progressively higher levels of product adpoption (see my Currents presentation).

What struck me in this current study we are doing it the negative impact the user's premature plateau was having. I talk in my article about unused features being the long tail, but what I saw this week is that our competitive advantage is in those long tail features--and they are not being used. It is so frustrating to hear users say, "I really hate that your product can't do..." and then they name a feature that our product has.

As I have said, I think there is a great opportunity for user assistance to add value by being part of a conscious, progressive user adoption strategy. Come to the Atlanta STC Currents conference on March 10 and hear more about this topic. (Yes, that was a shameless plug!)

The Rules Are Changing--

Want to get excited again about being a technical communicator? Watch this: http://www.youtube.com/watch?v=6gmP4nk0EOE&eurl=

The title is "Web 2.0 ... The Machine is Us/ing Us," and it is an extraordinary piece by Michael Wesch, a social anthropologist from Kansas State University.

And there is this piece: http://www.nytimes.com/ref/washington/20070123_STATEOFUNION.html. Think of it as Tufte online. (BTW, Tufte is also from Kansas, hmmmm.)

It reminds me that we have a whole new level of interacting with users, and we should be applying those new possibilities to user assistance.

But every force has its dark side. You hated Clippy? Look what Microsoft is doing now!
http://www.msdewey.com/.

Successful user assistance is like a three-legged stool: Respect the content, respect the technology, respect the user. Ms. Dewey misses the last leg.

Progressive User Adoption--
For those who were patient and let me ramble on last month about progressive user adoption, you might want to look at the more coherent discussion I will be presenting at Currents (STC Atlanta's conference) in March. I've preposted the paper to my web site http://www.mindspring.com/~mikehughes/index.htm . The newest twist is that I relate it to a long tail distribution marketing strategy, so you might find it is a new way to promote the value of technical communication as a revenue enhancer.

Shut Up and Talk--
A colleague sent a clip from an academic website that lists its latest banned words. It reminded me what I don't like about us (technical writers): We forget sometimes that language is about talking to each other, not setting up obstacles to the same. Some entries and my rebuttals:

NOW PLAYING IN THEATERS -- Heard in movie advertisements. Where can we see that, again?"How often do movies premiere in laundromats or other places besides theaters? I know that when I want to see a movie I think about going to a shoe store." -- Andrea May, Shreveport, Louisiana. (Mike: How about cable and network TV? Andrea apparently hasn't seen a movie since 1931)

ARMED ROBBERY/DRUG DEAL GONE BAD -- From the news reports. What degree of "bad" don't we understand? Larry Lillehammer of Bonney Lake, Washington, asks, "After it stopped going well and good?" (Mike: Generally refers to the part where people started getting killed. It's called gone bad because it was not part of the original plan. Notice, Larry, it never says "murder gone bad.")

ASK YOUR DOCTOR -- The chewable vitamin morphine of marketing."Ask your doctor if 'fill in the blank' is right for you! Heck, just take one and see if it makes you 'fill in the blank' or get deathly ill." -- R.C. Amundson, Oakville, Washington. (Mike: R.C., it means it's a prescription drug. Last time I checked, just taking one on your own was illegal.)

i-ANYTHING -- 'e-Anything' made the list in 2000. Geoff Steinhart of Sault Ste. Marie, Michigan, says tech companies everywhere have picked this apple to the core. "Turn on…tune in…and drop out.""Banish any word that starts with it. i am just tired of it. it's getting old. -- Brad Butler, Adrian, Michigan. (Mike: diot!)

HEALTHY FOOD -- Point of view is everything.Someone told Joy Wiltzius of Fort Collins, Colorado, that the tuna steak she had for lunch "sounded healthy." Her reply: "If my lunch were healthy, it would still be swimming somewhere. Grilled and nestled in salad greens, it's 'healthful.'" (Mike: Want to guess that was the last time Joy got asked to lunch?)

Hey, folks, relax. People are communicating here. I'll end with my pet peeve: folks whose pet peeve is using nouns as verbs, ala to google someone or task someone to do something. It's a normal construction in our language. We iron our clothes, bicycle around the park, book criminals, table discussions, etc.

Here is a useful rule of thumb: If you understood what someone said well enough to know right away you disagree with how they said it, they must have said it pretty good. ;-)

Instructional Text on the User Interface: Some Counter Intuitive Implications--
User assistance occurs within an action context (the user doing something with the application) and is almost always delivered in close proximity to the focus of that action, that is, the application it supports. When user assistance is displayed within the application as instructional text on the user interface, conventional principles of good information design must be modified to accommodate certain forces within an interactive user interface.

Consider the following assumptions. If you accept them, they are going to lead to some implications for UA design that might seem counter intuitive to some.

• The flow of focus by which users process information on a computer screen is the same as when they process information on a page. In English, for example, that would be left-to-right and top-to-bottom. In Arabic, for example, that would be right-to-left and top-to-bottom.
• Users within an application are motivated to take action, and their focus is easily drawn to action objects, such as text fields, menus, and buttons.
• Once the user's focus is drawn downstream in the focus flow, it is difficult to redirect it upstream. In other words, if something initially draws the user's attention to the middle of a screen, it is far more likely that they will continue going over and down as opposed to going back up. This is especially true if there are additional action objects downstream.

Example
So let's consider a simple application with a two-button radio button group, and you would like to explain the concepts needed to make the appropriate selection. An example I've used before is a report output dialog box that has the user select HTML or PDF for the output medium.

If you have an instructional design background or have been well-grounded in information mapping, your instinct will be to define the terms and give appropriate selection principles before you present the radio buttons. In other words, you will be inclined to put the instructional text above the radio button group. In a document that is removed from the action focus, it makes a lot of sense to introduce definitions and principles early in the document in order to prepare the reader/learner for what comes later. But if you accept the three assumptions I presented earlier, you will understand that the following scenario is what typically happens in a UI:

1. The user's focus is pulled almost immediately to the radio buttons because the user is motivated to act.
2. This jumping immediately to the buttons causes the user to leap-frog over the instructional text.
3. Once downstream of the text, the user does not go back and read it, even if unsure of what the buttons mean. The user makes a best guess and moves on (attracted by the next action object downstream).

I have seen this scenario played out in countless usability tests of form-based web applications where instructional text is placed at the top of the web page. The problem is exacerbated by the resultant appearance of seemingly a lot of words being presented as a dense block. Much the way that quantum physics says that dense matter bends space, I hold that dense text bends users' "eye rays" rendering dense text invisible. The user tries to read it but at the last second their eye rays get deflected and they see the action object instead. (OK, the physics is a little flaky on that one, but you get the point.)

Implications
When putting instructional text on the user interface, apply the following principles:

• Divide dense instruction up by action objects, and put the appropriate text in close proximity to its respective action object.
• Put the text next to the action object (in the downstream direction preferably) or just below it.
• If the text is too long, and this orientation disrupts the screen layout for the action objects, for example disrupting the grouping of a radio button group, provide a link that opens a pop-up or dynamic pane. I have seen links be very effective when phrased like an FAQ.

Instructive Labels--
I should have learned by now not to trust my instincts. Instincts are often the manifestation of programmed learning, which means that our creative and critical circuits have been turned off. That's why collaborative teams are so useful; members can challenge each other's programming.

Huh?

I'm working these days on a team designing an online, interactive workbook that helps a network administrator plan how to install and deploy a security appliance. The workbook has three purposes:

• Advise the administrator about some decisions that need to be made
• Provide a checklist at the end that lists the steps the administrator must go through (based on how he or she answers certain questions in the workbook)
• Direct the administrator to the correct deployment documentation (once again, based on how he or she answers certain questions in the workbook)

I wireframed an approach that I thought had great merit. (It turns out it had merit, just not GREAT merit.) A typical page asked whether the user would use the device in routing mode or transparent mode and was set up like this:

1. The page contained a short intro paragraph that explained the device could operate in two different modes and that the administrator had to designate which mode.
2. Two radio buttons were provided, labeled "routing" and "transparent".
3. Next to each radio button was a thumbnail diagram that showed a typical typography for that mode.
4. Next to each diagram was a description of when/why the user might want to select that mode.
5. Beneath that explanation was a link to provide more detail about the mode if the user wanted it.

//In my next post, I'll talk about why I rejected the design of explaining the required concepts before asking the user to select the mode. That's an entirely different topic.//

Step 2 is where my instincts did me in. It just seemed so right that a radio button group for selecting options should have the names of the options as labels. (Hence my lack of embarrassment--it's not one of those decisions that screams "stupid.")

Then one of the writers on the team asked one of those questions that just makes me go "huh!"

"Instead of labeling the buttons with the names of the modes, which we then have to go on and explain, can't we just label them as statements that get right to the main selection criteria?"

Example
Let's say you have a report output dialog box that includes selecting the output format. The two choices are HTML and PDF.

My instinctive approach is to have a radio button group with two buttons labeled HTML and PDF respectively. My user assistance instinct is to provide a tool tip or UI text that would elaborate on those choices, e.g., "Choose HTML to view the report online; choose PDF to have a printable version."

My colleague's suggestion in the first example would have the labels themselves say "I want to view the report online (HTML)." and "I want a printable version (PDF)."

Clutter or good user assistance? It depends. If you were going to take up screen text explaining the label (as in my first example), my colleague's approach is clearly better. In the second example, we have to make a judgment call about how well known the output labels of HTML and PDF will be. In an authoring tool meant to be used by tech writers--clutter. In a business intelligence application meant to be used by financial managers and analysts--maybe worth the screen real estate.

At any rate, it's always a question worth asking. Let your creativity and critical thinking challenge your instinctive approach.

Expert Guidance in User Assistance--
Those who read my ramblings in this blog on this topic, can read a more coherent discussion in my article in UXMatters. I've decided to make this topic my point of passion this year :-)

Stay posted.

Happy New Year--
And speaking of new year, the theme of the January issue of SIGCHI's magazine, Interactions, is "Help: User assistance and HCI." I have an article in that issue called "A pattern language for user assistance." I've posted a copy to my website, and you can link directly to that copy here.

I will be doing a presentation at the WritersUA conference in March on this same topic.

I have another article coming out next week in UXMatters. That article is called "User assistance in the role of domain expert." This is a topic I have discussed in this blog, and will include a practical example of a pattern language.

I will also writing a regular column for UXMatters called "User assistance: Putting Help in context." I will be drawing a lot from the material I experiment with in this blog (and benefitting from a GREAT editor, Pabini Gabriel-Petit).

Progressive User Adoption: More thoughts on building an adoption profile--
Before moving off the topic of laying out a suggested progression for user adoption, I would like to discuss the two main progressive adoption dimensions: efficiency improvement and feature adoption. In essence, efficiency improvement says, "There's a better way to do what you're doing." Feature adoption says, "You can do more things than you're doing."

Efficiency Improvement
The biggest challenge you face with efficiency improvement is that you are coming in low on the benefit/effort ratio. By that I mean that the user is already getting the task done and you're trying to get the user to invest immediate time and energy for a longer term gain. This ranks right up there with telling overweight people they need to diet and telling smokers they need to quit. In other words, don't expect the user community to hoist you on their shoulders and carry you in a display of triumphant gratitude. In this dimension, we are going to want to look at strategies that minimize the adoption effort, possibly embedding shortcuts and some degree of functionality within the user assistance itself.

Feature Adoption
Depending on your business model, increased feature adoption could be a real sweet spot for you. Even though there is still an increased effort required on the part of the user, the one thing you have going for you is being able to offer benefits the user is not currently getting. The dominant strategies here will be to show (illustrate or demonstrate) the new state and communicate the ease with which the user can get there (and cancel back out).

Considerations
When laying out your adoption profile, think about along which dimension you will be taking the user. If you are only going to improve efficiency and the user does not do that task very often--you might just want to let that dog lie sleeping, or at worst, give it a gentle nudge and move on.

The better payoff is along the feature adoption dimension; spend your time and creative energy there.

Progressive Adoption Principle 2: Establish an Adoption Profile--
The secret to progressive adoption is to stop thinking of adoption as a Yes/No state on the part of the user, rather think of it as incremental adoptions over a period of time. Map out the basic core features that would represent minimal adoption and apply principle 1 to those ("don't get in the way"). Next decide what levels logically lead the user through a comfortable progression pattern over time.

For example, in online bill pay, we decided it was too much to ask a user to start by turning off paper bills and having the system pay electronic bills automatically. They first had to build a trust in the system. The best progression seemed to be:

1. Get the bill in the mail and pay manually online.
2. Authorize getting the bill electronically but still pay manually online.
3. Authorize routine bills to be received electronically and payed automatically online.

Two elements you should consider when planning a progression profile are:

• Level of trust required. Plan a progression that allows the user to build trust with the system. Trust can mean a lot of things, trust you with my data, trust you with my SSN, trust you with my credit card number, etc. It can also mean I trust that all this work is going to get me what I want. For example, MS Excel's Chart Wizard lets you see how your data will be graphically displayed at each step in the process.
• Level of skill required. Move the user along incrementally from basic skills to get core value to more advanced skills to leverage greater value. For example, MS Word starts with a default template in place. Using templates should not be an initial requirement, but should be planned as a step that happens after the user has made the initial adoption. Steps along the skill dimension should be sized for easily managed progression. Don't make the user have to learn a lot to get more value. As long as the perceived increase in value is proportional to perceived effort to get there, you have a workable progression profile.

I will discuss concrete user assistance techniques that can be applied to support progressive adoption over my next several blogs.

Stay posted.

Principles of Progressive Adoption--
In my last blog entry I introduced the concept of progressive user adoption, moving a user further along in terms of the frequency of use, number of features used, or the depth of functionality (moving from basic to advanced). This week I will start to explore principles of progressive adoption, especially where user assistance can be involved.

Priniciple One: Don't interfere with core functionality.
Keep the basic tasks (the prime reason for the user being in your application) easy to do. This could be Clippy's fatal flaw—he intrudes when I don't need him, forcing me to get off task to dismiss him. His lame attempts to be precious do not make me want to kill him more, just kill him more slowly and in imaginative ways.

How do you apply this principle? For one, when the user assistance intervenes, make the intervention easy to ignore without action. If you force the user to dismiss the intervention, you are detracting from the core experience. Mirosoft Project does this fairly well. For example, if you add a resource to a task, an icon lets you know there is a tip. If you click the icon, a popup opens asking do you want to increase the work or shorten the duration? Based upon what mode you are in, it has already made the appropriate decision and has marked it as the default choice. If you just plow ahead and keep working, the popup goes away and the default choice stays in effect. So as a user, I get two opportunities to ignore the progressive help. I learn to ignore the tip icon when I know what the tip is about, and I can just keep working when I get the tip without having to select the default choice. I do have to click back into the desktop, however; it would be even better if I did not have to even do that.

Probably one of the most important dynamics in progressive adoption is "readiness," the user must be at a state that is ready to accept the change. Until then, coaching or coaxing the user to a new level of product use can detract from the quality of the core experience and you end up losing the user [insert clever fishing metaphor here—it's early in the morning and I'm too tired to do it myself].

So the bottom line in progressive user adoption is to measure all interventions against the yardstick of "Does this interrupt the core task?" If the answer is yes, change the intervention.

Progressive User Adoption--
I'd like to start a series of entries about the role that user assistance can play in what I call progressive user adoption. User adoption describes the rate that users will accept a new product or new technology. People who discuss user adoption usually mean it in the sense of the initial decision to accept or reject the technology or product as well as the ongoing re-enforcement of that decision. By progressive user adoption, however, I will be focusing on the tendency of users (or reluctance) to progress more deeply into the features, functionality, or frequency with which they use a new technology or product. Of partciular interest is why users' adoption curves typically plateau out at a suboptimal level.

Let me start with some concrete examples of what I'm talking about. Whenever anyone of us starts a new job one of the first questions we ask about the phone system is, "How do I dial out?" We learn what we have to learn in order to make the initial adoption decision. Fast forward several months (years) later and see if that person has learned to do a 3-way conference call (or in my case, even make a simple transfer). In many cases the answer is NO.

And how often have you had to edit a document someone did in Word only to find out that no style tags have been applied. All layout and typographic effects have be done with tabs, paragraph returns (sometimes one between paragraphs, sometimes two or three) and by manually bolding and changing text size to create headings? Why was this person not using the style tag feature that would have made the process so much easier and the output more consistent?

In short, why do people quit learning before they're done learning what they need to know?

Why Care?
Well, first off, why do we care about this premature leveling of the learning curve? If they've bought the software, why should we care how well they use it?

As is so often the case, the first question you need to ask is, "What's your business model?" More and more, due to e-commerce on the Internet, revenue around a product is transaction based. For example, I worked for a company that provided online bill pay software and the processing of the payment that went on behind the scenes. It made money everytime someone paid a bill with its product. The more bills someone paid, the more money the company made. Transaction-based products have a lot of skin in the game around progressive user adoption.

Of course, there is e-commerce, where user activity is directly related to revenue. Do you think Amazon.com wants me to stop shopping on their web site after I've bought my books? Do you think they would like me to progressively adopt them as my music and electronic gadget supplier as well?

And even non-transaction based applications have an interest in my progressive adoption of the features that give their product a competitive advantage or increase my satisfaction and loyalty. Nobody uses WordStar anymore, not because it did not produce good looking documents, but because it was displaced by GUI-based word processors that made it easier to adopt advanced features, such as style tags, automatic headings, etc.

And as we see Google and Microsoft moving into the web app space where revenue will be tied into usage, progressive user adoption will become critical in those kinds of applications as well.

So What's the Problem?
Having been involved in online banking and online bill pay applications, I have been very interested in understanding why users' adoption stops at less than optimal utilization of a product. The following explanation is based on observations made in formal usability tests, focus group research, contextual studies, and is supported by published research such as Everett Rogers' seminal work in Rogers, E. M. Diffusions of Innovations (4th ed.), New York: Free Press, 1995 and an interesting model called the Technology Acceptance Model, see Davis, F. D., Bagozzi, R. P., and Washaw, P. R. “User Acceptance of Computer Technology: A Comparison of Two Theoretical Models,” Management Science, 35, 1989, pp. 982-1003

In short, people quit learning before they're done learning for the following two reasons:

• They shift from a learning/exploration mode to a task orientation mode. When users can meet their initial goals, they stop exploring. Instead, they focus on doing what they came to do, e.g., paying bills or writing a report. In other words, they don’t look for ways to do what they don’t know they could do. I discuss this problem in general with why users abandon help procedures in a proceedings paper called "Procedures: The Sacred Cow Blocking the Road?"
• A reduced benefit/effort ratio. The benefit/effort ratio is less attractive for incremental improvement than for initial adoption. There is a big difference between “If I don’t learn how to make a phone call, I cannot get in touch with my essential contacts.” and “If I don’t learn how to transfer a call, I can’t pass an outside caller on to someone else in my organization.” The benefit side of the ratio is often diminished in the eyes of the user by existing alternatives that allow the user to reach a goal, although in a less efficient manner. In the call transfer example, the user can always give the outside caller the third party’s extension and ask them to redial that party directly.

What's Next?
I think that user assistance can have a positive effect on progressive user adoption if designed to do so. It can also have catastrophic consequences if done poorly. (I'm not making any specific references to Clippy here; I'm only saying.)

My next series of blogs will continue to explore how user assistance can be an asset to a company where progressive adoption advances the business model.

Stay posted.

Given-New vs. Analogy--
Today's blog is for die-hard writers who get a buzz from talking about rhetoric. No tools or technology today; I'm going through enough of that on the day job :-)

I was structuring a formal analogy the other day, you know--A:B::C:D (read A is to B the way that C is to D), and wondered what the preferred sequence should be. Should the new relationship be in the AB slot with CD being the relationship the reader is already familiar with, or should AB be the familiar relationship and CD be the one that is new to the reader?

I've always been a big fan of using a Given-New rhetoric when trying to explain complicated material. In that scheme you make the topic (subject) of the sentence some concept the reader is already familiar with, and you introduce the new concept in the predicate. Then the next sentence can take the predicate from the previous sentence and make it the subject, since it has now become a "given." The technique allows you to build up a knowledge base, so to speak, within the reader in small, manageable steps.

For example, let's say you had to explain DITA to a reader base for whom it would be a new concept. Watch how in the following text, the subjects of the sentences are concepts that are already familiar to the reader. Pay particular attention to the dance that ensues from a concept going from the predicate position in one sentence (where it was the "new" concept) to being the subject in the next sentence (because it is now a "given" concept). The following explanation assumes that the concept of structured writing is a familiar one to the reader.

A form of structured writing that has gained much popularity in recent years is DITA. DITA stands for Darwin Information Type Archictecture and is an XML-based approach to authoring. XML is the mark-up language that enables authors to share content across different platforms and among different documents.

You get the idea. This is a blog and that was a quick example, so don't edit me too critically on it. Like any horse, Given-New can be ridden to death and its overuse can leave your discourse sounding "sing-songish" and feeling mechanical. None-the-less, I have found that it is often a good technique for first drafts of paragraphs where I feel I have to move the readers across a rather large gap between what they already know and what they need to know.

But that logic didn't "feel" right to me when trying to put an analogy together; the order of New-Given seemed better within that device. For example, let's say I am trying to explain DITA topics to someone who is already familiar with Information Mapping. Which of the following analogies works better?

• Topics in DITA are similar to maps in Information Mapping.
• Maps in Information Mapping are similar to topics in DITA.

I think the first works better even though it is leading with the new concept and relating it to a given. Maybe because in context, it would appear in a discussion about topics, and, at least in that context, it would be the given topic.

But beyond that, I think there is something to be gained in an analogy by posing the strange relationship first and then grounding it in the familiar. It seems to be consistent with a principle I have noticed in instructional design: Students have no way to process a solution until they experience the problem. In other words, it's best to raise the question before providing the answer as an isolated fact.

Gap Analysis--
Sometimes we operate under the false myth that we must write user assistance for the lowest common denominator. I think this leads to bad help quite frankly. The better approach is to have a multichannel approach to user assistance and target channels toward the appropriate level of expertise for that channel.

I'm working on an embedded user assistance model (a dedicated help pane on the application UI), and this principle has suddenly clarified things for me. The issue came up, how far do we go with the embedded user assistance? My answer for embedded user assistance is, "Not too far." This channel is excellent for users that are almost smart enough to not need assistance. If the gap is large, other channels like elearning, tutorials, etc. are the appropriate place to deal with those needy ones.

In other words, it's OK to say, "You have to be this tall to ride this ride."

Once we accept this, then we can focus user assistance at the audience more appropriately.

Example
Let's say you were doing an embedded user assistance for a word processor, specifically the part of the application where you do Headings and Footers. I'd note in the embedded user assistance that headings can be automated by inserting a StyleRef field. I might add that this helps users find a topic by browsing the document header.

But what if someone doesn't understand style tags, should we put help about that in the embedded UA? What about principles of document design in general and what constitutes good heading hierarchies and should the StyleRef refer to Heading 1, Heading 2 or what?

Nope, nope, and nope. A snippet of help in a narrow sidebar in the middle of an off-main-page task is no time and place to educate the user about document design. It is a good place to ooch a fairly competent user to a higher level of efficiency or performance.

Put the training bit somewhere else.

Besides, what are the odds that your lowest common denominator is doing headings anyway?

Why I'm Not a Technical Writer--
And as Jerry Seinfeld would say, "Not that there'd be anything wrong with that." But I need to regroup and get my strategist hat back on here at my day job, and I feel the need to articulate and summarize what it is I do as a User Assistance Architect that is different from what I did as a technical writer.

Models
I seem to spend more time building models than producing documents. I do task analysis, just as a technical writer would do, but I seem to be less interested in "what a user needs to do" as much as "what would a user need to know?" And beyond that, I abstract one more level to "what kinds of information does a user need?"

I define patterns a lot. We have a department Wiki and I have a published pattern language I follow in posting patterns to our Wiki. By the way, I have an article coming out in the January/February issue of Interactions, the SIGCHI magazine. That issue will be a special topic issue edited by Fred Sampson focusing on User Assistance. My article is entitled "A pattern language approach to user assistance" (so much for coy titles). I hope folks get a chance to read it. I will be doing a presentation on this same topic at the WritersUA conference in Long Beach in March.

I wireframe a lot. I never did that as a technical writer, and frankly, I don't see a lot of technical communicators doing that. Wireframes let me model how the user assistance will behave. One reason we don't do a lot of that as technical communicators is that we are bound by the authoring tools. But that is tied into the model that Help is a separate application. As we get into more interactive models where user assistance is blended into the application, we need to wireframe how that works. Wireframing and use case modeling are two nifty disciplines I picked up while working as a UX designer at my previous job.

But I don't do a lot of use case modeling, and I'm not sure why not. Perhaps the pattern language approach fills the need that use cases did when I was designing UIs. But the other day, I did find myself looking at wireframes and asking about alternate and exception cases, so the discipline is still there and seems to influence me.

Content Management and Publishing Technologies
I spend a lot of time researching how we can author, store, retrieve, compile, and display information. Five years ago I would have been thinking about writing and publishing documents.

And somewhere in all that will eventually come architecture and tools.

Conclusion
Thanks for your patient ear. I'm stoked again.

My job is (1) to understand how our users apply information to their tasks, (2) how best to structure and deliver that information within the contexts of those tasks, and (3) how to author and manage that information so that it can be meet 1 and 2.

I gotta get to work!