Skip to main content
← Blog

Preparation Is Where fecit Touches the Real World — A Day Tidying the Preparation Section

VauDium·

A task app lives inside the screen. But the work happens in the real world. Materials, tools, venue, personnel, paper — these five kinds of preparation items are where fecit points at reality, so today I held onto that one axis. The catalog versus the task, remove instead of delete, photos that follow, and checks that survive rapid tapping.

Preparation Is Where fecit Touches the Real World — A Day Tidying the Preparation Section

A task app lives inside the screen. Title, date, notes, a checkbox. All of it is text. But the work happens in the real world. A shoot needs batteries, a class needs handouts, an exam hall needs your ID.

In fecit there is exactly one place that points at real things, places and people: the five kinds of preparation items in the Preparation section — materials, tools, venue, personnel, paper. The other fields are for “what and why.” Preparation is for “what has to be in your hands that day.” This is the axis I want to use to connect the real world and fecit. So today I spent the whole day on it.

1. The catalog is what you own; the task is what you pack that day

Preparation items live in two places in fecit: the catalog and the task. The catalog is a personal store of the materials, tools and venues you own. A task’s preparation list is what you need to bring that day. You pick from the catalog and attach to the task, so the same camera can be attached to ten shoots.

The trouble was that the screens moving between the two looked almost identical. Tapping + on a task’s Materials screen opens the catalog picker, and its header also said “Materials,” so it looked like the same screen had opened one more time. Here is how I split them today.

  • A picker opened from a task now carries its origin in the header: Catalog › Materials. A screen entered from the catalog itself is already inside the catalog, so it gets no prefix.
  • The picker’s row grammar now matches the other selection screens. Tap a row for detail; tap the + on the right to attach and close immediately. I did not use a check badge that toggles attached and detached, because the same material can go into one task twice — there is no “attached” state to speak of.
  • If you search and nothing matches, you create it right there. The first row under the search box is always “Create New Material,” and the name you were typing carries over.

2. Remove, not delete

The detail screen of a material on a task has a button to take that material off. Until yesterday its confirmation read “This can’t be undone.” Reading it again, it was frightening. It read as if you were throwing the actual object away.

What actually happens is that the item leaves this task’s preparation list. The material in the catalog stays, and you can attach it to the next task. So I changed the wording to “Remove,” and added one line to the confirmation saying the catalog is untouched. Deleting a catalog item really is a delete, so that wording stayed as it was.

Where the app points at real objects, the vocabulary has to be exact. If erasing text on a screen and losing an object share the same word, people stop in front of the button.

3. A photo is the object’s face

Preparation items can carry a photo — materials, tools and venues, one photo per item. But until today, photos existed only on the task side. You couldn’t put a photo on a catalog material, so every time you attached from the catalog, the material arrived without one. Ten shoots meant re-attaching the photo ten times.

Today I added the same photo input to the catalog, and made the photo follow when you attach from it. The implementation is a reference copy. The file belongs to the same user, so instead of duplicating the file, only the reference is copied. Deleting the photo on the task side deletes the reference, so the catalog photo remains. It is the same principle as “remove” above: the task references reality, and reality lives in the catalog.

4. Surviving rapid taps

In the field, preparation items get checked fast. Packing a bag: tap, tap, tap. The bug I found today was betraying those taps. Turn on five in a row and only the first and the fifth would stay.

The cause was how saves were written. Saving one toggle assembled the whole model from the screen and overwrote the store. If that base was one render behind, any other toggle flipped in between vanished. Out-of-order server responses caused the same thing.

The fix is simple: don’t assemble the model. Patch just that one key in the store, and take only the version number from the server response. When keys differ, no arrival order can make them touch each other. I applied this principle not only to preparation checks but to section expansion, attachment visibility, and every toggle and picker on the settings screens. A checklist that lags your hand, or undoes it, can’t be trusted with reality.

Not done yet

  • You can’t attach a photo while creating an item. Create first, then add the photo in the detail screen.
  • Personnel and paper have no photos. That scope is intentional.
  • Today’s changes have not all been verified on a real device yet.

Lessons

The axis that points at reality must be more exact than the axes inside the screen. Text can be undone; objects can’t. So the vocabulary separates delete from remove, photos keep their original in one place, and checks have to keep up with your fingers.

When the same thing exists in two places, the screen has to say which one you’re in. Catalog materials and task materials share a name, and one header line tells you where you are.

Preparation was one of the thinnest axes in fecit. As of today it is a little thicker.