Douku

Background

I developed Douku for my girlfriend to manage her bead supplies and patterns. The starting point was a practical need: choose a pattern, find its colour codes, check whether there is enough material and record what gets used.

As the project’s sole maintainer, I initially spent considerable time refining the interface for phones, tablets and computers. Feedback from testing then shifted the focus to practical tasks such as managing patterns, adjusting stock and recovering data.

Design

Each project centres on one pattern, using familiar colour codes and material lists. The design assumes that users buy beads in batches and are unlikely to count every remaining bead. Features therefore focus on finding colours, adjusting stock and recording material use.

Account recovery also evolved. The original registration flow required users to download their account credentials. A review of that experience led to an optional download with a reminder to save them. Users can enter the application directly and view or copy their account code in settings.

Pattern import follows three stages: locate the legend, interpret its codes and quantities, then let the user review the list before updating inventory.

Implementation

The application uses a JavaScript PWA client, an Express API with SQLite, and a Python FastAPI recognition service. After locating a candidate region and running OCR, the parser identifies colour codes, normalises quantities such as x142 and associates records by position.

The client stores inventory, history, patterns and pending changes in IndexedDB, using a versioned API and persistent outbox to synchronise data. The interface distinguishes pending uploads, conflicts and recovery. Heavy inference runs in a thread pool, with bounded admission and serial access to the shared engine. Readiness checks cover the database and model.

Challenges

• Keeping the workflow familiar. Testing exposed a pattern identifier that duplicated the project name, terminology that added unnecessary learning, and colour code examples that did not match real use.
• Recognising legends in different layouts. A vertical pattern failed recognition during testing. By saving and inspecting images from each stage, I traced the problem through cropping, recognition and parsing, and identified consecutive numbers as a useful feature for distinguishing a ruler.
• Making sync notices actionable. The initial interaction assumed use on one device. In practice, a persistent notice about one unsynchronised item gave no way to identify it. The interface did not show which record needed attention.

Solutions

The revised project page follows the process of making one pattern, with consistent colour search and examples, and features narrowed to everyday needs. Saving account credentials became a user choice, with viewing and copying still available in settings.

Ruler detection now checks consecutive integers, alongside layout, colour variation, edge density and text density for locating the legend. Intermediate images support inspection of cropping, recognition and parsing. A review step lets users correct the material list before changing stock.

The sync protocol rejects writes based on outdated revisions and stores mutation identifiers and receipts. Within retained receipt history, an identical retry returns its recorded result; the outbox preserves requests whose outcome is uncertain. A separate view lists pending records and offers an action to retry synchronisation. Supported conflicts offer local or cloud choices, while other cases retain data for recovery.

Outcomes

Douku connects pattern recognition, material review, project planning and inventory updates in a working application. Offline editing, conflict handling and recovery improved through successive iterations.

These improvements came from testing and actual pattern images. The project page follows the process of making one pattern, recognised material lists can be reviewed and edited, and sync notices provide a way to inspect records and retry an upload.