- From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
- Date: Wed, 21 Apr 1999 08:50:41 +1000 (AEST)
- To: w3c-wai-au@w3.org
What follows is a series of comments on the authoring tool guidelines which I originally wrote as an informal e-mail message to Charles, in response to his request that I review the document. The informality is reflected in the lack of polish that will be evident in the writing style. I have chosen not to edit the substance of the comments before forwarding them, however, as I am somewhat busy at the moment, and, in any case, the remarks themselves should be reasonably clear, even if poorly written. ---------- Forwarded message ---------- Date: Mon, 19 Apr 1999 10:45:12 +1000 (AEST) From: Jason White <jasonw@ariel.its.unimelb.edu.au> To: charles@w3.org Subject: Comments on latest draft of authoring tool guidelines Charles, As promised, I have reviewed the latest draft of your excellent authoring tool guidelines. Unfortunately, my comments will be somewhat disappointing, as they do not offer easy and straightforward solutions to the problems raised. The authoring tool guidelines are very good as they stand. Congratulations are owed to you and the other editors, together, of course, with the members of the working group, for compiling an excellent document which strives to address both the user interface of the authoring tool as well as the output which it generates. The central issue that I would like to draw to your attention, which is partially addressed by the guidelines but which may require further thought, may best be described as the nature and consequences of so-called "wysiwyg" editing. As the acronym implies, it refers to a type of editing practice in which the content is envisaged by the author largely, if not exclusively, in terms of appearance, and the actual markup codes are inserted behind the scenes. This can not be simply addressed by offering an alternative, structural or markup-oriented view of the document as an option, for the wysiwyg environment and the concepts surrounding it can fundamentally determine the nature of the author's interaction with the document, especially for inexperienced developers and those who are not sufficiently familiar with HTML and its roots in SGML concepts. Thus, even though it might be mentioned in documentation that, for example, the "indent" command inserts a BLOCKQUOTE element, or that it ought to be used to designate quotations, so far as the author is concerned, it serves to indent text in his/her editing environment, and has a similar effect in her/his favourite user agent. The tendency will thus be to think of it as the "indent command" rather than as the "BLOCKQUOTE element", and to reach for it whenever indentation is desired in any context, with consequently detrimental effects on the quality of the HTML output. Similar comments can be made regarding text positioning commands which generate (invisibly so far as the author is concerned) tables which are used for layout purposes, or a command which produces centred and boldface text (perhaps in HTML an H1 element) which the author feels inclined to use whenever a centred and boldface item appears to be appropriate. More generally, the problem is that the further one moves away from direct editing of the markup and toward a wysiwyg approach, the less aware the author will be of the underlying code and the concepts behind it, and, correspondingly, the distinction between structure and presentation will become invisible. What the author sees may well correspond to what he or she "gets" in her/his preferred user agent, but this will generally be quite different from what the user of a different output medium is likely to experience. Thus, the distinction between content and presentation has to become a genuine component of the author's every-day editing experience. The tool has to distinguish changes that affect content, from changes that alter style properties. The concept of wysiwyg must, it seems to me, be partially compromised. Perhaps a requirement that the name of the element which is currently under the editing cursor always be visible in the default view presented by the authoring tool, would help. The authoring tool should also offer distinctive commands and functions for editing style properties (implemented via a style language), which are clearly separated from those which change or insert markup/content. Also, the ways in which commands and operations are described in documentation will tend to influence the approach taken by the author. Thus, a description in entirely visual terms may tend to yield an editing process that is conceived visually as well--that is to say, in terms of appearance rather than structure. I am sure that you are aware of, and can develop, better solutions to this problem. The ability to edit auditory style sheets etc., is another important component of a comprehensive authoring tool. I assume that it is covered in your discussion of W3C technologies but thought that I should mention it. Also, the treatment of tables in the authoring tool guidelines will clearly be dependent on the final text of the table-related checkpoints in the web content accessibility guidelines. However, it may be arguable that the elimination of deprecated language features and bad habits (such as the use of tables for layout) is even more important in the authoring tool arena than it is for content developers generally. In the case of content authoring, the WCAG can recommend interim solutions, in the knowledge that web sites will be updated as technology evolves. However, an installed authoring tool may persist for much longer, without being upgraded, than a web page, and this may demand review of the importance of avoiding deprecated and inappropriate uses of markup. Of course, the argument will be that the authoring tool developers have to remain consistent with that which user agents have implemented, but user agent developers can likewise offer the same excuse for inaction. I would be very interested in your response to the above comments, and would be pleased to discuss some of the issues further, if desired.
Received on Tuesday, 20 April 1999 18:50:48 UTC