Quick Ref redesign

<shawn> prototype https://w3c.github.io/wai-wcag-quickref/

<shawn> survey results: https://www.w3.org/2002/09/wbs/35532/eowg27042015/results#xqr1

quickref

Sharron: we had pretty good response, 11 people reviewed and posted comments. Eric is implementing comments and will come back with questions if he has them

Shadi: I thought the comments were great. I didn't find anything needing discussion
... Shawn or Sharron - anything?

Sharron: is this one of the items for usability testing next week?

Shawn: yes

Sharron: are we going to try to resolve all these comments because there was not yet consensus. Some people liked this and others liked that
... will we have different version to test?

Shadi: No

Sharron: for example, some people said they liked the new side bar
... and some people were the opposite - this is too busy when expanded
... page is too crowded. Are we going to try to address these variations in response before user testing?

Wayne: got an email from Eric. Will wait on that until the responsive design is in place.

Sharron: any idea Shadi, Melody mentioned hamburger menu icon that she thought was confusing

<jon> Three lines

<jon> It looks like a I Ching hexagram

Sharron: I'm used to that and was not sure what she meant that many would be unfamiliar, do you agree?

Shadi: I haven't seen it. Okay, now I get it.

<Andrew> or narrow your screen -appears at top too

Shadi: I think those symbols are placeholders for now.
... Eric is conscious of this. Eric is looking to improve the symbols,
... hopefully, before AccessU.

<Andrew> 'hamburger' is common term for the icon, but lots of usability issues seems to be being documented in the survey.

Shadi: this relates to the symbols and ability to collapse stuff.
... dark blue might be causing noise. Saw comments much more going into visual design. Which is good, before talking about functionality. Seems to
... be shifting to how it looks. Anything else besides the hamburger
... you think needs to be looked at?

<shawn> [ for ERIC: maybe for the right & left areas, use a right and left arrow to indicate collapse and expand ?]

Sharron: Wayne's comment about the enlargement. Different between people's
... reaction that it works well and it's awfully cluttered & busy.
... but you answered that - thanks.

Shadi: What do other people think? It is a very complex page,
... a complex tool. Do people think it can be resolved through design or
... do people think we need to rethink sidebar?

Andrew: I found the flickering very annoying as I was
... scrolling down. I wondered if that could be controlled as it was very distracting for me.

<jon> +1 to flickering comment

Shadi: Left navigation bar?

Andrew: Yes. Change of highlighting I found very distracting and annoying.

Shadi: yes, I think that needs to be looked at.
... I think Eric wanted the navigation bar go along with you because the page is so long.
... I agree that it is distracting because of the way it jumps
... with you as you go along. We need to look at it a bit more.

<jon> Perhaps a fade in would be better after the page stops scrolling?

Andrew: I like the idea of being able to jump around without having to go back up to the top.

Shawn: one thing to think about. How often will people jump from the top
... to the bottom and so on.

Andrew: as people's expertise goes up, probably more jumping around will occur.

<shawn> maybe more often people will read slowly, more than scroll fast

Shadi: sometimes I am jumping around between success criteria.
... maybe there is another solution. "Get me the menu" type of function. There will be
... that sidebar in any case. That's for Eric to figure out.

<Andrew> desirable feature but not optimal behaviour

Shadi: were there other observations?

Kevin: my observation was around the right hand menu. I was thinking how would I use that in an evaluation. Probably limit my labels.
... filtering on things such as javascript. After that I would leave it. I didn't know if I would turn to those filters very much after that.

<Andrew> +1 to Kevin - probably filters become set and forget

Kevin: Didn't know if there's a way for all those menus not to overlap and be hidden more of the time. Or more obvious on how to operate them.

Sharron: Is the issue that the default is set so that all the side functions are open?

Kevin: I think the issue is that right now it needs to be set so that it's available to quickly change and operate. Maybe it could be set once and then not be as visible. Could avoid presenting the right hand column.
... you set, you minimilize and that that's it.

Shawn: that seems to be what it does not.

Kevin: I think there may be a design option that avoids the cross icon
... and those other functions.

Andrew: Tend to echo Kevin's thoughts. And other thoughts
... it's taking up real estate.

Shadi: that's useful feedback for Eric and should be looked at.

Shawn: Even when it's minimalized you think it's taking up too much realestate.

Andrew: Actually, now that I've minimalized it it's not as obtrusive.
... Will it stay that way?

Shadi: if you accept cookies it will retain your settings.
... we wanted the options open be default because we didn't want
... people to miss it.
... Maybe looking at this more specifically in the usability testing,
... perhaps the noise of it because of the 3 columns and options.
... beyond the visual improvements we plan to do anyway, there may be other approaches.

<Andrew> dropping to 2 col (with filters collapsed) is better and much less busy :)

Shadi: 1 function that is missing: being able to check off success criteria,
... to be able to say "passed/fail", etc. That's one use case we're still missing
... that Eric is looking to address. Marking whether something passe/failed, was looked at.
... That the tool has a check off feature. I'm not sure how far
... we'll get to this before the usability testing. Still, we have all the other

<shawn> [ shawn notes the checklist is useful for developers as well -- I want to check off what i've already addressed ]

Shadi: functionality, use cases, that we wanted.

<shadi> +1 shawn

Sharron: anyone else have any comments or questions for Shadi to take back to Eric?

quickstart Tips

<shawn> https://www.w3.org/WAI/EO/wiki/Quick_Start_Guides/Structure_and_Content

<shawn> feedback: https://www.w3.org/WAI/EO/wiki/Quick_Start_Guides/Structure_and_Content#Feedback

Shawn: Thanks to all who were able to put initial thoughts in the survey, we will discuss your points and work through them to be sure we are getting to understanding of what we want this to be.

Sharron: I just wanted to note that we have moved quite a bit from the original idea through our discussions. Kevin is doing a great job of reconciling all these visions. Bravo, Kevin!

<shadi> +1 to sharron - great work kevin!

<shawn> ... it's taking shape

Shawn: Are there any big picture comments or questions?

Kevin: From the feedback document, I pulled out some focus points for discussion.
... there are a couple of things that we have not yet considered but I do have 3 points to discuss (they may have some overlap)
... first is related to the fact that we should have UX and QA as an audience
... but Shadi pointed out that if we are task based rather than role based, individuals can categorize themselves. So a UX designer may look at various tasks related to his role. any thoughts on that approach?

<Andrew> +1 to activity-based approach

Wayne: That was actually what I was trying to get at in my comments. You imply a certain level of interest and entry point by talking about "Designer" for example, but it may relate to others as well. This access path seems better to me.

<Zakim> shawn, you wanted to say (*after* others chime in)

<shawn> +1 to activity/task instead of role (especially since some indivudlas do multiple tasks)

Shawn: I really strongly agree that we should relate these to a task rather than a role.

Kevin: And not that it will change the Tips so much as clarify the way to approach them.
... anyone want to chime in in strong defencse of roles?

All: none

Kevin: Is this in depth enough for Evaluators, Wayne asked. It occured to me that there is definitely a difference in the level of information needed for the various categories.
... Currently there is a difference in the level of detail for each of the categories. Is this a problem or do we accept that some tasks/roles require more detail than others.

<Andrew> not a problem if we provide more detail for tech dev vs a project mgr

Shadi: for example Advocates need higher level guidance of what to consider while developer need more detailed direction and guidance.

Kevin: yes and is that a problem? Is this what you were commenting on Wayne?

Wayne: Yes, there is a wide spread of knowledge and skill needed among all the roles. Moving to task based descriptions may address this.
... there was a very wide diversity, wondering if we needed entirely different pathways through the materials

Sharron: Wasn't that the whole point?

Kevin: there is the intent to provide a certain level of self-filtering.

Brent: I think the categorizations are fine, they seem to me to reflect the level of skill and detail needed by each task, role and area of responsibility. I can see that some categories will be more thorough and others more general. This reflects the need of each - the manager has a need to drive the effort but a developer has the responsibility to implement and will need more detail. So I think this is just fine.

Shadi: I agree, I do not see this as an issue.
... however the idea of having descriptions of each bullet with examples, etc was startling. If you only had a minute in an elevator with a developer, what are the quick, high level things you could say to help them. We seem to make assumptions as well about what some of the people may already know.

Sharron: I agree that the level of detail that was described - a bullet, some sentences, and example - was much more than what I had thought this wold offer. If this is our approach then this is a different set of resources that what I had envisioned. ... as I said in survey I recall that the joy that many people took in the biz card quicktips was its clarity and brevity.

<shawn> [ Shawn expects we will need to take a fair bit of effort on the details of each. so for now, need to get the overall what these are and check if these are the tasks (formeraly roles) we want...]

Shadi: the detail of how to expand the bullet points may need a step back and consideration of how to flesh it out, if at all.

Kevin: The third point I wanted to discuss was the scope.

Kevin: The requirements suggested a short tip, with an expansion paragraph and an optional example/benefit/more resources.
... a few quick examples can illuminate an idea very effectively. This was what we said in the requirements document and is now open for discussion.
... any other thoughts that people have on this?

<shadi> +1 back to purpose

Andrew: I like what Sharron said in the survey about the cards, I appreciated those. But it really comes back to what is out intent with this resource? We need to make up our minds about which it is. We seem to be moving in another direction, which is not wrong but we need to decide.

Shadi: Those do not need to be contradictory. So taking headings as an example, we say something short - use headings - and then link to somewhere that gives them more info. The question is in this resource, so we need to say what the benefits are and why they are improtant?

Andrew: If they are meant to be short and sharp, no. Let them click through to discover the what, the why and the how.

<shawn> <h1>Heading Level 1

Shawn: So using your example, there is some teeny little simple example that stimulates interest and makes people recognize that there is something more to learn.

Andrew: It means prioritizing.

Shadi: Bullets should be short, catchy and memorable. When expanded, it could be more detail on that short phrase, a sentence or two. Beyond that would be links to the supplementary docs. Is that what you are saying, Shawn?

Shawn: Yes, for example on the tables tutorials those little table icons that helped people understand, that turned on the light bulb and aided comprehension.

<kevin> https://www.w3.org/WAI/EO/wiki/Quick_Start_Guides/Requirements_Analysis#Tips

<shawn> -1 for the why

Kevin: I had a short example in the requirements doc. No example here but a short sentence and links to more info. It seems to me not to go overboard but does serve as a guidepost.
... the goal is to keep it short but make it clear enough to have the basics and then move them along to fuller understanding

<shawn> here is a rough example for discussion:

<shawn> ---

<shawn> Ensure color palette is high contrast

<shawn> Providing good contrast between foreground and background colors is important for some people with color discrimination difficulties and can also help some people with some form of learning disability, such as dyslexia. Tools are available to help you check and tweak your color choices until the right balance is reached.

<shawn> Related information

<shawn> Mr. Lee, Online shopper with color blindness

<shawn> Evaluation Tools List

<shawn> Contrast (Minimum): Understanding SC 1.4.3

<shawn> Also helps with...

<shawn> Mobile and tablet users who are in varying lighting conditions.

<shawn> ---

Sharron: I will once again strongly caution against providing too much information although I know it is a hard balance to strike

<Andrew> Quick Tips vs. Quick Start Guide?

Brent: I like what Andrew was saying. If something is called "Quick Tips" I would expect something that just gives me a few brief prompts to move me along, get me going. There should be something in there to tantalize readers enough to want to move along. We do not want to try to give them everything...give them a rabbit trail something to follow.
... I don't want to be overwhelmed with info but given a path.

<Brent> +1 to graphics (very simple ones)

Howard: I wanted to concur with Shawn's comments that a graphic has the potential to make a big difference. Something that will visualize the concept, get people intrigued and engage them to go further.

Shawn: Kevin, looking at an example was helpful in showing also what NOT to do - generally it should not inclcude Why or Also Helps With. Use Learn More rather than related info.
... also introduce the linked info. If going to a person, say that beforehand.
... If we have a short bullet point, text, short example, where to learn more.What are people's thoughts about Why? do we want the why to be in the Tip?

Sharron: Leave the Why for later in the discovery.

<Brent> Agree to Why is later

Wayne: I agree

<Andrew> coming for a tip on what to do - put why later

Shadi: a prelude to each of the links: Tools, for example or Examples, Why, or How - so you actually know what you will get when you follow the link.

Kevin: I have a partial concern that if the Why is not clear they may not follow.

Sharron: The reason I do not think that is an issue is becasue the fact that tehy are here as newbies probably means they ahve been prompted internally or externally to "find out what we need to do for accessiiblity" how often do we hear "just tell me what I need to do. " !

Wayne: Here is one I thought of...the heading example and how incredibly vital that is to be able to find your way in a document.

Wayne: if there are some things that we can explain quickly, it can make people more motivated.

Sharron: And we do provide reasons why, it is just pointed to and explained later on.

Shadi: People are motivated by different things and the we need to say in the mind set of the person coming to the resource and address that.
... I am now ready to follow the white tail bunny
... and we need to provide them with something quickly and shortly.

Wayne: The one point that is hard for me to understand is "Learn more about accessibility"

Kevin: Where I am a bit uncomfortable is the situation where the why is more important than anything else, such as the Manager and the Advocate. The Why is the most important thing for them. I am a bit worried that if we do not address Why in those situations, we willnot give them what they need.

Shadi: I do not disagree but it would be provided more as an expansion of the bullets. Look at the examples "Ensure buy-in" you could build a small why into the sentence without all the extra.

Wayne: What Kevin said is interesting becasue you are gathering your list of whys as an advocate.

<Brent> +1 to Wayne

Shawn: yes I can see that Whys might be important for other roles and tasks but not all.

Sharron:even in the advocate case, they already know why they are doing this - we don't need to tell them why they need to advocate, they want to know how to convince others, they need practical, applicable resources.

Shawn: So I think we take it case-by-case. For developers and implementers, we avoid why. For managers and advocates, we consider the specific need.

Shadi: Maybe looking at another example, we could look at it together and find the balance.

<shadi> [[sign-post the links]]

Shawn: Need to provide clearly explained and intro'd links. We want the bunny to know what trails are available and point to specific sections within documents. For tech detail -> link For why this is imp to PWD -> link. It will be useful to clearly clearly signpost the links and point to as specific and relevant info as possible.

Sharron: Leave the survey open for another week?

Wayne: I agree

Shawn: Let's talk a bit more and decide what we want to do. Do we want to discuss what the tasks are? If we change from roles to tasks - Developer becomes Developing, etc. Melody added UX and I added the ones from the QuickRef

<shawn> quick ref has:

<shawn> Front-End Development

<shawn> User Experience

<shawn> Content Strategy

<shawn> Design

<shawn> Development

<shawn> current ideas for these:

<shawn> 1 Designing

<shawn> 2 Developing

<shawn> 3 Authoring

<shawn> 4 Evaluating

<shawn> 5 Advocating

<shawn> 6 Managing

<paulschantz> Testing

Shadi: The comparison to the QuickRef filters the SCs and so focus on coding, not ideal.

Shawn: Understood and did not mean to suggest they should be the same, only a good excercise.

<Brent> Keep it simple. Don't break out groups. If they are covered in a group then that is good enough.

Shadi: Would front-end tips be different from other development

Sharron: No not at the tips level

Wayne: What is the question

<Andrew> tasks/activities look good for start - can be expanded later ;)

Shawn: So how does this work as a set of tasks?

Sharron: Testing makes more sense in this case than evaluating

Andrew: Let's start with what we have and not try to be everything to everyone today. We can split later if it seems necessary.

<Andrew> lets get some developed and released

Shawn: Kevin will do another example, looks like we have a start to the approach, we are comfortable with this as a first pass of task.
... what are EO next steps? A new example of approach? looking at detail?

Shadi: yes I think we can do both. We will leave the survey open and then have people looking at detail and Kevin will make another example or two

Shawn: Logistically, we can't delete questions without losing data.

Shadi: whatever works logistically.

Shawn: Go ahead and look at detail and we will let you know whetehr comments should be in this one or open knew. Kevin will create new examples based on today's discussion.
... Any wrap up questions comments on this?

<Brent> Just want to say great job so far Kevin

Usability Testing at F2F

<shawn> https://www.w3.org/WAI/EO/wiki/UT_May_2015

Shawn: If you look at the scheduling section. One room we have all day Monday and Tuesday and we have a second room intermittently. We expect to have people during lunch break and maybe between classes. In thinking about that, it would be good to have several people willing to help facilitate sessions.
... we will need to know who is planning to help with testing at what time. Please add when you plan to be part of the usability testing.

Sharron: Training?

Shawn: Yes, next week we can go through specifics.
... Please go into the wiki and add your availability for usability testing.
... it would be good to know who is doing what? We may end up with several EO folks testing different things and must organize participants by tasks.

Brent: Participate - does that mean facilitate the tests?

Shawn: Maybe but not necessarily. It is super informal. We will have to improvise based on demand.