Polishing

Today started with a single word. Adding a web link on mobile, the description field’s placeholder read “Tactics”. Why would the word for battle plans sit in a box meant for describing a link?

An odd word is usually a leak

The cause was simple. The description input component falls back to a translation key called input.description when no placeholder is given. But that key’s value is “Tactics” — the label from the task domain. Correct on a task screen; the web link screen just never passed a placeholder, so the task’s vocabulary leaked into the link screen.

My first fix was to put the right word in: “Description”. Then a question surfaced. Wait — do we even put placeholders in description fields anywhere else?

Before fixing, find the convention

I audited every usage. The result surprised me. Tasks, projects, memos, routines, labels, contacts — nearly every screen explicitly passes an empty placeholder. The field label already sits above the input, so the app’s convention is to not repeat it inside the box. The only exceptions are places with genuine guidance text, like the example prompts in response rules.

So the correct fix wasn’t “insert the right word” — it was “leave it empty, per convention”. And once I looked for other screens with the same leak, there they were: the free board, overviews, market products, photo descriptions, notice bodies. All outside the task domain, all quietly showing “Tactics”. One sweep cleaned them up.

One odd word is rarely a problem with that one spot. It’s a signal that a default is leaking, and defaults rarely leak in just one place.

Same flow, same shape

While I was in the web links area, I looked at the list itself. Fecit already has a grammar for drawing “items attached to a document” — the linked tasks and memos list. A tree connector line drops from the section header and elbows into each row, tapping a row opens its detail, rows have comfortable height and a pressed background.

Only the web link list was different. No connector, flat rows, and tapping opened the browser instead of the detail. Same kind of list, different look, different behavior. I aligned it: connector line, same height, row tap goes to detail. Opening the URL moved to a > button at the row’s end — and even that wasn’t drawn fresh; the app already had a navigate-chevron component, so I reused it.

I initially added a delete × to each row too, then took it out. Delete already lives on the detail screen, and there’s no reason for a destructive button to sit permanently on every row of a list. Polishing includes removing as much as adding.

Commas in numbers

The last one was small. Preparation quantities and costs printed as raw digits — 1200000. Desktop already had a helper with a simple rule: if the value reads as a number, format it with commas; otherwise leave it untouched. I ported the same rule to mobile and applied it across all five preparation categories. Edit fields stayed untouched — commas are good for display, but commas mixed into input contaminate what gets saved.

---

Looking back, most of today’s work wasn’t changing code. It was finding the standard — what this app’s placeholder convention is, what grammar attached-item lists follow, which rule formats numbers. Once the standard was found, each fix was a few lines.

Polishing isn’t making things pretty. It’s returning the places that drifted back to the shape you already decided on.