Friday, November 26, 2010

Can Fish See Colors?

It never occurred to me to ask the question, until last night. We have a fish in an aquarium in the corner of our dining room. I think he is a char — we caught him in a pond as a minnow so I have never been sure.

He doesn't get upset easily; I can move around the room without disturbing him and we went all the way through Thanksgiving — setting up the table, eating and cleaning up — without his showing any sign of stress.

He can clearly see what is going on. When I come down in the morning, he swims to the corner (closest to the kitchen) and wags his tail, waiting for me to feed him as is the daily ritual.

But last night, after clearing the table, I figured we would switch directly from Thanksgiving to Christmas, but as I moved towards the table to put on the new tablecloth, our fish (Sam) suddenly started splashing and darting back and forth in alarm. Something had set him off.

What was it? I occasionally take him by surprise and he splashes and hides behind his rock. But this time he was more alarmed than usual. And I wasn't even that close to his aquarium. But there was one difference: I was carrying a bright red tablecloth.

The bright color red had triggered something in him. He was very agitated until I had the tablecloth on the table. Once it stopped moving, he calmed down. I hadn't seen behavior like this since he was a very young fish (and not accustomed to his environment).

So, do fish react to the color red like the proverbial bull? Or would it be anything bright and moving that triggers a defensive response? He hasn't reacted to colored shirts or other materials that I noticed. Whatever the cause, the result was dramatic.

Tuesday, November 9, 2010

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.

Tuesday, October 5, 2010

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.

Tuesday, August 10, 2010

Moderation (or Lack Thereof)

For the past month or so I have been struggling with an ethical dilemma. My original intent in writing this blog was as a vehicle for me to think through some of the issues and ideas that concern me most. A second goal is to share those ideas with people -- friends and the occasional stranger -- who find their way here. A happy coincidence of the blog is the opportunity to converse with people who share my interests and concerns.

Since my blog is open to the world, I feel it only fair that if I get to have my say, the favor should be returned and others should be able to comment on what I post. I really enjoy seeing what others have to say, even if they don't agree with me.

Given the limited audience I expect, I figured spam would not be to much of an issue. But I chose to require registration before you could comment as a deterrent, just in case. And that worked... until recently.

Over the past few months I have been getting more and more spam -- particularly in Chinese -- posted as comments. I just put it down to the inevitable random internet annoyance, but made sure to delete them as soon as I could. I figured I could live with this downside of a public site, even at one or two spam comments a week.

But the volume has increased to a bogus comment every day or two and although I don't mind the work, I am annoyed that they are there even for the few hours before I get a chance to delete them. I don't want to create more barriers than necessary, but I finally broke down and added moderation to comments on this blog. This means I have to "approve" comments before they become visible on the blog.

To those of you who do come here to read or comment on my blog, I apologize. I am distressed that I have to add this extra layer of indirection. But the use of moderated comments is not intended in any way to limit or censor your responses.

And, of course, thanks for reading... and responding!

Saturday, July 31, 2010

Twitterfish Revisited (the Language of Tweets)

Last year I built Twitterfish to translate Twitter messages as a demonstration related to consulting I was doing. I haven't done much with the prototype since, until recently.

It turns out that the new company I work for is stirring up interest in both the US and overseas -- particularly in Japan. But it is tedious to translate the Japanese tweets one at a time.

When I wrote Twitterfish, I thought of handling search results... But it was a prototype and I didn't have a lot of incentive to finish it off. Suddenly I had both the interest and the need.

So Twitterfish now supports search. (See the tabs below the banner.) It also paginates the search results.

Next on my list is displaying the date/time of each tweet, because I may need to count the number of tweets per week...

Wednesday, May 5, 2010

Lurking or Lost?

Stan Garfield made an interesting comment in response to my post on lurking. Stan said:

I assume that most people who stay subscribed to a community discussion board are usually paying attention to what is being discussed. They can benefit from doing so, even if they post infrequently (or never).

Part of what Stan is positing is true. People who are not actively participating can -- and often do -- benefit from the discussions within the community. That is the aspect of lurking that makes it a constructive activity.

But it is dangerous to generalize this belief, particularly if you are managing communities. Which I suspect is why Stan qualified his statement with "most". The distinction is whether people are actually lurking or have turned off completely.

Membership, or subscriptions, are often used to measure the size of a community, using the premise that, if they are still members, they are at least "actively lurking".

However, going back to my own experience, I currently belong to at least ten online communities where I receive email:

  • Two I actively follow, reading each email as it comes in and -- occasionally -- responding.
  • One I read thoroughly but never respond to. I consider it "keeping up" with a specific technology area.
  • One I read if I have time, but at least half the time I skip.
  • Two I browse the subjects lines but almost never actually open the email before deleting.
  • Of the remaining four, at least two I delete without even considering the subject line. One I delete angrily after seeing that their infrequent messages are wasting my time, and the last falls somewhere in between those last two categories.

So which communities am I actively "lurking" in? If you asked me, I'd claim to be a "member" of three of the ten. Four at most. Less than 50%.

In truth the situation is much worse than what I describe, since I am a registered user of 10 or 20 more communities which I do not receive email subscription notices from. Of these I actively visit the forums of, perhaps, 5; occasionally visit another 2; and probably can't remember my password for at least half of what remains.

If that's the case, why don't I unsubscribe? Laziness, probably. About once a year I go through and remove myself from the most egregiously bad lists. But over the next 12 months I probably sign up for more new ones than I jettison. Some communities I signed up with for a specific purpose, which has since been satisfied. Some I joined as an experiment. And for many, there is a sense of not wanting to miss something that I might otherwise not hear about. (Although time proves that supposition wrong.)

Whatever the cause, I am technically a member of far more communities than I am actually "involved" with, whether active or lurking. Which brings us back to the dilemma for community leaders: how do you measure the size of an online community?

You can say for certain that people actively participating (posting, responding, or otherwise contributing) are members. But as has been said time and again, this is usually a very small percentage of the actual community size.

On the high end (assuming your community supports or requires some form of registration) you can count all registered users. However, as I have just explained, that number is unlikely to have any true meaning. So reality falls somewhere in between.

Second Life was roundly criticized four years ago for not being clear how they counted their "residents". (To be fair, the company improved both their methods of counting and reporting membership in response to the complaints.) But part of the confusion is not just how they were counting, but disagreements about what methods are appropriate.

The situation is no better for internal communities within corporations. Ultimately, there is no true answer. The interest level of individual members of the community will ebb and flow constantly, often with no external indications. So there is no way to provide an precise measurement of "engagement", even as a snapshot.

If you have subscriptions, you can report a combination of senders (unique posters) and receivers (subscribers) to give a range of possible activity. However, this leaves out anyone who reads the message online or (as is increasingly common) through an RSS feed. If you have access to web logs, you can report the number of unique visitors to the site/forum. But merging this data with email subscriptions can be difficult.

But no matter how you count, there are a variety of actions community facilitators can take to "take the pulse" of the community, beyond just numbers.

  • Talk to your members. Contact people directly to ask if the community is meeting their needs or not. and if not, how it could be improved. Ask them how its going.
  • When questions are asked, forward the question to people you know are knowledgeable on the subject and suggest they post an answer. This not only keeps the conversation going, it helps gets more experienced members involved and can spur interaction between members who do not know each other yet.
  • If there aren't any questions, ask some. Not trivial questions, but questions that will get the community thinking -- and talking.
  • Thank people, either publicly or privately through email, when they contribute significantly to the community. Make them feel appreciated for their efforts.

If this sounds more like hosting a high society soiree than facilitating a community, there's a good reason for that. They are very similar tasks. It is not enough to schedule a party, hire a caterer, and send out invitations. Once the event begins, you must play host: introduce people so no one feels left out, make sure they circulate, suggest activities... even plan party games! The exact same sort of activities that are needed to keep a community going once it has begun. What's more, being actively involved yourself gives you an intimate and immediate sense of the health and well-being of the community.

Measurements are fine and often necessary to convince management that positive momentum is occurring. But more important is knowing for yourself, as community leader, that your members are involved and benefiting from their participation. And this is not a number, it is a state of being you can contribute to yourself.

P.S. Stan himself has articulated many of these and other good ideas for how to actively facilitate communities in his own writing. Most recently, in his community manifesto. Recommended reading for anyone interested in the topic.

Tuesday, May 4, 2010

"You are being redeployed...."

The English language is a funny thing; words have meanings. They may have multiple meanings and -- despite the fact that people publish dictionaries claiming to be the authoritative definition of words -- those meanings are fluid and can change over time. But it takes time. Words have meaning because people collectively agree to them.

Another funny thing about the English language is that people are always trying to change the meanings of words. And if they can't change the meaning, they change the words. These are called "euphemisms" and we are all party to it. When an event or subject is painful, we use alternate words to lessen the blow. People don't die, they "pass on" or "go to a better place" (not that we know that for sure, but it sounds better). The goal is to soften the blow.

Problems occur when rather than softening the words, the euphemism is so extreme it twists the original intent and tries to actually deny the reality of the situation.

Two years ago I was laid off. That itself is a euphemism. I was fired. The original intent of the term layoff (which is defined as "a period of inactivity or idleness") was to imply that -- once things got better -- you would be rehired. Now it has become a blanket term for any time you are summarily fired for reasons unrelated to your performance.

But layoff has a negative connotation and so had to be softened even more. (Just as downsizing was replaced by rightsizing -- right for what?) And so I was not laid off or even WFRed (work force reduced), I was "redeployed".

Excuse me? I was not redeployed, I was undeployed. Yes, they pretended that there was a period of time where I could look for work elsewhere in the company before I was terminated. But I was not redeployed; I was not "transferred from one area or activity to another" as the definition implies. (Unless you consider looking for a job a business activity.)

At least, once my "redeployment" ended, they did stay true to the language and "terminated" me.

I can laugh about it now. The bitterness of being laid off is temporal and easily erased by the adventure of doing new (and far more interesting) things. However, the distaste for how it was done and loss of respect for my former employer's business practices when they misuse language that way lingers. It is only a word, a symbol. But the symbols we use define how we see -- or want to be seen -- by society. And the more we mask our intentions with euphemistic phrases, although no one will outwardly call your bluff, trust and respect ultimately pay the toll.