raven-mcp 1.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +72 -0
- package/dist/index.d.ts +2 -0
- package/dist/index.js +629 -0
- package/dist/index.js.map +1 -0
- package/package.json +51 -0
- package/src/data/business/growth.json +48 -0
- package/src/data/business/metrics.json +48 -0
- package/src/data/business/monetization.json +56 -0
- package/src/data/business/onboarding.json +48 -0
- package/src/data/business/retention.json +48 -0
- package/src/data/patterns/cta.json +51 -0
- package/src/data/patterns/dashboard.json +51 -0
- package/src/data/patterns/empty-states.json +42 -0
- package/src/data/patterns/error-states.json +51 -0
- package/src/data/patterns/forms.json +53 -0
- package/src/data/patterns/landing-page.json +51 -0
- package/src/data/patterns/loading-states.json +51 -0
- package/src/data/patterns/mobile-conversion.json +51 -0
- package/src/data/patterns/modals-dialogs.json +51 -0
- package/src/data/patterns/navigation.json +50 -0
- package/src/data/patterns/pricing-page.json +59 -0
- package/src/data/patterns/signup-flow.json +52 -0
- package/src/data/patterns/social-proof.json +49 -0
- package/src/data/principles/accessibility.json +151 -0
- package/src/data/principles/color-theory.json +100 -0
- package/src/data/principles/d4d.json +113 -0
- package/src/data/principles/gestalt.json +129 -0
- package/src/data/principles/laws-of-ux.json +490 -0
- package/src/data/principles/mobile-ux.json +126 -0
- package/src/data/principles/nielsen-heuristics.json +258 -0
- package/src/data/principles/typography.json +117 -0
- package/src/data/tokens/registry.json +67 -0
- package/src/data/tokens/systems/linear.json +134 -0
- package/src/data/tokens/systems/stripe.json +147 -0
|
@@ -0,0 +1,258 @@
|
|
|
1
|
+
[
|
|
2
|
+
{
|
|
3
|
+
"id": "visibility-of-system-status",
|
|
4
|
+
"name": "Visibility of System Status",
|
|
5
|
+
"category": "nielsen-heuristics",
|
|
6
|
+
"summary": "The design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time.",
|
|
7
|
+
"description": "Users should never have to wonder about the current state of the system. Every action should produce visible, immediate feedback. Progress indicators, loading states, success confirmations, and error messages all serve this heuristic. The system should proactively communicate state changes rather than leaving users to guess.",
|
|
8
|
+
"implications": [
|
|
9
|
+
"Show loading indicators for any operation over 1 second",
|
|
10
|
+
"Provide progress bars for multi-step processes",
|
|
11
|
+
"Confirm successful actions with visual feedback (toast, check mark, color change)",
|
|
12
|
+
"Display real-time validation on form inputs",
|
|
13
|
+
"Show current location in navigation (breadcrumbs, active nav state)",
|
|
14
|
+
"Indicate unsaved changes before the user navigates away",
|
|
15
|
+
"Use skeleton screens instead of blank loading states"
|
|
16
|
+
],
|
|
17
|
+
"violations": [
|
|
18
|
+
"A form submits with no visual feedback — user clicks again, creating duplicates",
|
|
19
|
+
"File upload with no progress bar — user doesn't know if it's working",
|
|
20
|
+
"No active state on navigation — user doesn't know which page they're on",
|
|
21
|
+
"Long-running process with no indication of progress or estimated time",
|
|
22
|
+
"Button click with no visual response (no disabled state, no spinner)"
|
|
23
|
+
],
|
|
24
|
+
"applies_to": ["loading", "forms", "navigation", "feedback", "progress", "empty-states", "error-states"],
|
|
25
|
+
"sources": ["https://www.nngroup.com/articles/visibility-system-status/"]
|
|
26
|
+
},
|
|
27
|
+
{
|
|
28
|
+
"id": "match-real-world",
|
|
29
|
+
"name": "Match Between System and the Real World",
|
|
30
|
+
"category": "nielsen-heuristics",
|
|
31
|
+
"summary": "The design should speak the users' language. Use words, phrases, and concepts familiar to the user, rather than internal jargon.",
|
|
32
|
+
"description": "Information should appear in a natural and logical order, following real-world conventions. The interface should use language and metaphors the target users already understand. Icons should map to real-world objects users recognize. Workflows should follow real-world task sequences rather than system architecture.",
|
|
33
|
+
"implications": [
|
|
34
|
+
"Use domain-specific language your users actually use, not internal product terms",
|
|
35
|
+
"Order information following real-world conventions (dates, addresses, names)",
|
|
36
|
+
"Use icons and metaphors that map to physical-world objects users recognize",
|
|
37
|
+
"Design workflows that mirror real-world task sequences",
|
|
38
|
+
"Use natural language for labels and instructions, not technical jargon",
|
|
39
|
+
"Show amounts in user's local currency and date format"
|
|
40
|
+
],
|
|
41
|
+
"violations": [
|
|
42
|
+
"Using 'repository' instead of 'project' for non-developer audiences",
|
|
43
|
+
"Error codes like 'ERR_404' instead of 'Page not found'",
|
|
44
|
+
"Technical field names like 'varchar' or 'uuid' visible to end users",
|
|
45
|
+
"Calendar that starts weeks on Monday in US-locale apps (or Sunday in European ones)",
|
|
46
|
+
"Using 'tenant' or 'instance' in user-facing copy"
|
|
47
|
+
],
|
|
48
|
+
"applies_to": ["copy", "labels", "navigation", "forms", "error-states", "onboarding"],
|
|
49
|
+
"sources": ["https://www.nngroup.com/articles/match-system-real-world/"]
|
|
50
|
+
},
|
|
51
|
+
{
|
|
52
|
+
"id": "user-control-freedom",
|
|
53
|
+
"name": "User Control and Freedom",
|
|
54
|
+
"category": "nielsen-heuristics",
|
|
55
|
+
"summary": "Users often perform actions by mistake. They need a clearly marked 'emergency exit' to leave the unwanted action without having to go through an extended process.",
|
|
56
|
+
"description": "Users need to feel in control. Every destructive or significant action should be undoable. The system should provide clear ways to go back, cancel, or undo. Confirmation dialogs for irreversible actions. Easy navigation back to known states. Users should never feel trapped in a flow they didn't intend to enter.",
|
|
57
|
+
"implications": [
|
|
58
|
+
"Support undo/redo for all significant actions",
|
|
59
|
+
"Provide a clear 'Cancel' option on every modal and multi-step flow",
|
|
60
|
+
"Allow users to go back to previous steps in multi-step processes",
|
|
61
|
+
"Use 'soft delete' (trash/archive) instead of permanent deletion",
|
|
62
|
+
"Show confirmation dialogs only for truly irreversible actions",
|
|
63
|
+
"Let users exit onboarding flows and return later",
|
|
64
|
+
"Provide a 'Home' or logo link that always returns to a known state"
|
|
65
|
+
],
|
|
66
|
+
"violations": [
|
|
67
|
+
"Permanent deletion with no undo or archive option",
|
|
68
|
+
"Multi-step wizard with no back button",
|
|
69
|
+
"Modal that can only be dismissed by completing the action",
|
|
70
|
+
"Onboarding flow that can't be skipped or paused",
|
|
71
|
+
"No way to unsend or edit a message after sending",
|
|
72
|
+
"Settings change that takes effect immediately with no revert option"
|
|
73
|
+
],
|
|
74
|
+
"applies_to": ["modals", "forms", "navigation", "settings", "destructive-actions", "onboarding"],
|
|
75
|
+
"sources": ["https://www.nngroup.com/articles/user-control-and-freedom/"]
|
|
76
|
+
},
|
|
77
|
+
{
|
|
78
|
+
"id": "consistency-standards",
|
|
79
|
+
"name": "Consistency and Standards",
|
|
80
|
+
"category": "nielsen-heuristics",
|
|
81
|
+
"summary": "Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions.",
|
|
82
|
+
"description": "Jakob's Law applies here — users spend most of their time on other sites and apps. They expect your interface to work the same way. Internal consistency (within your product) and external consistency (with platform conventions) both matter. Design systems exist to enforce this. Breaking convention requires a very good reason.",
|
|
83
|
+
"implications": [
|
|
84
|
+
"Use standard platform patterns (hamburger menu, search icon, settings gear)",
|
|
85
|
+
"Keep terminology consistent across the entire product",
|
|
86
|
+
"Use the same visual treatment for the same type of action everywhere",
|
|
87
|
+
"Follow platform conventions for gestures, keyboard shortcuts, and navigation",
|
|
88
|
+
"Maintain a design system to enforce visual and interaction consistency",
|
|
89
|
+
"Use standard form patterns (labels above inputs, primary action on the right)"
|
|
90
|
+
],
|
|
91
|
+
"violations": [
|
|
92
|
+
"Different words for the same action ('Remove' vs 'Delete' vs 'Trash')",
|
|
93
|
+
"Buttons that look different but do the same thing on different pages",
|
|
94
|
+
"Non-standard icons (using a heart icon for bookmarking)",
|
|
95
|
+
"Different navigation patterns on different pages of the same app",
|
|
96
|
+
"Custom scrollbar behavior that doesn't match OS conventions",
|
|
97
|
+
"Different date formats on different screens"
|
|
98
|
+
],
|
|
99
|
+
"applies_to": ["buttons", "navigation", "forms", "icons", "copy", "design-system"],
|
|
100
|
+
"sources": ["https://www.nngroup.com/articles/consistency-and-standards/"]
|
|
101
|
+
},
|
|
102
|
+
{
|
|
103
|
+
"id": "error-prevention",
|
|
104
|
+
"name": "Error Prevention",
|
|
105
|
+
"category": "nielsen-heuristics",
|
|
106
|
+
"summary": "Good error messages are important, but the best designs carefully prevent problems from occurring in the first place.",
|
|
107
|
+
"description": "There are two types of errors: slips (unconscious mistakes from inattention) and mistakes (conscious errors from incorrect mental models). Prevent slips with good defaults, constraints, and confirmations. Prevent mistakes with clear instructions, affordances, and previews. Error prevention is always better than error recovery.",
|
|
108
|
+
"implications": [
|
|
109
|
+
"Use inline validation to catch errors before form submission",
|
|
110
|
+
"Provide sensible defaults for complex inputs",
|
|
111
|
+
"Use constrained inputs (dropdowns, date pickers) instead of free text where possible",
|
|
112
|
+
"Show a confirmation step before irreversible actions",
|
|
113
|
+
"Disable or hide actions that aren't available in the current context",
|
|
114
|
+
"Auto-save work to prevent data loss",
|
|
115
|
+
"Show previews of the result before the user commits to an action"
|
|
116
|
+
],
|
|
117
|
+
"violations": [
|
|
118
|
+
"Free text input for dates instead of a date picker",
|
|
119
|
+
"No validation until the entire form is submitted",
|
|
120
|
+
"Destructive action button right next to the primary action with no confirmation",
|
|
121
|
+
"Allowing submission of obviously invalid data (negative quantities, past dates for future events)",
|
|
122
|
+
"No auto-save on long forms — a browser crash loses all work",
|
|
123
|
+
"Delete button with no confirmation or undo"
|
|
124
|
+
],
|
|
125
|
+
"applies_to": ["forms", "validation", "destructive-actions", "inputs", "settings"],
|
|
126
|
+
"sources": ["https://www.nngroup.com/articles/slips/"]
|
|
127
|
+
},
|
|
128
|
+
{
|
|
129
|
+
"id": "recognition-over-recall",
|
|
130
|
+
"name": "Recognition Rather Than Recall",
|
|
131
|
+
"category": "nielsen-heuristics",
|
|
132
|
+
"summary": "Minimize the user's memory load by making elements, actions, and options visible. The user should not have to remember information from one part of the interface to another.",
|
|
133
|
+
"description": "Human short-term memory is limited (Miller's Law). Interfaces should present options visibly rather than requiring users to remember them. Recently used items, search suggestions, contextual help, and visible navigation all reduce cognitive load. Every time a user has to remember something, there's a chance for error.",
|
|
134
|
+
"implications": [
|
|
135
|
+
"Show recently used items and searches",
|
|
136
|
+
"Use descriptive labels instead of icon-only buttons",
|
|
137
|
+
"Provide search with autocomplete and suggestions",
|
|
138
|
+
"Show contextual help and tooltips for complex features",
|
|
139
|
+
"Display relevant information in context rather than requiring navigation",
|
|
140
|
+
"Use visual cues (color, icons, thumbnails) to aid recognition",
|
|
141
|
+
"Keep important actions visible, not buried in menus"
|
|
142
|
+
],
|
|
143
|
+
"violations": [
|
|
144
|
+
"Icon-only toolbar with no labels or tooltips",
|
|
145
|
+
"Requiring users to remember codes or IDs from a previous screen",
|
|
146
|
+
"Hidden navigation that requires memorizing keyboard shortcuts",
|
|
147
|
+
"No search history or recent items",
|
|
148
|
+
"Complex settings with no preview of what they affect",
|
|
149
|
+
"Reference numbers shown once with no way to look them up later"
|
|
150
|
+
],
|
|
151
|
+
"applies_to": ["navigation", "search", "forms", "icons", "tooltips", "dashboard"],
|
|
152
|
+
"sources": ["https://www.nngroup.com/articles/recognition-and-recall/"]
|
|
153
|
+
},
|
|
154
|
+
{
|
|
155
|
+
"id": "flexibility-efficiency",
|
|
156
|
+
"name": "Flexibility and Efficiency of Use",
|
|
157
|
+
"category": "nielsen-heuristics",
|
|
158
|
+
"summary": "Shortcuts — hidden from novice users — can speed up the interaction for the expert user so that the design can cater to both inexperienced and experienced users.",
|
|
159
|
+
"description": "Interfaces should serve both novices and experts. Accelerators like keyboard shortcuts, customizable workflows, and batch operations let power users work faster without overwhelming beginners. Progressive disclosure shows basic features first with advanced options available on demand. The system should be learnable but also efficient at scale.",
|
|
160
|
+
"implications": [
|
|
161
|
+
"Provide keyboard shortcuts for common actions",
|
|
162
|
+
"Support batch/bulk operations for repetitive tasks",
|
|
163
|
+
"Allow users to customize their workspace and workflows",
|
|
164
|
+
"Implement progressive disclosure — basic features first, advanced on demand",
|
|
165
|
+
"Support command palettes for power users (Cmd+K pattern)",
|
|
166
|
+
"Allow drag-and-drop as an alternative to menu-driven interactions",
|
|
167
|
+
"Remember user preferences and recent selections"
|
|
168
|
+
],
|
|
169
|
+
"violations": [
|
|
170
|
+
"No keyboard shortcuts for any actions",
|
|
171
|
+
"Forcing users through a wizard for a task they do 50 times a day",
|
|
172
|
+
"No bulk selection or batch operations on lists",
|
|
173
|
+
"Expert features mixed in with beginner UI, making both worse",
|
|
174
|
+
"No way to save or template frequently used configurations",
|
|
175
|
+
"Search that requires exact matches with no fuzzy matching"
|
|
176
|
+
],
|
|
177
|
+
"applies_to": ["navigation", "keyboard", "power-users", "customization", "search", "workflows"],
|
|
178
|
+
"sources": ["https://www.nngroup.com/articles/flexibility-efficiency-heuristic/"]
|
|
179
|
+
},
|
|
180
|
+
{
|
|
181
|
+
"id": "aesthetic-minimalist-design",
|
|
182
|
+
"name": "Aesthetic and Minimalist Design",
|
|
183
|
+
"category": "nielsen-heuristics",
|
|
184
|
+
"summary": "Interfaces should not contain information that is irrelevant or rarely needed. Every extra unit of information in an interface competes with the relevant units of information and diminishes their relative visibility.",
|
|
185
|
+
"description": "This is not about visual minimalism — it's about information minimalism. Every element on the screen should earn its place. Prioritize content that serves the user's primary task. Secondary information should be available on demand, not competing for attention. Visual hierarchy should make the most important content immediately clear. White space is a feature, not wasted space.",
|
|
186
|
+
"implications": [
|
|
187
|
+
"Prioritize content by user goals — primary task front and center",
|
|
188
|
+
"Use progressive disclosure to hide secondary information",
|
|
189
|
+
"Remove decorative elements that don't communicate meaning",
|
|
190
|
+
"Use generous whitespace to create visual hierarchy",
|
|
191
|
+
"Limit choices to reduce cognitive load (Hick's Law)",
|
|
192
|
+
"Show only the most relevant data; let users drill down for details",
|
|
193
|
+
"Every visual element should serve a purpose — decoration, distinction, or information"
|
|
194
|
+
],
|
|
195
|
+
"violations": [
|
|
196
|
+
"Dashboard with 20+ metrics all given equal visual weight",
|
|
197
|
+
"Settings page showing every option at once with no grouping",
|
|
198
|
+
"Marketing copy mixed into a task-focused UI",
|
|
199
|
+
"Decorative animations that slow down task completion",
|
|
200
|
+
"Cluttered headers with too many navigation items",
|
|
201
|
+
"Showing database fields the user doesn't need to see"
|
|
202
|
+
],
|
|
203
|
+
"applies_to": ["layout", "dashboard", "navigation", "content", "hierarchy", "whitespace"],
|
|
204
|
+
"sources": ["https://www.nngroup.com/articles/aesthetic-minimalist-design/"]
|
|
205
|
+
},
|
|
206
|
+
{
|
|
207
|
+
"id": "help-recover-errors",
|
|
208
|
+
"name": "Help Users Recognize, Diagnose, and Recover from Errors",
|
|
209
|
+
"category": "nielsen-heuristics",
|
|
210
|
+
"summary": "Error messages should be expressed in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution.",
|
|
211
|
+
"description": "When errors happen, the user needs three things: what went wrong, why it went wrong, and how to fix it. Error messages should be written in human language, point to the specific field or action that caused the error, and provide a clear path to resolution. Never blame the user. Never show technical error codes without a human explanation.",
|
|
212
|
+
"implications": [
|
|
213
|
+
"Write error messages in plain, non-technical language",
|
|
214
|
+
"Point to the specific field or input that caused the error",
|
|
215
|
+
"Suggest a concrete next step to resolve the error",
|
|
216
|
+
"Use inline validation to show errors next to the relevant field",
|
|
217
|
+
"Provide a way to recover — retry, edit, go back, or contact support",
|
|
218
|
+
"Never blame the user ('Invalid input' vs 'Please enter a valid email')",
|
|
219
|
+
"Log technical details for developers but show human messages to users"
|
|
220
|
+
],
|
|
221
|
+
"violations": [
|
|
222
|
+
"Generic 'An error occurred' with no details or recovery path",
|
|
223
|
+
"Technical error codes shown to end users (500 Internal Server Error)",
|
|
224
|
+
"Error messages that blame the user ('You entered invalid data')",
|
|
225
|
+
"Validation errors shown at the top of the page, far from the problem field",
|
|
226
|
+
"Error state with no way to retry or recover without refreshing",
|
|
227
|
+
"Red text with no explanation of what's wrong or how to fix it"
|
|
228
|
+
],
|
|
229
|
+
"applies_to": ["error-states", "forms", "validation", "feedback", "copy"],
|
|
230
|
+
"sources": ["https://www.nngroup.com/articles/error-message-guidelines/"]
|
|
231
|
+
},
|
|
232
|
+
{
|
|
233
|
+
"id": "help-documentation",
|
|
234
|
+
"name": "Help and Documentation",
|
|
235
|
+
"category": "nielsen-heuristics",
|
|
236
|
+
"summary": "It's best if the system doesn't need any additional explanation. However, it may be necessary to provide documentation to help users understand how to complete their tasks.",
|
|
237
|
+
"description": "The best interface needs no documentation. But complex systems often do. When help is needed, it should be contextual (right where the user needs it), searchable, task-oriented (focused on concrete steps), concise, and easy to find. Help should be the last resort, not a crutch for bad design. Tooltips, onboarding tours, and inline guidance are all forms of help.",
|
|
238
|
+
"implications": [
|
|
239
|
+
"Provide contextual help tooltips next to complex features",
|
|
240
|
+
"Include a searchable help center or knowledge base",
|
|
241
|
+
"Write task-oriented documentation (how to accomplish X, not feature descriptions)",
|
|
242
|
+
"Offer onboarding tours for first-time users",
|
|
243
|
+
"Show inline hints for complex or infrequently used features",
|
|
244
|
+
"Provide example values in form fields (placeholder text)",
|
|
245
|
+
"Make help accessible without leaving the current context"
|
|
246
|
+
],
|
|
247
|
+
"violations": [
|
|
248
|
+
"Complex feature with no documentation or tooltip explaining it",
|
|
249
|
+
"Help docs that are only accessible from a separate website",
|
|
250
|
+
"Documentation organized by feature, not by user task",
|
|
251
|
+
"No onboarding or guidance for first-time users",
|
|
252
|
+
"Tooltip text that's just the field label repeated",
|
|
253
|
+
"Help that requires reading a 10-page document for a simple task"
|
|
254
|
+
],
|
|
255
|
+
"applies_to": ["tooltips", "onboarding", "documentation", "forms", "complex-features"],
|
|
256
|
+
"sources": ["https://www.nngroup.com/articles/help-and-documentation/"]
|
|
257
|
+
}
|
|
258
|
+
]
|
|
@@ -0,0 +1,117 @@
|
|
|
1
|
+
[
|
|
2
|
+
{
|
|
3
|
+
"id": "type-scale",
|
|
4
|
+
"name": "Typographic Scale",
|
|
5
|
+
"category": "typography",
|
|
6
|
+
"summary": "Use a mathematically consistent type scale to create harmonious size relationships.",
|
|
7
|
+
"description": "A type scale provides a set of predetermined font sizes based on a ratio (1.125, 1.200, 1.250, 1.333, 1.414, 1.500, 1.618). This creates visual harmony and reduces ad-hoc sizing decisions. Common scales: Minor Third (1.2) for compact UIs, Major Third (1.25) for general use, Perfect Fourth (1.333) for content-heavy sites, Golden Ratio (1.618) for editorial/marketing.",
|
|
8
|
+
"implications": [
|
|
9
|
+
"Choose a scale ratio based on content type (1.2 for apps, 1.25-1.333 for marketing)",
|
|
10
|
+
"Base size of 16px (1rem) for body text on web",
|
|
11
|
+
"Limit to 5-7 sizes in the scale — more creates noise",
|
|
12
|
+
"Use the scale for all text: headings, body, captions, labels",
|
|
13
|
+
"Define the scale in design tokens for consistency across the product",
|
|
14
|
+
"Adjust scale for mobile — tighter ratios (1.125-1.2) work better on small screens"
|
|
15
|
+
],
|
|
16
|
+
"violations": [
|
|
17
|
+
"Ad-hoc font sizes (13px, 15px, 17px, 19px) with no systematic relationship",
|
|
18
|
+
"Too many distinct sizes on one page",
|
|
19
|
+
"Heading sizes too close together — no clear hierarchy",
|
|
20
|
+
"Scale too aggressive for the content type (1.618 on a dense data app)"
|
|
21
|
+
],
|
|
22
|
+
"applies_to": ["typography", "hierarchy", "design-system", "headings", "body-text"],
|
|
23
|
+
"sources": ["https://typescale.com/", "https://alistapart.com/article/more-meaningful-typography/"]
|
|
24
|
+
},
|
|
25
|
+
{
|
|
26
|
+
"id": "line-height-spacing",
|
|
27
|
+
"name": "Line Height and Spacing",
|
|
28
|
+
"category": "typography",
|
|
29
|
+
"summary": "Proper line height and spacing dramatically impacts readability and scannability.",
|
|
30
|
+
"description": "Line height (leading) should increase with line length and decrease with font size. Body text: 1.4-1.6. Headings: 1.1-1.3. Captions/small text: 1.4-1.5. Paragraph spacing should be approximately equal to line height. Letter spacing (tracking) is generally left at default for body text but may need adjustment for all-caps text (add 0.05-0.1em) and large headings (tighten slightly).",
|
|
31
|
+
"implications": [
|
|
32
|
+
"Body text: line-height 1.5 (WCAG recommendation), range 1.4-1.6",
|
|
33
|
+
"Headings: line-height 1.1-1.3 (tighter for larger text)",
|
|
34
|
+
"All-caps text: add letter-spacing of 0.05-0.1em for readability",
|
|
35
|
+
"Large headings (32px+): tighten letter-spacing slightly (-0.01 to -0.03em)",
|
|
36
|
+
"Paragraph spacing: at least 1.5x the font size (WCAG)",
|
|
37
|
+
"Consistent spacing between all typographic elements"
|
|
38
|
+
],
|
|
39
|
+
"violations": [
|
|
40
|
+
"Single line height (line-height: 1.0) on multi-line body text",
|
|
41
|
+
"All-caps text without added letter-spacing",
|
|
42
|
+
"Inconsistent line heights across the same text style",
|
|
43
|
+
"No paragraph spacing — text blocks run together"
|
|
44
|
+
],
|
|
45
|
+
"applies_to": ["typography", "readability", "spacing", "accessibility", "content"],
|
|
46
|
+
"sources": ["https://www.w3.org/WAI/WCAG21/Understanding/text-spacing.html"]
|
|
47
|
+
},
|
|
48
|
+
{
|
|
49
|
+
"id": "font-pairing",
|
|
50
|
+
"name": "Font Pairing",
|
|
51
|
+
"category": "typography",
|
|
52
|
+
"summary": "Combine typefaces with complementary characteristics for visual variety and hierarchy.",
|
|
53
|
+
"description": "Effective font pairing creates contrast and hierarchy without chaos. The safest approach: one serif + one sans-serif, or one display + one text face. Look for shared characteristics (x-height, letterform proportions) with contrasting styles (weight, width, classification). Most products need only 1-2 typefaces. Three is the maximum. System font stacks are increasingly preferred for performance.",
|
|
54
|
+
"implications": [
|
|
55
|
+
"Use at most 2-3 typefaces in a product",
|
|
56
|
+
"Pair typefaces with contrasting classification but similar proportions",
|
|
57
|
+
"Consider system font stacks for performance (Inter, -apple-system, system-ui)",
|
|
58
|
+
"One typeface for headings/display, one for body/UI — or one family with enough weights",
|
|
59
|
+
"Variable fonts offer weight/width flexibility with a single font file",
|
|
60
|
+
"Test pairings at all sizes — what works at 48px may not at 14px"
|
|
61
|
+
],
|
|
62
|
+
"violations": [
|
|
63
|
+
"4+ different typefaces creating visual chaos",
|
|
64
|
+
"Two similar sans-serifs that don't create clear contrast",
|
|
65
|
+
"Display typeface used for body text (poor readability at small sizes)",
|
|
66
|
+
"Font loading flash causing layout shifts"
|
|
67
|
+
],
|
|
68
|
+
"applies_to": ["typography", "branding", "design-system", "performance", "visual-design"],
|
|
69
|
+
"sources": ["https://fonts.google.com/knowledge/choosing_type"]
|
|
70
|
+
},
|
|
71
|
+
{
|
|
72
|
+
"id": "text-hierarchy",
|
|
73
|
+
"name": "Text Hierarchy",
|
|
74
|
+
"category": "typography",
|
|
75
|
+
"summary": "Create clear levels of importance through size, weight, color, and spacing.",
|
|
76
|
+
"description": "Visual hierarchy in text guides the reader through content in order of importance. Primary hierarchy tools: size (the strongest), weight (bold vs regular), color (dark vs muted), and spacing (generous around important items). A clear hierarchy means users can scan the page and immediately identify what's most important. Every text element should clearly belong to one level.",
|
|
77
|
+
"implications": [
|
|
78
|
+
"Use 3-4 distinct hierarchy levels: primary (heading), secondary (subheading), body, and muted",
|
|
79
|
+
"Size is the strongest hierarchy signal — use it for the most important distinction",
|
|
80
|
+
"Weight creates secondary hierarchy within the same size",
|
|
81
|
+
"Color (opacity/saturation) creates tertiary hierarchy — muted for less important text",
|
|
82
|
+
"Combine size + weight + color for maximum hierarchy contrast",
|
|
83
|
+
"Test hierarchy by squinting — the most important text should still be visible"
|
|
84
|
+
],
|
|
85
|
+
"violations": [
|
|
86
|
+
"All text the same size and weight — no hierarchy",
|
|
87
|
+
"Too many hierarchy levels — 6+ sizes that blur the distinctions",
|
|
88
|
+
"Using only color to create hierarchy (fails for color-blind users)",
|
|
89
|
+
"Heading and body text too close in size — unclear distinction"
|
|
90
|
+
],
|
|
91
|
+
"applies_to": ["typography", "hierarchy", "layout", "content", "headings", "labels"],
|
|
92
|
+
"sources": ["https://practicaltypography.com/"]
|
|
93
|
+
},
|
|
94
|
+
{
|
|
95
|
+
"id": "measure-line-length",
|
|
96
|
+
"name": "Measure (Line Length)",
|
|
97
|
+
"category": "typography",
|
|
98
|
+
"summary": "Optimal line length for body text is 45-75 characters per line.",
|
|
99
|
+
"description": "The 'measure' in typography refers to the width of a text block. Lines that are too long cause the reader's eye to lose its place when returning to the left margin. Lines that are too short break reading rhythm with too many line breaks. The ideal range is 45-75 characters (about 2-3 lowercase alphabets). For multi-column layouts, 40-50 characters per column. Set max-width on text containers, not just the parent.",
|
|
100
|
+
"implications": [
|
|
101
|
+
"Body text: 45-75 characters per line (max-width: 65ch is a good default)",
|
|
102
|
+
"Short-form text (cards, labels): 20-40 characters",
|
|
103
|
+
"Use max-width on text containers — not on the parent layout",
|
|
104
|
+
"Wider columns need larger text; narrower columns can use smaller text",
|
|
105
|
+
"Increase line-height if line length exceeds 65 characters",
|
|
106
|
+
"Left-align body text for Western languages — centered text is harder to read beyond 3 lines"
|
|
107
|
+
],
|
|
108
|
+
"violations": [
|
|
109
|
+
"Full-width text spanning 1200px+ viewport — 120+ characters per line",
|
|
110
|
+
"Text constrained to 200px — constant line breaks, choppy reading",
|
|
111
|
+
"Centered text in paragraphs — hard to find the start of the next line",
|
|
112
|
+
"Justified text on the web (inconsistent word spacing)"
|
|
113
|
+
],
|
|
114
|
+
"applies_to": ["typography", "layout", "readability", "responsive", "content"],
|
|
115
|
+
"sources": ["https://practicaltypography.com/line-length.html"]
|
|
116
|
+
}
|
|
117
|
+
]
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
{
|
|
2
|
+
"systems": [
|
|
3
|
+
{
|
|
4
|
+
"id": "stripe",
|
|
5
|
+
"name": "Stripe",
|
|
6
|
+
"description": "Stripe's design system tokens — clean, professional fintech design with excellent typography and a signature purple accent.",
|
|
7
|
+
"category": "fintech",
|
|
8
|
+
"tags": ["professional", "clean", "accessible", "fintech"],
|
|
9
|
+
"url": "https://stripe.com",
|
|
10
|
+
"status": "available"
|
|
11
|
+
},
|
|
12
|
+
{
|
|
13
|
+
"id": "linear",
|
|
14
|
+
"name": "Linear",
|
|
15
|
+
"description": "Linear's design system tokens — dark-first, minimal, fast. Iconic developer productivity aesthetic.",
|
|
16
|
+
"category": "productivity",
|
|
17
|
+
"tags": ["dark", "minimal", "developer", "fast"],
|
|
18
|
+
"url": "https://linear.app",
|
|
19
|
+
"status": "available"
|
|
20
|
+
},
|
|
21
|
+
{
|
|
22
|
+
"id": "vercel",
|
|
23
|
+
"name": "Vercel",
|
|
24
|
+
"description": "Vercel's Geist design system — monochrome elegance with developer-first aesthetics.",
|
|
25
|
+
"category": "developer",
|
|
26
|
+
"tags": ["monochrome", "developer", "minimal", "elegant"],
|
|
27
|
+
"url": "https://vercel.com/geist",
|
|
28
|
+
"status": "planned"
|
|
29
|
+
},
|
|
30
|
+
{
|
|
31
|
+
"id": "shadcn",
|
|
32
|
+
"name": "shadcn/ui",
|
|
33
|
+
"description": "shadcn/ui component tokens — beautifully designed components using Radix and Tailwind CSS.",
|
|
34
|
+
"category": "component-library",
|
|
35
|
+
"tags": ["accessible", "customizable", "tailwind", "radix"],
|
|
36
|
+
"url": "https://ui.shadcn.com",
|
|
37
|
+
"status": "planned"
|
|
38
|
+
},
|
|
39
|
+
{
|
|
40
|
+
"id": "github-primer",
|
|
41
|
+
"name": "GitHub Primer",
|
|
42
|
+
"description": "GitHub's Primer design system — functional, accessible, scale-tested across one of the world's largest developer platforms.",
|
|
43
|
+
"category": "design-system",
|
|
44
|
+
"tags": ["accessible", "enterprise", "developer", "functional"],
|
|
45
|
+
"url": "https://primer.style",
|
|
46
|
+
"status": "planned"
|
|
47
|
+
},
|
|
48
|
+
{
|
|
49
|
+
"id": "notion",
|
|
50
|
+
"name": "Notion",
|
|
51
|
+
"description": "Notion's design tokens — warm, approachable, content-first design with playful illustrations.",
|
|
52
|
+
"category": "productivity",
|
|
53
|
+
"tags": ["warm", "content-first", "approachable", "illustrations"],
|
|
54
|
+
"url": "https://notion.so",
|
|
55
|
+
"status": "planned"
|
|
56
|
+
},
|
|
57
|
+
{
|
|
58
|
+
"id": "supabase",
|
|
59
|
+
"name": "Supabase",
|
|
60
|
+
"description": "Supabase's design tokens — dark-mode-first developer tool aesthetic with green accent.",
|
|
61
|
+
"category": "developer",
|
|
62
|
+
"tags": ["dark", "developer", "green-accent", "technical"],
|
|
63
|
+
"url": "https://supabase.com",
|
|
64
|
+
"status": "planned"
|
|
65
|
+
}
|
|
66
|
+
]
|
|
67
|
+
}
|
|
@@ -0,0 +1,134 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$name": "Linear",
|
|
3
|
+
"$description": "Linear design system tokens — dark-first, minimal, fast. Iconic developer productivity aesthetic.",
|
|
4
|
+
"color": {
|
|
5
|
+
"$type": "color",
|
|
6
|
+
"primary": { "$value": "#5E6AD2", "$description": "Linear purple — the signature brand color" },
|
|
7
|
+
"primary-light": { "$value": "#7B83EB", "$description": "Lighter purple for hover" },
|
|
8
|
+
"primary-dark": { "$value": "#4E5BBF", "$description": "Darker purple for active" },
|
|
9
|
+
"background": { "$value": "#191A23", "$description": "Dark background" },
|
|
10
|
+
"background-surface": { "$value": "#1F2028", "$description": "Slightly elevated surface" },
|
|
11
|
+
"background-raised": { "$value": "#25262F", "$description": "Raised surface (cards, panels)" },
|
|
12
|
+
"background-overlay": { "$value": "#2C2D3A", "$description": "Overlay background (modals)" },
|
|
13
|
+
"border": { "$value": "#2E2F3E", "$description": "Default border" },
|
|
14
|
+
"border-strong": { "$value": "#3E3F4E", "$description": "Strong border" },
|
|
15
|
+
"text-primary": { "$value": "#F2F2F2", "$description": "Primary text" },
|
|
16
|
+
"text-secondary": { "$value": "#8A8F98", "$description": "Secondary text" },
|
|
17
|
+
"text-tertiary": { "$value": "#5E6068", "$description": "Tertiary/muted text" },
|
|
18
|
+
"text-inverse": { "$value": "#191A23", "$description": "Text on light backgrounds" },
|
|
19
|
+
"accent-red": { "$value": "#EB5757", "$description": "Urgent/bug priority" },
|
|
20
|
+
"accent-orange": { "$value": "#F2994A", "$description": "High priority" },
|
|
21
|
+
"accent-yellow": { "$value": "#F2C94C", "$description": "Medium priority" },
|
|
22
|
+
"accent-green": { "$value": "#6FCF97", "$description": "Low priority / success" },
|
|
23
|
+
"accent-blue": { "$value": "#56CCF2", "$description": "No priority / info" },
|
|
24
|
+
"accent-purple": { "$value": "#BB6BD9", "$description": "Feature label" },
|
|
25
|
+
"success": { "$value": "#6FCF97", "$description": "Success state" },
|
|
26
|
+
"error": { "$value": "#EB5757", "$description": "Error state" },
|
|
27
|
+
"warning": { "$value": "#F2994A", "$description": "Warning state" },
|
|
28
|
+
"info": { "$value": "#56CCF2", "$description": "Info state" }
|
|
29
|
+
},
|
|
30
|
+
"color-light": {
|
|
31
|
+
"$type": "color",
|
|
32
|
+
"background": { "$value": "#FFFFFF", "$description": "Light mode background" },
|
|
33
|
+
"background-surface": { "$value": "#F7F7F8", "$description": "Light mode surface" },
|
|
34
|
+
"background-raised": { "$value": "#FFFFFF", "$description": "Light mode raised surface" },
|
|
35
|
+
"border": { "$value": "#E8E8EC", "$description": "Light mode border" },
|
|
36
|
+
"border-strong": { "$value": "#D4D4DB", "$description": "Light mode strong border" },
|
|
37
|
+
"text-primary": { "$value": "#1B1C26", "$description": "Light mode primary text" },
|
|
38
|
+
"text-secondary": { "$value": "#6B6F76", "$description": "Light mode secondary text" },
|
|
39
|
+
"text-tertiary": { "$value": "#9B9FA5", "$description": "Light mode tertiary text" }
|
|
40
|
+
},
|
|
41
|
+
"typography": {
|
|
42
|
+
"font-family": {
|
|
43
|
+
"$type": "fontFamily",
|
|
44
|
+
"body": { "$value": "\"Inter\", -apple-system, BlinkMacSystemFont, \"Segoe UI\", sans-serif", "$description": "Primary font — Inter for clean UI text" },
|
|
45
|
+
"display": { "$value": "\"Inter\", -apple-system, BlinkMacSystemFont, \"Segoe UI\", sans-serif", "$description": "Same family, different weight for display" },
|
|
46
|
+
"mono": { "$value": "\"JetBrains Mono\", \"Fira Code\", monospace", "$description": "Monospace for code and identifiers" }
|
|
47
|
+
},
|
|
48
|
+
"font-size": {
|
|
49
|
+
"$type": "dimension",
|
|
50
|
+
"2xs": { "$value": "10px", "$description": "Tiny — status badges" },
|
|
51
|
+
"xs": { "$value": "11px", "$description": "Extra small — metadata" },
|
|
52
|
+
"sm": { "$value": "12px", "$description": "Small — secondary labels" },
|
|
53
|
+
"base": { "$value": "13px", "$description": "Default body text (Linear uses 13px)" },
|
|
54
|
+
"md": { "$value": "14px", "$description": "Slightly larger body" },
|
|
55
|
+
"lg": { "$value": "16px", "$description": "Large body / small headings" },
|
|
56
|
+
"xl": { "$value": "18px", "$description": "Section headings" },
|
|
57
|
+
"2xl": { "$value": "22px", "$description": "Page headings" },
|
|
58
|
+
"3xl": { "$value": "28px", "$description": "Large headings" },
|
|
59
|
+
"4xl": { "$value": "36px", "$description": "Display text" }
|
|
60
|
+
},
|
|
61
|
+
"font-weight": {
|
|
62
|
+
"$type": "fontWeight",
|
|
63
|
+
"regular": { "$value": "400" },
|
|
64
|
+
"medium": { "$value": "500" },
|
|
65
|
+
"semibold": { "$value": "600" },
|
|
66
|
+
"bold": { "$value": "700" }
|
|
67
|
+
},
|
|
68
|
+
"line-height": {
|
|
69
|
+
"$type": "number",
|
|
70
|
+
"tight": { "$value": "1.2", "$description": "Headings" },
|
|
71
|
+
"snug": { "$value": "1.35", "$description": "Compact text" },
|
|
72
|
+
"normal": { "$value": "1.5", "$description": "Body text" },
|
|
73
|
+
"relaxed": { "$value": "1.6", "$description": "Long-form content" }
|
|
74
|
+
}
|
|
75
|
+
},
|
|
76
|
+
"spacing": {
|
|
77
|
+
"$type": "dimension",
|
|
78
|
+
"0": { "$value": "0px" },
|
|
79
|
+
"0.5": { "$value": "2px" },
|
|
80
|
+
"1": { "$value": "4px" },
|
|
81
|
+
"1.5": { "$value": "6px" },
|
|
82
|
+
"2": { "$value": "8px" },
|
|
83
|
+
"3": { "$value": "12px" },
|
|
84
|
+
"4": { "$value": "16px" },
|
|
85
|
+
"5": { "$value": "20px" },
|
|
86
|
+
"6": { "$value": "24px" },
|
|
87
|
+
"8": { "$value": "32px" },
|
|
88
|
+
"10": { "$value": "40px" },
|
|
89
|
+
"12": { "$value": "48px" },
|
|
90
|
+
"16": { "$value": "64px" }
|
|
91
|
+
},
|
|
92
|
+
"radius": {
|
|
93
|
+
"$type": "dimension",
|
|
94
|
+
"none": { "$value": "0px" },
|
|
95
|
+
"sm": { "$value": "4px", "$description": "Buttons, inputs" },
|
|
96
|
+
"md": { "$value": "6px", "$description": "Cards, panels" },
|
|
97
|
+
"lg": { "$value": "8px", "$description": "Modals, large cards" },
|
|
98
|
+
"xl": { "$value": "12px", "$description": "Large containers" },
|
|
99
|
+
"full": { "$value": "9999px", "$description": "Pills, avatars" }
|
|
100
|
+
},
|
|
101
|
+
"elevation": {
|
|
102
|
+
"sm": {
|
|
103
|
+
"$type": "shadow",
|
|
104
|
+
"$value": "0 1px 2px rgba(0, 0, 0, 0.3)",
|
|
105
|
+
"$description": "Subtle shadow — used sparingly in dark UI"
|
|
106
|
+
},
|
|
107
|
+
"md": {
|
|
108
|
+
"$type": "shadow",
|
|
109
|
+
"$value": "0 4px 12px rgba(0, 0, 0, 0.4)",
|
|
110
|
+
"$description": "Medium elevation — dropdowns"
|
|
111
|
+
},
|
|
112
|
+
"lg": {
|
|
113
|
+
"$type": "shadow",
|
|
114
|
+
"$value": "0 8px 24px rgba(0, 0, 0, 0.5)",
|
|
115
|
+
"$description": "High elevation — modals, command palette"
|
|
116
|
+
}
|
|
117
|
+
},
|
|
118
|
+
"motion": {
|
|
119
|
+
"duration": {
|
|
120
|
+
"$type": "duration",
|
|
121
|
+
"instant": { "$value": "50ms", "$description": "Micro-interactions" },
|
|
122
|
+
"fast": { "$value": "100ms", "$description": "Hover states, toggles" },
|
|
123
|
+
"normal": { "$value": "150ms", "$description": "Transitions, opacity changes" },
|
|
124
|
+
"slow": { "$value": "250ms", "$description": "Panel open/close" },
|
|
125
|
+
"slower": { "$value": "400ms", "$description": "Page transitions" }
|
|
126
|
+
},
|
|
127
|
+
"easing": {
|
|
128
|
+
"$type": "cubicBezier",
|
|
129
|
+
"default": { "$value": [0.25, 0.1, 0.25, 1], "$description": "Standard easing" },
|
|
130
|
+
"spring": { "$value": [0.34, 1.56, 0.64, 1], "$description": "Spring for microinteractions" },
|
|
131
|
+
"in-out": { "$value": [0.42, 0, 0.58, 1], "$description": "Symmetric in-out" }
|
|
132
|
+
}
|
|
133
|
+
}
|
|
134
|
+
}
|