giseldo/neodataset huggingface dataset:
Illustration > Add more grid information

## Purpose

In https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2636 the product illustration guidelines were updated. Based on some feedback there could be more helpful guides specifically around the grid.

> A link to some resource would be helpful, or at least some examples of illustrations within this grid so it's easier to see what are the focal points and how elements should align to it. https://design.gitlab.com/product-foundations/illustration#focal-point-grid
> 
> This grid is specific to illustration, so I wouldn't assume all Product Designers know how to use it if they haven't had experience with graphic design or illustration.

Story points: 1.0
UI kit > Define & validate shadow style specs

## Problem

The current layer shadow style/specs in the UI kit ([modal example](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Component-library?node-id=4263%3A22)) don't align with what's in [Pajamas](https://design.gitlab.com/layout/layers#large). This issue is to determine the correct specs and where updates are needed.

[View branch in Figma →](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/branch/k1Qah0jN5geit4umN5uCYI/Component-library)

| **UI kit** (Note that both are combined into one shadow) | **Pajamas** |
| ------ | ------ |
| ![CleanShot_2021-12-09_at_07.24.28](/uploads/086b732ca504a3a7dd4cbb93b8db0d7c/CleanShot_2021-12-09_at_07.24.28.png)![CleanShot_2021-12-09_at_07.24.42](/uploads/4f937c1aa0f963cdfeea240c6897250f/CleanShot_2021-12-09_at_07.24.42.png) | ```box-shadow: 0px 0px 4px rgba(0, 0, 0, 0.16), 0px 4px 12px rgba(0, 0, 0, 0.16);``` |

## Solution

Consolidated list of styles based on components in production and in the UI kit

## Shadow styles

### Small shadow - {+new+}

| GitLab-ui | GitLab UI kit | Components | CSS |
| ------ | ------ | ------ | ------ | 
| $gl-shadow-sm | Small $gl-shadow-sm | Card | `box-shadow: 0px 1px 2px rgba(0, 0, 0, 0.1);` | 

### Medium shadow - {+new+}

| GitLab-ui | GitLab UI kit | Components | CSS |
| ------ | ------ | ------ | ------ | 
| $gl-shadow-md | Medium $gl-shadow-md | Date picker, Dropdown, Menus, Flyout Nav, Card `on_drag` | `box-shadow: 0px 2px 8px rgba(0, 0, 0, 0.16), 0px 0px 2px rgba(0, 0, 0, 0.16);` | 

### Large shadow

| GitLab-ui | GitLab UI kit | Components | CSS |
| ------ | ------ | ------ | ------ | 
| $gl-shadow-lg | Large $gl-shadow-lg | Modal, Drawer | `box-shadow: 0px 4px 12px rgba(0, 0, 0, 0.16), 0px 0px 4px rgba(0, 0, 0, 0.16);` | 



## Changes for this issue

### UI Kit

- [x] Add missing shadow layer styles (sm & md)
- [x] Update the shadow-sm to be more appropriate for the card on boards.

### Pajamas

- [ ] Update documentation to reflect new styles
- [ ] Update images to follow `visual example` patterns

## GitLab UI

### In https://gitlab.com/gitlab-org/gitlab-ui/-/issues/615

1. Document new shadow styles and audit existing styles
1. Add new shadow styles as utility classes
1. Update instances to use the new GitLab UI utility classes

```
Out of scope but worth mentioning; 

* gl-shadow-focus: focus states

This will remain unchanged in Gitlab-UI
```

Story points: 1.0
Follow-up from "feat(Illustration): Update docs with new guides"

The following discussion from !2636 should be addressed:

- [x] @tauriedavis started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2636#note_757943934):  (+4 comments)

    > **non-blocking:** The figma frame has a purple background which is a bit odd. Can that be updated to be like the one above where it's on the toggle? :thinking:

Story points: 1.0
Inline note layout broken

## Problem

Recently we updated the look of the inline todo, but the change has also been applied to the inline note, which has different design constraints.

| **Todo** | **Note** |
| ------ | ------ |
| ![CleanShot_2021-12-07_at_11.45.44_2x](/uploads/f874e675facdf617fd3af76a8ac2f9f7/CleanShot_2021-12-07_at_11.45.44_2x.png) | ![CleanShot_2021-12-07_at_10.39.50_2x](/uploads/ca65232993b8b6b48e571ca16200e9f8/CleanShot_2021-12-07_at_10.39.50_2x.png) |

## Solution

Use a different layout for an inline note. Ideally the note content could have normal vertical flow to support longer content.

Story points: 2.0
Update todo note style

## Purpose

Update the todo styles to be more streamlined.

- Take up less vertical space and overall reduce visual weight.
- Allow the "Create an issue" link to stand out.
- Use a simple document (note) icon to insinuate that this is a note.

| **Before** | **After** |
| ------ | ------ |
| ![image](/uploads/550ef72061fe4ae04abc28fdcd7eb572/image.png) | ![image](/uploads/bca4181ff38e7270376c01563e2aad4c/image.png) |

[View in Figma →](https://www.figma.com/file/0enu1LVbrKOuhTjLsbRsb0/%231182-todo-update?node-id=0%3A1)

Story points: 1.0
Live example SSoT

From a Foundations Open Office Hours agenda:

>Correct me if I’m wrong, but we still have to update Pajamas examples to match GitLab UI stories, right? As I’ve been working through the accessibility audits, my assumption is that any change to the component in GitLab UI will mean that updates have to happen in Pajamas too. Any ideas on being able to have one live example SSoT?

Generally at the moment I think just about everything could be affected since one version exists in Storybook in either example or CSF format, and there'd be an example in Pajamas.

Recent example since I was working on auditing breadcrumbs. The separator isn't the same…

| **GLUI** | **PJs** |
| ------ | ------ |
| ![CleanShot_2021-10-27_at_15.54.48_2x](/uploads/ccdb005c614ac4dbf359f7b5b5c6d35a/CleanShot_2021-10-27_at_15.54.48_2x.png) | ![CleanShot_2021-10-27_at_15.54.25_2x](/uploads/88545b4156f01065ba60ff3e1ef4f0fa/CleanShot_2021-10-27_at_15.54.25_2x.png) |

Tabs was even more confusing because there are both stories and examples in GitLab UI, and then examples in Pajamas. I've worked on aligning them, but changes had to be made in all three places.

Another hypothetical example might be where we update the markup in a modal CSF, but then have to update in Pajamas example to match.

Story points: 3.0
Illustration > Update docs with new guides

After https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1087 there should be sweeping changes to the [Illustration](https://design.gitlab.com/product-foundations/illustration) documentation to outline the new process and guidelines.

## Process

* [x] Update https://design.gitlab.com/product-foundations/illustration.
* [x] Ensure that related issue templates and project docs are current.
* [x] Communicate changes to the UX team.

Story points: 3.0
Figma > Update Figma for GitLab guide

With Figma updates and new features and workflows to leverage, it's time to update the [**Figma for GitLab**](https://www.figma.com/file/73OcYdBfOaK2xlChC3tbNX/Figma-for-GitLab?node-id=0%3A1) deck.

[View the WIP branch →](url)

Story points: 2.0
Update contribution resources to account for Objects

Update contributor guidelines, MR templates, component lifecycle, and others…

1. [x] https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2726 and https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2744 — Update [MR template](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/.gitlab/merge_request_templates/component-guideline.md) to be generic for any kind of documentation update, including objects, and update its links.
1. [x] https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2727 — Expand on [object overview](https://design.gitlab.com/objects/overview) page, moving generic content out from the individual object pages.
1. [x] [Figma branch (merged)](https://www.figma.com/file/J68bePHXIN5OPWqaFFY9ri/branch/5tlA0Ov1H7coIxFqihWytc/Conceptual-model?node-id=5823%3A553) — Add example page and legend to conceptual model file with stickies explaining components (object and lines). Add legend component to each object page in Figma.
1. [x] https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2769 — Embed [conceptual model example page](https://www.figma.com/file/J68bePHXIN5OPWqaFFY9ri/?node-id=5823%3A553) in the [objects overview page](https://design.gitlab.com/objects/overview/).

Story points: 1.0
Review and polish Figma conceptual model file for Objects

[🖼 Main Figma file](https://www.figma.com/file/J68bePHXIN5OPWqaFFY9ri/Conceptual-model)

- [x] Convert file cover to standard Pajamas cover
- [x] Add objects “folder” page
- [x] Add icons to help identify pages
- [x] Add Pajamas link at the top of each published object
- [x] [Create variants for object and line components](https://www.figma.com/file/J68bePHXIN5OPWqaFFY9ri/branch/qCgSr8rBqgrm0TCTuwCo4T/Conceptual-model)

Story points: 2.0
Add skip link to Pajamas site

## Purpose

The Pajamas website doesn't have a skip link to jump keyboard users to the main content area. This adds one so that as the first focusable item a keyboard user can have focus moved to `main`. This will also aid in being able to access in-page rendered examples quicker instead of tabbing through all of the navigation.

The pattern outlined in https://css-tricks.com/a-deep-dive-on-skipping-to-content/ will be the starting point.

Story points: 1.0
Create an Object issue template

## 🧩 Problem

We've started documenting objects in Pajamas (see the [MR object](https://design.gitlab.com/objects/merge-request)). Currently we don't have any contribution guidelines for documenting objects. For someone unfamiliar with the purpose and process of object modeling it can be intimidating and difficult to get started.

The conceptual object model becomes more useful as more objects and layouts are documented since it helps communicate the relationships between different objects. The more objects and layouts we document (even if the model is imperfect at first), the more we'll be able to use it. For example, it can help identify important object relationships and ensure we don't overlook them in our design work.

## 💡 Proposal

We don't need to create a perfect set of guidelines and templates to start benefiting from the documented model. The objective is to create an MVC set of guidelines and resources to get more product designers interested in contributing.

This issue will focus on adding an Object issue template to guide designers as they document the conceptual model and the layouts for the object.

Story points: 2.0
Date picker - make month/year look more interactive

# Problem

- The date picker has a dropdown for the month and year and nobody knows about it!
- Related to #601. From this thread: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/601#note_689319507

# Proposal

- Use a similar pattern to the sidebar - with a tertiary button that goes to `gray-50` on-hover to show interaction...

![Screenshot_2021-09-29_at_18.09.](/uploads/2b519167e5160104db6465cb57a7268f/Screenshot_2021-09-29_at_18.09..gif)

# Other ideas

![Screenshot_2021-09-29_at_11.57._2x](/uploads/597d379e81300df7b0db0159f688a232/Screenshot_2021-09-29_at_11.57._2x.png)

Story points: 1.0
Follow-up from "feat(Drawer): Update content to utilize new template"

The following discussion from !2546 should be addressed:

- [x] @tauriedavis started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2546#note_684885183):  (+1 comment)

    > - If supplemental content isn't suited for small areas or is part of a flow, consider loading a new page, revealing content with an [accordion](/components/accordion), or using a [modal](/components/modal) instead.
    >
    >> I'm hesitant to add modal here as an option for when supplemental content isn't suited for small areas. I wonder if there is additional info to add here about where a modal should be used in place of a drawer (such as the line below this one).

Story points: 1.0
Update Pajamas UI Kit contribution guidelines

## Purpose

As new features have been released in Figma, so too we've started using them and changed up a few workflows. The [**Pajamas UI Kit contribution and updating guidelines**](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/blob/main/doc/pajamas-ui-kit.md#building-components) document could use a thorough review along with updates.

/cc @mle @lvanc @nadia_sotnikova @cam.x @tauriedavis

Story points: 2.0
Pajamas UI Kit > Text input add-on component variable

## Purpose

Recently the [text input base](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Component-library?node-id=43905%3A45856) was updated to include prefix and suffix options while the add-ons remained unchanged. This issue addresses making the add-ons easier to change and update in a similar way.

![CleanShot_2021-09-14_at_13.40.09_2x](/uploads/42ee6804da0c816a098adda02d456ca1/CleanShot_2021-09-14_at_13.40.09_2x.png)

## Scope

Create a branch of the component library **❖ _Base Add-on** component with the following variants:

- Character count
- Clear button ([clear](https://gitlab-org.gitlab.io/gitlab-svgs/?q=~clear) icon) to clear entered content
- Show button ([eye](https://gitlab-org.gitlab.io/gitlab-svgs/?q=~eye) icon) for password visibility
- Hide button ([eye-slash](https://gitlab-org.gitlab.io/gitlab-svgs/?q=~eye-slash)) for obscuring password
- Calendar button ([calendar](https://gitlab-org.gitlab.io/gitlab-svgs/?q=~calendar) icon) for date picker

The character count can be present with the buttons, but only one button can be visible at a time.

**Additional changes:**

- The add-ons in the **❖ _Base Field** component will be replaced with the **❖ _Base Add-on** component.
- Currently the add-ons are set to true/false for the **Text input** component and will need to be changed to a dropdown to choose the type of add-on. The **Text area** component can remain as true/false as long as the character count is the only option.
- All component variants will need to be updated to look the same as they do today, only they will have the correct add-on chosen by default. This applies to everything in **Forms**, as well as **Datepicker** and **Dropdown**.

### Design file

Figma: https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/branch/5BKoo354GwPXInx3EsPDFa/Component-library?node-id=425%3A10 `1120-working-branch-veethikaa`

Story points: 3.0
Component template: Component structure image

This issue is to discuss adding multiple structure images and what state the component should be in for the structure image. Based on https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2520#note_671632056.

Two main questions:

1. What state of the component should be the structure image? For example:

| Beginning | All possible elements (Base component) |
| ------ | ------ |
| ![Screen_Shot_2021-09-14_at_10.35.12_AM](/uploads/5440df806d6010c37e7b7c6e7976faa7/Screen_Shot_2021-09-14_at_10.35.12_AM.png) | ![Screen_Shot_2021-09-14_at_10.35.18_AM](/uploads/b6745b7566efb4ffa2cd2548ee6d173d/Screen_Shot_2021-09-14_at_10.35.18_AM.png) |

Which should be the structure image? My assumption is to use the base component so we can describe each possible visible element. 

2. Should we include multiple structure images if there are different variants? For example:

| Single file uploader | Multi file uploader |
| ------ | ------ |
| ![Screen_Shot_2021-09-14_at_10.35.18_AM](/uploads/9e2089c97144d8f97abcf4d75babf39d/Screen_Shot_2021-09-14_at_10.35.18_AM.png) | ![Screen_Shot_2021-09-14_at_10.37.34_AM](/uploads/1d2c201ce6b8bbadb557d5ec17d76a97/Screen_Shot_2021-09-14_at_10.37.34_AM.png) | 

Again, my assumption is we include both, with unique lists for each. Thoughts?

Story points: 1.0
Frontmatter description doesn't render unless there are tabs

Currently, we are rendering `description:` at the top of the page, but **only** if the pages contains tabs. This description should always render, regardless of whether there are tabs or not. A lot of pages don't contain tabs, so we'll never be able to utilize the `description:` unless there is a vueComponent associated with that component. 

For example, we are creating an overview page that utilizes the `description:` item: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1105. We are also updating the docs pages to utilize a new doc template, which utilizes the `description:` item, so if the components without a Vue component get updated to the new template, those updates will be blocked until this is resolved.

Story points: 2.0
Avatar > Reverse stack order

## Problem

The current stacked order of avatars places the last item at the very bottom. Since this can be an interactive badge I think the order should be reversed. Also, the stacking order infers who was added when. If someone was added later, it makes sense that their avatar is set on top of the one before.

## Solution

Continue to order the avatars from left to right, but as they're ordered from left to right, they should stack from bottom to top. This allows the badge (if present) to be the most visible item and have the largest click target when interactive.

When DOM order and z-index is considered I believe this is a more natural presentation too.

| **Before** | **After** |
| ------ | ------ |
| ![image](/uploads/e60fd6ae73743e07cb44ce1cba703e73/image.png) | ![image](/uploads/ef0058de0952bbb0b830ae674ce611f5/image.png) |

[View proposal in Figma →](https://www.figma.com/file/hO6UAuOrF5Ca8ltX4rZUb9/Avatar-stack-order?node-id=2%3A844) (Note: this was a separate file and not a branch because it's only changing instances and not a component or styles.)

Story points: 1.0
Focus ring: Explore increasing contrast

## Purpose

As a result of the audit in the parent epic, the focus ring visual styles should be reviewed to consider the following:

- Increase focus ring contrast to at least 3:1 (currently 1.97:1).
- While I believe that there is no current failure because for [SC 2.4.7](https://www.w3.org/TR/WCAG21/#focus-visible) there is a visible focus ring, and for [SC 1.4.11](https://www.w3.org/TR/WCAG21/#non-text-contrast) the button text and/or icon has sufficient contrast, there are potential updates per the [WCAG 2.2 Working Draft](https://www.w3.org/TR/WCAG22/) that we could aim to satisfy now.
  - [Success Criterion 2.4.11 Focus Appearance (Minimum)](https://www.w3.org/TR/WCAG22/#focus-appearance-minimum)

**Watch recordings  of the audit** (internal)

[▶︎ Visual scan](https://drive.google.com/file/d/1qCB9-KfC1p-D7ao0QiwzQQMehERZZvUS/view?usp=sharing)

**Current contrast:**

![CleanShot_2021-08-16_at_14.45.10_2x](/uploads/97f299ffbc64bbb4b225e4d52978abfd/CleanShot_2021-08-16_at_14.45.10_2x.png)

(Contrast with opacity checked with [contrast-ratio.com](https://contrast-ratio.com/#rgb%2831%20117%20203%20%2F%2048%25%29-on-white).

## Resources

- https://www.sarasoueidan.com/blog/focus-indicators/
- https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html

Story points: 2.0
Elevate contribution to a tab

How can we increase and invite contribution to Pajamas in a "boring solution" kind of way?

Inspired by the **Discussion** tab in https://designsystem.gov.au/components/buttons/discussion/ (thanks @mle for tweeting about this site, it's awesome) I'm exploring a **Contribute** tab.

What would go in there?

- A bit of a text preamble with a link to the **Getting started > Contribute** page.
- We already have links in the footer to related issues and merge requests. It'd be worth repeating here when either are available.
- Occasional links to research efforts, polls, questionnaires, hackathons, etc. It'd be great to have some passive, evergreen items like that where someone could provide feedback.

What does this solve?

- Reenforcing that "everyone can contribute," while creating more visibility on how.
- What I especially liked about the Australian Government Design System example is how I felt invited into the conversation. It wasn't just one-way information. It also felt very transparent to reference discussion happening behind the scenes that you might normally not be privy to.

![CleanShot_2021-08-11_at_06.58.24_2x](/uploads/37a795f289176828260a08d1747814db/CleanShot_2021-08-11_at_06.58.24_2x.png)

Story points: 2.0
feat(markdown): Underline links in body content

## Purpose

At the moment, links in the markdown content are not underlined and have low contrast next to static text. This makes it more difficult to discern a link from surrounding text.

## Solution

A boring solution is simply to leverage the default `text-decoration: underline` for links within markdown. This is also proposed as an update to markdown in GitLab UI https://gitlab.com/gitlab-org/gitlab-ui/-/issues/1084, but this solution covers the gap until that is updated and Pajamas is using the markdown styles in documentation.

Story points: 1.0
FY22-Q3 KR3: Illustrate empty states for Access Tokens and Admin/Applications using new styles and assets

Use the new style library and assets to create illustrations for the following empty states:

- [x] https://gitlab.com/gitlab-org/gitlab-svgs/-/issues/196
- [x] https://gitlab.com/gitlab-org/gitlab-svgs/-/issues/195

Story points: 2.0
FY22-Q3 KR2: Create new illustration asset and style library

Create a new Figma file and build a foundation of styles and assets in alignment with brand illustrations that can be used to update documentation and support a redesign of product illustration.

Light and dark UI will be considered to determine if there's an efficient way to create illustrations that can also adapt to UI preference.

* [x] Create a new Figma file with library styles that consider light and dark UI ~~(with mapping between the two)~~.
* [x] Start creating reusable assets as components based on the audit in https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1086 and the resources created by the brand team. ~~Initial focus specifically on assets that will support https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/issues/1088.~~
* [x] ~~Create a POC to test CSS vars and classes within the illustrations that update based on light/dark UI settings.~~ Create a POC to test browser support for SVG with transparency and gauge the result on light/dark UI.

Story points: 5.0