[xsl] discoverable design, was RE: When to use text()

Subject: [xsl] discoverable design, was RE: When to use text()
From: Michael Sokolov <msokolov@xxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 25 Mar 2014 20:39:31 -0400
On 3/23/2014 11:56 AM, Dimitre Novatchev wrote:
On Sun, Mar 23, 2014 at 3:01 AM, Ihe Onwuka <ihe.onwuka@xxxxxxxxx> wrote:
I don't want quirky arcane non-intuitive explanations.
If everything was so intuitive, then the various W3C working groups
wouldn't be working for years to design a language.

Also, the concept of "intuitive" cannot be objectively defined. What
is "intuitive" for one person often isn't "intuitive" at all for other

I believe that intuition is the result of practice and needs some
level of initial basic understanding.

I would like to supplant this striving for "intuitive" design with an attempt to attain something easier to grasp and perhaps closer to what might actually benefit people. Not that we are designing node tests any more, but we all have things to design from time to time, and have to choose names for things and so on. How should we do it? We struggle to appeal to intuition, since we don't know what intuitions others will have, and our own are so often wrong.

Instead, suppose we tried to create "discoverable" designs. By discoverable, I mean something that can be understood through trial, error and consultation, with minimal up-front tutelage or research. I'm not sure what that would look like exactly, but I feel like it's something we could grasp better than intuitive design, and which would be almost as good.

I know many people like to learn in courses, or by working through tutorials, or even by reading manuals and specifications. My experience is I seldom know what tool or system I'm going to need to study until I find myself in the middle of needing to do something with it. And in that circumstance time dictates aiming for bare competence. Mastery and deeper understanding will come with time and practice if it's warranted.

I don't think we ever really learn anything until we do it wrong, suffer a little, and correct our mistakes.

Maybe a key component of a discoverable system design is how the system behaves when a user makes a mistake, and I think a key reason why text() is so confusing to people is that it often works as expected even when the user is laboring under a misapprehension: the distinction between string() and text() may be stark to an experienced user, but to a neophyte it is profoundly subtle. In many (most?) circumstances, they appear to be doing the same thing (single text node child atomized automatically). There's no use proposing a solution to this problem (although I did like text-node()), but I do think it bears thinking about.

People often talk about the "principle of least surprise" as a way of getting at creating intuitive designs: the idea being to make things work the way people are going to expect. But as we've been pointing out, it isn't always clear how to do that, given a complex internal model that is unknown to users, and even if it were, it may even be impossible in a sufficiently complex system, since choices must be balanced against each other. Inevitably when one thing becomes easier and more obvious, something else is made more obscure, remote or difficult to apprehend.

The key point: Sometimes surprises are welcome. If the user makes a syntax error, usually by accident, the resulting error will come as a surprise. Surely this is better, for programming computers, than ambiguous syntax that attempts to make sense of every utterance.

Perhaps the trouble comes from borrowing too heavily from visual design metaphors. User interface design dictates that the user is always right: there should be no possibility of error in a well-designed graphical user interface (aside from the occasional "are you sure" barrier, or outside system errors that may intrude). But languages are different. They admit an infinitude of possible expressions, the vast majority of which are simply going to be nonsensical monkey-typing.

The best-designed languages anticipate common mistakes. In C, people so often confuse assignment "=" and comparison "==", which could often behave deceptively similarly that a compiler warning was introduced for perfectly valid expressions like if(a = 1). I remember this as an annoyance -- I had internalized the cant -- but I'm sure that warning made it easier for a lot of new programmers to pick up the same lesson. This was helpful, although many more modern designs have avoided the trap by syntax that disallows the confusion altogether (at some loss of convenience for experts).

So maybe if we fail to eliminate surprise altogether, we can strive at least not to bury the surprises under innocent-seeming default, automatic magical behaviors that mask a deeper misunderstanding. Let's avoid too much cleverness and make the surprises obvious!


Current Thread