Tag: user assistance

I’ve been reading Ginny Redish’s book, Letting Go of the Words: Writing Web Content That Works. It was a bit slow at first because the early material is pretty basic. And I came into it with the preconception that it wouldn’t apply much to documentation, since we write help systems and manuals.

In light of our team’s search for the tool that best meets a set of specific requirements, I’ve decided that Redish’s book has everything to do with what I do—or what I should be doing.

My Beef with Tri-pane Help

If you’ve been reading this blog for a while, it’s no secret to you that I’m not a big fan of tri-pane help. I think it’s dated and is associated in people’s minds with unhelpfulness.

But in our search for a tool that will give us a more robust Web output, I’ve discovered the main reason I don’t like tri-pane help.

› Continue reading…

Tags: , , , , , , ,

A Built-in Method of Delivering User Assistance

I have a crackpot idea for presenting user assistance in software or on websites. Okay, maybe it’s not so far out there, but I haven’t seen this done anywhere that I can recall.

Like a lot of ideas, I was probably thinking about something else when this occurred to me. But I’ve got this picture of a div that slides or pops out in the interface when the user wants to see it to get more information. This pane could appear to one side or the bottom of the main section of the page.

Here are a couple of mockups. These are not to scale.

Help opening at the side
Help appearing to one side

Help opening at the bottom
Help appearing at the bottom

The advantages of this approach is that the user doesn’t have to see help unless he or she wants to, and it’s right there in the same window, not covering up anything, so you don’t have to switch back and forth between windows.

Disadvantages are the limited real estate for content and the amount that this may cut into the site or application’s usable space.

One of the main things I like about an approach like this is that I believe user assistance ought to be designed into the interface. It shouldn’t be something added at the last minute like you were deciding what hat to wear today before leaving the house. It’s part of the user experience, so it should be part of the user experience design—with input from the technical communicator, of course.

What do you think? Have you seen this kind of approach anywhere?

Tags: , , , , , ,

Undiscovered Instructions Aren't Much Good

It’s funny when those little everyday experiences make you think about your job in a little different light.

I took the week off for the Thanksgiving holiday. My wife and I were doing some much-needed shopping in a mall at the beginning of the week and stopped at the food court for lunch. When I tried to open a ketchup packet by tearing off the corner, I made a small mess (didn’t get any on my clothes, fortunately).

Giving me a bit of a ribbing because of my profession, my wife said, “You didn’t follow the instructions!” and pointed to where the opposite corner had the dotted line and the words “Open here.”

“I didn’t see the instructions,” I replied.

› Continue reading…

Tags: , , ,

While filing my income tax return online, I noticed that the primary way the website offered user assistance was through questions worded in first person. Each screen provided four to six questions that had to do with that particular screen. This caught my attention partly because I had just been thinking about empathetic user assistance. When I clicked a question, the corresponding information opened in a small pop-up window in the center of my screen.

I’ve wondered how different my job would be if we offered user assistance this way. I like to design some of the user interaction myself, whereas in projects like this tax site I used, it seems like the Web designer took care of that part, and all the technical writer (assuming there was one) did was supply questions and answers to be plugged in.

› Continue reading…

Tags: , , ,
Back to top