Simple Query
A single filter line that becomes a living view — no table, no upkeep
- You write a Simple Query out of property filters and get a view. ·· Success criterion: You frame three filter queries, each showing the expected subset.
- You render the same query as a list, a table and a board. ·· Success criterion: You switch one query through all three views without rebuilding it.
- You explain why a query view stays current and a table goes stale. ·· Success criterion: You name the snapshot-versus-live-query difference using an example of your own.
Cmd+K finds a block. A query holds that finding in place: you describe once what you want to see — and mium shows it to you from then on, on its own. Instead of a table you maintain, a filter line that thinks along.
Why tables go stale
A hand-maintained overview is a snapshot: the moment you save it, it begins to age. Every new block, every status change in the existing set has to be entered by hand — and in day-to-day work that rarely happens in full. A query turns this around: it re-queries the existing set on every glance, so the view is always of right now.
5 rules for Simple Query
- A query is a filter line, not a formula editor — type:meeting, status:open, autor:team-mut.
- The view is live: when a block meets the criteria it appears; when it no longer does, it goes away.
- The same query renders as a list, a table or a board — you choose the view, the data stays one source.
- Properties are the filter axis — what you don't maintain as a property, you can't query for.
- A saved query lives as a block on a page, not as an external dashboard — it is part of the knowledge.
What a query looks like
{{query (and (property "type" "meeting")
(property "status" "offen"))}}
;; Ansicht: Tabelle · Sortierung: zuletzt-geändertBefore and after — table vs. Simple Query
| Step | Hand-maintained table | Simple Query |
|---|---|---|
| Setting up | define columns, type in rows | type a filter line |
| Keeping current | enter every change by hand | keeps itself current |
| Switching the view | build a new table | switch list / table / board |
| Source of truth | the table (a copy) | the blocks themselves |
| Upkeep | ongoing | one time (the criteria) |
An honest question
How many of your overviews are truly current today, and how many show the state of a fortnight ago because nobody updated them? The answer decides whether an overview takes work off your hands or becomes one more thing you have to maintain.
- Take an overview you maintain by hand today — an open-tasks list or a status table. Decide on one property to carry the filter, such as status, and build a Simple Query that shows exactly those blocks. Then switch the view once through list, table and board.⏱ 5 min
💡 Start with a single filter of property plus value. If the view is empty, the blocks are missing the property — fill it in on two or three blocks, and the query populates on its own.
Model answer: A hand-maintained list of open tasks becomes a filter line that reads the property status with the value open. From then on the view shows every matching block and drops every completed one on its own. As a board it serves the standup, as a table the reporting — one source, three views, zero upkeep.
What sets a Simple Query apart from a hand-maintained table?
Search once, see it for always.
One filter line, and your second brain shows the view — and keeps it current while you work on something else. A partner that thinks along, not a table you feed.
Reserve your slot··free of cost →