Andy Kopra
5f21d9099c
Direct-framebuffer ink pipeline (stock-quality strokes), finger-wipe erase, growable scrolling canvas with color-ghost cleanup, bidirectional toggle with a persistent 4-finger return launcher, instant button feedback. Includes prebuilt aarch64 binaries (dist/), build/deploy/install scripts, a user guide, and a complete technical reference. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
97 lines
5.1 KiB
Markdown
97 lines
5.1 KiB
Markdown
# Chatter — A custom application for the reMarkable tablet
|
|
|
|
## Background
|
|
|
|
I am helping someone who has a hard time speaking and who is using a
|
|
[reMarkable tablet](https://image.email.remarkable.com/lib/fe3511737364047c771479/m/1/e39f7595-fc99-4f8c-b7e3-dde042451668.pdf)
|
|
in conversations to write what she cannot say. I believe that the
|
|
reMarkable table is the best choice for a digital handwriting interface.
|
|
However, the tablet is designed for taking notes that can be preserved or even
|
|
transformed into digital text. It is not intentionally designed to be used as an
|
|
*assistive-speech device*. There are also a wide variety of customizable options
|
|
that are typically unnecessary if using the table in that way.
|
|
|
|
## Project goal
|
|
|
|
I would like to create a replacement for the reMarkable graphical user interface
|
|
(GUI) that would be tailored for using the table as an assistive-speech device.
|
|
This interface would not replace the standard GUI; choosing tablet settings for
|
|
the writing style or other interface parameters would still be done in the
|
|
standard GUI. This assumes, however, that the user can change settings as needed
|
|
in the normal way (or that technical help is available when necessary).
|
|
The goal here is to make the interaction with the tablet during conversation as
|
|
simple as possible.
|
|
|
|
The custom application's name is "Chatter", with the implication that
|
|
conversational interaction can be accelerated. The word also can refer to the
|
|
speaker as well as to the result of speaking.
|
|
|
|
## User-interface elements
|
|
|
|
In watching the user with the tablet's standard GUI, I have noticed a confusion
|
|
about whether writing or erasing is the active mode. A simple action like
|
|
clearing the page requires several user-interface gestures. The user's
|
|
inability to easily use the table is often not wholly due to a lack of technical
|
|
understanding but a failure to remember technical details when they are not
|
|
intuitive.
|
|
|
|
Chatter implements four actions, ordered here by their potential frequency of
|
|
use:
|
|
|
|
- *Erase part of the text* — This should be simple and intuitive gesture. For
|
|
example, I have seen the user wiping her fingers back and forth across some
|
|
text to erase it.
|
|
|
|
- *Erase the page* — Erasing the entire page should be a single gesture. The
|
|
blank page that results continues to use the current pen styling and other
|
|
parameters set in the standard GUI.
|
|
|
|
- *Save current text to a file named by time* — The current page is saved
|
|
with an automatically generated name that contains a human-readable text of the year,
|
|
month, date, hour, minutes and seconds. The seconds may not be necessary, but
|
|
I would rather have an elaborate name than risk losing a previously saved
|
|
file. These Chatter transcripts should be saved to a separate directory to
|
|
avoid cluttering the main screen. Deleting and renaming these files are
|
|
possible through the standard GUI; a tutorial about that should be provided if
|
|
the user expresses interesting in managing the transcripts in that way.
|
|
|
|
- *Toggle between the standard GUI and Chatter* — The standard GUI should still
|
|
be available through a single gesture; Chatter augments the tablet's interface
|
|
and does not replace it. However, returning to Chatter will require an
|
|
addition to the standard GUI that will be memorable for the user.
|
|
|
|
### Implementation considerations
|
|
|
|
If the table can differentiate between a fingertip and the stylus, then erasing
|
|
part of the text as well as the entire page could be implemented by a finger
|
|
gesture. Rubbing the finger back and forth of an area of text could remove any
|
|
drawing close to that area (where "close" might be determined experimentally
|
|
working with the user). A diagonal stroke with a finger from upper-right to
|
|
lower-left would be interpreted as a request to erase the entire page.
|
|
|
|
If differentiating between fingertip and stylus is not possible, then Chatter
|
|
should define some shortcut for the stylus that easily creates the standard
|
|
region-based erase gesture. For example, if the user circles an area twice,
|
|
that could signify erasure, not drawing. A stylus stroke from upper-right to
|
|
lower-left could specify whole-page erasure, even if the finger stroke
|
|
method is also possible.
|
|
|
|
The toggling the standard GUI and saving a file are not actions that the user
|
|
would frequently perform. I think that small icons at the bottom of the page,
|
|
activated by stylus or finger, would provide an ongoing reminder of how to do
|
|
those actions. The standard GUI will need to provide some way of switching to
|
|
Chatter; the user should suggest a method that she would find memorable.
|
|
|
|
|
|
## Deployment and refinement
|
|
|
|
A developer working on this project will install the custom GUI on the user's
|
|
tablet. After verifying that the installation is successful, the developer will
|
|
watch the user with the tablet to evaluate the current interface efficiency of
|
|
Chatter, talking with the user about what is missing and what could be improved.
|
|
Paying attention to the user's questions that begin, "Why does this..." and "Why
|
|
doesn't this..." will be very important in refining the design. I believe that
|
|
using a custom interface for the tablet might also inspire the user to suggest
|
|
other features that would not be obvious to the developers.
|
|
|