diff --git a/docs/docs/components/alertbar.md b/docs/docs/components/alertbar.md index 7de423c09..6fd07fc84 100644 --- a/docs/docs/components/alertbar.md +++ b/docs/docs/components/alertbar.md @@ -154,7 +154,7 @@ Read more about the `useAlert()` hook at the [App Runtime documentation](https:/ - Alert bar labels should be clear, concise, and easy to understand. Remember, `info` and `success` alert bars dismiss automatically. - Don't use unclear labels like _Success_, _Failed_, or vague descriptions like _There was a problem_. Be clear and precise. -- Check the [A-Z glossary](/design/patterns/glossary) and [communication guidelines](/design/principles/content-communication) for more tips for writing useful labels. +- Check the [A-Z glossary](/design-system/patterns/glossary) and [communication guidelines](/design-system/principles/content-communication) for more tips for writing useful labels. #### Display diff --git a/docs/docs/components/inputfield.md b/docs/docs/components/inputfield.md index b2ff2dfd9..7204814f4 100644 --- a/docs/docs/components/inputfield.md +++ b/docs/docs/components/inputfield.md @@ -137,7 +137,7 @@ Inputs width should reflect the expected content. ### Validation - Validating the type of data entered isn't part of the components themselves. -- Read more about [form handling in DHIS2](/design/utilities/forms/react-final-form). +- Read more about [form handling in DHIS2](/design-system/utilities/forms/react-final-form). ### Read-only @@ -174,7 +174,7 @@ Inputs width should reflect the expected content. - Use an error state if there's a problem with the content of the input, or if it's required but empty. - Don't show an error too early, give the user a chance to finish entering data. -- The error text should help the user fix the problem. Refer to the [error writing guidelines](/design/principles/content-communication) for examples. +- The error text should help the user fix the problem. Refer to the [error writing guidelines](/design-system/principles/content-communication) for examples. ### State: Disabled diff --git a/docs/docs/components/menu.md b/docs/docs/components/menu.md index 223fb4530..1d26e1958 100644 --- a/docs/docs/components/menu.md +++ b/docs/docs/components/menu.md @@ -32,7 +32,7 @@ A menu gives access to menu items, through a panel that opens from a trigger ele - Menu item labels should be short and easy to understand. - One or two words is often enough to explain the action. -- Refer to the [writing guidelines](/design/patterns/writing) and [glossary](/design/patterns/glossary) for more information about writing useful labels. +- Refer to the [writing guidelines](/design-system/patterns/writing) and [glossary](/design-system/patterns/glossary) for more information about writing useful labels. ##### Order and grouping diff --git a/docs/docs/components/notice-box.md b/docs/docs/components/notice-box.md index da02101ad..cda77868b 100644 --- a/docs/docs/components/notice-box.md +++ b/docs/docs/components/notice-box.md @@ -111,7 +111,7 @@ A notice box shows important information about a situation. - Notice box titles should be a short summary to help the user scan elements the page. - Notice box text should be clear and informative. Explain what the situation is and, if relevant, offer a solution. -- Check the [writing guidelines](/design/patterns/writing) for more information. +- Check the [writing guidelines](/design-system/patterns/writing) for more information. ## Options diff --git a/docs/docs/components/popover.md b/docs/docs/components/popover.md index 6e2761fcc..3c32e0ba4 100644 --- a/docs/docs/components/popover.md +++ b/docs/docs/components/popover.md @@ -29,7 +29,7 @@ A popover is used to show more information when a user interacts with a trigger ### Format - A popover doesn't offer any default content styling. -- Include padding between the popover frame and the content inside. The amount of padding depends on the content and density of the interface. Use a [spacer constant](/design/utilities/constants) for a consistent visual experience. +- Include padding between the popover frame and the content inside. The amount of padding depends on the content and density of the interface. Use a [spacer constant](/design-system/utilities/constants) for a consistent visual experience. ## API Reference diff --git a/docs/docs/components/select.md b/docs/docs/components/select.md index 261c870f0..6b976a5a4 100644 --- a/docs/docs/components/select.md +++ b/docs/docs/components/select.md @@ -221,7 +221,7 @@ Selects are used to choose one or more items from a list of options. - Use an error state if there's a problem with the chosen option, or if it's required but empty. - Don't show an error too early, give the user a chance to make a choice. -- The error text should help the user fix the problem. Refer to the [error writing guidelines](/design/principles/content-communication) for examples. +- The error text should help the user fix the problem. Refer to the [error writing guidelines](/design-system/principles/content-communication) for examples. ### State: Disabled diff --git a/docs/docs/components/transfer.md b/docs/docs/components/transfer.md index bec7b406f..bf09800a1 100644 --- a/docs/docs/components/transfer.md +++ b/docs/docs/components/transfer.md @@ -150,7 +150,7 @@ The footer component is as follows: - Different types of data will need different loading strategies. - Use a [`Loader`](loading.md) to block interaction if using the transfer while loading is taking place can cause problems. -- A common pattern is loading more options as a user scrolls. See the [Transfer: Infinite Loading recipe](/design/recipes/transfer-infinite-loading-all-options-selected) for more information. +- A common pattern is loading more options as a user scrolls. See the [Transfer: Infinite Loading recipe](/design-system/recipes/transfer-infinite-loading-all-options-selected) for more information. ## API Reference diff --git a/docs/docs/principles/forms.md b/docs/docs/principles/forms.md index f8f21f657..ddee20e52 100644 --- a/docs/docs/principles/forms.md +++ b/docs/docs/principles/forms.md @@ -56,7 +56,7 @@ Forms are made up of different types of inputs. There are various inputs availab ## Form actions -A form should always have a single, clear primary action. Often this action is 'Submit' or 'Save data'. Make sure the user understands what will happen when they submit a form. Additional options, like 'Save and add another', can be offered, but only a single primary action should be included. Make sure the action button label accurately describes the action. See the [content and communication section](/design/principles/content-communication) for more information of writing effective button labels. +A form should always have a single, clear primary action. Often this action is 'Submit' or 'Save data'. Make sure the user understands what will happen when they submit a form. Additional options, like 'Save and add another', can be offered, but only a single primary action should be included. Make sure the action button label accurately describes the action. See the [content and communication section](/design-system/principles/content-communication) for more information of writing effective button labels. ![example of clear form actions](/images/forms/actions.png)