Today is the first day of eyeskills.org. This project was actually started almost three years ago, when my eldest son developed lazy eye at the age of one year old… Continue reading “Hello world!”
What is the guiding light which we are following while we build the EyeSkills framework? You can find out more here…
This is an open design document, explaining the rational behind the evolution of the framework.
With more experience and evidence, many of these elements may change in unpredictable ways – it is a work-in-progress.
In Iteration 1 we had a participant flow which went through a series of calibration scenes covering different aspects of vision (e.g. Monocular vision present? Biocular vision? Depth perception?…). These scenes were originally focused on building up a calibration object which could describe the participants visual abilities, to then calibrate the “main” part of the app which would be games developed by third-parties.
We have identified four underlying motivations for the project. Whilst these build atop one another, we try to isolate them conceptually to help us manage our limited development resources.
Aspect 1 – Demonstrating the impossible is possible – Guided – Verifying abilities
Our user tests established the validity of checking and exploring the visual abilities of a participant in the following order:
The first iteration focused on technical feasibility and laying out an initial foundation we could build on.
We split the project into three core sections :
What are EyeSkills building?
We are building tools to help people with amblyopia and strabismus (lazy eye) have a chance to learn more about their condition, their visual system, and even to open up some opportunities to overcome and even correct their condition.
When building software, one is creating a simplified model of reality, capturing those parts which are relevant to achieving the system goals. This model is not generally not built to be passive, it should then interact with reality to alter the nature of reality. It’s an interesting feedback loop called “active modelling”. If we don’t iteratively test as we design and build, we will inevitably design systems that fail to capture reality and fail to then interact with it as desired. This is particularly true of systems which interact with people. Continue reading “Why is designing EyeSkills difficult? – a quick note”
Each user test is an exciting event. Each user test throws up at least half a dozen “aha” or “why didn’t I think of that” moments, driving on and further inspiring development. In our most recent user test (yesterday evening with Mr R) there were some obvious but useful minor improvements we could make to help practitioners, and a couple of major issues were also raised about determining what the participant is really perceiving.