<shawn> Introductions!
<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
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
+1
<Andrew> +1
<rjolly> +1 for DL
<Brent> Proposal + format in DL
<Chris> +1
<Andrew> Denis +1
<vavroom> +1
<Brent> +1
Adina +1
Denis +!
+1
<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
<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
+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
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
<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
<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
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
https://www.w3.org/WAI/beta/people-use-web/user-stories/
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
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!