Labels as a Lightweight Classification

When you have ten tasks, you don’t need categories. You can just scan the list. Once you pass thirty, things get blurry. “What was this one for, again?”

Projects exist, of course. But projects are heavy. They have members, abbreviations, and a task can only belong to one project. Using them just to group things by type feels like overkill.

So I built labels.

Name and Color

A label has a name and a color. That’s it.

You name it whatever you want. “Urgent,” “Personal,” “Reading,” “Someday.” Anything works. Color is picked from twenty point colors. It’s not required. You can add a description too, but you don’t have to.

I originally planned to add more attributes. Icons, emoji, groups. But labels need to be lightweight. If creating one takes more than three seconds, you won’t bother.

Attach and Remove

In the task detail screen, there’s a labels section. Tap the plus button, your labels appear in a modal, tap one to attach it. Attached labels show as chips with an x button — tap it, and the label comes right off.

You can attach multiple labels to a single task. Something can be “Urgent” and “Personal” at the same time.

The UI follows the same pattern as web links. A section header with an add button, a list below. No new UI patterns invented. Just reusing what’s already familiar.

How Labels Differ from Projects

Projects are one-to-one. One task, one project. Labels are many-to-many. Multiple labels on one task, multiple tasks under one label.

Projects are team-level structures. They have members, roles, and permissions. Labels are personal. They’re your own classification system.

Project-level labels are planned for later. Project labels would be visible to all members, while personal labels remain private. The same task could carry both team labels and personal labels at the same time.

Browsing by Label

If you create labels, you should be able to browse by them.

From the label detail screen, tap “Tasks” or “Templates” to see everything tagged with that label. It’s the same structure as browsing records and templates within a project.

Labels don’t show in the task list itself. I considered adding color chips, but it would make the list noisy. It can always be added later, but for now, labels are visible only in the detail screen. That feels right.

Technical Notes

Label data doesn’t live inside task documents. I created two separate collections: label definitions (label) and attachments (label_link).

When loading the task list, label information isn’t fetched at all. It’s only queried when you open the detail screen. This keeps list performance untouched.

Filtering by label is handled server-side. The server finds task IDs from the link collection first, then queries tasks by those IDs. No local cache involved.

Whether this is the best approach, I’m not sure yet. If labels grow into thousands of links, it might need rethinking. But for now, it’s enough.

On Being Lightweight

The thing I watch out for most when building features is heaviness.

Labels should be a lightweight classification tool. Three seconds to create, one second to attach, one second to remove. Anything more is a failure.

I think it’s staying within those bounds for now. I’ll keep it that way.

---

Classification exists for finding things. If it’s easy to find, that’s enough.