Every screen should expose a small number of choices so the user can focus on what's on the screen without any distractions. Status bar only appears where you want to see it.
Principle
Digital Minimalism
PocketInkOS was inspired by old PDAs. The OS favors deliberate entry points, monochrome UI, and pleasant UX as much as a small screen can deliver.
The design is shaped by a 200x200 e-ink display with 2 colors and limited refresh rate, leading to careful design approach, to tighten the UI elements to capture every touch accurately.
The system exposes features through an application-oriented interface inspired by monochrome mobile devices. Applications are displayed in a grid-based menu and function as self-contained UI modules within the shared embedded runtime. Unlike a general-purpose operating system, the platform does not implement process isolation, user accounts, or a Unix-like model.
Design record
UX Design Decisions
The UX priority is predictable operation on a small 200x200 touch surface with two reliable hardware buttons.
Touch is useful, but it is not treated as the only source of truth. Screens should avoid tiny hit targets, ambiguous taps, and destructive actions that depend on perfect touch accuracy.
Interactive touch elements should be large enough to select confidently on the physical display. If a control cannot be made large enough, the screen should use selection plus confirmation instead of immediate action.
When touch cannot be made reliable, use the PWR button as a deliberate confirmation step. This applies to destructive actions, dense grids, and screens where a wrong tap would be hard to recover from.
Show the current mode, selected cell, or pending action before committing. The user should understand what PWR or the next tap will do without remembering hidden state.
Design in black and white before adding texture. If a screen fails without gradients or dither, the structure is not strong enough.
Prefer static layouts and partial redraws where possible. Animation is allowed for demos and active tools, not as ambient noise.
The OS should remain useful without network apps. Online features live in a separate menu category and can be compiled out.
Runtime model
System UI Flow
The OS runs as a single active screen with optional active app ownership. switchTo() changes the screen, assigns an ActiveApp wrapper when needed, and marks the display dirty.
Rendering clears the framebuffer, draws the active screen, optionally overlays the quit dialog, then flushes the e-paper display.
Setup initializes serial, display, touch, environment snapshot, buttons, app state, and the button polling task.
Home shows the Pocket Ink mark, date/time when available, Wi-Fi status when network apps are enabled, and ambient/chip readings.
The launcher is a 3x3 grid. Categories are Games, Apps, and Network when ENABLE_NETWORK_APPS is enabled.
App screens draw through a common ActiveApp interface with draw, handleTouch, update, and hasActiveSession hooks.
After app state changes, apps must use a confirmation dialog before returning to the menu.