- From: David MacDonald <befree@magma.ca>
- Date: Mon, 24 May 2004 12:12:41 -0400
- To: <w3c-wai-gl@w3.org>
- Message-Id: <200405241612.i4OGCeLY008180@mail3.magma.ca>
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.
<http://www.eramp.com/> 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.
<http://www.eramp.com/> 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
<http://www.eramp.com/david/becky_use_cases.htm>
www.eramp.com/david/becky_use_cases.htm <http://
<http://www.eramp.com/david/becky_use_cases.htm>
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.
<http://www.eramp.com/> 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>
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>
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>
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: <mailto:gibsonb@us.ibm.com> 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 <http://www.eramp.com/david/becky_use_cases.htm>
www.eramp.com/david/becky_use_cases.htm.
The models for the Traffic Cop and navigation through the documents is at
<http://www.eramp.com/david/default.htm> 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.
<http://www.eramp.com/> www.eramp.com
Received on Monday, 24 May 2004 12:12:55 UTC