Sunday, February 28, 2010

27 Words for Snow

There is the idea that the Eskimo have 27 words for snow-- snow in its various forms is so well known to these people that all of its forms have different names. All of these different words help to differentiate between one type of snow and another. What happens when a taxonomy is unduly short? My Mom had a problem with her "computer"-- she kept referring to the problem that her "computer" would not light up; it was dim; it was blurry. For her, the video monitor and the processor were described with the same word. If the Eskimo can apply a specialist view on snow by describing it 27 ways, what happens to a technical description when multiple situations and/or devices are collapsed into the same phrase? In short: you get a bad technical definition.
What do you do when you face a technical problem and non-technical people are directing the work? This is especially bad when working with web design. In print design, page breaks, column breaks and 9x12 vs. 11x17-- these are all relevant to what you're designing. Move the same design project onto the web and these concepts go through a serious lensing. What do you do when you have this terminology breakdown?
  • Correct them. When they say "upload" you say "You mean send it via email?" This can be a painful exercise in being anal. At the end of the day, they won't get it, but you have a lot more questions. It's a passive approach to calling them mistaken but the net effect is the same.
  • Educate them. Try a primer on the terms and dynamics in use. Don't make them choke down two years of CompSci-- just give them color on the aspect of what's in play for the project. It then becomes the doctor-patient problem: Patient- "Give it to me straight, doc." Doctor - "You have a transitory displacement of your mandible." Patient - "What?" Some topics are very sophisticated and are difficult to put into layman's terms. I've seen this manifest in two dynamics. With a client, you have to educate your client at the risk of putting them off-- they hired you because you're a specialist. With a co-worker, education is more possible, but still not absolutely viable. You can try to educate co-workers, but if they can get the ear of their superior or your superior, education can be squashed, translated or incompletely executed. In one situation, co-workers routinely used the same wrong phrasing for YEARS after it was inappropriate. Because their non-technical co-workers understood them, they felt justified to use the wrong termiology and concepts. One even went so far as to email 2000 people with the wrong how-to because they didn't want to change to the new practice. With 2000 people armed with the wrong instructions, that worker wanted the river to follow the boat and revise the technical process to match the how-to that was distributed.
  • Translate them. This is what you have to do and some level, but it's an avenue that can make your project open-ended. For example: they say, "get this on the web" and that should mean that you finish off the work, upload the files to a spot where the files/application can be seen and used. It's common that techies translate stuff. The problems come when the user/client/non-technical co-worker (aka proponent) collapses multiple elements under the umbrella of the same term. They say, "upload"-- but could mean 'upload' (ftp); submit a form in a content management system; and/or email it. The remedy for that situation is come back and get a confirmation of the workflow available and the workflow they want to see executed. This is a much longer process because vagueness is a cornerstone of the project. If the proponent doesn't want to be corrected or educated, then they've opted for translation and a higher cost with a longer delivery time.

No comments: