giseldo/neodataset huggingface dataset:
A11y action > Add content to Forms > Placeholders

# Proposal

Add documentation to ` Forms > Placeholders` that describes the following:

> the intended use of placeholder text is for extra, non-essential information

# Background

>the intended use of placeholder text is for extra, non-essential information.
>
>>I like this little nugget and I think it’d be worth adding something similar in an update to https://design.gitlab.com/components/form#placeholders.

Source: https://gitlab.com/gitlab-org/gitlab-design/-/issues/1470#note_538076572

~accessibility ~"Category:FE/UX Foundations"

Story points: 1.0
A11y action > Inclusive design presentation

# Proposal

Create a presentation that addresses inclusive design and showcase it to the UX Department in order to increase awareness of biases.

@jeldergl is currently working on a presentation that would be a good fit to satisfy this.

# Background

>Some training on how to recognize bias in design would be helpful. In other words, evaluating design against our own bias and examine if we’re meeting the needs of more than just those like us — whatever that us may be.

Source: https://gitlab.com/gitlab-org/gitlab-design/-/issues/1463#note_499957432

~accessibility ~"Category:FE/UX Foundations

Story points: 4.0
Dig into whether or not the status table is accurate

As per discussion with Taurie: There is some concern that the [component status table](https://design.gitlab.com/components/status) isn't totally up-to-date. 

The goal for this issue would be to go through the [existing status table](https://design.gitlab.com/components/status) and dig into the `in progress` items to see if they can actually be moved to complete.

Story points: 3.0
Extend guidelines on labels

Discussion
---

[Labels](https://docs.gitlab.com/ee/user/project/labels.html) in GitLab have historically been tightly coupled with Issues, Epics, and Merge Requests ~"group::project management". There are other use cases (Compliance Frameworks or Topics) in GitLab where users are creating elements to categorize objects that would benefit from using [label](https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/base-label--default) the component.

> Scoped labels are a sub-type of labels, and their usage is determined by the user. A scoped label is differentiated from a regular label by the contrasting colors on the left and right sides of the label. - [Pajamas](https://design.gitlab.com/components/label/#usage)

Pajamas merely states that there is only a differentiation in the UI, but there is a unique feature tied to [exclusivity](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels) in scoped labels for project management. Compliance Frameworks are currently using scoped labels just for visual flair, although it is not possible to apply more than one Compliance Framework to a project today.

When considering the `scoped label` attribute, should this UI element always have exclusivity as a corresponding feature?

Story points: 1.0
Brand personality / Design principles table

In https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2345, we are removing outdated brand pages that are no longer shown in the sidebar. This includes the following table:

![brand personality table](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/uploads/5bdc8d3b977de19a7423bff75925c959/Screen_Shot_2021-04-20_at_11.18.20_AM.png)

Should we include this somewhere within our brand docs or possibly use it to better define our design principles?

Story points: 2.0
Collapse sidebar after navigation on mobile devices

The following discussion from !2301 should be addressed:

- [ ] @oregand started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2301#note_556227195):  (+3 comments)

    > @pgascouvaillancourt 
    > 
    > Great work on this, it looks super and feels great to use! I have left a selection of comments for you to check at your own time but your overall approach looks good to me here given the constraints you're working against with the keys && file boostrapping :smile: 
    > 
    > I was going to ask if we had supporting specs but see we don't have them in this repo yet :joy: 
    > 
    > One ~UX suggestion, we might want to auto close the sidebar on navigation from the search when we're on mobile but that's a non-blocking suggestion!
    > 
    > 
    > ![R1](/uploads/1cfa51f90106edd08012e080336d4043/R1.mov)

---

On mobile devices, the navigation sidebar can be expanded and overlaps the primary content. From there, clicking any link properly triggers navigation through `vue-router`, but the sidebar remains expanded, hiding the content that's being accessed.

Let's improve the ~UX by automatically collapsing the sidebar whenever navigation occurs.

Story points: 2.0
FY22-Q2 Foundations KR2: Create a maintained backlog of Pajamas issues that enables product designers and engineers to easily find issues and contribute => 79%

[FY22-Q2 UX Department: Foundations SubTeam OKR](https://gitlab.com/groups/gitlab-org/-/epics/5726)

Objective: Ensure Engineering is able to iteratively contribute to and utilize Pajamas for stage work deliverables

**KR2: Create a maintained backlog of Pajamas issues that enables product designers and engineers to easily find issues and contribute**

- [x] Ensure all issues within the Pajamas repo have a workflow label. See our [workflow label board](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/boards/1835632) 336/336 => 100%
- [ ] Ensure all issues within the Pajamas repo have a weight. See [issues without weights](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues?scope=all&state=opened&weight=None) 197/336 => 18%

533/672 => 79%

Story points: 13.0
Include GitLab UI utilities

The following discussion from !2300 should be addressed:

- [ ] @markrian started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2300#note_540028499):  (+2 comments)

    > **question (non-blocking)**: A quick grep suggests we don't use GitLab UI's utility classes in this repo. Should we?

Story points: 1.0
Badge > Linked badges > Make examples in Pajamas the SSoT

## Problem

Embedded badge examples in Pajamas are different from GitLab UI. Having a SSoT will help accurately complete the badge accessibility audit https://gitlab.com/groups/gitlab-org/-/epics/5664.

| **Pajamas** | **GitLab UI** |
| ------ | ------ |
| ![CleanShot_2021-03-22_at_15.10.48](/uploads/dce63a5d5d950da45aecb677b3cb1337/CleanShot_2021-03-22_at_15.10.48.gif) | ![CleanShot_2021-03-22_at_15.11.14](/uploads/a5429badcb1749274d21c7eb1b9e6db7/CleanShot_2021-03-22_at_15.11.14.gif) |

## Solution

Ensure badge examples align with the [badge design specs](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Component-library?node-id=425%3A3) and that action badges dont underline text on hover.

Story points: 2.0
Update guidelines around left menu items


- [x] Guidelines around what the menu items in the left sidebar
    - https://design.gitlab.com/regions/navigation#contextual-navigation
    - What should be a primary level item vs secondary
        - Updated: https://design.gitlab.com/regions/navigation#left-sidebar
    - ⛔️ Should "Labels" be allowed to jump between a submenu item to parent level? https://gitlab.com/gitlab-org/gitlab/-/issues/21147#note_525491995
        - We are putting Labels into `Project information` https://gitlab.com/gitlab-org/gitlab/-/issues/329905
- [x] Landing pages should be the first sub menu item
    - https://design.gitlab.com/regions/navigation#product-landing-pages


## Draft outline

### Parent item

### Submenu items

- Items in the submenu should help support navigation to the parent JTBD and supporting JTBD
- High level features of the category

Story points: 3.0
Document drag and drop updates in Pajamas [Drag & drop🤏]

Document any changes to drag & drop here to be merged into [Pajamas](https://design.gitlab.com/product-foundations/interaction#drag-and-drop).

#### :pushpin: Merge requests
- https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1941
- ....

#### :sparkles: Overall change highlights
- ...

Story points: 3.0
Guideline to open help links in new tab or not

In the [helping users](https://design.gitlab.com/usability/helping-users) section of the pajamas, we make use of two kinds of text links. While it's clear what the text should be, there's no guideline whether that link should open in a new tab or not.

We do however have some general guidelines about [external links](https://design.gitlab.com/product-foundations/interaction/#links-to-external-resources).

## More details

I personally am in favor of the new tab functionality, and this makes sense for GitLab.com where we now redirect all help links to the external site https://docs.gitlab.com.

For self-managed instances however, the help links still point to the `/help` page of the instance.

## Accessibility issues

Best practice for accessibility by default is to use native browser behavior and open in the same window.
Once `target="_blank"` is used it disables all other browser options, so it’s best to let the user choose.

## Resources

- https://css-tricks.com/use-target_blank/
- Docs guidelines on links https://docs.gitlab.com/ee/development/documentation/#linking-to-help

Story points: 1.0
Form: multi-column/row of grouped options in forms

### Background

This is an issue created based on [another issue](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues). Before we document something we agree on, we want to explore different solution options.

### Problem

In some areas, the user needs to set up complicated settings, such as variable sets with some details fine-tuning. Each variables settings is a group, and users need to see them together to have a better overview or comparing different variable groups.

The design needs to be flexible for desktop and mobile, easy to read and identify the groups.

| Example 1 | Example 2 |
| --------- | --------- |
|    ![Screenshot_2021-01-04_at_14.50.24](/uploads/a728ee6b2e7da9405b5acb2fd876f926/Screenshot_2021-01-04_at_14.50.24.png)          |       ![Screenshot_2021-01-04_at_14.50.33](/uploads/51b1af1081f717a44c8fb38650461dd9/Screenshot_2021-01-04_at_14.50.33.png) |



### Solution

| Option 1 - Row grouping | Option 2 - Column grouping | Option 3 -??? |
| --------- | --------- | -------- |
| ![row-based](/uploads/4d44b8f8fdcc9a8928a9edf439c05a8c/row-based.png) |  ![column-based](/uploads/b6c90c28d7446e7da1bbf03efdf9b2a9/column-based.png) |          |         
|           |           |          |

Story points: 3.0
Content section > Determine how to dedupe documentation with doc styleguide

# Problem

There are currently multiple places where we have content guidelines including:

* Pajamas: [Punctuation](https://design.gitlab.com/content/punctuation), [Terminology](https://design.gitlab.com/content/terminology), [Voice and tone](https://design.gitlab.com/content/voice-tone)
* Docs: [Styleguide](https://docs.gitlab.com/ee/development/documentation/styleguide.html)
* Handbook: [Styleguide](https://about.gitlab.com/handbook/style-guide/), [Markdown](https://about.gitlab.com/handbook/markdown-guide/)

There is repeated content in all of these sections, making it difficult to know when to go where for what.

We've started trying to harmonize this content between the different areas, which is resulting in content that is not DRY. For example, see https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26326 and https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2148.

Tech writing has started to look at both styleguides and align them here: https://gitlab.com/gitlab-org/gitlab-docs/-/issues/636. However, we need to determine the IA in order to ensure that we are not continuing to duplicate content over time.

# Solution

Determine how to dedupe content docs in all various locations. This could include:

- Moving all content docs to one area
    - Pros: Everything is in one place, you always know where to go to find what you need. Content isn't duplicated.
    - Cons: There are separate use cases for docs and product, so the documentation in this section could be expansive. Good IA would be needed so its easy to find details.
- Keeping documentation docs and product docs separate, with clear cross-linking as needed.
    - Pros: Separation of concerns could make it easier to find detailed docs as needed
    - Cons: A lot of content overlaps, so it may be difficult to fully dedupe and could mean lots of cross linking and jumping back and forth between sections.

Story points: 8.0
Move calendar icon in date picker

Per @cam.x’s great suggestion in https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/726#note_432971319, consider moving the calendar icon to the left of the date picker input.

**Benefits**

- Aligns with how the search input is handled.
- Provides more room on the right to use the clear × option.

![image](/uploads/bce5035304cede9416903d01a15cd98a/image.png)

/cc @gitlab-com/gitlab-ux/ux-foundations

Story points: 2.0
UX Foundations > Pajamas OKR exploration

During a recent conference, Design Systems & DesignOps, one of the self-work times was dedicated to thinking through what OKRs could look like for your design system. We were given about 40 minutes total to complete a list and then discuss in a small group. These were a few that came to mind, and I found it very helpful to think through objectives specific to the system itself.

Feel free to add your own, and perhaps we can have further exploration on a few of these. All of the below ramp up to a larger objective of making the product more beautiful, performant and accessible for users, while providing clear _foundational_ answers to common questions so that designers can focus on designing and not on rehashing what should be “boring” decisions. A reoccurring phrase from the workshop was “align the easy thing to do with the right thing to do,” which I think aligns with our goal of building foundational things for the team to build on.

Story points: 1.0
Dropdown component - Standardising on how to clear selection

## Problem

- From this discussion: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/43050#note_422606858
- There doesn't seem to be a standard way to clear the selection from a dropdown
- For example, in Value Stream Management, the following approach was used...

![Screenshot_2020-10-07_at_17.19._2x](/uploads/36fa40470131e174987d120cdc6adbd6/Screenshot_2020-10-07_at_17.19._2x.png)

## Proposal

Standardise on a solution for clearing the selection from a dropdown:
1. Document approach
1. Add functionality at the component-level

There are a few ways of going about it...

### When dropdown is open, the Action area for "clear selection"

| Single selection | Multi selection  |
| ------ | ------ |
| ![Screenshot_2020-10-20_at_17.32.16](/uploads/98bc3e80752a4122a9b52da599e49858/Screenshot_2020-10-20_at_17.32.16.png) | ![Screenshot_2020-10-20_at_17.32.22](/uploads/3a098f79146668b7725ab9ca41816add/Screenshot_2020-10-20_at_17.32.22.png)  |


### after dropdown closes, the action to "clear selection"
| Single selection | Multi selection  |
| ------ | ------ |
|![Screenshot_2020-10-20_at_17.33.39](/uploads/fcb45fe546a501bf957ff3d6315e3c45/Screenshot_2020-10-20_at_17.33.39.png)| ![Screenshot_2020-10-20_at_17.33.32](/uploads/36b6ddccb9e24009006f1956f17001ed/Screenshot_2020-10-20_at_17.33.32.png)|


<details><summary>Original proposal</summary>
<p>
| Dropdown open clear button | Dropdown closed clear button | Top-level selection clears |
| ------ | ------ | ------ |
| ![image](/uploads/ffe35399c9aeb1e710824e1d39067174/image.png) | ![Screenshot_2020-10-07_at_17.26._2x](/uploads/691adaf0219b08ea608bef2961dd6169/Screenshot_2020-10-07_at_17.26._2x.png) | ![Screenshot_2020-10-07_at_17.19._2x](/uploads/36fa40470131e174987d120cdc6adbd6/Screenshot_2020-10-07_at_17.19._2x.png) |
</p>
</details>
@gitlab-com/gitlab-ux/designers

Story points: 3.0
Mini progress/gauge indicator

# Problem

- Current use case: We need to visualise the progress of adoption of individual GitLab stages side-by-side
- General challenge: visualising progress as a percentage or within some target bounds

# Solution

- [Figma file →](https://www.figma.com/file/M04p4bPdJSRLJJxZ8DhgmA/Mini-gauge?node-id=785%3A161)
- Create a mini gauge chart that can fit within tables or metric boxes
- Need to be able to look good side-by-side

![Screenshot_2020-10-02_at_14.36._2x](/uploads/f30b7c854fb12840226f088b01237124/Screenshot_2020-10-02_at_14.36._2x.png)

# MVC iterations

1. Implement mini gauge variant with icon (no bounds)
1. Implement mini gauge variant with metric (no bounds)
1. Implement mini gauge variant with target bounds

Story points: 3.0
Make responsive segmented control

### Problem

Currently our [segmented control component](https://design.gitlab.com/components/segmented-control) isn't very responsive on small screens when the component has many options (see below screenshot).

![Screen_Shot_2020-08-31_at_9.31.20_AM](/uploads/00c01eef0681be6929cf16273669643d/Screen_Shot_2020-08-31_at_9.31.20_AM.png)

We don't have a current design for how to fix this.

### Proposal

Some possible solutions:

- [Vertical variation for button groups](https://bootstrap-vue.org/docs/components/button-group#vertical-variation)
- Wrapping the component
- Making the last button a dropdown with the extra options inside of it.
  - ![image](/uploads/faa949ce468effb51625e6c4b2046839/image.png)

Story points: 3.0
KR: Improve the component checklist by adding links/references to the necessary steps to complete the lifecycle, and move it to the Pajamas project. => 0%, TBD

Related to [Clarify the Pajamas component lifecycle process](https://gitlab.com/groups/gitlab-org/gitlab-services/-/epics/1)

Key Result: Improve the component checklist by adding links/references to the necessary steps to complete the lifecycle, and move it to the Pajamas project.

Story points: 1.0
Make mermaid diagrams work in Pajamas

This is a Follow-up from "Draft: docs(contribute): Move component lifecycle up" https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2053/

Currently, Pajamas does not render mermaid diagrams in markdown pages. 

Mermaid diagrams render as *code blocks* in markdown files. This is a useful tool for generation of diagrams and flowcharts from text, instead of using static images in the design docs pages.

See https://docs.gitlab.com/ee/user/markdown.html#mermaid

Story points: 5.0
Pajamas pages break if a Vue component doesn't exist in component_documentation.js

Recently, the dropdowns page was broken due to `GlNewDropdown` no longer existing under [`component_documentation.js`](https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1637/diffs#d836144972fdb1c81b2724a1b894dec15e0973f4_62_62), which Pajamas pulls from when checking if a vue component conforms to the design system [`followsDesignSystem`](components/componentinfo.vue).

MR that fixed the broken page: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2050

Story points: 1.0
Document established onboarding & educational patterns: nudge

Document the findings and learnings from the [suggest a pipeline experiment](https://gitlab.com/groups/gitlab-org/growth/-/epics/14). Based on these learnings, establish a pattern for onboarding and educational purposes, so that other designers can reuse it. 

By the time I'll start working on documenting these we'll have run numerous variations of this experiment: different initial nudges, different copy. 

Include details about:

* reference the FOGG behaviour model
* components that can be used
* variations of initial nudges and recommendations on when they should be used
* recommendations on the number of steps
* recommendations for writing copy and providing context (why the nudge is shown, what value will the user get from it)
* should only be done to benefit the user

Story points: 5.0
Update empty state documentation to include details about existing controls

As part of discussion on https://gitlab.com/gitlab-org/gitlab/-/issues/229636#note_382613266 and https://gitlab.com/gitlab-org/gitlab/-/issues/229350, we realized that we could use a little clarification in our empty state documentation.

When we have an empty state, should the page controls still appear, but be disabled? Or, should they be completely hidden? 

We currently have both situations in our empty states. Should we clarify when the controls appear, and why?

Story points: 2.0
Dropdowns > Audit Figma and GitLab UI component

Review dropdowns in Figma and GitLab UI to ensure parity

If issues are found, create issues and mark them as blockers to this issue.

- [ ] All variations exist in Figma and GitLab UI
- [ ] Styling in Figma matches GitLab UI
- [ ] All related issues are closed
- [ ] Status table in Pajamas is updated and accurate

Story points: 3.0
Mobile layout has double padding on left/right

From https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1963#note_359198356

`content` adds left/right padding which was getting doubled, so narrow screens have extra padding

We can probably move the `.content.limited` rule to `.limited` to fix this

![Screen_Shot_2020-06-12_at_5.56.02_pm](/uploads/52aaa87a4672e49bd04450409d7a163a/Screen_Shot_2020-06-12_at_5.56.02_pm.png)

Story points: 1.0
feat(filters): Research scroll behavior for filters

In https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1343 @matejlatin highlighted filters issue with scrollbar on OS X:

![image](/uploads/246b9e8c379b487c85e038913c079004/image.png)

pretty acceptable in Linux & Windows with other scroll type:

![image](/uploads/ce44e00e23f0d4428fa0f64df34f2e89/image.png)

We need to research the proper way of handling a lot of scrollable content in filters.

Story points: 3.0
Add additional chart information to to PJs

### Description

PJs doesn't include all chart options available from within gitlab-ui.

#### Examples

https://design.gitlab.com/components/charts#types only mentions column charts, line charts, and area charts.

In addition to these, we also have:

* Scatter chart
  * https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/charts-discrete-scatter-chart--default
* Heatmap
  * https://gitlab-org.gitlab.io/gitlab-ui/?path=/story/charts-heatmap--default

Column charts also support a click interaction - I don't actually think that this is explicitly mentioned in gitlab-ui either.

#### Additional information
This was raised in discussion over here https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541#note_333095362

Story points: 4.0
Add contrast info to neutral color palette

The following discussion from !1787 should be addressed:

- [x] @pedroms started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1787#note_322602636):  (+2 comments)

    > @jeldergl should we also add the `Passing level and contrast ratio` information to the neutral palette?

Story points: 1.0
Communicating code coverage of each component

In https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/1804, the status of components that already live inside the GitLab product were moved to `Integrated`. 

I'm curious to hear what would be helpful on the status page. A lot of questions I get are related to why a component in production does not match Pajamas. Even if a component already lives in the product, that does not mean they are fully integrated or used in every instance. How should we be communicating the code coverage of each component? Should that live inside the status page? How can we feasible track this over time?

Story points: 5.0