Friday, March 30, 2007
Tuesday, March 20, 2007
I've created a new term, chinking, to mean:
- Breaking a topic into atomic chunks and then making the user get to them through individual links. Also,
- Chunking these mini-links into a page of virtually nothing but links (typically introduced with an anemic stem sentence)
Essentially, it's Information Mapping as practiced on the planet Bizzarro.
Structured writing approaches, such as Information Mapping and DITA, assert that a topic should be self contained. That means that it has to have enough depth and breadth to satisfy a reasonable need for information. Some user assistance writers take modularity to too granular a level and thus undermine the ability for a topic to stand on its own.
Chunking good.
Chinking bad.
Wednesday, March 14, 2007
I love the Southern expression, "Bless their hearts." It's kind-hearted, but with a tinge of self-righteous superiority. As in, "They're doing the best they can, bless their hearts." It's also sympathetic with no commitment to be helpful. As in, "Can't log into the critical network drive that has all your work stored on it? Bless your heart." I think error messages should end with it. "System 404 error, website can't be found, bless your heart."
I went into a Help file recently trying to get help about an application. I used the context-sensitive link expecting to learn more about the page I was on. I got a page with an anemic stem sentence with seven links. I wasn't quite sure which one would help me so I guessed and clicked one. It expanded into five more links. They were trying their best to help me, bless their hearts.
But my response was not one of gratitude. What I wanted to say was, "Hey, who's supposed to be asking the questions, me or you?" Since the Help screens that were being 'anything but' were part of a Help system I am working on, I get to roll up my sleeves and do something about it.
So we are now working on a new architecture, one that emphasizes giving useful information on the first click and then offering a simple, two-path fork: One that gets the user directly to the task information (procedure) and one that takes the user to a guidelines topic. Each of those topics can have more links on them (for example, extended background topics linked from the guidelines topic), but by then the users are smarter and can understand their choices better.
On simple screens, we can make either the guidelines topic or the task topic part of the initial information screen. (In those cases, if the UI is self-explanatory, consider making the guidelines topic the first topic and link to the task topic from it.) On complex, multitask screens, such as multitab screens, the Help link could open a topic that has a Tab/Description table. For each tab description, provide the double link, i.e., task or guideline.
Principles
- Don't make the users click through a link farm before they get to anything useful. Give them insight into the application at their entry point into the Help system.
- Don't overload the user with decisions at their entry point into the Help system. Expand their choices as they travel the drill-down path.
Monday, March 12, 2007
I freely admit that I went to this year's Atlanta STC Currents with low expectations. I'm not sure why. As it turned out, I left more excited and energized than from any international conference I've ever attended. The three sessions I attended demonstrated leading edge thinking that I just wasn't anticipating at a local conference (Jack Massa's report on a usability assessment project, Holly Harkness's panel discussion combining perspectives of industry practitioners and academics, and Jennifer Bowie's presentation on the declining interest in research). The keynote by the new STC Executive Director, Susan Burton, was best summarized by Dirk Bender, "There's a new sheriff in town."
What's my point? Go to your regional conferences. The class acts and presentations you get at the international conferences are speaking at the regionals. For example, George Hayhoe, editor of the STC journal Technical Communication, will be doing a presentation on Knowledge Management 101 at the Summit conference in May. George used Currents as a warm-up for that presentation.
But best of all for me was the interaction I had with other technical communicators as we talked about the "bigger issues" that face our profession and not just the daily grind of "can you get Notes working today?" It was a delightful serving of brain food and caffeine for my professional motivation.
Thursday, March 08, 2007
I now have a regular column in UXMatters called "User Assistance: Putting Help in Context." By the way, if you ever catch yourself wondering what an editor does, read my raw blogs on a subject and then read what eventually shows up in UXMatters. (Thanks, Pabini)
This Saturday is Atlanta STC Currents. Y'all come out.
Friday, March 02, 2007
Not at the same table, mind you. He was at the VIP table at the front of the room and I was sitting half a football field away. But I did get to hear Chris speak at the Technology Association of Georgia conference, Innovation 2.0. Mr. Anderson is the editor of Wired magazine and creator of the long tail view of market distributions. Just as Lynyrd Skynyrd cannot do a concert without doing "Sweet Home Alabama" Chris did his obligatory spiel on the long tail. But then he got into his latest passion, the econonomy of abundance.
Scarcity vs. Abundance
Old thinking is about scarcity; new thinking is about abundance. Scarcity thinking told us bandwidth was scarce (so we kept web page content free of bandwidth hogs like graphics and video). New thinking says bandwidth is abundant (can you say "YouTube?").
At any rate, before it too late to say "to make a long story short," I pondered what kind of scarcity thinking might I be engaged in that was limiting my user experience and user assistance designs. I realized that I have always operated on the assumption that real estate on the user interface was limited. If I were to think in terms of abundance, I should consider the real estate on the user interface as being infinite. As I was chuckling to myself over that in my worldly-wise chuckle (hard to convey in text but imagine listening to a cynical Jack Nicholson playing a curmudgeonly tech comm professor just hearing a fresh-eyed, perky student say that improved instructions on the sides of shampoo bottles could make the world a better place) when it occurred to me--duh, the real estate on the UI is infinite! I apologize to my esteemed colleague at CheckFree, Jeff Zimmerman, who spent the better part of two years trying to teach me this for my presenting this realization as if I thought it up in my own little brain. I didn't. But I just got it.
Technologies such as AJAX and techniques such as using portions of the screen that we know the user doesn't need at that moment and progressively disclosing information to a user on an as-needed basis can essentially remove the artificial boundaries of a display's two-dimensional space.
But Chris Anderson points out that a new abundance creates a new scarcity. User attention is the new scarcity that I now worry about. It's not about fitting text into a two-dimensional space (that's the old scarcity thinking); it's now about metering information to the user on an as-needed basis.
Forget about book metaphors--arranging and sequencing information within 'pages'-- the new user assistance metaphor is the carburetor, that device in our cars that mixes fuel and air to maximize combustion and the amount of work we get out of the engine. How can we best meter information to the user so that their performance-on-task is maximized?
Vrooom
Monday, February 26, 2007
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.
Thursday, February 22, 2007
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.
Wednesday, February 21, 2007
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 :-)
Friday, February 16, 2007
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.
Wednesday, February 14, 2007
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!)
Wednesday, February 07, 2007
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.
Tuesday, February 06, 2007
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.
Thursday, February 01, 2007
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. ;-)
Friday, January 12, 2007
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:
- The user's focus is pulled almost immediately to the radio buttons because the user is motivated to act.
- This jumping immediately to the buttons causes the user to leap-frog over the instructional text.
- 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.
Wednesday, January 10, 2007
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:
- 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.
- Two radio buttons were provided, labeled "routing" and "transparent".
- Next to each radio button was a thumbnail diagram that showed a typical typography for that mode.
- Next to each diagram was a description of when/why the user might want to select that mode.
- 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.
Tuesday, January 09, 2007
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.
Friday, January 05, 2007
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).
Monday, December 18, 2006
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.