giseldo/neodataset huggingface dataset:
FY22-Q3 KR1: Audit current empty state illustrations

Audit all empty state illustrations to determine what elements are repeatable and where there are opportunities to empower designers to create their own unique empty state illustrations that are based on a library of reusable assets.

* [x] Audit all empty states in https://gitlab-org.gitlab.io/gitlab-svgs/illustrations (can also be referenced from Figma in https://www.figma.com/file/0DhXXlTakscLiHZLKuiJ6C/Illustration-library).
* [x] Create a list of repeating themes, sizes, and elements that could be leveraged to create an illustration library.

---

## Proposed state

* Use a common grid to layout the illustration — one for large and one for medium (no small identified as empty states in the current illustration library).
* Have a consistent focal-point. Leverage the grid and some keylines to help with object placement.
* Use a consistent color palette for the focal-point element(s).
* Establish guides on when to create a more custom illustration, and when to leverage something that's multi-purpose or more generic. For example, a more custom illustration could be created with a combination of new and existing assets for a new feature or one that isn't enabled, while an empty data state or configuration needed could always use the same asset.

### Repeating themes

- New feature
- Upgrade
- Not configured
- No data

## Sizes

- Large
- Medium
- Small (new)

## Elements

* Ellipses to contain icons or graphics.
* Dashed connectors to establish relationships.
* Shapes to represent placeholder content.
* Small reusable illustrations. For example, to consistently represent no data or needs configuration.
* More TBD after starting to build this out.

Story points: 3.0
GFM Typescale > Audio > design

## Task
Create Figma specs for the GitLab Flavored Markdown audio component. See parent epic for detailed information about this component.


## [Figma branch (Audio)](https://www.figma.com/file/V3HKN83B7rf2T6sseLMrxa/Type-scale---Documentation-Markdown?node-id=1097%3A10)
![Documentation](/uploads/0bda3b5a88fa7e256a5523fcc954ae7e/Documentation.png)

Story points: 1.0
GFM Typescale > Inline diff > design

Create Figma specs for the GitLab Flavored Markdown inline diff component. 

See parent epic for detailed information about this component.

Figma files:

- [Documentation markdown - Inline diff](https://www.figma.com/file/V3HKN83B7rf2T6sseLMrxa/Type-scale---Documentation-Markdown?node-id=988%3A10)
- [Compact markdown - Inline diff](https://www.figma.com/file/mjAZxHkK95TlQ6L14aNp2M/Type-scale---Compact-Markdown?node-id=893%3A4)

Story points: 1.0
GFM Typescale > Code block > design

Create Figma specs for the GitLab Flavored Markdown code block component.

See parent epic for detailed information about this component.

Figma assets:

- [Documentation markdown - Code block](https://www.figma.com/file/V3HKN83B7rf2T6sseLMrxa/Type-scale---Documentation-Markdown?node-id=985%3A10)
- [Compact markdown - Code block](https://www.figma.com/file/mjAZxHkK95TlQ6L14aNp2M/Type-scale---Compact-Markdown?node-id=890%3A8)

Story points: 1.0
GFM Typescale > Image > design

Create Figma specs for the GitLab Flavored Markdown image component.

See parent epic for detailed information about this component.

- :pencil2: [Figma branch - Documentation markdown](https://www.figma.com/file/V3HKN83B7rf2T6sseLMrxa/branch/gI2szSJVfByu9N0Etzucr0/Type-scale---Documentation-Markdown?node-id=974%3A10)
- :pencil2: Figma branch - Compact markdown - TBD

Story points: 1.0
Fix sidebar collapse when section has a collapsable sub-section

The following discussion from !2469 should be addressed:

- [ ] @jeldergl started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2469#note_633217411):  (+1 comment)

    > @tauriedavis something seems to be broken with this extra nested level. It's always open and looks active by default, even when navigating to other pages. Closing it closes the parent too. I haven't been able to dig into this further, but it makes me wonder if something with the JS has to get updated.
    > 
    > ![CleanShot_2021-07-22_at_08.06.31](/uploads/88b404ed7ab0554f1e081159b338ab41/CleanShot_2021-07-22_at_08.06.31.gif)

Story points: 2.0
GFM Typescale > Blockquote > design

Create Figma specs for the GitLab Flavored Markdown blockquote component. 

See parent epic for detailed information about this component.

### Proposal

| Compact (current) | Compact (New) |
| ------ | ------ |
| ![Screen_Shot_2022-04-25_at_09.13.25](/uploads/21ff653feded81ff89bb895ab230b107/Screen_Shot_2022-04-25_at_09.13.25.png) | ![Blockquote-compact-md](/uploads/0b2321770d18641b42fc914459cafd8b/Blockquote-compact-md.png) |

| Documentation (current) | Documentation (New) |
| ------ | ------ |
| ![Screen_Shot_2022-04-25_at_09.12.21](/uploads/bf3713fb90309cd3905cdb6b2ee36040/Screen_Shot_2022-04-25_at_09.12.21.png) | ![Blockquote-doc-md](/uploads/9d8293214f4d4f2eba1c03ff10190ed9/Blockquote-doc-md.png) |


**Summary of changes:**
- Left border: `4px` `$gray-100`
- Text: `$gray-700`
- See reasons for color updates: https://gitlab.com/gitlab-org/gitlab/-/issues/231405/

### Design source
- :pencil2: [Figma - Documentation markdown](https://www.figma.com/file/V3HKN83B7rf2T6sseLMrxa/branch/eMkpaCMX6MS4JsZhgRB23O/Type-scale---Documentation-Markdown?node-id=1843%3A373)
- :pencil2: [Figma - Compact markdown](https://www.figma.com/file/mjAZxHkK95TlQ6L14aNp2M/branch/ygOLNsF7gZZlJKrrOzaGlu/Type-scale---Compact-Markdown?node-id=1657%3A170)
- :pencil2: [Figma - Component library](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Component-library?node-id=33967%3A28794)

Story points: 1.0
GFM Typescale > Table > design

Create Figma specs for the GitLab Flavored Markdown table component. 

See parent epic for detailed information about this component.

- :pencil2: [Figma branch - Documentation markdown](https://www.figma.com/file/V3HKN83B7rf2T6sseLMrxa/branch/vO1Ef5cah3JWGlJKq9XvGw/Type-scale---Documentation-Markdown?node-id=1174%3A11)
- :pencil2: [Figma branch - Compact markdown](https://www.figma.com/file/mjAZxHkK95TlQ6L14aNp2M/branch/F0ml9uXBQGWz0Jg5YVjY90/Type-scale---Compact-Markdown?node-id=1554%3A78)

### Summary of changes
- Removed all vertical borders
- Removed thicker border between header and body row
- Changed cell text color from `$gray-900` :arrow_right: `$gray-700`
- Changed vertical text alignment from `middle` :arrow_right: `top`
- All inner cell content for both header and body cells has a consistent padding of `8px` L/R and `12px` T/B 
- Added alternating rows by default

Story points: 1.0
FY22-Q3 Foundations KR1.5: Identify whether there are additional empty state types that need to be added

- [x] After reviewing the [four empty state types](https://gitlab.com/groups/gitlab-org/-/epics/6413), identify whether there are additional empty state types that need to be added
    - [x] If yes, identify problem statements to test during the validation phase

Story points: 2.0
FY22-Q3 Foundations KR1.4: Review "empty search results" empty state

Within our empty state documentation, we've identified [four types of empty states](https://design.gitlab.com/regions/empty-states#when-to-use-an-empty-state). In this issue, we will review the `empty search results` empty state.

Empty search results: Display empty search results.

- [x] Find 2-3 existing examples of the `empty search results` empty state in the product
- [x] Determine if this type of empty state is a valid use case for the empty state region
- [x] Identify areas of possible improvement by writing problem statements to test during problem validation

Story points: 1.0
FY22-Q3 Foundations KR1.3: Review "error state" empty state

Within our empty state documentation, we've identified [four types of empty states](https://design.gitlab.com/regions/empty-states#when-to-use-an-empty-state). In this issue, we will review the `error state` empty state.

Error state: Convey an error state, which will depend on the nature of the error and should be used judiciously. An example of this would be a server response error, that is, 404 or 500.

- [x] Find 2-3 existing examples of the `error state` empty state in the product
- [x] Determine if this type of empty state is a valid use case for the empty state region
- [x] Identify areas of possible improvement by writing problem statements to test during problem validation

# Outcome


We will want to remove this from empty state guidelines, as it is not a valid use case. Errors are separate and can be handled with anything from an alert to 404 to form validation

Story points: 1.0
FY22-Q3 Foundations KR1.2: Review "blank content" empty state

Within our empty state documentation, we've identified [four types of empty states](https://design.gitlab.com/regions/empty-states#when-to-use-an-empty-state). In this issue, we will review the `blank content` empty state.

Blank content: Act as a placeholder for regions in the app left blank intentionally.

- [x] Find 2-3 existing examples of the `blank content` empty state in the product
- [x] Determine if this type of empty state is a valid use case for the empty state region
- [x] Identify areas of possible improvement by writing problem statements to test during problem validation

Story points: 1.0
FY22-Q3 Foundations KR1.1: Review "unused feature" empty state

Within our empty state documentation, we've identified [four types of empty states](https://design.gitlab.com/regions/empty-states#when-to-use-an-empty-state). In this issue, we will review the `unused feature` empty state.

Unused feature: Make users aware that a feature is not configured for use.

- [x] Find 2-3 existing examples of the `unused feature` empty state in the product
- [x] Determine if this type of empty state is a valid use case for the empty state region
- [x] Identify areas of possible improvement by writing problem statements to test during problem validation

Proposals:

* Update category name to `Configuration required`.

Story points: 1.0
FY22-Q3 Foundations KR2: Perform problem validation where necessary to understand existing limitations, creating recommendations and performing solution validation to confirm assumptions

[FY22-Q3 UX Department: Foundations SubTeam OKR](https://gitlab.com/groups/gitlab-org/-/epics/6412)

Objective: Improve learnability of features by researching and providing recommendations for improved empty states with a focus on user on-boarding

**KR3: Perform problem validation where necessary to understand existing limitations, creating recommendations and performing solution validation to confirm assumptions**

- [ ] Using the problem statements from the [first KR](https://gitlab.com/groups/gitlab-org/-/epics/6413), perform problem validation to address assumptions
- [ ] Generate recommendations based on research
- [ ] Perform solution validation as needed

Ally: https://app.ally.io/objectives/1453437?time_period_id=135090

Story points: 3.0
FY22-Q3 Foundations KR3: Update empty state usage guidelines/design specs using what we've learned from research

[FY22-Q3 UX Department: Foundations SubTeam OKR](https://gitlab.com/groups/gitlab-org/-/epics/6412)

Objective: Improve learnability of features by researching and providing recommendations for improved empty states with a focus on user on-boarding

**KR3: Update empty state usage guidelines/design specs using what we've learned from research**

- [x] Update [empty state guidelines](https://design.gitlab.com/regions/empty-states) in Pajamas
- [ ] ~~Update design specs in the [Figma UI Kit](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Pajamas-UI-Kit)~~
- [x] Review [existing empty state issues](https://gitlab.com/groups/gitlab-org/-/epics?scope=all&search=empty+state&state=opened) and close any that are no longer relevant

Ally: https://app.ally.io/objectives/1453438?time_period_id=135090

Story points: 3.0
Button > Explore documentation hierarchy

## Purpose

When working through some Pajamas research related to https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/541, I noticed that the concept of button categories and variants was confusing for users. I still mull it over from time to time too. I’m wondering if perhaps we could reconsider the hierarchy of information here to simplify it? 

| **Current** | **Proposed** |
| ------ | ------ |
| **Category:**<br>- Primary<br>- Secondary<br>- Tertiary<br><br>**Variants:**<br>- Confirm<br>- Default<br>- Dashed<br>- Danger<br>- Link | **Variants:**<br>- Confirm<br>&nbsp;  - Primary<br>&nbsp;  - Secondary<br>&nbsp;  - Tertiary<br>- Default<br>&nbsp;  - _Same pattern as Confirm_<br>- … |

This would focus on the variants, and then the options for each variant. I think doing away with the category content as-is would be helpful. We can still identify primary, secondary, and tertiary actions, but secondary to variant. We could always take naming further, but a change like this doesn't require component changes as far as I can tell, just how it's presented.

Story points: 3.0
GFM Typescale > Code span > design

Create Figma specs for the GitLab Flavored Markdown code span component. 

See parent epic for detailed information about this component.

- [Documentation markdown - Code span](https://www.figma.com/file/V3HKN83B7rf2T6sseLMrxa/Type-scale---Documentation-Markdown?node-id=909%3A10)
- [Compact markdown - Code span](https://www.figma.com/file/mjAZxHkK95TlQ6L14aNp2M/Type-scale---Compact-Markdown?node-id=862%3A4)

Story points: 1.0
Add Pajamas Playground to documentation

### Problem

While the Pajamas documentation provides extensive examples and code snippets for our components, there is currently no easy way to try our design system without installing GDK or creating a GitPod instance.

### Proposal 

This issue proposes adding a Pajamas Playground to our documentation (potentially as a simple iframe), to remedy this gap and enable designers & developers to:

- Quickly try component code directly in the browser
- Test different component props and combinations
- Easily collaborate and generate code snippets for other developers

**Question for the Foundations Team**: Do you see this as something useful and worth integrating into the docs?

You can see a working proof of concept at https://dfosco.gitlab.io/pajamas-playground

![image](/uploads/34e863f638e349383893a28330476fe3/image.png)

### Possible Next steps

The proof of concept above is a very rough prototype, and it can likely break very easily. Possible next steps to integrate this as an official part of our tooling include:

- Embed playground in a dedicated page of Pajamas docs
- Update code to dynamically import the latest version of _every_ Pajamas component (including new ones)
- Add sharing button to append current code to URL -- see [example on Auth0 docs](https://auth0-cosmos.vercel.app/#/playground)
- General cleanup of the code to meet team standards and reliability

Story points: 2.0
Pajamas > Move contributing content

## Problem

- Recently the **Component lifecycle** content was updated, but it still remains the last item in the menu and could be elevated for more visibility.
- Under the **Contribute** menu heading there is a **Get started** page, but there is already a **Get started** navigation heading above.

## Solution

- Move the **Component lifecycle** page under the top **Get started** menu heading.
- Move the **Get started** page under the top **Get started** menu heading and rename the page to "Contribute."
- Remove the **Contribute** menu heading.
- Update any Pajamas links to point to the new pages.

![CleanShot_2021-07-15_at_15.51.59_2x](/uploads/e9501d2bc4269ee76a96fe9ac64cb55b/CleanShot_2021-07-15_at_15.51.59_2x.png)

Story points: 2.0
Regions > Add merge request reports

## Purpose

Add [merge request reports](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Component-library?node-id=38197%3A204050) to the **Regions** section of Pajamas. The initial content will come from the [Figma file](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Component-library?node-id=38197%3A204050). This is in preparation of the implementation phase for the MR widgets and having the SSoT in Pajamas.

Story points: 2.0
Follow-up from "feat(Color): Add color theme notes"

The following discussion from !2460 should be addressed:

- [ ] @jeldergl started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2460#note_625218336):  (+6 comments)

    > Note: these changes (and others like it) were brought about by the lint job that runs during a commit.

---

The changes in question was the removal of indentation for HTML within a markdown file. The indentation helps with nesting and understanding the code. Removing it makes the markup harder to read and understand.

Story points: 1.0
Update component markdown template

### Description

Update the [example component documentation page template](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/pages/components/template.md) after https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2414 has been merged to reflect template updates.

### Checklist

Make sure the following are completed before closing the issue:

1. [x] Assign the correct component label to this issue.
1. [x] Create an MR with the additions or updates needed.
1. [-] When applicable, [create a new Pajamas issue using the "Figma update" issue template][pajamas-figma-update-template] to update the component in Figma. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [-] When applicable, [create an MR in GitLab UI][gitlab-ui-mr] to update the component. If you do not have capacity or are unable to update the component directly, [create a new GitLab UI issue using the "Component"][gitlab-ui-component-template] issue template. Bring the issue to your team planning session for prioritization and scheduling. Mark the issue as related to this one.
1. [x] When introducing a major or breaking change, communicate the changes within the Engineering Week in Review and UX Weekly meeting.
1. [x] 🎉 Congrats, you made it! You can now close this issue.

<!-- 
### Resources

* [Compontent Lifecycle][component-lifecycle]
-->

[gitlab-ui-mr]: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/new
[component-lifecycle]: https://design.gitlab.com/contribute/lifecycle
[pajamas-figma-update-template]: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/new?issuable_template=Figma%20update
[gitlab-ui-component-template]: https://gitlab.com/gitlab-org/gitlab-ui/-/issues/new?issuable_template=Component

Story points: 1.0
Add bot warning for workflow label and weight

## Purpose

In https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/850 the UX Foundations team is working on adding workflow labels and weights to each issue. When a new issue is created there's no way for the author to know that a workflow label and weight should be added.

The proposal is to have a bot notify the author to add the workflow label or weight, or to automatically add a label.

---

Message:

```
Hi @[AUTHOR],

Please add a [workflow label](https://about.gitlab.com/handbook/product-development-flow/) and [weight](https://about.gitlab.com/handbook/engineering/ux/ux-designer/#ux-weight-definitions) to your issue. This helps to categorize and locate issues in the future.

Thanks for your help! :heart: 

---

You are welcome to help [improve this comment](LINK).
```

Story points: 2.0
Evaluate VPAT against GitLab v14.0

## Purpose

In https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2434 we're updating the VPAT version to note that no material changes happened between 13.5 (date of current report) and 14.0. [More context](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1031)

This effort evaluates 14.0 against the current VPAT report, makes any updates, and updates the version and report date in the VPAT.

Story points: 2.0
Pajamas competitor analysis

This issue is to discuss the possibility for doing competitor analysis for Pajamas. I think it will be valuable to do a lightweight version of the UX competitor analysis to gain insight into how we can continue to improve Pajamas, by taking a look at some other design systems. 

I think we have the opportunity to do something from scratch, I have heard from multiple designers that the current competitor analysis in UX is too in depth, perhaps we look at developing our own from scratch that's much simpler. 

- [ ] Determine whether doing a competitor analysis is useful 
  - [ ] Determine how a formal competitor analysis will be structured

Story points: 1.0
Where should research insights live that impacts Pajamas?

## Purpose

In a recent 1:1 I brought up the idea of using the wiki feature in the Pajamas project to house research insights and more conversational reasoning behind decisions that impact components. From each component page we could link to the relevant section of the wiki.

This brought up the need to address a few questions at a higher level before solutioning:

- Where should research live and how should it be incorporated into Pajamas (if at all)?
- Is there still an insights repo that could be linked to?

Currently, in https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2414 as part of the component page template update a new "Reference" section is being added with the intent to add links and commentary.

The component page documentation should be direct, and we don't want to add to the overhead by having research links throughout that might be private or change. So where could we have a SSoT and how should we reference it?

Story points: 1.0
Tree > 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 tree 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
Tooltip > 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 tooltip 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
Token > 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 token 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