Independent product · Android, backend & cloud
An accessibility assistant needs more than a convincing answer. It needs the right context.
Keep the question and its evidence together · Explanatory diagram
Frank is intended to help blind and low-vision users ask questions using voice and current camera context. The difficult part is not simply producing a spoken answer. It is ensuring that the answer relates to the right request, uses sufficiently current evidence and respects the limits of what the product should attempt.
I own the Android client, backend and cloud deployment. Android is in internal testing; iOS is planned. The product runs without additional hardware, although users can choose connected equipment for convenience. Its current stage is product development and research, not broad accessibility validation.
Frank is an accessibility assistant for blind and low-vision users. I built its Android client, backend and cloud deployment, bringing together voice interaction, on-demand camera context and user-controlled memory.
Frank is a long-term personal product developed through Idumet. It works on Android without extra hardware; connected hardware is optional.
A stale-image failure became an important engineering lesson: a fluent answer is not useful if it describes an earlier frame. The system needed to keep the question and its visual evidence together.
I added request/frame association, freshness checks and regression tests. I also worked on cancelling superseded requests, so old work does not quietly become the answer to a newer question.
The Android client communicates with an authenticated REST and WebSocket backend. The control layer tracks context and evidence rather than treating every provider response as immediately ready to present.
Testing covers failure paths such as stale frames, reconnection and provider errors. My October 2026 implementation record reports 92 server tests and 29 Android unit tests passing at specific revisions. These are dated automated results—not a guarantee of real-world accessibility or current service reliability.
Memory is useful only if the user has a say in it. I implemented owner-scoped review and deletion rather than treating saved context as something the user cannot inspect or change.
Frank is not a navigation or crossing-safety system. The implementation includes refusal handling for crossing and movement-safety requests before calling an AI provider. That boundary matters more than producing an answer to every question.
Testing and research so far include one hands-on product test, eight demo-based research interviews and one advisory review.
The next step is more physical-device testing, including retesting the capture changes with users.
The following decisions connect the implementation to its practical constraints. Each separates what I changed from what still needs verification.
Different evidence answers different questions. This record distinguishes a visible demonstration, implementation history and validated operational outcomes.
What it supports: The October 2026 record reports 92 server tests and 29 Android unit tests passing at specific revisions.
What it does not establish: Counts describe those revisions and test scopes, not real-world accessibility, present uptime or universal correctness.
What it supports: One hands-on product test, eight demo-based interviews and one advisory review informed development.
What it does not establish: People who watched a demonstration are not counted as hands-on testers. The sample does not establish broad user validation.
What it supports: Shows the intended interaction and product direction.
What it does not establish: A demonstration is not proof of safe performance in all environments.
The stale-frame issue changed the emphasis from answer generation to evidence handling. A useful assistant needs to know when its context is inadequate, not only how to produce a response when context is available.
The next stage is physical-device retesting of capture changes and further testing with users. That work should examine failure recovery and accessible interaction as well as successful answers. These remain next steps, not completed validation claims.