Wishwell

The awkward part is that a claim has to be two contradictory things at once. Public enough that nobody buys the same gift twice, and private enough that the surprise survives. So Wishwell answers the question differently depending on who is asking, and enforces the difference on the server rather than in the interface.

The other half of the problem is the list itself. A row of links is not something anyone enjoys shopping from, so every item has room for photographs, a short video, and the reason it is on the list at all, which turns out to be the part people actually read.

The two bugs that mattered most were only found by driving the application, not by reading it.

The first was visible. Claiming a gift from inside an item view opened a second dialog on top of the first, and two translucent scrims stacked into something close to black. The screen appeared to go blank at the exact moment somebody was trying to give a present. The fix was to stop nesting: the item view now claims in place, inside the surface that is already open.

The second was worse, and quiet. A two-step delete button switched itself from a plain button into a submit button inside its own click handler. The browser reads that attribute after the handler has run, so the first press submitted the form. One click removed an item, or an entire list along with every claim on it. It is never a submit button now, and asks the form to submit explicitly on the second press.

Both are covered by tests now, which is the only reason they stay fixed.

The application is complete and runs locally: accounts, list and item management with real uploads, the shared list, the whole claim lifecycle, a buyer’s dashboard, notifications, and the privacy and gifting settings that govern all of it. It is not deployed. The data layer is a local SQLite file kept behind one module, so a hosted database can replace it without the rest of the app noticing.

The demo content is written the way a person would write it, and every photograph is credited. None of it is presented as a live service.

Most of what I took from this was interface work on a product whose content is photographs and video rather than text. The media is taken from other websites too, off the product pages where the thing is actually sold, rather than shot for the app. Designing around images you did not make and do not control is a different problem from designing around copy you write. They turn up at every shape, quality and orientation, and the page has to hold together whatever arrives.

That is where most of the usability decisions came from. How much room an item gets is worked out from the item rather than set by hand, a video sits inside the item instead of hanging off it as an attachment, and on a phone the photographs run edge to edge so a list reads like something you look through rather than a form you fill in.