Yes/No badges
Booleans are the easiest thing to get wrong in a data grid. Raw t/f looks like database debris; 1/0 gets confused with integer columns; a green cell with no text fails for colour-blind users. SeeKi renders booleans as shaped pill badges that carry both a colour and a glyph.
Large view. The glyph (✓ / ✕) sits inside the pill — not floating beside it — so the badge reads as one atomic unit at any size.
Inline — how the grid actually renders them
What the backend can send
SeeKi normalises every common boolean encoding the backend might serve. The frontend sees one of two possible rendered outputs: a yes badge or a no badge. (NULL is a separate case — see NULL rendering.)
| Raw value from DB | Rendered as |
|---|---|
true, t, TRUE | Yes |
1 (when column type is boolean) | Yes |
"yes", "y" | Yes |
false, f, FALSE | No |
0 (when column type is boolean) | No |
"no", "n" | No |
NULL | hatched NULL cell |
Why a glyph and a colour
Design principle 6 (from .impeccable.md): no information conveyed by colour alone. A yes badge in grey-scale — a printed report, a screenshot pasted into a ticket, a low-contrast monitor — still reads as ✓ Yes. A no badge still reads as ✕ No. The colour reinforces; it does not carry the meaning by itself.
Filtering on booleans
In a column’s menu, the filter input for a boolean column accepts plain words:
Clearing the filter restores all three states (yes, no, null).
Nullable booleans
Postgres lets a boolean column be null. SeeKi does not flatten that into No — a null is genuinely a third state, and it gets the hatched cell treatment instead.
Related
- NULL rendering — the third boolean state.
- Data grid — where the badges appear.
- Column menu — per-column boolean filter.