# Getting Started \*Welcome to the Nord Design System. If you're just getting started with designing or developing something for our therapyveterinary products, you're in the right place. \[For veterinary, please switch brand]\(/start/?theme=vet)\[For therapy, please switch brand]\(/start/?theme=nord).\* Nord Design System is a collection of reusable components and tools, guided by clear standards, that can be assembled together to build digital products and experiences for [Nordhealth](https://nordhealth.com){rel=""nofollow""}. The goal of Nord Design System is to improve UI consistency and quality, while making our software design and development processes more efficient. The system also helps to establish a common vocabulary between everyone in our organization and ease collaboration between different teams and disciplines. \> \[!NOTE] \> Nord Design System ships with two distinctive brands, \[therapy]\(/?theme=nord) and \[veterinary]\(/?theme=vet). You can switch the currently active brand from the top left corner of this documentation website. --- ## Design guidelines Check out these practical guides to help you understand how to design for Nordhealth's platforms using Nord Design System. \*\*\[Nord Design Principles]\(/principles/)\*\* - nordhealth.design/principles/ \*\*\[Figma Toolkit]\(/figma/)\*\* - nordhealth.design/figma/ \*\*\[Color guidelines]\(/colors/)\*\* - nordhealth.design/colors/ \*\*\[Iconography guidelines]\(/iconography/)\*\* - nordhealth.design/iconography/ \*\*\[Grid guidelines]\(/grid/)\*\* - nordhealth.design/grid/ \*\*\[Typography guidelines]\(/typography/)\*\* - nordhealth.design/typography/ \*\*\[Theming guidelines]\(/themes/)\*\* - nordhealth.design/themes/ \*\*\[Design Tokens]\(/tokens/)\*\* - nordhealth.design/tokens/ \*\*\[Components]\(/components/)\*\* - nordhealth.design/components/ \*\*\[Templates]\(/templates/)\*\* - nordhealth.design/templates/ \*\*\[Nordicons]\(/nordicons/)\*\* - nordhealth.design/nordicons/ \*\*\[Downloads]\(/downloads/)\*\* - nordhealth.design/downloads/ ::div --- :: ## Development packages Nord is a collection of reusable components and tools that are divided into nine packages. They can be used together or separately depending on your team's needs. \*\*\[Web Components]\(/web-components/)\*\* - nordhealth.design/web-components/ \*\*\[React Wrappers (deprecated)]\(/web-components/#react)\*\* - nordhealth.design/web-components/#react \*\*\[Vue Types (deprecated)]\(/web-components/#types-and-editor-integration-with-vue)\*\* - nordhealth.design/web-components/#types-and-editor-integration-with-vue \*\*\[CSS Framework]\(/css/)\*\* - nordhealth.design/css/ \*\*\[Themes]\(/themes/)\*\* - nordhealth.design/themes/ \*\*\[Nordicons]\(/nordicons/)\*\* - nordhealth.design/nordicons/ \*\*\[Design Tokens]\(/tokens/)\*\* - nordhealth.design/tokens/ \*\*\[Webfonts]\(/webfonts/)\*\* - nordhealth.design/webfonts/ \*\*\[Color Utilities]\(/color-utilities/)\*\* - nordhealth.design/color-utilities/ \*\*\[AG Grid Theme]\(/components/table/#recommendation-for-component-based-libraries)\*\* - /components/table/ Each package can be installed using [Node Package Manager](https://www.npmjs.com/org/nordhealth){rel=""nofollow""}. To do so, run the following command(s) in your terminal: ```bash # Design Tokens, CSS Framework, Themes, Nordicons, Webfonts: # (For usage with any framework) npm install @nordhealth/tokens npm install @nordhealth/css npm install @nordhealth/themes npm install @nordhealth/icons npm install @nordhealth/fonts npm install @nordhealth/color npm install @nordhealth/ag-theme-nord ``` ```bash # Web Components for HTML, Vue.js and Vanilla JS: npm install @nordhealth/components ``` ```bash # React Wrappers (deprected): npm install @nordhealth/react ``` ```bash # Vue Types (deprected): npm install @nordhealth/vue ``` \> \[!WARNING] \> For further installation and integration guidelines for each Nord Design System package, please see documentation \[linked above]\(#frontend-packages). ::div --- :: ## What's new This section is updated regularly with new content to help you stay up to date with the latest [releases](https://nordhealth.design/changelogs/web-components) and [updates](https://nordhealth.design/updates/) from the Nord team. We also have [an RSS feed](https://nordhealth.design/feed.xml) you can subscribe to. \*\*\[Changelog]\(/changelogs/web-components)\*\* - nordhealth.design/changelogs/web-components \*\*\[Latest Updates]\(/updates/)\*\* - nordhealth.design/updates/ \*\*\[Migration Guides]\(/migrations/)\*\* - nordhealth.design/migrations/ ::div --- :: ## Browser support Nord Design System is tested in the latest two versions of the following browsers. Our team addresses critical [bug fixes](https://nordhealth.design/help/) in earlier versions based on their severity and impact. If you need to support IE11 or pre-Chromium Edge, this library isn't for you. \*\*Supported browsers:\*\* Chrome, Safari, Edge, Firefox, Opera ::div --- :: ## Can I use Nord in my own project? Nord Design System is solely meant for building digital products and experiences for [Nordhealth](https://nordhealth.com){rel=""nofollow""}. Please see the [terms of use](https://nordhealth.design/terms/) for full license details. ::div --- :: ## Getting support If you experience any issues while getting started with any of Nord's tools, please head over to the [Support page](https://nordhealth.design/help/) for more guidelines and help. # About Nord \*Nord Design System is a collection of reusable components and tools, guided by clear standards, that can be assembled together to build digital products and experiences.\* The goal of Nord Design System is to improve UI consistency and quality, while making our software design and development processes more efficient. Nord also helps to establish a common vocabulary between everyone in our organization and ease collabo­ration between different teams and disciplines. Nord Design System has a core team of designers and developers inside Nordhealth who are dedicated to building and supporting the system. The core team includes [Elwin van Eede](https://elwinvaneede.com){rel=""nofollow""}. Our documentation is public as it makes sharing and collaboration between different teams and third party vendors much easier as it increases the system’s visibility and accountability. This also makes us push towards higher quality and enables us to be more transparent. Finally, it also serves as an amazing tool that we can leverage in recruiting. You can reach out to the team by heading over to [our support page](https://nordhealth.design/help/). ![Nord Design System architecture overview](https://nordhealth.design/img/updates/architecture/1.jpg){.n:border.n:rounded} Nord Design System package architecture, [read more from our blog](https://nordhealth.design/updates/february-2022-design-system-architecture/). --- ## Relevant reading - **[Launching Nord Design System article](https://arielsalminen.com/2022/launching-nord-design-system/){rel=""nofollow""}** - **[How Nord team uses Custom Properties in Web Components](https://web.dev/custom-properties-web-components/){rel=""nofollow""}** - **[Nord Statistics for the first year](https://nordhealth.design/updates/march-2022-statistics-for-the-first-year/)** - **[How Nord team uses Figma](https://nordhealth.design/updates/january-2022/)** - **[Nord Design System documentation](https://nordhealth.design){rel=""nofollow""}** --- ## How we started Looking back in time, we started our design system journey at the end of 2020 with initial user research. We did this because we wanted to first better understand the challenges we're trying to solve at [Nordhealth](https://nordhealth.com){rel=""nofollow""} and how the design system might help. Back then, we interviewed around 60 different persons from different teams, with different backgrounds, and with different levels of experience. The result of this research was an organizational challenges heatmap that highlighted organization level problems. Once we had this data, we continued the research with a [series of workshops](https://arielsalminen.com/2018/vue-design-system/#figuring-out-challenges){rel=""nofollow""}. These workshops were meant to reveal a lack of alignment and personal biases across teams. The final output from these workshops was a set of prioritized actions that directly informed the backlog of the design system. Once we knew what the challenges were, it was a matter of creating fundamental [principles](https://nordhealth.design/principles/) and [goals for the system](https://nordhealth.design/about/#our-goals) that we should follow to start solving these issues. We came up with these four goals for Nord: ![Nord goals](https://nordhealth.design/img/updates/goals.jpg){.n:border.n:rounded loading="lazy"} At the same time, we also created design principles for the design systems work that would form the foundations for Nord and guide our team when working on the different parts of the system and help us do better and more informed decisions. These are the six design principles we created for Nord: ### 1. Put user needs first We care for the people who use our products. We're here to make their day-to-day and long-term work better and more pleasant through great user experience. ### 2. Strive for consistency, not uniformity We should use the same language and design patterns wherever possible. This helps people get familiar with our services. Same holds true for the system and its developer experience. ### 3. Default to openness We should share what we're doing whenever we can. Building our services transparently increases their visibility and accountability and makes us push towards higher quality. ### 4. Make it accessible Our services are for everyone. We make sure people with different needs can use our products and that they meet the accessibility standards outlined in WCAG 2.1. ### 5. Provide a good developer experience Providing a good developer experience is very important to us. Developers should be able to start using our tools in minutes, not hours, days or weeks. ### 6. Automate everything you can We value the time of our colleagues, users, and our future selves over our own. We are always proactively looking for ways to automate repetitive tasks and testing. ![Nord has tech-agnostic components](https://nordhealth.design/img/updates/agnostic.jpg){.n:border.n:rounded loading="lazy"} --- ## Technical architecture Whenever we talk about Nord Design System, one of the first things that we like to mention is that Nord is **tech agnostic, not tech specific.** Meaning that you can take any component from Nord and use it with any framework. That could be Angular, React, Preact, Vue.js, plain HTML, your old PHP application, or any future framework. We achieve this by building on top of existing web standards ([Web Components](https://developer.mozilla.org/en-US/docs/Web/Web_Components){rel=""nofollow""} to be exact), instead of choosing a specific framework to go with. This is really important for us for a few reasons; ### Tech-Agnostic Instead Of Tech-Specific In order to create modular interfaces, a design system needs to be technology-agnostic instead of technology-specific. Web Components offer this benefit and make it easier to reduce our design system's complexity and improve its reusability. ### Future Proofing With Web Standards [Web Standards](https://en.wikipedia.org/wiki/Web_standards){rel=""nofollow""} are more future proof than any given JavaScript framework. I've seen different frameworks come and go during my almost two decade long career on the web, but Web Standards keep thriving and evolving. ### Any Framework Or No Framework Web Components can be used with [any JavaScript framework](https://custom-elements-everywhere.com/){rel=""nofollow""} or no framework at all. This means we're able to support all our product teams from a single codebase. This makes it possible for our small design system team to be very efficient. ### Full Encapsulation [Shadow DOM](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM){rel=""nofollow""} allows components to have their own DOM tree that can't be accidentally accessed from the main document. For us this means that "everything just works" when the components are implemented onto different environments and platforms. Most styles cannot penetrate a component from the outside, and styles inside a component won't bleed out. ![Nord has tech-agnostic styles as well](https://nordhealth.design/img/updates/agnostic-2.jpg){.n:border.n:rounded loading="lazy"} Nord's tech-agnostic thinking isn't limited to only components either, all our styles are agnostic as well. We use [design tokens](https://nordhealth.design/tokens/) instead of hard coded values to ensure a better UI consistency across different platforms. Be that a web application, a native application, a mobile application, a VR solution, or something new that doesn't even exist today. The way [Nord](https://nordhealth.design) itself is structured, looks somewhat like shown in the picture below. The most important thing about the architecture is that we aren't really talking about one gigantic design system, but multiple small modular systems that can be used either standalone or together depending on specific team's needs. On the first level, we have packages called [Webfonts](https://nordhealth.design/webfonts/), [Design Tokens](https://nordhealth.design/tokens/), and [Nordicons](https://nordhealth.design/nordicons/). These packages are like atoms of the systems as they don't have external or internal dependencies into any other packages in the system. On the second level, we have [CSS Framework](https://nordhealth.design/css/), [Web Components](https://nordhealth.design/components/), and [Themes](https://nordhealth.design/themes/). These packages internally depend on the first level packages, but we wanted to hide these dependencies for the end user, Frontend Developer in this case, meaning that you'd more or less always install one or more of the second level packages only into your app to consume parts of the system. ![Nord Design System architecture overview](https://nordhealth.design/img/updates/architecture/1.jpg){.n:border.n:rounded loading="lazy"} As an example, if you would like to use our **CSS Framework,** you would only install that specific NPM package and that's really it. You don't have to care, as a user, that internally this package also uses our **Webfonts** and **Design Token** packages: ![Dependencies for utilizing CSS Framework](https://nordhealth.design/img/updates/architecture/2.jpg){.n:border.n:rounded loading="lazy"} Another example could be that if you'd want to skin your application with one of our themes, you'd also add the **Themes** package and choose a theme to use from it. Again, internally, we still use both **Webfonts** and **Design Token** packages, but as a user, you don't have to care about those: ![Dependencies for utilizing Nord Themes](https://nordhealth.design/img/updates/architecture/3.jpg){.n:border.n:rounded loading="lazy"} Finally, in the below example, we show all three first level packages being used internally (Webfonts, Design Tokens and Nordicons), but for the end user, only **CSS Framework** and **Web Components** will be relevant in this case: ![Dependencies for utilizing Web Components](https://nordhealth.design/img/updates/architecture/4.jpg){.n:border.n:rounded loading="lazy"} You could also directly utilize one of the first level packages, like the **Design Tokens** if you're working on a native iOS application and want to pull in the base colors and similar styles in XML format: ![Dependencies for utilizing Design Tokens on iOS](https://nordhealth.design/img/updates/architecture/5.jpg){.n:border.n:rounded loading="lazy"} While the above is still possible, we wanted to avoid the user having to install a lot of different dependencies to be able to use a utility class from the CSS Framework, or a component from the Web Components package. So while we strive towards having modularity to reduce the complexity and improve our system's reusability by breaking it into small, easier to consume parts, we also want to make sure this modularity doesn't become too burdensome for our users. **To learn more about the Nord Design System, how it works, and our release in 2022, please also read [Launching Nord Design System](https://arielsalminen.com/2022/launching-nord-design-system/){rel=""nofollow""} article.** --- ## Important information - **Name of the project:** Nord Design System - **Companies involved in design:** [Nordhealth](https://nordhealth.com){rel=""nofollow""}, [Ariel S. Design](https://arielsalminen.com){rel=""nofollow""}, [Iijii (icons)](https://ilkkaj.com){rel=""nofollow""} - **Companies involved in implementation:** [Nordhealth](https://nordhealth.com){rel=""nofollow""}, [Ariel S. Design](https://arielsalminen.com){rel=""nofollow""} - **Client:** Nordhealth - **Category:** Best design system - **Link to the project:** {rel=""nofollow""} --- ## Further material - **[Launching Nord Design System article](https://arielsalminen.com/2022/launching-nord-design-system/){rel=""nofollow""}** - **[How Nord team uses Custom Properties in Web Components](https://web.dev/custom-properties-web-components/){rel=""nofollow""}** - **[Nord Statistics for the first year](https://nordhealth.design/updates/march-2022-statistics-for-the-first-year/)** - **[How Nord team uses Figma](https://nordhealth.design/updates/january-2022/)** - **[Nord Design System documentation](https://nordhealth.design){rel=""nofollow""}** --- ## How we work The following set of fundamental rules allows us to get to the highest level of productivity while benefiting both the company and our team members. - We avoid meetings as much as possible. Instead of having them, we communicate asynchronous to each other via Linear, GitHub, Notion, Figma, and (occasionally) Slack, expecting responses within 24 hours. - We don’t do team wide standups or sync meetings, except one meeting at the start of every cycle. Here we walk through the tasks and also discuss about how the team feels, what motivates them right now, and what would they want to change. - Most collaboration and discussion happens in feedback loops, using the above mentioned tools, which requires clear and thoughtful communication from everyone. - We don’t have strict deadlines. We ship incrementally as we move through the backlog and launch new things as they become ready. - Our team members should be able to work on what they think is fun, or rely on their intuition when picking tasks from the backlog. Our [roadmap on Linear](https://linear.app/nordhealth/team/NDS/all){rel=""nofollow""} holds us accountable. - We focus on persistent iteration over flashy launches. --- ## Our goals ![Nord goals](https://nordhealth.design/img/updates/goals.jpg){.n:border.n:rounded loading="lazy"} ### Efficiency Improved work efficiency for designers and developers. ### Consistency Improved user interface consistency and quality. ### Openness Improved communication between teams and people. ### Standards Shared guidelines and standards through documentation. # What's New \*This section is updated regularly with new content to help you stay up to date with the latest \[releases]\(/changelogs/web-components) and \[updates]\(/updates/) from the Nord team.\* \*\*\[Changelog]\(/changelogs/web-components)\*\* - nordhealth.design/changelogs/web-components \*\*\[Latest Updates]\(/updates)\*\* - nordhealth.design/updates/ \*\*\[Migration Guides]\(/migrations)\*\* - nordhealth.design/migrations/ # Web Components \- \[nord-avatar]\(/raw/components/avatar.md): Avatar is used for showing a thumbnail representation of a single user or entity. Default avatar illustration is displayed when no src is specified. \- \[nord-badge]\(/raw/components/badge.md): Badges are used to inform users of the status of an object or of an action that’s been taken. Commonly used in tabular data to indicate status. \- \[nord-banner]\(/raw/components/banner.md): Banner informs users about important changes or conditions in the interface. Use this component if you need to communicate to users in a prominent way. \- \[nord-button]\(/raw/components/button.md): Buttons are used for interface actions. Primary style should be used only once per section for main call-to-action, while other styles can appear more frequently. \- \[nord-button-group]\(/raw/components/button-group.md): Button groups are designed to bring together button controls that are of a similar nature. For example text formatting controls. \- \[nord-calendar]\(/raw/components/calendar.md): Calendar allows user to pick a date. It comes with built-in functionality that allows you to set a minimum and a maximum allowed date. Please note that the date must be passed in ISO-8601 format. \- \[nord-card]\(/raw/components/card.md): Cards are shadowed surfaces that display content and actions on a single topic. They should be easy to scan for relevant and actionable information. \- \[nord-checkbox]\(/raw/components/checkbox.md): Checkboxes allow user to choose one or more options from a limited set of options. If you have more than 10 options, please use Select component instead. \- \[nord-command-menu]\(/raw/components/command-menu.md): Command Menu allows users to navigate and use an app without touching the mouse and helps them transform into “power users” who can harness more advanced features far faster. \- \[nord-date-picker]\(/raw/components/date-picker.md): Date Picker allows user to enter a date either through text input, or by choosing a date from the calendar. Please note that the date must be passed in ISO-8601 format: YYYY-MM-DD. \- \[nord-divider]\(/raw/components/divider.md): Divider components are used to separate and distinguish sections of content or groups of menu items. Visually, they look like horizontal or vertical lines. \- \[nord-drawer]\(/raw/components/drawer.md): Drawer is used to display context-sensitive actions and information. Drawer doesn’t block users from completing their task, like a modal would. \- \[nord-dropdown]\(/raw/components/dropdown.md): Dropdown menu displays a list of actions or selectable options for a user. Dropdown uses popout component internally to create the overlay functionality. \- \[nord-dropdown-group]\(/raw/components/dropdown-group.md): Dropdown group includes all the actions or items in a single dropdown group and is used for grouping items into related categories. \- \[nord-dropdown-item]\(/raw/components/dropdown-item.md): Dropdown item populates dropdown with actions. Items can be placed either inside a dropdown group or directly inside a dropdown component. \- \[nord-dropdown-submenu]\(/raw/components/dropdown-submenu.md): Dropdown submenu nests a secondary menu within a parent dropdown. The trigger slot contains the item that opens the submenu, and the default slot contains the submenu items. Supports both hover (non-touch) and click (touch-devices/accessibility) interactions. On small screens, uses mobile stack navigation: tapping a submenu trigger replaces the dropdown's visible content with the submenu's items and shows a back button. \- \[nord-empty-state]\(/raw/components/empty-state.md): Empty state can be used when there is no data to display to describe what the user can do next. Empty state provides explanation and guidance to help user progress. \- \[nord-fieldset]\(/raw/components/fieldset.md): Fieldset is used for grouping sets of input components. It is necessary to use a fieldset with radio and checkbox components. It can also be useful for logically grouping other types of inputs. \- \[nord-footer]\(/raw/components/footer.md): The footer is a block of designated space for providing additional information or actions that are positioned below the main content. \- \[nord-header]\(/raw/components/header.md): The header is a block of designated space for labelling the currently viewed context as well as providing primary actions. \- \[nord-icon]\(/raw/components/icon.md): Icons are used to provide additional meaning or in places where text label doesn’t fit. Icon component allows you to display an icon from the Nordicons library. \- \[nord-input]\(/raw/components/input.md): Inputs are used to allow users to provide text input when the expected input is short. As well as plain text, Input supports various types of text, including passwords and numbers. \- \[nord-layout]\(/raw/components/layout.md): Layout component is used to create the main layout of an app. Layout currently comes with one main configuration: two-column. \- \[nord-message]\(/raw/components/message.md): Message represents a specific item within a collection, such as notifications, tasks or conversations. Message can be placed directly inside a dropdown component. \- \[nord-modal]\(/raw/components/modal.md): Modal component is used to display content that temporarily blocks interactions with the main view of an application. Modal should be used sparingly and only when necessary. \- \[nord-nav-group]\(/raw/components/nav-group.md): Navigation group includes all the actions or items in a single group and is used for grouping items into related categories. \- \[nord-navigation]\(/raw/components/navigation.md): Navigation is used to display the primary navigation in the sidebar of an application. Navigation includes a list of links that users use to move between sections of the application. \- \[nord-nav-item]\(/raw/components/nav-item.md): Navigation item populates sidebar navigation with links. Every item should be placed inside a navigation group. \- \[nord-nav-toggle]\(/raw/components/nav-toggle.md): Nav toggle is meant for hiding and showing the primary navigation. This component is used internally in the Layout component, but can also be used separate to further customize the behavior. \- \[nord-notification]\(/raw/components/notification.md): Notifications provide important information that requires action or acknowledgement. A notification is displayed until the user dismisses it. \- \[nord-notification-group]\(/raw/components/notification-group.md): Notification group is used to position and style a group of notifications. \- \[nord-popout]\(/raw/components/popout.md): Popouts are small overlays that open on demand. They let users access additional content and actions without cluttering the page. \- \[nord-progress]\(/raw/components/progress.md): Progress component is used to display a circular pie-chart style progress indicator. You can customize the size and color of the progress indicator with the provided properties. \- \[nord-progress-bar]\(/raw/components/progress-bar.md): Progress Bar is used to visually represent the completion of a task or process. It shows how much of the task has been completed and how much is still left. \- \[nord-qrcode]\(/raw/components/qrcode.md): QR Code component is used for providing information or links to users which they can quickly scan with their smartphone. \- \[nord-radio]\(/raw/components/radio.md): Radio buttons are graphical user interface elements that allow user to choose only one option from a predefined set of mutually exclusive options. \- \[nord-range]\(/raw/components/range.md): Range input lets user specify a numeric value using a slider which must be no less than a given value, and no more than another given value. \- \[nord-segmented-control]\(/raw/components/segmented-control.md): Segmented control is used to pick one choice from a set of closely related choices, and immediately apply that selection. \- \[nord-segmented-control-item]\(/raw/components/segmented-control-item.md): Segmented control items populate a segmented control with options. Every item should be placed inside a segmented control. \- \[nord-select]\(/raw/components/select.md): Select lets users choose one option from an options menu. Consider using select when you have 5 or more options to choose from. \- \[nord-skeleton]\(/raw/components/skeleton.md): Skeletons are used to provide a low fidelity representation of content before it appears in a view. This improves the perceived loading time for our users. \- \[nord-spinner]\(/raw/components/spinner.md): Spinner component is used to indicate users that their action is being processed. You can customize the size and color of the spinner with the provided properties. \- \[nord-stack]\(/raw/components/stack.md): Stack component manages layout of immediate children along the vertical or horizontal axis with optional spacing between each child. \- \[nord-tab]\(/raw/components/tab.md): The interactive tab button for use within the tab group component. \- \[nord-tab-group]\(/raw/components/tab-group.md): Tab Group allows multiple panels to be contained within a single window, using tabs as a navigational element. \- \[nord-table]\(/raw/components/table.md): Table is used to organize and display information from a data set. Provides table styles in addition to features like sticky headers and support for narrow viewports. \- \[nord-tab-panel]\(/raw/components/tab-panel.md): The panel which contains content that can be revealed using a tab in the tab group component. \- \[nord-tag]\(/raw/components/tag.md): Tags represent a set of keywords that help label, categorize, and organize objects. Commonly used to signify the attributes of an object. \- \[nord-tag-group]\(/raw/components/tag-group.md): Tag groups are designed to bring together selectable tags that are of a similar nature. For example categories you can filter by. \- \[nord-textarea]\(/raw/components/textarea.md): Textarea is a component that allows user to write text over multiple rows. Used when the expected user input is long. For shorter input, use the Input component. \- \[nord-toast]\(/raw/components/toast.md): Toasts are non-disruptive messages that appear in the interface to provide quick, at-a-glance feedback on the outcome of an action. \- \[nord-toast-group]\(/raw/components/toast-group.md): Toast group is used to position and style a group of toasts, whilst ensuring they are announced by screen readers. \- \[nord-toggle]\(/raw/components/toggle.md): Toggle switch gives control over a feature or option that can be turned on or off. If a physical switch would work for the action, a toggle is probably the best component to use. \- \[nord-tooltip]\(/raw/components/tooltip.md): Tooltips are floating containers for displaying additional information for the currently focused element. A tooltip can be useful when you want to e.g. give a hint about an existing Command Menu shortcut. \- \[nord-top-bar]\(/raw/components/top-bar.md): Top bar is a header component that is always visible at the top of the interface. Top bar allows functionality such as search and contextual menus to be placed at the top of the interface. \- \[nord-visually-hidden]\(/raw/components/visually-hidden.md): Visually hidden is used when an element needs to be available to assistive technologies like screen readers, but be otherwise hidden. # Readme ## Usage This section includes guidelines for designers and developers about the usage of this component in different contexts. \> \*\*Do:\*\* - Use the circle avatar to represent a single user or an animal. \- Use the square avatar for organizations or group of animals. \- Always add the name of the user, animal, organization, or group of animals using the \`name\` property. \- For the best results, use square images or images cropped into a square. \> \*\*Don't:\*\* - Don’t use the circle avatar to represent organizations or group of animals. \- Don’t use the square avatar to represent a single user or an animal. \- Don’t use an avatar when an icon is more suitable, for example when denoting groups or "things". \- Try to avoid using landscape or portrait images as avatars. Let users crop their images before or after uploading if possible. # Readme ## Usage This section includes guidelines for designers and developers about the usage of this component in different contexts. \> \*\*Do:\*\* - Use established variants and color patterns so that users can clearly identify the importance level. \- Use to show a status update on a piece of information or action. \- Use to mark something as a “draft” or “new”. \- Use when you want to highlight something that has been added recently. \- Always position badge so that it’s easy to understand what object it’s related to. \> \*\*Don't:\*\* - Don’t make badges clickable. Instead use button component’s small variant. \- Don’t use alternatives to existing badge variants. \- Don't use badges for labeling, categorizing, or organizing objects. Use the \[tag component]\(/components/tag/) instead. --- ## Content guidelines Badge labels should use a single word to describe the status of an object. Only use two words if you need to describe a complex state: \> \*\*Do:\*\* Complete \> \*\*Don't:\*\* Action completed When writing badge labels, always write them in sentence case, not title case. The first word should be capitalized and the rest lowercase (unless a proper noun): \> \*\*Do:\*\* Partially refunded \> \*\*Don't:\*\* Partially Refunded Avoid unnecessary words and articles in badge labels, such as “is”, “the”, “an” or “a”: \> \*\*Do:\*\* Pending \> \*\*Don't:\*\* Item is pending Always describe the status in the past tense: \> \*\*Do:\*\* Refunded \> \*\*Don't:\*\* Refund --- ## Variants This section describes the different component variants, their purpose, and when to use each variant. | Name | Purpose | | ----------- | --------------------------------------------------------------------------------------------------------------------------------------- | | `neutral` | The default style variant. | | `info` | Used to convey general information that isn’t critical. | | `success` | Used to convey success states. For example, you might want to show a badge that tells the user a payment was successful. | | `highlight` | Used to highlight specific items in the interface, like notifications. | | `danger` | Used to communicate problems that have to be resolved so that user can continue forward. Should always be used for highlighting errors. | | `warning` | Used to display information that needs a user’s attention attention and may require further steps. | | `progress` | Used to convey something that’s in progress. | # Readme ## Usage This section includes guidelines for designers and developers about the usage of this component in different contexts. \> \*\*Do:\*\* - Use this component if you need to communicate in a prominent way. \- Place banner at the top of the section it applies to. \- Use for highlighting errors and success statuses. \- Put banner close to the context it’s referring to. \- Move focus to the banner if it’s relevant to the current workflow. \> \*\*Don't:\*\* - Move focus to banner if it appears on page load. \- Use for highlighting general content or as a banner. \- Use to replace an error page. --- ## Content guidelines Banner content should be clear, accurate and easy to understand: \> \*\*Do:\*\* We’re experiencing an incident. Please see our status page for more details. \> \*\*Don't:\*\* There was an error. When writing banner content, always write it in sentence case, not title case. The first word should be capitalized and the rest lowercase (unless a proper noun): \> \*\*Do:\*\* We’re experiencing an incident. \> \*\*Don't:\*\* We’re Experiencing An Incident. Always end in punctuation: \> \*\*Do:\*\* We’re experiencing an incident. \> \*\*Don't:\*\* We’re experiencing an incident # Readme ## Usage This section includes guidelines for designers and developers about the usage of this component in different contexts. \> \*\*Do:\*\* - Use to group together buttons, or dropdowns, of a similar nature or purpose. \- Use the appropriate \`role\` attribute on the button group to provide additional semantics. \- Use an \`aria-labelledby\` attribute referencing another element to best explain the contents of the button group. \> \*\*Don't:\*\* - Don’t add components other than buttons, dropdowns and in some instances visually hidden components to the button group. \- Don’t skip the addition of an appropriate label if the added \`role\` attribute value calls for it. \- Don’t use for building grid based layouts. --- ## Content guidelines Button labels should be clear, accurate and predictable. It should be possible for the user to understand what will happen when they click a button: \> \*\*Do:\*\* View user settings \> \*\*Don't:\*\* Click here When writing button labels, always write them in sentence case, not title case. The first word should be capitalized and the rest lowercase (unless a proper noun): \> \*\*Do:\*\* My tasks \> \*\*Don't:\*\* My Tasks Avoid unnecessary words and articles in button labels, such as “the”, “an” or “a”: \> \*\*Do:\*\* Add item \> \*\*Don't:\*\* Add an item --- ## Variants This section describes the different component variants, their purpose, and when to use each variant. | Name | Purpose | | --------- | -------------------------------------------------------------------------------------------------------- | | `default` | The default variant renders a group of segmented buttons to emphasize that they’re thematically-related. | | `spaced` | The spaced variant renders a gap between the buttons to space them out evenly. | # Readme ## Usage This section includes guidelines for designers and developers about the usage of this component in different contexts. \> \*\*Do:\*\* - Only use one primary button per section, as a main call-to-action. \- Use clear and accurate labels. \- Use established button colors appropriately. For example, only use a danger button style for an action that’s difficult or impossible to undo. \- Prioritize the most important actions. Too many buttons will cause confusion. \- Be consistent with positioning of buttons in the user interface. \- Use strong, actionable verbs in labels such as “Add”, “Close”, “Cancel”, or “Save”. \> \*\*Don't:\*\* - Don't use a primary button in every row of a table. \- Don’t use buttons to link to other pages. Use regular link or a plain style instead where necessary. \- Don’t use buttons for navigation where the link appears within or following a sentence. \- Don’t use labels such as “Read more”, “Click here” or “More”. --- ## Content guidelines Button labels should be clear, accurate and predictable. It should be possible for the user to understand what will happen when they click a button: \> \*\*Do:\*\* View user settings \> \*\*Don't:\*\* Click here When writing button labels, always write them in sentence case, not title case. The first word should be capitalized and the rest lowercase (unless a proper noun): \> \*\*Do:\*\* My tasks \> \*\*Don't:\*\* My Tasks Avoid unnecessary words and articles in button labels, such as “the”, “an” or “a”: \> \*\*Do:\*\* Add item \> \*\*Don't:\*\* Add an item --- ## Variants This section describes the different component variants, their purpose, and when to use each variant. | Name | Purpose | | ---------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `default` | Default style is the most common button variant. Only switch to another variant if you need to adjust the visual weight of the element. | | `primary` | Primary style is reserved for main call-to-actions. Should be used only once per content area or panel, e.g. for a “Save” action. | | `dashed` | Dashed style should be used for actions that trigger filtering. | | `danger` | Danger style should be used for actions that delete data or otherwise make it hard to undo the action. | | `plain` | Used for less important or less common actions. Can be also used for linking to other pages. | | `disabled` | Used for actions that aren’t currently available or not available anymore. Also prevents users from being able to interact with the component, and conveys its inactive state to assistive technologies. | --- ## Icon usage in button Illustrative icons should be always positioned in the `start` slot: ![Button with icon in start slot](https://nordhealth.design/img/components/button/start-slot.png){.n-border.n-border-radius.n-brand-therapy height="475" loading="lazy" style="max-inline-size:700px;" width="800"}![Button with icon in start slot](https://nordhealth.design/img/components/button/start-slot-vet.png){.n-border.n-border-radius.n-brand-veterinary height="475" loading="lazy" style="max-inline-size:700px;" width="800"} When a button is used as a dropdown toggle, the `interface-dropdown-small` icon from [Nordicons](https://nordhealth.design/nordicons/) is automatically placed in the `end` slot (you can use the `hideDropdownIcon` property to hide it): ![Dropdown button](https://nordhealth.design/img/components/button/dropdown.png){.n-border.n-border-radius height="475" loading="lazy" style="max-inline-size:700px;" width="800"} Each button size has a recommended icon size. The medium button uses the `s` icon size, the [small button](https://nordhealth.design/components/button/?example=small+buttons) uses the `xs` icon size, and the [large button](https://nordhealth.design/components/button/?example=large+buttons) uses the `m` icon size. The icon will adjust size automatically based on the button size, so you will get the correct behavior by default. However, this can be overridden by explicitly setting a size on the icon. ![Button icon sizes](https://nordhealth.design/img/components/button/icon-sizes.png){.n-border.n-border-radius.n-brand-therapy height="475" loading="lazy" style="max-inline-size:700px;" width="800"}![Button icon sizes](https://nordhealth.design/img/components/button/icon-sizes-vet.png){.n-border.n-border-radius.n-brand-veterinary height="475" loading="lazy" style="max-inline-size:700px;" width="800"} Use `interface-add-small` icon in the `start` slot for create/add type primary actions in the [header](https://nordhealth.design/components/header/): ![Create/add type primary action with icon](https://nordhealth.design/img/components/button/create.png){.n-border.n-border-radius.n-brand-therapy height="475" loading="lazy" style="max-inline-size:700px;" width="800"}![Create/add type primary action with icon](https://nordhealth.design/img/components/button/create-vet.png){.n-border.n-border-radius.n-brand-veterinary height="475" loading="lazy" style="max-inline-size:700px;" width="800"} --- ## Additional considerations - Users of assistive technology expect a button to submit data or do an action. If you need the button to navigate into another view, use the `href` property which will output `` tag instead of a `