1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
#+TITLE: Pattern catalog — collapse N orthogonal prompts into one enriched prompt
#+DATE: [2026-05-28 Thu]
#+SOURCE: pearl session 2026-05-28, third follow-up to UI-patterns thread
* Pattern 6 (or refinement of 4): "Collapse N orthogonal prompts into one enriched prompt where each candidate is a complete end-state"
Shipped as a design decision in =docs/saved-query-sync-spec.org= on 2026-05-28 during sprint review. Sharpens earlier catalog candidates rather than introducing a new direction.
** The trigger
Craig, while reviewing the spec's sync-saved-query-to-linear command: "have we informed the user if this choice is consequential in any way? this almost feels as if we can collapse two levels together by adding more information to each individual choice."
The spec originally proposed two sequential prompts:
1. Team scope: =[ Personal. ]= / Engineering / Marketing / ...
2. Shared visibility: personal / shared
Four orthogonal combinations the user had to mentally assemble:
- Personal scope + personal visibility = "just me, no team"
- Personal scope + shared visibility = doesn't quite make sense (no team to share with)
- Team scope + personal visibility = "team-scoped but only I see it"
- Team scope + shared visibility = "team-scoped and team-visible" (the typical sync intent)
** The collapse
One prompt where each candidate spells out the complete end-state:
#+begin_example
Where does this view live?
[ Team: Engineering, visible to the team ] <- default when :team Engineering in filter
[ Personal, only I see it ]
[ Team: Engineering, only I see it ]
[ Team: Marketing, visible to the team ]
[ Team: Marketing, only I see it ]
...
[ Cancel. ]
#+end_example
Same logical surface (N teams × 2 visibility + 1 personal). One fewer modal moment. Meaningless combination (personal + shared) absent from the list. Default at the top per the existing most-common-on-top pattern.
** What changed by the collapse
- Two prompts went to one. Smaller stack of decisions to track.
- Each option is now self-explanatory. "Visible to the team" reads as the consequence, not the mechanism.
- The default conveys *what will happen*, not just *which radio button is selected*.
- The degenerate combination doesn't have to be defended against in code -- it's not in the candidate list.
** Why for the catalog
This is a third worked form of the principle that's emerging across the pearl catalog notes:
#+begin_quote
The choices the user has should all be on screen, accurately labeled, ordered by what they'll most often want, with friction sized to the cost of being wrong.
#+end_quote
Previous catalog candidates touch parts of it:
- Pattern 3 (no empty input as meaningful): visible choices, no hidden idioms.
- Pattern 4 (prompt label matches behavior): accurate labels.
- Pattern 5 (default the most-common choice): right ordering, with safety-proportional friction.
This pattern (collapse N orthogonal prompts into one enriched prompt) is the *cross-product* form. When two or more prompts compose, each combination IS its own meaningful choice, and the user thinks about end-states, not dimensions. So show the cross-product, label each row with its end-state, and let the user pick destination rather than coordinates.
** Applicability gate
The collapse only works when the cross-product is small enough to scan (5-20 rows comfortably). For N=2 dimensions × M values, that's 2M to N×M rows depending on whether all combinations are meaningful.
It doesn't work when:
- The cross-product is large (many teams, many statuses, many priorities -- the candidate list becomes a wall).
- Dimensions are independently and frequently re-set (the user wants to change one without re-picking the rest).
- One dimension is "free text" (not a small enumerable set).
For those cases the sequential-prompts shape stays appropriate.
** Cumulative shape after this entry
The pearl catalog now has six worked candidates:
1. One-prompt picker with typed prefix (2026-05-27)
2. Transient state-buttons (Craig's external reference; magit-transient)
3. No empty input as meaningful (2026-05-28)
4. The prompt label matches what the prompt does (2026-05-28)
5. Default the most-common choice; friction sized to consequence (2026-05-28)
6. Collapse N orthogonal prompts into one enriched prompt (this note, 2026-05-28)
Patterns 1, 3, 4, 5, 6 are arguably one principle in five shapes. The catalog might want a single root entry (the principle stated once) with five cross-linked worked examples; or six tightly-cross-linked separate entries. The single-principle-multiple-shapes form scans more cleanly as the count grows; six independent entries fragments the underlying idea.
* Standing by
Spec reviews welcome when the rulesets discussion produces a concrete shape. Pearl's docs/saved-query-sync-spec.org now sits at =Ready=; implementation can start whenever Craig says.
|
