Skip to end of metadata
Go to start of metadata

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
  • No labels