PGA Co-Design Meeting Notes: 2015-01-16

Owned by Anastasia Cheetham
Last updated: Jan 20, 2015
3 min read

Attendees

  • Anastasia Cheetham
  • Michelle D'Souza
  • Cynthia Jimes
  • Kate Katz
  • Jess Mitchell
  • Madeleine Rothberg
  • Rich Schwertdfegger
  • Sepideh Shahi
  • Shari Trewin
  • Gregg Vanderheiden
  • Amy VanDeVelde

Agenda

Resources: Latest designs

  1. Review of latest wireframes, agreement to identify them as "Iteration 1" for development
  2. Revising February and April deliverables
  3. User testing protocol
  4. Update on Thursday's call with NIDRR
  5. Responding to NIDRR feedback
    1. Where possible, make changes directly to the document.
      1. clarify what "getting in the door" means in different application areas, what would the next phase be
    2. Where necessary, add additional or supplemental materials.
      1. consider creating "design requirements" for different application areas
    3. Create some sort of cover page that quotes directly their feedback, how we addressed it, and references to where those changes appear.

Notes

Anastasia's notes:

1- Quick review of latest wireframes

Plan: Give these designs to development team to get started with; doesn't require locking the designs in

Help: still need to figure out what to do with that "help" button

Q from Shari: Why slow keys and not other keyboard prefs?

A: This is only an exploration of what such a screen might look like if we included it.

Shari wants more discussion on what a screen for keyboard settings ought to look like; agreed.

Gregg: new layout great; having the mute onscreen always is good idea; whether or not these are the right screens: we still need to work that out. Also, num of icons along bottom of screen might change. Agreed

 

2- Timeline:

Milestones: mid-Feb (cross-setting features) and end of April (application-setting-specific features)

but now, everything is cross-setting

Next week, tech team will task out the work and identify what we hope to have ready for mid-Feb.

NIDRR: ok to break things up in a different way

 

4- Update on Thursday's call with NIDRR

Regarding NIDRR's comment that we weren't stressing enough of the differences between application areas:

What was not clear was the particular phrase "get in the door" – what does that mean, and what does it look like in each of the application areas? How will our tool accomplish FD in each application area? If actually accomplishing FD in an application area is not possible in this scope of this project, be clear about that. We have started to articulate our answers to this question in the google doc "Getting in the Door  - definition and application areas." We'd like input from stakeholders as to what FD means in their application area, and are we able to accomplish fd with the proposed tool and in the scope of this project?

Als: assessment and IEP: Is an IEP an input to FD?

What does it mean to "use" the system in a given application area?

Gregg: able to "use the interface" - they can perceive the information,

(Amy?) Would this mean that endpoint of fd in assessment is "taking the test"? What about IEPs? they might specify which kinds of supports are allowed, so prefs may not be relevant. There are interesting questions.

We need to discuss this question, we need to take IEPs into account. It's not a separate question from FD if FD is "getting to the point where you can take the test"

AC: first task: draft text describing "getting in the door" in each app area and how it fits into ecosystem

Gregg to create a Google document, Madeleine to add some draft text.

 

5- Responding to NIDRR feedback

a) Where possible, make changes directly to the document.

        AC: a new version of the doc is underway: "PGA Requirements Doc - Revised"

b) Where necessary, add additional or supplemental materials.

        AC: we've started some discussion documents for this

            consider creating "design requirements" for different application areas

            suggested names: "Design recommendations and notes"

            distinguish between ideas and recommendations (suggestion vs. best practice)

c) Create some sort of cover page that quotes directly their feedback, how we addressed it, and references to where those changes appear.

        our current discussion page is a start

    

Kathy: NIDRR didn't get response to Workshop feedback. Some of NIDRR's questions might make more sense int he context of the feedback from the workshop document, so construct our response as being to both feedbacks

 

3- User testing protocol

We need to develop these so we can user-test early and often

Shari: Do we want to test the paper prototypes?

Shari and Dana will start on this

 

Final thought:

Gregg: We don't actually answer the questions "Does this person need to have auditory information presented visually?" "Does this person need to have visual information presented auditorially?" etc. These are FD things - we need to know them. This has impact on effect of IEP: What if IEP says "no audio" but FD says "this person absolutely requires audio"