Something stinks

When I run our dishwasher, the washed dishes stink. Kristina thought she figured out the magical incantation to avoid stinky dishes, but we both agreed it doesn’t work.

What gives?

This all started with simply unclean clean dishes. We put in the detergent, got the water hot, and hit “go”, but the dishes came out with (baked-on) crap on them.

Perhaps you’ve encountered a dishwasher repairman. They will tell you lots of theories for how to avoid unclean dishes: too much detergent, too little detergent, wrong kind of detergent (powder vs. liquid), water not hot enough, dishwasher installed incorrectly (“You see this hose? It goes down, then up; the dishwasher works twice as hard to expel the water. That’s your problem right there.”) Over the past two years, we’ve ruled out all of the explanations, including the dishwasher itself. (Granted, the replacement dishwasher was also a similar make, but it was installed by a professional.)

The dishes are now usually visually clean, but if you hold them up to your face, they stink. It’s just a bad smell, kind of like the funkiest dog that hasn’t been washed in a long time. Plastic dishes usually avoid it; it lives with many of the ceramic items.

I’m starting to think it’s the water. Kristina pointed out that the steam from the iron is a little stinky. I thought maybe it was the hot water (from the water heater), but the water going into the iron is cold. Could our water be stinky when heated?

The water as the source of the problem seems really unlikely: we drink it every day (usually filtered), and it never smells. We bathe in it, and it smells like nothing. Can you even test water for stinkiness (bacteria maybe)?

I have no answers at the time of this writing, but I know one thing: if I don’t figure this out, I might go insane.

Defining animal “behavior”

Continuing my Konrad Lorenz theme (I didn’t even know I had one) for another post, here is a link to a NY Times article on the definition of animal “behavior” (Hint: scientists don’t agree on one, but the superset of their ideas makes for a good definition):

When ‘What Animals Do’ Doesn’t Seem to Cover It, by Natalie Angier.

King Solomon’s Ring

In King Solomon’s Ring (1949), Konrad Lorenz devotes a chapter to the domestic dog and its evolution. It is one of the best chapters of the book,and one gets the sense, both from the chapter title (“The Covenant”) and the section’s cohesiveness and tone in comparison to other chapters, that the dog was quite important to Lorenz. Most interestingly, he frames the dog in an evolutionary history from wolves and jackals, and relates the behavior and other characteristics of the modern dog to these ancestors. I wondered about this claim, and whether it was still accurate; I’d only heard of wolves as the likely ancestors of dogs. Not only was I thinking about how accurate the chapter was, but I was also considering that if it’s not scientifically truthful, is it rational of a current publisher to publish it without so much as a footnote?

My understanding of the domestic dog’s evolution, up to this point, was based on a great NOVA episode, “Dogs and More Dogs”, which is to say its based mainly on the interviews of the researchers James Serpell (University of Pennsylvania) and Ray Coppinger (Hampshire College). In that show, they never mention jackals, nor the idea that behaviorally, the jackal contributes one set of traits to the modern dog while the wolf contributes another. Lorenz wrote King Solomon’s Ring in 1949; has our understanding of dog evolution changed since then? One would hope.

I think I’m right in concluding that the current consensus is that the domestic dog (Canis lupus familiaris) is a descendant of the Gray Wolf (Canis lupus). From Wikipedia:

The domestic dog was originally classified as Canis familiaris and Canis familiarus domesticus by Carolus Linnaeus in 1758,^[14][15] and is currently classified as Canis lupus familiaris, a subspecies of the gray wolf Canis lupus, by the Smithsonian Institution and the American Society of Mammalogists. Overwhelming evidence from behavior, vocalizations, morphology, and molecular biology led to the contemporary scientific understanding that a single species, the gray wolf, is the common ancestor for all breeds of domestic dogs,^[3][16] however the timeframe and mechanisms by which dogs diverged are controversial.^[3]

Another summary, this one from the Princeton Encyclopedia of Mammals (2006), agrees:

Various origins have been proposed for domestic dogs, and doubtless many different canids have been partly domesticated at one time or another. Even so, the wolf is generally accepted as the most likely ancestor of today’s domestic dogs. Domestic dogs are thus known to science as a subspecies of wolf—Canis lupus familiaris. The earliest known archaeological indication of domestication comes from a single canine jawbone unearthed at a site in Germany. More foreshortened than that of a wolf … this find is thought to be around 14,000 years old… These various discoveries demonstrate that the wolf entered into domestic partnership with man before any other animal species and before the cultivation of plants for food. Indeed, recent molecular evidence suggests that dogs may even have been domesticated as much as 100,000 years ago.

Sounds straightforward enough. Here are some of Lorenz’s assertions, for comparison:

At the dawn of the later stone age, there appears, as the first domestic animal, a small semi-domesticated dog, certainly descended from the golden jackal (Canis aureus). At this time, in north-west Europe, where skeletons of these dogs have been found, there were probably no more jackals, but there is every reason to believe that the turf dog already lived as a true house dog and that the lake dwellers had brought it with them to the shores of the Baltic sea. (108)

Interestingly, Lorenz’s ideas about the process of the dog’s domestication are less dated and even somewhat prescient, as they mirror contemporary theory (cf, Coppinger):

But how did the stone-age man come by his dog? Very probably without intending it. Whole packs of jackals must have followed in the train of the wandering, hunting hordes of early stone-age man and surrounded his settlements just as the pariah dogs of the East do to-day, of whom no one knows exactly whether they are housedogs run wild, or wild dogs that have taken the first steps towards domestication.

This is essentially Coppinger’s thesis, described in the NOVA special. But then Lorenz veers off-course, jumping to the misguided theory espoused by current dog trainer Cesar “Put-the-dog-on-its-back” Milan:

Very gradually, in the course of the centuries, it has become customary, in the “better families” of dogs, to choose, instead of another dog, a man as the leader of their pack.

We can, however, forgive Lorenz for this, and get back to the original question of jackal inheritance (which we may forgive him for as well). Lorenz states that “comparative research in behavior has revealed that all European dogs, including the largest ones… are pure Aureus [jackal] and contain, at the most, a minute amount of wolf’s blood”. Lorenz then goes on to describe various breeds as being either influenced by wolf lines or jackal ones. This apparently influences: the period of the dog’s life when the dog is susceptible to “sealing of the bond” between dog and master (Wolf dogs are earlier and the seal is much stronger); loyalty to the pack, and therefore human pack-leader (Wolves win; jackal dogs will love anyone); “child-like dependency”/”infantile affection”/playfulness (jackal dogs stomp wolf-like dogs); submissiveness (wolf dogs never fully submit); and “monogamous fidelity” of the female to male (wolf dogs win here too).

It’s kind of unfortunate that this dichotomy of dog behavior doesn’t pan out in accepted current science. If accurate, it would give us some insight into dog behavior and what we can expect from certain breeds or mixes. But if the whole “Aureus dog” theory is bunk, then we never get the clean lines that Lorenz puts forth. It also tarnishes the book a bit, which is unfortunate because there’s a lot to like, in this chapter and in general. It’s at this point that I stumble across the book “Dog behaviour, evolution, and cognition” by Adam Miklósi (2007), and after Googling through it for the word “jackal”, I see the following paragraph (emphasis mine):

The living species of Canidae might present different behaviour mosaics which are the most successful in their present environments. Thus comparison of dogs with the present-day wolf, their closest genetic relative, might be too restrictive because since the species split modern wolves may have adapted to a different environment, and the ancestor wolves could have represented a different mosaic pattern of behavioural traits. Lorenz (1954) might have been wrong about the actual ancestors of dogs but he could still have had a good eye for picking out those features of dog behaviour that are not present in the wolf but in other species of Canis.

I guess Miklósi’s sums it up best: Lorenz might have been wrong about the ancestors of dogs–the heritage just isn’t there–but there is plenty of behavioral overlap between wolves, jackals, and dogs, enough to trace behaviors from the dog back to these other relatives. I’m left thinking that my hunch was right, but also that the science just isn’t so clear cut. We also shouldn’t discount Lorenz’s chapter (or Routledge, the publisher) based on a small inaccuracy.

I want to conclude by pointing out two good pieces of King Solomon’s Ring. The first concerns dogs. Lorenz states that the value of the dog to human is psychological, that the dog can re-connect us to nature, and that most pedigree dogs can’t provide “a natural being with an undistorted soul”. To this, I couldn’t agree more. Lorenz concludes the chapter:

Let us admit this and not lie to ourselves that we need the dog as a protection for our house. We do need him, but not as a watch-dog… In the almost film-like flitting-by of modern life, a man need something to tell him, from time to time, that he is still himself, and nothing can give him this assurance in so comforting a manner as the “four feet trotting behind”.

The second highly respectable piece comes in the final chapter in which Lorenz compares man with his socially developed external weapons to animals with biologically evolved innate weapons and inhibitions. The animals with these weapons have also evolved inhibitions which prevent them from recklessly destroying one another, while we have evolved nothing like that. The comparison with animals reveals something so human about us that it shocks us. And it reminds us of the value of watching nature.

Sources:

• http://en.wikipedia.org/wiki/Origin_of_the_domestic_dog
• http://en.wikipedia.org/wiki/Gray_Wolf#Relation_to_the_dog
• http://en.wikipedia.org/wiki/Dog#Taxonomy_and_evolution (some thoughtful readers might be noticing a taxonomy issue in Wikipedia here!)
• PBS’s Nova: Dogs and More Dogs – http://www.pbs.org/wgbh/nova/transcripts/3103_dogs.html
• Dog behaviour, evolution, and cognition, Adam Miklósi, http://books.google.com/books?id=EUrXahLxUL8C
• The Princeton Encyclopedia of Mammals (2006) by David W. Macdonald (Editor)
• King Solomon’s Ring: New Light on Animal Ways by Konrad Lorenz, published by Routledge (2002)

Dog behaviour, evolution, and cognition

By Adam Miklósi, Ádám Míklósi

Mixing the conceptual with the procedural

While revising some content marked up with DocBook this week, I’ve become increasingly concerned that mixing conceptual and procedural (task-based) information in the same topic is rather perilous. You probably can’t reuse it again; there’s no evidence that answers to specific questions will be findable for users; and it’s just not “clean”.

But what’s enticing about mixing the two is that it seems like you can pull it off just by writing well. Start with conceptual description of the system and what you can do with it, sprinkle in some procedural instruction where appropriate, and make sure it’s all cohesive. After all, isn’t that how technical books are written?

But is it near impossible to make this work?

Example: a section of a users guide describing “ordering constraints” (this problem-solving step comes before this problem-solving step) in an intelligent tutor and how to author them. I wrote:

In a tutorable activity, you may want to specify which problem-solving steps come before other steps. In what order (if any) should the correct steps be completed by the student?

You can specify ordering constraints in CTAT by grouping steps, and specifying whether each group of steps can be completed in any order or sequential order. Using these basic tools, you can construct complex step-ordering constraints.

So far, so good. Now let’s try to say something about showing the windows needed to visualize these ordering constraints. Now let’s return to the conceptual discussion, and introduce and define some more concepts, then describe how to set those options. (Just writing this now, I’ve realized I didn’t actually write about how to set those options.)

Is this approach effective?

I don’t know. I don’t have any direct evidence that it’s not effective, if that means anything.

I guess the main concern is findability, which is a big issue with the HTML version of the documentation I’ve created. The typed-topic camp (topics are either task, concept, or reference) might argue that users don’t like the mix of tasks and concepts, that they have a goal in mind but the text doesn’t clearly show which part might help them. But as long as tasks are visually distinct in the text, I’m not sure I see the harm. The typed-topic approach is exemplified in the Eclipse documentation: browsing the documentation from its table of contents reveals a concept-task-reference organization. Do people think in that way? I’m unclear about a concept or I’m attempting a task but I don’t know what to do or I need to know about a single preference and what it means. My guess is that people might actually think that way, but they don’t use the terms “concept”, “task”, or “reference”.

So to go back to my original question: have I been perilous in mixing the conceptual and the procedural in a thematic topic? It’s perilous only if the risk is great. I’d define the risk as 1) failing to help users, and 2) failing to achieve reusability later on. These could be pretty big risks. I can’t say anything about reusability yet, as I haven’t attempted to compose something new out of old pieces. Do these documents fail to help end-users?

I guess I need some data.

delicious at 1,000 bookmarks

So I meant to write something—or at least just stop and think—about my use of delicious when I hit the 1,000-personal-bookmarks milestone. Like a car odometer rolling to another power of ten, this event seemed important. Well, it did before it happened, but then I rolled right past 1,000 without even noticing, which summarizes my use of delicious pretty well: I drop stuff in the bucket but rarely retrieve or think about it.

Given that I rarely search through my old bookmarks, I’m not sure why I continue to save things on delicious. Maybe I’m afraid of losing things. Or maybe I just like the idea of looking at my tag cloud, a bottom-up visualization of my interests.

I have the Firefox addon, and I use it to search my bookmarks once in a while, so it’s not completely accurate that I never look at my bookmarks again. It’s only mostly accurate. I don’t manage my tags, and I haven’t created a tag “bundle” in at least a year. I like the social aspects of delicious: I subscribe to a few bookmark streams of other people I know, and I look at the “popular” bookmarks on delicious every day or so (although the topics of which are usually very geeky or obscure).

I think I’m just more into the idea of delicious than anything else. I like the idea of putting all of my bookmarks in one place. I like the idea of not losing things; and storing them is free. But there is no practical, every-day use of delicious that is really crucial. My one buddy thinks Yahoo! is dropping the ball by not integrating delicious with all of their services. He might be right, but it’s not like I spend that much time in Yahoo! web applications anyway. I’m absolutely enamored with the delicious redesign, but I don’t think that’s why I keep bookmarking.

So happy 1,000 entries, brett’s delicious account. Maybe you’ll make something of yourself someday.

DocBook is not making my life easier

DocBook might be a great vocabulary for describing technical content, but the HTML output produced by its style sheets leaves quite a lot to be desired. Granted, they work, they’re free, and they get your content into a suitable format for publishing (web, print, online help, etc); but tweaking that output format is a doomed process.

My experience is primarily with the XHTML stylesheets. What could be simpler than XHTML? Sure, there are some hazy areas, points where you as the style sheet author need to make some non-trivial decisions. But in the end you should produce some clean, semantic, human-readable XHTML. Shouldn’t you?

Maybe we should start at the beginning, before acronyms ruled the earth. DocBook is a vocabulary, a big set of terms that can be applied to pieces of text. Describing a document with DocBook vocabulary adds meta-information to the text, and describes it at a fine level. In addition, DocBook provides rules for places where words from the vocabulary can be used. For example, a “section” can contain a “title”, but not the other way around. The result of applying DocBook “tags” to a document is that you have a document with semantic pieces: the world is your oyster. But only sort of, because DocBook vocabulary is only as good as the output in enables. What good is an XML document on its own? Besides some altruistic notions–maybe someday, someone will write an application that creates a really cool visualization using your data–the value of this marked-up technical document is very little; that is, until it’s transformed into an output format like HTML, PDF, or JavaHelp–online and print formats that people can see and use.

That is the background. The current state in the trenches is that DocBook produces shitty XHTML. Div-itis–<div> elements that are meaningless wrappers for yet more <div> elements–is rampant. Then DocBook presumes that although it’s creating the HTML, these pages should be mini-sites on your web site. By this, I mean that the pages it creates are complete HTML documents that lend themselves to being customized as complete HTML documents.

And all of this is disappointing because I want to like it, and I want to use it. I want to mark up my text in DocBook so I can provide the JavaHelp format from our Java application and XHTML on our website–from the same source. That’s actually a really useful endeavor (for those non-believers).

And then there’s customization. All would be well if the path to customizing DocBook output was transparent, simple, and natural. It’s none of these. You customize the output with XSLT parameters, little on-and-off switches that control the nature of the output. Maybe some CSS too. But with shitty markup, what’s the point? It’s an uphill battle.

These are all complaints. What’s the way forward? I think we need a collection of resources for making good XHTML from DocBook source. I’m thinking of something more than a token wiki page, but less than a web site. We need a collection of best practices (plus a showcase of them in situ); useful and reusable customizations; and recipes for creating things. And you shouldn’t need to know XSLT to get the desired effect! No more scouring parameter documentation and email list archives.

Who’s with me?

Putting Thunderbird 2’s new tagging feature to work

The question of the moment: researcher or practitioner?

Both roles (jobs) appeal to me. I’m currently practicing the latter, but I’m at a crossroads nonetheless.

Can I be both? In parallel? Serially? If serially, in what order? If in parallel, in what way?

What will make me (most) happy?

At this point in my life, I can’t imagine research as being rewarding. Maybe it’s because in practice, there is a plethora of poor technical communication and uninformed design. If shown good design, would I be content to leave design to the practitioners?

Researchers are specialized by trade. There is nothing wrong with specialization, but there is lots wrong with irrelevance, near-sightedness, and unpractical theory. Again, if shown good theory, would I be content to leave it to the theorists?

Can I be just a well-read, theoretically inspired practitioner? A practically inspired theorist? Or are theory and practice at odds?

Thoughts on ‘How Cognitive Models can Inform the Design of Instructions’ (Taatgen, Huss, and Anderson 2006)

What I read: Taatgen, N. A., Huss, D., & Anderson, J. R. (2006). How cognitive models can inform the design of instructions. In Proceedings of the Seventh International Conference on Cognitive Modeling (pp. 304-309). (link)

In this paper, the authors apply an observation from a cognitive modeling scenario to the design of instructional text: computer models learn poorly with list-style instructions, so augment traditional, context-less list-style procedural instructions to include if-then instruction with good procedure titles and clear operators (conditions for doing something). I think this difference in instructional text style can be summed up less academically by saying: name the ‘task’ (eg, ‘how to modify a waypoint’), and chunk tasks appropriately.

The researchers run two studies—one with computer models attempting to perform a task, the other with CMU students performing a task. In each study, one condition receives list-style instructions, the other operator-style instructions; and in both studies, those receiving the operator-style instructions made less errors and completed tasks faster. So a clear win for operator-style instructions.

But what exactly are operator-style instructions? The paper authors only provide one real-world example used in the study, but they show other more pseudo-code-like examples. Operator-style instructions have a pre-condition—what must be perceived in the environment for the following instructions to be considered—and a post-condition—what does the resulting environment look like. They are like if-then rules—very similar to ACT-R production rules, but with the post-condition tacked on. This raises flags for me, since the rules are being given to an ACT-R cognitive model; of course it is going to do better in comparison to these procedural instructions. What’s interesting then is that the humans perform significantly better with the operator-style instructions.

The resulting advice for designing/writing text is interesting not only because it’s validated by cognitive modeling theory, but because the shift from context-less list-style text to small-chunk-size text is being practiced by technical writers in the wild; they’re already doing what Taatgen, Huss, and Anderson are recommending! These short procedures start with a condition, or more often a task (eg, “To add a new button panel:”). Are they much different than what the paper authors recommend? How can they be improved based on these results?

Overall, a very interesting read (thanks to my Software Documentation Workshop instructor). Recommended for technical communication practitioners and researchers.

Efficiency in software use

Attended a talk today at CMU by Camille Peres, Assistant Professor of the University of Houston’s Psychology Department. She explained her research on the determinants of (in)efficient software use, arguing that users acquire efficient methods by observing peers. Users then update their internal cost/benefit analysis–in which benefits are more compelling–when determining whether or not to learn the method for use in the future.

So by better understanding cost/benefit analysis, we may be able to predict “when users will and will not utilize a more efficient technique”. While I understand that there is a significant social factor–and that’s very interesting–I can’t help but be unenthusiastic about predicting efficiency in software use; so what if Joe Smith is inefficient at using Outlook?

But maybe there are implications for training and documentation that could inform my writing; and maybe (probably) this work applies to the science of learning, which is very useful. And maybe this post isn’t going anywhere. I just don’t think that efficiency is very exciting, nor does predicting it move us forward very much, especially if it’s mainly applicable to professionals using complex applications.

Maybe that’s where I wanted to end up: I don’t care much for helping professionals using complex applications. I don’t know precisely what I care about, but I know I don’t care about that. Is that hypocritical, since I’m a technical writer? I think it is. So much the better; I never professed love for and faith in the profession of technical communication. But I definitely can’t go on like this forever.

Knowing what you dislike can almost be as powerful as knowing what you like. To be continued.