xml-dev - RE: Less Stupid XML

[Joshua Allen <joshuaa@microsoft.com>]

Maybe two others:

* Well-defined and limited scope.

* Simplicity -- I repeat smplicity because I do not think it has to be all
that subjective.  Things like XML exist for developers to use.  Developers
are scarce and expensive, good developers are especially scarce because the
cognitive skills necessary are in cramped space at the right side of the
bell curve.  Everything that we can do to slide the bar just a tiny bit to
the left, and thus make the tools productive in the hands of more of the
bell curve, increases the pool of developers available to bless the world
with that technology's capabilities.  In other words, if you make a
technology simpler, you more than linearly increase the amount of people
thatr can harness it.  Simplicity is the purest form of humanism.  Now, how
do you measure simplicty?  Simple!  If you want to know if alot of people
can quickly become productive with your tool, do some usability testing!  If
only people with the IQ of people on this list to use the tool effectively,
it's too complicated.  I mean, these things are meant to be used by real
people, right?  I think some of these activities would do well to first
define exactly who their target demographic is, figure out how to usability
test against that demographic, and ruthlessly focus on that demographic --
and not the priests and clergy interested enough to download and play with
the specs.

(well, something like that :-))

> -----Original Message-----
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: Thursday, October 05, 2000 12:52 PM
> To: xml-dev@lists.xml.org
> Subject: Less Stupid XML
> 
> 
> Taking Dvorak to a different level.  We 
> know that XML works fine applied well, 
> and that folks like Dvorak, and really, 
> most users, should not be aware that it 
> is there.  He is complaining like a shocked 
> monkey usually does: by showing his teeth.
> 
> Simplicity and complexity are terms often  
> used to beat up solutions we don't like, 
> or worse, don't own.  So what are some 
> other terms we might use to describe 
> qualities of good XML design.  Let me toss 
> out three:
> 
> 1.  Transparency - the quality that the 
> designer and or the mechanism is invisible. 
> In art, say songwriting, this means that 
> the song when listened to, reflects the 
> listener and not the singer or songwriter.  
> Shakespeare is considered phemomenal because 
> you learn so little about him studying his work. 
> In fact, we know very little about him.  A good 
> XML-enabled site should do that do.  When 
> I see a business site, I want to see  
> the business, not XML savvy.
> 
> 2. Coherence - the quality of a signal that 
> it transmits the longest distance with the 
> least attenuation.  See LASER.  When we begin 
> to work with XLang, we will finally see the 
> ultimate application of extensibility.  We 
> begin to use enterprise modeling to create 
> long term transactions.   Consider these the 
> macro level of what we do in the business objects 
> with ACID properties.  In effect, we hierachicalize 
> the business process such that within it, each 
> process opens and closes correctly and can be said 
> not just to be, well-formed, but well-performed. 
> 
> My intuition (with some ancient work to back it up) 
> is that the quality of coherence is important.  There 
> will be patterns in these processes that scale 
> and produce mutually reinforcing patterns.  Thus, 
> what we will see in coherent systems will be their 
> ability to propagate for very long terms without 
> loss of information.  Orchestration will depend 
> on achieving coherent presentation and navigation. 
> It is a hierarchy of feedback systems, each 
> enabling events to open and close such that no 
> event transits a view dimension unpredictably.  
> Be aware of hidden couplers.  They resonate and 
> create interference patterns that look like noise 
> or distortion in the image. 
> 
> On the other hand, it is precisely such patterns 
> that create images and these are very useful for 
> seeing around the shape of the thing.  This is a 
> hint to those who are working on using XML/XSLT 
> for visualization tools.
> 
> 3. Predictable - In short, Don't Shock The Monkey. 
> If the monkey is shocked, it reacts unpredictably. 
> VRML navigation has this problem and we are working 
> to solve it.
> 
> Mammals meet surprise with hesitation.  If we want 
> a transparent and coherent system, we have to make 
> sure the ear is satisfied with a certain amount 
> of predictable repetition over innovation.  (that is really 
> at the heart of dvorak's dilemma).  If you must 
> shock the monkey, be sure of the reason for it.  
> Usually it is to wake the monkey up because the 
> predictable experience put them to sleep.  In these 
> cases, better bananas than bees.  Paul Grosso 
> told me once about the principle of least surprise, 
> and it is the heart of the matter.  It isn't the 
> same as consistency, by the way.  You really do 
> have to wake them up to get them to listen. 
> 
> Which is also probably why Dvorak shocks this 
> tree from time to time. ;-)
> 
> Len Bullard
> Intergraph Public Safety
> clbullar@ingr.com
> http://www.mp3.com/LenBullard
> 
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h
>