Colin, Anastasia, Dana, Jonathan, Jess, Kevin, Sepideh, Michelle
Why are we doing this?
- 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