giseldo/neodataset huggingface dataset:
Modal > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the modal component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
List > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the list component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Label > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the label component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Infinite Scroll > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the infinite scroll component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Form > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the form component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Filter > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the filter component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
File Uploader > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the file uploader component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Dropdown > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

- Update the dropdown component usage tab to be in alignment with the template changes.
- Update the content to align with the [results of the accessibility audit](https://gitlab.com/gitlab-org/gitlab-ui/-/issues/1534) where we need to specify the _type_ of dropdown and it's purpose to make the use cases semantically different.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Drawer > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the drawer component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Date picker > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the date picker component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Checkbox > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the checkbox component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Card > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the card component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Breadcrumb > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the breadcrumb component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Banner > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the banner component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Accordion > Update docs to utilize new template

## Background

As part of https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, we worked on a new page template for the `Usage` tab of component pages.

## Resources

See the [parent epic](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/5) for the new template, as well as a few examples of components that have already been migrated to the new structure.

## Proposal

Update the accordion component usage tab to be in alignment with the changes.

This may involve rewording content in addition to restructuring sections. After pushing up your MR, assign it to another Foundations design member for review.

Story points: 1.0
Remove Helm 3 upgrade CI config

In https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2411, we introduced a temporary config to upgrade review apps and production environment from Helm 2 to 3. We need to keep this config for a while to make sure all existing review apps can be migrated to Helm 3 by running the `review:helm-2to3:migrate` manual job. Once we are confident that all review apps have been migrated or shut down, we can clean up the CI config by reverting https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2411 altogether.

/cc @hfyngvason

Story points: 1.0
Review navigation specs

The following discussion from !2386 should be addressed:

- [ ] @tomquirk started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2386#note_592680887):  (+1 comment)

    > **suggestion (non-blocking)**: I guess we should have a spec or to that tests the `isExpanded` state. Not critical though :shrug:

---

Let's drop the snapshot tests in favor of more relevant specs that won't fail every time we update the navbar.

Story points: 1.0
Update presentation of when to use and not to use a selection component

With the update to the toggle documentation https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2356 we have opted to remove the table to make a decision between form components in favour of sections `Usage` and `Do not use a toggle when`.

Components that should be updated:

- [ ] Single checkboxes https://design.gitlab.com/components/checkbox
- [ ] Single-select dropdown https://design.gitlab.com/components/dropdown
- [ ] Radio buttons https://design.gitlab.com/components/radio-button
- [ ] Segmented control https://design.gitlab.com/components/segmented-control
- [ ] Multiple checkboxes https://design.gitlab.com/components/checkbox
- [ ] Multi-select dropdown https://design.gitlab.com/components/dropdown

Story points: 3.0
Getting Started > Structure > Audit and update language

As our system grows, we're adding more complex elements such as object that include conceptual models and layouts in addition to regions.

We want to ensure that definitions for each of these are clear to ensure that it is understandable where to add new elements that are larger than individual components.

## Proposal

Audit the [Getting Started > Structure](https://design.gitlab.com/get-started/structure) page for clarity. The end result should be a general understanding of what makes something a component vs. a region vs. an object.

Story points: 2.0
Pajamas nav > Reconsider parent item function

## Purpose

In the Pajamas navigation a parent item both expands the subnav and takes a user to the first page of the subnav with the same click. Given that we don't make use of section overview pages this behavior feels a bit odd and misleading. While it's not difficult to determine where you landed, I don't think it's the most intuitive. It can also create a delay when you only wanted to access a page within that category, but have to wait for the first page to load before navigating where you wanted.

I'd like to propose that the parent item only expands/collapses the subnav list and does not have it's own destination.

Story points: 1.0
Consider dropping the use of details/summary in the navbar

The following discussion from !2371 should be addressed:

- [ ] @jeldergl started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2371#note_574973550):  (+3 comments)

    > The use of `details` and `summary` here feels out of place semantically. I need to test this in a screen reader, but I'm wondering what the reason is for using it?

The navbar currently leverages `<details>` and `<summary>` elements to render collapsible menu items. This might not be a valid use-case for those elements, let's consider dropping them in favor of simple `v-if`s in the Vue components.

## Implementation plan

- [x] Drop the use of summary elements in favor uls and v-ifs.
- [x] Do not automatically select the first child item when clicking on a parent.
- [x] Keep the behavior where only one menu section can be expanded at a time.
- [x] Improve navbar's accessibility by leveraing `role` and `aria-` attributes.

Story points: 2.0
Adjust navigation items under Data Visualization

Here is the current nav under data visualization in Pajamas:

![Screen_Shot_2021-05-05_at_9.43.01_AM](/uploads/0ce25114150a3bb0ca96d188b99b3d4c/Screen_Shot_2021-05-05_at_9.43.01_AM.png)

From discussion on https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2361#note_568114665, it sounds like the order of pages is because the nav items are automatically placed in alphabetical order. In this section, that leaves us with a surprising result - the Overview item is third and the more detailed pages (Charts, Color) are first.

Should we consider re-ordering the pages in this section based on content rather than alphabetizing? 

If so, perhaps the order could be:

- Overview
- Color
- Charts 
- Single stat

Story points: 1.0
Document a conceptual object model for Jobs

## Problem

Jobs are the main building block of a pipeline. Understanding the essence of Jobs and the concepts associated with them can help us create a better experience around Jobs in GitLab UI. Currently, Jobs are not documented as an object in GitLab. It's difficult to find information around all the concepts associated with jobs and how they're represented in the UI.

## Proposal

Document Jobs using the Conceptual Object Model. 

This model allows for proper separation of concerns: concepts (meaning) and user interface (representation). In other words, a conceptual model is only focused on the concepts and how they relate to each other, not how it’s technically implemented or used in the UI. A conceptual model defines the objects and actions, and enumerates the attributes for every object. The language of the conceptual model diagram is meant to be as simple and accessible as possible to everyone, even if they are not familiar with these kinds of diagrams (for more information, see [Object Modeling for Designers](https://medium.com/@hpadkisson/object-modeling-for-designers-an-introduction-7871bdcf8baf).

Here's an example of how we document the [Merge Request as an object in GitLab.](https://design.gitlab.com/objects/merge-request)

#### Next steps

- [x] Document the concepts associated with Jobs
- [x] Map the concepts associated with Jobs
- [x] Document the layouts for the representations of Jobs in GitLab
- [x] Review the Figma file
- [x] Merge to the Conceptual object model file in Figma
- [x] Map the primary Job page layout
- [x] Merge the semantic layout to the Layouts file 
- [x] Work on a documentation MR ([MR in review](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2713))

## Working Figma files

* [Job object model](https://www.figma.com/file/J68bePHXIN5OPWqaFFY9ri/branch/bMpqqGQtDoPqty4sAFPUsy/Conceptual-model?node-id=5423%3A453)
* [Job semantic layout](https://www.figma.com/file/shVF8UZwrQtkNfMDjcrsyH/branch/PZruVNvWVcpdNwm69cXgeJ/Semantic-layouts?node-id=4636%3A208)

Story points: 3.0
Themes > Adding missing color palettes

Within Pajamas, Figma, and GitLab-UI we define a series of color palettes for each of our available themes. However, we are missing all of the options that are currently available in the product:

![Screen_Shot_2021-05-04_at_1.34.18_PM](/uploads/e63808429305b01cbab67adc1bebeea1/Screen_Shot_2021-05-04_at_1.34.18_PM.png)

Ensure there is continuity between the options in the product and the palettes in Pajamas.

Story points: 2.0
A11y action > Increase input placeholder contrast

## Purpose

Placeholder text within a text input should have sufficient contrast (at least a 4.5:1 ratio).

![image](/uploads/7cefc2c77c090f32fc071b1a7e1ae909/image.png)

## Solution

Use `$gray-500` for `placeholder` text.

This should be updated both in Figma and GitLab UI.

Source: https://gitlab.com/gitlab-org/gitlab-design/-/issues/1475#note_550956831

Story points: 1.0
add description to Toggle like input field

### Problem

I have a need to use a long description to explain what does this toggle is about instead of short help text like "disabled by admin". If I use the help text, it looks like this:

Those live example copies need to be refined. But the length and format illustrate the problem we will face. Long copy and copy with "learn more". I think we should discuss this because in English the copy might be short, but in another language, a two-line description might be common when we face German or another lengthy language.

|  Live Example   |   Component  |
| --- | --- |
| ![Screenshot_2021-04-30_at_09.50.07](/uploads/459b3285064480d5a11b141534095ee5/Screenshot_2021-04-30_at_09.50.07.png)![Screenshot_2021-04-30_at_09.55.32](/uploads/8a2a5f4b8295a4f219879186a4aa3164/Screenshot_2021-04-30_at_09.55.32.png)| ![Screenshot_2021-04-29_at_11.12.38](/uploads/1a80149ee0ae91812bab064f43ee5cbb/Screenshot_2021-04-29_at_11.12.38.png)| 

**This has two problems:**

1. The description is far from the label it belongs to and closer to the label of the next item. This creates more cognition load for a user to figure out, this description belongs to which one?
1. It is too long and visually looks unbalanced

### Solution

|  vertical1 - Live Example   |   vertical1 -  Component  |
| --- | --- |
| ![Screenshot_2021-04-30_at_09.49.33](/uploads/00c0fce14fbf63669f958ae3e0b2edcd/Screenshot_2021-04-30_at_09.49.33.png)   |   ![Screenshot_2021-04-29_at_11.09.57](/uploads/f34e95f7f42b2184cb4b8a3e03f6561f/Screenshot_2021-04-29_at_11.09.57.png)  |

<details><summary>Other explorations</summary>

|  vertical2 - Live Example   |   vertical2 -  Component  |
| --- | --- |
|![Screenshot_2021-04-30_at_09.49.38](/uploads/eef1aa5fde30dc0c159250a37d7adb15/Screenshot_2021-04-30_at_09.49.38.png)|![Screenshot_2021-04-30_at_09.51.37](/uploads/2c19442d8db58a44c96393cd196ee1b4/Screenshot_2021-04-30_at_09.51.37.png)|

| horizontal Live Example | horizontal - component |
| ------------ | --------- |
|          ![Screenshot_2021-04-30_at_10.51.01](/uploads/75dc9299de6d7b7a760e67b61ba2704a/Screenshot_2021-04-30_at_10.51.01.png) ![Screenshot_2021-04-30_at_10.50.57](/uploads/28982d1f3bcd2c045ee1c60a267a772c/Screenshot_2021-04-30_at_10.50.57.png)         |   ![Screenshot_2021-04-30_at_10.58.12](/uploads/c0e42bea94330edb606f16cbe4e20dd9/Screenshot_2021-04-30_at_10.58.12.png)      |
| ![Screenshot_2021-04-30_at_10.50.53](/uploads/fd33afcfc2aeef24bf8dc21694774f1c/Screenshot_2021-04-30_at_10.50.53.png)| ![Screenshot_2021-04-30_at_10.58.15](/uploads/0c57427e72defa377fbd0440100210f3/Screenshot_2021-04-30_at_10.58.15.png)|

</details>


cc: @gitlab-com/gitlab-ux/designers

Story points: 3.0
A11y action > Update audit issues to include severity rating

# Proposal

We have a number of [accessibility audit issues](https://gitlab.com/groups/gitlab-org/-/epics/5387) open. We should include a severity rating for each finding.

# Background

> One thing I haven’t included in the audits I’ve done so far is the level of severity. I’ll try to do that from now on.
> 
> This is the same I’ve used before:
> 
> - **Critical:** prevents some or all users from performing critical tasks with no workaround.
> - **High:** prevents some users from performing critical tasks, or where a workaround may exist.
> - **Medium:** prevents some users from performing non-critical tasks, or where the user experience is seriously degraded for users with certain assistive technologies.
> - **Low:** the user experience is degraded for users with certain disabilities or using certain assistive technologies.
>
>This is the rating Deque proposes:
>
>- **Critical:** This issue results in blocked content for individuals with disabilities. Until a solution is implemented content will be completely inaccessible, making the organization highly vulnerable to legal action.
>- **Serious:** This issue results in serious barriers for individuals with disabilities. Until a solution is implemented, some content will be inaccessible, or significant a work-around is required, making the organization vulnerable to legal action. Users with disabilities may experience significant frustration when attempting to access content.
>- **Moderate:** This issue results in some barriers for individuals with disabilities but would not prevent them from accessing fundamental elements or content. Users with disabilities may experience moderate frustration when encountering this issue.
>- **Minor:** This is an issue that may inconvenience a user but would not cause significant frustration in accessing content or accomplishing tasks. 

Source: 
https://gitlab.com/gitlab-org/gitlab-design/-/issues/1473#note_545158557, https://gitlab.com/gitlab-org/gitlab-design/-/issues/1473#note_545159441

~accessibility ~"Category:FE/UX Foundations"

Story points: 1.0