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

On 3/23/2014 11:56 AM, Dimitre Novatchev wrote:
> On Sun, Mar 23, 2014 at 3:01 AM, Ihe Onwuka 
> <ihe(_dot_)onwuka(_at_)gmail(_dot_)com> 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
> people.
>
> 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!
-Mike

--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--