Re: Proposing <indent> vs. <blockquote>

Mike Schinkel wrote:

> The problem there is it is a complex question so how does one accurately 
> design a usability study whose results would be valid?

That's really a question for a usability academic.

> I think the very fact that no tools except text editors are available in 
> all environments where HTML is applicable argues strongly that HTML 
> should be designed with a strong leaning towards hand-authorability.

That's not true. When you're faced with a WYSIWYG editor on a blog or
CMS, you haven't got a text editor available to you. When you're using a
symbolic editor, you might have a text editor available but not have the
ability to use it:

http://www.csun.edu/cod/conf/2002/proceedings/220.htm

And even if text editors were available everywhere, it wouldn't follow
that they'd be the most widely chosen or the most fit for purpose. So I
don't think that's a strong argument.

> Maybe a good idea, but it would be extremely vast in scope and hence and 
> hence wonderfully expensive.

Yet even a little testing might prevent a lot of expensive usability 
problems later on.

>>> But I do have anecdotal evidence that the languages that have been 
>>> easy to hand code have gained more rapid adoption.  RSS vs RDF, HTML 
>>> vs SGML, Visual Basic vs. C++, Python vs. Perl, for example.
>> I think the problem with this is that what may hold true for developers
>> programming does not necessarily hold true for ordinary people writing
>> web content. My experience of recommending text editor authoring over
>> WYSIWYG to everyone who asks on the basis that WYSIWYG tools are
>> fundamentally broken suggests that ordinary newbies generally prefer
>> WYSIWYG and consider text editor authoring to be scary "programming".

> You are looking at today, not 10 or 15 years out.  Many of those people 
> who view it to be scary will be retired, and many of the kids who cut 
> their teeth on computers will be using HTML.

a) HTML-next is supposed to be finalized in 2010, not 2022. ;)

b) Retired people will want to author HTML too.

c) I see no reason to believe people will accommodate themselves to text
editors, but not to semantic markup.

d) That's plenty of time for the development of editors that are neither
text editors nor WYSIWYG. In 1992, the web was in its infancy and most
people were still using textmode word processors like WordPerfect 5.1
for DOS.

> But fundamentally, tools constantly change as vendors get bought or 
> morph, new products constantly emerge, and we never get to a "perfect" 
> tool. 

Nor a perfect markup language.

> A language as fundamental as HTML shouldn't be designed that it 
> *requires* a tool beyond a text editor.  Tools should be viewed as 
> beneficial but not a requirement.

A language as fundamental as HTML shouldn't require a text editor
either. A text editor is not a baseline any more than a text browser is.

> Over time, the number of people willing to be hamstrung my a requirement 
> for tools will be less and less. 

What makes you think that?

> Tools will be beneficial, but they add a layer of complexity on top 
> of text that should be able to be peeled away because I doubt anyone
> will  ever be able to build a WYSIWYG tool
> that will be available in all environments and will meet the needs of
> all users.

Neither WYSIWYG editors nor text editors meet the needs of all 
users.HTML (the language, as opposed to the social movement surrounding 
it) should ultimately be tool agnostic, but it should also meet the 
needs of common existing tools: text editors, Wiki/BBCode 
transformations, somewhat-less-broken WYSIWYG editors.

>> This remains true of many web professionals and people commissioning
>> small retail websites. I doubt it's an accurate characterization of the
>> "common" authors of social media.
> I don't follow who you are referring to.

I thought by "'common' authors" and "social media" you meant bloggers, 
forum posters, and user-generated content producers.

>> Web accessibility issues are a novelty
>> to most of the ordinary people I speak too. They don't know what screen
>> readers are, for instance; some express surprise that blind people can
>> use the web at all.
> Exactly. Until you people actually experience the need, most will never 
> even consider it.

Actually, the ordinary people I meet don't have to experience the need
themselves, only to be made aware that other people have such needs.

> So we need to make accessibility come as close to "free" as possible.

This is always a good principle. :)

> You don't get it!.  You don't have the ability to make that choice for 
> them; they will make their own choices no matter what you think.  If you 
> want to make things better you need to accommodate the fact people will 
> do what is easiest, accessibility be damned. Make the easiest thing the 
> most accessible thing and accessibility wins a lot.  Make the easiest 
> thing less bad and accessibility wins a little. That's what I'm proposing.

How would <indent> make "[m]ake the easiest thing the most accessible
thing"?

> Again, it is better to have an unknown than a known that is misused.  I 
> still don't think you've addressed that (at least not thus far in my 
> reading of your replies.)

I recognize that principle. I just think we need to be careful in our
choice of generic elements, and doubt <indent> would be a good choice.

>> 100% accessibility is an ideal not a target, but I certainly believe
>> that mass accessibility is reconcilable with widespread authorship and a
>> sine qua non of mass authorship.
> Can you provide any support for this belief?

Give people the tools and patterns to create accessible content, and 
it's no longer rocket science.

>> Semantic markup that common authors aren't going to use doesn't 
>> particularly interest me (I recognize TEI and MathML have their places 
>> in specialist circles, but we're talking HTML here.)
> What semantic markup are you referring to here?

/Anything/ which will be ignored by most authors in favour of catch-all
presentational equivalents.

> But you still want to control things, and I'm saying it's better to 
> loosen the reigns and empower people. Given the constraints but no so 
> much that they suffocate.

Equal access is part of empowering people.

>> And that's how HTML was designed. By contrast, Flash was designed for 
>> animations.
> Although I'll give you Flash, I'm pretty sure HTML was designed for 
> both. 

The web was certainly intended for hypermedia as much as hypertext:

http://www.benjaminhawkeslewis.com/www/history/text-only-www

But /HyperText/ Markup Language wasn't designed for animations.

> Two websites from professional bloggers do not make a statistically 
> accurate point. I could easily find two counterexamples, but it would 
> prove nothing.

Actually Glenn Reynolds is supposed to be a professional law professor.

Anyway, it still shows that /some/ ordinary authors do use some semantic
markup, and I could easily accumulate examples to show that /many/
ordinary authors do so. At which point the truly difficult and
interesting question becomes, why do some ordinary authors do so, and
some not? Is it because of the different tools they use, for instance?
How far is it about shared approaches to technology in particular social 
networks?

>>> A wiki is a perfect example of the kind of problem that occurs! Look 
>>> at Mediawiki's syntax; it's so complex now as to be overwhelming.
>> At least in the case of Wikipedia, that's largely because there's more
>> than one way to do any one thing. That's another reason not to introduce
>> <indent>.
> Not really. Are there multiple ways to do bold?  Underline?  Italics?  
> And the big one: tables?

Yes indeed:

http://en.wikipedia.org/wiki/Help:Table

But I was more thinking about:

http://en.wikipedia.org/wiki/Wikipedia:Citing_sources

> Better to simplify basic HTML and have only one markup language for people to 
> learn rather than tens or hundreds of obscure ones.

Perhaps we need a formal separation between  HTML for streams of text 
(e.g. comments, articles) and other uses of HTML (forms, image maps 
etc.). Or a way of specifying particular subsets for input and textarea.

>> But perhaps the way to combat individual web user powerlessness against
>> companies is to begin to organize corporate action. I've been thinking
>> recently that many inaccessible sites remain inaccessible because the
>> people experiencing the problems don't have the technical skills to
>> identify and articulate problems and solutions, and wondering if
>> creating a bugzilla where reports could be refined before being mailed
>> to webmaster would help. Even a template email where users report what
>> OS, browser, and assistive technology they are using and how what
>> happens differs from their expectations, and which provides links to WAI
>> and other resources, would help.
> Good idea, but who would implement?

Possibly me, if I can find the time.

> Bringing up a suggestion I made on another forum, things would be a lot 
> better if IE would display a green icon for valid HTML and a red one for 
> invalid HTML so validity would finally become "visible."

A happy face and an unhappy face would be more accessible (something 
like one tenth of American males can't easily distinguish red and 
green). I put this suggestion on the MS bug tracker before they shut 
that down.

The HTML Validator extension for Firefox shows how this can be done:

http://users.skynet.be/mgueury/mozilla/

Björn Höhrmann actually started work on a toolbar equivalent for IE a 
long time ago:

http://ieqabar.sourceforge.net/

>> How is representing "the full set of HTML", rather than the /relevant/
>> set of HTML, a useful goal?
> Who defines relevant?

Various people: non-technical users by choosing editors and logging 
requests for enhancement on public bug trackers, geekier users by 
scripting editors, and uber-geek users by coding editors.

> People learn from view source.  People often discover how to fix broken 
> links with view source. 

Technical people, but I suspect not ordinary folk.

> People discover ids (for URL fragments) with view source. 

Judging by the tools we're making, we both recognize how broken /that/
non-interface is.

> View source is one of the many powerful reasons why the web 
> has been such a success. Just because most people won't use it doesn't 
> mean it should be dismissed.

I didn't dismiss it. I said it's irrelevant to most people ("common
authors").

>> I think <indent> would be detrimental to source view. I find semantic
>> elements buried in presentational soup extremely difficult to read. It
>> gives me headaches trying to untangle the stuff.
> Here's where you and I disagree.

Really? Is your head some sort of mirror universe version of mine, such 
that when you spot semantic markup like <blockquote> you feel the need 
to find an aspirin while <center> fills you with inner peace?

>>>> 1. HTML is about what you mean (content/semantics), not what you see 
>>>> (presentation).
>>>>
>>> If that is actually completely true, then we should eliminate ALL 
>>> default presentational behavior from ALL elements (p, h1..hn, 
>>> table/tr/td, ol/ul/li, etc.)
>>
>> That's a non sequitur. 
> Is it really?  You said "HTML is about what you mean 
> (content/semantics), not what you see (presentation)"  If it is not 
> about what you see, why shouldn't we remove ALL default presentational 
> behavior?
> Honestly, I asked the question to trap you. It is not a non sequitur 
> because if your assertion is false, i.e. that presentation should not be 
> part of HTML then your arguments against presentation do not hold.  You 
> can't have it both ways.

Basically presentation is a function of user agents plus stylesheets. 
User agents can do what they like in terms of default rendering.
The use of W3C providing default stylesheets would be so that designers 
can build on them, expanding the elements of a design that they care 
about without having to zero down than build again from scratch.

> The problem is you can't get common semantic ones for every use-case, so 
> you need catch-alls for those that don't fit. Over time we can identify
> new common use-cases and there will be less and less need for 
> catch-alls, but the need will still be there.  It's why we database 
> developers put a "Notes" field in most entity records to give users a 
> place to put stuff that doesn't fit elsewhere.

I think HTML already has the equivalent of "Notes" in the form of div, 
span, and class. Possibly RDF roles might make such extension mechanisms 
a bit more machine-learnable, but we'll see.

The use of class in this way proved important to how new elements were 
developed for the HTML5 draft:

http://code.google.com/webstats/2005-12/classes.html

> Well, I believe people won't learn semantics until there is some visual 
> benefit they get out of it.  That's why I hope to achieve with Toolicious.

A lot of people already are using basic semantics; tools will help even 
more people join them.

> But expecting tools to solve these problems is a Faustian bargain as you 
> can't depend on the tools to be available. That's why raw HTML needs to 
> be designed to address the problem.

I think we need both.

--
Benjamin Hawkes-Lewis

Received on Tuesday, 17 April 2007 22:15:24 UTC