[uf-discuss] human and author friendliness

[Tantek Ç elik]

On 11/9/05 3:24 AM, "Danny Ayers" <danny.ayers at gmail.com> wrote:

> On 11/8/05, Karl Dubost <karl at w3.org> wrote:
> 
>> May I disagree but in a gentle way ;) More pushing forward than
>> disagreeing in fact. I think microformats as HTML are not author
>> friendly. The only way to make that _really_ friendly is to have
>> template engines to edit the content and not see the source code. For
>> example, the good thing when I use my Address Book application is
>> that I don't have to view the coding behind. Binary, XML, whatever is
>> the encoding is not my issue, as long as I can type in these little
>> form the information.
> 
> Yep, I think this is a fair point (again in a gentle way ;-)
> 
> HTML may be a lot easier to hand-author for many people than other
> formats, but that isn't saying much.


I will also partially agree and partially disagree in a gentle way ;)


A few points:


1. Danny is correct about "easier to hand-author for many people".  Emphasis
on the "easier".

Karl's statement:

>>microformats as HTML are not author friendly.

makes a common assumption (which I am not sure he meant to make / state, so
I am criticizing the statement, not the author ;) which is inaccurate.

The common implicit assumption is that "author friendliness" is an absolute
attribute which something has or doesn't have.

This is incorrect.

Methods for authoring content are more / less author friendly compared to
other methods.  It's a range, a spectrum, not a boolean absolute of author
friendly or not.

Karl also makes the following statement which I have to again partially
agree with and partially disagree with:

>> The only way to make that _really_ friendly is to have
>> template engines to edit the content and not see the source code.

Karl says "the only way", I would say "a better way".  It's a minor
distinction, but an important one.  Again this is about thinking in terms of
a spectrum of author-friendliness rather than a single bit.


Methods that are *more* author friendly will appeal to more people.

Methods that are less will appeal to fewer.


This is why author-friendliness is one aspect of the microformat principle
of human's first, machines second.

Thus microformats are designed to be much *easier* for people to author by
hand than other formats, and thus more people will and do author them by
hand.

This seems obvious once you state it, and yet, history has certainly shown
that many (most?) people who design formats completely ignore
author-friendliness, very often because they make the false assumption that
"tools are all that matter".  Which is my next point.


2. False assumption that "tools are all that matter"

Karl wrote:

>> For
>> example, the good thing when I use my Address Book application is
>> that I don't have to view the coding behind.

Absolutely.  Having a friendly user interface to read and enter information
is much better than having to do it in code, for almost anyone I know (a few
programmer are more efficient with manipulating coded data with a
command-line than using a UI).

>> Binary, XML, whatever is
>> the encoding is not my issue, as long as I can type in these little
>> form the information.

Agreed.  For Karl, myself and perhaps 99+% of folks the user interface is
MUCH more important than the encoding.

BUT:

Who writes that Address Book application or that tool with the nice user
interface?

Typically a software developer, a human.

As a software developer who has written support for standards, and having
talked with numerous other such developers, I can tell you from experience,
that the simpler the format is, and the more author friendly that the format
is, as long as it is a "format" (i.e. not just natural language), it is
easier to:
 * implement
 * write test cases for
 * test

This is a VERY important point.

Yes of course the tools are what matter for 99% of people authoring the
content.

But, again, the more author-friendly you make the format, the more folks
will be able to write tools (or do so in less time) to support the format,
more quickly.

XFN is a perfect example of this.  Numerous tools were created within days
if weeks that supported XFN because it was so simple and easy to code.

And actually, empirically we have at least two *very* big examples of
author-friendliness *beating* tools in the market.

Example 1:

If tools were all that mattered, then the Web would be a bunch of
interlinked Microsoft Word documents, since everyone knew how to use
Microsoft Word and only a handful of people knew how to write or had tools
to write HTML when it was invented.

But that's not what happened.  HTML won over Word on the Web, and I would
posit period.  I would posit that there are more HTML pages in the world
than Word documents.

Example 2: 

Same thing, but PDF.  Again, HTML clearly trumps PDF both on the Web and in
terms of total documents in the world.

It turns out that author-friendliness is actually MORE important than having
the tools, for in the long term a more author-friendly format will have more
in quantity and more in diversity tools to author and consume it than any
binary or random XML format.

Again, this seems obvious once you put these together;

 make it easier to author content =>
 makes it easier to develop tools to author that content =>
 more tools sooner to author that content

And yet again, as history has certainly shown us, many (most?) people who
design formats completely ignore author-friendliness, very often because
they make the false assumption that "tools are all that matter".

They couldn't be more wrong.  But that's ok.  The way to prove them wrong is
not to fight them.  The way to prove them wrong is to simply succeed by
doing a better job.  Which is exactly why we are doing microformats.  To
prove by example that it is possible to do a *much* better job than those
that would design formats abstractly and in very human unfriendly ways.
Nevermind that history (Word vs. HTML, PDF vs. HTML) has already proven as
much.


3. Human-friendliness is also about considering human *behaviors* as more
important than abstract ideals or purity of abstraction.


Danny wrote:

> Without something like the templating
> Karl suggests, the "human-friendly" argument for microformats isn't
> very strong. But hopefully it will only be a short time before we do
> see good tool support.

Yes.

But this is also assuming that "author-friendliness" is all we mean when we
say microformats are for humans first, machines second.

There is a second, perhaps even more important aspect of what human's first
means, which is that both:


a) Microformats are designed based on existing *human* behaviors (see the
microformats process, researching examples etc.).  This is a very big
distinguishing feature of microformats which is often a learning exercise
for new folks joining the community who want to simply "make a microformat
version of their format" or "present a new microformat proposal".

This is *very* different from how other format efforts are done, which, from
my experience almost always are based upon some set of supposed domain
experts' opinions of what the ideal abstract models are for some type of
data.


b) Microformats are designed to *work with* and *adapt to* existing content
and content authoring systems.

This is why sites like Laughing Squid, Upcoming.org, and EVDB took *an hour
or less* to add hCalendar support to their systems, it was just a matter of
adding a few more "class" attributes, and maybe a few <span>s and <abbr>s to
their *existing content*.

Or a site like Avon adopted hCards completely organically -- without any
communication from the microformats community at all.


On the contrary, most other formats efforts start by saying, first, create
this *new* file in this *new* format as a parallel silo to your existing
content.

More often than not, this is much more work, and thus is done less often.
The successful examples of this are few and far between, and even those have
taken MANY YEARS to succeed.

We assert that being more friendly with existing *human* content production
practices, microformats are easier, less work, and take less time to
implement than other attempts to (re)create structured content.

Thus with those advantages, again, we expect *more* people to adopt and
publish microformatted content *faster* than by other means.


Thanks,

Tantek