Best. Documentation. Ever.

I recently picked up an OP-1 synthesizer from Teenage Engineering. The OP-1 is a marvel of design and engineering. But I already knew that, which is why I was so interested in it. What I didn't expect is that it has some of the best documentation I have ever seen.

Of course, saying it is the best documentation ever is a bit of an exaggeration. Kind of like saying Rembrandt is the best painter ever. Better than Renoir? Better than Tintoretto? When you get into the realm of art and genius, comparison becomes irrelevant. What is important is that they far outshine any of their contemporaries.

The same is true for the documentation of the OP-1. To start with it isn't "documentation" per se. There is no manual. There is no paper Getting Started guide. When you open the package (which serves as its own case, which is also pretty neat) there is a clear plastic overlay on top of the synthesizer, describing each of the controls. That's it.

Well, not quite it. Because in the available space over the keyboard the overlay also includes a 8-step "QuickStart" for getting started using the OP-1. Just enough to show off some of its key features and get you playing with it (literally and figuratively).

Does it cover all features? No. Does it go into detail about what each knob does? No. But it makes you comfortable trying them to find out for yourself. Besides, there actually is a more detailed printable user's guide available online. But you won't find that until you've at least looked over instructions on the overlay and tried it out a little. (There is a link to the online document in the lower-left of the overlay.)


Is it perfect? No, not quite. The plastic overlay can get a little wrinkled and not lay flat. Also, since much of the OP-1 is light gray, the white printing on the overlay can be a little hard to read when it is actually covering the device. But these are minor quibbles. For 95% of its purpose, the "documentation" for the OP-1 is as well designed and inspiring as the device itself. Nothing short of exceptional.

I Did Something Stupid (Wearable UX)

I did something stupid today. I disagreed with one of the leading experts in interface design, mobile, and specifically the soon-to-be-released Apple Watch.

The argument is over a chart Luke Wroblewski (@lukew) posted about the distraction factor of a smart phone vs. a smart watch, indicating use of a smart watch lets you be "more connected to the people around you..."

There are two problems here:

• First, the chart is fiction. It measures "real life" vs. "lost in phone" — concepts of psychological state which are hard to define, never mind measure.  Perhaps there is some real data behind the charts, but if so the labels do it no justice. I suspect the diagram is more a representation of belief or expectation than fact. In which, why is it a chart?
• Second, it is not the phone that this the point of distraction. It is the information on the phone — phone, watch, iPad, eye piece, etc — and not the device itself that is the distraction. So putting the notifications on the wrist may reduce the time it takes to switch from in-the-present to in-the-data, but it does not alter the distraction factor that data provides, whether it is in my pocket or on my wrist.

One of the most disturbing studies in this area is recent research into the use of "hands free" devices while driving.  I would equate Luke's proposal that data-on-the-wrist is  less distracting from "real life" to the arguments that hands-free phone technology is less distracting to driving. However, the National Safety Council published a report arguing that hands-free does not significantly reduce the risks to distracted driving.

"Hands-free devices often are seen as a solution to the risks of driver distraction because they help eliminate two obvious risks – visual, looking away from the road and manual, removing your hands off of the steering wheel. However, a third type of distraction can occur when using cell phones while driving – cognitive, taking your mind off the road. 

The amount of exposure to each risk is key. Crashes are a function of the severity of each risk and how often the risk occurs. Most people can recognize when they are visually or mechanically distracted and seek to disengage from these activities as quickly as possible. However, people typically do not realize when they are cognitively distracted, such as taking part in a phone conversation; therefore, the risk lasts much, much longer. This likely explains why researchers have not been able to find a safety benefit to hands-free phone conversations.  "

— Understanding the distracted brain:
Why driving while using hands-free cell phones is risky behavior
National Safety Council White PaperApril 2012

One argument is that the data on the smart watch is primarily uni-directional — not requiring a response. For example, a "be there in 5 mins"  message  But if that is the case, how are those messages being generated? By smart watch wearers pulling out their phones to push the messages? And the fact that the message doesn't require a response doesn't mean it doesn't require cognitive effort — and distraction from current activities — to process it.

Wearables such as smart watches may eliminate the time and effort required to pull out the smart phone. But I have my doubts (unfounded, uninformed, as they may be) that they actually reduce the distraction that modern streaming personal data causes.

Customer Survey Apocalypse

 I recently bought a fairly expensive item. I shopped around, decided what I wanted, and then went in to finalize the deal.

As I was completing the purchase and was shaking hands with the sales person, they leaned in and in a confidential tone told me a story. I would receive a survey through email in a week or so asking about my experience buying the item. The survey would cover a number of topics, including how clean was the showroom, was I told about all the options, was the sales person helpful, etc.

The reason for telling me this, he explained, is that the sales personnel are rated on the responses they receive. What's more, if they receive any responses less than "exceptional", they are considered to have failed. So, if I was happy with the purchase, could I please make sure I marked everything as "exceptional" on the survey?

There are so many things wrong with this experience it is hard to know where to begin. But what spurred me on to write about it is because this is the second time this has happened to me in the past year — dealing with completely different companies and different services!

So where to begin?

• First, I actually did have a good experience with the purchase and would, without prompting, have given a good review in response to the survey.
• But having been prompted, I am tempted to not respond to the survey at all rather than deal with the pressure to up my score.
• I don't blame the sales person. If he is being judged on each survey, why not try to game the system and improve the scores?
• I do blame the company. They have soiled what was a pleasant experience and made it seem seedy and somehow underhanded.
• I understand the need to stay in touch with the customer experience. And as problematic as they are, surveys are one mechanism to achieve this. Especially for large national or multi-national corporations
• But having said that, conflating customer awareness with personnel management is a disaster waiting to happen!

 I know people (and I am not far from being one myself) who would, under some perverted sense of justice, actually lower their scores on the survey in response to the request to score high. There are others, obviously, who would go along to be friendly and up the scores, regardless of what they might have given as ratings without external prompting.

Survey results are problematic enough to start with. 10% return on all surveys sent out is often considered a "good" percentage. Add to this limitation the fact that often those who hold the strongest opinions — either for or against — are the most eager to express their opinion. And now you further skew the results by having employees pushing participants to either extreme.

So rather than get an accurate (or semi-accurate) picture of the customer's experience,  they have invalidated the entire process and skewed the results. At the same time, they are using a completely spurious method for assessing their employees. Don't assess your customer facing employees on what the customer says! It is like telling the cleaning service their pay is dependent on how clean the bathroom sink is. You can be sure the bathroom sink will be clean -- even if the rest of the house isn't touched!

If you are going to rate customer-facing employees on what customers say, base it on the aggregate, not on individual scores. You are still going to sabotage the accuracy of your customer responses, but at least you would reduce the damage. And, possibly, not disillusion the customers you rely on to spread positive word-of-mouth about your business.

Going Around in Circles

I, like several million other people, have recently been trying out Google+. G+ has received plenty of press in the past few weeks and I don't want to add to the noise. But when I started I noticed two things that I didn't see mentioned until recently:

• All my G+ friends are KM types, or otherwise involved professionally in communication and social interaction. Few if  any of my "normal" friends are using G+ (or see why they should).
• I don't like making circles. They require too much thinking.

The first observation were confirmed this week when the unofficial Google Plus Directory (http://findpeopleonplus.com/) posted demographic information on G+ users based on their ascribed professions. Most of the top twenty are technology or information-focused professions. And many of those that are not explicitly "in the business" are questionably tied to technology (such as writers and designers).

My second issue is around circles. I understand they sound like a good idea. My personal (and professional) relationships are more complex than Facebook's simplistic friends / non-friends model.So being able to define your relationships in more detail sounds like a positive step.

The problem is, it's far more difficult than it sounds. I have friend friends and I have professional friends. I have professional friends and professional acquaintances. Some work for my old employer; some used to; some never did. Some know I am interested in poetry and video games (among other things); some don't. A few have met my wife; some may not even know I am married.

When I start to break it down, it is not only not binary, it is more complex than even I can describe. Which is what makes Google+'s circles so frustrating. They require too much thinking. This is not a technical issue, per se, but a failure to be able to turn an implicit organic process into an explicit concrete categorization.

In other words, my friends are analog and circles are digital.

Andrew McAfee confirmed my suspicions in a blog post. He goes into far more depth and argues that it is an issue of a priori vs. a posteriori decisions.I am sure he is right from a process perspective, but I am not even sure deciding after I find an item to share is going to help that much.

Part of the joy of Twitter is that there is no decision. You post or you don't. You open yourself to anyone who chooses to listen (essentially). Oh, it has its limitations as well (starting with the length of the messages). But the freedom from thinking about who a message is intended for can be quite liberating.

However, that freedom doesn't have much to do with friends; it has more to do with publishing (or proclaiming). But it can be a useful and easier process in the digital world than trying to sort out your friends.

The Ultimate Architecture Diagram

I carry a small notebook with me at all times to jot down ideas, reminders, fragments of thoughts, or just doodle in my spare moments. Over the years I have filled up quite a few such notebooks.

Many of the items in them I can identify, some I cannot. They include drafts of messages to coworkers, a phrase or word I thought critical at the time, or notes for business presentations long since given and forgotten.

I was leafing through one of my notebooks the other day when I came across a curious diagram. I don't remember where or when I drew it, but looking at it now I am struck by its simplicity, its utter honesty and completeness.

Yes, there is stuff. And there is other stuff. Beyond that, very little matters.

The issue, from a business, technical, and/or personal perspective, is being able to separate the right "stuff" from everything else. There lies the rub. Maybe I captured that in another diagram, but I can't find that one at the moment...

Thinking About Tabs

OK. I am back to designing interfaces. Well, interaction design more than UI design since I am concentrating on the larger scale sets of content and interaction rather than the detailed UI artifacts on the page.

One thing I am learning this time around is that I have a proclivity for tabs. But tabs are dangerous. Let me explain.

Tabs are an easy way out. They let you create multiple "views" or "panels" at an equal level and tie them together with the tabs. For example, Facebook (with Home / Profile / Find Friends), Yahoo Shopping, or — most famously — Amazon. Of course, Amazon has dropped their tabs. But the intent is still present in their lefthand pull-right menus.

The key to a tabbed interface is that it lets the user decide between multiple functions or views. The advantage is that the tabs stay present so the user can navigate easily between functions. The disadvantage is that it is up to the user to decide; the interface does not promote a specific priority or process.

Which is what makes tabs dangerous. It is too easy for the designer to accede responsibility for guiding the user and say disingenuously "the user gets to decide".

Tabs make sense when dealing with a large inventory of heterogeneous objects. In this situation the tabs act as a classification mechanism. But what if the content is not evenly distributed or readily partitioned? Then the tabs are simply a way to "chunk" a large set of functions with little regard for their natural affinities (c.f. the facebook tabs).

While working on my current design project, I discovered that I often fall back on tabs as a default technique for organizing disparate information and controls. The consequence is that I tend to get lazy and not think through the other possible options.

Even if done well, tabs tend to reinforce ingrained ways of viewing the content, without thinking too deeply about the alternatives. Using tabs feels safe, but it can unnecessarily fragment the workspace, separating functions the user may want to compare or contrast. (Jakob Nielsen has an excellent essay on this topic.)

So, if tabs are not the answer, what are the alternatives? Perhaps it might serve us well to think about why tabs so readily come to mind. I suspect it is historical. The web started as a hypertext delivery system, where the text was largely static. There were forms, but little other interactivity. Much of the "early days" of the web were focused on determining best how to:

• Structure the content
• Represent the structure as navigation

Menu bars, navigation menus, and ultimately tabs became essential components of the web experience and designer's toolkit. However, as we move into Web 2.0 and the predominance of scripting languages, flash, and HTML v5, the web is not only interactive, it becomes an application of it own.

Although there is still a lot of text and pictures where navigation plays a role, there is a lot more interaction involved and the design must help direct users through processes, not just content. It is unclear that what has been learned from years of application interface design has yet to be effectively integrated in web interface design.

The Work of Technical Documentation

Contrary to the assumptions of many, the job of technical writing doesn't involve that much writing. The actual act of writing is at most 30% of the work.

In fact, the more writing you do, often the worse the end product becomes. Writing is a test of understanding. As you write, you come to realize what it is you understand and what you don't.

But if your job is to write, you not only need to write to understand, you need to write to be understood. Two distinct and at times opposite goals.

The danger is that, when writing instructions for something you don't completely understand, you write more. You try to write around the parts you don't understand; you describe it two or three times in the hope one of the descriptions sparks understanding in the reader; or you simply transliterate what you are told, because you can't figure out what parts are important and what parts aren't.

The result is lengthy documentation that does more to obfuscate that elucidate.

So if technical writers don't write, what what is it that they do? Well, primarily we investigate. We learn so we can explain. This is particularly true of new products where often the developers themselves don't know exactly how the features will be used by the customers.

I lay no claim to scientific accuracy, but my estimate is that more than half of the time technical writers spend is used in investigating. Of the remaining time, about half is used for actually writing. The remainder is used for testing (to see that what we wrote is true) and "production" (proofreading, editing, and the tedious and finicky work of tweaking the content into the appropriate output).

Are there exceptions to this "rule"? Yes.

• New Projects: When you are starting a new project from scratch, excessive amounts of time are dedicated to production, since you need to get your processes and tools right. Then the split is more like 40% investigation, 20% writing, 10% testing, and 30% production.
• Wrong Tools: If you aren't using structured tools (for example. using Word instead of xml or other structured tagging system), you spend far more time on production but don't know it because it is indistinguishable from the writing. At least 30% is production and/or rework spread out across the project at all times.
• Updating Existing Documentation: If you are doing an "update", less time is spent on investigation but it is usually made up for by more time in testing as you need to make sure existing descriptions are still accurate. Something like 40% investigation, 25% writing, 25% testing, 10% production.
  

What Happened to Postcards?

I spent much of yesterday at the Museum of Fine Arts in Boston. It was a singularly exhausting experience -- as most museum visits are. (Being a combination of exhilaration and stultification at the same time.)

But what particularly struck me was when we visited the gift store before leaving (I can't resist tacky souvenirs) and there were no postcards for sale.

Yes, they had one small rack of postcards of Egyptian paraphernalia, capitalizing on their current special exhibit of an Egyptian tomb and children's fascination with mummies. (Egypt is to art museums what dinosaurs are to science museums.) There was also a book of postcards depicting paintings by Monet. But there were no small mementos for sale of the individual works that may have struck a chord during your visit.

At first I was confused. But then it occurred to me that there may be a very practical reason why postcards are missing: no one sends physical mail anymore.

Now, this is just supposition. There are a number of different reasons why they may no longer sell postcards: too expensive to produce, take up too much space, need to constantly change stock to keep up with what is on display at any given time... But these conditions are either identical to what they were 20 years ago or easily offset by inflating prices (as they do with the trivets, posters, T-shirts, and other items that are on display).

So I can only assume the market for postcards has itself diminished because people do not send physical mail anymore. Statistics from the US postal service verify this, indicating that personal correspondence via USPS decreased 14% between 2002 and 2008. And the drop off is expected to continue.

The unfortunate part of this situation is that postcards play a role beyond just souvenirs and something to write "wish you were here" on. Postcards, especially postcards from places like museums and zoos that have many different exhibits, serve as mnemonic devices. These mnemonics remind us of the strong emotional experience of seeing the painting, sculpture or whatever. They also act as a surrogate of that experience that we share with those we send the postcards to.

People do not send as much mail because email and other electronic media have replaced the need for physical letters and cards. (As well as being easier, cheaper, and more convenient.) In place of postcards, I could have taken pictures of the paintings I wanted to remember -- which I did in a few instances. But the lighting in museums is hardly conducive to photography. (In some cases, it doesn't even seem very conducive to viewing!)

So what should be done? As much as I enjoy postcards, I recognize it is not practical to argue a return to a form of gifting that never was very practical and is now downright archaic. But it would be a loss to the patrons -- and to the museum -- if there were no form of mnemonic to help visitors retain and relive the pleasure of seeing the art in first person.

If it is not financially viable to stock physical postcards, perhaps they can make it possible to send electronic postcards or custom "picture books" of one's favorite works, whether to yourself or to your friends?

But, surprise surprise. They almost do...

The museum has an searchable online catalog of many of its holdings. The catalog has an expansive advanced search capability. It even lets you send e-cards once you find a specific item. (Yes!)

However, the catalog is only available if you are on the internet, not in the museum itself. (No!) Add to that, the catalog is really designed for those who understand how the catalog works, not the casual user. (For example, the search interface has 12 fields. Enter "Egypt" under culture and search for items on display and nothing shows up. Search for "Egypt" as a keyword and 58 pages of results are returned.)

What would be great would be if there were monitors in each room that let you browse the items available in that room. (No painful searching.) You could select an item and send an e-card in seconds when it strikes you, rather than spending minutes (or more) searching for it later.

Better still, for those with smart phones you could provide a simplified interface that only asks for the asset or accession number. (The accession number appears on the bottom of the placard describing each work of art.)

(Example placard with the accession # 72.2617)

The visitor could quickly call up an item they liked and send e-cards to others or a reminder to themselves on the spot. They could even create an e-book of their favorite works as they proceed through the collection.

In an ideal world, the MFA could put 2D barcodes on the placards so the information could be scanned and retrieved automatically by cellphone. This would be the easiest method technically. However, it would require changes to museum itself (the placards) and a common interface on cell phones -- something available in Japan but still not standard in the US yet.

So sticking with the first two suggestions -- and especially the suggestion for a simplified search available on smart phones -- it would be possible for the MFA to provide a thoroughly innovative and satisfying way for visitors to remember and share their experience with very little change to the existing infrastructure.

Why should the MFA bother? Although this sort of addition would have a cost associated with it, much of the technology already exists in the electronic catalog. Simply by creating a targeted interface -- and promoting the new capability - the museum can deepen the experience for the patron as well as advertise its best qualities through the messages the patrons send.

The word "souvenir" comes from the French for the act of remembering. Postcards are both a souvenir in the sense of a mnemonic device and a vehicle of communication. Their loss may seem minor from a commercial perspective, but they served as a valuable thread connecting the museum experience (quiet, austere, contemplative) with the visitor's regular life (loud, jumbled, exciting and excitable). A thread by which we carry the experience of art from previous generations back into our lives.

Without it, the day at the museum is just that: a day at the museum. But museums have the opportunity to create an even stronger link, electronically. It will be interesting to see if they pick up the challenge.

The World's Smallest Instruction Manual

3.5 X 4.25 inches
Single sheet of paper, printed on one side.
(Instructions for a pocket calculator.)

The Work We Do

I recently changed jobs. As a consequence I am no longer "doing" Knowledge Management. I am reminded of this fact by friends who ask me how much KM is involved in my new job. The simple answer is none. But to be honest, that's not entirely true.

My new role brings me back to my roots in Technical Writing, Information Architecture, and what is currently known as "Content Strategy". (Although "Content Strategy" appears to be having the same sort of identity crisis KM and IA go through on a regular basis.)

Which may also explain why my new role doesn't feel so different. In my previous profession, people would ask me how Information Architecture relates to Knowledge Management. My pat answer was that KM is the architectural design of potential -- rather than existing -- information.

My response was flippant, but also quite accurate. Whether you are defining the structure of a website for well-understood content or designing an interface for some as-yet-undefined content that will be chosen by people in the future... the tools, the methods, and the experience you use are much the same.

Ditto technical writing, which is very much like information architecture except on a much smaller scale. (What goes in this document vs. another? Where do we put the introductory information so the user can't help tripping over it? etc.)

Now, I know there are technical writers that do nothing but write and are affronted if you suggest they "design" things. Just as there are Information Architects that design taxonomies and not much else. But the fields themselves are much bigger than that. Which is where the confusion and bickering comes in.

I seem to be constantly in the middle of one battle or another no matter which of my various "professions" I am practicing. The reason for that is because the boundaries are very fuzzy. And ambiguity makes people uncomfortable.

So they try to delineate their roles. On the one hand, practitioners try to define the field by how they currently practice it: the tools they use or the methodology they have adopted. While others with a more philosophical bent try to expand the scope, often treading on the toes of their neighboring professions.

Currently, information architects are arguing whether IA even exists or if it (and several other forms of design) are all just different flavors of a new profession, user experience design. Or is it interaction design? Or is it...

Similarly, KM practitioners (and pundits from other fields) are trying to decide if there is a battle going on between KM and social media. Excuse me? There is no battle unless you assume KM as a field of study has to be practiced in a specific way or within a predefined, limited field of vision.

I feel like channeling a famous ex-wrestler and shouting "It doesn't matter what your profession is!"

The names we make up for our jobs help avoid conflicts when working with others by divvying up the territory. They also give us a ready answer to social situations when someone asks "what is it you do?"

Unfortunately, these names also create unnecessary barriers to getting work done. If you define your role by specific tools or tasks, you are also defining the boundaries for the solutions you can provide. You doom yourself to repeating the same work over and over... even when the environment around you changes, as it inevitably will.

The fact is that all of my professions are variations on addressing the traditional dilemma of communications theory. Whether it is communication between management and employees, among the employees themselves, between the company and customers, or among the current and potential customers the company seeks, the professions I travel with are all trying to resolve the problem of getting information into the right hands at the right time.

In knowledge management it is creating channels for the ambient knowledge within whatever community you support. In this case, your audience is often both content providers and consumers at different times. You don't control the content, you try to maximize the channel.

In information architecture it is sorting, defining, and providing a clear logical structure to at least that part of the information space you have control over (whether that be a web site, marketing, promotion, community facilitation, or whatever). You manage the content, somewhat like an orchestra conductor. But you are not the composer.

In user experience and usability design it is tuning the communication channel to be as effective as possible. You don't control the content or the structure, but you control how the audience interacts with it. (Of course, this is untrue in actuality because the interface becomes part of the message. Wasn't it McLuhan who said the medium is the message? But this is just another example of how the professions overlap...)

And in technical writing it is creating the perfect communication, including content and structure, but within the limited scope of the channel you have available to you (whether that be books, online help, training modules, or a web site). You have complete control over the content, but less over the channel and still less over the audience.

They all address the issue of communication from different angles. And taken together, provide an endless array of solutions and approaches when faced with any problem related to information.

That's why I like it.

And that's what I do.

Social Architecture

Patti Anklam recently asked whether we need to define social architecture and if so, how should we do it? I never shy away from defining new terms, as long as:

• The term identifies some meaningful thing or quality
  
• The thing being defined is new and/or unlabeled (and therefore difficult to discuss without some shared terminology)
  
• The term is not completely ambiguous*

My gut feeling is that social architecture would be a good thing to define. That said, let's start with what it is we are defining.

The Definition

Social architecture is the conscious design of an environment that encourages certain social behavior leading towards some goal or set of goals.

By environment I mean a bounded set of physical or virtual structures, functions, or events where people interact.

I say "certain social behavior" because you are designing for specific interactions with the aim of achieving some goal. You are not designing a generic space where people congregate and interact in whatever way they please. (Unless, of course, that will achieve your goal.) You are designing towards some purpose, such as encouraging conservation (wiserEarth) or grassroots sharing of ideas and innovation (barcamps).

On the other hand, I am intentionally vague about what constitutes an "environment". If we are just speaking of digital spaces, then there is very little difference between "social architecture" and "information architecture" or "interaction design". Designers of social software might very well call themselves "social media architects". But that is not inclusive of everything that is needed to instigate and drive social behavior. Barcamp is an example that requires digital spaces to organize, but also a physical space and event logistics to pull off.

There is an ongoing debate within the Enterprise 2.0 community that E2.0 is not just social software inside the firewall. It is a change of culture. Well, that change of culture cannot occur without establishing the appropriate environment to foster it, including a coordinated set of capabilities, recommendations, influences, and incentives. The design of such an environment is social architecture.

Is a Definition Necessary?

Why even bother with a definition? Well, the argument within the Enterprise 2.0 community is a good example of why a new term is needed. I won't go into the details of why discussing changing culture is unproductive -- Venkatesh Rao has done a far better job explaining it than I could do -- suffice it to say that rather than complaining about a resistant culture, designing a system that utilizes inherent social behavior to recognize and reward a different approach is more likely to result in change.

Unfortunately, social media is being applied within corporations as if it were a large hammer, cutting a wide swath through traditional, stovepiped corporate approaches to knowledge. Even when the new applications are well received (which isn't always the case), one of the side effects of this approach is an "us vs. them" mentality. The old approaches are not removed; the new social applications are set up in opposition to them, creating an unnecessary barrier between the traditonalists and new agers. This friction is often amplified by a lack of integration of the social software into the existing corporate infrastructure.

What is needed is a more systematic approach to integrating social applications -- and the activities and interactions they incite -- into the corporate environment. From a technical perspective, this means integrating the content into intranet search and actively feeding social content streams into traditional environments, such as intranet web sites (e.g. the latest Yammer messages on the team site, the employee's blog and Twitter ID becoming part of the corporate whitepages, liveblogging status meetings, etc.) From a operational perspective, structuring the social interactions around meaningful topics and goals helps avoid competing approaches.

This type of coordination does not require extensive resources or a major overhaul of existing systems,. But it does require planning and often a complex set of small, coordinated adjustments to systems and processes. And the best way to describe this approach is social architecture.

As a side note, despite my examples, corporate environments are not the only possible target for social architecture. However, I mention them here because intranets are an area with perhaps the greatest potential use of coordinated architectural approaches because of the need to address deep rooted hierarchical processes.

Ambiguity

We also need to check to see if the new term we are defining is so ambiguous it will be misinterpreted or quickly misused. In other words, is there a better term?

I happen to like social architecture for several reasons:

• It fits well into the lingua franca of social computing, where terms such as social media and social software are already established.
• It is distinct from the existing terminology which tends to focus on either the technology or the content, but not the overall strategy.
• It is relatively intuitive as a term and does not require a significant amount of explanation.
  

On the negative side, there is ambiguity with previous uses of the term within the realm of physical architecture and sociology. (There is at least one reference as far back as 1876.) In physical architecture, the term social architecture tends to refer to the application of architecture towards humantarian aims. Housing for the poor, sustainable architecture practices, and designing for larger social goals all seem to fall within this category. The Wikipedia entry on social architecture is a stub referring to social structures, a sociological concept not too far from the environments and goals discussed in my definition.

Although there is ambiguity here, it does not seriously invalidate the use of the term in reference to web-based systems. More importantly, there is sufficient crossover between the definitions to to avoid direct conflict.

Existing Usage

Finally, I make no claim of originality in defining social architecture. Besides the use of the term in other fields, there are already a number of references to it as applied directly to social software and the internet:

• Stowe Boyd defined it in 2005. Although he appears to define it as an existant state ("the foundation of the blogosphere") rather than as a specific activity.
• Sam Huweatt describes it in his blog. His definition is very similar to what I outline above. He also makes a distinction between social architecture and social media architects.
• Christina Wodtke lists the elements of social architecture in her book Blueprints for the Web (summarized in A List Apart).
• In his slide presentation on Social Architecture: Modeling the Next Generation, Sean Madden makes the point that "social networks have limitless potential but we need to work towards designing them that way."
• Amy Jo Kim, in her bio, defines herself as designing "social games and social architecture[s]". Her book Community Building on the Web pre-dates much of what we now consider social software, but is still the pre-eminent text on designing for social interaction. She also calls her blog "Musings of a Social Architect".
  

I take these all as good signs that the term is both useful and sufficiently clear in its meaning. On the other hand, there are at least two other uses that do conflict.

There are a number of people (in particular, Ryan Turner) who use the alternate term "web information architecture" to define much the same thing as I defined as social architecture. My preference for the shorter term comes from the fact that "web", by this point in time, is pretty much redundant. Almost all information and interaction in modern life now involves the web to at least some extent. But at the same time, as I mentioned in the definition, not all activity involving social architecture is web based (for example meetups, Big Urban Games, and barcamps).

There is also at least one case where social architecture is equated to an existing term (Information Architecture = Social Architecture). Although this is well-intentioned, I believe it is inherently wrong. Not all information is social (in the social media sense) and at least some aspects of information architecture -- such as navigation and metadata definition -- that are determinative, not social. And not all social interaction design can be considered a part of information architecture. They are definitely related fields, but not identical.

*I'm sure others would go for more precision, such as "not ambiguous". But if that were the criteria we would define almost nothing.

TwitterFish: Bridging the Language Gap

A common problem for knowledge management programs -- especially those that span multiple countries or continents -- is bridging the gap between languages. People obviously feel more comfortable communicating in their native language and in many cases cannot communicate well -- if at all -- in other languages.

For formal documents such as white papers or reports, there is no easy solution to this problem. Automated translation services exist but the results are often rudimentary, at times amusing, and at worst they can actually be misleading or just plain wrong. There is very little choice but to do manual translations for important documents, insist that everyone communicate using one common language, and/or live with a Babel-like ignorance of the knowledge and expertise of other countries.

Because of their limited usefulness for published documents, automated translation services have been shunned by most KM programs. But are they really so bad? Or are there cases where automated translation is not only "good enough" but provides a vital missing link for multilingual teams?

I was recently working with an organization that operates in four different locations around the world, in four separate languages. Clearly, the language barrier is a significant obstacle for them. It turns out, however, that within each geographic region team members communicate frequently among themselves through IM and mobile texting.

The good news is that communication is happening. The bad news, from a knowledge management perspective, is that the language barrier has become a permanent wall separating groups of employees and the insights they hold.

The usual KM solution to this problem is to try and get each group to capture their learnings in whitepapers, reports, and other written documents. The problem of translating those documents is then addressed as a separate task. The language problem is exchanged for a translation problem and significant extra work for everyone. This is in addition to the many bright ideas and offhand stories that are lost in the move from conversation to written documents (i.e. implicit vs. explicit).

But if you take a step back, translating everything (or even a select portion identified as "important") before determining if it is actually going to be useful, is inefficient and almost guaranteed to be prohibitively expensive. What is really needed is to get a rough sense if something is of interest before making the effort to establish connections across the language boundary.

Which is exactly what automated translation is good at. Trying to follow a procedural document written in a foreign language -- or translated badly -- without other assistance can be both difficult and dangerous (depending on how risky mistakes are). But knowing that such knowledge exists, even if you can't read it all, can save hours or days trying to recreate the learnings that have already been captured.

What would we give for a way to "listen in" to conversations -- no matter what the language -- to see if there was either a discussion we could contribute to or knowledge we could use.

Well, we have ways to listen in through social computing. Forums, blogs, and microblogging move the one-to-one conversation to a broader social platform. Micro-blogging services in particular, such as Twitter, provide almost all of the immediacy and interaction of IM but to a much larger audience. All that is missing is the ability to read the different languages.

Which is where TwitterFish comes in. TwitterFish is a prototype to demonstrate the effectiveness of automated translation services for identifying potential points of useful information.

Twitter already provides a translation feature for its search interface. But the public timeline and the stream of your friends' updates do not. TwitterFish lets you select a language and translate all updates into that language on the fly. You can also click on a specific individual to see just their status updates, if you find something interesting.

The translations are still rough. You cannot use them alone. But the point is they give you window into what people are discussing in other languages that is not available in any other form. What's more, each message is associated with a person. So if you do find a piece of information you want to follow up on, you can start a conversation directly with those involved. Unlike translated documents, where the text is all you have, in social applications such as Twitter you have both the words and the people.

TwitterFish is just a prototype. Viewing the public timeline (the default) is interesting but not necessarily useful. However it does demonstrate the potential of automated translation services for dynamic data. The techniques used to create TwitterFish would be far more effective to groups bounded by a common interest. For example:

• Apply TwitterFish to Yammer, the business version of Twitter, where only messages from within a single company are visible.
  

• Create a Twitter account that "friends" a specific, global community of users, such as a professional organization. The accounts' stream can then be recast-- or displayed on the organization's web site -- translated into the viewer's language of choice.
• Apply the same technique to other dynamic community content, such as forum posts, blog comments, etc.

As a final note, TwitterFish is a fairly simple application. It would not be possible without the generous availibility of a number of foundation services. Specifically:

• Messaging services from Twitter
• Translation services from Google
• Interface functions from the Dojo Toolkit
• JSON functions from Jason Levitt

Twitter Revisited

A while back I discussed why I don't use Twitter. But despite my disclaimers, my curiosity about the service was unabated. Finally, after yet another friend asked for my Twitter ID, I decided to give it another try.

This time I made a concerted effort to use Twitter. By that I mean there is no driving need to use it, but it might provide benefits to my life and/or work. And there was no way to know without giving it a try.

I conscientiously used Twitter for two months. This took more effort than I would have liked. I had to remind myself to tweet. Occasionally it seemed like I was making things up to post (usually trivia about what I was doing -- cleaning the basement, making dinner, etc). But more often than not, there was something on my mind that seemed it might be remotely interesting to others. And at times I became quite voluble, as thinking and twittering became almost one and the same activity.

Let me just say Twitter is useless without friends -- and I have to thank a number of people, in particular Brian Halligan and John Tropea, for making my Twitter experience successful and enjoyable. In many ways, the two months flew by. They taught me a tremendous amount about what is interesting and what is not on Twitter.

For example, I discovered (as I had expected) that I do not like hearing the minutiae of people's personal lives: what pastry they are eating, how long they had to wait in line at the bank, what they are drinking, where they are drinking, how drunk they are, or who they are making out with while doing it.

On the other hand, it is quite exhilarating to see the breadth and depth of ideas people are pursuing within my fields of interest. A number of times I became engaged in conversations with fellow practitioners around the world re: the pros and cons of various KM concepts or methodologies, poetry, etc.

Finally, the open conversations in Twitter have introduced me to some surprising new members of a constantly expanding circle of friends and associates in the topics that interest me (and some I had not expected to pursue).

The world doesn't need yet another "why/how to use Twitter" blog entry. So I will refrain from that activity. (I think Mr. Tweet's 5 Stages of Twitter Acceptance is perhaps the best and most succinct of that species.) But I have noticed a few commonalities that I find interesting.

The most obvious is the personal/professional tweets dichotomy. There have been many posts arguing against flooding your twitter feed with too much personal trivia (even Tim O'Reilly mentions it as a cause for early pessimism about Twitter). However, this is not a black and white issue. For some people that is exactly what Twitter is for: a personal stage in an ever-expanding virtual social gathering. So it is a matter of personal opinion whether overtly private information is objectionable in tweets or not.

Also, it is not necessarily just a question of personal vs. professional. There were a number of times I found someone's professional tweets trite and almost intrusive. Too many "I'm at the office", "In a meeting with an important client", or "my PC is rebooting" type of tweets can be as uninteresting as what someone is having for lunch. So the personal/professional dichotomy might actually be more accurately a temporal/ideological split.

It is also not black and white because not all temporal tweets are annoying. In fact, I find that the people I am most interested in following tend to tweet a mix of ideas, actions, and questions. There are multiple layers: personal vs. professional, ideas vs. actions, statements vs. questions, theory vs. practice, proposal vs. proclamation... The twitterverse begins to look like one of those medical anatomy diagrams covered in transparencies -- each with its own brightly colored orgains, veins, muscles etc -- you uncover one at a time to understand the different ways in which the body works.

The twitter interface asks "What are you doing?" (It is the naive simplicity and flexibility of that question that imparts much of Twitter's power, allure, and mystery.) But that's not really the question. Just like someone asking "what's up?" at a party, the question is more of an opening for you to use as you see fit than a specific request. A party where everyone is listening and the conversations go on 24 hours a day.

The Intranet is not a Thing

Patrick C. Walsh recently asked for input on a concept he is calling lean intranets, based at least in part on the concept of lean manufacturing. The basic concept he is promoting is very attractive: make the intranet more productive by significantly reducing the content down to only that which actually helps employees "create value".

Certainly many if not all intranets could do with some dramatic reduction in either outdated or superfluous content. However, as attractive as the concept of a "lean intranet" is, it is based on a false assumption: that the intranet is a "thing" that can be managed or controlled as a single entity.

The problem is that the intranet serves more than one purpose and more than one master. Unlike manufacturing, where there is one linear process that can be optimized to reduce "waste", the intranet is more like a city, with hundreds or thousands of diverse members each with their own goals and objectives.

The reason this caught my eye is not because Walsh's theory is fatally flawed -- in fact it is not. His prescription for creating a lean intranet may make a few spurious assumptions, but the goal and many of his suggestions are still valid. (More on than later.) The reason the assumption is important to recognize is because the same assumption is endemic to corporate managers and intranet teams everywhere.

The Intranet as a Thing and its Postulates

For any company larger than, say, 200 or 300 people, you cannot ask "what is the purpose of the intranet" as if it was a singular thing. However, this is exactly how it is treated by many, many companies, resulting in some rather spectacularly dysfunctional behavior.

Most of the time when people -- especially managers -- talk about "the intranet" they are talking about the corporate intranet portal; the internal "home page" for the company. The problem is that the portal is -- quite literally -- just the tip of the iceberg in terms of content and uses of the intranet.

This "intranet as a thing" thinking results in a number of fallacious assumptions:

• The corporate portal is everyone's home page
• Only pages linked to by the portal are part of the intranet -- everything else is noise
  
• You can control the intranet by dictate

Many companies enforce the first assumption by setting the intranet portal as the browser home page as part of their standard PC configuration. But, is the corporate home page the most useful page for employees? Shouldn't they start at their division or their department's home page? And, let's face it, most experienced users navigate through bookmarks/favorites, significantly diminishing the importance of the home page...

Some companies also enforce the second postulate -- "the intranet is what I say it is" -- by limiting the corporate search engine to crawling only "official" pages. The argument is that by restricting the scope of search, you increase the value of the results that are returned. The actual consequence is that you put up castle walls around a portion of your intranet, leaving many employees (and their content!) outside the walls. This form of electronic feudalism creates significant barriers to sharing information across organizational boundaries within the corporation.

Finally, many companies try to control their intranets by dictate: they define requirements and standards for the appearance, structure, and even content of web pages within the intranet. These rules start out as well intentioned, attempting to define a common look & feel for the intranet browsing experience (usually through a common intranet banner, colors, and fonts). But it soon extends to guidelines for the layout and even the content of pages.

Again, this mandated layout is done under the auspices of standardizing the browsing experience and simplifying maintenance, but the result is that lower level groups are handcuffed into following a structure that may have no relation to the information they need to present. A prime example is intranet guidelines that require each organizational home page start with a mission statement and "news". I cannot tell you how many times I have watched groups struggle to come up with news items simply to fulfill this stylistic requirement.

Creating a Lean Intranet

As I said earlier, Walsh's assumption that it is possible to define a single set of criteria for identifying and eliminating wasteful content on the intranet from the top is flawed because the intranet does not have a single purpose, as a manufacturing process has. However, at each of the lower levels at which intranet content is owned and maintained it ought to be possible to define and apply such criteria. Because that is the level at which the goal of the content is defined and understood.

So although I am quibbling that a process for lean intranets cannot be applied at the top level, there is real opportunities for applying it at lower levels, assuming the corporate style police allow it.

The Alternatives to Collaboration

Ever since knowledge management as a discipline began some thirty years ago, there has been a strong focus on collaboration. We always assume everyone knows what we mean when we say that: groups working together and sharing knowledge. Even if we define “collaboration” at a more granular level (distinguishing between team collaboration and communities of practice or communities of interest), our intent is clear.

So why is it so difficult to get users to play along? At times it seems like we have taken something people do naturally and we have turned it into something they don’t want to do. Partially this can be attributed to regimentation: even if 90% of the people would do it naturally, there are 10% who don’t and will resist all efforts to enforce it.

But if we are honest with ourselves, the resistance to KM programs is a much larger ratio than just human disinclination. Frequently, an adoption rate as low as 20% is considered success for a KM initiative.

So where is the gap?

The Problem With Collaboration

We assume that collaboration is the preferred and most effective approach for sharing knowledge and solving problems. However, collaboration can be a surprisingly elusive goal. Reticence, resistance, even outright refusal can strain relationships among team members or employees.

The fact is not everyone is comfortable with the practices used to encourage collaboration. Not everyone likes brainstorming. Some people are simply not comfortable opening up to a group of relative strangers. And no amount of team building or facilitation seems to completely resolve these differences.

So, if collaboration is so fundamental, are the methods themselves insufficient or is there a deeper problem?

The Alternatives to Collaboration

Perhaps we need to consider the possibility that some people simply don’t like to collaborate. I am not talking about the “dead wood” and underachievers. In many cases, some of the most productive workers are also the most resistant to collaborative activities and group meetings. Despite not “playing along” they continue to work effectively. Sometimes more effectively than the rest of the team. How do they do it? What alternative approaches do they utilize to continue their high level of contribution?

In my experience, I have seen at least three behaviors people use to work with others. (This is in no way a scientific study, purely a personal observation.) The first is what is traditionally called "collaboration": working in teams, sharing knowledge and experiences openly, etc. The other two techniques are conspiring and competing.

Conspiring and Competing

At first, these two activities might not seem effective methods for working with others. However, they each provide a measure of collaboration that has -- in each case -- unique advantages in terms of achieving business goals (which, in the long run, is the ultimate goal). Of course, they also have offsetting and equally unique deficits.

Conspiring

Conspiring is very common among senior contributors within a team. Conspiring is simply a form of collaboration where the"community" is limited, usually to select members who the contributor trusts. Rather than speak out or agree during meetings, this individual will seek out others who they feel will understand and appreciate their contribution and work with those people to flesh out their ideas. They may even strategize privately about how to bring the rest of the team "around" to their way of thinking. (This is the conspiratorial part of the equation.)

The advantage of conspiring is that ideas gestate rapidly -- far more rapidly than in public discussions -- due to the level of trust and commitment of the participants. They talk almost in a private shorthand, there is so much understanding within the core conspirators. No need to explain fully or argue seemingly irrelevant details as can happen in broader discussions. Ideas and inspiration grow and move forward rapidly.

The disadvantage of conspiring is that the individuals who practice this technique can be seen as not "team players" or as underhanded if their conspiring is found out. When they finally reveal their opinions -- fully-fledged and often in opposition to ideas being openly discussed -- it can result in hard feelings, even though the ideas are well thought out.

Competing

Competing, on the other hand, happens out in the open. Competing is founded on two basic assumptions:

• Ideas reached by consensus are not necessarily the best ideas. Rather, they are ideas that sound most agreeable or that provide the least resistance to current conditions (in other words, ruffle as few feathers as possible).
• By openly pursuing multiple approaches in parallel, you can test more possibilities and (the key to competing) inspire each group to reach farther and develop a more complete and creative solution.

Competing is one of the key characteristics of open source development, as described in Eric Raymond's book The Cathedral and the Bazaar. The concept is that competition, the same basic principles behind capitalism's supply and demand and Darwin's theory of evolution, will drive innovation faster and result in the solutions with the best fit "surviving".

Rather than pursue a single line of thought resolving differences in the discussion, individuals inclined towards competing will break off in small groups offering to come back with the solution after they have tested and refined their theories. They will also argue the correctness of their ideas even in the face of significant opposition from the majority of the group. This is based on the thinking that only the marketplace can determine the true right or wrong of a concept. Theoretical discussions, although interesting, are not decisive or binding in any way.

The obvious advantage of competing is that less obvious but more creative and possibly, ultimately, stronger ideas have a chance to survive and thrive. Competing can also break the stalemate that sometimes arises when groups or teams try to achieve consensus.

The major disadvantage of competing is that the individuals are often seen as loud, disruptive, and stubborn as they tend to stick to their ideas in the face of overwhelming opposition.

Understanding and Bridging Multiple Styles of Interaction

I have discussed these styles of interaction in terms of group decision making. However, they affect other forms of collaboration as well, which is where they can play havoc with knowledge management initiatives.

Each behavior leads to a preference for particular technologies. Those who conspire tend to adopt 1-to-1 technologies, such as instant messaging and IRC. Those who like to compete tend to favor group technologies where they can carve out their niche and take the lead, such as wikis and Twitter. Whereas, those who are collaborative tend to prefer more "democratic" tools, such as forums and distribution lists.

That is not to say there is a cut and dried separation. Conspirators may use forums, but they will tend to hang back and only respond when prompted or specifically requested. Those who compete will tend to use forums and distribution lists in bursts -- arguing their point of view vehemently (it is a competition after all) -- leading others to fall silent or complaints of aggressiveness or other asocial behavior.

Of course, there are times when people act trollish in forums. But that is not always the case. Sometimes they are simply communicating in their own, competitive, style which is seen as abrasive by others. But the backlash against their approach will tend to drive them underground until the next subject comes up.

Similarly, there has been a recent fad for using Twitter and live blogging during events (presentations, seminars, etc) as a "backchannel", sometimes even presented on a separate screen during the event. These technologies tend to favor those who favor competition -- literally competing with the presenter in terms of attention. They find this format invigorating. While those who tend to collaborate are extremely uncomfortable with the "noise" created by the competing inputs; their tendency would be to let the speaker have their say before opening the floor to discussion and alternatives.



Mix & Match

The good news is that -- like any personality traits -- there are no hard and fast rules about people's tendencies concerning collaboration. Some people are extremely conspiratorial, some are extremely collaborative, and some seem able to perform well in two different modes. Some people can both collaborate and conspire, while others conspire and compete and still others compete and collaborate. However, I don't think I've ever met anyone who does all three well.

The key is there are points of intersection and the individuals able to bridge the gap between different modes are critical to making the systems "work". For example:

• Cultivate personal relationships with the "quiet" members of your communities. Rather than trying to force senior contributors or other conspirers to participate in forums, contact them directly if there is a question you know they could contribute to. In many cases, individuals who would not speak up in public because they "don't have the time" or "have nothing to offer", are more than generous if asked directly 1-on-1. The output of these discussions can then be fed back into the forums by the intermediary.
• If someone is making a strident argument (and possibly verging on the abrasive), ask them directly what their suggestion is, making sure they get to explain it in full. You can do this either in public (the forum, meeting, or other venue in which the argument is occurring) or personally 1-to-1. Although this is the opposite of many people's tendency (which runs more towards "you are in the minority, please shut up") it offers a way for competitive members of the community to "have their say" and circumvent further bad feelings. In most instances, they are not trying to block a decision. They simply want to make sure that their point of view is being seriously considered. So once they get to voice it in full, they will allow the decisions be made and the discussion move on.
  

Searchable

Searchable is a lightweight application I wrote for use in a corporate intranet. It is a good case study in how the simple answer is often the most effective.

The design goal for Searchable was quite simple:

• The corporate search engine did not cover all of the content employees needed to access
  
• Several applications had their own search interfaces
• Employees couldn't remember where all of the content was
• Design goal: improve this situation

The design constraints were that we did not control the corporate search engine (we could not change its scope) and we could not replace it or compete with it (both for political and resource reasons -- we did not have a server sufficient to run our own search or produce a federated search).

The team had already tried providing a web site with links to all of the relevant resources. That had -- not surprisingly -- resulted in little significant improvement. It was just too cumbersome for users to jump from site to site, find the search interface, search, fail, then back up to the list and repeat.

What the users wanted was a consolidated or federated search: perform one search and have all the results in one place. This is usually expressed by the exasperated question "why can't we just use Google?"

Since federated search was technically beyond our means, I tried the next best thing. Rather than federate the results, I federated the interface. The result was Searchable.

The key to Searchable is that it provides a single interface. Enter your search terms, select a target, and press Go. The search box remains with the results in a frame underneath, allowing the user to switch targets and search again without losing context or having to jump back and forth. From a design perspective, the entire application operates in the browser (the client) and doesn't require any server resources except hosting the files.

My initial reaction, beyond being proud of the implementation, was that it wouldn't have much impact on the original problem. It doesn't do anything new: the results are the same and the user still has to search each site separately, even if I simplified the process.

But to my surprise, the users were happy, very happy. I could tell because they kept asking for new features and additional targets. (The e-mail link was one such addition, so if they found something they could e-mail the current search results to a friend.)

It seems that simply putting all of the search targets into a single input form was sufficient to alleviate much of their frustration with the fragmented content. They hadn't realized it was possible, so it looked like magic to them.

Searchable Revisited

The other assumption I made about Searchable was that it wasn't much use except on an intranet. I figured the internet is open enough and search engines like Google and Yahoo! are thorough enough that there was no need for a federated interface. (Besides, there have already been federated search engines like Dogpile. What could I provide that they didn't?)

But I actually answered the question myself one day when I was looking for some images online. I found myself trying Google first, then Flickr, then other sites. This was both tedious and not terribly rewarding, since I had to keep entering the same search terms.

So one aspect of Searchable which is not addressed by internet or federated searches is logical scoping by topic. Oh, search engines do segment by content type (images, video, maps, shopping, etc.) But the results are neither complete nor easy to sort and decipher.

Another aspect of searching (which was not originally addressed by Searchable but that I added for this version) is localized preferences. Some search engines allow you to refine your search based on various criteria. For example, if doing job searches you can specify the location to search. In many cases these are attributes that do not change from one search to another. So I added the ability to set and save advanced properties for specific search targets as part of the change options... function.

Try It

This version of Searchable is just a demonstration. I've provided some example targets. There are many more that could be included. The same goes for the advanced properties.

The technology is most powerful when tweaked for specific audiences (by adding and customizing the search targets to match the needs of the audience, such as a corporate intranet). But I have posted it as a sample so people can see it in action.

Pros and Cons

As mentioned above, the advantage of Searchable is that it satisfies a need. The disadvantage of a solution such as Searchable is that it is totally dependent on the REST interfaces of the target sites. If they change their parameters, rename them, or require new parameters, Searchable breaks. In the six months I managed an intranet version of Searchable, I had to update the mappings at least four times. So there is definitely a maintenance cost that needs to be considered before putting a solution like this into production.

The Purpose of Wikis

In one of the email distribution lists I participate in, the inevitable discussion of whether we need a wiki came up. As usual, this suggestion was followed by arguments for and against, etc.

I won't even go into the issue of people suggesting technologies without any clear reason for using them. What particularly caught my attention was one message that began something like "As I see it, wikis are meant to be..." Why did that attract my attention? Because wikis are a technology. They aren't meant to be anything. they simply provide a set of functions that may or may not be useful for different purposes.

Of course, like all technology, wikis were dreamed up to solve a problem. So if they were meant to do anything, it was to solve that initial problem. In the case of wikis, it was to let a group of people -- anyone -- easily create and edit a website without worrying about versioning, permissions, ownership, HTML, complex formatting, etc. The goal was simple, collaborative creation.

Now, once the technology existed, people found more and more purposes for the technology. Collaborative encyclopedias (wikipedia), event scheduling (barcamp), team/business collaboration (SocialText) etc. To say wikis were meant for one of these purposes over another would be inaccurate... and limiting.

We don't know yet what innovative uses will be discovered for the technology. It is still too early to tell.

The KM Core Sample

One of my favorite diagrams of the past year or so is what I call the "KM Core Sample". The Core Sample is not really an architectural diagram, since it shows no process or function that can be implemented. But I have found the diagram to be extremely useful in explaining why knowledge management is such a complex topic and where various KM methodologies "fit" within the strata of the knowledge universe.

(Click to expand)

The Core Sample is -- like its name sake -- a snapshot of a point in time. It captures the various levels of "knowledge" and where they reside. The diagram also illustrates the rationalization and codification of knowledge as it rises through the layers.

That last statement might sound like the description of a process: the codification of knowledge. But what I like about the diagram is that it shows that different types of knowledge reside in all levels at any given time.

This is because the process of codifying or standardizing knowledge into actionable procedures and practices actually changes the knowledge. It cleanses, sanitizes, and simplifies the knowledge -- removing the stray tidbits, the ugly but necessary workarounds, the secret tricks of the trade... all of the untidy clutter that make up true expertise in a field -- all of this is stripped off to achieve a linear, documentable, process.

But back to the diagram. Let's take a quick look at the various strata of the core sample:

• Starting at the bottom, at the very core, are people. This is where true knowledge exists. In other words what people know. And the most accurate way of sharing that knowledge is talking to the people who possess it: asking questions, telling stories, cracking jokes.
  
• The next layer up is where that personal communication is expanded to allow people to "talk" to others they do not know or cannot meet in person. Email distribution lists, forums, and other discussion technology reside in this layer. (Note that blogs are also in this layer.)
• The next layer up represents "knowledge capture". Here the knowledge is instantiated in documents of some kind: sample documents, lesson learned, case studies, white papers. These all represent mechanisms used to selectively capture and sort knowledge in such a way that it can be reused by people who may never come in contact with the original author. The obvious limitation is that only a small portion of what any individual knows about their profession is captured in any of these documents. This is offset by trying to capture the most important or influential pieces of wisdom.
• Finally, in the top layer the captured knowledge and learnings are further refined into a defined set of templates, guidelines, and standard processes. In some sense, you might say that in this final layer the actual "knowledge" has been removed and is replaced by step-by-step procedures to ensure a consistent and reliable execution of desired behavior. To achieve this goal, a significant amount of sorting, sifting, and selection is required to winnow down all possible options or alternatives to a limited set of recommended or required processes and deliverables.
  

What I like about the core sample diagram is that it helps you discuss the scope and effects of different approaches to knowledge management. Collaboration strategies focus on the tacit knowledge layer. Methods like knowledge harvesting, lessons learned, and storytelling focus on the best practices layer. While ITIL, Six Sigma, ISO 9001, and other standardization methodologies focus on establishing institutionalized knowledge.

The Web Litmus Test

[Editorial Note: At first I was doubtful about posting a concept I developed ten years ago. However, just the other day someone called me looking for a designer/developer. When I suggested doing an architectural design for the site content first, he said "we have all the content. What my boss wants is to make sure the site is flashy and cool." I guess we haven't made that much progress in ten years....]

Web design is a tricky business. there are so many conflicting requirements to consider, as well as rapidly shifting expectations on the part of the users as the web grows and evolves.

On the positive side, there is no shortage of guidelines and recommendations for designing web sites to make them usable and functional. However, despite this guidance, there are still sites that are simply "unusable" at a higher level. Sites that aggravate, annoy, insult, confuse, or simply bore their users. Why?

The fact is that most usability guidelines operate at a rather low, micro level dealing with specific interface artifacts and interactions: the placement of buttons, the arrangement of forms, the structure and consistency of the navigation, etc. These attributes certainly impact the usability of web sites and shouldn't be ignored. But often when a web site fails it fails on a much larger, dramatic scale. It fails because it doesn't offer what the user wants.

It is not possible to provide a simple set of design rules that guarantee a successful web site. There is just too much variation in the intent and purpose of sites to cover all circumstances. But there are a few basic measures -- what I call the web litmus test -- that can fairly consistently tell if a web site design will fail or not. Passing the test does not guarantee success; it only means your site has a chance of succeeding. But fail the test and your site is toast.

As I say, the web litmus test can't be used to design sites -- there is much more skill and experience required to design the site right from the beginning -- and that is where the art and science of information architecture comes in. But the test can be a very quick and useful reality check that anyone can perform for designs before they get implemented or for existing sites planning a redesign.

Seven Characteristics of Human Behavior that Affect Web Design

The problem is often not the design but the site itself -- what the site is doing or trying to achieve. It is not failure to implement, it is a failure of intent. The seeds of failure are planted early and concern the basic impulses that drive the creation of the site from the very beginning.

There are two separate sets of goals that control any web site: the goals of the visitors -- or audience -- and the goals of the owner -- or sponsor -- of the site. Those driving impulses are different for every site, but fall into seven basic categories.


For the visitor, there are only four possible goals:

• Help me find something
• Help me do something
• Help me fix something
• Once I have satisfied all three of the above, entertain me!

As I said, the specifics of what the visitor wants to find, do, or fix are different for each site they visit. (I wouldn't try to buy a vacuum cleaner from www.bmw.com, but figuring out why my current vacuum is making so much noise is a likely goal for a visitor to www.kirby.com.) With the exception of people simply "channel surfing" the web, the goals of all of your visitors fall into one of these four categories.

From the other perspective, the web site owner has only three basic intentions:

• Let me tell you something
• Let me sell you something
• Let me impress you!

These three impulses apply to all websites, even non-commercial web sites. (For non-commercial sites, "sell" can be interpreted figuratively to be an attempt to persuade the visitors to take some action: sign a petition, join an organization, etc.)

Achieving Alignment

It would seem, at first glance that aligning the needs of the owners and the audience should be simple: you want to find something and we want to sell something! Unfortunately, in practice the priorities and order of importance are often askew.

Site owners often focus on their last impulse first: let me impress you. At this point, it is fairly well accepted that elaborate flash intros to web sites are more annoying than effective. However they are still very prevalent.

Similarly, the days of commercial internet sites proudly displaying a photo and message from the CEO as a home page are pretty much over. However, many corporate intranets are still littered with web sites that prominently display a photograph of the manager, an org chart, and list of "news" stories and other managerial announcements. How does this help their employees find, do, or fix anything?

But the real problem is that the web site needs to address all of the visitors' possible needs, not just the one or two that match the owners' goals. Even if you can get past the sponsor's desire to turn impressiveness into a requirement, there is still too often a narrow focus on what the company wants to achieve and not what the users expect.

Note that addressing the needs of the visitors is not the same as solving them. If you are a manufacturer, you don't have to sell online. But you can expect at least some of your site's visitors will be looking to buy your goods, so you better tell them where they can buy your items rather than leaving them to vainly search your site and give up in frustration.


How to Use the Web Litmus Test

So, how do you apply the web litmus test? It is simple. Try this 15 minute experiment:

1. Pick a site on the internet. Any site. (If you have a commercial site on the internet I would suggest not starting with that one. It is hard to be objective the first time.)
2. Take 2 minutes to make a list of the things that site's visitors would want to find, do, or fix.
3. Spend 3 minutes trying to perform each activity from the web site's home page.

The key points to note here are that the web litmus test is in no way a complete analysis of a web site. Its goal is to test the site's main features against the visitors' main goals and nothing more. So don't try to go into too much detail.

Keep it short. 1-3 specific tasks for each of the visitor goals is more than enough. And if you can't complete a task in 3 minutes, you are already spending more time than the majority of visitors would before giving up in disgust.

Again, it is not a test of the entire site. It doesn't matter whether a specific function exists on the site, but whether someone can find it in an acceptable amount of time. This is why you should always start at the home page (as visitors are likely to do).

But the best way to understand the web litmus test is to see it in action, so let's try a few of examples...

Continue to examples of the web litmus test in action