<scribe> scribe: chaals
<jeanne> 1 pref for moving Tues. ! for Friday, lots of people can make it work.
JS: It's in the phase 3 folder, and there are results by tables.
<jeanne> https://docs.google.com/document/d/1XDOmjQkMRqQ0XKiKYA-mDAuA40oHtaXNl1H0NXLcV80/edit?usp=sharing
JS: The group worked on strictly
testable but we didn't find their output for that, and on
"difficult to get started".
... today I would like to start a new document - the report on
the design sprint.
... Thought to take the problem statements, and then merge in
the outputs of each group that worked on that statement. And
then try to shake it into clarity.
... Without losing ideas, I hope.
CH: Not sure why we would extract this a different way. I started a document that is nearly complete for table 4 - might be an interesting comparison.
<Charles> https://docs.google.com/document/d/1zTij1pH9NumEmMJoTFlsnpkUHpM6SmP852jmkNDjAd0/edit?usp=sharing
CH: started to follow the outline
- who was there, what problem statements were addressed. Then
think we should have an executive summary.
... So I tried to cull out major themes, and will continue to
edit that. Then took the literal transcriptions from the
sprint, and have notes on what each sprint aimed at and its
outcomes.
JS: We don't need an overall summary for all 5 tables?
CH: Right. If we have summaries
from each table, we can just put them all in a single
document.
... I have some transcription still to do, and then to flesh
out the executive summary, generate a report of the sprint in
its entirety.
JS: Better to do this by individual tables?
[CMN thinks it is good for each table to try and put their stuff into a shape that can be read, and then hold discussions]
Imelda final report form would be best for me
AA: Do we have people from each table to represent the work?
Imelda I have a question regarding table 3. I haven't heard from Jan who was going to send notes.
<Luis_Garcia> Imelda is talking now
JS: OK, so let's change the
plans.
... Started thinking about how to get the work done for the
next few months.
JS: Would like feedback...
... Saw 4 things we need to get started, and work in parallel
because they interact.
... 1. Get the plain language of WCAG 2.1 started. It's a big
job so need to get it rolling.
... 2. Homepage design - lowest priority but the most
contentious, so we need to start.
... 3. The prototype design - this is the real piece of work
that we need to do.
... 4. working on the design and information architecture for
development and maintenance
... tooling choices, etc.
Kelsey: Why would the information architecture use e.g. JSON information?
JS: We have traditionally worked
on "flat" documents. But the prototypes and a lot of the ideas
have been about starting from a collection of small atomic
peices of data that we can mix and match.
... e.g. pick the things relevant to the task you are doing, or
the technology you are using...
... this makes it easier to give people the kind of information
they are looking for, rather than asking them to hunt through a
large document for it.
... there are a lot of ways to do this...
CH: Fine on having a location to
start this work - a repo or whatever. I think what we need is
to create a glossary of terms that advises our starting point
so people can contribute.
... A glossary is something we want to avoid in final
documentation, but we need a common understanding of tags we
use to do the work.
JS: Is that another concurrent project, or does it precede others?
CH: It is probably concurrent and
simultaneous.
... Naming things is hard so we need to figure out how we are
going to do it.
... E.g. we need to have a sense of common names for
disabilities. Does "Design Pattern" mean "how to do it" or
"what it looks like"?
<jeanne> chaals: I agree term design needs to happen concurrently
<jeanne> ... I also think we need a shared single document view that has everything that for those that need to see everything.
CMN: It would be helpful to have a single-document view available, so people *can* have a sense of everything at once, even though it isn't the way most people will actually use the information.
<Charles> perhaps a list of known knows and known unknowns
CH: We still have to constrain the information to match the scope. Don't want to spend a lot of time organising user agent terminology if we are not going to need much.
CMN: Agree. work on terminology as we go, to match what we need, and be aware of when we need to shake down what we have and try to make better sense of it again.
Kelsey: How do we make sure that this doesn't just get ossified after we have launched it.
JS: One of the key marching orders was to make sure that this is readily maintainable - e.g. a biennial update should be feasible.
Kelsey: Nice. Developing a glossary of terms can be a good chance for user research to idenntify what the terms in use are, and what people mean by them.
CH: SO we need to determine where this lives - tools/repo - so we can organically work on the problem. I don't know that we have answers to all the questions yet but we need to get them all on the table so we can contribute to answers.
[+1]
Kelsey: Would that be for the silver TF only, or for other WGs?
JS: Would be easiest to open a
silver TF repository on github - not combined a priori with
existing WCAG
... we could start small pieces.
<Charles> There are already 574 repositories in W3 GitHub: https://github.com/w3c
JS: Was thinking about getting
the plain language started.
... We hae 5 people interested in being editors to work on
converting existing WCAG content to plain language.
... So as we develop, we have some concrete information to
populate it, that we can use for testing.
<Charles> So then the first order of business is creating a style guide or set of rules for simple language.
JS: If we take a small section of
WCAG and put people on that, we could get an idea of what it
will take to cover the whole of WCAG - at the moment we don't
have a sense of how big a work item that is.
... Another piece, thinking of scope, is that we aimed for a
first version of silver that only covers what WCAG already has.
But MichaelC believes there is a lot of expectation about what
might be added, and we should consider an extra year and bring
in some reasonable amount of new material.
... I feel confident we could make the current stuff in by 2020
and do not want to work on getting new material in over this
summer but it is something to think about.
CH: There is a lot of work to do - we need to figure out how to scope the project. So we need to have a framework or styleguide for simple language and get some people working on it.
Kelsey: Great idea...
JS: So we should not look at plain language and should look at simple language?
CH: That was because "Plain
Language" is a term of art that has specific meaning to some
people.
... related to secondary education level of people. "Simle
language" just means what it says, so we chose it to avoid
getting into arguments over what it means
JS: So we need people to work on this.
who: Do you know what the ISO standard actually says?
JS: No, I don't. We need to have people look at this critically and see if the ISO thing will work for us. Sounds like a job for John Rochford and John Kirkwood. [and chaals - ed's note]
who: If the ISO standard works, is that a good thing or not?
CMN: An ISO standard that is useful would be great - the major issue with ISO is when their documents are really expensive. If it is not helpful, then we work around the unhelpful bits
<scribe> ACTION: JS to check what it costs to use the ISO standard on Plain Language
<trackbot> Created ACTION-163 - Check what it costs to use the iso standard on plain language [on Jeanne F Spellman - due 2018-04-06].
<scribe> ACTION: JS to Talk to people who know about whether the Plain Language standard is suitable.
<trackbot> Created ACTION-164 - Talk to people who know about whether the plain language standard is suitable. [on Jeanne F Spellman - due 2018-04-06].
CH: Think we should look at the
ISO standard, the education org (IMS ?), the US Federal Govt.
advice on how to do this.
... Should try to avoid being in conflict with the US federal
government work.
JS: We have to remember we work for a global audience, most of whom are outside the US.
CH: Sure.
Kelsey: Regarding ISO standard, can see how it might be useful. Wondering if there is a risk of getting more confusion than benefit from trying to work to them.
JS: We should get some named people working on this soon - in a ffew days. We don't want to reinvent the wheel - but nor should we spend too much effort twisting ourselves to meet a standard that isn't quite right for us.
[Chaals, Kelsey are interested, with caveats]
JS: This seems to be an underpinning for everything, so we need to get it going quickly.
LG: I am happy to help out as well, but am not confident that I am *the* expert.
JS: I am hoping you will work on getting the prototyping moving.
LG: Sure
JS: We will need to divide the
work amongst people to get there, so it will help if people
figure out what bits of the work they want to help drive along
and coordinate.
... people tend to work better on things they are interested
in, so bear that in mind.
<Charles> Table 4 prototype thus far: CodePen: https://codepen.io/hallmedia/full/zWpoEd/
JS: Would be good to have something we can show people in May as a preview of what it might look like, with some real content to play with.
CH: This is a document outline
using a single scenario - the goal was to figure out if the
outline was reaonable.
... used a scenario of a person who cannot hear the audio in a
video - e.g. a training video.
... we tried to progressively provide information, so people
could go as far into it as they want. A simple statement of the
problem at the beginning without saying *who* it affects. Next
level is what is the goal to solve the problem. Deeper in, who
does it impact and how, then ways to solve the problem, and
those get into implementation techniques, and then testing
methods - how do you determine if the problem
... was solved, not just whether the implementation recipe was
followed.
... Too much testing now doesn't check if the concrete problem
for users was solved.
... This is as far as we got in the design sprint. Feel free to
kick it around and work out how to move it on.
JS: Don't think we are ready to
put it in Github yet. But in Codepen is nice.
... many of these sections would be stored separately so they
can be reused in different ways.
... one of the table 2 things that are not yet transcribed is
dealing with "accessibility supported".
... We took a similar take, from the viewpoint of a
sccreenreader developer - how to handle tables properly?
... We came up with a very similar pattern, which I think is
nice.
... We are on a good track here, we should start experimenting.
Ideally we would spend summer doing user testing on prototypes,
while we have people working on getting simple language content
in there.
... And we need to start the discussion on homepage of what
Silver will be.
CH: Agree there are a lot of stakeholders who will have differing opinions. But can we say something other than homepage? People don't land on homepages...
<Kelsey> So it would be the new version of this homepage? https://www.w3.org/TR/WCAG20/
CH: they land on an understanding
page, or somewhere else within the document, from a bookmark or
a search or citation.
... don't think the homepage will get as much traffic as the
content pieces inside.
... So what is the information architecture of the content
overall so people an find their way from inside out.
JS: Indeed. But there is still a need to *have* a landing page, and some people will need or want to work on that.
MC: so by "homepage" you mean "the formal silver document" on w3.org/TR?
JS: No, although we need that too.
MC: Normative content needs to be controlled in that space. But I find that not ideal for many real use scenarios. We didn't do much creative with undestanding in WCAG 2 having moved it inot a space where we could...
[sounds of agreement]
JS: To clarify - we cannot overwrite https://www.w3.org/TR/WCAG20
<Charles> the ISO style guide for how to write standards using “plain language”: https://www.iso.org/files/live/sites/isoorg/files/developing_standards/docs/en/how-to-write-standards.pdf
JS: We need at least a rough prototype for FPWD by September...
MC: Ask EO for pointers to the work they have written. THey have a big task list already, so do not expect a lot off input from them within 6 months. Start coordinating with them now so they can plan to do review and give feedback.
<Luis_Garcia> We also can't hear Jeanne
JS: I have notes to follow up
with people who were interested in creating an interface to
help people file issues and follow them more easily
... (Github is not very accessible to some users)
... have a list of people in W3C to talk to about possible
structures that we can use within W3C requirements.
JS: Need to organise user testing, have TF prioritise which prototypes to try, and get some developers and designers to help us work with this.
CH: One thing to consider early is the number of prototypes. We may end up with overlapping prototypes, and if we work out which ones we want to move forward we can address several concurrently.
JS: Should we talk about that before we have the final report done?
CMN: There is a lot of value in encouraging people to prototype something, and show it, so we can see what good bits we want to keep, as well as trying to push specific paths we decide on.
Kelsey: with user testing, is there felxibility about how we do it? Ideally we can do it before, during, after developement. Are there specific guidelines on what we should be doing?
CH: I have some opinions... we
should determine that a prototype is ready to test. In testing,
we should have a fairly common base methodology.
... a simple written statement can help allow multiple people
to conduct testing and be able to usefully compare their
results.
... we have to test including people with disabilities as part
of testing.
[general agreement on that point].
Kelsey: Maybe there is an opportunity to test before developing, to guide the developemnts
CMN: It is useful to do testing before development, but I would avoid trying to formalise the process on pre-development testing, sowe minimise constraining thinking and work that has high cost for little extra benefit. I think it is important as CH said to have testing that is consistent post-development, so we can compare results across different tests and different prototypes tested.
Kelsey: Hope we don't stop people from doing early testing by being too tied up in methodology and formal requirements at that stage.
CH: we are trying to find out whether what we do is usable - including for people with disabilities. SO we need some heuristics that explain what are we trying to find out / check, and what is a way to discover that.
JS: We can share that so people working on prototypes can be guided. But doesn't it vary by what peice of a prototype we are trying to do?
CH: we may have less testing for e.g. a new way to write success criteria
JS: So how do we approach this? I am looking for help in this area
CH: Think we should have some general guidelines on how to do this, without putting constraints on what people do.
[adjourned]
<jeanne2> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/?:/Imelda/ Succeeded: s/?:/Imelda/ Succeeded: s/atmoic/atomic/ Succeeded: s/the terms/the terms in use/ Succeeded: s/I feel confident we could make the current stuff/...I feel confident we could make the current stuff in by 2020 and do not want to work on getting new material in over this summer but it is something to think about./ Succeeded: s/was solved/... was solved/ Succeeded: s/2.0/WCAG20/ Default Present: chaals, Charles, Jeanne, JohnM, Imelda, Kelsey, Luis Present: chaals Charles Jeanne JohnM Imelda Kelsey Luis Regrets: Shari Found Scribe: chaals Inferring ScribeNick: chaals Found Date: 30 Mar 2018 People with action items: js WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]