Eye mouse 'eyeCan' - 1st offline
Design Dive UX Team
Engineering part — Pleasant Charles
2012.08.01
Decisions after the first offline
1. Positioning: focus on clear, simple communication.
2. Meeting time: Wed 7:30 AM + Sun 4 PM (from August 12).
User-trial notes
1) Terminology and explanations are in English.
2) Very heavy.
3) Posture has a big effect.
4) Initial setup is absolute coordinates, but the interface is relative coordinates.
5) The reference is pupil motion, not field of view.
6) In band form, adjusting the camera position is tricky.
7) Wearing it over glasses is inconvenient.
8) Curious about usability on the high-end product.
9) The larger the screen, the easier the control.
Shared take-aways from the notes
→ 1) The interface is designed around physical references (the mouse), not around the target user.
2) The actual primary user is the elderly. The written explanations and terminology are too difficult.
Exploring alternatives
An interface composition grounded in user testing.
A new UI, UX needed.
Needed (reflect the voice, apply simple, clear delivery elements).
Korean translation needed (beyond just the explanations — down to the terminology).
Customize (user-environment settings).
Related materials (eye movement — for patients / for the general public / research materials).
Gather supporting analysis data (eye tracking, questionnaires).
Guide for downloading the typing program and on basic provision or Windows settings is needed.
One eye works better with absolute coordinates; both eyes with relative coordinates.
(Keep in mind: with absolute coordinates, less separate learning is needed.)
Use a fully fixed tab bar to lock the core UI zones in place.
Because the functional scope targets people with disabilities — not the general public —
more concrete alternatives that account for their usability are needed.
Fundamentally, reconfigure the IA for the functions.
Check interaction for up/down, left/right; need to research info on finger ballet.
Technical questions (for developers)
1) Relative vs. absolute coordinates.
2) Can the camera position be changed?
3) The reason for adopting the keyboard program, and the possibility of accepting other interfaces.
4) History of the navigation-position choice.
5) History of the UI composition (two-column).
Focused study items (by August 8)
1) Software installation.
2) Eye movement.
3) Check basic Windows input-interaction elements.
4) Analyze existing competitors (tools, source analysis).
5) Define language patients urgently need (breath, phlegm...).
6) GUI to replace the keyboard.
7) Basic UI elements.
8) Draw the IA.
9) Task Analysis.
