The ConditionViewer components render a read-only summary of a set of rules — one boxed sentence per rule, nested under the operator that combines them.
Anatomy
[WIP image]
| # | Required | Element | Description |
|---|---|---|---|
| 1 | Group | A set of conditions combined under one operator. | |
| 2 | Descriptor | The sentence saying how the group combines — the operator reads as a badge inside it. | |
| 3 | Collapse toggle | Shows and hides the conditions inside the group. | |
| 4 | Group actions | The way into editing the set, at the far end of the header. | |
| 5 | Condition | One rule, as a boxed sentence. | |
| 6 | Marker | A coin naming the kind of thing the rule is about. | |
| 7 | Sentence | The rule in words, with the values that carry meaning emphasized. | |
| 8 | Detail chips | The sub-conditions one rule is refined by. | |
| 9 | Condition actions | What sits beside a rule rather than inside its sentence — a warning, a cost indicator. |
Guidelines
ConditionViewer vs. DescriptionList and Table
- ConditionViewer shows a set of rules and how they combine, where the shape of the logic is part of the meaning.
- DescriptionList pairs labels with values. Reach for it when the entries are independent facts, not a rule set.
- Table compares many rows across the same columns. Reach for it when scanning down a column matters more than reading each row as a sentence.
The distinction is the boolean structure. A rule set nests, and the nesting is what a reader needs to understand; neither of the alternatives can express it.
Reading, not editing
These components render the view state only. They have no inputs, no controls beyond collapsing, and no opinion about how a rule is changed — the way into editing belongs in the group's actions, pointing at whatever editor the application provides.
What Pluma does not know
Every word is the application's. Pluma sets no wording for operators, no icon per rule type, no counts, and does no recursion — it renders the boxes, the typography, the spacing and the semantics, and nothing else. Two applications summarizing the same rules will look identical and read differently, which is the intent.
Best practices
Emphasis
Emphasize the parts a reader scans for — field names, values, entity names — and leave the grammar plain. Emphasizing everything is the same as emphasizing nothing.
Markers
Keep markers consistent across a set: one color, varying only by what the rule is about. Recolor a marker only to flag a rule that needs attention, such as one referring to something that no longer exists.
Nesting
The outermost group carries no surface or border; every group below it does. That contrast is what makes depth legible, so a nested group always needs its nested treatment — and the outermost one never does, or the whole summary sits in a box within a box.
Configurations
A single rule with no group around it. Use it where a rule is one fact among others rather than part of a set.
The common case: a descriptor saying how the rules combine, then the rules.
A rule refined by others. The lead-in ends the sentence and the chips sit below it.
Appearance
Inline
A condition fills the width it is given. Inline conditions hug their content instead, for a rule shown beside other content rather than as part of a list.
The default. Use it for a list of rules, where the boxes should line up.
Hugs its content. Use it inside a card or beside other content, where a full-width box would look empty.
Markers
The marker names the kind of thing a rule is about. It is decorative — the sentence already says what the rule concerns — so it never carries meaning a reader would otherwise miss. A rule given no marker is fine; its sentence simply starts at the box's edge.
The usual case. Pick an icon for the kind of thing the rule is about.
Use it where the rules are all of one kind and an icon per row would only add noise.
Trailing actions
Actions sit at the trailing edge, aligned with the marker, and stay put as the sentence wraps. Use them for what belongs beside a rule rather than inside it.
A rule that needs attention — one referring to something that no longer exists, for example.
The way into editing the set, at the far end of the group's header.
Behaviors
Collapsing
A group can be collapsible, which puts a toggle before its descriptor. Collapsing removes the conditions rather than hiding them, so they leave the tab order with everything else — a collapsed group is genuinely absent, not invisible.
Reach for collapsing where a summary is long enough that a reader needs to skim it. A short set is easier to read whole.
The default for a collapsible group.
The descriptor stays, so the group still says what it holds.
Wrapping
Condition text is machine-generated — event names, URLs, attribute values — so it wraps rather than overflowing, breaking mid-token where a long value leaves no other choice. The marker and the trailing actions stay against the first line as the sentence grows, so a tall condition doesn't leave them floating in the middle.
Detail chips wrap as a row and each hugs its own content, so a long chip takes a line to itself rather than stretching its neighbors.
Content
The wording is entirely the application's, which makes consistency its responsibility too. Phrase the same kind of rule the same way everywhere it appears.
Descriptors
Write a group's descriptor as a sentence with the operator reading as a badge inside it — Matches all of 4 conditions. Say how many conditions the group holds; a reader deciding whether to expand a collapsed group has only the descriptor to go on.
Sentences
Write each rule as a sentence a person would say out loud, not as a field-operator-value triple. A rule does not have to start with a field.
Sub-condition lead-ins
End the rule's own sentence with the lead-in — and matches all: — so it reads as one phrase with the chips below it. A second, differently described set of chips takes its own label, which necessarily starts a new line.