New Column--
Please see my column in the current UXMatters. It is called The Anatomy of a Help File and discusses how user-centered Help can be developed iteratively.
Tuesday, May 22, 2007
Monday, May 21, 2007
Patterns for Interviewing SMEs--
At this year's STC conference, I attended a presentation by Larry Todd Wilson on Knowledge Harvesting. Larry is a knowledge management consultant who specializes in capturing knowledge from experts. Larry talked about patterns of interviews he would use, based on the situation he was in. One pattern that seemed appropriate for investigating software application screens that serve as status or dashboards was this one:
At this year's STC conference, I attended a presentation by Larry Todd Wilson on Knowledge Harvesting. Larry is a knowledge management consultant who specializes in capturing knowledge from experts. Larry talked about patterns of interviews he would use, based on the situation he was in. One pattern that seemed appropriate for investigating software application screens that serve as status or dashboards was this one:
- What is the intent of the screen?
- What are its primary objects (what should the user look at)?
- What are the traits or attributes of the objects?
- How do you weight the objects?
- How do you integrate this screen into your decision making?
Another pattern I have found useful for investigating screens that require the user to enter a numerical parameter is the following:
- What's a good starting value (or what influences the starting value)?
- When would you make it higher?
- When would you make it lower?
- What happens if it gets too high?
- What happens if it gets too low?
- What indicators (e.g., reports) would you look at to evaluate if your choice was too high or too low?
I think as an industry, we would be well-served if we could categorize a set number of patterns like this to help us interview SMEs. If you have any useful patterns, please send them to me and I will share them.
Friday, May 18, 2007
Breathe in, breathe out--
In my last blog I spoke about the importance of collaborative walk-throughs, and I wanted to reflect a little on what behaviors seem to make them more effective.
In a sense there are two complimentary activities that should occur in a collaborative walk-through in the early phases of a project:
In my last blog I spoke about the importance of collaborative walk-throughs, and I wanted to reflect a little on what behaviors seem to make them more effective.
In a sense there are two complimentary activities that should occur in a collaborative walk-through in the early phases of a project:
- On the one hand, you want to uncover and illuminate a diversity of approaches and opinions.
- On the other hand, you want to get convergence around a set of standards and best practices for going forward.
Opposing goals? Not at all, it's more like the breathing in and breathing out that sustains life. Both are necessary. And to ride the metaphor a little longer, just as individual stress can be managed by seeking a rhythmic balance to one's breathing, collaborative stress can be managed by trying to seek a good balance between diversity-seeking and convergence-reaching.
Diversity-seeking needs to be openly valued and encouraged. Differences need to be viewed as the natural outcomes of multiple perspectives and not as competing ideas. Phrases such as "I disagree" or "You're wrong" need to be replaced with "I did it a different way," or "I see the probelm a little differently."
Convergence-reaching is the necessary coming together around an agreed upon standard or way to do something. A good exercise during a walk-though is to conduct a claims analysis on each different approach, that is, articulate the positives and negatives of an approach. And ALL approaches have positives and negatives. Concise must be balanced against incomplete, accurate against pedantic, good for novices versus inefficient for experts, etc. Bear with the following anecdote for an illustration.
The Shark
When I was ten years old, my brother and I were swimming in the surf at Gulf Shores. There are certain events in your life that cause what I call "moments of crystal clarity." A shark's dorsal fin breaking the water (when you are a swimmer) is one of those moments. Well, that happened to us and we were doing a nightmarish run through waist-high water trying to get back to shore. With safety just yards away, we were suddenly confronted by a viscious dog on the beach. To make matters worse, the dog had only three legs, thus adding credence to the bad feeling we already had about the shark. Shark behind us, dog in front of us...and then it happened, an insight of crystal clarity: We had to find the depth of water that was too shallow for the shark and too deep for the dog. We did and we walked home safely. This summarizes for me what is the essence of design, finding the right path between the shark and the dog, and claims analysis is a good way to get there.
More reflection later, the day job calls and I can see the fins and hear the snarling already :-)
Tuesday, May 15, 2007
Team Writing--
My current project has four writers dividing up the contents for a Help file in our belief that nine women could have a baby in one month if properly managed. Our motivation is to try to get an initial Help file delivered to QA at the same time the product first goes in for testing. Just to make it more challenging, this is the pilot project for our transition to DITA and our first release out-of-the-gate since becoming part of IBM. To heck with the proverbial adage of eating an elephant one bite at a time. For some reason I thought eating an entire herd would be the way to go. We bundled new release content, new (for us) IBM styles, new authoring tools, new publishing and deployment architecture, and a new information development methodology. Just reading that sentence back to myself has been liberating; it explains the general sense of anxiety I have been feeling and the sleepless nights of late. (It also explains my lack of blogging activity of late--I've actually been working the day job!)
Whether we survive the journey (let alone be successful) aside, I'm amazed we have gotten this far and are still alive. An important element for having gotten where we are is that we have recognized and accommodated the organic aspect of a team and the value of information in context. By that I mean that a team must learn as a team and that learning must occur wrapped around tangible examples and solutions.
We started by commandeering a small conference room and declaring it to be our project's "war room." We worked in weekly iterations, setting the goals for the next week's iteration at the end of the current week. Most importantly, we set up standing war room meetings four days a week for one hour each. In these meeting we shared tool and methodology lessons learned, white-boarded architectural issues, and discussed progress toward project goals.
When we started getting to the point where we were developing content individually, we scheduled formal walk-throughs in a larger conference room. We set up a projector and each day a different writer did a show and tell of what he or she had done. We looked at the product being documented, the Help the writer had developed, and the underlying XML structures the writer had used to identify the semantic content. We added an editor to the team at this point as well.
What I have learned most of all is that even though the daily war room meetings were absolutely necessary and were very productive, we would not have converged nearly as well without the walk-throughs. I must admit that they were stressful at times, having that many peers question almost your every decision, but that is where we became aware of the many different ways a writer could look at something and see it differently. The thrashing around in the walk-throughs is where it all got sorted out. And the range of the discussions was unbelievable, at times tackling high-level architectural issues, at others dealing with the necessary style minutia that does not become apparent until four different writers tackle what is essentially the same document. The importance of an editor at this point cannot be underestimated, acting at times as researcher and historian ("This is how we've done it in the past, this is what the IBM style guide says") and as referee at times.
Had we all hunkered down and stayed in our cubes cranking out content, our project would be a literary platypus of mismatched styles and informational structures. This was an important lesson for us because our traditional approach had been more of a writer-document specialization approach. Certainly easier to manage and maintain consistency, but one that lends itself to a waterfall convergence of documentation at the end of a project, and not as useful in an iterative, early blending of product and documentation we have been trying to get to.
In the next several blogs, I will try to capture some team dynamic guidelines I have learned through all of this.
Stay posted.
My current project has four writers dividing up the contents for a Help file in our belief that nine women could have a baby in one month if properly managed. Our motivation is to try to get an initial Help file delivered to QA at the same time the product first goes in for testing. Just to make it more challenging, this is the pilot project for our transition to DITA and our first release out-of-the-gate since becoming part of IBM. To heck with the proverbial adage of eating an elephant one bite at a time. For some reason I thought eating an entire herd would be the way to go. We bundled new release content, new (for us) IBM styles, new authoring tools, new publishing and deployment architecture, and a new information development methodology. Just reading that sentence back to myself has been liberating; it explains the general sense of anxiety I have been feeling and the sleepless nights of late. (It also explains my lack of blogging activity of late--I've actually been working the day job!)
Whether we survive the journey (let alone be successful) aside, I'm amazed we have gotten this far and are still alive. An important element for having gotten where we are is that we have recognized and accommodated the organic aspect of a team and the value of information in context. By that I mean that a team must learn as a team and that learning must occur wrapped around tangible examples and solutions.
We started by commandeering a small conference room and declaring it to be our project's "war room." We worked in weekly iterations, setting the goals for the next week's iteration at the end of the current week. Most importantly, we set up standing war room meetings four days a week for one hour each. In these meeting we shared tool and methodology lessons learned, white-boarded architectural issues, and discussed progress toward project goals.
When we started getting to the point where we were developing content individually, we scheduled formal walk-throughs in a larger conference room. We set up a projector and each day a different writer did a show and tell of what he or she had done. We looked at the product being documented, the Help the writer had developed, and the underlying XML structures the writer had used to identify the semantic content. We added an editor to the team at this point as well.
What I have learned most of all is that even though the daily war room meetings were absolutely necessary and were very productive, we would not have converged nearly as well without the walk-throughs. I must admit that they were stressful at times, having that many peers question almost your every decision, but that is where we became aware of the many different ways a writer could look at something and see it differently. The thrashing around in the walk-throughs is where it all got sorted out. And the range of the discussions was unbelievable, at times tackling high-level architectural issues, at others dealing with the necessary style minutia that does not become apparent until four different writers tackle what is essentially the same document. The importance of an editor at this point cannot be underestimated, acting at times as researcher and historian ("This is how we've done it in the past, this is what the IBM style guide says") and as referee at times.
Had we all hunkered down and stayed in our cubes cranking out content, our project would be a literary platypus of mismatched styles and informational structures. This was an important lesson for us because our traditional approach had been more of a writer-document specialization approach. Certainly easier to manage and maintain consistency, but one that lends itself to a waterfall convergence of documentation at the end of a project, and not as useful in an iterative, early blending of product and documentation we have been trying to get to.
In the next several blogs, I will try to capture some team dynamic guidelines I have learned through all of this.
Stay posted.
Monday, April 16, 2007
Design for the Primary User Assistance Experience--
How do you architect a Help experience? Well, the common wisdom is to design it around the user tasks. But what does that that really mean and how do you implement such a design strategy?
Let's start by asking how a user gets to a Help topic. There are four ways:
How do you architect a Help experience? Well, the common wisdom is to design it around the user tasks. But what does that that really mean and how do you implement such a design strategy?
Let's start by asking how a user gets to a Help topic. There are four ways:
- Through a context-sensitive link on the user interface itself
- Through the Help table of contents
- Through a link from another Help topic
- Through a search/index results list
Alan Cooper, author of The Inmates Are Running the Asylum, points out that design works best when it targets a specific user. I think a similar idea for Help design is appropriate: Decide which of the four access points is your critical user experience and then optimize your design for that experience.
I think the most important user assistance experience is what happens when the user clicks the context-sensitive link. The user is on task and the Help needs to be focused and useful so that the user can get back on task as soon as possible.
The product I am working on now has page-level context-sensitive Help for every page in the application. We are designing and developing "task support clusters" around every one of those entry points. These are the critical conceptual, task, and reference topics designed specifically to support someone who has clicked on Help from a page-level Help link or button. The first topic the user gets is typically one we call a "keystone concept," a blend of what does this page do, show me an example, give me some tips--whatever seems most appropriate for someone being on that page and asking for help. Part of that keystone concept includes links to task information as well as higher level and deeper level conceptual topics. After designing and while writing the task support cluster, accommodate the other ways those topics could be accessed. Here are some implications:
- Don't put navigation and obvious UI interaction information on the keystone concept topic.
- Don't burden the users with a link farm right away that overwhelms them with new choices to make. Add value at every click; this first click should give valuable insight that the user can apply.
- Make sure that the user can link to navigational information from conceptual topics in case those topics are accessed through the TOC or other non-UI links.
- Put the appropriate task, reference, and additional conceptual links on the bottom of the keystone concept topic. When choosing how advanced or how elementary the available topics should be, assume the user was smart enough to be in the application at a fairly deep level to begin with.
The last bullet point is a key to staying parsimonious with your links. If your Help provides basic domain educational topics (for example, Firewalls 101) , collect them in their own "book" and put it in the TOC. That way, you can link to the book from a task support cluster and not provide a lot of distracting links and unnecessary navigation within the Help file for someone who is on task.
Finally, let the TOC emerge from an analysis of the content this task support approach creates.
Friday, April 06, 2007
Iterative Design and Big Boxes--
A couple of decades ago, at the early part of my technical communication career, I developed and delivered installation and maintenance training for industrial equipment (specifically, hot melt glue machinery that went on packaging lines) . Part of my job included setting up equipment for lab exercises, which required plumbing hydraulic and pneumatic lines and solenoids and such. My technical background is in electronics, so this hydraulic and pneumatic plumbing aspect was a challenge for me. Basically I had a small box of fittings and connections, and if I needed to get part A plumbed to part B, I found a fitting that went on part A and kept going into my box finding and connecting fittings until I had a jerry-rigged arrangement that ended with a fitting that matched part B. It worked.
I then had an opportunity to visit a Procter and Gamble plant in Lima, Ohio, where they were completely refitting a production line. I was thrilled; I was going to get to see how a by-gawd union pipe-fitter for a major packaging plant did it. I showed up; the union pipe fitter showed up; she had a BIG box of fittings that she kept digging into until she had an arrangement that fit on part A on one end and part B on the other. My reaction was, "Well I'll be damned!"
I moved on, away from hydraulics and pneumatics and into the more rational word of software applications. I was committed to the belief that thorough planning and design could create efficiently producible documentation that was user-friendly. Twenty years later I am a user assistance architect with a PhD working for IBM. What does that mean? I now have a BIG box of tools and patterns that I fish around in, but basically I still get from A to B by looking for what fits and doing a lot of trial and error.
But at last I think I get it: That's the way design happens!
I now give myself shorter planning windows and plan on doing frequent iterations to get it right. I fiddle less with planning tools and more with wireframing and rapid prototyping tools. My mantra is learn fast, fail early. Get something that you can play with, interact with, and show others as soon as possible.
This is not a natural behavior for technical communicators; we have this notion that things we develop should be accurate and complete (and even look good). Well, eventually, they should be, but not at first. To do collaborative, iterative design, we must create cultures where we show first drafts and half-baked ideas to others and not worry that we will be judged by their flaws and inadequacies. We must be willing to let others share their early drafts with us and not judge them for their lack of quality that can come only with polishing. There is little time for polishing at the early stage of design, and besides, you'd be polishing a lot of stuff that eventually gets thrown away.
Don't stop analyzing and planning, just recognize that the real creative breakthroughs come from building and kicking what you've built. The earlier you can do that and the more iterations you can take it through, the better the final design will be.
A couple of decades ago, at the early part of my technical communication career, I developed and delivered installation and maintenance training for industrial equipment (specifically, hot melt glue machinery that went on packaging lines) . Part of my job included setting up equipment for lab exercises, which required plumbing hydraulic and pneumatic lines and solenoids and such. My technical background is in electronics, so this hydraulic and pneumatic plumbing aspect was a challenge for me. Basically I had a small box of fittings and connections, and if I needed to get part A plumbed to part B, I found a fitting that went on part A and kept going into my box finding and connecting fittings until I had a jerry-rigged arrangement that ended with a fitting that matched part B. It worked.
I then had an opportunity to visit a Procter and Gamble plant in Lima, Ohio, where they were completely refitting a production line. I was thrilled; I was going to get to see how a by-gawd union pipe-fitter for a major packaging plant did it. I showed up; the union pipe fitter showed up; she had a BIG box of fittings that she kept digging into until she had an arrangement that fit on part A on one end and part B on the other. My reaction was, "Well I'll be damned!"
I moved on, away from hydraulics and pneumatics and into the more rational word of software applications. I was committed to the belief that thorough planning and design could create efficiently producible documentation that was user-friendly. Twenty years later I am a user assistance architect with a PhD working for IBM. What does that mean? I now have a BIG box of tools and patterns that I fish around in, but basically I still get from A to B by looking for what fits and doing a lot of trial and error.
But at last I think I get it: That's the way design happens!
I now give myself shorter planning windows and plan on doing frequent iterations to get it right. I fiddle less with planning tools and more with wireframing and rapid prototyping tools. My mantra is learn fast, fail early. Get something that you can play with, interact with, and show others as soon as possible.
This is not a natural behavior for technical communicators; we have this notion that things we develop should be accurate and complete (and even look good). Well, eventually, they should be, but not at first. To do collaborative, iterative design, we must create cultures where we show first drafts and half-baked ideas to others and not worry that we will be judged by their flaws and inadequacies. We must be willing to let others share their early drafts with us and not judge them for their lack of quality that can come only with polishing. There is little time for polishing at the early stage of design, and besides, you'd be polishing a lot of stuff that eventually gets thrown away.
Don't stop analyzing and planning, just recognize that the real creative breakthroughs come from building and kicking what you've built. The earlier you can do that and the more iterations you can take it through, the better the final design will be.
Friday, March 30, 2007
Tuesday, March 20, 2007
Chinking--
I've created a new term, chinking, to mean:
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
Is It Help or Is It a Pop Quiz?--
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
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
Atlanta Currents a Big Energizer for Me--
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.
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
Column Debut--
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.
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
Chris Anderson and I were having lunch this week...
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
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
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.
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
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.
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
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 :-)
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 :-)
Monday, February 19, 2007
Friday, February 16, 2007
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.
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
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!)
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
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.
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
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.
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.
Subscribe to:
Posts (Atom)