Skip to main content
Version: Next (nightly)

Views

A view is a way of looking at your data. The items don't change, only how you see them. The same set of parts can be a spreadsheet-style table one moment, a kanban board the next, or a display on the shop wall.

The lenses​

  • Table: rows and columns, for scanning, sorting, and editing.
  • Kanban: cards grouped into columns (by status, by location, by whatever you pick), which you drag between.
  • Calendar: items placed by a date field, like due dates, arrivals, or events.
  • Gallery: a photo-forward grid, for when what things look like matters. A photo-first collection opens on one by default, a wall of covers.
  • List: the simple default, one item per row.
  • Trend: a value plotted over time, with an optional goal line for the target you're aiming at.
  • Gantt: each item a bar from a start date to an end date, for a schedule at a glance.
  • Heatmap: a square per day shaded by how much you logged, for anything you keep on a rhythm.

A Heatmap can also score a rhythm you meant to keep. Give it an expected cadence (every day, weekdays, weekly, or your own rule) and the days you were due get outlined, so a gap on an expected day reads as a miss while a rest day doesn't count against you. The legend keeps score of the days you kept and your current streak, and a weekend never breaks a weekday streak.

Any view can also go on a TV or wall: public sharing puts a big, read-only, auto-refreshing version of it on a no-login URL.

What a view controls​

Each view is its own saved setup of:

  • which fields show as columns (a view can only show fields the data actually has)
  • grouping, such as a kanban or table grouped by location, status, or category
  • sorting and filtering, to order and narrow what's in view
  • the field a lens reads for its job, where the type needs one: the date a calendar places items by, the value a trend plots, the caption under a gallery card
  • A collection opens on the view its bundle calls the first thing to see (Groceries on What's on hand, a Bookshelf on its Covers) instead of the table, and remembers the view you last picked on this device, Table included. A link that names a view still wins.
  • An empty collection invites your first one. A fresh cover wall or an empty board says "Add your first book" (or item) with the same add door the table has and the scan door beside it. A view whose filter hid everything still says "No matching" and offers everything.

Filtering to more than one value​

A view filter takes either one value or a list, and a list means "any of these". That works for any field, not just location.

filter: { location_id: "fridge-id" } one place
filter: { location_id: ["fridge-id", "pantry-id"] } either place

This is what lets a screen show exactly one part of a room: a tablet by the fridge and pantry shows those two and nothing else, and a second one by the spice cabinets shows those.

If a filter is written in a way Cobblr cannot use, the view shows nothing rather than everything. That is deliberate. An empty view is obviously wrong and gets fixed, whereas a view quietly showing your whole kitchen looks like it is working.

Making one, keeping one​

Views live on the Views page. New view asks for a name, which records it looks at, and the lens, then the settings that lens actually needs: a group-by and filter for a kanban or table, an image field (and optional caption) for a gallery, a date field, value field and optional goal line for a trend. You are never asked for a date field by a lens that does not place things by date.

Some list pages offer the shortcut in place: filter and group the list the way you want it, then Save view keeps that exact arrangement under a name, without visiting the Views page at all.

Each saved view's row carries the rest of its life: pin puts it on the dashboard as its own card and unpin takes it off, edit reopens every setting including the name, and delete asks first. A view is shared with the workspace by default, so untick Share with workspace while saving to keep one private to you.

You can also just ask: Cobb builds a view from a sentence ("a board of my open tasks", "a calendar of what is due"), proposes saving it, and pins it if you want.

Many views, one set of data​

Saved views, each a tuned lens on the same parts Saved views, each a tuned lens on the same parts

A module isn't limited to one view. You keep as many as you find useful, each tuned for a job: a low-stock filtered table, a this-week calendar, a by-shelf kanban. Switching between them is instant, because they all read the same items. A change in one shows up everywhere.

This falls out of the modular kernel. Because every module speaks the same item-and-field language, every module gets the full set of views without any extra work.