WAI Authoring Tool Guidelines Working Group
Date: 7 January 2002
Time: 12 noon Boston time (what time is that where I am?)
Phone number: W3C MIT Bridge, +1.617.761.6200 ext. 2894
IRC: server irc.w3.org:6665 channel #wai
JT: In terms of the first agenda item we should talk about 3 aspects: how do we judge applicability, how do we define the category: functionality or tool and applicability of techniques to conversion tools
JT: 2 Agenda Items: 1. Applicability - how is it judged? All CP's could apply to all tools in theory. 2. Defining categories? Either categories of functionality or categories of tools.
JT: Functionlity was the original intent.
JR: Then we need to go through techs and decide what's applicable to conversion tools.
JB: charles what's your item?
CMN: applicability. I think that it is related to functionalities of tools. Some tools will have several functionalities, eg conversion, document editor, other tools will really only do one thing. (This is related to discussion we had in ?August?)
JR: JT, JR, CMN all agree that icons refer to functionality. Any given tool may have several applicable functionalities.
JR: We need to change icon text to functionalities. Explain that tools may have multiple functionalities.
JR: How applicable do functionalities need to be?
HS: We discussed this last time. 2 extremes - either any possibility of applicability or applies to majority of tools. Prefers majority of tools but wants one or another
JT: Charles and Liddy which extreme would you vote for?
CMN: I think it has to be "any tool" - these are only techniques so it is still possible that a number of techniques will be not applicable for a given tool.
CMN: the idea is to enable reducing the techniques by removing chunks that are not applicable to some definable class of tools.
LN: I am thinking about the icons and agree that I'd like it to be any tool
JR: I favour specifying only the most relevant functionalities. If we go to the other extreme almost all techs will apply to all functionalities and the classification system is pointless
JB: there are pros and cons to both approaches
JT: another consideration is the "views" of the document - it is less confusing when in view mode
JR: Lets just go through 1.1 and 1.2
JB: Using "views" model we should go with the maximum extreme
JT: But some people will still see whole document ao minimal extreme is better for that
JB: Some groups have used conformance profiles. This group is not suggesting that?
HS: If we use maximal option the user will start to ignore icons.
JB: But icons dissappear in "views" mode
HS: But what about user just pressing "techniques for 1.3" This is probably the most likely use case. "views" are a good idea but difficult to use
CMN: I don't think it is a problem if people do ignore the icons, they are only there to allow people to identify things that don't apply to them
LN: Guidelines are special docs that are read once and then the user goes to the techniques.
JT: We could have icons turned off in the full mode?
CMN: Doesn't see a problem either way. Icons there or not.. Icons are useful as an opinion of the group.
JT: Should we go through 1.1 and 1.2.
JB: Yes.
JR: 1.1-T0001
JR: Ensure that all structural features of the supported languages are available within the tool.
CMN: correction. Icons are useful to identify a subset that the group thinks covers the applicable checkpoints for a functionality.
JT: All 5 cats. apply.
CMN: not all techniques will be applicable to a given tool, but it is helpful to remove the techniques people are sure won't be applicable to tools that don't do a particular thing
CMN: having features in tools: It means that the tool is capable of generating the elements
JR: Conv. tools - ok. Con - editor - OK. Prog. tools - OK.
JR: JT: all 5 apply
JR: 1.1-T0002
JR: Allow the author to directly edit the source markup
CMN: makes sense for programming tools as well as document editors
JR: How about conv. tools
CMN: don't think so. A related techinque might apply, but I would propose it as a differnt technique: Allow the author to specify the code produced by a transformation.
JR: OK so I will just add Prog. Tools.
CMN: I support just adding programming tools
HS: We should add note on direct editing in the con. func. Definction.
JB: Let's talk about logisitics
JB: CONF CALL MEETING LOGISTICS (Phone vs. IRC issues)
JB: Difficult to have mixed meetings.
LN: When it works it's very good
LN: Calling from Australia is very expensive
JB: There is a (limited) ability to pay expenses
CMN: it is also good to be able to see what happened in the last couple of minutes without asking for a repeat.
CMN: (for those in IRC channel). Liddy is right - it takes some work to make sure that IRC keeps a good paralell with the voice track.
CMN: for people doing this meeting outside office hours (i.e. outside the US) it is also easier to reduce the noise level on IRC
JB: We can only cover costs when all the details are tightly recorded.
JR: Prefer all IRC to mixed (prefer phone to IRC, of course)
JB: which meeting did LN prefer? Which one made it easier to contribute?
LN: Some of the problem is the way meetings are organized - agenda not sent early enough
JT: can organize a list of documents needed for meeting
HS: Could not participate in IRC for sure for awhile
JB: Can't participate effectively in IRC clarification: due to problems w/ finger muscles
JT: Boils down to LN's expense issue
JB: Group could consider a few different meeting options (will talk with Jutta and Jan)
BYE
Last updated 16 January, 2002 by Jan Richards (jan.richards@utoronto.ca)