- From: Doyle <doyleb@alaska.net>
- Date: Mon, 24 May 2004 10:25:38 -0800
- To: <w3c-wai-gl@w3.org>
- Message-ID: <001401c441bc$839d55c0$04000005@madyburnett>
Personally, I like the mock-up and realize that it's a first approach toward bringing all the doucments together in a more usable fashion. Now, whether we call it Traffic Cop and I realize from others this may not be a good term - whatever. We need to make going form one location in our guidelines to other associated materials as easy for individuals as possible.
I liked David's format and flow - it's user friendly and makes sense right from the strart. Thank you for all the hard work, David.
Doyle Burnett
----- Original Message -----
From: David MacDonald
To: w3c-wai-gl@w3.org
Sent: Monday, May 24, 2004 8:12 AM
Subject: RE: [TECH] use cases diagrammed
Hi Gregg
>> "If we use the 'traffic cop/locator' as the link from guidelines to techniques. what is the purpose of the techniques gateway ?
-------------------------
Wendy has been working with Shawn from the Authoring Tools Working Group. Shawn is in charge of the WAI web site revision. She has extensive experience in usability and she conducted usability studies of WAI documents. Several of Shawn's key findings include the following:
1) People become disoriented when they are thrust into the middle of a separate document. (i.e., bouncing from a guideline in the Guidelines document to the middle of a long techniques or techniques gateway document)
2) Users want a quick effective way to find technology specific techniques that apply to guidelines (without being thrust into the middle of those techniques documents)
In preparing for our work, I interviewed 25 Government webmasters who depend on WCAG. I also interviewed Frances Grenier of the Kansas State University Accessibility Centre. She is on the State wide accessibility committee for the Kansas State Government & University web sites. Frances has heard dozens of comments from web masters who depend upon WCAG. The primary complaint that Shawn, Frances and myself have found is that it is difficult for users to find their way through all the WCAG documents. They don't want to be linked to the middle of a big long technical document. They want to quickly chose from all of the technology specific methods available to meet a guideline and see what they have chosen.
The Locator/Cop is an attempt to meet the needs of our users who are out there working with these documents every day and also to meet the needs of users who do not have an intimate knowledge of the documents and their interrelationships such as us on the committee.
Before the locator/cop, the "Techniques Gateway" was slated to take on 2 different functions:
1) to provide technology independent techniques (such as "how to write a good caption")
2) to direct the user to technology dependant documents to meet guidelines
It has become apparent to some people on the Techniques committee that these two functions work against each other. If we are to provide quick, simple access to technology specific techniques then we need to provide a simple menu where users can choose the technology they want to fulfill a guideline rather than sending them to the middle of a long Technology Independent document and then force them to fish around for links to technology dependant documents.
Before the cop, in order to go from a guideline to a technique the user would have to link to the middle of the Techniques Gateway document, violating Shawn's usability findings. We would be forcing the user to wade through technology independent techniques to find a HTML or CSS technique to fulfill a guideline. Once they did find a link to the technology specific technique in the Techniques Gateway document they would be sent into the middle of a 3rd or 4th document (technical documents) disorienting them further. Users have told us this is confusing.
In order to overcome these issues, the technical committee has been discussing separating the two functions of the Techniques Gateway.
1) The locator/cop is the Navigation part of the Techniques Gateway.
2) The Technology Independent Techniques document would contain the technology independent principles such as "how to write a good caption".
Wendy has informed us that it would be easy to generate a page via XSLT that would present
(1) the guideline,
(2) the success criteria
(3) the technology specific technique
(4) technology independent techniques (from the techniques gateway document) could also be included on this page.
This way the user would have everything they want for a particular guideline on one page. This page would also contain a link so that the user can enter the Technique Specific Guidelines document if they choose.
In the guidelines document after each success criteria there would be 2 links:
[Checklists] [Techniques]
If the user selected the [Techniques] link, they could be brought to a page such as this:
http://www.eramp.com/david/traffic_cop_from_guidelines_techniques_menu.htm
Another option is here:
http://www.eramp.com/david/traffic_cop_from_guidelines_checkbox.htm
I hope I have explained this well. Any other committee members are welcome to add their comments.
A mock up and further discussion is here: www.eramp.com/david <http://www.eramp.com/david>
Regards
David MacDonald
---------------------------------------------
.Access empowers people.
.barriers disable them.
www.eramp.com
------------------------------------------------------------------------------
From: Gregg Vanderheiden [mailto:gv@trace.wisc.edu]
Sent: Saturday, May 22, 2004 5:06 PM
To: 'David MacDonald'; w3c-wai-gl@w3.org
Subject: RE: [TECH] use cases diagrammed
Hmmm
I we use your 'traffic cop/locator' as the link from guidelines to techniques. what is the purpose of the techniques gateway ?
Gregg
-- ------------------------------
Gregg C Vanderheiden Ph.D.
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center
University of Wisconsin-Madison
------------------------------------------------------------------------------
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of David MacDonald
Sent: Saturday, May 22, 2004 8:20 AM
To: 'Gregg Vanderheiden..'; w3c-wai-gl@w3.org
Subject: RE: [TECH] use cases diagrammed
Gregg says:
>>>1) In the guidelines themselves, I think it would be nice to have the links, but have the big long sentences would make it unduly long. How about if after every >>>item in the guidelines, we just simply have 2 one-word links. Perhaps they could be in square brackets to set them off but they would be in the same line as >>>the guidelines so they wouldn't use up an extra vertical line of space. For example:
>>>[Checklist] [Techniques]
I like that.
>>>2) Traffic cop really does cause people problems and also sounds like Bobby, which is not let that function would be
>>>I don't have a good final suggestion but some ideas to get us thinking.
>>>- Locator
>>>- Technique Locator
>>>- Customizer
Yeah, I knew early on that the name "Traffic Cop" wasn't a keeper. I was just thinking of it as a code name until we had a better name. But I love the concept and basic design of the "whatever we call it."
---------------------------------------------------------------------------------------
>>>>On the second illustration where you show the two flow pads off of the guidelines, the first box is the guidelines and the last box at the bottom is either the >>>techniques or the checklists. Between them are two boxes which have a description but not a name. Aren't these really the techniques gateway document and the >>>checklist gateway document? If they are, we might just label those boxes on the diagram with those names and then put the function in parenthesis underneath them.
I was going to call these two boxes "mini cops" but thought I better leave them unnamed for obvious reasons.
I wasn't thinking of those boxes as the current "Technique Gateway" document which currently contain the "Technology Independent Techniques". I was thinking of them as what you call above a "Locator" . The way into the Techniques from the Guidelines (the left middle box) would be something like this www.eramp.com/david/traffic_cop_from_guidelines.htm The way into the Checklists from the Guidelines (the right middle box of the 2nd diagram) would be something like this www.eramp.com/david/traffic_cop_from_guidelines_checkbox.htm
Perhaps on one of our Thursday calls I should explain these use cases that have grown out our Wed Techniques calls.
Cheers
David MacDonald
A mock up and further discussion is here: www.eramp.com/david <http://www.eramp.com/david>
Cheers
David MacDonald
---------------------------------------------
.Access empowers people.
.barriers disable them.
www.eramp.com
-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of David MacDonald
Sent: Friday, May 21, 2004 10:23 AM
To: Becky_Gibson@notesdev.ibm.com; w3c-wai-gl@w3.org
Subject: RE: [TECH] use cases diagrammed
Hi Becky
I made the adjustment for Use Case persona Andy's printing from the Checklist (not the Techniques).
I've posted these use cases to www.eramp.com/david/becky_use_cases.htm <http://www.eramp.com/david/becky_use_cases.htm>
The models for the Traffic Cop and navigation paths through the documents are at www.eramp.com/david/ <http:// www.eramp.com/david/>
I also made a temporary Checklist gateway that will serve as a placeholder until I understand all the checklists and how the will look and work together. It is here. Use Case persona Jessica would have sent this URL .http://www.eramp.com/david/checklist_window.htm
Cheers
David MacDonald
---------------------------------------------
.Access empowers people.
.barriers disable them.
www.eramp.com
------------------------------------------------------------------------------
From: Becky_Gibson@notesdev.ibm.com [mailto:Becky_Gibson@notesdev.ibm.com]
Sent: Friday, May 21, 2004 10:16 AM
To: w3c-wai-gl@w3.org
Cc: David MacDonald
Subject: Re: [TECH] use cases diagrammed
Thanks very much to David for wading through my use cases and creating the drawings! I think his diagram in the posting from http://lists.w3.org/Archives/Public/w3c-wai-gl/2004AprJun/0333.html captures everything that these use cases require - I just needed to create a "real world" scenario to wrap my head around them better! I also don't fully understand the checklists and how they will be organized. I liked his example at http://www.eramp.com/david/benshtmlchecklist.htm. I also envision one page that is able to encapsulate the entire checklist for a specific technology but that may be too complicated.
I agree that it is probably too complicated to add all the checklist links to the traffic cop but it would be a good idea to add a link to the checklist gateway from there. I would like to see a link to the checklist gateway in the cell/row for each guideline. It seems like overkill since it will be the same link in each cell but a person may enter the traffic cop in the middle and not find a checklist gateway link at the top or bottom of the page. Also, do you think it makes sense to add a link to the checklist from the success criteria page? This will allow direct access to a checklist with just one hop from the traffic cop. That may be too complicated to maintain, though, but I think it would be helpful.
In the Jessica example you have:
1) The first link she sends is here:
http://www.eramp.com/david/traffic_cop_from_guidelines_checklists.htm
This actually takes you to a checklist gateway for a particularly guideline. I was envisioning a Checklist Gateway that is not guideline specific and allows you to select a technology. I then assumed that Andy would pick the HTML or CSS set of checklists. But, this gets back to how the checklists are organized - is it possible to have all of the checklist for one technology in the same document? One other minor nit in the diagram is that I expected Andy to print an HTML checklist. You have the printing from the techniques (which is also a good idea) branch. I just wanted to include printing so we would think about it when we designed the checklist page.
thanks,
-becky
Becky Gibson
Web Accessibility Architect
IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com
"David MacDonald" <befree@magma.ca>
Sent by: w3c-wai-gl-request@w3.org
05/20/2004 10:14 AM
To
<w3c-wai-gl@w3.org>
cc
Subject
[TECH] use cases diagrammed
My action item was to make drawings and comments on Becky's use cases. My drawings are simple box diagrams so that "lay people" can easily understand them. They are based on UML principles but not strict UML (to avoid visual jargon that might not be understood by all and inaccessible). I've posted these use cases to www.eramp.com/david/becky_use_cases.htm.
The models for the Traffic Cop and navigation through the documents is at www.eramp.com/david/default.htm
Wendy has asked me to send these links to the list for review by anyone who wishes.
Cheers
David MacDonald
---------------------------------------------
.Access empowers people.
.barriers disable them.
www.eramp.com
Received on Tuesday, 25 May 2004 02:22:41 UTC