Benjamin Hawkes-Lewis wrote:
Since helping authoring tools is now within its remit, should not the
Working Group conduct some actual usability testing with ordinary people
from different constituencies and with various abilities (e.g. geeks who
aren't web professionals, technophobic newbies, political bloggers,
MySpace users, people with visual or mobile or learning disabilities) of
different authoring forms? It is impossible to settle the question of
whether there are better models for web authoring than WYSIWYG or text
editor authoring without first developing tools exploring such models.
The problem there is it is a complex question so how does one
accurately design a usability study whose results would be valid?
But we could at least assess how easy people really find using HTML with
current WYSIWYG and text editor systems (and learn how to make both
easier and produce superior markup).
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.
In addition, should not the Working Group conduct some actual usability
testing for each feature, or at least each new feature, in HTML5? I do
not believe that simply dumping features on the World Wide Web
constitutes usability testing of any meaningful sort, since HTML
features are filtered through crass educational systems (e.g. w3schools,
MSDN, the dire deadtree books people learn HTML from), broken user
agents (e.g. the sorry fate of <q>), broken CMS (e.g. generating invalid
and oft inaccessible HTML), and broken WYSIWYG authoring tools (e.g.
misuse of <strong> for the [B] (bold) button).
Maybe a good idea, but it would be extremely vast in scope and hence
and hence wonderfully expensive.
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.
But fundamentally, tools constantly change as vendors get bought or
morph, new products constantly emerge, and we never get to a
"perfect" tool. 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.
This even holds true with newbie visually impaired authors, who I'd have
thought would be a natural non-technical constituency for text editor
authoring. See for example:
http://www.gwmicro.com/Support/GW-Info_Archives/index.php?postID=10515
http://www.freelists.org/archives/nvda/04-2007/msg00215.html
Over time, the number of people willing to be hamstrung my a
requirement for tools will be less and less. 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. This is such a
fundamental principle I find it hard to even discuss it; To me it's a
lot like a postulate; something that is so obviously true that its
proof is difficult if not impossible.
most authors don't care about accessibility because it is a lot more
"costly" to develop accessible content than not. Most authors
implicitly make a cost-benefit decision and chose not to address it.
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.
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. Sad, but true. So we need to make
accessibility come as close to "free" as possible.
<blockquote> misused is less accessible than <indent>
I don't think people's desire to format text should take priority over
everyman accessibility issues.
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.
If newbie authors need to understand one
thing above all others, it's that HTML is about what they mean not
WYSIWYG.
Newbie authors don't NEED to understand anything. They will
understand what they will, your opinions be damned. What YOU need to
understand is this reality, and that to improve things you have to
cater to them.
I think supporting "visual appeal" within HTML itself makes the language
harder to use for both authors and readers.
I'll say again, it's not what you think that is important, it's what
people will do.
And anything that even sometimes "mean[s] something" must /not/ be
ignored by assistive technology.
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 regard inline styling as a detrimental practice. But I don't seek the
style attribute's deprecation from HTML. Ruby on Rails is successful
because it is "opinionated software": it makes good practices trivially
easy without making "bad" (but conceivably /useful/) practices
impossible; I believe that is a good model for HTML 5 to follow.
That sounds like an argument for <indent>...
BTW, don't get me starting on Ruby on Rails. ;-)
I'd prefer W3C provided demonstrable use-cases with
new (preferably semantic) elements /before/ said use-cases pollute the
web with misused markup.
Frankly, I'd prefer a lot of things but we have to work with what
"is" and not with what we'd like.
XHTML 2's roles module, the microformats movement, and WHATWG's aim
of making HTML5 forwards compatible are all attempts to meet this need.
As an aside, I think the microformats movement as is is destined to
create far more problems than it will solve. JMTCW
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?
And the misuse of <blockquote> is a perfect example. The irony is
I'm arguing for an <indent> with no semantics (or something similar)
for the exact reason you are arguing against it; to improve the
quality of semantic markup on the web!
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?
And if it wouldn't communicate anything, than why would we want
common authors using it?
You know, doesn't that sound a bit "Big Brother-ish?" ;-)
Not really. Big Brother was all about shutting down thought. I want to
prevent the free flow of ideas being hindered by styling misused to
express ideas in ways that everyman (i.e. almost every person) cannot
understand.
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.
HTML isn't designed as a medium for visual self-expression, unlike
Flash for example.
It isn't? I feel like I'm expressing myself every time I use HTML.
What am I missing?
But you're not /visually/ expressing yourself (to me) when I view your
blog in Lynx, fire it up in my mobile browser, apply a user stylesheet
to it in Firefox, or have Opera read it to me. And that's how HTML was
designed. By contrast, Flash was designed for animations.
You may use Lynx, and you may apply a user stylesheet in Firefox or
Opera, but most people don't. And I'm expressing myself to the vast
majority of people when I write in HTML, not the outliers. And I'll
bet the vast majority do the same.
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. OTOH, I think you would have liked for it to be designed
without visual aspects, but reading "Weaving the Web" that's not what
I read. And that's not what has happened. For the most part HTML is
about pragmatic publishing of information which includes both
semantics and presentation.
Our odd culture of formatting HTML differently on every site and
providing a hideous default presentation
Our culture? I'm confused. Isn't it user agents that render, not
people? Do user agents have culture? Do androids dream of electric
sheep?
I meant the (human) culture that creates styled content and
develops and chooses browsers to view it.
Besides me really being confused by your comment, I was hoping you'd
catch my subtle cultural reference. Too bad, I think it was a good
pun. :-)
has been far more burdensome on ordinary authors than semantic
markup has.
Semantic markup has not been a burden because the authors do not
see it, so they ignore it.
The evidence is against the notion that ordinary authors don't use
semantic markup. Consider the front page of a popular American political
blog:
<snip>
If authors do not "see" this markup, it is because they choose WYSIWIG
tools over text editor authoring and do not see /any/ markup at all.
Two websites from professional bloggers do not make a statistically
accurate point. I could easily find two counterexamples, but it would
prove nothing.
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?
I've actually thought a lot about this, and if I had a platform to
make changes I would be advocating that we get rid of wiki syntax and
just get everyone to understand HTML. That way they could learn it
once and be done with it. Of course HTML would need to become a bit
easier to hand-author.
More like a /lot/ easier - starting with the need to encode ampersands.
That I don't debate. But the problem is any markup language used to
simplify HTML ends up becoming increasingly more complicated as its
evolution forces it to approaches HTML's functionality. Better to
simplify basic HTML and have only one markup language for people to
learn rather than tens or hundreds of obscure ones.
I suspect the business case for accessibility is stronger than most
people realize. Also, by raising the spectre of litigation, tightening
accessibility laws are strengthening it still further.
Again, I support your goal. We just disagree on how to get there.
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?
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."
On the flipside, give me ONE, just ONE HTML editor that can represent
the full set of HTML w/o switching to a source..
How is representing "the full set of HTML", rather than the /relevant/
set of HTML, a useful goal?
Who defines relevant?
One of the biggest problems with the "TOOLS WILL SAVE THE WORLD"
mindset is that each tools is only available in a subset of the
contexts where HTML can be used, yet text editors are available in
100% of the contexts where HTML will be used. This is the
insurmountable reality that the toolset mentality can never address.
AND, you are ignoring the benefits of the "view source" effect.
Hand-authorable HTML is also a lot more readable.
I don't object to hand-authorable HTML at all, but only to the notion
that HTML is /best/ authored by hand.
I don't think it is best authored by hand either. But I think it
should be *able* to be hand authored as a primary requirement. Not
having this as a requirement ends up giving rise to justifications
for overwhelming complexity with rationalization like "Don't worry,
the tools will handle it." That's what the primary author of XBRL
told Jon Udell when Jon complained of inability to author XBRL by
hand. Jon believed that the inability to author XBRL by hand was to
XBRL's detriment. And I wholeheartedly agree.
And because I think hand-authoring
HTML in a text editor is a technical task, I don't think the "view
source" effect has much relevance for common authors like bloggers and
forum posters who tend to choose WYSIWYG tools.
People learn from view source. People often discover how to fix
broken links with view source. People discover ids (for URL
fragments) with view source. 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 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.
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.
What I'd like to see is authors writing semantic
HTML and user agents rendering all features of that HTML in a consistent
(at least within a single user agent), beautiful, and understandable
manner by default. Ordinary authors wouldn't have to worry about CSS.
Web designers could continue to use CSS. I'd like to see W3C produce
suggested stylesheets containing default presentation for all elements.
Web designers might wish to use those stylesheets as a base, so they
don't have to specify everything from scratch. I want the pain taken out
of web authoring.
I actually agree with all of that, which is why your dislike for
solving the misuse of <blockquote> so surprises me.
You seem to be want to turn HTML into a presentational language
You seem to misread my intentions. I don't want to turn it into a
pure presentational language any more than I want to pure semantic
language. I want to address most common use cases in a pragmatic way.
(or at east provide presentational alternatives to semantic
elements, which amounts to practically the same thing).
Your assertion that they are the same does not make it true.
What I mean is that creating presentational elements that could be used
instead of semantic ones will leave the semantic elements largely unused
by "common" authors, so they might as well not exist.
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.
And I am saying we first make it hand-authorable with a text
editor, THEN we build those tools. Doing otherwise, therein lies
madness; believing that we can use tools to hide too complex markup
will lead us down a sordid path from which we cannot recover.
No objections here but: my experience is that semantic markup produces
simpler markup every single time.
I'm not sure I disagree, but how do you deal with the things were
nothing quite fits? Currently HTML has many cases where things just
don't quite fit.
* HTML should be pragmatic, not ideological
In the absence of concrete distinctions this is fluff, but I think I
agree.
One concrete example is <indent> vs. no <indent>!
(Not necessarily for newbie authors, but that's not the same thing.)
Can you define your distinction between common and newbie authors
as I believe many of the former are the latter?
Fair point: newbie authors are properly a subset of common authors. What
I was getting it is this: newbies may initially find writing with
semantics confusing, just as once people found writing with WYSIWYG
interfaces confusing. But once familiar, semantics make writing much
easier. As social media uptake spreads and semantics becomes as
culturally familiar as WYSIWYG, this obstacle will cease to
exist - unless we occlude semantics with broken WYSIWYG tools, which is
what is in fact happening.
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.
Anyway, I love <sic> the "encourage people to have better habits"
solution mindset.
Well, when I say that I include empowering people to do the right
thing by giving them the right tools for the job and taking away
the features that lead them astray as a /necessary/ component:
evangelization alone is not enough.
But an abstinence/prohibition stance is not workable either.
The operating idea here is that people abuse markup because they want to
achieve presentational effects. While this is obviously commonplace, I
think it often points to an underlying desire to express a semantic to
which HTML authoring tools do not properly cater. If authoring tools had
dropdowns for "Foreign phrase..." (using <span lang="whatever">) and
"Book title" and "Movie title" (using <span> with hCite), I think a lot
of <em> abuse would disappear. If tools offered even more functionality
around such features, such as reading your text with the correct
pronunciation or inserting (say) Amazon and IMDB links automatically,
then abuse of <em> might disappear from new content almost entirely.
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.
--
-Mike Schinkel
http://www.mikeschinkel.com/blogs/
http://www.welldesignedurls.org
http://atlanta-web.org - http://t.oolicio.us
