Surveys for publication approval

<shawn> - Forms and Images Tutorials changes - ready! please complete by Thur 19 Feb or let us know if you need more time

<shawn> - WCAG-EM Report Tool - ready! please complete before Tue 24 Feb or let us know if you need more time

<shawn> - Tables Tutorial - waiting for WCAG WG review on Tue 17. (if you have any comments now, please file them in Github)

Shawn: Thanks everyone for completing, sorry it was posted late. The Forms and Images Tutorial is ready, complete by the 17th please.
... WCAG-EM Report tool survey is ready, complete as soon as you can
... WCAG-WG is still looking at the Tables tutorial and once they have completed it , it will be ready for our review. Questions?
... sooner is better esepcially if you have comments.

Planning Guide

<shawn> https://www.w3.org/2002/09/wbs/35532/eo-weekly-20150206/results#xq1

Shawn: We added a few questions to last week's survey about the Planning Guide, and since we were not able to review last week will do so now.
... any questions about what we are trying to do with the Planning Guide?

<shawn> mock up: http://w3c.github.io/wai-dynamic-planning/task_panel.html

<yatil> Howard's comment from the survey: [[I like the overall look and feel. However your question is confusing - sounds like this tool is set up to find other information on WAI related to planning & managing accessibility for web projects or is this tool itself serving that purpose?]]

Howard: If I could take a look at it again, I could clarify that this is a resource to link users out to other WAI resources?
... kind of a navigator for people?

Kevin: Kind of yes and no. We know that there is a lot of material in the planning guide recently rewritten. So broadly what this will do is incorporate Strategic Planning Guide content into the tool and link to other resources as well.

Shawn: WAI resources?

Kevin: Yes

Shawn: Howard, does that clarify?

Howard: Yes

Shawn: Good, so Kevin do you want to walk us through the comments based on the comments within the survey?

Kevin: Wayne, you had comments about the fact that the content was not naturally partitioned. Can you clarify that a bit?

<kevin> [Wayne's comment: One thing I found when looking at tasks was that they were not naturally partitioned. They seem like a cover set of subsets with some non-empty intersections. Your approach gives the strong feel of a disjoint partition: that is a subset cover with no intersections.]

Wayne: Well the point is that you have that kind of guiding wheel. But what I found when I was working through it is that there are several concepts that fall within multiple categories. Do we want to have something put in one bucket exclusively or do we want to think about how those task overlap into other categories?
... we may need to allow access to a concept from several different directions.

Kevin: As you look at the titles and we find there are activities related to multiple categories that we should put them into multiple places?

Wayne: I think we should consider how to do something like that. At least ask the question and think about it as we design the tool.

Kevin: We may need to do that as each issue comes up. As we recognize the overlaps, we can address those.

Wayne: Probably everyone had the experience when they did the sort that I could place this in one box, or another, or even a third. Training is a good example of it. Training is iterative and must occur across the varied categories.
... maintenance, monitoring are other examples.

Kevin: There were a number of design comments that were helpful. I won't necessarily respond to each but integrate the perspective into the design going forward.
... any comments about the mockup?

Sharron: I like it very much

Wayne: me too

Howard: A nice interface, I looked at it for the first time, just cold. I did think it was important to know what the text will say in the introduction. It will help to evaluate the rest of it to have that "What is the tool for" clearly explained. Otherwise it was difficult to evaluate.

Shawn: Maybe we should start drafting that intro?

Howard: Maybe some tool tips that explain the icons because I did not immediately connect them to the short descriptions below.

<shawn> Task Categories: https://www.w3.org/WAI/EO/wiki/Planning/Information_Architecture/Categories

Kevin: The icons are early concepts will continue to be revised
... and what I did with the sort results (about 25 responses) is reflected in the categories. There was an average of about 6 categories across the responses we had.

Shawn: Good job in getting participation, kudos to all of you getting others to do the task sorting excercise.

<shadi> +1 to thanks for the input

<yatil> EOWG++

Kevin: As the clusters began to emerge, I looked to the terminology for items in that cluster. That allowed me to take a first pass at naming the groups.
... what are people's thoughts at this approach for naming? There have been suggestions to combine 3 Reporting and 4 Maintenance, for example

Wayne: I see reporting and maintenence as distinct categories. The process of doing the reporting which is now a small category could include more tasks. We were limited and if we had been able to add tasks, reporting would have more. I see a qualitative difference between them.
... However, I thought you were trying to keep it at one level without subcategories.

Kevin: Yes that is my approach at this time

Wayne: Reporting is a very important aspect. In many countries the legal ramifications are based on how you report.

Kevin: Brent, you had said you put this together as a PMP, not sure what that was.

Brent: Project Management Professional certification, a formal training program and certification for PMs

Kevin: So in your experience do the names match your approach?

Brent: Since I have been studying for the PMP certification, the terminolgy was top of my mind and I found what you call categories very similar to the performance domains within that course of study. So I looked at all the tasks as if I were a PM in a large organization. My comment was therefore that if the tool is meant for PMs and many of them would be certified, it made sense to me that we are conscious of the language if we are targeting that group.

Kevin: My expectation in terms of audience is that they will NOT have been formally certified and in some cases, such as upper management, they may not be PMs at all.

Paul: one of my staff who completed this exercise categorized tasks based on which stakeholder would do it, from a scrum approach

Brent: In a PMP certification there is Initiation, where you gather info and get buy-in; Planning is second, setting goals, who's on team etc; Executing when you start moving on everything; Monitoring and Controling where you look at how things are going and make needed adjustments; and finally Closing where you report and document lessons learned, etc

<shawn> [PMP "performance domains" - 1. initiation 2. planning 3. executing 4. monitoring & controlling 5. closing]

Brent: the reason I went to this is because as I looked at your tasks, I was surprised at how closely they aligned to the PMP performance domains and wondered if that was deliberate.
... but the categories that you have developed are quite good as well and I have no objection to using those

Shadi: Thinking about those categories and being inspired by them are good. It is also good news to understand that we are closely tracking with professional PM training. We need to remember as well that we will have a broader audience since some of our targets may be management and advocates, not PMs at all.
... there is also some discussion of the classical approach to project management within agile environments for example of for things that do not have a discrete ending, like accessibility is.

Wayne: I was hoping that our choice of category terms might provide people with keywords and guidance to useful vocabulary and resources. It might provide ways that people would look for this information on the web. Recognizing that people will approach from varied points of view, I think the terms can provide good indices to our info.

<shadi> [accessibility should not be a project but a quality attribute of a project]

Shawn: We need to keep both audience - those with PM training and those without - as primary audiences. Also remember that this categorization is still in draft form. Now is the time to share ideas about changing approach or fine tuning the focus.

<Wayne> Lots of people have an MS in CS or an MBA in most of which are designed to teach PPM so they are trained and certified.

Brent: As a PM, generally when you look at tasks you insist on the linear way to do it. I like the comment about accessibility being unending, but that takes it out of the containerized category of a Project.

<shadi> +1 to brent

<shawn> +1 to exploring and communicating: [accessibility should not be a project but a quality attribute of a project] AND an organization

Brent: so it is therefore important not to box it into the PM framework.

Kevin: Yes I agree that this is about project management to some extent, but also much broader about change and process.

<Brent> +1 to Kevin

Kevin: Melody, your comments about process improvement - what terms would you suggest?

Melody: I left it open since saying "process improvement" assumes there is a process in place already and that may not be the case.
... the individual tasks within the categories may create an new process.

<shadi> +1 to melody ... or may not have any (formalized) processes at all

Kevin: So I feel as though we have covered the submitted comments, anything else?

Shawn: I think an issue is the number of categories - I liked the four categries but then see how the tasks do and do not easily align within them. Shall we discuss the number of categories?

<shadi> [ less less less :)]

Kevin: Yes I am happy to consider people's thoughts about that...

Sharron: I appreciate the need for tersification and the tendency for fewer categories. However, I think that as we reduce the nimber of categories, we really need to look more closely at those areas of overlap to make sure they are clearly communicated and not pidgeonholed into one exclusive category when they may apply more widely. I really trust Kevin's instincts as he is developing this and would just want to be sure that we recognize the relationship between limiting categories and making clear the areas of overlap

Eric: We should take a look at how the content flows and meets user needs and not be too focused on how it will look at first. So get the categories right first and then worry about the look.

<paulschantz> +1 to Eric's "let's get the content right first" comment

Melody: Are we expecting people to navigate through the categories to get to a task? Is this for discovering or for finding specific help for a task?

Kevin: Don't quite know yet, but it is a consideration.

Melody: So I agree with Eric. We want to understand how people will use it and provide alternative ways to navigate to specific resources related to a task.

Shadi: I would not suggest to think of them for categories for exploring but rather a series of tasks that follow on from what you are trying to do.

Shadi: thinking of them as activities or phases of a project. The fewer categories that we have the less overlap there might be.

Shawn: We need to keep in mind that different people have different modes of how they find and use information. So to be sure that in addition to being able to explore, we need to remember to give users a way to directly access specific information.

Wayne: Maybe we need to do the shuffle in reverse. The idea of access paths is really important. We do not want to limit people finding what they need by imposing a hierarchy on the info. The idea of how people find info is just as important.

Kevin: I would agree that we do not want to impose one model of Info structure. We do need to think about what is our core structure and approach however, and then provide alternative ways to get to the info.

Melody: An example is a marketing person is looking for this they would look for a communications briefing but would not necessarily look for process improvement.

Paul: I applaud the idea of varied approaches. I also need to note our tendency at W3C of providing so much text, as well considered as it is. I wonder if we are able to be open to the idea of allowing the document itself to evolve over time depending on how people use it?

Shawn: We do not have analytics in place as yet, although we are assured that some level of analytics is coming.

Paul: We seem to be taking a relatively new approach to how we develop this tool. And I don't meant to take us completely on a tangent, but since we have in the past presented an overwhleming amount of text, this approach seems lighter and more easily used. Rather than driving toward text heavy documents, are we open to another approach as we continue?

Shawn: I am not sure what the specific suggestion is.

Paul: OK Let me think about it and send a more detailed email to the group.

Brent: My last two cents is that I agree with Melody and Wayne in terms of understanding that people will approach from varied perspectives and that should take priority over classic project management.
... what will ultimately be the outcome? Once they work through the tool,where will people end up, what happens once they have identified the task?

<shawn> http://www.w3.org/WAI/impl/Overview

Shawn: My understanding is that you will get to a paragraph or two that is content pulled from the "Strategic Planning" doc. or you may get pointed to another existing WAI resource. Does that make sense to everyone?

<Howard> yes

Brent: Yes, and Paul's comments make me consider that again. My hope is that we would point people to more processed information rther than those W3C documents that are so dense and hard to access.

Shadi: That brings us to the QuickRef document and making it more easily usable.
... Brent we need to think of the many different ways but I do not think it is mutually exclusive to having a useful tool for project managers or other leaders in an organization. I think we must keep in mind the idea of this as both a planning and a management tool.

Shawn: We have gone back and forth about the title and so we must keep thinking about the naming of the resource so that people who need it know that it is there for them.

QuickRef redesign

<shawn> Analysis: https://www.w3.org/WAI/GL/wiki/Resource_Redesign/Quickref/Analysis

Shawn: We worked on this in 2009, developed requirements.
... we have made it an active project at this time. We have an early rough prototype to consider and provide guidance for Eric and get in our own minds what we are trying to do here.

Shawn: in the next week or two, try to skim through analysis

Eric: It is really really early. Everything from the analysis is not addressed yet, but will be eventually.

Shawn: Any questions about what this is, what we are doing here?

<shawn> http://www.w3.org/WAI/EO/Drafts/2015/quickref/

Melody: I am so excited about this, I refer to it often.

Shawn: Anyone want to share initial reactions?

Wayne: WOW! I am going to have to read this!

Howard: The one thing that strikes me is that is seems very vertical. Looking at the tool and the tutorials, they both give a scope of what is coming from the initial page. here you must scroll down to get a sense of what might be coming. Would like to see more inidcation of what lies below...again, just an initial thought, it seems a bit daunting

<paulschantz> I looked at this too and had comments, but didn't complete the survey.

<paulschantz> I was a little escared by it

Wayne: There was a question of joining the WCAG-WG to comment?

Shawn: To comment on their wiki, but you can comment in the survey or to editor's list without joining.

<paulschantz> it cries out for collapsible sections

<shawn> +1 to paul!

Melody: If I wanted to toggle for example for color from A to AA to AAA I would like to not have to go all the way to the top to do that.

Eric: Yes we will work on that with collapsible sections and more.

Shawn: Any other EO issues to bring up? news to share?

Wayne: I would like EO documents to stop referring to screen magnification as a primary mode used by people with low vision - it is not.

Shawn: Can you find those places and send to editor's list?
... also the longdesc resolution, can you respond?

Wayne: I liked it and think it is phrased right.

<shadi> [it is unfortunate that longdesc is not properly supported]

Shawn: Two surveys ready now, one more coming.