Comic Relief

As part of a project I'm working on, we are going to develop a comic-style collection of user scenarios to help communicate best practices around a security service we are offering. This is just experimental at this stage, mainly doing a concept piece to see 1) will is work and 2) will stakeholders buy into it. The model I am using is Google's Chrome's Googlebook for web app developers.

There can be a number of advantages to using a comic-style treatment:

• Overcome traditional disinterest in "User Guides"
• Allow a friendlier, instructive tone
• Use line illustrations of screen areas to focus user attention on critical details
• Use "illogical" shifts, such as going from a "white board" type overview to the narrator standing in front of a large UI pointing to an area of interest
• More easily translated than screen cam tutorials
• Can be randomly accessed for review purposes (something hard to do with video-based training)

The coolest part, though, is this gives me a legitimate reason to be playing with comic styles while at work and on the clock. How cool is that? Actually, I have a real by-gawd graphic designer assigned to the team, but I need to get more familiar with the genre...yeah, that's the ticket; I'm doing comics at work to get more familiar with the genre. Actually, my next column in UXmatters does deal with how I use comics in an internal Wiki-based status report.

So for a while, Fridays will be "Comic Day" in this blog. Just trying to get immersed in the genre--all work and profession related. I'll try hard not to enjoy myself :-)

Veterans Day

I am sitting in my cube in my "Army Strong" baseball cap and my khaki green fatigue-style jacket with my sergeant pins on my lapels. I was a patriotic draft-dodger of the late sixties: Low draft number so I enlisted and became an Arabic linguist for the Army Security Agency. It got me to Ethiopia and out of Viet Nam.

Actually, my tour was fun--more like a PG-13 Hunter Thompson episode--so I take the opportunity today to thank those who have truly served and who are serving by going into harm's way.

Thanks

\:-| (lame emoticon of a salute)

Energy in; energy out

OK, be prepared for Dante's 6th inner ring of metaphor Hell.

I broke down and took a by-gawd Dobro lesson this week. I figure it's time to get serious about my music so I paid this guy $100 for a three-hour Vulcan mind-meld of Musical Theory 101. Never touched my guitar. (He got interrupted, though, so I did get to play his $5000 Dobro for about 20 minutes while he handled a domestic emergency.)

So I go home with his two-sided yellow legal page on which he had scribbled the sacred code that explained the chromatic scale, all of the keys, and the how to construct every major, minor, and dominant chord. I was overwhelmed and stunned. Had I just gotten the deal of a lifetime or did I just flush five Andrew Jacksons down the toilet?

The next day I pick up my Dobro and start experimenting with the different patterns of the chromatic scale notes on the fretboard and playing around with the chord construction schemes he had taught me. It got interesting when I started playing around with a G9, one of the dominants. It was a different sound and I started putting a bit of a riff around it and pretty soon was playing a jaunty little latin-sounding thing I ended up calling "Tijuana Roller Coaster" because it had an unbalanced feel caused by the G9 and then resolved nicely to a slide up into the 1st inversion of the root chord (C) with a pause and then a final C note on the bass-most string.

OK, a little of that intro is just me showing off the new stuff I learned--but heck, I paid a hundred bucks to be able to write that paragraph, and it's my blog so humor me.

But it reminded me of the importance of grounding the energy out of a system. I used to be an electronics technician, and one of the electrical components we dealt with was the capacitor. A capacitor stores energy, and after you take one out of a circuit it can still give you a bit of a shock if you don't short the two terminals and get rid of the charge. If it has a big charge stored, you might have to do that a couple of times.

I've noticed that a lot of music does a similar thing. Notice how many symphonies end with a big chord that the orchestra repeats a couple of times? Ta Dah!.. dah...dah. Well, it's like the symphony has the musicians and the audience all worked up and the composer is trying to ground them at the end. Leave them someplace comfortable. And as much as I hate the practice of rock musicians trashing their instruments and amps at the end of a performance, I understand that they are trying to ground all of that energy so the performance leaves them and the audience back at sea level and not soaring up in the clouds.

So my slide to the root chord was to ground the listener, get him or her back to a safe place. But a 1st inversion chord is still a tad unsettling. A root chord is like having three singers harmonizing with the notes do, mi, sol, respectively. The first inversion would have them sing mi, sol, do with do being sung as the highest note. Still safe and stable, just a wee bit top heavy because the root note is on top instead of at the bottom. So that's why I throw in the root C on the bass-most string at the end, sort of like the second touching of the capacitor to fully discharge the energy. It kind of simulates what happens when a roller coaster stops; it leaves you leaning slightly forward in your seat from your forward momentum for a second, and then you settle back comfortably into the seat. Ta dah! ...dah.

Working with teams has a similar requirement, every now and then you have to ground the energy and bring everybody back into a safe comfort zone. Steven Wright has the line, "You know how you feel when you're leaning back in a chair and then you start to tip backwards? I feel that way all the time." Team work involves a lot of energy as new questions disrupt old, comfortable theories, agendas collide, etc. Periodically you need to ground the team--nobody wants to feel like they're tipping backwards in the chair all the time.

So how do you ground team energy?

In music we emphasize root chords and root notes. Playing in the key of C? End on C, E, G. Safe, predictable, comfortable. Working on a team? Get back to basic assumptions around which the team members can feel safe and comfortable. Weekly summaries are great grounders. Here's what we did this week and what we learned. Chronological descriptions of what happened or what happens are great grounders. Can we all agree that we saw A happen and then B? This is one of the reasons usability tests are great team builders, the team has equal access to the same data: what they saw the users do. As a test facilitator, when teams would start getting edgy over a point and I wanted to ground them, I would get consensus on the sequence of events. "Did the user click Add first or did he type the variable name first?" Direct observations are a safe common ground around which a team can safely discuss and agree on basics.

Other grounders are getting team members to agree again on the high level goals of the project or restating the criteria by which we accept or reject design decisions. C, E, G.

But... There is always a big but...sometimes you need to put energy into the team. The whole reason I like Tijuana Roller Coaster is that it starts on a G9, the musical equivalent to leaning back in your chair right at the tipping point. You energize a team by pulling them out of their safe, comfortable places. As you could well imagine, there are good ways to do this and bad.

When dealing with conflicts (the ultimate energizers), avoid dis-chord, i.e., out and out wrong notes being put together. Emphasize constructive tension. (A G9 introduces constructive tension into a song in the key of C.) Look at the differences in these statements in terms of dis-chord vs constructive tension:

• You're wrong.
• I disagree with you.
• I have a different perspective.

The last one is the rhetorical equivalent to a G9. It gets the tune going and you sure can't leave it there, but it's a pleasant enough tension. The first statement is fingernails on a chalk board.

Enough. The point I wanted to explore is the creative management of energy, when to infuse it and when to dissipate it. I can't wait to see what my next Dobro lesson brings.

Talk Your Walk

I know the title of today's blog seems backwards, but that's the point I want to make. It is not at all unusual to find situations where a person says one thing and does another. In Action Science, that is called a gap between a person's stated beliefs and their theories in use. In common practice we say that someone isn't "walking the talk" with the implication that the problem is in the walk.

Sometimes that's true, but often the reverse could be true, we're walking a particular walk because it works for us and it is the talk that is out of place. Action Science recognizes that and spends as much energy trying to align the message with the reality as it does on adjusting the practice to the preaching.

For example, if you ask writers how to write, they often say, "I start by making an outline." I taught technical writing and I often said "I start by making an outline." Most writers don't actually do that and if you corner them they will say things like, "I really should but..." Maybe, but the alternative is to just quit saying "I start by making an outline." In my case, for instance, I often just start writing. That's my way of exploring the content space. My friend and mentor, Carol Barnum, often says "Writing is thinking." So I start by writing, which gets me thinking about content, theme, and sequence. Interestingly, when I'm about a third of the way into an article, I turn on Outline view in Word and view only headings 1, 2, and 3. It lets me see where the flow is wrong or the appropriate ideas are not getting grouped.

I'm not saying that's the right way to write, but I have been successful with it so I need to quit telling people "I start by making an outline." I need to say, "I just dive in initially as a way of dumping what I already know and getting a feel for the content."

We confuse people when there is a disconnect between our stated beliefs and our theories in use. When managers say they demand teamwork but evaluate employees based on individual accomplishments, they do a disservice to the person who puts the team's overall needs ahead of his or her specific goals. That person gets punished for believing what the boss said and acting on it. The same applies to spouses, kids, friends, and all.

But don't be so quick to blame the disconnect on your behavior--It could be you are reciting scripts that describe what you think you should do. Actions speak loudly, and we are getting something that works for us from our behaviors or else we would have abandoned them (compulsive behavior aside).

So there is absolutely nothing wrong with the following talk:

• I start writing by just letting the firing of every synapse go to my fingers and then I organize and clean it up later.
• Although I value teamwork, I will evaluate each employee on his or her individual achievements first. It's my job as manager to make sure that your individual goals add up to a team achievement.
• We are not all equal here, I am more mindful of engineers' time than writers' time. That's just the reality of it.
• I'm going to ask if these jeans look good on me because I'm feeling fat, but I'm just fishing for some positive stroking.

It's kind of like using turn signals when you drive. It's easier for others to avoid hitting you if you share where you're going.

Moron Holes

My buddy, Miranda, is a gamer, and she showed me a new one that allows the participant to shoot a hole into a wall that sort of bypasses normal space and time limits and lets the player emerge, for example, on the the other side of an otherwise uncrossable chasm. Cool.

I think a similar device explains how some people can jump from assumption A to a logically inaccessible conclusion B--they're traveling through moron holes.

Classical logicians were unfamiliar with quantum concepts such as wormholes, so they had to explain such leaps from A to B with phrases such as non-sequitor or post hoc ergo propter hoc, without any explanation about how the speaker had accomplished such a feat.

No longer. We now have a scientific explanation: The speaker fell through a moron hole.

So at your next meeting when the project manager suggests that the doc can be ready on the same day coding the UI is done, you can glibly reply, "What moron hole did you fall through?"

Uh, bring cookies to the status meeting.

Screen Shots in Documentation

Sometimes someone gives me documentation that "so and so" put together for his IT group that tells them how to install our product. Generally, the purpose is to show me how "real users" want to see documentation. Invariably it is a 32-step procedure with a screen shot in every step.

Well, obviously, the writer in not familiar with Robert Horn or the demands for accessibility and globalization that I must deal with, so I have dismissed it.

But it just keeps coming back, so I'm going to ask myself, "What if they're right?"

First, so I can be more open to new thinking, let me purge myself of all the reasons I have traditionally rejected screen shots in documentation:

1. Every time the UI gets modified, screen shots must get updated.
2. Every time the UI gets translated, new screen shots must be generated in the new language and coordinated into the translated text.
3. Information in the screen shot (like button selection or entries) must be documented in the steps anyway so the information can be rendered by adaptive technologies like screen readers.
4. Many screen shots just show the reader what the user is already seeing.
5. Users may be overly attracted to the visual and miss important points in the explanatory text.
6. It makes the document bigger.

Now let me changes hats a bit a take a critical look at my traditional positions.

Objection 1 (updating screen shots) seems writer-centric. Essentially it is saying "It makes my job harder." Well if it does make the user's job easier, it would make sense that it makes my job harder--nothing's free. OK, Objection 1 is bad.

Objection 2 (translation) is just an instantiation of Objection 1. Therefore, Objection 2 is bad.

Hmmmm, I don't like how this is going so far :-(

Objection 3 (information still has to exist in words) has some substance. Information in a screen shot cannot be used to substitute for information in the steps. Unless of course, you're not worried about accessibility. Now that's an entirely different blog!

Objection 4 (what good is a picture of what the user can clearly see) has always resonated with me. Here is an example:

This example is particularly problematic for me since the UI text is actually pretty explanatory.

It also can get fairly tedious. consider the next steps that follow the example above:


But it seems that this by-the-numbers, picture-by-picture aspect is the attraction for this type of documentation. As in "So easy a..." well you get the picture.


So am I hearing from users who want this type of documentation, or am I hearing from technicians who think users need this level of hand-holding?


Objection 5 (visually distracts from useful text) has merit. Although it's true that a picture is worth a thousand words, it did take seven words to express that concept, and I'm not sure how you would get that across as well in a picture. Also, I think it is easier to wrap context around an example if the example is in words. For example, in the following shot, is the value 10240 an example or is it the value the user should enter?


And in the next example, the screen shot visually contradicts the step.


Objection 6 (document size) should be evaluated based on the merit of the document. If the screen shots make the document better, no one will care about bigger.

So where does this leave me?

I am going to be more open to including screen shots where they do the following:

• Help reassure the user that where they are in the UI is the right place to be
• Help call attention to a specific area of a complex UI
• Support an example that is hard to visualize otherwise, e.g., setting up a desktop configuration
  

So where they add value, I'll be more willing to tackle those aspects that make my job harder (e.g., documentation maintenance). But just as I would with words, I'll cut out the obvious and whatever does not add value. I prefer an additive approach (put it in only when the words seem inadequate) over a subtractive approach (take it out if it seems superfluous). In other words, I'll be more open to screen shots in the future, but they have to work themselves into the document, not just be their by entitlement until expelled.

State of the Ark (part 2)

As I said in an earlier blog, "state of the ark" is my phrase for when I think I am on the leading edge of technology when in fact I'm back among the late majority or laggards.

One of the problems with playing a Dobro all by yourself is that the instrument is really suited to provide accents and solo snippets. But I'd look a bit stupid standing in my den tapping my foot doing nothing then occasionally playing a "twinky twang."

So I thought I should get some bluegrass CDs so I could get used to playing in the context of a band. If you need a visualization, see this classic Andy Kaufmann bit from SNL.

I decided to go to Amazon.com to look at what was available. I thought to myself, "Wouldn't it be cool if when you bought albums online, you could actually hear bits of each track?" What a great, innovative idea. I could get RICH!!!!!


So, how long has Amazon been doing that, and why haven't I taken advantage of it before?

We probably don't think of music clips as user assistance, but this feature helped me make an informed choice (Patty Loveless, Mountain Soul II), and that's the ultimate goal of UA.

Job well done, Amazon.