In a big house used by many people, getting an overview of where things are is an interesting challenge. Last month, a small team gathered to explore better processes of making signs and maintaining inventories. With this blog post I want to give a sense of the sorts of problems we tried to tackle. Please reach out if you have solutions to recommend!

Our motivation

When a newcomer arrives in a place like Kanthaus' workshop (or even Kanthaus as a whole), they generally need help to find the things they are looking for. If knowledgeable people are around and available, that's great, but if not it can be quite a hurdle. With a good system to document where things are, we reduce that barrier and make users of the space more autonomous.

The knowledgeable people often feel responsible for the maintenance of the space and spend significant amounts of time sorting things into the places they belong to. With good documentation, this effort should also be reduced.

But it's not clear how to do it well! Organizing things into a physical space is a subjective process. It's tempting to put related things together, but opinions on categorization can vary widely. People also name things differently, even in the same language. A system that only makes sense to one person is unlikely to be of much help.

So we've been working on systems to help with this problem, with a focus on:

• streamlining the production of good labels, to go on shelves, boxes and other sorting containers
• maintaining an index of where each type of item is stored, to help with finding that item without having to visually scan a lot of places

Example: the bike workshop

When I first came to Kanthaus about 5 years ago, one of the things that made me fall in love with the place was how the bike workshop was organized. Let me show you what my experience is, as a user of the space.

Say I come in and am looking for a trailer hook, to attach a trailer to a bike which isn't equipped for that yet.

So many shelves and boxes! Where do I find my part? I could visually scan each shelf, but that would take quite some time. Instead, I can have a look at the index that is hanging in the entrance.

I can use this alphabetical index to look for "trailer hook" to figure out where it is stored. There are also entries in German ("Anhängerkupplung") and for synonyms ("tow hitch", "kupplung"…), so I don't have to use the same word as the person who came up with this system.

The location is described by a code: M11-2, which lets me find the box: it's in the Middle (M) shelf, on level 11, in the 2nd box from the left.

This is so satisfying! I can find the things I am looking for, on my own, in a workshop I don't know. I also notice that someone has put in a lot of effort into organizing the space to make it usable for me. It makes me very grateful and encourages me to play along, putting things where they belong according to this system. More than five years after this system has been put in place, it has required very little maintenance.

I like it so much that I would be keen to have something like that in use in other places in Kanthaus, such as in other workshops or storage spaces. But how can I make a similar index and labels?

Generating an index and signs

Felix, the author of this amazing system, wrote software to ease the creation of such indices and labels. It's called Flinventory. It takes:

• a list of the things you want to organize (with their alternate names, in multiple languages)
• a description of how your space is hierarchically subdivided (into rooms, shelves, boxes…), which defines codes for each location
• a list of where each thing is stored.

Supplied with this data, the tool generates the index for you, and lets you easily print labels (packing many signs on the same sheet to save paper). One of the things we did over the weekend was to have me try to use it to create a new inventory for another part of Kanthaus, and to identify usability issues.

Quickly came the question of whether we could reuse existing inventory systems, which would be more established and mature. For instance, we discovered Snipe-IT, Inventree and HomeBox, which are all about keeping an overview of where things are (among others). But so far, none of them seem to serve the use case above out of the box and it's not clear if any of them would be a fitting basis on top of which inventory generation and label printing could be built. Many of them have a focus on keeping an overview of stock, which isn't our goal (as we deal with many sorts of items that are often saved from various sources and rarely proactively re-stocked).

Another question is to what extent the list of things (parts and tools, in the case of a bike workshop) could be shared between multiple inventories, since the metadata (alternate names and pictures) should be mostly the same everywhere. Felix has indeed deployed similar inventories in other workshops already. For this mutualization, we had a look at Wikidata, a knowledge base developed alongside Wikipedia, which felt pretty fitting for such an use case.

For instance, there is a Wikidata item about the concept of a chain guard. It contains default names in many languages (called "labels" in Wikidata's terminology), but also descriptions and aliases (alternate names), also in many languages. It also contains links to images taken from Wikimedia Commons, the media repository where most illustrations of Wikipedia articles are coming from. Wikidata items have stable identifiers (such as Q1467873 in this case), which can be used to refer unambiguously to the item from other databases in a language-independent way.

There are open questions about reusing Wikidata in such a project. First, we would want to make it easy to add entries to the inventory. If supplying a Wikidata item is required to add an entry, it might be a significant hurdle for people contributing to the inventory. Then, the granularity of the modelling on Wikidata and in the inventory isn't always compatible: in certain cases, an entry in the inventory will be very specific (for instance, "stainless steel M8 nuts"), which will not have a corresponding Wikidata item. Also, in the context of our bike workshop, it's clear that the parts we store are for bikes, whereas Wikidata has a much broader scope. So, something that Wikidata would name a "bicycle wheel" would probably just be named "wheel" in our workshop. So the difference of scopes and contexts makes it harder to reuse names. On top of that, Wikidata is a living database: items get created, merged and deleted all the time. That generally is for the better, but can induce a maintenance load to keep the inventory and Wikidata connected and consistent. Many of those limitations are applicable to other reuses of Wikidata. But it still feels quite fitting. We also spent some time improving the Wikidata items around bike parts, as a way to familiarize ourselves with the quality of the data in this domain.

So that's essentially it so far. We don't have a silver bullet to offer, but I like it that we explored the use cases and limitations of existing things before jumping into reinventing the wheel. If you are aware of other systems or projects that could be relevant, please do get in touch.