- From: Jeanne Spellman <jspellman@spellmanconsulting.com>
- Date: Fri, 30 Mar 2018 08:23:17 -0700
- To: Silver Task Force <public-silver@w3.org>
- Message-ID: <46e7ff76-76e5-9b5e-ffde-99451b260fa1@spellmanconsulting.com>
Formatted version of minutes:
https://www.w3.org/2018/03/30-silver-minutes.html
Text version of minutes:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Silver Task Force Teleconference
30 Mar 2018
Attendees
Present
chaals, Charles, Jeanne, JohnM, Imelda, Kelsey, Luis
Regrets
Chair
SV_MEETING_CHAIR
Scribe
chaals
Contents
* [2]Topics
1. [3]Moving the meeting time (initial discussion)
2. [4]Categorizing ideas from Table 5
3. [5]Prototype strategy
4. [6]Information architecture
5. [7]Prototype design
* [8]Summary of Action Items
* [9]Summary of Resolutions
__________________________________________________________
<scribe> scribe: chaals
Moving the meeting time (initial discussion)
<jeanne> 1 pref for moving Tues. ! for Friday, lots of people
can make it work.
Categorizing ideas from Table 5
JS: It's in the phase 3 folder, and there are results by
tables.
<jeanne>
[10]https://docs.google.com/document/d/1XDOmjQkMRqQ0XKiKYA-mDAu
A40oHtaXNl1H0NXLcV80/edit?usp=sharing
[10] https://docs.google.com/document/d/1XDOmjQkMRqQ0XKiKYA-mDAuA40oHtaXNl1H0NXLcV80/edit?usp=sharing
[11]results for table 5
[11] 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>
[12]https://docs.google.com/document/d/1zTij1pH9NumEmMJoTFlsnpk
UHpM6SmP852jmkNDjAd0/edit?usp=sharing
[12] 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.
Prototype strategy
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:
[13]https://github.com/w3c
[13] 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:
[14]https://codepen.io/hallmedia/full/zWpoEd/
[14] 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?
[15]https://www.w3.org/TR/WCAG20/
[15] 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
[16]https://www.w3.org/TR/WCAG20
[16] https://www.w3.org/TR/WCAG20
<Charles> the ISO style guide for how to write standards using
“plain language”:
[17]https://www.iso.org/files/live/sites/isoorg/files/developin
g_standards/docs/en/how-to-write-standards.pdf
[17] 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
Information architecture
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.
Prototype design
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.
Summary of Action Items
[NEW] ACTION: JS to check what it costs to use the ISO standard
on Plain Language
[NEW] ACTION: JS to Talk to people who know about whether the
Plain Language standard is suitable.
Summary of Resolutions
[End of minutes]
__________________________________________________________
Received on Friday, 30 March 2018 15:23:34 UTC