- From: Mike Schinkel <w3c-lists@mikeschinkel.com>
- Date: Mon, 16 Apr 2007 03:32:57 -0400
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- CC: public-html@w3.org
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
Received on Monday, 16 April 2007 07:33:34 UTC