Education and Outreach Working Group Teleconference

19 Mar 2018


Nic, Shadi, Brent, Denis, Andrew, Chris, Thomas, Sarah, Howard, Bill, Eric, Sean, Shawn, Robert, Bri, Howard, Jillian, Adina, KrisAnne
Bri, jillian


<shawn> Introductions!

Role-based Accessibility

<Brent> WAI engage Responsibility Breakdown: https://www.w3.org/community/wai-engage/wiki/Accessibility_Responsibility_Breakdown

Denis: In 2011 – abstract for responsibility breakdown – idea of only training people that was relevant for them. Breakdown of a product lifecycle with roles that would be generic enough for people to recognise them (not necessarily by success criteria).
... Goal by relevance – shorter wcag criteria by roles, checklists for different people. Looking at QA as part of the agile process, designers look at different criteria than say a developer, then broke down criteria. Intent initially, fast forward to last year
... Met with Bill and now working together
... Quick tips – 10 different tips for roles, idea was to take the breakdown and make a series of small quick tips that would allow you to get started
... This idea was to bridge the gap, break down the criteria and make it easier to understand for new starters Started the set for UX designers first, and gave it to a bunch of designers for them to test, written in a way that resonates with them

<yatil> https://docs.google.com/document/d/1KpIJefOrnSfiNTB3MVqoEk_X_8_M2y7pxShgyHXnGJY/edit#

Denis: Looking to create a set for different roles: Designer, Developer, Tester and Manager

<shawn> RACI = Responsible, Accountable, Consulted, Informed

Denis: Determined which success criteria would apply and broken down to a granular level, have this available on a website for people to access and create their own checklists
... Using the RACI model to determine who this work impacted on– primary, secondary and third. One checkpoint impacts 3 roles for each step in the lifecycle
... There’s a future for this work, where would it sit?

<shawn> Chris: Is this EOWG resource?

<shawn> Shawn: Not yet. We have it as a possibility in our current charter.

Bill: Education to those who make the decisions and develop role-based training materials. Tailored to their experience and role. Design making process can happen before development happens.

<shawn> Andrew - .... What about things not in WCAG?

<shawn> Shadi: ... advisory techniques ...

<shawn> Shadi: ... issue: not redefine WCAG. maybe markup [tag] techniques

Shadi: First, framework is great – need to think it will influence future development of the guidelines Concern is about different levels, roles, checklists then breaking down the criteria (redefining wcag that could drag on) Maybe scope these out as techniques until Silver is out

Denis: agree in scoping

<Howard> +1 to Brent

<Howard> +1 to Brent's comment on Techniques

Denis: Goal is not exhaustive but a first step towards a bigger thing
... General rules of thumb as you come in to WCAG and an entry point, then more able to develop towards learning more, to fill a gap. An initial checklist for a role, as the person learns, they develop and want to learn more and improve by researching. An easier way to get in, to get started.

Brent: We get asked, what am I supposed to be doing in my job? Needs a meeting to discuss where different roles fit with what you do and the success criteria about what you have to accomplish

Bill: Decisions can be made earlier by using these techniques as a communication guide

<Zakim> shawn, you wanted to ask Andrew how many "best practices" do you have outside of WCAG? and to say we have gone beyond WCAG (eg for tutorials) we were very clear to designate what

Shawn: to answer, we have gone go beyond WCAG in tutorials (clear that it’s best practice)
... WCAG on the street but there is a reason for it, we need it The difference, adding the role base, this is good and need to figure out parameters, scope but it fits

Denis: To respect what Shadi is saying, we don’t want anyone who knows wcag to write this, then it will resonate.
... It will be a way to operate what WCAG is doing to identify the gaps of what is missing
... maybe this will help to do that

Sarah: People find it difficult to understand WCAG, this education tool would help guide people to the standard (not replace it). Techniques per role are a good idea and have done this before and can find this again to share, was a lot of work but the techniques can add extra layer and important for learning

<Zakim> yatil, you wanted to say difference between SCs and interpretation of SCs in a language for an audience. “What this SC means for you?” and to say also: Very dev heavy guidance

Denis: Checklist lists items that are in automatic tools - how meaningful help text will be (not alt text)

Eric: Helpful to have this written to understand the criteria, to meet what the audiences need
... Techniques don’t have enough context, can meet criteria but not necessarily best practice

Denis: writing something that refers to the criteria

Bill: it is to explain how you (ie a designer) impact the criteria, how this is met is something you own.

<shawn> [ Shawn ask Thomas to look at Perspective Videos, revised "business case", etc for the why ]

Thomas: addressing usability of WCAG itself – html spec – there are many html interpretations – turn the standards to see different impacts

<Zakim> shadi, you wanted to say that AGWG open to completly revamping design of Techniques and Understanding docs

Thomas: Eg: Icons – subject to interpretation

<shawn> [ Shawn thinks of the "intent" in WCAG Understanding = the "why" ]

Shadi: everything is about guiding people about WCAG, if anyone wants to rewrite the techniques, can be done based on roles

Denis: Who owns the techniques? Shadi: Content is #AG

Shadi: definition of roles and breakdown is important

<Zakim> shawn, you wanted to say Let's talk next steps! and to also mention that EOWG helping with Understanding and to say like QuickRef

Denis: this is ready to be delivered and a good starting point

Shawn: Next steps? What needs to happen next?

Bill: continue the process, fleshing out the UX, then repeat on some of the other roles, need direction from this group what fits in the plan

Shawn: Looking to feeding WCAG, eg Refer to…

Denis: 1. Lifecycle cross-functional themed roles document – agreement or changes required 2. First draft, discussion, make changes as required for each role

WAI redesign beta - any EOWG discussion

Shawn: new pages and biggest changes are resources

<Andrew> Audiences - Issue#3 https://github.com/w3c/wai-audiences/issues/3

<shawn> Nic: ...

Nic: These are a good entry point to get started. For newbies. Adcanced people already have their [bookmarks ro whatver]

Denis: get a foundation, can we move it to the overview page?

Shawn: most people won't go to the overview page

Eric: we will discuss the overview page, the idea is to send a person (eg designer) can see on one page resources for them

Robert: what about the links to other tutorials as well?

Shawn: developers links to tutorials but designers (only a few spots) – links to get started then goes to tutorials from there

Eric: also there are different examples on different pages, needs some more work

<Zakim> Andrew, you wanted to talk about overview & roles

Andrew: Could we use the list of roles for the overview page (from previous #eowg discussion)

Shawn: Denis can you include? Denis: yes

Andrew: eg: content designer

Denis: UX designer, etc - includes IA - details great content for the overview page

Sarah: terminology – may need to be reviewed for consistency?

Shawn: will revisit to check

Sarah: link – description, is there any talk about how to use links with details?

Shawn: would like to discuss, is there time?

Brent: going to try and fit in discussion now and fit github before lunch

Shawn: In general, if in the middle of prose, then it’s better to have a link at the end (document link in sentences) Link first, then description: clarify that for some people it works much better, there was an issue that raised about how it is done on the current site it looked like a list of links

Sarah: that if it’s a list, it’s not prose

Shawn: in some cases there is a strong reason to use one way rather than the other

Sarah: sometimes links are taking place or being used as headings

<Sarah> Andrew: Links are bold and in another colour and draws attention. Allows people to choose if they want to read the description.

<Zakim> yatil, you wanted to say Principles in the foundation?

Howard: comments on audience pages – on hold

Eric: prefer principles in foundation section on the top, it’s good to introduce to the general principles first

Shawn: Eric's question will follow resolution of Sarah's question

<Howard> +1

<Brent> Proposal - Rewrite the content with the links first and description/content following (similar to the policy makers page)

<Sarah> +1

<yatil> +1


<Andrew> +1

<rjolly> +1 for DL

<Brent> Proposal + format in DL

<Chris> +1

<Andrew> Denis +1

<vavroom> +1

<Brent> +1

Adina +1

Denis +!


<yatil> +💯

<Sarah> +1

RESOLUTION: Rewrite the content with the links first and description/content following (similar to the policy makers page). format in DL

Howard: h-nav more visable - stood out - solid background

Eric to review

Issue using ZoomText? may need left nav

Chris: open issue regarding including a left nav

<Zakim> Denis, you wanted to discuss random question about button

Open Issues (Policies)

<rjolly> https://github.com/w3c/wai-policies-prototype/issues/304

<Brent> Laws and Policies: https://www.w3.org/WAI/beta/policies/

<Sarah> Proposal for #298 - We won't provide new filter capabilities, instead we will provide a downloadable version.

<Chris> +1

<Andrew> https://github.com/w3c/wai-policies-prototype/issues/298

<Andrew> +1

<Brent> +1

<Howard> +1

<Denis> +1


<yatil> +💯

<Sarah> +1

<shawn> +1

<rjolly> +1

<Sarah> +1 Adina

<rjolly> https://github.com/w3c/wai-policies-prototype/issues/297

<rjolly> https://github.com/w3c/wai-policies-prototype/issues/293

Overall agreement on #297 closed

<Andrew> Beyond our purview

<shawn> https://github.com/w3c/wai-policies-prototype/issues/328

<Zakim> shawn, you wanted to say maybe that is examples for Developing Org Policies

Eric: Example policies for orgs and institutions - not sure if it fits on this policy page

Shawn: Laws are different to policies to follow

Shadi: resources like this would be good to have but how do we manage it

Adina: need to consider ownership of the resources we link to and if it changes

Shadi: we can include a disclaimer to explain it's an example

<Andrew> We have a disclaimer already: "The information on this page is _not_ legal advice"

Shadi: #293 added wish list of example policies as a resource

<Andrew> https://github.com/w3c/wai-policies-prototype/issues/293

<Andrew> https://github.com/w3c/wai-policies-prototype/issues/205

Robert: needs more discussion and will reply to the issue

Shadi: UN monitoring to see what is already out there

Potential Curriculum Materials

Howard: Curriculum development - looking to not duplicate
... Referring to https://www.acm.org/binaries/content/assets/education/curricula-recommendations/it2017.pdf
... referencing specific parts related to accessibility

Adina & Sarah: consider gaming, frameworks and larger devices (eg smart TVs) and self-service kiosks

Sarah: advice - consider these other areas even if we don
... don't build into the actual courseware base

Robert: another area to consider VR

Howard: referring abstract summary of a survey - to do something specific, not just general guidelines

Kris Anne: audience is not now just ICT

Howard: 6 items taken out of what is already been taught, could be combined with some model courses
... looking to add demographics - take the examples and combine and revisit, question is what are the next steps?
... proposal idea - better use if taken off the shelf and modified as required
... specific lesson plans and assignments

Shadi: question about how to plan, slide sets?
... describe learning outcomes - leave teachers to build the slide sets?

Howard: would be nice but concerned about time?
... need to give them as much as we can and take it from there

Adina: already creating a curriculum, would like to see a thorough approach and happy to help

Sarah: learning outcomes is good so a lecturer can match to curriculum - match to general topics (include accessibility naturally)
... needs to see accessibility not as an addon or a feature - integrated

Eric: guide with principles, resources can be used to build to the curriculum

Howard: this is a 'design for all'

<yatil> [ Eric: layered approach, guide teacher trough how people with disabilities use the web and the accessibility principles, then build on that for design, or development. Also helps teachers to backfill their existing personal curricula. ]

Adina: is there a way to do research and lab work - internships - include dev firms that practice good accessibility coding?

Howard: includes exercises for interactions with people with disabilities - interviews, etc - includes etiquette

Brent: thinking about resources for instructors to use - 1. to look at what we have anything relevant and if they need to be updated
... 2. what resource do we have, to fit in with the learning objectives

Sarah and Andrew: yes there are

Howard: 1. look at the topics to be covered, then 2. look at the resources to support

Shadi: audience is important but difficult as don't know their background

Brent: idea is to create modules to be plugged in anywhere

Shadi: we also need the big picture - then focus on a specific modules

<rjolly> Shadi: there is a possibility of having the curriculum mapped to different roles

Howard: summarise shadi - develop for different roles - then work out what we're going to develop from that

<rjolly> Shadi: Possibly need to sketch out curricula for various roles, but trainers/educators will need to know more of everything to be able to teach others

Howard: think at the moment to come up with the most important topics and let people grab them

Shadi: match with the roles to give context - let's develop the concept and plan for the future to extend that

<shawn> ?

Adina: start as MVP and add to it

Howard: use our expertise, resources we have and the key topics
... give them support material to build as part of the current course process

Shadi: how do we expect them to know when to use this material

Brent: provide basic objectives and student outcomes - no matter the role - here are resources to help

Kris Anne: like objectives rather than modules

<shawn> [ issue: separate vs integrated.... how get integrated... ]

Howard: focus on accessibility but links to what is already teaching about -eg user-centric design - drawing into the larger topic

Brent: trying to find the gaps in the topics - already resources out there we can link it

Kris Anne: to be aware of 1. course content is not created by instructors 2. difficult of time/classes so no time for an accessibility only class

<Zakim> shawn, you wanted to say not be limited by current, yet be aware and to say big picture and tightly scoped thing for now and then... and to say note current project parameters

Howard: need flexible, smaller pieces and taken and used in courses more easily

Shawn: need to review and go through current stuff first

Howard: agree use what is already in place

Shawn: Agree that we need a big picture but don't want to spend a lot of time on it

Howard: address the limited resources issue - keep them small - important is to develop what we can

Shadi: training is serious for WAI - providing more guidance and support - this project will support more but determine what the MVP for the short term

Howard: next step is to do a more detailed proposal and present

<Zakim> yatil, you wanted to say integration of existing resources and to say build small MVP and iterate from there.

Shawn: w3c considering doing more curriculum. Still working on this, could fit into another project of work

Eric: a guide to how to use our resources in their teaching

Howard: prepare a more specific proposal and bring it back to #eo

Shawn: how to get instructors to use resources

Howard: will survey to check use - currently need it to get jobs

<shawn> http://uiaccess.com/teachDI.html

EOWG editor role

<shawn> scribe: jillian

Brent: We previously had editors who were working on resources full-time. We tried EOWG participants doing "resource management". Now in middle ground as we work with resources. Role of resource editor is to prepare material for EOWG review, then take EOWG input into doc revisions. For existing resources, refresh the memory of the EO group and say, this is what the resource is, this is what we said the requirements were in the past & entails, and get the group’s perspective of what should be done with that resource. This is what Denis was referring to [CUT]
... Nic’s role is to make sure everyone is on the same page with the purpose of the document’s objectives are, and find out where the group wants to take it, then implement the feedback into the resource the best he can, then check in with the group to ensure it was implemented properly

Selecting Authoring Tools

<vavroom> https://www.w3.org/WAI/EO/wiki/Selecting_Authoring_Tools_Requirements_Analysis#Questions_to_consider

<vavroom> https://www.w3.org/WAI/impl/software

Brent: Nic is currently editor for authoring tools (and we need to give valuable feedback on this)

Nic: "Selecting and using authoring tools for web accessibility." Very mature document that is old and dated

Shawn: It was actually never approved. Had known issue that Shawn doesn't know

Nic: Looking at revamping it and probably need to do a fairly extensive, swipe-everything-off-and-rewrite
... Will discuss questions first. Understand target audience, how much we want to keep, reaching out to CMS developers, and do we want to create separate resources? Review timeline and see if anyone wants to join Nic
... Goals - help people know what to look for, the "why", understand the limitations & workarounds, help people who go out and build systems to think about accessibility in their authoring tools. Asked for any other goals or objectives that we might want to add as we prepare this resource

Adina: Are we talking about authoring during the process, or upon check-in/ validation/ blocking check-in?

Nic: The authoring tools themselves. The end user being able to create content. The text writer/ content creator
... Needs to create accessible content

Shadi: Social media falls into this category. Tool vendors has been an issue in the past. Types of tools are so diverse, many are in-house & homegrown
... Not only tool vendors, but tool developers and tool customizers (many times you have to customize tools to meet your needs)

Sarah: Still struggling to understand ATAG- You have a tool to create a site, you have a developer to create the template, then a content creator who updates the content. Understood it as a tool that can create an accessible website

Nic: Look at this as "these are your options," "strategies to be applied" instead of "here are the steps to follow"

Adina: Would this be an example? Have Einstein, SiteCore, Mailchimp... The problem is, you type content in, no <p> tags. Would something like this address "when you're building X, when you put in text, it wraps properly in <p> tags instead of using <br />"

<Denis> q

Nic: Something like this could become really complicated and reflect the content of ATAG . Leaving it open to you all to tell us what we want to do. Do we want to go this granular or instead, think about adding a page that gets more specific about what an authoring tool does

Adina: Something that says, look for these 5 things, and if they have them, it's a pretty good candidate?

Denis: The document should not try to explain what ATAG is, its intent, or its value. Instead, should focus on how from a procurement perspective, what to think about when chosing
... The main point is, what am I supposed to look for? If I have to purchase a tool, what should I be thinking about?

Kris Anne: Is this a list of, who's taking these ATAG guidelines and doing it right? Or are we not calling people out for not doing it right? They can come here, see who's abiding by the rules?

Nic: We don't have the bandwidth, time, energy to assess. Will take 100s of hours to do

Sarah: Things change too much for us to maintain

Shadi: Suggest that we keep this resource very high-level, maybe even switch around primary and secondary audience. Don't know exactly. Adina's question was very context specific. "This is an email authoring tool..." when you then have the same requirement apply to social media, it's a very different context
... What you're looking for from the tool will be different from one industry area to another. Becomes very tricky here. What we could have in the future if we get the resources is to have a branching out from this high-level document, saying "if you're in a certain sector, this is how ATAG is relevant to your sector"

Nic: The general purpose: keep it high-level, talking about procurement and a little bit about what to look for in an authoring tool. Point people to the fact that there are guidelines

<Zakim> yatil, you wanted to say we have a intro-atag document and to say Is audience correct? and to say two different sides of ATAG

Eric: ATAG has two sides: 1. developer looking at a CMS to create accessible templates. 2. can producers put this content in in the first place. When I read "select authoring tools" I think can I make it accessible from both venues? As a developer, what do I need to do to enable this?
... We should also switch around the audiences. Make this about getting a CMS and telling them what they can expect from a CMS off the shelf

Howard: Seems to be some confusion on what an authoring tool is. Item to define it?

Nic: There is a definition, we would like to paraphrase the definition to clarify it.

Sarah: There's the definition of it, but could we broaden the definition to help aide the selection process?

Howard: At some point, does it become any piece of software? What's the dividing line between an authoring tool and any piece of software?

<Sarah> Sarah: to include frameworks which are used to create websites.

Shadi: Nothing. And even more so, software as a service. Lines are becoming blurry

Denis: Two things. 1. Have we agreed on the primary audience shifting to procurement officers?

<Andrew_> Authoring Tool definition in ATAG - https://www.w3.org/TR/ATAG20/#def-Authoring-Tool

Denis: Are developers and designers really the secondary audience? If the document is explaining to you what to look for in a tool, what does it matter? Anything beyond that could be a different document?

Nic: I would probably put devs and designers into indirect audience as information in this document could influence what they do

Denis: Are we diluting our message here by not having a separate document?

Nic: Scope has crept to do additional pages in the future for devs and designer

Shadi: Develop very short use cases (1 sentence each) on what this document should cover, then extrapolate audience. Probably won't be as role-based or focused. Will be like, "people who want to do x, y..."

Adina: See authoring tool vendors as a secondary audience because they will want their product to be selected. If someone who is procuring that and is following these guidelines to procure, it behooves the authoring tool vendor to read this and make sure that they can do what needs to be done
... Don't have a problem with devs in the indirect audience because there are so many blurred lines. Devs finding their way into SiteCore because they could do things real content people couldn't do. Had to ensure everyone knew how to do certain things because the content editors were breaking accessibility
... Could lead to opportunities to partner with tool vendors to make future releases more accessible

Sarah: Was wondering about solution architects. In a procurement situation, can include ATAG as a requirement but won't necessarily know if it conforms. Strategies for repair. A solution architect will need to know about the cause & effect and thus needs to be included in the decision making process AND part of the primary audience

Denis: Sarah just proved his point. This document needs to focus on what's needed in general and not be role specific necessarily as it limits people who may need to be involved, and another document needs to talk about what developers need
... makes for a shorter document, easier to read

Adina: to clarify, the secondary audience could read what the primary audience reads

Denis: but if we focus on addressing developers on purpose, we may have to word things in a different way that may not be appropriate or complete for other roles

KrisAnne: In all places ever worked, the procurement officer is more of just a purchasing agent. isn't fact checking or researching. the people who are doing the research on this are the people who are going to use it

Denis: It's not just the procurement people, it's everyone involved in making the decision (ie project managers, etc)

KrisAnne: Does there need to be variations on this based on roles we created for the new site? ie ATAG for project managers, etc

Nic: that's what we were talking about, making two main ones

Eric: often the company who has the website created for them is not even involved in the CMS choice because they just contracted the design shop who is using whatever they want to use
... a lot of people don't pick their CMS

Nic: in the RFP, saying "this is accessible" isn't enough. need to provide enough tools to help people make better decisions

Denis: People say, we need to pick a CMS; which is the most accessible? They want to know we're going to choose one. This document claims to address this so let's stick to this

Robert: Do you see this being similar to the eval tools in that authoring tool vendors may want to submit their info and get listed?

Nic: No
... May be entirely different resource later on

Denis: It's a reminders list on what to look for

Shadi: even with the tools list (also an interesting development), we started adding more and more to this. At some point, we took all these features and put it into a working group note (don't know where to find this)
... There you have all about how this fits into your dev environment, what's the performance, tech features etc., since it's a different audience who needs this technical glossary
... This might actually go into something similar, but the difference here is that people want to know "what's the most accessible authoring tools" but we can't really give this answer because it depends on industry

Denis: This doesn't answer the question; it helps people answer it for themselves

Shadi: Earlier, we needed to explain why particular requirements are relevant to different environments. Need to do the same for ATAG

Denis: That's why there will need to be different documents. What we have to think about is choosing authoring tools that are accessible and put out accessible content. Would be better to keep it very generic in this document

Andrew: How to work in standards in certain jurisdictions?

Nic: don't know if we want to be that granular in this document

Sarah: encourage people to learn more about their local procurement standards

<Zakim> yatil, you wanted to say implementation design and to say different modules might vary

Andrew: encourage them because sometimes they MUST (not just social good arguments)

Eric: the difficult thing talking about ATAG is that so much comes down to implementation design. This can be something that can be hard to explain & make convincing argument
... even if the core of the CMS is accessible, additional modules may not be. ie WordPress slider - have to pick the accessible one. This document applies to those modules as well but could open can of worms

Howard: Might be a different resource, but UC has started evaluating every piece of software they use in the educational realm. Might be a nice resource to link to all these different places who evaluate software to see what people do. Might be beyond the scope

Nic: Might be a great resource to think about as we go down the granularity of things

Howard: oftentimes people just want to know if they can buy it or not

Nic: recommended approach - keep it simple.
... reaching out to CMS, LMS - will be for next resource. already decided we would create separate pages later on. is there one person who has the bandwidth to work with Nic (maybe not as a co-author, but a first bump-back before coming back to the group)?

Sarah: given that plans have changed, do you need to wrap your head around the new plan then come back?

Brent: rework the plan based on today's feedback

Brent: quick break before moving on to integrating user stories

Integrating user stories

Shawn: We currently have stories of web users

<shawn> https://www.w3.org/WAI/beta/people-use-web/user-stories/

<Bri> https://www.w3.org/2018/03/19-eo-minutes.html

Shawn: 8 stories aimed to cover an array of situations


Denis: why do we use user stories and not persona?

Shawn: "persona" can be jargon for certain people
... recommend that we add issue to discuss user stories vs. persona at a later time. Perhaps "persona" is a term that many understand better now than before

<Denis> Let's capture discussing the use of the term "user stories" to describe this resource, as opposed to "personas"

<Brent> ACTION: Shawn to add issue on Stories of Web Users about calling them stories or personas.

<trackbot> Created ACTION-387 - Add issue on stories of web users about calling them stories or personas. [on Shawn Henry - due 2018-03-26].

Shawn: Mobile developer intro has many mini personas. The desktop publishing group also has the idea that we want little stories. Cog group as well
... How do we want to incorporate this? How do we want to address this? It's good if someone is focused on mobile, desktop and there are stories that speaks their language.
... Need to decide - do we really want all of these (General & Targeted)? On one page and have people filter? Pretty open for discussion

Sarah: If we have one that is specific to something like mobile, how do we break them out into different requirements? or make sure sure that it doesn't focus on just one access requirement

Shawn: Could have a mega database of scenarios and you could choose to see everything, or filter to show specific criteria (show me only mobile)

Denis: Webinar on UX personas. Point was that you need to find a way to make the personas modular based on context, what you want to represent, you can pull different pieces that represent that scenario
... What if we had 4-5 only that we reuse as often as possible, and in context, we give them different particularities?

Shawn: Do you change their disability, or do you change what you say about them?

Howard: You risk giving two personas the same name

Shadi: Have feeling we are talking about different audiences and purposes here. The stories we try to create were primarily intended for designers and developers to build empathy
... The mobile personas in this case are more bare. Other than that, there isn't much more about that person
... Done for the purpose of informing devs of requirements. In that case, this database that allows you to see all the personas to design for would be interesting. We already have a lot of resources from different task forces we can pull from
... Suggest not to mix but to cross link

Shawn: Right now, we have similar types of information in multiple places. Is this okay because we have different audiences?

<shawn> different use cases? ...

<Zakim> yatil, you wanted to say Have common stories and then pull individual aspects for individual use cases. and to say learn more about rebecca

Eric: What I think is that we have to use stories. Have core stories about who they are and keep referring back to them in different contexts
... Using the same people helps users going through the tutorials develop a bond with these personas, "this is why we do what we do"

<Bri> Jillian: by using the same characters we develop an overall picture of them

Andrew: Let's a full story, then on certain pages, pull out points that apply, then link back to the whole story about that person
... You would write things slightly differently, synthesize for that particular environment/ process/ product--

<Zakim> shawn, you wanted to say more rather than less, though :/

Eric: --then link to the individual story. Sometimes companies get a call from a PWD then ask, "how do I address this?"

Shawn: Like the idea & had this in mind. We will end up with more, not less however. In the real world, this person can only do so much (one person may not use many different types of software)

Shadi: Am torn! Like the idea, am proponent of having small pieces that come together to build a bigger story that ties together. What am worried about is knowing how much this would expand, how difficult this is
... Thinking about how PWD use the web. When working with the mobile personas, could throw these lighter-weight personas together quickly & easily
... Even if we bring this down to 20 (limits this scope as we also want to cover cognitive disabilities), do we really want to put this on how PWD use the web? If not, where do we put these? What are the purposes?

Andrew: proposal -- at minimum, if Joe has Parkinsons disease, we always talk about Joe when we talk about Parkinsons. Build consistency across what we are doing at the moment with the intention of building a full persona around him

<Zakim> yatil, you wanted to reply to shadi

Shawn: If we're developing a persona about someone who has a disability, but with different requirements from someone else who has the same disability, we're showing the different contexts and can continue building on this
... The conclusion of the initial discussion is to tend towards the idea of short term - if you're creating mini personas/ user stories and we already have a user story with that disability, and it makes sense for that user to do that thing in that environment, then use that same name.
... bigger picture, look at the possibility of some meta information that we can point to as we build new personas or upon existing ones

Shadi: Potential issue - if we capture all of these in a database, we're going to have strong skews towards certain..

Shawn: Agree. We have one view: general awareness (basically what we have now, not very different). Then we have another view that is, understanding mobile, understanding cognitive, etc.
... still will be very biased, but that is the goal

Shadi: Was thinking about pulling them together

Shawn: maybe we do have one page that has it all, but a disclaimer that says this is not representative of the real world

Planning tomorrow's work sessions

Shawn: who is here tomorrow? everyone except Chris, Brent, Shadi, KrisAnne
... the plan was to be flexible and work on what people want to tomorrow. can work in this room or break out
... Shouldn't talk about the business case without Sharron

Howard: would still like to work on curriculum

Brent: an idea, if we are lacking topics, Shawn could work on priorities with everyone

Shawn: another thing was the training resource updates... wondering if Andrew wanted to help with this? Could do these two things together because if we did the training resource suite updates as a group, then worked on the curriculum, then the first part would be the background and refresher
... could work really well together

Denis: other topic - tackling defining the roles, see if there are any gaps or if they work?

Robert: would be interested in that

Shawn: reminder: if it's on an EO resource, needs to be approved before posting on the website
... The other thing we decided this morning: quote audience pages, putting the link at the beginning instead of at the ending

Robert: can work on policy issues
... it's Canada

Shawn: We could ask Denis
... re the getting started tips. We're trying to clean up our GitHub issues so just do them, or just leave them and go back to that.

Denis: That's what I would do (the latter)

Shawn: Denis prefers for the getting started tips issues to be postponed until we get back into the resource

Denis: the simple fact of getting back into it and understanding what i had in mind is work

Robert: I remembered at the time it made sense to me, but now...

Eric: We need to learn how to write better issues

Denis: Says it's okay to discuss role definitions without him since he cannot be here tomorrow. 1-3 people, 1 hour discussion. Whole group, could be whole day

Shawn: Do we want to do this all together or split up? Should everyone go around and say what they would like to work on, and how?

Nic: probably start reworking the requirement doc since there's quite a bit to work on that document. I am beyond help
... Having 1-2 people participating in that would be great

Andrew: Will work on training and role definitions. Want to do a little more brainstorming around that.

Sarah: If it doesn't clash with navigation, would like to work on role definitions too

Shawn: Reviews edit suggestions document with Shadi

Shadi: Wondering in the long term, what the relationship the training resources will be to the curricula

Shawn: totally different but it's important that as we talk about the curricula, people have an awareness of what is there

Howard: Will sit in on training resource and definitely want to do the curriculum. If i had to pick a third, redesign navigation

Sarah: Redesign nav & role definitions

Bri: redesign nav & role definitions. may only have a half day, need to confirm morning or afternoon

Eric: redesign navigation and then I think I will work with Nic on selecting authoring tools

Shadi: interested in authoring tools and curriculum, but not sure

<yatil> [ Group compliment Jillians diligent scribing. ]

Shawn: It looks like one possibility would be the redesign navigation as a group, and then break up into three: 1. selecting tools, 2. role definition, 3. training.

Eric: would really not like to discuss redesigning the nav as a group

Robert: volunteer me for whatever is most needed. Like the role definitions (Since andrew is alone)

Howard: set time to discuss each?

Shawn: we are pretty flexible. need to first decide what we want to work on

<jillian_> Eric: one hour blocks in the morning, then see if we want to reconvene in the afternoon?

<jillian_> Shawn: overlapping or no? can we do concurrent groups or not?

<jillian_> Shawn: we could start at 10 if we want!

<jillian_> Nic: then the food would be cold

<jillian_> Shawn: who else wants to work on the training resource? Howard, Shadi, Andrew?

<jillian_> Brent: we have no one coming tuesday only

<jillian_> Shawn: training resource updates - if we get to this - could actually take a really long time. Here's an idea: redesign navigation & authoring tools first two sessions, then split up into role definitions and training

<jillian_> Brent: we have two minutes because we have to be over there in ten minutes and need to pack up. i say, be flexible and we can figure it out tomorrow AM

<jillian_> Shawn: will think with a fresh brain and decide tomorrow morning

<jillian_> Howard: would be better to do two topics at a time

<jillian_> Shawn: will draft an idea and send it out tonight or tomorrow morning when she has a fresh brain.

<jillian_> Shawn: we're done! off!

Summary of Action Items

Summary of Resolutions

  1. Rewrite the content with the links first and description/content following (similar to the policy makers page). format in DL
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/03/28 16:55:13 $