@adobe/spectrum-design-data 0.3.0 → 0.6.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.
Files changed (99) hide show
  1. package/LICENSE +1 -1
  2. package/components/accordion.json +108 -194
  3. package/components/action-bar.json +64 -97
  4. package/components/action-button.json +95 -230
  5. package/components/action-group.json +88 -86
  6. package/components/alert-banner.json +104 -76
  7. package/components/alert-dialog.json +78 -126
  8. package/components/avatar-group.json +61 -119
  9. package/components/avatar.json +98 -212
  10. package/components/badge.json +138 -256
  11. package/components/breadcrumbs.json +95 -89
  12. package/components/button-group.json +57 -48
  13. package/components/button.json +151 -368
  14. package/components/calendar.json +97 -34
  15. package/components/cards.json +109 -250
  16. package/components/checkbox-group.json +50 -58
  17. package/components/checkbox.json +121 -186
  18. package/components/close-button.json +61 -124
  19. package/components/coach-indicator.json +63 -72
  20. package/components/coach-mark.json +89 -93
  21. package/components/color-area.json +68 -94
  22. package/components/color-handle.json +39 -79
  23. package/components/color-loupe.json +35 -52
  24. package/components/color-slider.json +95 -116
  25. package/components/color-wheel.json +67 -73
  26. package/components/combo-box.json +243 -331
  27. package/components/contextual-help.json +86 -175
  28. package/components/date-picker.json +139 -179
  29. package/components/divider.json +30 -69
  30. package/components/drop-zone.json +51 -92
  31. package/components/field-label.json +75 -117
  32. package/components/help-text.json +81 -105
  33. package/components/illustrated-message.json +106 -73
  34. package/components/in-line-alert.json +50 -83
  35. package/components/link.json +63 -85
  36. package/components/list-view.json +107 -146
  37. package/components/menu.json +180 -274
  38. package/components/meter.json +72 -118
  39. package/components/number-field.json +213 -305
  40. package/components/picker.json +208 -320
  41. package/components/popover.json +94 -129
  42. package/components/progress-bar.json +94 -131
  43. package/components/progress-circle.json +45 -72
  44. package/components/radio-button.json +87 -156
  45. package/components/radio-group.json +107 -74
  46. package/components/rating.json +66 -99
  47. package/components/search-field.json +132 -202
  48. package/components/segmented-control.json +94 -109
  49. package/components/select-box.json +119 -179
  50. package/components/side-navigation.json +108 -118
  51. package/components/slider.json +143 -228
  52. package/components/standard-dialog.json +96 -114
  53. package/components/standard-panel.json +105 -53
  54. package/components/status-light.json +104 -240
  55. package/components/steplist.json +77 -161
  56. package/components/swatch-group.json +42 -58
  57. package/components/swatch.json +75 -162
  58. package/components/switch.json +101 -189
  59. package/components/table.json +97 -102
  60. package/components/tabs.json +77 -104
  61. package/components/tag-field.json +86 -150
  62. package/components/tag-group.json +50 -44
  63. package/components/tag.json +81 -198
  64. package/components/takeover-dialog.json +59 -57
  65. package/components/text-area.json +200 -323
  66. package/components/text-field.json +183 -304
  67. package/components/thumbnail.json +63 -105
  68. package/components/toast.json +97 -83
  69. package/components/tooltip.json +104 -96
  70. package/components/tree-view.json +169 -181
  71. package/guidelines/app-frame-content-area.json +87 -0
  72. package/guidelines/app-frame-creating-bluelines.json +61 -0
  73. package/guidelines/app-frame-header.json +75 -0
  74. package/guidelines/app-frame-overview.json +167 -0
  75. package/guidelines/app-frame-side-navigation.json +138 -0
  76. package/guidelines/attention-hierarchy.json +42 -0
  77. package/guidelines/background-layers.json +41 -0
  78. package/guidelines/brand.json +50 -0
  79. package/guidelines/colors.json +65 -0
  80. package/guidelines/containers.json +65 -0
  81. package/guidelines/developer-overview.json +38 -0
  82. package/guidelines/faqs.json +35 -0
  83. package/guidelines/fonts.json +58 -0
  84. package/guidelines/grays.json +69 -0
  85. package/guidelines/icon-fundamentals.json +45 -0
  86. package/guidelines/illustrations.json +114 -0
  87. package/guidelines/introduction.json +34 -0
  88. package/guidelines/manifest.json +204 -0
  89. package/guidelines/motion.json +41 -0
  90. package/guidelines/object-styles.json +105 -0
  91. package/guidelines/principles.json +30 -0
  92. package/guidelines/resources.json +59 -0
  93. package/guidelines/spacing.json +25 -0
  94. package/guidelines/states.json +34 -0
  95. package/guidelines/typography-fundamentals.json +145 -0
  96. package/guidelines/using-icons.json +110 -0
  97. package/package.json +5 -2
  98. package/tokens/layout-component.tokens.json +72 -36
  99. package/tokens/layout.tokens.json +207 -92
@@ -0,0 +1,87 @@
1
+ {
2
+ "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
3
+ "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/app-frame-content-area.json",
4
+ "name": "app-frame-content-area",
5
+ "title": "App frame content area (browsing context)",
6
+ "category": "designing",
7
+ "documentBlocks": [
8
+ {
9
+ "type": "purpose",
10
+ "content": "App frame content area (browsing context)"
11
+ },
12
+ {
13
+ "type": "guideline",
14
+ "content": "This layout is suitable when all content is related and unified by the primary purpose of the page. This single section can be subdivided using full-width dividers, or by creating visual groupings of content using proximity and spacing."
15
+ },
16
+ {
17
+ "type": "guideline",
18
+ "content": "Dividers are useful to separate content when using spacing alone wouldn’t be clear enough to mark the boundaries of distinct areas. Generally, more complex content with a varying alignment of objects will benefit the most from using a divider."
19
+ },
20
+ {
21
+ "type": "guideline",
22
+ "content": "The top section can also be useful to visually indicate that the content is separate and has additional affordances, such as the ability to be minimized. For example, “welcome” type content might be shown in the top section, and recent files might be shown below."
23
+ },
24
+ {
25
+ "type": "guideline",
26
+ "content": "When using horizontal sections, the page should scroll as a single unit. Consider other ways to minimize the top section if needed, such as through an additional control to show and hide content."
27
+ },
28
+ {
29
+ "type": "guideline",
30
+ "content": "The top section of a horizontal layout should be reserved for high-attention marketing messages or quick actions, and it should not be scrollable. Put infinite scrolling and longer content in the bottom section."
31
+ },
32
+ {
33
+ "type": "guideline",
34
+ "content": "This layout is suitable to separate content that’s not semantically related, and if one of the content areas can be minimized. For example, this might apply for onboarding tutorials, or to include an AI assistant."
35
+ },
36
+ {
37
+ "type": "guideline",
38
+ "content": "This layout is suitable to separate multiple groups of content that aren’t semantically related. For example, this could show several widgets and distinct marketing messages. This layout can also be useful if a user is able to customize the page."
39
+ },
40
+ {
41
+ "type": "guideline",
42
+ "content": "Make sure to consider smaller breakpoints and decide how content areas should reflow, hide, or combine. In general, show the most important information at the top, and if possible, then progressively disclose the not-as-important information."
43
+ },
44
+ {
45
+ "type": "guideline",
46
+ "content": "Backgrounds that use gradients are always placed within the app frame intentionally and with a strategic meaning. They should contribute to the visual hierarchy, not distract from it. And, their colors are directly tied to product brand color palettes."
47
+ },
48
+ {
49
+ "type": "guideline",
50
+ "content": "For example, on a Home screen, gradient backgrounds might call attention to new AI features in the product. On a Learn screen, gradient backgrounds might call attention to tutorials from new creators. On a Files screen, gradient backgrounds might not be used at all in order to focus attention on asset previews. In any context, consider where you want to draw attention and what you want to highlight for the user, what the user’s intentions might be, and how gradient backgrounds may add or detract from the goals of the page."
51
+ },
52
+ {
53
+ "type": "guideline",
54
+ "content": "While there isn’t an objective scale for each style, it can be helpful to think about backgrounds in terms of how much attention they draw, on a scale of low-to-high."
55
+ },
56
+ {
57
+ "type": "guideline",
58
+ "content": "While you may have seen past Spectrum 2 explorations showing gradients as the background in header and navigational areas, they should not be used in that context. This is because gradients that appear in the navigation of every page distract from more important information on the page, clash with other imagery, and might not work for some product segments."
59
+ },
60
+ {
61
+ "type": "guideline",
62
+ "content": "By using gradients in the content areas as backgrounds instead, there’s more flexibility to direct attention to different content and messages, depending on what’s important in the context of that page or workflow."
63
+ },
64
+ {
65
+ "type": "guideline",
66
+ "content": "Gradients are used to draw attention to important content and features. They can be used in the background of content areas. Using gradients in more than one content area results in multiple areas competing for attention. This is distracting from the task-at-hand workflows on the page."
67
+ },
68
+ {
69
+ "type": "guideline",
70
+ "content": "Gradients should always be delivered directly from the Spectrum Brand team and used as-is. Do not modify them."
71
+ }
72
+ ],
73
+ "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/app-frame-content-area/",
74
+ "lastUpdated": "2026-02-02",
75
+ "status": "published",
76
+ "tags": ["designing"],
77
+ "related": [
78
+ {
79
+ "ref": "s2-app-frame-side-navigation-browsing-context",
80
+ "kind": "guideline"
81
+ },
82
+ {
83
+ "ref": "s2-app-frame-creating-bluelines-browsing-context",
84
+ "kind": "guideline"
85
+ }
86
+ ]
87
+ }
@@ -0,0 +1,61 @@
1
+ {
2
+ "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
3
+ "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/app-frame-creating-bluelines.json",
4
+ "name": "app-frame-creating-bluelines",
5
+ "title": "Creating bluelines (browsing context)",
6
+ "category": "designing",
7
+ "documentBlocks": [
8
+ { "type": "purpose", "content": "Creating bluelines (browsing context)" },
9
+ {
10
+ "type": "guideline",
11
+ "content": "Accessible names vary depending on the content. Accessible names must be defined for controls that don’t have visible text labels."
12
+ },
13
+ {
14
+ "type": "guideline",
15
+ "content": "Here are some guidelines to keep in mind as you define accessible names in the app frame:"
16
+ },
17
+ {
18
+ "type": "guideline",
19
+ "content": "Any non-text element in a digital interface with a text label must have a text alternative. Here’s an example of how you might name landmark regions in an app frame:"
20
+ },
21
+ {
22
+ "type": "guideline",
23
+ "content": "Here’s an example of how you might structure heading annotations for this screen:"
24
+ },
25
+ {
26
+ "type": "guideline",
27
+ "content": "Keyboard focus order will depend on what controls are available on the page. Here’s an example of how you might define the order in the app frame:"
28
+ },
29
+ {
30
+ "type": "guideline",
31
+ "content": "Example of correct usage, support for keyboard focus for size navigation. The side navigation width is focusable and resizable by using the left and right arrow keys."
32
+ },
33
+ {
34
+ "type": "guideline",
35
+ "content": "Example of correct usage, inclusion of a Skip to main content button within the app frame header."
36
+ },
37
+ {
38
+ "type": "guideline",
39
+ "content": "When properly supported, the F6 key allows keyboard users to navigate through different regions of an application efficiently. Without this support, keyboard-only users have no means to jump to specific areas of the application, resulting in an excessive number of keystrokes to reach their desired goal."
40
+ },
41
+ {
42
+ "type": "guideline",
43
+ "content": "Here are some key quality factors to consider:"
44
+ },
45
+ {
46
+ "type": "guideline",
47
+ "content": "For mobile breakpoints, a tray is used to open and close the app frame side navigation. In this example, the keyboard focus order starts at the “Create” button and ends at the close button. Clicking on esc should also close the tray."
48
+ }
49
+ ],
50
+ "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/app-frame-creating-bluelines/",
51
+ "lastUpdated": "2026-02-02",
52
+ "status": "published",
53
+ "tags": ["designing"],
54
+ "related": [
55
+ {
56
+ "ref": "s2-app-frame-content-area-browsing-context",
57
+ "kind": "guideline"
58
+ },
59
+ { "ref": "brand", "kind": "guideline" }
60
+ ]
61
+ }
@@ -0,0 +1,75 @@
1
+ {
2
+ "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
3
+ "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/app-frame-header.json",
4
+ "name": "app-frame-header",
5
+ "title": "App frame header (browsing context)",
6
+ "category": "designing",
7
+ "documentBlocks": [
8
+ { "type": "purpose", "content": "App frame header (browsing context)" },
9
+ {
10
+ "type": "guideline",
11
+ "content": "There are several parts of the header that are consistent across all Adobe products:"
12
+ },
13
+ {
14
+ "type": "guideline",
15
+ "content": "Shows a hamburger button on the far left of the header. This controls whether the minimized style of the side navigation (partial/full)."
16
+ },
17
+ { "type": "guideline", "content": "Shows navigation items in the header." },
18
+ { "type": "guideline", "content": "Shows a search option in the header." },
19
+ {
20
+ "type": "guideline",
21
+ "content": "Defines the style of the search option that's shown."
22
+ },
23
+ {
24
+ "type": "guideline",
25
+ "content": "The “skip to main content” button helps improve keyboard navigation by creating a shortcut to the main content of the page. This button is an accessibility feature to allow skipping to the first navigable HTML item."
26
+ },
27
+ {
28
+ "type": "guideline",
29
+ "content": "Shows an icon to represent the header navigation item."
30
+ },
31
+ {
32
+ "type": "guideline",
33
+ "content": "The text that is displayed as the label of the header navigation item."
34
+ },
35
+ {
36
+ "type": "guideline",
37
+ "content": "Presents the header side navigation as selected or not selected."
38
+ },
39
+ {
40
+ "type": "guideline",
41
+ "content": "Changes the header navigation item to the disabled state."
42
+ },
43
+ {
44
+ "type": "guideline",
45
+ "content": "Shows a chevron next to the label that indicates an additional menu."
46
+ },
47
+ {
48
+ "type": "guideline",
49
+ "content": "The text that is displayed as the label of the tooltip."
50
+ },
51
+ {
52
+ "type": "guideline",
53
+ "content": "As a general rule, only use one call-to-action (CTA) button, aside from any buttons used to log in or log out, as defined in the universal nav. When too many CTAs are shown at once, the messages compete for attention and dilute the ability for a focused attention hierarchy."
54
+ },
55
+ {
56
+ "type": "guideline",
57
+ "content": "If there are multiple actions, consider combining them into a single menu or use other button types. The button should represent the most important CTA across the product; for example, “Share” and “Get desktop app” are common CTAs."
58
+ },
59
+ {
60
+ "type": "guideline",
61
+ "content": "Diagram with notes about the app frame header in the editing context. If there’s a menu represented by a hamburger icon, such as the application menu in Creative Cloud, it should be shown to the left of the product logo for continuity with the browsing context. The product name can be hidden in the editing context in order to provide more room for other actions. The height of the header should be the same as in the browsing context (56 px)."
62
+ }
63
+ ],
64
+ "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/app-frame-header/",
65
+ "lastUpdated": "2026-02-02",
66
+ "status": "published",
67
+ "tags": ["designing"],
68
+ "related": [
69
+ { "ref": "s2-app-frame", "kind": "guideline" },
70
+ {
71
+ "ref": "s2-app-frame-side-navigation-browsing-context",
72
+ "kind": "guideline"
73
+ }
74
+ ]
75
+ }
@@ -0,0 +1,167 @@
1
+ {
2
+ "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
3
+ "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/app-frame-overview.json",
4
+ "name": "app-frame-overview",
5
+ "title": "App frame",
6
+ "category": "designing",
7
+ "documentBlocks": [
8
+ { "type": "purpose", "content": "App frame" },
9
+ {
10
+ "type": "guideline",
11
+ "content": "The app frame is the core navigation direction for Spectrum 2. It’s designed as a flexible framework that’s readily adaptable to specific product needs while still creating a shared, predictable experience across products."
12
+ },
13
+ {
14
+ "type": "guideline",
15
+ "content": "The app frame needs to be opinionated without being restrictive. It directly accounts for the needs of future Spectrum 2 products, and is also flexible enough to be readily adaptable across varying product segment needs."
16
+ },
17
+ {
18
+ "type": "guideline",
19
+ "content": "A cohesive, consistent app frame reinforces Adobe’s brand and helps users feel comfortable and familiar with our products. Predictable navigation across products is also imperative for Adobe to support users working across multiple applications — and helps people more readily learn how to use new products."
20
+ },
21
+ {
22
+ "type": "guideline",
23
+ "content": "The app frame is the main stage to showcase the Spectrum 2 style, and it reflects the core foundations and principles of the design system. It works readily with all other design system resources, is committed to complying with WCAG standards, and holds the highest standards for globalization support."
24
+ },
25
+ {
26
+ "type": "guideline",
27
+ "content": "Spectrum offers a high-level direction as well as a definition of which parts can be flexible and which parts need to be highly predictable. Product teams are then empowered to apply this direction in ways that make the most sense for their use cases and users."
28
+ },
29
+ {
30
+ "type": "guideline",
31
+ "content": "Zones are the general areas into which certain types of actions should go. They’re not specific to components."
32
+ },
33
+ {
34
+ "type": "guideline",
35
+ "content": "This is a general area that contains global actions, such as view actions (e.g., layout and zoom options) and supplemental features (e.g., AI Assistants). Actions here can be shown in different ways, such as using part of the content area to show actions in the header, or in a dedicated side rail. There is no single visual representation of how actions should look in this area."
36
+ },
37
+ {
38
+ "type": "guideline",
39
+ "content": "This area is reserved for transient actions that are contextual to content on the page (e.g., an action bar)."
40
+ },
41
+ {
42
+ "type": "guideline",
43
+ "content": "Parts of the anatomy have defined rules and behaviors. The terms used here to describe the anatomy of the app framework are for internal alignment only, and are not representative of how these parts of the app frame should be described to end users."
44
+ },
45
+ {
46
+ "type": "guideline",
47
+ "content": "In the S2 app frame, gradients are only used as backgrounds in content areas — they are not used in the header (A) and navigational areas (B). This allows for greater flexibility between pages where gradients may be calling attention to different kinds of content."
48
+ },
49
+ {
50
+ "type": "guideline",
51
+ "content": "There are two variants of the side navigation state control: hamburger and panel. They should never be used at the same time."
52
+ },
53
+ {
54
+ "type": "guideline",
55
+ "content": "Interacting with this icon in the header will either fully expand and collapse, or partially collapse, the panel."
56
+ },
57
+ {
58
+ "type": "guideline",
59
+ "content": "When hovering on the panel icon, the icon will show an animated preview of what action would be done upon interaction (either expanding or collapsing). This animation offers more context about what to expect. The placement of the panel icon is at the bottom of the app frame side navigation panel."
60
+ },
61
+ {
62
+ "type": "guideline",
63
+ "content": "To activate or deactivate the TAB, select the 9-grid icon. Once clicked on, the TAB will appear above the header. On a screen reader, if there is an alert banner present, then the visual placement from top to bottom would be alert banner, TAB, then header."
64
+ },
65
+ {
66
+ "type": "guideline",
67
+ "content": "The placement and appearance of the TAB icon may differ across Adobe products. Not all products will utilize the TAB. The currently supported products are Adobe Home, Firefly, Express, Photoshop, Lightroom, and Acrobat."
68
+ },
69
+ {
70
+ "type": "guideline",
71
+ "content": "For products that use the TAB, the side navigation state control (panel icon) will be at the bottom of the side navigation. For mobile experiences, the side navigation state control (hamburger icon) and product switcher will be in the header."
72
+ },
73
+ {
74
+ "type": "guideline",
75
+ "content": "The following are some common terms used at Adobe for describing the core UI elements that make up the app frame, along with some notable usage considerations. Consider this as a starting point for you to take and develop into working language that may need to be more contextual for your product. Work with your Content Strategy partners to adapt it to your needs."
76
+ },
77
+ {
78
+ "type": "guideline",
79
+ "content": "The word “content” is general in theory but specific in application. In general, it’s a catch-all word for something that is contained in a designated space, and communicates meaning or intention. Specific to the context of the app frame, it describes that what goes into this area is at the discretion of a given situation or user experience."
80
+ },
81
+ {
82
+ "type": "guideline",
83
+ "content": "This is a commonly used internal term, but is not recommended for describing the interface to an end user. This is because it relies upon a visual metaphor to mimic an analog concept: something that “sinks” into a UI plane, like a water well sinks into the surface of the ground."
84
+ },
85
+ {
86
+ "type": "guideline",
87
+ "content": "Internal jargon is important and we want to be aligned across teams, but we also need to be careful about using internal terms, externally. By “user-facing term,” we mean that user to be the “end user”: the person who encounters the UI of an Adobe experience."
88
+ },
89
+ {
90
+ "type": "guideline",
91
+ "content": "In general, if you’re creating resources for internal usage (such as design guidelines or specs), you can safely use internal jargon. If you’re creating actual product UI, you will need to ensure that you’re using the appropriate terms that will help your user best understand and navigate the interface. Use the following steps to decide on terms:"
92
+ },
93
+ {
94
+ "type": "guideline",
95
+ "content": "What's the context — the workflow or scenario — for where a term will appear? That will help you determine who you’re speaking to, with what language."
96
+ },
97
+ {
98
+ "type": "guideline",
99
+ "content": "Different deliverables will each have their own audience. For example:"
100
+ },
101
+ {
102
+ "type": "guideline",
103
+ "content": "Are you creating something for internal builders (designers, engineers, anyone creating products) at Adobe? Or are you creating something for an external user?"
104
+ },
105
+ {
106
+ "type": "guideline",
107
+ "content": "Be specific about who you’re speaking to. If you're speaking to an internal audience looking at design direction for how to build UI, that’s a different audience from the users who will ultimately work with the UI."
108
+ },
109
+ {
110
+ "type": "guideline",
111
+ "content": "Will the term appear as a UI string (such as the title of a panel)? Would it appear as a label in an image that shows the anatomy of different parts of the component?"
112
+ },
113
+ {
114
+ "type": "guideline",
115
+ "content": "The main focus for most users is on the content — the information being shown, and the actions to select from — rather than where or the means by which the action is contained."
116
+ },
117
+ {
118
+ "type": "guideline",
119
+ "content": "This app framework intentionally uses the anatomy term “content area” to describe the main information or main focus in a given view, because it’s a flexible area that’s contextual to the main view of a given place in a user’s workflow."
120
+ },
121
+ {
122
+ "type": "guideline",
123
+ "content": "To create more inclusive products, describe parts of the UI in terms of function (what something does, or what something is) rather than appearance or position (such as relative direction: left, right, top, bottom)."
124
+ },
125
+ {
126
+ "type": "guideline",
127
+ "content": "Describe the actions or items available."
128
+ },
129
+ {
130
+ "type": "guideline",
131
+ "content": "Avoid describing where to find specific items or actions in relation to UI construction."
132
+ },
133
+ {
134
+ "type": "guideline",
135
+ "content": "The word panel is acceptable as a user-facing term only when there is no other way to describe the interface."
136
+ },
137
+ {
138
+ "type": "guideline",
139
+ "content": "The word rail is acceptable to use as internal jargon, but it should never be used as a user-facing term. This is because the word is about how something looks: a long, straight divider, like a slide rule or a railroad track."
140
+ },
141
+ {
142
+ "type": "guideline",
143
+ "content": "Describe the action to take on the UI."
144
+ },
145
+ { "type": "guideline", "content": "Don’t describe the UI itself." },
146
+ {
147
+ "type": "guideline",
148
+ "content": "“Show” and “hide” are the preferred terms to use to describe the open/close actions on the side navigation. This is for several reasons:"
149
+ },
150
+ {
151
+ "type": "guideline",
152
+ "content": "As you’re designing the UI content of your app frame using this framework, follow the Spectrum content standards for all UI text and labels."
153
+ },
154
+ {
155
+ "type": "guideline",
156
+ "content": "Most of the components that will go into your app frame design have their own associated content standards:"
157
+ }
158
+ ],
159
+ "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/app-frame-overview/",
160
+ "lastUpdated": "2026-02-02",
161
+ "status": "published",
162
+ "tags": ["designing"],
163
+ "related": [
164
+ { "ref": "containers", "kind": "guideline" },
165
+ { "ref": "s2-app-frame-header-browsing-context", "kind": "guideline" }
166
+ ]
167
+ }
@@ -0,0 +1,138 @@
1
+ {
2
+ "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
3
+ "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/app-frame-side-navigation.json",
4
+ "name": "app-frame-side-navigation",
5
+ "title": "App frame side navigation (browsing context)",
6
+ "category": "designing",
7
+ "documentBlocks": [
8
+ {
9
+ "type": "purpose",
10
+ "content": "App frame side navigation (browsing context)"
11
+ },
12
+ {
13
+ "type": "guideline",
14
+ "content": "The side navigation is always used in partnership with the header, and never instead of it. When used, the side navigation holds the main categories of product functionality, such as workflow-related navigational items (e.g., Home, Files, Learn, Dashboards). Don’t use this for categorizing marketing pages."
15
+ },
16
+ {
17
+ "type": "guideline",
18
+ "content": "Side navigation consists of a few parts:"
19
+ },
20
+ {
21
+ "type": "guideline",
22
+ "content": "Additionally, this button should not be used outside of the app frame context. It has unique animations between expanding and collapsing that are optimized for the app frame side navigation panel."
23
+ },
24
+ {
25
+ "type": "guideline",
26
+ "content": "Allows the side navigation to be minimized by the user."
27
+ },
28
+ {
29
+ "type": "guideline",
30
+ "content": "The partial style displays icon-only side navigation items when minimized. The full style hides the side navigation when minimized."
31
+ },
32
+ {
33
+ "type": "guideline",
34
+ "content": "Shows a create button at the top of the panel."
35
+ },
36
+ { "type": "guideline", "content": "Enables drag on the side navigation." },
37
+ {
38
+ "type": "guideline",
39
+ "content": "If the side navigation panel can be minimized (Can be minimized: true), dragging to the min width (expanded) will collapse the side navigation into the minimized state."
40
+ },
41
+ {
42
+ "type": "guideline",
43
+ "content": "The minimum width that the side navigation panel can be adjusted to."
44
+ },
45
+ {
46
+ "type": "guideline",
47
+ "content": "The default width that the side navigation panel appears in."
48
+ },
49
+ {
50
+ "type": "guideline",
51
+ "content": "The text that is displayed as the label of the app frame side navigation item, to supplement the icon."
52
+ },
53
+ {
54
+ "type": "guideline",
55
+ "content": "Hides the label, making the app frame side navigation item icon-only."
56
+ },
57
+ {
58
+ "type": "guideline",
59
+ "content": "The number of lines that is shown before the label is truncated."
60
+ },
61
+ {
62
+ "type": "guideline",
63
+ "content": "After the user clicks on an app frame side navigation item, the left visual bar will turn gray-800, text will bold, and color will change to content-neutral."
64
+ },
65
+ {
66
+ "type": "guideline",
67
+ "content": "Changes the side navigation item to the disabled state."
68
+ },
69
+ {
70
+ "type": "guideline",
71
+ "content": "The text that is displayed as the label of the tooltip."
72
+ },
73
+ {
74
+ "type": "guideline",
75
+ "content": "Use the overlay variant of the app frame: side navigation (browsing) component for smaller breakpoints. The overlay is triggered via the hamburger menu in the header (rather than a touchpoint at the bottom)."
76
+ },
77
+ {
78
+ "type": "guideline",
79
+ "content": "Although 768 px is the recommended breakpoint to begin displaying the overlay designs, each product team should determine which breakpoint best suits their needs."
80
+ },
81
+ {
82
+ "type": "guideline",
83
+ "content": "The divider at the bottom of the side navigation is an intentional visual element that separates overflow side navigation items and end section items from the state control icon."
84
+ },
85
+ {
86
+ "type": "guideline",
87
+ "content": "The end section is optional and used to contain navigation items in a separate category that is secondary to the main navigation items. Categories, when defined, should readily communicate a clear purpose and be meaningful to users. Items placed here sit on a separate area. When resized to a smaller height, the items should append onto the start section and scroll together."
88
+ },
89
+ {
90
+ "type": "guideline",
91
+ "content": "The minimum width is customizable, depending on the number of levels:"
92
+ },
93
+ {
94
+ "type": "guideline",
95
+ "content": "If the side navigation contains user-generated content (like shortcuts to folders and files), enabling resizing can be a good way to improve usability by respecting user content, without needing to predict the length of labels that users might input."
96
+ },
97
+ {
98
+ "type": "guideline",
99
+ "content": "Along with being descriptive, the labels of navigation items should be succinct. Keep navigation strings to 1 or 2 and no more than 3 concise words (in U.S. English, which is the source locale). Reduce any unnecessary words in order to ensure simplicity."
100
+ },
101
+ {
102
+ "type": "guideline",
103
+ "content": "Navigation items should never be so long that they require truncation, except in instances where navigation is user-generated (e.g., folder and file names)."
104
+ },
105
+ {
106
+ "type": "guideline",
107
+ "content": "If possible, the default width should auto-adjust to the longest string in the navigation in order to accommodate all translations. As a last resort for long strings, specific line breaks can be built into the implementation. These line breaks depend on the content, and requires manual handling by Globalization engineers."
108
+ },
109
+ {
110
+ "type": "guideline",
111
+ "content": "When navigation items are shown in both the side navigation and header at the same time, the hierarchy and relationships between them become unclear. If the side navigation is used, don’t put any navigation items in the header."
112
+ },
113
+ {
114
+ "type": "guideline",
115
+ "content": "Supporting multiple states (default, and partial or fully minimized style) provides users with the option to choose their preferred layout based on their own preferences. In user studies, individual preference is the biggest factor when it comes to whether or not people want to view labels by default."
116
+ },
117
+ {
118
+ "type": "guideline",
119
+ "content": "If supporting multiple states, consider showing the side navigation in the expanded state by default, and preserve user preferences across pages and sessions. If minimizing the side navigation is not supported, show the side navigation in the expanded state. Showing labels by default increases recognition and familiarity."
120
+ },
121
+ {
122
+ "type": "guideline",
123
+ "content": "There are some app frame-specific constraints for the side navigation. Icons are required at the parent level. Nested items can have no icon, but the parent level must have an icon."
124
+ },
125
+ {
126
+ "type": "guideline",
127
+ "content": "Diagram describing notes about the side navigation for the app frame, in the editing context. While toolbars share the same location as the app frame side navigation in a browsing context, toolbars in an editing context serve a different purpose: to readily select commonly used tools, rather than to navigate between pages. The behavior and interaction of toolbars doesn’t need to mirror the side navigation and should instead best serve user needs in an editing context. For example, the option to show and hide tool labels can be an additional customization option and doesn’t need to be controlled by the hamburger menu, which is used to display the application menu in Creative Cloud."
128
+ }
129
+ ],
130
+ "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/app-frame-side-navigation/",
131
+ "lastUpdated": "2026-02-02",
132
+ "status": "published",
133
+ "tags": ["designing"],
134
+ "related": [
135
+ { "ref": "s2-app-frame-header-browsing-context", "kind": "guideline" },
136
+ { "ref": "s2-app-frame-content-area-browsing-context", "kind": "guideline" }
137
+ ]
138
+ }
@@ -0,0 +1,42 @@
1
+ {
2
+ "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
3
+ "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/attention-hierarchy.json",
4
+ "name": "attention-hierarchy",
5
+ "title": "Attention hierarchy",
6
+ "category": "designing",
7
+ "documentBlocks": [
8
+ { "type": "purpose", "content": "Attention hierarchy" },
9
+ {
10
+ "type": "guideline",
11
+ "content": "Design systems are ultimately communication systems. A main goal of any kind of UI communication — visual, linguistic, motion, and more — is to convey a message in a way that the audience can readily understand what they need to know and why it matters. And most importantly, communication needs to be respectful of user attention."
12
+ },
13
+ {
14
+ "type": "guideline",
15
+ "content": "**Attention hierarchy** is a core concept in Spectrum 2. This idea has always been a part of Spectrum as a design system — and a tenet of responsible UX design as a whole — but it's now more formalized as a way to validate assumptions using clear guidelines and considerations. It's based on the methods of typographic hierarchy, where scale, size, and text pairings help readers to readily recognize what's the most broad and important information to the most detailed and nice-to-know information. We've extended this practice beyond just text and into all the ways that UI communicates."
16
+ },
17
+ {
18
+ "type": "guideline",
19
+ "content": "Another way to think of attention hierarchy is as a way to manage the ratio of signal-to-noise in an experience. Different parts of the UI all communicate meaning, at different levels of attention. High attention elements show a primary area of focus, and communicate timely, high-signal meanings. Low attention elements blend into the background, and communicate more utilitarian, lower-priority meanings. Things like object styles, component options, and typography all draw different levels of attention."
20
+ },
21
+ {
22
+ "type": "guideline",
23
+ "content": "High attention elements should be used sparingly and selectively. If too many things are high attention at once, the experience becomes noisy and unfocused. For example, both high-contrast colors and elevation communicate specific meanings and add emphasis within pages and flows — and these are both used very thoughtfully."
24
+ },
25
+ {
26
+ "type": "guideline",
27
+ "content": "As a general rule, only one element or group of elements should have high attention on a page. Too many elements drawing high attention makes it difficult to focus."
28
+ },
29
+ {
30
+ "type": "guideline",
31
+ "content": "**Good example:** The \"Share\" button is the most timely and high-impact action to take in this example. It's high attention because the next step after finishing creating something within the canvas would be to share it."
32
+ },
33
+ {
34
+ "type": "guideline",
35
+ "content": "**Bad example:** The \"Share\" button is competing with the selected states of items in the navigation. These navigational items are still important for communicating wayfinding and context, but are not as timely as the action of sharing."
36
+ }
37
+ ],
38
+ "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/attention-hierarchy/",
39
+ "lastUpdated": "2026-02-02",
40
+ "status": "published",
41
+ "tags": ["designing"]
42
+ }
@@ -0,0 +1,41 @@
1
+ {
2
+ "$schema": "https://opensource.adobe.com/spectrum-design-data/schemas/v0/guideline.schema.json",
3
+ "$id": "https://opensource.adobe.com/spectrum-design-data/guidelines/background-layers.json",
4
+ "name": "background-layers",
5
+ "title": "Background layers",
6
+ "category": "designing",
7
+ "documentBlocks": [
8
+ {
9
+ "type": "guideline",
10
+ "content": "Layer 2 is the color of the canvas. This background layer color can also be used in both professional and lightweight editing applications, in the app frame, to put it on the same dimension as the primary content."
11
+ },
12
+ {
13
+ "type": "guideline",
14
+ "content": "Layer 1 can be used as the app frame color in professional editing applications, which require additional depth differentiation."
15
+ },
16
+ {
17
+ "type": "guideline",
18
+ "content": "The pasteboard has a dedicated background layer. This is because no components are placed directly on top of it, with the exception of an artboard (which uses a white background color). Other components should be placed on a layer 1, layer 2, or elevated background."
19
+ },
20
+ {
21
+ "type": "guideline",
22
+ "content": "This example shows an editing application using background layer 2 for both the artboard and the app frame. An elevated background is used for a floating toolbar, which appears on top of the canvas."
23
+ },
24
+ {
25
+ "type": "guideline",
26
+ "content": "Spectrum 2 uses gray-25 as the base background color to draw attention to the primary content of a page. Using gray-25 allows for higher contrast between the background and content, and it provides a blank canvas for more vibrant colors."
27
+ },
28
+ {
29
+ "type": "guideline",
30
+ "content": "In dark theme, the primary background (using the background base layer) is the darkest color. This allows for more flexibility for the grays that are layered on top of it, and provides contrast for more vibrant user-created content."
31
+ }
32
+ ],
33
+ "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/background-layers/",
34
+ "lastUpdated": "2026-02-02",
35
+ "status": "published",
36
+ "tags": ["designing"],
37
+ "related": [
38
+ { "ref": "colors", "kind": "guideline" },
39
+ { "ref": "typography-fundamentals", "kind": "guideline" }
40
+ ]
41
+ }