Behind the project

How Movement Lab works

Movement Lab is deliberately simple: a collection of accessible web pages that run directly in a browser, require no account and keep practice data on the visitor's own device. It is also openly developed with help from ChatGPT. This page explains both the technology and the human approval process so other people can learn from it and build something similar.

Why a static website?

A static approach keeps the project inexpensive, quick to load and comparatively easy to understand. Most exercises can work without sending information to a remote service. It also means each activity can be opened on a phone, tablet or computer using an ordinary web browser.

How an exercise works

Each exercise is normally a self-contained HTML page. The page describes the task, displays its controls and contains the JavaScript needed to run it. Shared files provide the navigation, visual style and private progress functions.

1. The visitor chooses an exercise.
2. The page listens for an appropriate input, such as a key press, tap, click, drag or pointer movement.
3. The exercise updates the screen immediately with clear feedback.
4. When a session is completed, a small summary can be passed to the shared progress system.
5. The visitor can stop at any time; the exercises do not require a fixed session length.

Touch and pointer input

Browser pointer events allow one exercise to support a touchscreen, mouse, trackpad, stylus or compatible assistive pointing device. Controls are made deliberately large, spacing is generous and speed is not treated as the main measure of success.

For example, Target Tap places a large target within a chosen movement area. A successful pointer interaction moves the target, while an inaccurate tap can be counted without ending the session or presenting it as failure.

Private progress storage

Practice history is stored using the browser's localStorage feature under a project-specific key. The saved record can include values such as the exercise name, date, accuracy, attempts, duration or a short summary.

This information stays in that browser on that device. Movement Lab does not require it to be uploaded to a central user database. Clearing browser data, using private browsing or changing device can remove or separate that history.

Accessibility approach

Accessibility is treated as part of the exercise design rather than a later addition. The project aims to use semantic headings, labelled controls, visible keyboard focus, plain instructions, responsive layouts and feedback that does not rely on colour alone.

Exercises should also avoid assuming which hand a person uses or why they are practising. Where possible, difficulty, target size, movement range or input layout can be adjusted without turning the activity into a competitive test.

Development and release workflow

Changes are made on a separate development branch first. Cloudflare Pages publishes that branch to a review site so the change can be tested on real devices. Once it has been reviewed and approved, the tested change is promoted to the main branch. The live site is then deployed from main to the VPS through Plesk.

1. Choose one coherent improvement.
2. Review the existing code before editing it.
3. Implement and commit the change on development.
4. Test the Cloudflare Pages development preview, especially on the intended input device.
5. Collect human feedback and make corrections if needed.
6. Promote the approved change to main.
7. Deploy the live site from main on the VPS through Plesk.

A repeatable AI-assisted workflow

1. Describe the problem in practical terms, including who the feature should help.
2. Ask the AI to inspect the existing project rather than generating an unrelated replacement.
3. Keep each change small enough to understand and test.
4. Require the AI to work on a development branch.
5. Review the preview on the devices and input methods the intended audience will use.
6. Give concrete feedback about wording, movement, fatigue, accuracy and accessibility.
7. Publish only after a person explicitly approves the tested version.
8. Keep GitHub history so changes can be reviewed or reversed.

This process is especially useful where fatigue, dexterity or technical barriers might otherwise make sustained development difficult. It allows a person to direct a real software project through conversation without surrendering ownership or final judgement.

What the AI is not trusted with

AI-generated code can contain mistakes, misunderstand an accessibility need or produce an interaction that looks correct but feels poor in real use. For that reason, no AI output is treated as automatically safe, clinically valid or ready to publish.

• It does not provide medical diagnosis or prescribe rehabilitation.
• It does not publish changes without explicit approval.
• It should not be given passwords, private keys, access tokens or unnecessary personal data.
• Its code and wording must be tested by people, not accepted simply because they appear plausible.

Adding another exercise

A simple new activity can be added by creating another page in the exercises folder, linking it from the exercise index and optionally recording a session through the shared progress script.

• Start with the movement or cognitive skill being practised.
• Keep the instructions short and literal.
• Provide an untimed or low-pressure mode.
• Use controls large enough for reduced dexterity.
• Test keyboard, touch and screen-reader behaviour where relevant.
• Store only the minimum information needed.
• Explain that the exercise is not medical advice.

Limitations

A browser exercise cannot assess a person's condition, prescribe therapy or know whether a movement is clinically appropriate. Local browser storage is convenient but is not a medical record or a synchronised account. Different browsers and assistive technologies can also behave differently, so practical testing remains essential.