@adobe/spectrum-design-data 3.3.0-beta.1 → 3.3.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 (135) hide show
  1. package/components/accordion.json +67 -15
  2. package/components/action-bar.json +30 -9
  3. package/components/action-button.json +92 -39
  4. package/components/action-group.json +137 -18
  5. package/components/alert-banner.json +27 -8
  6. package/components/alert-dialog.json +55 -34
  7. package/components/avatar-group.json +35 -9
  8. package/components/avatar.json +105 -29
  9. package/components/badge.json +163 -56
  10. package/components/breadcrumbs.json +107 -26
  11. package/components/button-group.json +63 -19
  12. package/components/button.json +105 -61
  13. package/components/calendar.json +74 -8
  14. package/components/card.json +13 -0
  15. package/components/cards.json +46 -31
  16. package/components/checkbox-group.json +85 -16
  17. package/components/checkbox.json +97 -27
  18. package/components/close-button.json +75 -20
  19. package/components/coach-indicator.json +44 -14
  20. package/components/coach-mark.json +26 -8
  21. package/components/color-area.json +100 -20
  22. package/components/color-handle.json +46 -25
  23. package/components/color-loupe.json +14 -2
  24. package/components/color-slider.json +129 -26
  25. package/components/color-wheel.json +91 -17
  26. package/components/combo-box.json +189 -50
  27. package/components/contextual-help.json +126 -80
  28. package/components/date-field.json +7 -0
  29. package/components/date-picker.json +127 -24
  30. package/components/divider.json +38 -12
  31. package/components/drop-zone.json +37 -18
  32. package/components/field-label.json +62 -21
  33. package/components/heading.json +7 -0
  34. package/components/help-text.json +53 -16
  35. package/components/illustrated-message.json +85 -21
  36. package/components/in-line-alert.json +53 -13
  37. package/components/link.json +63 -24
  38. package/components/list-view.json +80 -15
  39. package/components/menu.json +181 -45
  40. package/components/meter.json +78 -24
  41. package/components/number-field.json +175 -34
  42. package/components/picker.json +188 -42
  43. package/components/popover.json +126 -37
  44. package/components/progress-bar.json +108 -23
  45. package/components/progress-circle.json +55 -12
  46. package/components/radio-button.json +67 -14
  47. package/components/radio-group.json +132 -28
  48. package/components/rating.json +38 -9
  49. package/components/search-field.json +126 -34
  50. package/components/segmented-control.json +70 -21
  51. package/components/select-box.json +103 -29
  52. package/components/side-navigation.json +69 -28
  53. package/components/slider.json +155 -39
  54. package/components/standard-dialog.json +88 -16
  55. package/components/status-light.json +136 -41
  56. package/components/steplist.json +24 -5
  57. package/components/swatch-group.json +55 -19
  58. package/components/swatch.json +79 -24
  59. package/components/switch.json +79 -31
  60. package/components/table.json +73 -26
  61. package/components/tabs.json +52 -22
  62. package/components/tag-field.json +60 -14
  63. package/components/tag-group.json +56 -16
  64. package/components/tag.json +78 -21
  65. package/components/takeover-dialog.json +61 -10
  66. package/components/text-area.json +205 -49
  67. package/components/text-field.json +170 -42
  68. package/components/thumbnail.json +63 -22
  69. package/components/time-field.json +7 -0
  70. package/components/toast.json +50 -29
  71. package/components/tooltip.json +87 -27
  72. package/components/tree-view.json +147 -45
  73. package/components/user-card.json +7 -0
  74. package/guidelines/app-frame-content-area.json +81 -0
  75. package/guidelines/app-frame-creating-bluelines.json +58 -0
  76. package/guidelines/app-frame-header.json +72 -0
  77. package/guidelines/app-frame-overview.json +50 -44
  78. package/guidelines/app-frame-side-navigation.json +138 -0
  79. package/guidelines/attention-hierarchy.json +21 -12
  80. package/guidelines/background-layers.json +10 -44
  81. package/guidelines/brand.json +10 -30
  82. package/guidelines/colors.json +17 -35
  83. package/guidelines/containers.json +62 -0
  84. package/guidelines/developer-overview.json +9 -25
  85. package/guidelines/faqs.json +9 -96
  86. package/guidelines/fonts.json +14 -29
  87. package/guidelines/grays.json +44 -17
  88. package/guidelines/icon-fundamentals.json +18 -7
  89. package/guidelines/illustrations.json +111 -0
  90. package/guidelines/introduction.json +2 -2
  91. package/guidelines/manifest.json +60 -252
  92. package/guidelines/motion.json +16 -17
  93. package/guidelines/object-styles.json +102 -0
  94. package/guidelines/principles.json +2 -2
  95. package/guidelines/resources.json +15 -21
  96. package/guidelines/spacing.json +25 -0
  97. package/guidelines/states.json +10 -15
  98. package/guidelines/typography-fundamentals.json +142 -0
  99. package/guidelines/using-icons.json +44 -33
  100. package/package.json +2 -2
  101. package/registry/platform-implementations.json +30 -0
  102. package/guidelines/ai-resource-guide.json +0 -50
  103. package/guidelines/applying-the-type-system.json +0 -63
  104. package/guidelines/bi-directionality.json +0 -57
  105. package/guidelines/border-width.json +0 -42
  106. package/guidelines/cognitive.json +0 -197
  107. package/guidelines/component-spacing.json +0 -49
  108. package/guidelines/contact-us.json +0 -67
  109. package/guidelines/content-area-browsing-context.json +0 -65
  110. package/guidelines/creating-bluelines-browsing-context.json +0 -91
  111. package/guidelines/design-tokens.json +0 -122
  112. package/guidelines/drop-shadow.json +0 -56
  113. package/guidelines/grammar-and-mechanics.json +0 -252
  114. package/guidelines/header-browsing-context.json +0 -37
  115. package/guidelines/illustration.json +0 -109
  116. package/guidelines/in-product-word-list.json +0 -29
  117. package/guidelines/inclusive-design.json +0 -93
  118. package/guidelines/inclusive-ux-writing.json +0 -30
  119. package/guidelines/internationalization.json +0 -87
  120. package/guidelines/layout-and-structure-containers.json +0 -47
  121. package/guidelines/layout-spacing.json +0 -39
  122. package/guidelines/object-styles-overview.json +0 -17
  123. package/guidelines/rounding.json +0 -61
  124. package/guidelines/side-navigation-browsing-context.json +0 -71
  125. package/guidelines/spacing-overview.json +0 -45
  126. package/guidelines/typography-overview.json +0 -39
  127. package/guidelines/typography-system.json +0 -168
  128. package/guidelines/visual-language-containers.json +0 -36
  129. package/guidelines/voice-and-tone.json +0 -47
  130. package/guidelines/writing-about-people.json +0 -103
  131. package/guidelines/writing-for-errors.json +0 -120
  132. package/guidelines/writing-for-onboarding.json +0 -119
  133. package/guidelines/writing-for-readability.json +0 -54
  134. package/guidelines/writing-with-visuals.json +0 -70
  135. package/registry/platform-extensions/web-components-states.json +0 -58
@@ -8,154 +8,160 @@
8
8
  { "type": "purpose", "content": "App frame" },
9
9
  {
10
10
  "type": "guideline",
11
- "content": "Flexible and adaptable.\n\nThe 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."
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
12
  },
13
13
  {
14
14
  "type": "guideline",
15
- "content": "Cohesive and predictable.\n\nA 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."
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
16
  },
17
17
  {
18
18
  "type": "guideline",
19
- "content": "Embodies Spectrum 2.\n\nThe 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."
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
20
  },
21
21
  {
22
22
  "type": "guideline",
23
- "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. We’re designing the app frame in stages that align to the two main experiences that are shared across all Adobe products: browsing and editing. What’s currently defined here is mainly focused on the browsing context: workflows that draw attention to the content as the primary focus (examples of pages in browsing contexts include a Home or Files experience). This does overlap with the editing context, where the workflow draws attention to the canvas as the primary focus, but we’re still defining the editing context in more detail overall. This framework defines broad information architecture: the general categories of objects, and where they go in the app frame. It does not define the location or ordering of specific objects within those categories. View Spectrum Patterns for more specific information architecture by product group. For guidance on Experience Cloud products, contact the DX Unified Experience team. For guidance on Creative Cloud products, contact the CC Unified Experience team."
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
24
  },
25
25
  {
26
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. We’re designing the app frame in stages that align to the two main experiences that are shared across all Adobe products: browsing and editing. What’s currently defined here is mainly focused on the browsing context: workflows that draw attention to the content as the primary focus (examples of pages in browsing contexts include a Home or Files experience). This does overlap with the editing context, where the workflow draws attention to the canvas as the primary focus, but we’re still defining the editing context in more detail overall. This framework defines broad information architecture: the general categories of objects, and where they go in the app frame. It does not define the location or ordering of specific objects within those categories."
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
28
  },
29
29
  {
30
30
  "type": "guideline",
31
- "content": "Browsing context: Zones.\n\nZones are the general areas into which certain types of actions should go. They’re not specific to components."
31
+ "content": "Zones are the general areas into which certain types of actions should go. They’re not specific to components."
32
32
  },
33
33
  {
34
34
  "type": "guideline",
35
- "content": "A. Navigation zone.\n\nThis area holds the primary navigational items on a page. Navigation should be highly predictable across products. In the Spectrum 2 app frame, navigation can be shown in different ways: through the header and side navigation components, as well as through other navigational components (e.g., side navigation and tabs ) within the content area for secondary navigation."
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
36
  },
37
37
  {
38
38
  "type": "guideline",
39
- "content": "B. Global action zone.\n\nThis 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."
39
+ "content": "This area is reserved for transient actions that are contextual to content on the page (e.g., an action bar)."
40
40
  },
41
41
  {
42
42
  "type": "guideline",
43
- "content": "C. Contextual action zone.\n\nThis area is reserved for transient actions that are contextual to content on the page (e.g., an action bar)."
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
44
  },
45
45
  {
46
46
  "type": "guideline",
47
- "content": "Browsing context: Anatomy.\n\nParts 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."
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
48
  },
49
49
  {
50
50
  "type": "guideline",
51
- "content": "A. App frame header (Navigation, required).\n\nHolds the product brand and global actions, including the universal nav. This area can include top-level navigation, and is suitable for categorizing product segments (e.g., marketing contexts) and for larger fly-outs. If there is an app frame side navigation instead, use this area for global, app-wide actions (e.g., search). View header guidelines and examples in App frame header (browsing context)."
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
52
  },
53
53
  {
54
54
  "type": "guideline",
55
- "content": "B. App frame side navigation (Navigation, optional).\n\nHolds the main categories of product functionality, such as workflow-related navigational items (e.g., home, files, learn, dashboards). This navigation has specific behaviors for showing and minimizing labels. Do not use this for categorizing marketing pages. View side navigation guidelines and examples in App frame side navigation (browsing context)."
55
+ "content": "Interacting with this icon in the header will either fully expand and collapse, or partially collapse, the panel."
56
56
  },
57
57
  {
58
58
  "type": "guideline",
59
- "content": "C. Content area (Required).\n\nModular space that supports multiple layout configurations. The content that goes inside this area is free and not defined by the app frame. More specific guidelines will be defined in Spectrum Patterns. Gradients, when used in this space, are applied with clear intent and strategic purpose. They should contribute to the visual hierarchy, not distract from it. And, their colors are directly tied to product brand color palettes. 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. View side navigation guidelines and examples in App frame content area (browsing context)."
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
60
  },
61
- { "type": "guideline", "content": "Anatomy examples" },
62
61
  {
63
62
  "type": "guideline",
64
- "content": "C. Content area (Required).\n\nModular space that supports multiple layout configurations. The content that goes inside this area is free and not defined by the app frame. Gradients, when used in this space, are applied with clear intent and strategic purpose. They should contribute to the visual hierarchy, not distract from it. And, their colors are directly tied to product brand color palettes. 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. View side navigation guidelines and examples in App frame content area (browsing context)."
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."
65
64
  },
66
65
  {
67
66
  "type": "guideline",
68
- "content": "Hamburger.\n\nInteracting with this icon in the header will either fully expand and collapse, or partially collapse, the panel."
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."
69
68
  },
70
69
  {
71
70
  "type": "guideline",
72
- "content": "Panel.\n\nWhen 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. Learn more about the side navigation state control’s user customization and preserve user preferences. App frame variants: Top App Bar (TAB) will go over the use cases of hamburger and panel icons."
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."
73
72
  },
74
73
  {
75
74
  "type": "guideline",
76
- "content": "How to use the TAB.\n\nTo 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."
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."
77
76
  },
78
77
  {
79
78
  "type": "guideline",
80
- "content": "Product-Specific Variations.\n\nThe 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."
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."
81
80
  },
82
81
  {
83
82
  "type": "guideline",
84
- "content": "TAB products (Digital Media).\n\nFor 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."
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."
85
84
  },
86
85
  {
87
86
  "type": "guideline",
88
- "content": "Non-TAB products (Digital Experience and Unified Shell).\n\nFor products that don’t use the TAB, the side navigation state control will always be the hamburger icon. View the Unified Shell component (Shell Frame) in the Spectrum 2 Experience Cloud Patterns library for more information."
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."
89
88
  },
90
89
  {
91
90
  "type": "guideline",
92
- "content": "Non-TAB products (Digital Experience and Unified Shell).\n\nFor products that don’t use the TAB, the side navigation state control will always be the hamburger icon."
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:"
93
92
  },
94
93
  {
95
94
  "type": "guideline",
96
- "content": "Some common Adobe terms for describing the UI.\n\nThe 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."
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."
97
96
  },
98
97
  {
99
98
  "type": "guideline",
100
- "content": "Panel, Rail.\n\nPanels and rails share so many similarities in their appearance and behaviors, as well as the same root concept: an area of content, with visible boundaries, affixed to one side, that has a specific focus or intention. These are a type of container, and can be flexible in what they contain. A panel is the preferred way to describe this general concept. This is because the word borrows from the well-known analog metaphor of a “control panel”: a flat board, usually square or rectangular, where controls are fixed."
99
+ "content": "Different deliverables will each have their own audience. For example:"
101
100
  },
102
101
  {
103
102
  "type": "guideline",
104
- "content": "Content area.\n\nSpectrum refers to a designated part of a composition of components as a content area if it can support many layout options, and is flexible in what it can contain. 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."
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?"
105
104
  },
106
105
  {
107
106
  "type": "guideline",
108
- "content": "Well.\n\nA well is a type of container that is used to show non-user-editable content. It generally communicates lower-attention, supplementary information. 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."
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."
109
108
  },
110
109
  {
111
110
  "type": "guideline",
112
- "content": "Identifying user-facing terms vs. internal-only terms.\n\nInternal 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. 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:"
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?"
113
112
  },
114
113
  {
115
114
  "type": "guideline",
116
- "content": "Note your context.\n\nWhat'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. Different deliverables will each have their own audience. For example: A label on a button in a UI mock, in Figma: end user Technical specs that show how to build UI: Adobe engineer Design guidelines that show assemblages of components: Adobe designer"
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."
117
116
  },
118
117
  {
119
118
  "type": "guideline",
120
- "content": "Assess your audience.\n\nAre you creating something for internal builders (designers, engineers, anyone creating products) at Adobe? Or are you creating something for an external user? 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."
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."
121
120
  },
122
121
  {
123
122
  "type": "guideline",
124
- "content": "Identify where the term will appear.\n\nWill 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? It’s generally OK to say things like \"left rail\" or “side panel” descriptively in day-to-day work conversation, but be careful about using that description in an end user/customer facing capacity. Review Creating accessible app frame terminology for more guidance."
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)."
125
124
  },
126
125
  {
127
126
  "type": "guideline",
128
- "content": "Focus on the content, not the container.\n\nThe 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. 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."
127
+ "content": "Describe the actions or items available."
129
128
  },
130
129
  {
131
130
  "type": "guideline",
132
- "content": "Avoid terms of relative direction or appearance.\n\nTo 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). Talk about the actions available or the names of the features inside of a part of the interface, rather than how the interface itself looks. View the Spectrum Inclusive UX writing guide for more guidelines and examples. Describe the actions or items available.Avoid describing where to find specific items or actions in relation to UI construction."
131
+ "content": "Avoid describing where to find specific items or actions in relation to UI construction."
133
132
  },
134
133
  {
135
134
  "type": "guideline",
136
- "content": "Using “panel” and “rail” as user-facing terms.\n\nThe word panel is acceptable as a user-facing term only when there is no other way to describe the interface. 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. View the Spectrum in-product word list for more details and usage notes about these and other terms to refer to parts of the interface. Describe the action to take on the UI.Don’t describe the UI itself."
135
+ "content": "The word panel is acceptable as a user-facing term only when there is no other way to describe the interface."
137
136
  },
138
137
  {
139
138
  "type": "guideline",
140
- "content": "“Show” and “Hide”.\n\n“Show” and “hide” are the preferred terms to use to describe the open/close actions on the side navigation. This is for several reasons: Globalization readiness. The words “show” and “hide” both have low character counts in U.S. English, and are the most common already-existing terms to express this concept across Adobe products. Plain language. “Hide” is more straightforward and common language than “Minimize,” and is also at the appropriate reading level for UI text. Conceptual accuracy. “Show” and “Hide” better align to their associated actions; items aren’t disappearing completely from view, but are being tucked away or are changing appearance."
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."
141
140
  },
142
141
  {
143
142
  "type": "guideline",
144
- "content": "When in doubt, use sentence case.\n\nAs you’re designing the UI content of your app frame using this framework, follow the Spectrum content standards for all UI text and labels. Most of the writing you’ll be doing for the app frame will be short labels. These, as well as all other UI content, are formatted in sentence case: only the first letter of the first word is capitalized. View the Spectrum Grammar and mechanics page."
143
+ "content": "Describe the action to take on the UI."
145
144
  },
145
+ { "type": "guideline", "content": "Don’t describe the UI itself." },
146
146
  {
147
147
  "type": "guideline",
148
- "content": "Refer to Spectrum Patterns.\n\nThere may be particular content standards or specific writing scenarios that are designed for your product. Defer to these product-specific terms and language preferences. Check the Spectrum Patterns documentation for product-specific writing guidelines, or ask your team’s Content Strategist for more resources."
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:"
149
157
  }
150
158
  ],
151
- "sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/app-frame/overview",
152
- "lastUpdated": "2026-09-04",
159
+ "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/app-frame-overview/",
160
+ "lastUpdated": "2026-02-02",
153
161
  "status": "published",
154
- "tags": [
155
- "App frame",
156
- "Framework",
157
- "Navigation",
158
- "Browsing context",
159
- "Editing context"
162
+ "tags": ["designing"],
163
+ "related": [
164
+ { "ref": "containers" },
165
+ { "ref": "s2-app-frame-header-browsing-context" }
160
166
  ]
161
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" },
136
+ { "ref": "s2-app-frame-content-area-browsing-context" }
137
+ ]
138
+ }
@@ -8,7 +8,15 @@
8
8
  { "type": "purpose", "content": "Attention hierarchy" },
9
9
  {
10
10
  "type": "guideline",
11
- "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. 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."
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."
12
20
  },
13
21
  {
14
22
  "type": "guideline",
@@ -16,18 +24,19 @@
16
24
  },
17
25
  {
18
26
  "type": "guideline",
19
- "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. The plus button is the most timely and high impact action to take in this example.Selected state of items in the navigation is competing with the plus button."
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."
20
36
  }
21
37
  ],
22
- "sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/attention-hierarchy",
23
- "lastUpdated": "2026-08-24",
38
+ "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/attention-hierarchy/",
39
+ "lastUpdated": "2026-02-02",
24
40
  "status": "published",
25
- "tags": [
26
- "attention hierarchy",
27
- "high attention",
28
- "low attention",
29
- "UI communication",
30
- "elevation",
31
- "contrast"
32
- ]
41
+ "tags": ["designing"]
33
42
  }
@@ -5,68 +5,34 @@
5
5
  "title": "Background layers",
6
6
  "category": "designing",
7
7
  "documentBlocks": [
8
- { "type": "purpose", "content": "Background layers" },
9
8
  {
10
- "type": "guideline",
11
- "content": "In Spectrum, background layers are used differently depending on the primary context of the page. For pages where the primary purpose is the canvas and related actions for editing, view Editing contexts. For pages where the primary focus is browsing content, such as a Home or Files experience, view Browsing contexts. If you’re not sure whether a page is in an editing or browsing context, contact the Spectrum design team. In addition to the three existing background layer options — background layer 1, background layer 2, and background base — Spectrum includes an elevated option. Elevated background layers create depth and emphasize content floating on top of a canvas. Background layer Light theme Dark theme Elevatedgray-25 (with drop shadow)gray-75 (with drop shadow)Layer 2gray-25gray-75Layer 1gray-50gray-50Pasteboardgray-100gray-25"
12
- },
13
- {
14
- "type": "guideline",
15
- "content": "Overview.\n\nIn Spectrum, background layers are used differently depending on the primary context of the page. For pages where the primary purpose is the canvas and related actions for editing, view Editing contexts. For pages where the primary focus is browsing content, such as a Home or Files experience, view Browsing contexts. If you’re not sure whether a page is in an editing or browsing context, contact the Spectrum design team."
16
- },
17
- {
18
- "type": "guideline",
19
- "content": "Editing application.\n\nPages in editing contexts draw attention to the canvas, which is the primary focus."
20
- },
21
- {
22
- "type": "guideline",
23
- "content": "Elevated (highest attention).\n\nElevated backgrounds create the illusion of depth through the use of a drop shadow, and display content that appears on top of other content. They draw attention and are used sparingly. In an editing application, this background option works well for parts of the app frame that appear on top of the canvas, such as a floating toolbar, panel, or popover."
24
- },
25
- {
26
- "type": "guideline",
27
- "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."
28
- },
29
- {
30
- "type": "guideline",
31
- "content": "Pasteboard.\n\nThe 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."
32
- },
33
- {
34
- "type": "guideline",
9
+ "type": "purpose",
35
10
  "content": "Layer 1 can be used as the app frame color in professional editing applications, which require additional depth differentiation."
36
11
  },
37
12
  {
38
13
  "type": "guideline",
39
- "content": "Pasteboard.\n\nThe 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)."
14
+ "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."
40
15
  },
41
16
  {
42
17
  "type": "guideline",
43
- "content": "Elevated (highest attention).\n\nElevated backgrounds create the illusion of depth through the use of a drop shadow, and display content that appears on top of other content. They draw attention and are used sparingly. In browsing contexts, this background layer style is used in components like menus and tooltips."
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."
44
19
  },
45
20
  {
46
21
  "type": "guideline",
47
- "content": "Layer 2 is used to group related content together and to create separation from the primary content on a page, such as in the background of the app frame."
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."
48
23
  },
49
24
  {
50
25
  "type": "guideline",
51
- "content": "Base.\n\nSpectrum 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. For using a drop shadow to draw emphasis to a container that isn’t elevated, view container emphasis. Background layer Light theme Dark theme Elevatedgray-25 (with drop shadow)gray-75 (with drop shadow)Layer 2gray-25gray-75Layer 1gray-50gray-50Pasteboardgray-100gray-25"
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."
52
27
  },
53
28
  {
54
29
  "type": "guideline",
55
- "content": "Professional editing applications have the option to use background layer 1 for the app frame in order to create additional depth differentiation. To create separation for toolbars and panels that meet at the edges, include a border in size medium that matches the pasteboard color. 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. This example shows containers that are emphasized to draw attention. They don’t use the elevated background because they don’t appear on top of other content. View container emphasis for more context.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 above the canvas."
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."
56
31
  }
57
32
  ],
58
- "sourceUrl": "https://main--spectrum-hub--adobe.aem.live/foundations/color/background-layers",
59
- "lastUpdated": "2026-08-13",
33
+ "sourceUrl": "https://s2.spectrum.corp.adobe.com/page/background-layers/",
34
+ "lastUpdated": "2026-02-02",
60
35
  "status": "published",
61
- "tags": [
62
- "background layers",
63
- "elevated background",
64
- "editing contexts",
65
- "browsing contexts",
66
- "canvas",
67
- "Layer 1",
68
- "Layer 2",
69
- "Pasteboard",
70
- "artboard"
71
- ]
36
+ "tags": ["designing"],
37
+ "related": [{ "ref": "colors" }, { "ref": "typography-fundamentals" }]
72
38
  }