Re: XHTML and RDF

Mark,

Your analysis of (a) and (b) suffers from the same fundamental flaw.  You
are attempting to make an absolute assessment of how high a barrier an
author will attempt to overcome, when that is essentially irrelevant, and
incalculable.

What *is* relevant is that given comparable in-demand features, solutions
with relatively lower barriers will outperform solutions with higher
barriers nearly everytime.

Namespaces in a syntax are such a barrier.

Solutions not requiring them will outperform solutions that do.

More specifically, requiring a higher barrier in a technology, that's not
necessary for the typical (90%) case, and only serves to address edge cases,
needlessly cripples the adoptability of that technology.

Technologists and academics and researchers love to design for the edge
cases, because typically there are more "interesting" problems to solve on
the edges.  Unfortunately by using edge cases as design centers, they often
neglect, and destroy, the usability of typical cases.


On 2/26/04 3:12 AM, "Mark Birbeck" <mark.birbeck@x-port.net> wrote:

> (a) Their willingness to learn
> 
> My recollection of the early days of HTML was of a real 'buzz' with
> people knocking out great web-sites using nothing more than notepad. I
> even recall that the common criticism of products like FrontPage was
> that they "messed-up my mark-up". I used to see people on the train with
> great big HTML books (and JavaScript ones, for that matter), eager to
> learn whatever they could.

And HTML wasn't the first markup technology.  It wasn't the first hypertext
technology either.

But it was the first with a low enough barrier to entry that it made sense
to try and use to substantially more people than previous solutions.

And before there were big HTML books, there were little HTML books that a
reasonably educated person could easily and quickly read and start applying.

Given a number of solutions to a problem, authors/users will opt for the one
that requires less investment of time etc. spent learning.


> (b) Their willingness to do something complicated,

Only if they must.

> if it solves a problem

If there is a simple option and a complicated option, both which solve a
problem (provide a desired good), more often than not, they will choose the
simple option (lower cost).  That's economics 101.


> These people are already working around the limitations of both the
> languages (HTML, CSS, etc.) and the implementations.

Right, even solutions with limitations (e.g. *simpler* solutions) are fine
for folks -- when they need to, they'll figure out how to work around the
limitations.


> Authors are
> delivering useful sites now, despite the efforts of us experts.

I would say many authors are now better experts at *using* these
technologies than "us experts" as you put it.  It's a direct consequence of
the difference in talk/use ratios.


> Whether
> it's working around the inconsistencies between CSS on Mozilla and IE,
> or using JavaScript to give their users powerful menus, toolbars or
> validation, or using XSLT and XPath to get more control and flexibility,
> they are certainly not 'average Joe-blow authors'.

And 15 years ago there were authors delivering content/applications in other
formats as well.

Certainly, no matter how complex you make your solution, you'll find at
least someone somewhere who is curious enough to try making it work.

Existence != adoption.


> So, I'd rather not take as our starting-point that 'the author' is
> incapable of grasping anything more complicated than a horizontal line
> and a break - let's treat them with some respect!

This gets back to the fundamental flaw that I noted at the beginning.

There is no one particular 'the author'.  There is a broad range of authors,
including potential authors.

By needlessly complicating a technology, you limit the number of folks who
will be bothered to understand and or use it.

Simpler technologies will be appealing to more people.

And even experts (especially experts) don't like to waste their time with
solutions that are more complicated if simpler ones suffice (unless they're
publishing academic papers on the subject, and then they demand sufficient
complexity to maintain their expert status).


> And if we do agree that we want better functionality for the end-user -
> and in particular we want to 'unlock' the wealth of information
> contained in HTML documents, so that the user can do cleverer things,
> faster - *then* of course we should move on to looking at how to make
> that as easy to author as possible.

Absolutely, and this is what semantic use of XHTML does much better than
typical presentational HTML, and has a fairly low barrier to entry.


> But to paraphrase ... "it should be as simple to author as possible, but
> no simpler".

The designers of these solutions are a long way from hitting that "as
possible" requirement, so don't bother with "no simpler".

I would posit that a better way to find the simplest solution, instead of
being afraid to cross into the zone of "no simpler", is to actually simplify
it until it becomes too simple, and then slowly back off one step.

Tantek

Received on Thursday, 26 February 2004 13:19:33 UTC