giseldo/neodataset huggingface dataset:
UX Merge Request Coach

How can we incorporate UX MR coaches into the current process, especially for repos like Pajamas and gitlab-ui? [See Merge Request Coach page](https://about.gitlab.com/job-families/expert/merge-request-coach/) 

The following discussion from https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/26512 should be addressed:

- [ ] @rverissimo started a [discussion](https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/26512#note_195850582):  (+2 comments)

    > I'm not totally sure if this is applicable to designers, but I decided to keep it as it shows in the engineering page. Could you please review and give feedback?

Story points: 2.0
Follow-up from "Update contents/components/tables.md"

The following discussion from !1444 should be addressed:

- [ ] @matejlatin started a [discussion](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/merge_requests/1444#note_192402923):  (+4 comments)

    > Should we also suggest using the lining tabular figures when the tables are numbers-heavy?
    > 
    > ![image](/uploads/864311111597cdb51fd3c23c139d3e35/image.png)
    > 
    > I know that the SF font supports them as an OpenType feature, not sure about Segoe UI though :thinking:

Story points: 1.0
Add 10 Usability Heuristics for User Interface Design to the Usability menu for the design documentation

### Problem

With https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/1448#note_187568144 we'll be adding error prevention to the usability menu, one of the 10 usability heuristics from NNgroup: https://www.nngroup.com/articles/ten-usability-heuristics/

We already have a few others as well. 

### Proposal

This issue is to discover which other heuristics we can add and what duplicate content we might already have existing in other places.

Story points: 2.0
Add compact empty state region component variant

### Problem

Following the discussion in https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/14349#note_184643601 and the need in https://gitlab.com/gitlab-org/gitlab-ce/issues/57086#note_181276839, a new component variant is about to be introduced in https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/592 for **compact empty state**.

### Proposal

Let's add some design documentation about this new component variant in Pajamas.

Story points: 2.0
Delete old review apps host

Once AutoDevops is enabled (https://gitlab.com/gitlab-org/design.gitlab.com/issues/96) and all MRs are rebased, we should go and delete the old host?

The following discussion from !1216 should be addressed:

- [ ] @leipert started a [discussion](https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/1216#note_182856734): 

    > Once Auto-Devops is enabled and MRs are rebased we probably should go and delete the current host we have set up for review apps.

Story points: 1.0
Create nice error pages for design.gitlab.com

With https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/1437 we are going to have a nice nginx container for auto-devops. Ths container could serve custom 40x and 50x error pages. Let's create them!


The following discussion from !1437 should be addressed:

- [ ] @leipert started a [discussion](https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/1437#note_181880339):  (+1 comment)

    > @DylanGriffith I am not too familiar with AutoDevOps (shame on me). The built nginx image is run at the end, right? Because if so, we could create a follow-up issue to also provide a nice 40x error template (additionally to the 40x one)

Story points: 2.0
Add paginated list component

### Problem 

Following the need in https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/1183 to facilitate paginated lists with less than 20 items which derived from the discussion in https://gitlab.com/gitlab-org/gitlab-ee/issues/10059, a new component is about to be introduced in https://gitlab.com/gitlab-org/gitlab-ui/merge_requests/350 for **paginated lists**.

### Proposal

Let's add some design documentation about this new component in Pajamas.

This could be added as a) separate component for now or b) variation of the [lists](https://design.gitlab.com/components/lists) component while this could easily become the basis of a [data tables](https://design.gitlab.com/components/data-tables) component in the near future.

Story points: 3.0
Create, Build, and Style > Banners

This issue is to complete the ~"pajamas::create", ~"pajamas::build", ~"pajamas::style" portion of ~"component::banners" as part of FY20-Q2 OKR to Improve the quality and consistency of our UI.

This includes a single-source-of-truth component that is implemented in Vue and thoroughly documented on design.gitlab.com. This does not include implementing the component throughout the product.

Related epics:
*  [Components of Pajamas Design System](https://gitlab.com/groups/gitlab-org/-/epics/973)
*  [Pajamas component: Banners](https://gitlab.com/groups/gitlab-org/-/epics/1136)

Related issues:
*  [FY20-Q2 UX OKR: Improve the quality and consistency of our UI](https://gitlab.com/gitlab-com/www-gitlab-com/issues/4355)

## Checklist

* [x]  Usage documentation is included in Pajamas
* [x]  Design specs are included in Pajamas
* [x]  Component is built and styled in gitlab-ui according to specs
* [x]  Banner on vue tab that warns of incorrect styling is removed from Pajamas
* [x]  All demos and todos are complete
* [ ]  Status is changed to `Built` in Pajamas
* [ ]  Add a reference and link to the completed component in the [Engineer Week in Review](https://docs.google.com/document/d/1Oglq0-rLbPFRNbqCDfHT0-Y3NkVEiHj6UukfYijHyUs/edit) doc

Story points: 5.0
Create, Build, and Style > Lists

This issue is to complete the ~"pajamas::create", ~"pajamas::build", ~"pajamas::style" portion of ~"component::lists" as part of FY20-Q2 OKR to Improve the quality and consistency of our UI.

This includes a single-source-of-truth component that is implemented in Vue and thoroughly documented on design.gitlab.com. This does not include implementing the component throughout the product.

Related epics:
*  [Components of Pajamas Design System](https://gitlab.com/groups/gitlab-org/-/epics/973)
*  [Pajamas component: Lists](https://gitlab.com/groups/gitlab-org/-/epics/1084)

Related issues:
*  [FY20-Q2 UX OKR: Improve the quality and consistency of our UI](https://gitlab.com/gitlab-com/www-gitlab-com/issues/4355)

## Checklist

* [ ]  Usage documentation is included in Pajamas
* [ ]  Design specs are included in Pajamas
* [ ]  Component is built and styled in gitlab-ui according to specs
* [ ]  Banner on vue tab that warns of incorrect styling is removed from Pajamas
* [ ]  All demos and todos are complete
* [ ]  Status is changed to `Built` in Pajamas
* [ ]  Add a reference and link to the completed component in the [Engineer Week in Review](https://docs.google.com/document/d/1Oglq0-rLbPFRNbqCDfHT0-Y3NkVEiHj6UukfYijHyUs/edit) doc

Story points: 3.0
Create, Build, and Style > Forms

This issue is to complete the ~"pajamas::create", ~"pajamas::build", ~"pajamas::style" portion of ~"component::forms"  as part of FY20-Q2 OKR to Improve the quality and consistency of our UI.

This includes a single-source-of-truth component that is implemented in Vue and thoroughly documented on design.gitlab.com. This does not include implementing the component throughout the product.

Related epics:
*  [Components of Pajamas Design System](https://gitlab.com/groups/gitlab-org/-/epics/973)
*  [Pajamas component: Forms](https://gitlab.com/groups/gitlab-org/-/epics/1021)

Related issues:
*  [FY20-Q2 UX OKR: Improve the quality and consistency of our UI](https://gitlab.com/gitlab-com/www-gitlab-com/issues/4355)

## Checklist

* [ ]  Usage documentation is included in Pajamas
* [ ]  Design specs are included in Pajamas
* [ ]  Component is built and styled in gitlab-ui according to specs
* [ ]  Banner on vue tab that warns of incorrect styling is removed from Pajamas
* [ ]  All demos and todos are complete
* [ ]  Status is changed to `Built` in Pajamas
* [ ]  Add a reference and link to the completed component in the [Engineer Week in Review](https://docs.google.com/document/d/1Oglq0-rLbPFRNbqCDfHT0-Y3NkVEiHj6UukfYijHyUs/edit) doc

Story points: 3.0
Create, Build, and Style > Dropdowns

This issue is to complete the ~"pajamas::create", ~"pajamas::build", ~"pajamas::style" portion of ~"component::dropdowns" as part of FY20-Q2 OKR to Improve the quality and consistency of our UI.

This includes a single-source-of-truth component that is implemented in Vue and thoroughly documented on design.gitlab.com. This does not include implementing the component throughout the product.

Related epics:
*  [Components of Pajamas Design System](https://gitlab.com/groups/gitlab-org/-/epics/973)
*  [Pajamas component: Dropdowns](https://gitlab.com/groups/gitlab-org/-/epics/1018)

Related issues:
*  [FY20-Q2 UX OKR: Improve the quality and consistency of our UI](https://gitlab.com/gitlab-com/www-gitlab-com/issues/4355)

## Checklist

* [ ]  Usage documentation is included in Pajamas
* [x]  Design specs are included in Pajamas
* [x]  Component is built and styled in gitlab-ui according to specs
* [ ]  Banner on vue tab that warns of incorrect styling is removed from Pajamas
* [ ]  All demos and todos are complete
* [ ]  Status is changed to `Built` in Pajamas
* [ ]  Add a reference and link to the completed component in the [Engineer Week in Review](https://docs.google.com/document/d/1Oglq0-rLbPFRNbqCDfHT0-Y3NkVEiHj6UukfYijHyUs/edit) doc

Story points: 3.0
Homepage > Pajamas logo > Animation

Ensure the animation used on the homepage of design.gitlab.com is following our motion guidelines and/or update motion guidelines as needed.

---

The following discussion from !216 should be addressed:

- [ ] @tauriedavis started a [discussion](https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/216#note_134646588):  (+5 comments)

    > Do these animations match our motion guidelines? Or do we need to add to our motion guidelines?

Story points: 1.0
Include a fallback for help links in empty state call to action design specifications

### Problem

Previously added empty states contained duplicate primary call to action buttons (see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/22745, https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/21975) but empty states are still being added with duplicate primary call to action buttons (see https://gitlab.com/gitlab-org/gitlab-ee/issues/9233, https://gitlab.com/gitlab-org/gitlab-ee/issues/9230).

### Proposal

Include a fallback for help links in empty state [call to action](https://design.gitlab.com/regions/empty-states#call-to-action) design specifications (see [helping users](https://design.gitlab.com/usability/helping-users)).

`CURRENT`

> - The call to action button in the empty state should be a primary button.
> - There is only one primary button since there can only be one primary button per form. If there is a need for more than one button, the other should be a secondary button.

`PROPOSED`

> - The call to action button in the empty state should be a primary button.
> - There is only one primary button since there can only be one primary button per form. If there is a need for more than one button, the other should be a secondary button.
> - If there is no need for a primary button or the primary button has already been added in the near components (see [tabs](/components/tabs)), there can be one or more help links within the description text (see [helping users](/usability/helping-users))

Story points: 1.0
Component: Add accessibility guidelines for invisible labels to forms documentation

As outlined in the [W3 guidelines](https://www.w3.org/WAI/tutorials/forms/labels/#hiding-label-text):

>A label for a form control helps everyone better understand its purpose. In some cases, the purpose may be clear enough from the context when the content is rendered visually. The label can be hidden visually, though it still needs to be provided within the code to support other forms of presentation and interaction, such as for screen reader and speech input users. 

```
<label for="search" class="visuallyhidden">Search: </label>
<input type="text" name="search" id="search">
<button type="submit">Search</button>
```

Story points: 1.0
Empty state: design and layout

Stemming from a conversation on slack about empty states:  

We need to reconsider the layout of empty states and how they refactor on smaller screens. Today the design documentation states: 

#### Description
* If the description needs to wrap on desktop, align it to the left.
* If the title needs to wrap on desktop, align both the title and description to the left.
* If the title and description do not wrap on desktop, center them horizontally.

This is causing some compromises to the design of empty states. Instead, we should consider a layout that doesn't need to mix center-aligned and left-aligned titles and body copy. 


@tauriedavis proposed this layout: 
![screen_shot_2018-12-04_at_10.15.26_am](/uploads/7802dbc4c79cca91cd21dc8a302672ba/screen_shot_2018-12-04_at_10.15.26_am.png)

Which eliminates the need to have empty states who's headlining are center-aligned and left-aligned.

Story points: 2.0
Check for broken links

(Shamelessly copied from https://gitlab.com/gitlab-org/gitlab-ce/issues/51696)

### Problem to solve

Check for broken links, both **internal and external**

### Further details

- 404s are bad UX; we should check the docs to assure we don't have them
- The recent change to use the `#` led to broken links, as noted by the community on [Twitter](https://twitter.com/Citizen_Drain/status/1064886792657281024) and [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:6473126444728872960/?commentUrn=urn%3Ali%3Acomment%3A(activity%3A6472126819968524288%2C6473126423233077248))
- There were some broken links that went unnoticed: https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/165

### Proposal

Implement a broken link checker, preferably in a job (not allowed to fail) that runs with the entire pipeline. As inspiration, checkout how GitLab Docs implemented their external link checker: https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/360

### What does success look like, and how can we measure that?

:thinking: green pipelines == 100% success :stuck\_out\_tongue\_winking\_eye: 

### Links / references

- Community noticing broken URLs on [Twitter](https://twitter.com/Citizen_Drain/status/1064886792657281024) and [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:6473126444728872960/?commentUrn=urn%3Ali%3Acomment%3A(activity%3A6472126819968524288%2C6473126423233077248))

Story points: 2.0
Dropdowns have no accessibility and behavior documentation defined for small viewports

### Problem

Dropdowns have no accessibility and behavior documentation defined for small viewports

### Further information

| Current situation | visually improved situation | Actually accessible behaviour situation |
| --- | --- | --- |
| ![_0px-expanded-single-upstream_copy](/uploads/2703f8028c9497192a736ec9c2e16ecc/_0px-expanded-single-upstream_copy.png) | ![_0px-expanded-single-upstream_copy_2](/uploads/140f81d6a055ee71dd294cca915277dc/_0px-expanded-single-upstream_copy_2.png) | ![_0px-expanded-single-upstream_copy_3](/uploads/6c42150fe956b4c473c8ed0f2e8db926/_0px-expanded-single-upstream_copy_3.png) |

Last mockup is based upon https://developer.apple.com/design/human-interface-guidelines/ios/controls/pickers/

Examples are based on designs from https://gitlab.com/gitlab-org/gitlab-ee/issues/2122

### Proposal

- Create documentation detailing accessibility and behavior for dropdowns
- Create pattern library assets supporting the documentation

#### What does success look like, and how can we measure that?

- Documentation is created detailing accessibility and behavior for dropdowns
- Pattern library is updated with assets supporting the documentation

Story points: 3.0
Follow-up from "Resolve "Component: Add Toast documentation""

The following discussion from !41 should be addressed:

- [ ] @tauriedavis started a [discussion](https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/41#note_105879603):  (+4 comments)

    > Why does the dismiss icon act different if there are 1 vs. 2 lines?

- [ ] @dimitrieh 

>I feel we should just do away with dismiss actions.
>
>The text button next to an icon button feels out of place/inconsistent. A group of buttons should either be all text or all icons.
>
>Also taken from [material design guide lines](https://material.io/design/components/snackbars.html#usage):
>
>> Snackbars inform users of a process that an app has performed or will perform. They appear temporarily, towards the bottom of the screen. They shouldn’t interrupt the user experience, and they don’t require user input to disappear.
>>
>> Frequency
>> Only one snackbar may be displayed at a time.
>>
>> Actions
>> A snackbar can contain a single action. Because they disappear automatically, the action shouldn’t be “Dismiss” or “Cancel.”

Story points: 1.0
Add the Law of Proximity Gestalt principle to the Layout > Spacing page

Based on this [discussion on Slack](https://gitlab.slack.com/files/UA7DGQSAZ/FB3HHAJJ3/image.png) we concluded that we should add the [Law of Proximity](https://en.wikipedia.org/wiki/Principles_of_grouping#Proximity) Gestalt principle somewhere in our Design System. 

>"objects or shapes that are close to one another appear to form groups". Even if the shapes, sizes, and objects are radically different, they will appear as a group if they are close.

![image](/uploads/a9f6478d2ad2a081d190e9dc50b3602c/image.png)
*In [this particular case](https://gitlab.com/gitlab-org/gitlab-ce/commits/issue_44230): A button that navigates to another page, a search box and a 'Subscribe to RSS' button, three things that are completely unrelated seem like they are because of their placement on the page. This makes our interfaces unintuitive and harder to adopt.*

Atm, our interfaces seem cluttered sometimes and one of the common issues is that we group together things that aren't related. We'll add this principle that is commonly used in graphic and UI design to guide us and prevent this from happening in the future.

Story points: 1.0
Write guidelines for text colours in Typography section

I recently noticed that the quotes text colour is way too light on white background and hard to read (gitlab-org/gitlab-design#147). I think we should write down the guidelines for text colours: what is the default text colour, what is the lightest shade allowed to use on the white background. These guidelines should be aligned with the [accessibility standards](https://webaim.org/resources/contrastchecker/).

Story points: 1.0
Design Pattern Library - Component: Links

Add a new component for links.

This should include documentation related to styles and usage of anchors as well as documentation regarding truncation of links.

Transfer/update existing information regarding anchors: https://docs.gitlab.com/ee/development/ux_guide/components.html#anchor-links

Related: https://gitlab.com/gitlab-org/gitlab-design/issues/122

- Buttons vs links: https://gitlab.com/gitlab-org/gitlab-ce/issues/21287#note_17099288
- https://gitlab.com/gitlab-org/gitlab-ce/issues/21287#note_16963426

Story points: 3.0
Design for Tabs within tabs (contextual tabs)

### Overview

We can several places in GitLab where we have top-level tabs for categories but we need further context within and thus we use tabs under the content of top-level tab. One such example is on `/dashboard/projects` page which looks like this;

![image](/uploads/fb989f15d7e9938485dda1daebd2e3d4/image.png)

Tabs inside tabs is very common UX pattern and it is generally preferred to have slightly different design for _sub-tabs_ than the one you have to main tabs.

#### See the discussions around this design in following threads on StackExchange.

*  [Is there evidence to suggest that designing tabs within tabs creates a bad user experience?](https://ux.stackexchange.com/questions/5136/is-there-evidence-to-suggest-that-designing-tabs-within-tabs-creates-a-bad-user)
*  [Elegant, simple and obvious sub-tabs?](https://ux.stackexchange.com/questions/16281/elegant-simple-and-obvious-sub-tabs)

#### Proposal

Let's discuss possible alternative designs (or reasoning behind current design) :smiley:

I think [Bootstrap Pills](https://getbootstrap.com/docs/3.3/components/#nav-pills) are ideal choice when we want to have nested tabs but I'll leave our options open. :slight_smile:

Although I've put together a quick mock up on CodePen which uses Pills under Tabs, check it out [here](https://codepen.io/kushalpandya/pen/zEzEbP).

![image](/uploads/bb80d08b6ca7fe8c2005dbcde291c5bf/image.png)

Story points: 5.0
Progress bar > 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 progress bar 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
Popover > 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 popover 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
Path > 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 path 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
Pagination > 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 pagination 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