- From: Scott Luebking <phoenixl@netcom.com>
- Date: Tue, 10 Mar 1998 06:58:08 -0800 (PST)
- To: Jon@operasoftware.com, jongund@staff.uiuc.edu, phoenixl@netcom.com, w3c-wai-ui@w3.org
Hi, I agree that the focus should be on the user needs. However, I believe that guidelines can be written in such a way that the needs of the user can be expressed in ways that are more easily understood by programmers. This doesn't necessarily mean that all the implementation issues need to be specified. It is important to remember that we do not have automatic agreement of browser developers to implement the guidelines. It is still a "selling" job to browser companies and programmers. If they think it looks easy to do and will take less effort than they expect, they are more likely to implement them. Scott > >We really want to focus on the user, not on the implementation >as that quickly makes a bad UI. We also want things as practical >as possible. We have already implemented a keyboard interface >that allows jumps between elements of various types. We try >to focus on what the user needs. Then we think about how to >implement it. > >At 09:44 09.03.98 -0600, Jon Gunderson wrote: >>I think we want to write the guidelines so they are easy to understand by >>developers. Could browser developers respond to Scotts thoughts on the >>format of the guidelines? >>Jon >> >> >> >>At 11:54 AM 3/7/98 -0800, Scott Luebking wrote: >>>Hi, >>>I have a suggestion which might be helpful for writing the guidelines. >>>It is often useful to write guidelines not so much from the perspective of >>>the writer but from the perspective of the reader. This approach can often >>>make it easier for the reader to understand. Since we want browser >>>companies to understand the guidelines and agree to implement them, we need >>>to think about how the browser company's might look at things. >>>Also, the easier it looks to do, the more likely browser developers >>>will do the needed work. >>> >>>My suspicion is that many of the browsers are written using object-oriented >>>technology. The object-oriented technology has many advantages, but one >>>challenge is that good object-oriented programmers need to think >>>fairly abstractly about the issues, much more abstractly than programmers >>>writing in C, etc. >>> >>>The guidelines reference things like headers, links, forms. One suggestion >>>is to come up with an abstract class name for them. The term 'elements' >>could >>>be used, but I think a term which somehow conveys the navigation aspect >might >>>be very helpful. (Many elements in HTML are not related to navigation.) >>>My suggestion is the term 'landmark elements' or just 'landmarks' for >>short. >>>(Actually, it might be useful to drop the 'elements' part in case there >>>might be navigation points which don't exactly correspond to HTML elements.) >>> >>>If the abtract class is "landmarks", then various sub-classes can be: >>> >>> links >>> headers >>> paragraphs >>> begin form >>> end form >>> input fields >>> begin list >>> end list >>> list item >>> begin table >>> end table >>> table cell >>> >>>The various types of landmarks actually have similarities in navigation. >>> >>>Explicit navigation >>> >>> e.g. go to link numbered 5 >>> >>>Sequence navigation >>> >>> e.g. go to next/previous header >>> >>>Navigation via list of landarks >>> >>> e.g. go to zip code field in form >>> >>> >>>A few of the landmarks have actions associated with them. The landmark >>>class structure could look like: >>> >>> landmarks >>> >>> headers >>> paragraphs >>> begin form >>> end form >>> begin list >>> end list >>> list item >>> begin table >>> end table >>> table cell >>> >>> action landmarks >>> >>> links >>> input fields >>> >>>The action landmarks could be triggered by explicit specification >>>or by having the landmark highlighted in some way. >>> >>>Does this class structure make sense? >>> >>>Scott >>> >>>
Received on Tuesday, 10 March 1998 09:58:19 UTC