GV Part of what Wendy and I talked about this afternoon, how do you make something objective? is that we know several things about a checkpoint. example, flicker checkpoint. We know that if something flashes at 20 Hz it's not good. But, what if it is only one pixel? It is not likely to cause a seizure since it is so small. Don't want to say no flashing of any kind. What if the guidelines had a checkpoint and under the checkpoint we have minimum, objective, clear requirements. We've been calling it success criteria, but I'll leave that for now. These (minimum requirements) are the things you have to do. Have another category, "these are the things you should also do." Those are never judged and we can list additional things. They can be vague. No one has to decide if you did them or not.
GSW Isn't that priority levels?
GV No and yes. No because A, AA, and AAA are levels of conformance. But, it does the same thing that we were trying to do. It gives you the ability to do minimum, or more, or even more. Although with A, AA and AAA we were talking about different things you were doing. Here, it is more depth in one thing. Some of the "also good if you can" or "also good as you can" there is no way to determine if you have done them. A ramp is declared accessible if it's run in 1 in 12, but there are people who can not push their chair up this ramp. Someone somewhere had to draw a line. It's good if you can do less, but you must do this at least. This model would allow us to include things that we wanted to say in the guidelines but finding that they would fall out if they don't make it as a success criteria. If you look at ATAG wombat, they have minimum requirements and advanced requirements. If we do this, the checkpoint should not be absolute if the criteria are limited. for example, we shouldn't say "do not do x" as a checkpoint if underneath it the minimum requirement gives some allowance.
CS In general, I like it. I would add a 3rd category of testable but less important. It makes sense to divide them into objectivity and being able to include them. However, how would you make a conformance claim? i like the idea of metadata. How do you say you've done what is not testable?
GV If you do the minimum, you check the checkpoint. "Also good if you can" can include testable (but less important) and non-testable. Other level, "if you want to optimize your site."
CS It sounds like sub-checkpoints and you would check off each of those. If so, then make a conformance claim at that level. Even if not able to get to the minimum, you can claim what of the minimum you have done.
GSW We shouldn't allow any metadata conformance claims if they haven't met the minimum.
CS I strongly disagree.
(other voice, not sure who) I also strongly disagree.
GV Let me clarify what I mean by minimum. It's not the minimum of the whole set of guidelines, but of individual criteria on a particular checkpoint.
CS Whatever the smallest unit of thing you can do, you should be able to make a metadata claim. It's useful for the user who cares about that thing.
WC Strongly agree, also that info helps track progress, either by human or between tools.
LS I think it will be counterproductive, they will make checklists of what they need to do. I really liked kynn's suggestion of doing something modular. If go "below the line" then people aren't going to read it.
GV It's not putting checkpoints above or below the line, we're putting criteria for checkpoints above or below the line. We are trying to make sure that checkpoints don't get dropped.
LS What happened with the modular proposal?
JW That's concerned with claiming conformance to the whole document, it is a different matter and still an open issue.
AP For the smallest unit of success criteria and metadata, I would like some sort of bucketing. "We meet above the line" or "We meet below the line" instead of having to list everything.
LS Yes, it does sound o.k.
GV summarizes (will send to the list)
GSW Summarizes points made in email.
LS What we really mean, is that if you've used a good data model and language, things of the same class it should have the same tag. If same tag then same presentation. e.g. main menu buttons have one form.
GV Someone asked about skins. If you have a science theme, it would use science icons. Another page has plants and use plant-like themes. Therefore, different appearance for different parts of the site. therefore, does this prevent you from making the pages different.
CS I didn't think it meant that. I thought it meant, if you're top level site nav is horizontal bar across every page, then it should be in horizontal bar on every page.
LS Same class elements should be recognizable as being in the same class because of their presentation.
GV it gets back into predictability. Very good point. Is it something that is objective?
GSW Rationalize presentation, isn't that a good way? Not consistent, but rationale or predictable.
CS If we break it into sufficient detail, then each piece can be objective. e.g., "do your h1s look like h1s?" "Is primary navigation in the same place on every page?"
LS The fact that you couldn't get a group of people to agree on what things could be associated w/each other. Perhaps different levels, as GV discussed.
GV suggestion for better phrase?
GSW "Use predictable presentation" or "use rationale presentation"
CS Also, 3 different ideas of what this checkpoint meant. These are all likely success criteria that aren't listed.
GV For now, let's not worry if testable or not. The 2 parts: a - checkpoint wording, b - ideas for success criteria.
CS 1. place navigational elements consistently on the page, e.g. main menu same place on every page, secondary nav same place on every page, menu items w/in secondary navigation should be relevant to each other. 2. each one should look like each one. may be diff colors, but all h2s are similar.
JW A particular element should have a distinct presentation. A recogniably distinctive presentation.
CS True at page level - each page consistent w/itself.
LS Distinguishing features.
CS Difference between page and site. Also, responses should be consistent.
GV Already there. This one is presentation the other is how they behave. checkpoint 2.2.
CS perhaps we should add in the one re: navigation menus and such, buttons that are not part of menus should not be in that. In other words, a print button on printable pages should be on the same place on each page. Won't be on all of them.
GV navigation and action items. What if it's informational?
CS It's important to call out what types of elements we're talking about.
GV If you say "navigation, action, and information" what is not included?
CS That's good for now. Another concept, things need to be really similar at page level, similar at a section level, and less and the site level.
GV same on same page, similar of diff pages, do we want to say something more than just location and presentation but also ...?
LS Use common presentation conventions. If we suggest using defaults (blue links on white, e.g.) then people get more predictability. above the line, links. below the line, logos.
CS perhaps find an online reference?
GV Want to be careful. I saw a site where the links looked like buttons and not underlined text. They were obvious to push whether you use the Web often or not. They follow web conventions, but they looked like real buttons so you follow life as well.
JW Any discussion of following conventions falls below the line, since people will disagree about what they are and how widespread they are. It's not testable. We need to be careful with our language and examples to make sure it is not dependent on any media. It also applies to a speech-only site. Location not on the screen, but the temporal order.
LS An interesting point, thinking of speech, that's a place where there is a lot of work to be done to make it more obvious. That points out that what we want to do is make navigation predictable. what you say about buttons, it is more predictable by keeping to conventions. way to make predictable but not always the best way.
CS Good to have explicitly, but perhaps falls below the line.
GV Buttons were following convention, but a different one. I have several notes on this checkpoint. (GV will send)
LS From my email from this morning, simple presentation.
CS Not true in all cases.
JW Differences in what people find easy to use. If we think it's important, could be a separate checkpoint.
LS A site w/a page with multiple functions could be unusable by some, for others less enjoyable. (scribe's note: more to it than this. I didn't capture it well).
CS Wizards are usually easier to use, but a dozen pages that you have to find might be harder.
LS Could be bad planning.
GV This is discussion of a site that could make it easier, although not all the time will it help.
CS Just putting one function per page, as an extreme example, does not necessarily make the site easier to use.
GV Could go in as a suggestion. This makes a 3rd category: 1 - absolutely do, 2 - advanced, 3 - alternative strategies. That last set seem like techniques, "here's are ways of doing it." not "what you should do."
LS I prefer "normative" or something. with this one level of functionality at a time, one primary function per page, it's always going to be better for people with cognitive disabilitie. I might be wrong, but from the background research I've read, they did tests on this. We ought to investigate further.
CS What about ADD? Wouldn't someone get bored with the 3rd screen out of 15? Did the research look at ADD?
LS Not sure.
GV in ADD, the focus would be good, with ADHD, might be a problem. In both cases, if you have a progress bar that might keep them going. Anyone using the Web, might bail if they keep getting page after page, however the progress bar might keep them there.
CS While wizards are a way to do things, they do slow them down. don't want to do this for every page, but perhaps give people an alternative path.
LS I totally agree.
CS For myself, I'll use a wizard perhaps the first time, but not afterwards.
JW It's an adaptation process. Believe this is what the Device Indie WG calls it.
GV the 3.1 wording proposal, "use predictable" or "rationale". would it really be irrationale? unpredictable could be rationale. do you mean logical?
JW I think the best way, is to forget existing checkpoint and summarize success criteria in one sentence.
GV consistent presentation sounds like a technique for doing something. using predictable sounds more like what you are trying to achieve. consistency is a way to help make it predictable.
CS Consistent is used in UI design literature. a term people will be familiar with.
WC I've seen predictable used a lot, e.g. Schneiderman.
GV predictable by itself might be a bit academic.
CS Could be derogatory, e.g. "boring."
LS Simple, clear, and consistent.
JW In that case, we would need to add success criteria re: simple and clear.
CS Like JW's idea to summarize success criteria and discuss on the list.
GV Propose changing to simple, clear, and predictable. Goal is to help people figure out these things. This becomes parallel with write clearly and simply. therefore content and presentation be on a similar line. If people feel that we don't want to do it, I'll back off, but don't want 3 checkpoints. the 3 are trying to achieve the same thing. "use a presentation that isn't hard to figure out."
CS I agree conceptually, but could be misinterpreted.
PB I do prefer predictability over consistentcy. I'll post more on the list about this.
$Date: 2002/01/10 22:39:10 $ Wendy Chisholm