Accessibility: Some honest talk

Sometimes I like to use my blog to wrestle outwardly with conflicts I am having so that others can weigh in with their perspectives. This one can get a little edgy, so let's all stay on our good behavior.

Is it just me or can accessibility be a big pain in the ass at times? As Andy Rooney once said about an entirely different subject "I am violently ambivalent" about this. By that I mean I can passionately argue two opposing perspectives, mainly because I have two opposing perspectives.

The side of me I like holds the position that accessibility is good and anything we do to make our products more accessible makes our products better.

The part of me I'm a little nervous about exposing wants to offer a lot of rich Internet interactions and resents the constraints that accessibility requirements put on that.

These opposing poles can be summarized by what I call the accessibility paradox:
I don't need to be accessible because my clients aren't physically challenged--but none of my client base is physically challenged because my product's lack of accessibility won't let physically challenged persons become my clients.

These debates make great barroom entertainment and inspiring conference presentations, but right now I have some very real design decisions to make. Anyone who has both design and accessibility responsibilities knows the frustration of using AJAX. Anything dynamic on a screen starts to cause problems for adaptive technology devices.


I'm not going to pick on Jaws because it is a good product, but I will use them as an example. Instead of making me constrain my design so that Jaws can handle it, why not beat Jaws up until it can handle these modern types of interactions? Instead of regulating me, regulate them!

OK, it felt good to whine, so let's get practical for a minute.

As a designer I have to strike that balance between rich interactions that enhance the user experience for my majority base, namely folks who can see the screen and manipulate a mouse. I also need to make the content and functionality available to those who can't. Companies, in general, get a little bipolar on this. Marketing wants to say the products are accessible; they also want rich interaction; and they want a lot of new features. How's the classic punch line go? "Pick any two."

I read an accessibility tip yesterday that said to summarize the key points of a graphic in its caption. I work with dashboards where the graphs are dynamically generated in real time with the latest available data. How am I going to do that? You caption a sparkline that contains 30 days of trend data or a tree map that is summarizing hundreds of data points--and generate that caption dynamically.

And yes, I know the classic solution to the problem is linking to the source data  from a longdesc attribute in the image tag. That's work, that's time, that's less features we will be able to build for the release. (BTW, I elaborate on this in the Comment section.)

I'm not saying we shouldn't do it; I just wish the conversation about accessibility would be more frank when it comes to the opportunity costs and real costs to implement it.

And I'm embarrassed by my own petty frustration in having to accommodate someone who has a real beef with the world and a legitimate cause for frustration.

Happy pi Day

I love pi! It's Greek; it's irrational; it's a number that eschews exactitude and demands rounding.

What exactly is it? Take a piece of string and tie a loop in both ends. Pin one end in the center of piece of paper and put a pencil in the other. Now, with the string stretched tight, move the pencil around the pin until it inscribes a circle. Now lay another string around the circumference of the circle you just drew. Cut off any extra. Fold it in half and cut it. Lay one of the halves next to the first string. The second string is pi times as long as the first.

Here's the cool part: Even though you have obviously created a physical ratio (second string to first) there are no numbers that can express that ratio. Really pissed off the Pythagoreans ;-)

Enjoy pi today.

If I only had an *

My favorite quote from the Wizard of Oz:

Why, anybody can have a brain. That's a very mediocre commodity. Every pusillanimous creature that crawls on the Earth or slinks through slimy seas has a brain. Back where I come from, we have universities, seats of great learning, where men go to become great thinkers. And when they come out, they think deep thoughts and with no more brains than you have. But they have one thing you haven't got: a diploma.

I'm designing a new user experience for submitting technical support requests. The support folks said customers aren't giving them enough information and they specified what fields they wanted to be required. So I mocked up a form and put "*" in front of the required fields. Then I cross referenced it against the existing form and found mine was pretty much the same--except for the asterisks.

Pretty powerful thing, an asterisk, apparently it can make our users smarter.

When did I become "that guy?"

Five months ago I was in the camp of "All I need my cell phone to do is make and take calls." Then I realized that sooner or later I was going to need to design user experiences for smart phones and that I had no direct experience as a user. So I cowboyed up and bought an iPhone.

Fast forward to yesterday. I got a call from our customer loyalty manager late in the afternoon (on my iPhone). We are doing a big customer hoo-hah thing today and we were out of Post-it flip charts. (Who you gonna call? Apparently the UX guy!)

So I go down to the conference room to see what they need. They showed me what they had and suggested I write down the part number and description. "Not necessary," I said. I took out my iPhone and opened my RedLaser app. I scanned the bar code and got a description and the pricing for all the local office supply stores. I put the address of the closest Office Depot in my Google Map app and used my iPhone's GPS to get there.

When did I become "that guy?" Five months ago I'm all about "I don't need no stinkin' camera in my cell phone," and yesterday I'm laser scanning bar codes with it.

Lesson for UX: Discount NO technology. The adoption rate happens in dog years, if not faster.

Hughes' Law of Non-linear UX Time

I've always wanted my own law. Here it is:

t=log_(UX) 

User experience time is logarithmic. The user's first 30 seconds on an application or web page is as important as the next 30 minutes. And that 30 minutes is as important as the next 3 hours.

Loren Burke, my usability mentor, created an entire business fixing the first 30 minutes of products that were about to be launched or which were already in trouble.

I am reminded of this as I am working on dashboards right now. Manage the first 30 seconds, then the first 30 minutes.

The next question then is whether to move on to the next 3 hours or to find another 30 second/30 minute problem to solve.

The Spherical User

Just read a great joke--OK, a joke I liked at any rate.

"A dairy farmer, in a fit of desperation because his cows aren't giving enough milk, consults a theoretical physicist about the problem. The physicist listens to him, asks a few questions, and then says he'll take the assignment. A few weeks later, he calls up the farmer, and says 'I've got the answer.'

'Tell me,' pleads the excited farmer.

The physicist starts his answer by saying, 'First, we assume a spherical cow...'"

Physicists often have to construct clean, clear-cut laws to describe messy realities. They do this by cleaning up their concepts about reality, assuming frictionless surfaces, loss-less mirrors, and yes, lots of spherical objects.

UX and UI designers sometimes do the same thing, assuming a spherical user who knows what he wants to do, will not make errors in doing so, and will do it in an environment that supports his objective, his timing, and everything else idiosyncratic about him.

Anything outside of those design boundaries we term "edge cases." The result is often a design that works great when it works and that really sucks when it doesn't.

I admit that I laughed at the cow joke, but it was a nervous, could-this-be-me laugh. Maybe because in my Agile zeal, I try to avoid over-thinking the solution at the front end. My scenarios are happy paths that lead to success.

But I'm going to stop and pause more and ask myself, "How can someone do this wrong?" Anyone have any experience or ideas on how to implement that step systematically in an Agile model?

The Degentrification of User Assistance

A theme I have watched for awhile has finally caught up to me. There has been a steady movement away from using professional technical writers to produce user assistance and, instead, let subject matter experts do it directly.

Some examples:

• Wikipedia (I use it all the time to understand security concepts my products naturally assume I already know.)
• Product-sponsored social networks that let users pose questions to product experts or other users
• Open social networks where users pose questions for other users in the audience, e.g., Twitter and Linkedin

I am working on a project now to revamp an Internet portal for managed security services. There is a  requirement in the project to provide contextual help at the page level. But there are no technical writers. To date, there has been no formal approach to user assistance, and this particular portal offers a varied set of documents available to users. There are PDF mini-papers, PDF user guides, HTML help for some pages, Knowledge Base Articles that are available to the public, and video tutorials and best practices documents provided by a training group.

And there was a strong sentiment among the project stakeholders to have SMEs write the content directly without having to require engineering intervention to post new topics or edits to existing topics.

As someone who still feels he is a technical writer at heart, my initial reaction was mixed. On one page our current online explanation reads, "This report is ran every hour." Ouch. Also, last year I pulled in user guides from a third party vendor where none of the procedures had numbered steps. Yes, this is what happens when you let untrained writers generate unedited content.

But let's remember Sturgeon's law: "Ninety per cent of everything is crud."

The truth is that in those examples above, there was also some very useful information--just badly written. On the other hand, take a look at professionally written Help and you will find your share of well-stated, correctly punctuated crud. "Type your user ID in the field labeled UserID." Well said but still crud!

My job right now as the UX architect on the project is to translate these high level requirements into scenarios and the starts of stories so that my Engineering cohorts can estimate the various features. So with apologies to my technical writer friends, I have embarked on creating a design that will make it easy for SMEs, who have insight about how to get value out of our portal and services, to pass that insight along. I want it to be easy for the SME to post, and easy for the user to get to it.

So I'm looking at a split pane, embedded assistance panel. The top pane will be for tips and definitions and the bottom pane will be for links to larger files, such as video tutorials and PDF documents that offer more extensive information. It can also contain links to KBAs as well. The split pane approach keeps the external links above the fold.

I'm asking the Engineers to code it to look for HTML files in a database, and to make that database available to the SMEs who are responsible for the content.

So not only I am developing user stories such as:

• As a portal user, I want to see contextual Help so that I understand how to use specific aspects of a screen I am on.
• As a portal user, I want to hide the embedded Help pane so that I have more real estate on my screen.

I am also developing stories such as:

• As an SME, I want to upload content to the embedded Help for a specific screen so that I do not have to be limited by engineering availability to add or edit content.
• As an SME, I want to provide links to documentation and media that could help a user on a specific screen so that I do not have to be limited by engineering availability to add or edit content.

In addition, I will develop the templates and CSS files for the embedded panes along with guidelines that help SMEs focus on writing effective user assistance.

Not sure what the outcome will be, but I suspect it will be Help that is more helpful but less elegant than if we went with a traditional HAT and technical writing staff. I'm sure there will be examples aplenty that support Sturgeons law, but that is always the case.

Productivity

The head of my engineering department had a meeting yesterday to talk about getting from requirements to shipped product. He talked about our need to become more productive and more efficient--not because we were dogging it, but because the market place is getting more competitive. He made a couple of points that had the same clarifying effect you get when you've been knocking about in a dark room and you finally turn on the light. That "aha!, that's what I've been barking my shins on" kind of moment.

He defined just one metric for assessing the productivity of an engineering department: $/E
$ = revenue
E = number of engineering employees

The point is that any time you are exerting any kind of effort, you must ask "Is this adding value that someone will pay for?"

He also talked about efficiency, and he pointed out that there are only two ways to improve efficiency:

• Add more value for the same amount of work.
• Do less work for the same amount of value.

The second bullet leads to such questions as "Do we need  a 90-page PRD to build this?" and "How much detail does the programmer need in the wireframe to know what the UI needs to do?"

He did not give the following sobering example, but it is food for thought along these same lines as we go into the new year.

Let's say that your product has a profit margin of 10% and let's say an employee costs $100,000 a year.

A company would have to sell $1,000,000 of product to add $100,000 to the bottom line.

Or it could lay off that employee.

I worked for a guy who had been a colonel in the green berets. He used to describe poor performers as "So and so isn't worth their rations."

$/E

Top four misunderstood expressions

There's a great column in UXmatters on the Freemium Model. What I liked most was that the author resurrected B.F. Skinner and reinforcement ratios. I was talking with my wife this weekend about what I consider to be the three most misunderstood expressions, and this column reminded me that B.F. Skinner is a source of a common misunderstanding--so my list has grown to the following four most misunderstood expressions:

1. "God rest ye merry, gentlemen, let nothing you dismay." It means, "Hey guys, I hope God keeps you happy, and don't let anything scare you." Putting the direct object "you" in front of the verb "dismay" throws folks--that and the fact they don't hone in on the first comma before "gentlemen."
2. "Wherefore art thou Romeo?" Means "Why did you (hunky guy I really like) have to turn out to be Romeo--my enemy?" Wherefore means "why" and note the lack of comma before Romeo.
3. "Suffer the little children." Means "Put up with the kids."
4. And last, my buddy, B.F. Most people interpret negative reinforcement to mean what B.F. Skinner calls "punishment," i.e., the doing of something unpleasant to make someone stop doing something (like the electrical shocks Bill Murray administers in the lab in Ghost Busters). Actually, negative reinforcement is the removal of something unpleasant to encourage someone to keep doing something. If a teacher cancels weekend homework because a class has had perfect attendance, that is negative reinforcement. The key is the word "reinforcement."

Designing for the total mobile experience

I've been working on my first "smart phone" project--investigating how our managed security services portal could accommodate smart phone users. If nothing else, it forced me to take the plunge about a month ago and get an iPhone. Up to now I have used phones to call people and take calls from people. At least I was using a cell phone and not one of those things that hang on the wall and you have to crank.

I was lucky to have done an internal presentation about 2 months ago for IBM on the same topic I will be doing at the STC Summit in Sacramento (Designing user assistance for trial demo software), and the speaker right after me was the manager of the IBM Mobile Research Center. Needless to say, I stayed on to hear what he had to say. (Say what you want about large corporations, how many companies have a Mobile Research Center?)

The most important insight I got from his research was that users distribute a task between their smart phone and their workstation. Smart phones are easier to access than workstations and good for monitoring; workstations are better for doing work than smart phones. I know, kind of duh!, but it's led to a different approach to the UX design than I would have taken.

I am writing use-scenarios that envision the total experience:

• What triggers the user to access our portal from a smart phone?
• How much of the task needs to be/should be done on the smart phone?
• How do we gracefully transition the completion of the task to when the user gets back on our portal from his workstation?

It has really helped me stay away from just redesigning pages to look good in constrained real estate. 

And the way cool part is that my wireframing tool, Basalmiq Mockups, has iPhone templates.

 
Oh brave new world :-)

Better than Disneyland!

I don't think there is any way I'm going to be able to tie this blog into user assistance or user experience, so I'm writing it off as "Hey, it's Friday and it's my blog :-)"

Went to a gritty little bar in Atlanta's mid-town last night that has an open bluegrass jam session every Thursday night. I mostly play alone-- three times a year I get together with an old high school friend and play Dobro to mostly what would be called folk songs.

I was nervous! My minimum objective was to find the place and walk in with my guitar. If I only did that, it would be a baby step in the right direction. My other objectives were not to cry and not to throw up.

These folks were good! It turned into a group of about 4 fiddlers, 2 banjos, 2 mandolins, a stand up bass, and a couple of guitars--oh yeah, and a Dobro player, me!

Not only did I meet all my objectives, I actually got my Dobro out and played along. Bluegrass jams are an interesting dynamic. There is a real culture of inclusion. Every player is given an opportunity to solo. Sometimes when I got the nod, I could only shake my head and say "I got nothing." But then there were the times when the lead banjo guy or the guy on bass would say, "Take it, Dobro," that I had something and jumped in.

They called me "Dobro!" A sixty-one year old man should not get giddy, but I gotta tell you, I'm still flying over that!

Playing bluegrass in a group that big, what with its driving rhythms and full sound, had a very physical sensation. It reminded me of when I would go sailing in a brisk wind. There is an awesome sensation of being moved by something that is both soft and powerful at the same time. Air pushing a boat at adrenaline-provoking speed--vibrating strings carrying you in a current of harmonious sound.

I will never be the same.

A simple productivity tool

A lot of vectors converged this week:

• Got back from vacation with the usual back-from-vacation-what-is-it-I-do-that-these-folks-pay-me-for fog
• Recently got a new boss (former boss from earlier position)
• Some projects slowing down, some simmering under the radar, some seemingly waiting for...oops, waiting for me!

On and off I have used an Excel spreadsheet to track my time against projects, and that has been a useful tool--psychologically, it keeps my nose to the grindstone. But it has some limitiations:

• I don't share it with anyone--hey some things just need to stay private.
• It is "time spent" focused, not achievement focused.

So I created a new tool to use: A Google spreadsheet to track project status and to log activities against their respective projects--not time, more of "Held meeting with SME to determine how single sign on works" and the date. Each project has its own tab with the following:

• Project name
• Description
• Status (green, yellow, red)
• Status description (where the project is currently or why it is yellow or red)
• A log to record activity and date

I also have a main summary tab that pulls all of the above information except the log and that shades the status cell with the appropriate color (use the "change with rules" option for the background color).

Tip: To pull data from a another sheet in the same file:

1. Click the cell on the summary page where you want the data to show.
2. Type an equal sign.
3. Navigate to the sheet that has the data you want to display.
4. Click the cell that has the data.
5. Press Enter.

And since it is a Google doc, I have shared it with my boss.

My new routine is to look over the status summary and the individual tabs each morning.

Here is what I have noticed:

• I am motivated to do something so I can log an activity. And since neither my boss nor I are stupid, I look for a meaningful activity.
• When my status indicates I am in a holding pattern waiting for someone/something, I send an email to the party I am dependent on, or I schedule a meeting with them--and log that activity!
• My focus is on making progress and not on clocking in and out.

I find this particularly helpful in my current environment, which is an Agile shop. I am on several scrum teams and I have some strategic project work I am involved in. My daily scrum reports do not adequately let me reflect on my total contribution. This status spreadsheet does. BTW, the log is great for when I call into my daily scrum meetings, I can see exactly what I have accomplished the previous day for that project.

Productivity: Live by the sword, die by the sword?

I was not only enthralled by an article in the Sept/Oct issue of Intercom (STC's magazine), but I was equally interested in my reaction. I love it; I hate it, wuh?.

The article is Measuring Productivity and is very well written by Pam Swanwick and Juliet Wells Leckenby , two STC members. This is a great article if you are involved in managing technical communication projects. That's the part I LOVE!

But a part of me is concerned that it might focus too much on what we produce and not on what we contribute, in terms of helping a design become more user centered or helping a team build knowledge that it can leverage. What does it do in the case when a writer spends a lot of time helping the developers improve the product but that effort does not get reflected in the writer's output (but does improve the user experience)?


Read the article and share your reactions. I've started a discussion in the STC group in Linkedin if you want to weigh in there. 

Zombies, Expertise, and Post-Apocalytic Scenarios

A lot of things kind of converged yesterday. I had lunch with my friend and colleague Miranda Bennett, and she was excited over a new game--lousy UI but engaging premise. Apparently you collect pieces and build a fort-like structure and then zombies come out to get you at night. I'm not a gamer, but I commented that zombies were a popular construct these days and wondered why. Miranda posited it was less about zombies and more about surviving in a post-Apocalyptic world. Hadn't thought about that. Most zombie movies do have that theme.

Miranda went on then to observe that people are being taught that they don't know how to cook (as she nuked her prepackaged lunch). She pointed out that even the simplest dishes, such as baked chicken breast, come prepackaged and pre-prepared. Add to that the other ways technology has embedded expertise into our tools, e.g., spell checker, calculators, etc., and no wonder we view post-Apocalyptic scenarios with horror--we will be helpless. Maybe the zombies are just metaphors for our atrophied brains--that would account for their craving to eat brains.

All this on the same day I received my author's copy of Qualitative Research in Technical Communication, edited by James Conklin and George Hayhoe. At long last, the findings from my doctoral research got published as Chapter 14. In it my major professor, Tom Reeves, and I discuss the role of experts on usability teams. They can streamline the process and even improve the results, but at a cost to team learning. We rely on experts and take them at their word, sometimes deferring our own critical thinking and creativity.

As user assistance tries to take the role of expert (see my article on User Assistance in the Role of Domain Expert in UXmatters) how do we avoid contributing to post-Apocalyptic impotence (PAI--I just made that up)?

I think the answer is simple, expertise should be about transferring insight and not about dictating steps. It should enrich the question so the user can wrap the answer in his or her own context and data. That way the user is enabled and not just directed. See my column in UXmatters Making the Deal: Supporting the Demo with User Assistance for a practical example.

Odd First Sentences

When I read my title, I was reminded of the Stephen Wright joke, "I got in a terrible fight at the roulette table with the croupier over what I considered to be an odd number." (It occurred to me as I read the title that all 1st sentences are odd--literally.)

OK, so I'm reading an article in American Rifleman (not mine, someone left it laying around at work) and the opening sentence is "It's surprising how many of our most useful and reliable cartridges started in the military."

You gotta wonder what is so surprising about that. I don't know much about guns and ammo, but if you came to me and said you needed something good in that line and asked my opinion about where to go, I'd probably come up with "See the Army." That's what they do, they shoot at people and they try to do it accurately and with great effect. They should know.

About 35 years ago I picked up a copy of my company's employee newsletter, and there was an article profiling one of the employees. Its opening line was "Bill certainly fits the mold of 'he's one of a kind.'" If he's one of a kind, why is there a mold? The sad part is that we were a manufacturing company, you'd think we would understand the concept of a mold.

And now a bit of a bonus, the original line that inspired the Bulwer-Lytton award:

"It was a dark and stormy night; the rain fell in torrents--except at occasional intervals, when it was checked by a violent gust of wind which swept up the streets (for it is in London that our scene lies), rattling along the housetops, and fiercely agitating the scanty flame of the lamps that struggled against the darkness."

 --Edward George Bulwer-Lytton, Paul Clifford (1830)

Note that its claim to infamy has more to do with the length and rambling nature, not the inherent badness of its oft abbreviated version, "It was a dark and stormy night." Had he left it at that, I think it would have been right up there with "Call me Ishmael." Hmmmm. Maybe I'll do a sequel to Moby Dick from the perspective of his girlfriend. Opening line: "Call me, Ishmael." (Apologies to Lynne Truss)

Three Myths

When I hear people talk about not getting respect for being a technical communicator (or not getting paid enough) I wonder if the following three myths are holding them back:

• Thoroughly described = adequately explained
• Accurate = useful
• Grammatically correct and correctly punctuated = well said
  

These are the "writer" myths, based on the belief that the value we bring is our ability to write. Technical communicators should be "sense makers" and "explainers." We should deliver timely insight that enables the user to act more like an expert.

Easy words to pen; hard ones to live up to.

Dashboarding

I'm reading a lot about dashboards these days. What a fun challenge in technical communication, trying to put ten pounds of information into a one pound UI.

I'm reading Stephen Few's Information Dashboard Design, and he makes the most elegant points:

Reduce the non-data pixels:

• Eliminate all unnecessary non-data pixels
• De-emphasize and regularize the non-data pixels that remain

Enhance the data pixels:

• Eliminate all unnecessary data pixels
• Highlight the most important data pixels that remain

He also had some interesting things to say about pie charts, as in basically they all suck. His point is that human perception cannot compare 2-D areas as well as other visual attributes such as length. He suggests that bar charts make better comparison graphics than pie charts.

So I'm trying a little experiment on myself. I keep a time sheet in Excel so I can track where my time goes (plus I find that recording my activities makes me way more productive--try it some time). I've been keeping a little pie chart dashboard on the sheet so I can see how my time gets allocated. It seemed useful to me.

So as an experiment, I've added a bar chart of the same data.

Here is the pie:


Here is the bar:


Jury of one is out on this. What's your opinion?

Menu Blind Spot

I'd write this one off to stupid user (moi) except that I saw it a lot when I was a usability tester. I wanted to change presentation colors in my email client. I was pretty sure I did that in Tools > Preferences. It is important to note that my opening assumption, I repeat, was that I would find it under Tools > Preferences. I clicked on Tools.


I couldn't find Preferences.

After some frustrated head scratching wondering where they would have put it, I saw it.

I would see the same phenomenon in usability tests with drop down menus where the top choice was preselected (reverse video). Humans process a list like this:

Top item set off typographically in some way = column title and is not a choice; therefore ignore.

The reversed video selection became invisible as users would scan the not-highlighted choices under it. Because Preferences is a single entry and is underlined, I think I processed it the same way.

These mental shortcuts usually make us more efficient--but sometimes they get in our way. As designers, try to avoid making the top choice different in any way.

Rubifying the Language

My favorite Scrum Master used the word "uniqify" in a sprint planning call today, as in "Could you uniqify that expression?" I poked him through the instant message tool we have because he had recently taken me to task for using the word "epistemology" in a design session.

It turns out that this is a fairly common pattern in Ruby, as in stringify, uniquify, htmlify, etc.

The rule seems to be that the verb [term]ify means to take the ensuing object of the verb and give it the qualities of the [term].

Of course, this has instances in our day-to-day language, that's where all these types of linguistic manipulations have their origin. To "liquify" is to to make the object like liquid. Its opposite is "solidify." It's very similar to putting "ize" at the end of a term to make a verb--but I sense a subtle difference I haven't yet quite distilled.

As an amateur linguist, I LOVE when a language can do this. Arabic does it on steroids, having a very complex set of patterns that decomposes just about every word down to a tri-literal root. Verb forms take their nuances from the root, as do noun patterns for the doer, the done-to, and the where-done.

English doesn't do it nearly enough. Sure, add and "er" to the end of a verb to get the doer, as in writer, rider, sleeper. Sometimes an "ee" to get the done-to, as in payee. Do we even have a pattern for deriving the noun for where-done from the verb? For example, the Arabic word for school, madresa, comes from a pattern that makes it "the place where studying is made to happen."

HTMLify is my favorite so far. "Can you express this in HTML?" becomes "HTMLify it."

Tonight I'm going to mealify some leftovers. Anyone who thinks that means "reheat" has never seen what I can do for leftovers.

Knowledge Life Cycle and Social Media

I usually try to keep work and blog separate, but I gotta say I really like working for IBM and especially the IBM Security Services group. Why? I get paid to have some really interesting conversations.

Last week I was in a meeting where we were discussing the right way to use Lotus Connections in our work team--versus a department Wiki we already have.

Lotus Connections is social network app that has forums, file uploads, activities, wiki, yadda yadda. BTW, it's pretty good. But the discussion was "When do we use that tool versus our more formal department Wiki--where we keep departmental procedures and such?"

The conclusion was actually quite elegant in its simplicity: We will use Lotus Connections to hold the conversation; we will use the Wiki to curate the answer. I'm sure that's not original--but we got there on our own, nonetheless.

I think this is a pattern that has lots of applications where social media has started to get traction. Online user doc vs. user forums, for example. STC SIGs and its Body of Knowledge is another example that I think about a lot and that seems to apply here.

I think this is a field that needs a lot of discussion and open dialogue, specifically, how to manage the life cycle of knowledge from ideation and churn, through vetted "this is how it is," and eventually to "this is last week's dead fish."

Of course, my traditional mistake is to impose formal process and control on what should be left open and organic, but still, I feel that some sort of process or guidelines would be useful. Here's my laundry list of questions. More questions, answers, general trouble-making--all are welcome:

• What are the stages of knowledge or what are the categories of maturity/credibility, whatever?
• What other dimensions should go into "whatever" in the question above?
• Where does knowledge live during these stages?
• Who moves its classification during its lifecycle?
• At what point is someone liable for the consequences if knowledge is acted on and proves wrong?
• When can knowledge be branded as intellectual property in an evolutionary model like this, and who gets to own it?

And I apologize if this is all naive and the solution is fully developed by now. I was very involved with Knowledge Management before social media had the kind of impact it has today.