# Navigation

## Product architecture

### Overview

People tend to be unaware of an product’s navigation until it fails to meet their expectations.

Your job, as a designer, is to design your navigation in a way that supports the structure and purpose of your product without calling attention to itself. Navigation should feel natural and familiar, and shouldn’t dominate the interface or draw focus away from content.

Based on your platforms information architecture (IA), a user can move in one of three navigational directions.

#### Hierarchical Navigation

Also referred to as **‘forward navigation’** and **‘reverse navigation’**, this navigation pattern refers to the moving between destinations at consecutive levels of your information architecture.

For example, users may want to move through your platform to in order to complete a task, however they would also like to move back up the IA to get back home.

Hierarchical navigation can be implemented using:

- Content containers such as cards, lists, or image lists
- Buttons that advance to another screen or return to previous
- In-platform search on one or more screens
- Links within content

<Image
  src={patternsNavigationProductArchitectureHierarchicalNavigation}
  alt=""
/>

#### Flat Navigation

Also referred to as **‘lateral navigation’**, this navigation pattern refers to movement between screens at the same level of hierarchy. It enables access to different destinations and features, at the same contextual level.

Flat navigation can be implemented using:

- Navigation drawer
- Navigation rail
- Tabs

<Image src={patternsNavigationProductArchitectureFlatNavigation} alt="" />

#### Experience-Driven Navigation

This navigation pattern allows users to move freely through content, or the content itself defines the navigation. Legislative workflows, games, and other immersive apps generally use this navigation style.

Experience-driven navigation can be implemented using:

- Content containers such as cards, lists, or image lists
- Buttons that advance to another screen or return to previous
- In-platform search on one or more screens
- Links within content

<Image
  src={patternsNavigationProductArchitectureExperienceDrivenNavigation}
  alt=""
/>

| Component         | Used for               | # destinations | Devices                 |
| ----------------- | ---------------------- | -------------- | ----------------------- |
| Navigation drawer | Top-level destinations | 5+             | Mobile, Tablet, Desktop |
| Navigation rail   | Top-level destinations | 5+             | Mobile, Tablet, Desktop |
| Tabs              | Any level of hierarchy | 2+             | Mobile, Tablet, Desktop |

## Configuration

The TDS navigation components are entirely configurable so that your product is built in the most appropriate way for your users. Simpler products have the flexibility of using a header or a navigation drawer, whereas more complex products may require a combination of navigation components to accommodate the depth of their information hierarchy.

Want to learn more? Visit our [Top tips](#top-tips) area to find out more about composing effective information and visual hierarchies.

### Header only

The Header component can be used as a standalone navigation for your product through the use of tabs.

<Image
  src={patternsNavigationConfigurationHeaderOnly}
  alt="An example of header-only navigation"
/>

### Header with Navigation Drawer/Rail

The Navigation Drawer or Rail allows for more navigational items to stack vertically and an additional level of hierarchy when paired with the header navigation.

In this instance, the **header remains the highest level of navigation**. Therefore, it is important to place any product-level navigation/actions within the header and any subsequent pages of navigation underneath these in the drawer/rail.

<Image
  src={patternsNavigationConfigurationHeaderWithNavigationDrawerRail}
  alt="An example of a header with a navigation drawer"
/>

### Navigation Drawer/Rail only

The Navigation Drawer/Rail can be used as a standalone navigation for your product.

However, please ensure that if you are only using a drawer/rail, that the component has the header turned on. This is to keep the product identifiable to customers with the Thales branding.

<Image
  src={patternsNavigationConfigurationNavigationDrawerRailOnly}
  alt="An example of a navigation rail only"
/>

## Responsiveness

When designing your layout system, you may want to include some form of navigation to help your users better orientate themselves within your product.

This page aims to promote best practices and the TDS standard for implementing navigation components, while optimising the pre-defined [layout system](/docs/foundations/grids-layout).

### So what is the ‘Safe zone’?

The TDS provides a grid system based on a **fluid** grid type, designed for complex screens and web applications as it uses 100% of the screen’s width. When implementing a navigation system, it is important to adapt your grid layout based on the size of your **“safe zone”**.

Safe zones are designed to keep your user interface (UI) in-view, taking into consideration internal factors, such as components that push content like the navigation drawer, and external factors, such as the edge of a TV display or under the notch and home bar of an iPhone X. It is often referred to as the **main viewport**.

**When safe zones hit a breakpoint in the grid system, it is important to consider whether the UI needs to adapt for the new layout.**

To help us calculate a navigation component’s correct size, we divide the viewport into zones.
The more important one is the **safe zone**.

As mentioned above, it is important to always consider the safe zone as your main viewport in which you apply the grid to.

<Image src={patternsNavigationResponsivenessSoWhatIsTheSafeZone} alt="" />

### Choosing the right grid and component

Depending on the size of your safe zone, you should consider making a consistent choice between which navigation pattern to choose (rail or drawer) and also which grid to apply on your safe zone frame.

| Viewport size | Recommended navigation pattern                         | Safe zone grid    |
| ------------- | ------------------------------------------------------ | ----------------- |
| 1440px        | persistent drawer (240px width)                        | xlarge            |
| 1366px        | persistent drawer (240px width)<br/>Collapsible drawer | @<br/>large       |
| 1024px        | Overlay drawer<br/>Rail (72px width)                   | medium<br/>medium |
| 768px         | Overlay drawer<br/>Rail (72px width)                   | xsmall<br/>xsmall |
| 320px         | Overlay drawer                                         | xsmall            |

### Responsive sizing using the Navigation Drawer

#### XLARGE GRID 1440px

- High resolution desktops and laptops

<Image
  src={
    patternsNavigationResponsivenessResponsiveSizingUsingTheNavigationDrawer0
  }
  alt=""
/>

#### XLARGE GRID 1366px

- Standard resolution desktops and laptops
- Tablets in landscape mode.

<Image
  src={
    patternsNavigationResponsivenessResponsiveSizingUsingTheNavigationDrawer1
  }
  alt=""
/>

#### MEDIUM GRID 1024px

- Standard resolution desktops and laptops
- Tablets in portrait mode.

<Image
  src={
    patternsNavigationResponsivenessResponsiveSizingUsingTheNavigationDrawer2
  }
  alt=""
/>

#### MEDIUM GRID 768px

- Small tablets in portrait mode.

<Alert type="info" title="Note">
  For any device that force the main content to fall within the ‘xsmall’
  breakpoints (0-599px), the drawer must **overlay** rather than push the main
  content.
</Alert>

<Image
  src={
    patternsNavigationResponsivenessResponsiveSizingUsingTheNavigationDrawer3
  }
  alt=""
/>

#### XSMALL GRID 320px

- Phones in portrait mode.

<Alert type="info" title="Note">
  For any device that force the main content to fall within the ‘xsmall’
  breakpoints (0-599px), the drawer must **overlay** rather than push the main
  content.
</Alert>

<Image
  src={
    patternsNavigationResponsivenessResponsiveSizingUsingTheNavigationDrawer4
  }
  alt=""
/>

## Top tips

The handy guide is designed to help you build an effective navigation system using the TDS Navigation Drawer component.

Through careful analysis of Thales’ own products, the TDS Core Team recognises that navigation can differ from product to product.

We have produced this handy guide to help you, the designer 🎨, build the most effective navigation system for your product using our pre-built navigation drawer. It is almost entirely configurable through the diverse range of variants designed with you in mind.

With tips on how to structure your navigation and a guide on building your very own navigation drawer using the diverse range of variants provided, we hope that you find this guide helpful and you enjoy designing with the Thales Design System (TDS).

### 💡Tip #1: Know your Information Architecture (IA) first

Abby Cover, author of [How to Make Sense of Any Mess](http://www.howtomakesenseofanymess.com), describes information architecture as **“the way that we arrange the parts of something to make it understandable”**. Its as simple as that…

A well-designed, user-friendly information architecture ensures that users spend less time and effort searching for information and are successful in finding what they need.

IA is an essential part of user experience (UX) design and much like navigating a supermarket or shopping mall in real-life, information architecture for digital products must do these two things:

- **Help the customer find whatever it is they’re looking for**
- **Tell the customer where they are**

When designing your products information architecture, it is important to think of it as a **user-flow** rather than a traditional hierarchy. Some examples of navigation use these common forms of layout:

- Categorize by **topic**, letting the user know what’s here by revealing the content of the product.
- Categorize by **audience groups**, such as
- Categorise by **tasks**, such as

### 💡Tip #2: Create effective visual hierarchies

An important way to make your product easy to grasp in a hurry is to make sure that the appearance of things on the page accurately portray the relationships between the things on the page.

- **The more important something is, the more prominent it is**
- **Things that are related logically are related visually**
- **Things are “nested” visually to show what’s part of what**

<Image src={patternsNavigationTopTipsTip2} alt="" />



# Forms & Controls

## Form Structure

### Overview

To help you build consistent forms in your product, the Thales Design System is providing a set of on-the-shelf components in the “Form Elements” section. This dedicated patterns section is made to help you correctly build with those elements, avoid common mistakes and give some empirically proven good practices.

We have dedicated documentation for each component to help you use them well at their component level. If you need to refer to a specific component’s documentation please check the right page.

### Prefer multi-step forms over single step forms

Sometimes, you need to gather lots of data from your users.
This might end up in very long forms. To **avoid strain and frustration**, you can easily create sub-forms of related contents to slice your form into a **multi-step pattern**.
Doing this will increase form completion **in B2B and Business** related environments.

- First impression matters, so a first small form will always be less intimidating
- By asking for sensitive data (i.e financial) at the end of a multi-step form, users are more likely to finish the form (rather than losing all the previous steps). It’s a cognitive bias know as “sunk cost fallacy”)
- Seeing a progress indicator help users to be more motivated to complete the form. This is, again, based on numerous proven cognitive biases such as “the endowed progress effect”.

<Image src={formStructurePreferMultiStepFormsOverSingleStepForms} alt="" />

### Provide the related progress indicator

If you are doing a multi step form, you need to provide the user a way to understand where they are in the process, and also what is coming next.
Depending on the situation, several progress indicators can be used such as:

- Steppers
- Progress bars
- Progress headers/footers

Always choose the progress indicator that fits the most your product, there is no right or wrong component to choose in that case, only your users can tell.

<Image src={formStructureProvideTheRelatedProgressIndicator} alt="" />

### Forms should be in one column

Google’s study on the subject showed that aligning labels above fields on the top-left side reduces form completion time because of the fewer visual fixations it requires to get the information. Also, as the eye scans from top to bottom, stacking your elements vertically will be more comfortable for the user. Multiple columns can have an unexpected and unwanted effect, and strain the user.

[Reference here](https://ai.googleblog.com/2014/07/simple-is-better-making-your-web-forms.html).

<Image src={formStructureFormShouldBeInOneColumn} alt="" />

### Always have readability in mind

As mentioned in the Typography System in the Foundations, you should always set a consistent, maximum number of characters.

Long form fields tend to make things harder to read, and are visually unbalanced.
You should always go with form inputs that can fit **40 to 80 characters**.

<Image src={formStructureAlwaysHaveReadabilityInMind} alt="" />

### Name your forms correctly

By giving your forms a clear title, you will help the user understand the goal and value of it. For example, if you are making a form for filling a Technical Issue ticket, you could clarify by naming it “Technical issue submission form” or “Declare a technical issue”.

<Image src={formStructureNameYourFormsCorrectly} alt="" />

### Create groupings, and name them

If you have several sections in your form (Personal information, billing address, payment details, …), you should always keep them in groupings. And of course, give a name to those groupings.

<Image src={formStructureCreateGroupingsAndNameThem} alt="" />

### Form buttons must be specific to the task

The “Submit” button at the end of your form should describe exactly the action it will invoke. Never confuse the user about what is going to happen when he clicks the button. You can also refer to our dedicated documentation on button labelling.

<Image src={formStructureFormButtonsMustBeSpecificToTheTask} alt="" />

### Create visual density in your forms

The form elements and text inputs are built with some natural spacing. But because a label is related to its field below and not the field before it in the form, you will always want to put more spacing between two form items than between the label and the field. This to follow Gestalt’s Law of Proximity and Similarity.

[Reference here](https://www.interaction-design.org/literature/topics/gestalt-principles).

<Image src={formStructureCreateVisualDensityInYourForms} alt="" />

## Form flow

[Find the relative content directly into Figma](https://www.figma.com/design/z6RoOdZKVzR2Yl588C22ku/Quantum---4.-%F0%9F%93%90Patterns---Templates?node-id=2008-15904&t=2wzDbA8VSKy75m1Y-4).

## Case study

[Find the relative content directly into Figma](https://www.figma.com/design/z6RoOdZKVzR2Yl588C22ku/Quantum---4.-%F0%9F%93%90Patterns---Templates?node-id=2008-15911&t=2wzDbA8VSKy75m1Y-4).



# Data Tables

Tables are containers for displaying information. They allow users to quickly scan, sort, compare, and take action on large amounts of data.

## Problem

When reviewing table components across the Thales organisation, the Core Team recognised that the tables were inconsistent - they had a diverse range of competing UX decisions. The sizing placement of links and CTAs, filtering, sorting and pagination were all over the place.

We needed to define a pattern in Quantum that could universally serve all use cases across all digital products and serve future products and features.



## Purpose

In order to define the patterns that shape the Quantum Table component, it is important to establish the purpose of the component. Hence, the following statements have been agreed to describe the purpose of the table component:

1. To browse large amounts of information at once, such as assessing showing multiple items and their statuses.
2. To determine and execute actions quickly, such as deleting or moving multiple items.
3. To compare information, such as how many items are completed versus how many are in progress

## Options

The Table component needs to cater for a variety of user needs across the business lines and therefore, a diverse range of options to build your table must be available. These are outlined below:

### Types

#### Standard table

Simple data tables are intended to define a list of values of data types that have a simple structure.

<Image src={optionsTypesStandardTable} alt="" />

#### Expandable table

Expanded view enables the users to expand and collapse the row for an optimum use of the display. This means they can instantly expand to view more details and collapse when not necessary.

<Image src={optionsTypesExpandableTable} alt="" />

### Layout

#### Density

Data tables support three densities:

- Small (S) for condensed amount of data
- Medium (M) as default
- Large (L)

When users view and interact with large amounts of information, high density components can improve the experience.

<Image src={optionsLayoutDensity} alt="" />

### Table Style

The style of a row can be a big factor in how easy it is for users to scan and read when looking to find data quickly. So, when designing a table element, you should also try to choose the row style that best suits the overall style of your platform.

#### Horizontal lines (Dividers)

Only showing horizontal lines reduces the visual noise of a full grid. This style includes plenty of white space while still helping the user keep their place while reading.

This style is the most common and recommended for all data set sizes.

<Image src={optionsTableStyleHorizontalLinesDivider} alt="" />

#### Grids

Including both horizontal and vertical lines provides the most separation between data points, but the excess visual noise can be distracting.

This spreadsheet-style is recommended for dense, data heavy tables.

<Image src={optionsTableStyleGrids} alt="" />

#### Zebra stripes

Alternating different color backgrounds for each row is another good way to help users keep their place while reading.

This style is recommended for larger data sets where the alternating pattern will be clear and not cause confusion that a particular row is highlighted.

<Image src={optionsTableStyleZebraStripes} alt="" />

#### Free forms

With no horizontal or vertical dividers, this style of row is effective in reducing visual noise and can also produce a very minimalistic look.

This style is appropriate for small amounts of information, where users don’t need too much assistance when following the information.

<Image src={optionsTableStyleFreeForms} alt="" />

### Row Behaviour

Depending on the importance of the table and the information provided in each row, it is necessary to provide varying levels of abstraction within the row of a table.

#### Single row

Single rows are used to present primary information.

<Image src={optionsRowBehaviourSingleRow} alt="" />

#### Expandable row

The expandable row is useful for displaying secondary information about an item, without having to navigate to a new page.

Not only does this maintain the abstract information of the item, but it provides an expandable/collapsible option that is triggered by a chevron icon.

<Image src={optionsRowBehaviourExpandableRow} alt="" />

#### Multi expandable row

Multiple expanded rows are used when there is a list of sub-items within a row item.

The columns within a Multiple Expanded Row can follow different column headers than the main table.

<Image src={optionsRowBehaviourMultiExpandableRow} alt="" />

### Utilities

Table utilities are best described as the “tools” that help customise the level of information that is presented to the user. Whether that be filtering a list of items or sorting them to improve scannability.

#### Total entries

Displaying number of data entries is recommended to help the user consider the quantity of data they are dealing with. Especially when using search and filtering features.

<Image src={optionsUtilitiesTotalEntries} alt="" />

#### Toolbar

Some data tables require advanced features like search, settings, filtering…
In these specific cases, you should create a dedicated toolbar for your data table to include these capacities.

<Image src={optionsUtilitiesToolbar} alt="" />

#### Pagination

It is often recommanded to break long tables into several pages.
When doing so, make sure to include a pagination system. Users need to understand on which page they are at the moment, and be able to navigate to other pages.

When doing pagination, consider giving the users the freedom to choose how many rows they want to be displayed.

<Image src={optionsUtilitiesPagination} alt="" />

## Behaviour

### Resizing

The data table component should provide two types of horizontal resizing methods: Fixed or Fluid.

#### Fixed

<Image src={behaviourResizingFixed} alt="" />

#### Fluid

<Image src={behaviourResizingFluid} alt="" />

### Sticky header & column

#### Sticky header

A sticky header allows the end user to always be aware of the data type they are looking at thanks to the header.
It is very helpful in a very long data table situation or when you need to create scroll zones.

<Image src={behaviourStickyHeader} alt="" />

#### Sticky column

Sticky columns are used to emphasize on a certain type of data, allowing the user to quickly create a functional or logical link with the rest of the data.
Also, very helpful when the data table is very wide or you have restricted space and need to create a scroll zone.

<Image src={behaviourStickyColumn} alt="" />

### Table interactions

#### Resizing columns

To optimize readability on the end user side, and when you have a cluttered amount of columns, it might be smart to consider giving the capacity to resize the columns
as they need.

<Image src={behaviourTableInteractionsResizingColumns} alt="" />

#### Toggle density

You can include toggle buttons to let the user switch between densities (Small, medium, large) depending on their preferences.

<Image src={behaviourTableInteractionsToggleDensity} alt="" />

#### Filtering data

Include filtering capability to allow users to apply specific parameters in order to see only filtered data. This can be applied at the table level globally in the toolbar, or filter at a specific data type level in the header.

When displaying filtered data, consider displaying the number of results.

<Image src={behaviourTableInteractionsFilteringData} alt="" />

### Row interactions

#### More actions

Allow the user to access multiple actions on the same row with a “More actions” button.
This will save a lot of space and reduce information overload.

<Image src={behaviourRowInteractionsMoreActions} alt="" />

#### Hover actions

Presenting additional actions when a user hovers, helps to reduce visual clutter.
However, it can cause discoverability issues because the user needs to interact with the table to expose the presentation of actions.

<Image src={behaviourRowInteractionsHoverActions} alt="" />

#### Row details: modal

To apply modifications, updates or actions on a row, you can allow the user to click on it to scale it up in a modal view.
It can also allow you to display more information about the row (i.e full truncated texts, images, …)

<Image src={behaviourRowInteractionsRowDetailsModal} alt="" />

#### Row details: side panel

The side panel has the same interest as the modal but doesn’t prevent the end user from interacting with the rest of the table, whereas the modal does.

<Image src={behaviourRowInteractionsRowDetailsSidePanel} alt="" />

#### Multi-select & bulk actions

Allow the user to select multiple items and update/edit them at the same time. Once the user has selected rows, actions in the header or above the table should have a common impact on them. This helps the users save a lot of time.

<Image src={behaviourRowInteractionsMultiSelectBulkActions} alt="" />

### Editing data

#### Single cell edition

Allow your users to edit a single data cell by providing a data input field when the user clicks (or press the Enter key if focused) on the cell or on the edit button.

<Image src={behaviourEditingDataSingleCellEdition} alt="" />

#### Modal

Allow your users to edit the data when the users open the row details in a modal view.

<Image src={behaviourEditingDataModal} alt="" />

#### Side panel

Allow your users to edit the data when they open the row details in a side panel view.

<Image src={behaviourEditingDataSidePanel} alt="" />

## Usage Guidelines

### Readability and discoverability

#### Left align textual data

Textual data is always left-aligned within a table to improve scannability. Column headers follow the alignment of the data and therefore will too be left aligned.

<Image
  src={usageGuidelinesReadabilityAndDiscoverabilityLeftAlignTextualData}
  alt=""
/>

#### Right align numerical data

Numerical data should generally be right-aligned for the ease of scanning and comparing.

However, numerical data can be left aligned if the numbers are arbitrary identifiers, also known as “nominal numbers,” which means they can’t be compared or combined arithmetically (e.g., postcodes, IP addresses, phone numbers). Column headers follow the alignment of the data.

<Image
  src={usageGuidelinesReadabilityAndDiscoverabilityRightAlignNumericalData}
  alt=""
/>

#### Units of measure

Numerical data will sometimes require units of measure to help indicate to the user what data is necessary to communicate values of that physical quantity.

It is recommended that units are presented alongside the data within the cell, for clear and consistent readability.

<Image
  src={usageGuidelinesReadabilityAndDiscoverabilityUnitsOfMeasure}
  alt=""
/>

#### All data should be centred vertically

By vertically centring all data, the table offers a sense of visual balance regardless of the complexity of its contents.

<Image
  src={
    usageGuidelinesReadabilityAndDiscoverabilityAllDataShouldBeCentredVertically
  }
  alt=""
/>

#### Arrange columns in order of importance from left to right

- **Don’t**: put secondary information on the far left, it will imply to the user that it is most important.
- **Do**: present columns in a logical order for the user.

<Image
  src={
    usageGuidelinesReadabilityAndDiscoverabilityArrangeColumnsInOrderOfImportanceFromLeftToRight
  }
  alt=""
/>

#### Use imagery where appropriate

- **Don’t**: simplify the table with purely textual and numeric data if there is a more accessible opportunity to present information.
- **Do**: use relevant imagery to elevate your data, and create a more obvious trigger for your users.

<Image
  src={usageGuidelinesReadabilityAndDiscoverabilityUseImageryWhereAppropriate}
  alt=""
/>

#### Avoid using too many colors

- **Don’t**: overcrowd the table with numerous states and visual indicators. It will confuse users and make the information difficult at the beginning.
- **Do**: minimise the use of visual signs, providing clarity on the important pieces of information.

<Image
  src={usageGuidelinesReadabilityAndDiscoverabilityAvoidUsingTooManyColors}
  alt=""
/>

#### Truncation

- **Don’t**: use inconsistent row heights to cater for text wrapping, this makes the table harder to scan.
- **Do**: use truncation for consistency and scannability, while maintaining visual balance in row height.

<Image src={usageGuidelinesReadabilityAndDiscoverabilityTruncation} alt="" />



# Data Table Filtering

## Introduction

These patterns cover how to approach and use filtering in the context of Data Tables.



### Useful links

Find researches material and details about the [Figma contribution process](https://www.figma.com/design/7qEttRJIyhDwlN3Tih320D?node-id=99-89).

## Common guidelines

### Distinguishing filtering from sorting

#### Filtering

The process of **narrowing down** a larger set of data or content by applying one or more criteria or conditions, so that only items matching those criteria are displayed.

It hides items that do not match chosen criteria.

#### Sorting

The process of **arranging data** or items in a particular sequence or order based on defined criteria such as alphabetical, numerical, or chronological order.

It changes the order of the items without removing any.

#### Provide visual feedback

When designing filters, it is essential to provide clear and consistent visual feedback to users about the active filters and their effect on the displayed data. It is therefore important to provide a visual indication following user actions, such as update success, loading time, absence of results or possible errors.

Feedback should be delivered through means appropriate to context (such as color changes, inline messages, icons, or notifications) and should be discoverable and accessible to all users.

<Image
  src={patternsDataTableFilteringCommonGuidelinesProvideVisualFeedback}
  alt=""
/>

#### Allow users to adjust their search criteria

Allow users to easily add or remove filters to adjust their search criteria with options to select or unselect directly or use a “clear filters” quick action. Ensure real-time updates to the data when filters are adjusted, or provide an “apply” button for more complex scenarios/eco-design rules.

<Image
  src={
    patternsDataTableFilteringCommonGuidelinesAllowUsersToAdjustTheirSearchCriteria
  }
  alt=""
/>

#### Responsive

Adapt the accessibility of your filters based on the device and available screen space. Avoid using floating sheets on touchscreens and overly intrusive filters on desktops or larger screens. Additionally, you may need to adjust the number of filters displayed on the page, making the prioritization of the order in which filters are shown a crucial aspect to address.

Ensure filter controls are easily tappable on touch devices, optimize loading times to enhance performance, and maintain clear visibility and usability of filter options without requiring excessive scrolling or zooming.

Make sure to test the filtering workflows on the targeted devices and viewport sizes where your user will perform the tasks.

<Image src={patternsDataTableFilteringCommonGuidelinesResponsive} alt="" />

#### Eco-design

Eco-design minimizes environmental impact by reducing data queries. For light datasets, use dynamic loading to apply filters instantly. For heavy datasets, an “Apply filters” button helps control queries. It groups modifications, reducing excessive server requests. This improves performance, lowers the carbon footprint, and enhances user experience.

As a developer, it is important to test the cost and weight of the data requests. As a designers, it is important to know those considerations upfront so you can implement the most relevant loading and data request approach and getting the right balance between UX / Cost / Eco-design.

<Image src={patternsDataTableFilteringCommonGuidelinesEcoDesign} alt="" />

#### Accessibility

Be careful to make an accessible design. Test it with real users or use tools to simulate specific situations. Research and filtering in data table can be tricky. Here is the link to the internal accessibility guidelines.

<Image src={patternsDataTableFilteringCommonGuidelinesAccessibility} alt="" />

## Usage

### Filters visibility & access

#### Filters in the content flow

Filters are part of the main page layout. They live alongside the content, typically in a sidebar, horizontal bar, or embedded within a results table. Even when collapsible, they are considered part of the main interface structure.

Characteristics:

- Always or mostly visible
- Minimal disruption when used
- Filters inputs are directly nearby the content

Examples:

- Dashboard filter bars above data tables / lists
  <Image
    src={
      patternsDataTableFilteringUsageFiltersVisibilityAccessFiltersInTheContentFlowDashboardFilterBarsAboveDataTablesLists
    }
    alt=""
  />
- Filters within columns in a data table
  <Image
    src={
      patternsDataTableFilteringUsageFiltersVisibilityAccessFiltersInTheContentFlowFiltersWithinColumnsInADataTable
    }
    alt=""
  />
- Faceted navigation (e.g. Amazon desktop)
  <Image
    src={
      patternsDataTableFilteringUsageFiltersVisibilityAccessFiltersInTheContentFlowFacetedNavigation
    }
    alt=""
  />

#### Off-canvas but non-obtrusive filters

Filters are accessible through a toggleable side panel or area that slides or fades in, but does not block the main content. Users can interact with both the filters and the results at the same time.

Characteristics:

- Panel can be shown or hidden
- Does not hide content area — either resizes it or floats beside it
- Good for progressive disclosure: keep UI clean while retaining access
- Ideal for cases where filtering is useful, but not the primary task

Examples:

- Sliding panels
  <Image
    src={
      patternsDataTableFilteringUsageFiltersVisibilityAccessOffCanvasButNonObtrusiveFiltersSlidingPanels0
    }
    alt=""
  />
  <Image
    src={
      patternsDataTableFilteringUsageFiltersVisibilityAccessOffCanvasButNonObtrusiveFiltersSlidingPanels1
    }
    alt=""
  />
- Expandable filters on desktop with a floating sheet
  <Image
    src={
      patternsDataTableFilteringUsageFiltersVisibilityAccessOffCanvasButNonObtrusiveFiltersExpandableFiltersOnDesktopWithAFloatingSheet0
    }
    alt=""
  />
  <Image
    src={
      patternsDataTableFilteringUsageFiltersVisibilityAccessOffCanvasButNonObtrusiveFiltersExpandableFiltersOnDesktopWithAFloatingSheet1
    }
    alt=""
  />

#### Off-canvas and obtrusive filters

Filters are accessed through a modal or full-screen panel that fully or partially covers the content. Users must interact with the filters and apply them before returning to see the filtered results.

Characteristics:

- Used when space is constrained
- Filtering is a separate step in the flow
- Often includes “Apply” and “Cancel” buttons
- Useful when filters are complex or rarely adjusted

Layout examples:

- Dedicated page for filtering

<Image
  src={
    patternsDataTableFilteringUsageFiltersVisibilityAccessOffCanvasAndObtrusiveFilters
  }
  alt=""
/>

<Alert type="info">
  It is possible to **combine these 3 types of access to filters**. If you have
  both novice and expert users, you may need to display the most used and
  simplest filters within the content, and leave the advanced filters off-canvas
  in a collapsible panel or modal for example.
</Alert>

#### Summary

| Access                           | Best when                                                                                                                                     | Advantages                                                         | Disadvantages                                                                                                                        |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Filters in the content**       | - When the filters are essential to the content and often used                                                                                | - Intuitive and spontaneous<br/>- Non-intrusive                    | -Limited space if too many options <br/>- Might visually overload the interface                                                      |
| **Off-canvas but non-obtrusive** | - When using filters is occasional but it is important to see both the filters and the filtered view                                          | - Easy to access<br/>- Non-intrusive<br/>- Saves space when hidden | - Complex layout and responsive behaviour on small screens<br/>- Reduced screen legibility, especially if there are charts or tables |
| **Off-canvas and obtrusive**     | - When using filters is occasional and/or when the space is constrained<br/>- For deep filtering on complex load of data with many dimensions | - Plenty of space for filters combination<br/>- Reduce distraction | - May cover the main content<br/>- Users might feel interrupted in their task                                                        |

### Live filtering vs. applying filters on submit

#### Behaviour selection

| Behaviour                   | Description                                                                                                                                        | When to use it                                                                                                                                                                                 |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Live filtering**          |   Results update automatically as the user selects or modifies filters, without requiring any additional action (like clicking an "Apply" button). | - Low number and not complex filters<br/>- Real-time feedback is important<br/>- Smaller datasets<br/>- Great for exploratory tasks where users iterate quickly                                |
| **Submit to apply filters** |  Filters are only applied after user confirmation, typically by pressing a button labeled “Apply,” “Done,” or “Update.”                            | - For deep investigations in large datasets<br/>- For complex or multi-steps filters<br/>- Scenarios where performance is important<br/>- Gives more control and adjustments before committing |

#### Live filtering (auto apply)

Results update automatically as the user selects or modifies filters, without requiring any additional action (like clicking an "Apply" button).

<Alert type="warn">
  Be mindful of performance impact, as each user interaction with instant
  filters can trigger a request to the database.
</Alert>

<Image
  src={
    patternsDataTableFilteringUsageLiveFilteringVsApplyingFiltersOnSubmitLiveFiltering
  }
  alt=""
/>

#### Submit to apply filters (manual filter validation)

Filters are only applied after user confirmation, typically by pressing a button labeled “Apply,” “Done,” or “Update”.

Place the Apply button in a consistent and accessible location to avoid risk of forgotten changes.

<Image
  src={
    patternsDataTableFilteringUsageLiveFilteringVsApplyingFiltersOnSubmitSubmitToApplyFilters
  }
  alt=""
/>

### Loading states

When the data is being loaded, it can take a long time to be displayed, so the user needs to be told that the table is being loaded.
To do this, we recommend to display an explicit loading state depending of the development resources (time, finance), UX and performance relevancy

Examples:

#### Skeleton loading

<Image
  src={patternsDataTableFilteringUsageLoadingStatesSkeletonLoading}
  alt=""
/>

#### Loading overlay

<Image
  src={patternsDataTableFilteringUsageLoadingStatesLoadingOverlay}
  alt=""
/>

### No Data scenarios

#### Error case

If a filtering request to the database fails, users should be informed clearly. Provide an error message indicating the failure and suggest actions such as retrying the filter, reloading the table (if so, with the same or previous filters ?), or refreshing the page. Ensuring clear error handling improves usability and prevents user frustration.

<Image src={patternsDataTableFilteringUsageNoDataScenariosErrorCase0} alt="" />
<Image src={patternsDataTableFilteringUsageNoDataScenariosErrorCase1} alt="" />

**How to choose between the first option and the second option?**

- If it is important to keep the filters generating the error and that replacing the previous working state is okay then no data is a relevant option.
- If it is important to preserve the previous working state and it is not bad to remove the error filters then the banner is a relevant option.

<Alert type="warn">
  The following examples are non-exhaustive, and are intended only to inspire
  your future designs. In no way they represent the only truth.
</Alert>

### No Results

An empty state can arise when a user searches for a product or item and no results are found. This may be due to misspellings, incorrect search criteria, the application of restrictive filters, or simply because the item does not exist in the catalog. Besides informing the user that no results were found, suggest they refine their search keywords or filters and verify their spelling.

- **It is necessary to clearly indicate to the user when a query does not yield any results.**
- **Some tips can also be displayed, such as changing the filter or the value of the filters applied to the research.**

<Alert>
  This component can display different messages like a loading error or simply
  the fact that the filters applied returned no results.
</Alert>

<Image src={patternsDataTableFilteringUsageNoDataScenariosNoResults} alt="" />

## Example

### Column filtering

**Purpose:** Allow users to narrow down table data by applying specific filters on one or more columns. Helps users find relevant rows quickly based on column-specific criteria.

#### Usage

When to use:

- For data table in which the users want to cross filters the different dimensions
- Enable a granular and immediate filtering without losing the sight of the data
- When you need independent and non obtrusive filtering by data table (i.e. dashboard view)
- When the data table is the focus of the experience (i.e. data sheets like Excel)

When not to use:

- If the number of columns is very high, filtering by columns could be tiring for the users
- When space is limited, especially if the area is too narrow for tactile interaction

<Alert>
  Refer to the previous sections for common guidelines, how to select between
  live filtering and submit to apply filters, loading states and no data usages.
</Alert>

#### Behaviour

- Filter icon or component is placed in the column header
- When clicking on the component it will open contextual dropdown or modal
- All displayed options are values available in the column
- Active filters are highlighted (e.g.: colors, active indicator, checkbox...)
- Multiple filters can be applied in one column or across others columns at once
- Filter options in one column are dynamically updated based on filters applied in other columns. Only the values that remain valid after applying existing filters are displayed.
- An indicator is showed to the user to inform that some filter are applied (e.g. badge, coloured icon):

<Alert type="warn">
  The following examples are non-exhaustive, and are intended only to inspire
  your future designs. In no way they represent the only truth.
</Alert>

<Image src={patternsDataTableFilteringExample} alt="" />



# Operator Filtering



## Example

### Operator filters

Filtering enables users to streamline and manage visible items within extensive data sets more effectively. By applying filters, users can efficiently locate specific information, explore available options that meet particular criteria, and make well-informed decisions when dealing with a large volume of choices. This functionality not only saves time but also enhances the accuracy and relevance of the data presented to the user.

<Image src={patternsOperatorFiltering} alt="" />

#### Input

| Field        | Definition                                                                                                                                                                                                  | Type                 | Required |
| ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- | -------- |
| **Filter**   | List that is the target of the search performed by the Filter function card.                                                                                                                                | Dropdown             | Yes      |
| **Operator** | Specific comparison to be performed on a list (see Table of Relational Operators below).                                                                                                                    | Dropdown             | Yes      |
| **Value**    | When searching within a list of objects, Value is the name of the key that holds the value you want to compare. User can type it manually or choose from the dropdown. We support multiple values in there. | Multiselect Dropdown | Yes      |

#### List of Operators

| Operator              | Use case                                                                                                                                                     |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **is**                | Will used when user wanted to filter it by specific value.                                                                                                   |
| **is not**            | Will used when user wanted to filter it to exclude the specific value.                                                                                       |
| **contains**          | When value a is an string and value b is text, tests to see if the object has a value with the specified name.                                               |
| **does not contains** | When value a is an string and value b is text, tests to see if the object does not have a key with the specified name.                                       |
| **is empty**          | Checks to see if value a is empty, ignores value b. Definition of "empty" varies by type. Note: Only works for Text and Numbers, Dates, are viewed as empty. |



# Power BI

## About Power BI & Dataviz

Power BI is an interactive data visualization software product developed by Microsoft to support business intelligence.

Data visualization or Dataviz encompasses data and information which are displayed through smart and abstract representations in order to reinforce user’s instant understanding, big picture, data correlation and awareness.
This field is crossroads between Design, Infographics and Data Sciences and plays an important role when it comes to make data meaningful, extract values from amount of data and while also speed-up dashboard analysis.

Other the past few years, Dataviz became more and more ubiquitous in the Thales digital journeys for tracking among other things KPIs (ex: manufacturing efficiency, on-time delivery, forecasting, system health and monitoring…).

## What’s in the box?

The Quantum Power BI distribution provides:

- Dashboard templates that you can use to build your own
- Recommendation and guidelines to build clean and professional dashboards
- Quantum icons pack in .png
- Thales and Thales Alenia Space logos





# Login Page



## Overview

The login page template is a preconfigured form and page layout for applications that need authentication.
The login page enables a user to access an application by entering their authentication info.

## Usage

When to use:

- When a user wants to access his application’s personal account.
- When a user logs out voluntarily or because of inactivity, they can be redirected to the login page.

## Anatomy



### Composition break down

| Required elements     |                                                                                                                                   |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| **Main navigation**   | Simplified navigation with useful links and a language switcher.                                                                  |
| **Login panel title** | A title that describe the form action (login) and can also provide the application name.                                          |
| **Form**              | Single or paired fields that will submit the login data. The form includes the primary action and can also suggest a helper link. |

| Optional elements |                                                                                                                             |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Alternatives**  | Secondary action suggesting an alternative login option. This action leads to another experience/page.                      |
| **Footer**        | If relevant, the footer contains a link to the sign up experience as a tertiary action. Can also contain a disclaimer text. |

## Behaviour

### Size, spacing and position

The Login panel maximum width is 464px.
The Login panel is included in a container with 16px, centred.



### Error message

Error message should appear in a alert component at the top of the form container.
Error messages should be clear and concise. They should help users understand what went wrong and give users steps to resolve the error.
Do not use error message specific to an input, prefer an error banner global to the form.



### Multi-steps

It’s possible to use the login page template to build a multi-steps authentication flow. Use the same Login panel by adapting the content according to your steps.



### Marketing content

If you need to add some marketing or illustrated content to the login page, please contact the Quantum Core Team.



## Usage Guidelines

### Size, spacing and position

- **Don’t**: change the maximum size of width, spacing, centred position.
- **Do**: keep the maximum width to 464px for the Login panel and be careful to use the correct padding in desktop and mobile



### Clear and concise content

- **Don’t**: write too much text in your title or in your disclaimer.
- **Do**: be clear and concise in your title and use links to dedicated pages in your disclaimer for more details.



### Error message

- **Don’t**: give user error message specific to a form field. This protects valid email addresses and usernames from being exposed and helps keep your product be more secured.
- **Do**: use a clear and concise error messages displayed as a global banner at the top of the form container.



### Required field are obvious

- **Don’t**: use the required asterisk symbol
- **Do**: leave the asterisk symbol out from the Login panel. The form is short and the experience makes it obvious that both fields are required.



### Marketing content and other branding decorations

- **Don’t**: add any decoration to the template. No marketing or branding decoration usage guidelines have been documented yet but we want to think about it.
- **Do**: If you have needs and suggestions regarding marketing content, please comment the section so we can discuss about it.