MouseTrap Requirements

(Difference between revisions)
Jump to: navigation, search
Line 2: Line 2:
  
 
==Questions==
 
==Questions==
 +
(The following are questions intended as jump-off points for discussion during the meeting)
 +
*Rewrite using current GTK and OpenCV APIs?
 +
*Small, single-purpose module that enables the user to use *other* applications (including assistive applications), or application that encompasses multiple features?
 +
*Focus on forehead, or scrap and use OpenCV's newest haars APIs (related to #1)?
 +
*How to account for spasticity -- should this be a priority or worked on down the road?
 +
*There are a number of features in Mousetrap that never worked in the first place, but intended for future development (finger-tracking, plug-in architecture), should those be preserved, or scrapped? (related to #2)
 +
*Priority: to fix, or to introduce something that works?
 +
*Interface -- should it be simple, or full-featured? Should it simply be a program that moves the mouse with head movements, and leave the other features to other applications (Dasher and built-in on-screen keyboard and so forth)?
 +
*"Personas" and HCI -- to be discussed (different people with differing needs/disabilities) -- should we account for this, or try to design for a "wider audience" and work on more specific cases later?
  
 
==Meeting TBD==
 
==Meeting TBD==

Revision as of 19:30, 12 April 2013

Contents

This page was created to address Mousetrap's formal Requirements

Questions

(The following are questions intended as jump-off points for discussion during the meeting)

  • Rewrite using current GTK and OpenCV APIs?
  • Small, single-purpose module that enables the user to use *other* applications (including assistive applications), or application that encompasses multiple features?
  • Focus on forehead, or scrap and use OpenCV's newest haars APIs (related to #1)?
  • How to account for spasticity -- should this be a priority or worked on down the road?
  • There are a number of features in Mousetrap that never worked in the first place, but intended for future development (finger-tracking, plug-in architecture), should those be preserved, or scrapped? (related to #2)
  • Priority: to fix, or to introduce something that works?
  • Interface -- should it be simple, or full-featured? Should it simply be a program that moves the mouse with head movements, and leave the other features to other applications (Dasher and built-in on-screen keyboard and so forth)?
  • "Personas" and HCI -- to be discussed (different people with differing needs/disabilities) -- should we account for this, or try to design for a "wider audience" and work on more specific cases later?

Meeting TBD

Requirements

Use Cases

Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox