Attendees

 Colin, Anastasia, Dana, Jonathan, Jess, Kevin, Sepideh, Michelle

Links

Wiki page:

https://wiki.fluidproject.org/display/fluid/Inclusive+Design+Guidelines+for+Good+Practice

Why are we doing this?

• from the P4A DoW:

• • Identify good practice guidelines for internal project use as they pertain to business practices, infrastructure design and user experience design for required transactions.

• • Outline initial good practice guidelines for external use.

• • 1st iteration for February 2016

• tie in with Floe - a "miniaturized" ILDH

• a way in to the ILDH (an on-ramp?) - easier to consume - concise - a way to get started and then dive in deeper

Who will use the guidelines?

• anyone interested in building inclusive content - designers, developers
• our collaborators - want basics on how to get started (design, development, content) - how to meet policy, how to improve accessibility
• P4A - other SPs - determining how end users will enter the system

What will the guidelines contain?

•  depending on the audience - we may want to communicate different things

• • do we want to make different versions for different users? e.g. high level info about meeting policy vs. ARIA labelling and other technical details

• • a deck of cards? each card is a specific detail

• POUR - perceivable, operable, useable, robust

• we add another P - personalizable, configurable

• Jutta’s 3 dimensions of inclusive design

• multiple levels of information - overarching values and specific details (i.e. how do I build it?)

• much of this information is “out there” already - how do we bring it together, "package" it in a way that is more easily consumed?

• cards give user the ability to jump to the info they want

• cards are informal, allow trying new things - shuffle the deck, serendipity… 

• we need to balance the abstract and the concrete (want to avoid too much abstraction - want to make sure there is concrete information available)

• look at the Inclusive design handbook (in addition to the learning handbook)

• user states and contexts - concrete tool that also conveys principle of mismatch

• guidelines will be indexed in DSpace

• "business practices" referred to in DoW - not part of the design guidelines we are creating, but we could package them in a similar way if we choose to - business models used, transactions

• express the what, not the how - guidelines, goals and reasons why/value without being overly prescriptive

• SP1 interviews, survey results summary, personas development - principles and guidelines that came out of this - broad user group - will apply beyond P4A - perhaps link to these guidelines from SP1 report instead of writing something new/separate?

• how does this link to SP4 work? should inform work on performance indicators - measuring against a baseline - e.g. asking have guidelines been followed? is the infrastructure we built enabling the ecosystem we want?

• Dana to send minutes out and arrange another meeting - perhaps next week