Reply versus Reply All

My e-mail inbox is cluttered by something other than SPAM. I am on a number of committees and list servers where I must wade through large amounts of chatter that does not add value, but takes up my time and effort to get rid of. Last week I accidentally deleted an important meeting invitation because I inadvertently deleted it along with this category of junk mail.

Here's what I'm talking about. I got an e-mail reminding me that there is a board meeting this Friday that goes out to all of the board members. That's good. The e-mail asks attendees to verify if they are going to have lunch so that the organizer knows how much food to order. Now starts the litany of emails from individuals saying "I'll have lunch." I get these because the responders click "Reply All" instead of "Reply." (This is just one example of a phenomenon I experience several times a week if not daily.)

STOP IT!

"Reply All" sends your answer to everyone on the original email. Use "Reply All" when your answer applies to everyone, or you want to open up your response to the public scrutiny of the group you are participating in. Who am I to give feedback on who should be eating lunch?

"Reply" sends your answer just to the person who sent you the email. In the example above, only the sender needs to know if you will show up hungry.

And list servers have a sneakier version of the same problem. "Reply" sends the answer to the list server list (EVERYBODY), not the person who wrote the post. That is because the e-mail did not really come to you from the individual; it came from the list server.

I'm sorry for the cranky post.

New Column

I have a new column out in UXmatters today called Placing Value on User Assistance. It's a topic I have blogged on before, but the column has a nice shiny picture as my colleague Mark Wallis would say. Speaking of Mark and pictures, right after WritersUA, Mark let me be his gear monkey while he took nature shots around and up Mt. Hood outside of Portland. Awesome! We went from mossy rain forests to 25 feet of snow in less than an hour.

WritersUA was great. The presentations were their usual high caliber, the vendors just chock full of new features, and the networking as valuable and enjoyable as ever.

Great Currents Conference

I went to the Atlanta STC regional conference, Currents, this Saturday. As always, it was a great professional motivator and a chance to chat with some of our leading technical communicators. And Jean-Luc's final slide was right, I will never be able to look at a road sign the same way ever again. Yesterday on my way to the airport, I saw one of Jean-Luc's favorites:

State Law
STOP
Yield to pedestrian in crosswalk

Jean-Luc's point is that it is strange that we need to be told to do this, as if we would have hit them otherwise, and that we must be told it's the law (as opposed to a guideline, I guess.) Jean-Luc forgets that we are the culture that created the video game Death Race 2000 where you get points for hitting pedestrians.

The reason I was going to the airport is that I am in Portland, Oregon, this week for the WritersUA conference. First Currents and now WritersUA! I'll try to post on the conference this week.

One more thing, on the Portland light rail, nobody checks to see if you bought a ticket. It's the honor system. Kind of a nice contrast to "No running over pedestrians or else we'll give you a ticket."

Instructional Text on the UI

Embedded assistance makes us reevaluate some tried and true principles of information design because our instructions occur within an action-packed medium--an application's user interface. If you think you have trouble holding a student's attention in the classroom, try teaching in a video-arcade. In many ways, embedded assistance has the same challenge.

Having said that, I'm going to shoot you over to a column I wrote a year ago for UXmatters called Instructional Text in the User Interface: Some Counterintuitive Implications of User Behaviors .

News

• Check out Martha Stevens new blog on user assistance. Martha's voice and insights will be a good addition to the blogosphere.
• Currents (Atlanta STC regional conference) starts in a few days. Shout out to my buddy, Miranda Bennett, who will be doing an interesting presentation on collaborative walkthroughs.
• And with the start of daylight savings time, I'm back on my routine of going fishing every Wednesday afternoon after work. Actually, I sit in my kayak on Stone Mountain lake, drink two beers, and smoke a cigar while pretending to fish. I have come to the very serious realization that life balance is important; do you have something you make time for every week that is just for you? (Tip: Scheduling something for mid-week is a great way to break up the work week.)
• Voting for STC officers starts next week. If you are an STC member, vote early; if you're voting for me, vote often.

MOO POPs

I want to discuss MOO POPs early in this series of blogs on embedded assistance (EA) because the concept drives straight to the heart of EA: When and where do we need it?

MOO POP stands for "Moment of Opportunity" and "Point of Pain." A moment of opportunity refers to a state in the user interface when we can intervene and move the user to increase his or her adoption of the product. I wrote an article for the Cutter IT Journal last year about progressive user adoption that talks about the ability of embedded assistance to increase user adoption of advanced features based on detecting user readiness for that advanced feature. For example, a useful feature in Microsoft Word is its ability to automate header content using heading tags in the document, such as making the current Heading 2 the header entry. When would you point that out to the user? If someone is in the act of defining a header, that could be the appropriate moment of opportunity. Imagine a link on the header dialog box that said "Tell me how to automate my headers" and which launched a popup that explained how to do that.

A point of pain is where we anticipate that the user might run into trouble. For example, if we provide a field for entering the name of a firewall rule the user is creating, and the developer points out that the database cannot accept spaces in the name, we can reasonably anticipate that some users will screw up. A simple statement next to the field that says merely "No spaces" will save innumerable instances of error messages popping up. In general, the following situations are good candidates to be points of pain:

• When choices or actions are grayed out (Hey! why can't I do this?)
• When we ask users to make decisions (Did you want DES, 3DES, or AES encryption?--say what!)
• When business or validation rules will lead to likely error conditions

So one of the first lessons in doing embedded assistance is that you do not have to be consistent, and by that I mean you don't have to treat all fields equally. The field that asks the user to type her first name does not need embedded assistance; the field that asks her to create a new password probably does (as in what are the rules for a valid password).

The guiding principle should be "Is there a moment of opportunity or point of pain that justifies taking up room on the user interface?"

In my next blog, I will talk about how to maximize effectiveness and minimize the intrusiveness of the EA entries on the user interface.

Embedded Assistance

I'm working these days on some very exciting projects involving embedded assistance. Embedded assistance (EA) is user assistance that is incorporated directly into the user interface, specifically, assistance that does not require the user to go into a Help file or document. Although most people think of embedded Help panes that exist along the right or left side of the application screen when you say embedded assistance, that is just one aspect of EA--and quite frankly, one of the less important elements. Embedded assistance incorporates any text or communication within the user interface that informs or instructs the user:

• Field labels
• Inline instructional text
• Error or information messages
• Button labels
• On-screen examples
• Hover text
• Tool tips

And beyond this obvious list of element where words are involved, I also include other design considerations such as grouping and sequencing of fields on the UI.

I'd like to give a shout-out to Fred Sampson, a colleague of mine within IBM, for the leadership he has shown in taking me down this path. In the next series of blogs, I will be relating research and guidelines Fred has helped assemble along with tips and how to's from my own experiences helping my division move in this direction.

Why embedded assistance?

Today's blog focuses on why user assistance writers should shift their focus from traditional Help and concentrate more on embedded assistance.

1. Users don't go to Help.
2. Embedded assistance keeps users in their task flow.
3. OK, some users eventually go to Help, but then it isn't helpful.

Users don't go to Help

In most corporate cultures there is somewhat of a dichotomy between working and learning. By that I mean we think of the two as being different activities. We say things like "I won't be at work next week because I'm going to the WritersUA conference." Or when an inhouse training session comes to an end, someone invariably says, "Time to get back to work."

Users see going into Help as being an interruption to work. I used to complain about users who were "too lazy to read the manual" until I started doing usability testing. I then realized that the users were working very hard to get the task done, and they were not going to Help for that very reason, they were focused on the task and that is where they felt they should stay.

Staying in the task flow

The best place to put user assistance is in the UI where and when the need occurs. I like to talk about MOO POPs--no, not milk-based Popsicles, moments of opportunity and points of pain. Understanding where the MOO POPs are in your application is a critical aspect of designing good EA. I will blog on that later.

Why Help is anything but

When I watch users doing a task and then watch when they eventually go into Help, more times than not the Help is not helpful. It's not the writer's fault. See my UXmatters column Stepped Procedures: The Sacred Cow Blocking the Road for an explanation of why there is often a mismatch between the user's question and Help's answers.

Upcoming blogs

Tune in for the next few blogs as I go deeper into the following:

• MOO POPs
• Progressive disclosure (an essential technique for EA)
• How to sell the developers on letting us into the UI