@adobe/spectrum-design-data 3.3.0-beta.1 → 3.3.0-beta.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/guidelines/app-frame-content-area.json +81 -0
- package/guidelines/app-frame-creating-bluelines.json +58 -0
- package/guidelines/app-frame-header.json +72 -0
- package/guidelines/app-frame-overview.json +18 -10
- package/guidelines/app-frame-side-navigation.json +138 -0
- package/guidelines/applying-the-type-system.json +14 -10
- package/guidelines/attention-hierarchy.json +3 -3
- package/guidelines/background-layers.json +41 -5
- package/guidelines/bi-directionality.json +8 -8
- package/guidelines/border-width.json +17 -1
- package/guidelines/brand.json +6 -6
- package/guidelines/colors.json +24 -12
- package/guidelines/component-spacing.json +14 -2
- package/guidelines/contact-us.json +1 -1
- package/guidelines/containers.json +62 -0
- package/guidelines/content-area-browsing-context.json +11 -11
- package/guidelines/content-design-grammar-and-mechanics.json +241 -0
- package/guidelines/content-design-voice-and-tone.json +37 -0
- package/guidelines/content-grammar-and-mechanics.json +252 -0
- package/guidelines/content-language-and-inclusivity-writing-about-people.json +103 -0
- package/guidelines/content-language-and-inclusivity-writing-with-visuals.json +70 -0
- package/guidelines/content-voice-and-tone.json +47 -0
- package/guidelines/creating-bluelines-browsing-context.json +9 -9
- package/guidelines/design-tokens.json +50 -14
- package/guidelines/drop-shadow.json +13 -1
- package/guidelines/grays.json +5 -5
- package/guidelines/header-browsing-context.json +7 -4
- package/guidelines/icon-fundamentals.json +4 -4
- package/guidelines/illustration.json +21 -25
- package/guidelines/illustrations.json +111 -0
- package/guidelines/in-product-word-list.json +1 -1
- package/guidelines/inclusive-design.json +14 -6
- package/guidelines/inclusive-ux-writing.json +1 -1
- package/guidelines/internationalization.json +13 -13
- package/guidelines/introduction.json +2 -2
- package/guidelines/language-and-inclusivity-writing-about-people.json +85 -0
- package/guidelines/language-and-inclusivity-writing-with-visuals.json +61 -0
- package/guidelines/layout-and-structure-containers.json +7 -7
- package/guidelines/layout-and-structure-spacing-overview.json +66 -0
- package/guidelines/layout-spacing.json +4 -4
- package/guidelines/manifest.json +199 -39
- package/guidelines/motion.json +5 -5
- package/guidelines/object-styles-overview.json +2 -2
- package/guidelines/object-styles.json +102 -0
- package/guidelines/principles.json +7 -8
- package/guidelines/rounding.json +15 -3
- package/guidelines/side-navigation-browsing-context.json +16 -13
- package/guidelines/spacing-overview.json +7 -7
- package/guidelines/spacing.json +25 -0
- package/guidelines/states.json +4 -4
- package/guidelines/support.json +113 -0
- package/guidelines/typography-fundamentals.json +142 -0
- package/guidelines/typography-overview.json +7 -3
- package/guidelines/typography-system.json +56 -16
- package/guidelines/using-icons.json +14 -14
- package/guidelines/visual-language-containers.json +7 -7
- package/guidelines/whats-new.json +32 -0
- package/guidelines/writing-for-errors.json +21 -21
- package/guidelines/writing-for-onboarding.json +17 -17
- package/guidelines/writing-for-readability.json +4 -4
- package/package.json +1 -1
|
@@ -0,0 +1,81 @@
|
|
|
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
|
+
{ "ref": "s2-app-frame-side-navigation-browsing-context" },
|
|
79
|
+
{ "ref": "s2-app-frame-creating-bluelines-browsing-context" }
|
|
80
|
+
]
|
|
81
|
+
}
|
|
@@ -0,0 +1,58 @@
|
|
|
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
|
+
{ "ref": "s2-app-frame-content-area-browsing-context" },
|
|
56
|
+
{ "ref": "brand" }
|
|
57
|
+
]
|
|
58
|
+
}
|
|
@@ -0,0 +1,72 @@
|
|
|
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" },
|
|
70
|
+
{ "ref": "s2-app-frame-side-navigation-browsing-context" }
|
|
71
|
+
]
|
|
72
|
+
}
|
|
@@ -28,7 +28,7 @@
|
|
|
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": "Browsing context: Zones.\n\nZones are the general areas into which certain types of actions should go. They’re not specific to components. Image: Diagram showing the three zones of the construction of the Spectrum 2 app frame: A, navigation zone, B, global action zone, and C, contextual action zone. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_19aef995718b2fb929aef522835b8af9a752400ed.png?width=750&format=png&optimize=medium)"
|
|
32
32
|
},
|
|
33
33
|
{
|
|
34
34
|
"type": "guideline",
|
|
@@ -44,7 +44,7 @@
|
|
|
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": "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. Image: Diagram showing the three parts of the anatomy of the Spectrum 2 app frame: A, header, B, side navigation, and C, content area. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_187bd949ffe1f05a278b9a306eabdb7516805dc19.png?width=750&format=png&optimize=medium)"
|
|
48
48
|
},
|
|
49
49
|
{
|
|
50
50
|
"type": "guideline",
|
|
@@ -63,6 +63,10 @@
|
|
|
63
63
|
"type": "guideline",
|
|
64
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)."
|
|
65
65
|
},
|
|
66
|
+
{
|
|
67
|
+
"type": "guideline",
|
|
68
|
+
"content": "Anatomy examples.\n\nImage: Two examples of Spectrum 2 app frame anatomy. Example one: Header only. Header contains the primary navigation and global actions. Example two: Header plus side navigation. Because the side navigation is present, the header is used for global, app-wide actions instead. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1b47658c35e18eead92d82cc540f886a57b6ee84f.png?width=750&format=png&optimize=medium)"
|
|
69
|
+
},
|
|
66
70
|
{
|
|
67
71
|
"type": "guideline",
|
|
68
72
|
"content": "Hamburger.\n\nInteracting with this icon in the header will either fully expand and collapse, or partially collapse, the panel."
|
|
@@ -83,17 +87,21 @@
|
|
|
83
87
|
"type": "guideline",
|
|
84
88
|
"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."
|
|
85
89
|
},
|
|
90
|
+
{
|
|
91
|
+
"type": "guideline",
|
|
92
|
+
"content": "Anatomy examples.\n\nImage: Examples of the product switcher in different places. One example of the Top App Bar (TAB) active at the top of the viewport with the panel icon state switcher at the end of the side navigation section. Another example is the mobile experience with the hamburger icon state switcher and the product switcher in the header. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_19bf4524cadbd94da0231a7cce0d587f0be0ac845.png?width=750&format=png&optimize=medium)"
|
|
93
|
+
},
|
|
86
94
|
{
|
|
87
95
|
"type": "guideline",
|
|
88
96
|
"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."
|
|
89
97
|
},
|
|
90
98
|
{
|
|
91
99
|
"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."
|
|
100
|
+
"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. Image: Diagrams of the hamburger side navigation state control in a web and mobile breakpoint. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1ba4d3297356f4f73b02b4fb05bed4596a9fcd706.png?width=750&format=png&optimize=medium)"
|
|
93
101
|
},
|
|
94
102
|
{
|
|
95
103
|
"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."
|
|
104
|
+
"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. Image: Illustration of where panels or rails appear in the app frame layout: to either the left or right side of the UI. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1c4e8402f034d1e4c9737e42b72fad58518c38c1f.png?width=750&format=png&optimize=medium)Image: Illustration of one example where a content area can appear in the app frame layout: as the main focus or work area. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1600fc2e5b4260da2d3f688f8b0c9d7c4604016f1.png?width=750&format=png&optimize=medium)Image: Illustration of an example of where a well can appear in the app frame layout: in the middle of a content area. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1a80cabda2a52fad2708546441c70773dd8942506.png?width=750&format=png&optimize=medium)"
|
|
97
105
|
},
|
|
98
106
|
{
|
|
99
107
|
"type": "guideline",
|
|
@@ -109,7 +117,7 @@
|
|
|
109
117
|
},
|
|
110
118
|
{
|
|
111
119
|
"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:"
|
|
120
|
+
"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: Image: A black-and-white line icon of a browser window with a top toolbar and a single dot. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_15b3b3fb77bc097c8d306652754e50f38e16cb7fb.png?width=750&format=png&optimize=medium)Image: A black-and-white line icon of a magnifying glass, representing search. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_12ac292a56a7ce97b0042216244922f5d9e32f56f.png?width=750&format=png&optimize=medium)Image: A black-and-white line icon of two overlapping user silhouettes, representing a group of people. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_150f01f672f95313815260ac49144b5023d36ae5e.png?width=750&format=png&optimize=medium)"
|
|
113
121
|
},
|
|
114
122
|
{
|
|
115
123
|
"type": "guideline",
|
|
@@ -129,26 +137,26 @@
|
|
|
129
137
|
},
|
|
130
138
|
{
|
|
131
139
|
"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."
|
|
140
|
+
"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. Image: Example of correct usage. Approvals. Colors. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_114c85b714942bddf4a0baaac51146c4e1755a454.png?width=750&format=png&optimize=medium)Describe the actions or items available.Image: Example of incorrect usage. Approvals rail. Colors panel. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_16927fb5340c20e1bd0dbaf651eb68d4c4d76032e.png?width=750&format=png&optimize=medium)Avoid describing where to find specific items or actions in relation to UI construction."
|
|
133
141
|
},
|
|
134
142
|
{
|
|
135
143
|
"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."
|
|
144
|
+
"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. Image: Example of correct usage. Show more options. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1bc5bf7de9abaf2318532d97026370f9d9be0fa1e.png?width=750&format=png&optimize=medium)Describe the action to take on the UI.Image: Example of incorrect usage. Hide navigation rail. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_17fc6b06737dfff7420c77dd28a9df09d1715610d.png?width=750&format=png&optimize=medium)Don’t describe the UI itself."
|
|
137
145
|
},
|
|
138
146
|
{
|
|
139
147
|
"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."
|
|
148
|
+
"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. Image: Example of correct usage. Show menu labels. Hide navigation. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_18c67799a786aa0e8335712032da5e43b57fdc230.png?width=750&format=png&optimize=medium)Image: Example of incorrect usage. Expand menu labels. Minimize navigation. Collapse side bar. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1ab30756ab3323c279063b24ab1950d5ecd12b932.png?width=750&format=png&optimize=medium)"
|
|
141
149
|
},
|
|
142
150
|
{
|
|
143
151
|
"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."
|
|
152
|
+
"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. Image: Example of correct usage. All templates. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1f4aca7a576edf2610ac55b033fa6c32b0ce79736.png?width=750&format=png&optimize=medium)Image: Example of incorrect usage. All Templates. ALL TEMPLATES. (source: https://preview.spectrum.adobe.com/foundations/app-frame/media_1d2fe39e9e168e4a5493e212e36a31d36e765060d.png?width=750&format=png&optimize=medium)"
|
|
145
153
|
},
|
|
146
154
|
{
|
|
147
155
|
"type": "guideline",
|
|
148
156
|
"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."
|
|
149
157
|
}
|
|
150
158
|
],
|
|
151
|
-
"sourceUrl": "https://
|
|
159
|
+
"sourceUrl": "https://preview.spectrum.adobe.com/foundations/app-frame/overview",
|
|
152
160
|
"lastUpdated": "2026-09-04",
|
|
153
161
|
"status": "published",
|
|
154
162
|
"tags": [
|
|
@@ -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,11 +8,15 @@
|
|
|
8
8
|
{ "type": "purpose", "content": "Applying the type system" },
|
|
9
9
|
{
|
|
10
10
|
"type": "guideline",
|
|
11
|
-
"content": "Card
|
|
11
|
+
"content": "Image: Card example with numbered callouts: 1) \"Card title\" labeled as the Title style, and 2) \"Card description\" labeled as the Body style, over a colorful gradient image. (source: https://preview.spectrum.adobe.com/foundations/typography/media_18dd0601a7059dd3b917ba5cc09fa50cfc5e3786e.png?width=750&format=png&optimize=medium)"
|
|
12
12
|
},
|
|
13
13
|
{
|
|
14
14
|
"type": "guideline",
|
|
15
|
-
"content": "
|
|
15
|
+
"content": "Card.\n\nIn this card example, Title and Body text styles are used together to establish a clear visual hierarchy, helping users quickly identify the primary content while keeping supporting information easy to scan. Title S The card title uses the Title style to establish the primary focus of the card. It provides strong visual emphasis, making it easy for users to quickly identify and scan content across multiple cards. Body XS The supporting description uses the Body style because it provides additional context without competing with the title. Its lighter weight and smaller size reinforce the content hierarchy while maintaining readability. The body text is presented in gray-700 to further distinguish it as secondary information and keep attention on the primary title. Image: Dark \"Featured project\" page section for \"Dreams from Oostende\" with numbered callouts labeling the eyebrow text, heading, body paragraph, byline, and button group. (source: https://preview.spectrum.adobe.com/foundations/typography/media_1e2a2ea1530d45f5b5ab50e4406d52bfc78a2b4e6.png?width=750&format=png&optimize=medium)"
|
|
16
|
+
},
|
|
17
|
+
{
|
|
18
|
+
"type": "guideline",
|
|
19
|
+
"content": "Page section.\n\nSpectrum's type scale creates a clear visual hierarchy that naturally guides the eye through the page. By assigning each type style a distinct role, Spectrum organizes information into predictable patterns that make content easier to scan and understand. Title M Heading XXL Body M Body S Component M, used in a button group Image: Unlabeled image (source: https://preview.spectrum.adobe.com/foundations/typography/media_1cd4d7ef6ccfd52ab7af605bc861bcdd334201f0a.png?width=750&format=png&optimize=medium)"
|
|
16
20
|
},
|
|
17
21
|
{
|
|
18
22
|
"type": "guideline",
|
|
@@ -20,36 +24,36 @@
|
|
|
20
24
|
},
|
|
21
25
|
{
|
|
22
26
|
"type": "guideline",
|
|
23
|
-
"content": "All-caps.\n\nAll-caps styles are not recommended for usage within UI components because it does not support accessibility requirements An all-caps style can still be used sparingly and strategically in use cases where longform content is the primary experience (like a blog post or a marketing website). All-caps text brings a heavier, punctuated feel to letterforms and adds visual impact to single words or short, standalone phrases."
|
|
27
|
+
"content": "All-caps.\n\nAll-caps styles are not recommended for usage within UI components because it does not support accessibility requirements An all-caps style can still be used sparingly and strategically in use cases where longform content is the primary experience (like a blog post or a marketing website). All-caps text brings a heavier, punctuated feel to letterforms and adds visual impact to single words or short, standalone phrases. Image: Button labeled \"EXPORT VIDEO\" in all-caps text, shown as a don't example. (source: https://preview.spectrum.adobe.com/foundations/typography/media_111cb65fe657204f59fbf7ba2758d84ed1330d7c2.png?width=750&format=png&optimize=medium)"
|
|
24
28
|
},
|
|
25
29
|
{
|
|
26
30
|
"type": "guideline",
|
|
27
|
-
"content": "Use Spectrum font sizes.\n\nChoose from Spectrum's defined font sizes. By using unique font sizes, you risk upsetting the hierarchy and balance of typography in your product."
|
|
31
|
+
"content": "Use Spectrum font sizes.\n\nChoose from Spectrum's defined font sizes. By using unique font sizes, you risk upsetting the hierarchy and balance of typography in your product. Image: Text reading \"Spectrum delivers what's needed, when it's needed.\" labeled with a custom value of 17 px instead of a Spectrum font size token, shown as a don't example. (source: https://preview.spectrum.adobe.com/foundations/typography/media_1280ff1daf36ac669b43bcc3e021b8a6774c4cbb6.png?width=750&format=png&optimize=medium)Image: Text reading \"Spectrum delivers what's needed, when it's needed.\" labeled with the token font-size-200, shown as a do example. (source: https://preview.spectrum.adobe.com/foundations/typography/media_17c4dbbf625e3b2e743e6a75e591d7f5991b5cfbc.png?width=750&format=png&optimize=medium)"
|
|
28
32
|
},
|
|
29
33
|
{
|
|
30
34
|
"type": "guideline",
|
|
31
|
-
"content": "Respect capitalization rules.\n\nUse sentence case for all UX content. For more on capitalization guidelines, go to Grammar and mechanics."
|
|
35
|
+
"content": "Respect capitalization rules.\n\nUse sentence case for all UX content. For more on capitalization guidelines, go to Grammar and mechanics. Image: Form with a \"Create audience\" button, an \"Email address\" field, and a \"Contact preference\" dropdown listing \"Phone call,\" \"Email address,\" and \"Text message\" in sentence case, shown as a do example. (source: https://preview.spectrum.adobe.com/foundations/typography/media_1e8d9950994f825a7339aaac2677a0f16286e1762.png?width=750&format=png&optimize=medium)"
|
|
32
36
|
},
|
|
33
37
|
{
|
|
34
38
|
"type": "guideline",
|
|
35
|
-
"content": "Use tabular numbers for numerical data.\n\nNumbers within components should be tabular with lining figures. In tables, numbers should be right aligned to make numerical data easier to read and compare. This is used, for example, in tables, time stamps, and bar loaders. This is supported by Adobe Clean (via the Monospace uppercase option in Figma, the OpenType panel in Illustrator, or the CSS font feature settings). For iOS and Android, use the Spectrum Monospace numbers type styles."
|
|
39
|
+
"content": "Use tabular numbers for numerical data.\n\nNumbers within components should be tabular with lining figures. In tables, numbers should be right aligned to make numerical data easier to read and compare. This is used, for example, in tables, time stamps, and bar loaders. This is supported by Adobe Clean (via the Monospace uppercase option in Figma, the OpenType panel in Illustrator, or the CSS font feature settings). For iOS and Android, use the Spectrum Monospace numbers type styles. Image: Table with a \"Count\" column showing right-aligned tabular numbers 2, 5, 10, 12, and 25, with a bolded total of 324, shown as a do example. (source: https://preview.spectrum.adobe.com/foundations/typography/media_17aab398526c4b42c420abce55611379ee1eba044.png?width=750&format=png&optimize=medium)"
|
|
36
40
|
},
|
|
37
41
|
{
|
|
38
42
|
"type": "do-dont",
|
|
39
43
|
"content": "Don't let paragraph widths get too thin",
|
|
40
|
-
"dont": "Paragraphs of text that are too long are difficult to follow, and paragraphs of text that are too thin are difficult to read. Ideally, blocks of text should be roughly 70 characters wide. Be sure to keep them at least between 50 and 120 characters wide."
|
|
44
|
+
"dont": "Paragraphs of text that are too long are difficult to follow, and paragraphs of text that are too thin are difficult to read. Ideally, blocks of text should be roughly 70 characters wide. Be sure to keep them at least between 50 and 120 characters wide. Image: Narrow column of the \"Collaborative\" paragraph broken into many short lines, illustrating a paragraph width that is too thin, shown as a don't example. (source: https://preview.spectrum.adobe.com/foundations/typography/media_13bb8774bddfb85d336faadbf8f1f4936f9020f4e.png?width=750&format=png&optimize=medium)"
|
|
41
45
|
},
|
|
42
46
|
{
|
|
43
47
|
"type": "guideline",
|
|
44
|
-
"content": "Keep content short and to the point.\n\nKeep paragraphs concise. Some users with cognitive disabilities (and even those who don't) can have a very difficult time reading and comprehending large blocks of text."
|
|
48
|
+
"content": "Keep content short and to the point.\n\nKeep paragraphs concise. Some users with cognitive disabilities (and even those who don't) can have a very difficult time reading and comprehending large blocks of text. Image: Moderate-width column of the \"Collaborative\" paragraph with comfortably readable line lengths, shown as a do example. (source: https://preview.spectrum.adobe.com/foundations/typography/media_15433cd18805249164930961eb963e4bec4bacba9.png?width=750&format=png&optimize=medium)"
|
|
45
49
|
},
|
|
46
50
|
{
|
|
47
51
|
"type": "do-dont",
|
|
48
52
|
"content": "Don't fully-justify text",
|
|
49
|
-
"dont": "Do not use fully-justified blocks of text. This adds trapped white space within paragraphs, which makes it harder to read, especially for those with cognitive disabilities or dyslexia. Right alignment (left rag) is also discouraged for paragraphs of text."
|
|
53
|
+
"dont": "Do not use fully-justified blocks of text. This adds trapped white space within paragraphs, which makes it harder to read, especially for those with cognitive disabilities or dyslexia. Right alignment (left rag) is also discouraged for paragraphs of text. Image: The \"Collaborative\" paragraph shown fully justified with uneven word spacing on a pink background, shown as a don't example. (source: https://preview.spectrum.adobe.com/foundations/typography/media_1da6c7af0217c78e26865de32b20a08b32471b743.png?width=750&format=png&optimize=medium)"
|
|
50
54
|
}
|
|
51
55
|
],
|
|
52
|
-
"sourceUrl": "https://
|
|
56
|
+
"sourceUrl": "https://preview.spectrum.adobe.com/foundations/typography/applying-the-type-system",
|
|
53
57
|
"lastUpdated": "2026-08-13",
|
|
54
58
|
"status": "published",
|
|
55
59
|
"tags": [
|
|
@@ -12,14 +12,14 @@
|
|
|
12
12
|
},
|
|
13
13
|
{
|
|
14
14
|
"type": "guideline",
|
|
15
|
-
"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."
|
|
15
|
+
"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. Image: Three labeled pill buttons on a low-to-high attention scale: a light gray button on the left (low attention), a dark gray/black button in the middle, and a solid blue button on the right (high attention). (source: https://preview.spectrum.adobe.com/foundations/media_14ae3b9cab583541ca3057219e82b963cb577f719.png?width=750&format=png&optimize=medium)Image: Four empty rounded rectangle cards arranged on a low-to-high attention scale, showing progressively deeper drop shadows from left to right to indicate increasing visual elevation and attention. (source: https://preview.spectrum.adobe.com/foundations/media_145c026b410020965c87b15781c669231233cd7fa.png?width=750&format=png&optimize=medium)"
|
|
16
16
|
},
|
|
17
17
|
{
|
|
18
18
|
"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."
|
|
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. Image: A vertical sidebar with a blue circular add button at top, followed by icons for recent, cloud, and people, with a tooltip labeled 'Recent' pointing to the clock icon, and a panel toggle icon at the bottom. (source: https://preview.spectrum.adobe.com/foundations/media_1a93a0b0e1b7fb0945b404bf29ffcc9bd5cc43d71.png?width=750&format=png&optimize=medium)Image: A vertical sidebar with a blue circular add button, a highlighted blue 'Recent' clock icon with a matching blue tooltip label, plus cloud and people icons, and a panel toggle icon at the bottom — showing overuse of blue accent color across multiple elements. (source: https://preview.spectrum.adobe.com/foundations/media_19fb239ceeb047bb8e509bb2f502737325765d41e.png?width=750&format=png&optimize=medium)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."
|
|
20
20
|
}
|
|
21
21
|
],
|
|
22
|
-
"sourceUrl": "https://
|
|
22
|
+
"sourceUrl": "https://preview.spectrum.adobe.com/foundations/attention-hierarchy",
|
|
23
23
|
"lastUpdated": "2026-08-24",
|
|
24
24
|
"status": "published",
|
|
25
25
|
"tags": [
|