|
1 | 1 | export function uxPrinciplesRules() {
|
2 | 2 | return `
|
3 |
| - <ux_principles> |
4 |
| - <settings> |
5 |
| - <general_guidance> |
6 |
| - Keep it simple, clear, and non-repetitive. |
| 3 | +<ux_principles> |
| 4 | + <settings> |
| 5 | + <general_guidance> |
| 6 | + Keep it simple, clear, and non-repetitive. |
7 | 7 |
|
8 |
| - - The setting type can provide context that the setting label doesn't need to provide. Example: "Number of columns" can simply be "Columns" if the input indicates that it's a number value. |
9 |
| - - Assume all settings to be device-agnostic, with graceful scaling between breakpoints. Only mention mobile or desktop if there is a unique setting required. |
10 |
| - - Use common shorthand where it makes sense. Example: Max/Min to mean Maximum and Minimum. Caveat: ensure these values are translated/localized correctly |
11 |
| - - Help text: Minimize use as much as possible. If really required, make it short and remove punctuation unless it's more than 1 sentence (but it shouldn't be!) |
12 |
| - </general_guidance> |
| 8 | + - The setting type can provide context that the setting label doesn't need to provide. Example: "Number of columns" can simply be "Columns" if the input indicates that it's a number value. |
| 9 | + - Assume all settings to be device-agnostic, with graceful scaling between breakpoints. Only mention mobile or desktop if there is a unique setting required. |
| 10 | + - Use common shorthand where it makes sense. Example: Max/Min to mean Maximum and Minimum. Caveat: ensure these values are translated/localized correctly |
| 11 | + - Help text: Minimize use as much as possible. If really required, make it short and remove punctuation unless it's more than 1 sentence (but it shouldn't be!) |
| 12 | + </general_guidance> |
13 | 13 |
|
14 |
| - <information_architecture> |
15 |
| - <ordering> |
16 |
| - The order of theme settings greatly impacts the merchant's ability to understand and configure the section/block. |
| 14 | + <information_architecture> |
| 15 | + <ordering> |
| 16 | + The order of theme settings greatly impacts the merchant's ability to understand and configure the section/block. |
17 | 17 |
|
18 |
| - - List settings to reflect the order of elements they control in the preview. Top to bottom, left to right, background to foreground. |
19 |
| - - List resource pickers first, if they're needed, followed by customization settings. Focus on what the merchant needs to take action on in order for the section/block to function. Example: a featured collection block needs the merchant to choose a collection before deciding the number of products per row. |
20 |
| - - List settings in order of visual impact, example: Number of products per row should come before the product card settings. |
21 |
| - </ordering> |
| 18 | + - List settings to reflect the order of elements they control in the preview. Top to bottom, left to right, background to foreground. |
| 19 | + - List resource pickers first, if they're needed, followed by customization settings. Focus on what the merchant needs to take action on in order for the section/block to function. Example: a featured collection block needs the merchant to choose a collection before deciding the number of products per row. |
| 20 | + - List settings in order of visual impact, example: Number of products per row should come before the product card settings. |
| 21 | + </ordering> |
22 | 22 |
|
23 |
| - <groupings> |
24 |
| - Consider grouping settings under a heading if there are more than 1 related setting. List ungrouped settings at the top of the section/block. |
| 23 | + <groupings> |
| 24 | + Consider grouping settings under a heading if there are more than 1 related setting. List ungrouped settings at the top of the section/block. |
25 | 25 |
|
26 |
| - Common groupings: |
| 26 | + Common groupings: |
27 | 27 |
|
28 |
| - - Layout |
29 |
| - - Typography |
30 |
| - - Colors |
31 |
| - - Padding |
32 |
| - </groupings> |
| 28 | + - Layout |
| 29 | + - Typography |
| 30 | + - Colors |
| 31 | + - Padding |
| 32 | + </groupings> |
33 | 33 |
|
34 |
| - <naming> |
35 |
| - Remove word duplication in the heading and nested labels. When a word appears in a heading (e.g. "Color"), it should not be repeated in nested setting labels or help text. The hierarchy of information provides sufficient context. |
36 |
| - </naming> |
| 34 | + <naming> |
| 35 | + Remove word duplication in the heading and nested labels. When a word appears in a heading (e.g. "Color"), it should not be repeated in nested setting labels or help text. The hierarchy of information provides sufficient context. |
| 36 | + </naming> |
37 | 37 |
|
38 |
| - <conditional> |
39 |
| - Use conditional settings when it: |
| 38 | + <conditional> |
| 39 | + Use conditional settings when it: |
40 | 40 |
|
41 |
| - - simplifies decision-making for merchants via progressive disclosure |
42 |
| - - avoids duplication of settings |
43 |
| - - avoids visual clutter and reduces cognitive load |
| 41 | + - simplifies decision-making for merchants via progressive disclosure |
| 42 | + - avoids duplication of settings |
| 43 | + - avoids visual clutter and reduces cognitive load |
44 | 44 |
|
45 |
| - Conditional settings should appear in the information architecture wherever they're most relevant. That might be directly below the trigger setting, or it could be a whole separate group of settings that are surfaced elsewhere where it makes sense for the merchant. |
| 45 | + Conditional settings should appear in the information architecture wherever they're most relevant. That might be directly below the trigger setting, or it could be a whole separate group of settings that are surfaced elsewhere where it makes sense for the merchant. |
46 | 46 |
|
47 |
| - Tradeoffs and considerations of conditional settings: |
| 47 | + Tradeoffs and considerations of conditional settings: |
48 | 48 |
|
49 |
| - - They hide functionality/options that help merchants decide how style their website, so be judicious in what concepts you tie together. For example, don't make a Product card's "Swatch display" setting conditional on a "Quick buy" setting. They are both related to variant selection, but they serve different purposes. |
50 |
| - - Limit conditions to 2 levels deep to avoid complex logic (up for discussion!) |
51 |
| - - Even when not shown, a conditional setting's value is evaluated in the Liquid code. Code defensively, never assume a theme setting's value is nil. |
52 |
| - </conditional> |
| 49 | + - They hide functionality/options that help merchants decide how style their website, so be judicious in what concepts you tie together. For example, don't make a Product card's "Swatch display" setting conditional on a "Quick buy" setting. They are both related to variant selection, but they serve different purposes. |
| 50 | + - Limit conditions to 2 levels deep to avoid complex logic (up for discussion!) |
| 51 | + - Even when not shown, a conditional setting's value is evaluated in the Liquid code. Code defensively, never assume a theme setting's value is nil. |
| 52 | + </conditional> |
53 | 53 |
|
54 |
| - <input_type> |
55 |
| - **Checkbox**: Treat checkbox as an on/off switch. Avoid using verb-based labels, example: use "Language selector" and not "Enable language selector". The presence of the verb may inadvertently suggest the direction to toggle to enable or disable it. |
| 54 | + <input_type> |
| 55 | + **Checkbox**: Treat checkbox as an on/off switch. Avoid using verb-based labels, example: use "Language selector" and not "Enable language selector". The presence of the verb may inadvertently suggest the direction to toggle to enable or disable it. |
56 | 56 |
|
57 |
| - **Select**: Keep select option labels as short as possible so they can be dynamically displayed as segmented controls |
58 |
| - </input_type> |
59 |
| - </information_architecture> |
60 |
| - </settings> |
| 57 | + **Select**: Keep select option labels as short as possible so they can be dynamically displayed as segmented controls |
| 58 | + </input_type> |
| 59 | + </information_architecture> |
| 60 | + </settings> |
61 | 61 |
|
62 |
| - <server_side_rendering> |
63 |
| - Storefronts are to be rendered server-side with Liquid as a first principle. As opposed to client-side JavaScript. |
| 62 | + <server_side_rendering> |
| 63 | + Storefronts are to be rendered server-side with Liquid as a first principle. As opposed to client-side JavaScript. |
64 | 64 |
|
65 |
| - When using JavaScript to render part of the page, fetch the new HTML from the server wherever possible. |
66 |
| - <optimistic_ui> |
67 |
| - This is the exception to the rule of server-side rendering |
| 65 | + When using JavaScript to render part of the page, fetch the new HTML from the server wherever possible. |
| 66 | + <optimistic_ui> |
| 67 | + This is the exception to the rule of server-side rendering |
68 | 68 |
|
69 |
| - "Optimistic UI" is the idea that we can update part of the UI before the server response is received in the name of **perceived performance**. |
| 69 | + "Optimistic UI" is the idea that we can update part of the UI before the server response is received in the name of **perceived performance**. |
70 | 70 |
|
71 |
| - <criteria> |
72 |
| - Key factors to consider when deciding whether to use optimistic UI: |
| 71 | + <criteria> |
| 72 | + Key factors to consider when deciding whether to use optimistic UI: |
73 | 73 |
|
74 |
| - 1. You are updating a **small** portion of the UI on the client (with JavaScript) before the server response is received. |
75 |
| - 2. The API request has a high degree of certainty of being successful. |
| 74 | + 1. You are updating a **small** portion of the UI on the client (with JavaScript) before the server response is received. |
| 75 | + 2. The API request has a high degree of certainty of being successful. |
76 | 76 |
|
77 |
| - Examples of appropriate use cases: |
| 77 | + Examples of appropriate use cases: |
78 | 78 |
|
79 |
| - When filtering a collection page, we can update the a list of applied filters client-side as a Buyer chooses them, i.e. "Color: Red" or "Size: Medium". However, we do not know how many products will be returned that match the filters, so we can't update the product grid or a count of products. |
| 79 | + When filtering a collection page, we can update the a list of applied filters client-side as a Buyer chooses them, i.e. "Color: Red" or "Size: Medium". However, we do not know how many products will be returned that match the filters, so we can't update the product grid or a count of products. |
80 | 80 |
|
81 |
| - When a Buyer attempts to add an item to their cart, we can update the cart item count client-side. Assuming our product form's "add to cart" button is already checking the item's availability, we can have a reasonably high degree of certainty that the item will be added to the cart (API request is successful). However, we do not know what the new cart total will be, nor do we know what the line items will look like, so we can't update those in a cart drawer without waiting for the server response. |
82 |
| - </criteria> |
83 |
| - </optimistic_ui> |
84 |
| - </server_side_rendering> |
85 |
| - </ux_principles>`; |
| 81 | + When a Buyer attempts to add an item to their cart, we can update the cart item count client-side. Assuming our product form's "add to cart" button is already checking the item's availability, we can have a reasonably high degree of certainty that the item will be added to the cart (API request is successful). However, we do not know what the new cart total will be, nor do we know what the line items will look like, so we can't update those in a cart drawer without waiting for the server response. |
| 82 | + </criteria> |
| 83 | + </optimistic_ui> |
| 84 | + </server_side_rendering> |
| 85 | +</ux_principles>`; |
86 | 86 | }
|
0 commit comments