Finding things

Search is the payoff. Everything else in the app is data entry in service of one moment: you want a thing, and you would like to be told where it is.

Search by meaning, not by name#

Bin by Bin runs a semantic search. It compares the meaning of what you typed against the meaning of what is recorded, which is why "the blue camping stove" finds an item filed as a two-burner propane burner, and "something for cutting tile" finds an angle grinder.

This matters more than it sounds, because the failure mode of a keyword-only inventory is that you have to remember the words you used. If you could reliably remember what you called things, you would not need the app.

Keyword matching still runs alongside it. Exact names, prefixes and part-words all work. Semantic search is added to that, not swapped in for it.

Confident results, then "Broader matches"#

Results come in two tiers, separated by a Broader matches divider.

Above the line are confident results: semantic matches plus solid keyword hits. Below it are looser matches: things that share a fragment of what you typed and might be what you meant.

The divider exists so the app can show you the long shots without pretending they are answers. A search that returns nothing is unhelpful; a search that puts a weak guess at the top and lets you believe it is worse.

Local and server results are blended#

Each search runs in two places at once: the server, which does the semantic work, and the on-device database, which knows about everything you have entered whether or not it has synced yet.

The two are merged and de-duplicated, semantic results leading each tier. The reason is specific and practical: without it, an item you added or scanned two minutes ago on a bad connection would be invisible to search, which is precisely when you are most likely to go looking for it.

Offline, search keeps working against the local database alone. You lose the semantic layer and keep the keyword matching.

Tags#

Tags are free text and they are searchable, which makes them the right tool for anything that cuts across containers: a project, a color, a season, "fragile".

This is the answer to the temptation described in Rooms, bins and items: when you want a category that spans physical boxes, tag it. A bin has to stay a place you can walk to; a tag has no such obligation.

Barcodes#

The mobile app scans barcodes, stores the code on the item, and tries to look the product up. It checks UPCitemdb first and falls back to Open Food Facts, which is the better of the two for groceries.

If either knows the product, the name, description and tags fill themselves in, but only where you have left them blank. Anything you have already typed is never overwritten. If neither knows it, the code is still saved, and you name the item yourself.

The lookup leaves your device. The barcode is sent to those two public catalogs, on self-hosted setups as much as on cloud. Nothing else about the item goes with it (not your photos, not the bin, not who you are), but if you would rather nothing left at all, type the code in by hand instead of scanning.

It earns its place with consumables you rebuy by exact specification: the right filament, the right dye lot, the right cartridge. Scanning the old packet beats transcribing a fourteen-digit number.

When search comes back empty#

Usually one of three things:

• It was never entered. The most common answer, and the app cannot help.
• It is inside a bin that was scanned but not reviewed carefully, so the item exists in the photo and not in the list. Open the bin and look at the picture.
• You are searching for the container when you want the contents, or the reverse. Both bins and items are returned, and they are labeled: check which kind of thing came back before concluding it is missing.