PGA Co-Design Meeting Notes: 2015-02-18

Actual Agenda and notes 

 

  1. Progress report/timeline
    1. Update workflow image:
      1. Gregg would like to discuss with the group.
      2. Group agree/approves of new flowchart (no objections)
    2. Updated text to address items 0-3 and Cover page to address responses:
      1. Kate and Cynthia are working on this. Hope to have it ready to share on Friday 2/19
    3. Moving "Criteria" to a separate document (not incorporating into requirements)
      1. Everyone seems to agree, at least no objections
      2. Kate and Cynthia will follow up on this in the following weeks.
      3. Current focus is on Requirements doc changes, then will revisit this.
  2. Outstanding questions added to the Requirements Doc:
    1. Item (4) What exactly is output (of Capture and Pre-tool questionnaire) and how will it be treated in the first discovery tool itself:
      1. Gregg: there is no first capture tool -- but we could produce something using other prefs editing tools, in order to simulate it for the first discovery tool.
        Gregg: If the capture file contains a named value pair that exactly matches what the discovery tool generates, then that page can be skipped, or given a green check mark. It still needs to be confirmed at first discovery confirmation step.
        Q: Is an altered GPII file like this sufficient to communicate this requirement to the developers?
        A: Yes. However, we may still not build this within this task.
                  **Afterthought: This would still be useful to include in the architecture documentation of our final report (Deliverable 3.3)
      2. NOTE that none of the GPII preference editing tools – nor the Matchmakers – do any thing at all with the notion of a 'need.' They don't capture needs or respond to them.
        We concluded that the FD tool won't worry about needs, only preferences (though it's still helpful for the documents to define the two terms).
    2. Item (5) capture and sharing tools are under development in other projects and this fact might affect what can be done in this task order.  The reason for this is not clear.
      1. Discussion on previous item seems to cover this.
    3. Item (6) Requirement 19 and its discussion raises several issues: Please carefully describe how different preferences for different testing areas will be handled…
      1. Anastasia will consider the technical implications of this feedback and send some ideas about how to address it.
    4. Item (7) Are there other methods for ensuring the IEP mandated preferences are followed?
      1. Anastasia and Madeleine will discuss and make some recommendations
      2. Should be able to follow up with them on this by EOD tomorrow (2/19)

 

Next steps

  • Rich creating a list of task-centered requirements for each setting

  • Anastasia will look into responses to Items 6 and 7
  • Cover letter for revised requirements doc should be ready to review Friday (maybe Monday)
    Next week we continue with design and development interactions

  • Jess and OCAD team will let us know about a hosting a meeting re GPII Architecture.


Raw notes

It is something that we would like to consider for the future.
We don’t have a capture or pre-tool right now?
    That is correct

 

Part of the issue: we referred to the fact that it can pull in information? Is it different than the information

 

Could we say capture tool, may be able to answer two-thirds of the questions, and move forward to the confirmation step.
>> To confirm that

 

With capture tool, we might be able

 

Until capture exists, we can’t do this analysis.

 

Is there an associated requirement for this?
What is the requirement implication for the first discovery tool?

 

Sufficient parameters in those settings?
Where does that tool come from?

 

How are you storing your preference now?
Capture tools - They don’t exist.

  • We have seen demonstrations of GPII with files
  • So GPII files could be edited?
  • unless we can say how the tool would be behave differently, then

Gregg: there is no first capture tool -- but we could produce something, in order to simulate a first discovery tool.

 

If the capture file contains, a name value paired that exactly matches what the discovery tool generated, then that page can be skipped, or given a green check mark. It still needs to be confirmed at first discovery confirmation step. You could just do that one’s that aren’t covered.

 

Example: aging environment, shared preferences,


** We probably wouldn’t have that fit into the current build. But would really like to include that in the

 

Example: Person needs to be able to recognize and press a button. -- Getting in the door criteria. Get to that kind of a statement: For example: in OER setting: they should be able define it in terms of task-based, for each of the application settings. List tasks, and then listed.
When can we follow up on this? -- started for next week. - More follow up with NIDRR in just a few weeks.

 

** Does a capture tool capture in a format?
In terms of
-If someone has a first capture tool --


Item (6) -- Technical perspective about
Item (7)  -- when should I check in with Anastasia - by end of tomorrow.

 

Any given setting may be need or a preference for a given users.
“First group” of settings.  - what does this individual need or

 

We are collecting the answer to the question: “do you want audio on”
We don’t know if what we are collecting is a “need” or a “preference” - we just know that that is the answer to the current question.
We are collecting a group of settings that gets the user in the door.

 

We don’t know if it’s a need or not.

  • GPII

Is there a difference, once they enter into the next tool,
It’s a limit below/above which the use simply can not participate in the system.

 

Just go with preferences - GPII architecture is using “preferences”.
It will match what we are doing with GPII?

 

Explore the ecosystem of GPII.
Use the term “Needs and preferences” is best for funding. But in actual application preferences will be so application specific… capturing “needs” may not turn out to be that useful.

 

** Resources and timing issue… will get to it eventually.
** OCAD team will consider when would be the right time to introduce the whole group to the ecos