Skip to content

G
gitlab-ce
Commit 0ca7221d authored by Marcia Ramos's avatar Marcia Ramos
Browse files
Options

Merge branch 'deprecate-ux-ee' into 'master' 

Deprecate UX Guide and redirect to design.gitlab

See merge request gitlab-org/gitlab-ee!8546
parents c86bbf61 b835200e
Expand all Hide whitespace changes
Inline Side-by-side
Showing with 43 additions and 1464 deletions
doc/development/README.md
View file @ 0ca7221d
......@@ -23,7 +23,7 @@ description: 'Learn how to contribute to GitLab.'
## UX and frontend guides
- [UX guide](ux_guide/index.md) for building GitLab with existing CSS styles and elements
- [GitLab Design System](https://design.gitlab.com/) for building GitLab with existing CSS styles and elements
- [Frontend guidelines](fe_guide/index.md)
- [Emoji guide](fe_guide/emojis.md)
......
doc/development/documentation/index.md
View file @ 0ca7221d
......@@ -100,9 +100,6 @@ The table below shows what kind of documentation goes where.
**General rules & best practices:**
1. The correct naming and location of a new document, is a combination
of the relative URL of the document in question and the GitLab Map design
that is used for UX purposes ([source][graffle], [image][gitlab-map]).
1. When creating a new document and it has more than one word in its name,
make sure to use underscores instead of spaces or dashes (`-`). For example,
a proper naming would be `import_projects_from_github.md`. The same rule
......
doc/development/fe_guide/components.md
View file @ 0ca7221d
......@@ -6,7 +6,7 @@
## Dropdowns
See also the [corresponding UX guide](../ux_guide/components.md#dropdowns).
See also the [corresponding UX guide](https://design.gitlab.com/#/components/dropdowns).
### How to style a bootstrap dropdown
1. Use the HTML structure provided by the [docs][bootstrap-dropdowns]
......@@ -40,7 +40,7 @@ See also the [corresponding UX guide](../ux_guide/components.md#dropdowns).
## Modals
See also the [corresponding UX guide](../ux_guide/components.md#modals).
See also the [corresponding UX guide](https://design.gitlab.com/#/components/modals).
We have a reusable Vue component for modals: [vue_shared/components/gl_modal.vue](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/vue_shared/components/gl_modal.vue)
......
doc/development/ui_guide.md
View file @ 0ca7221d
# UI Guide for building GitLab
---
redirect_to: 'https://design.gitlab.com/'
---
## GitLab UI development kit
We created a page inside GitLab where you can check commonly used html and css elements.
When you run GitLab instance locally - just visit http://localhost:3000/help/ui page to see UI examples
you can use during GitLab development.
## Design repository
All design files are stored in the [gitlab-design](https://gitlab.com/gitlab-org/gitlab-design)
repository and maintained by GitLab UX designers.
## Navigation
GitLab's layout contains 2 sections: the left sidebar and the content. The left sidebar contains a static navigation menu.
This menu will be visible regardless of what page you visit.
The content section contains a header and the content itself. The header describes the current GitLab page and what navigation is
available to the user in this area. Depending on the area (project, group, profile setting) the header name and navigation may change. For example, when the user visits one of the
project pages the header will contain the project's name and navigation for that project. When the user visits a group page it will contain the group's name and navigation related to this group.
You can see a visual representation of the navigation in GitLab in the GitLab Product Map, which is located in the [Design Repository][gitlab-map-graffle]
along with [PDF][gitlab-map-pdf] and [PNG][gitlab-map-png] exports.
### Adding new tab to header navigation
We try to keep the amount of tabs in the header navigation between 5 and 10 so that it fits on a typical laptop screen. We also try not to confuse the user with too many options. Ideally each
tab should represent separate functionality. Everything related to the issue
tracker should be under the 'Issues' tab while everything related to the wiki should
be under 'Wiki' tab and so on and so forth.
When adding a new tab to the header don't use more than 2 words for text in the link.
We want to keep links short and easy to remember and fit all of them in the small screen.
## Mobile screen size
We want GitLab to work well on small mobile screens as well. Size limitations make it is impossible to fit everything on a mobile screen. In this case it is OK to hide
part of the UI for smaller resolutions in favor of a better user experience.
However core functionality like browsing files, creating issues, writing comments, should
be available on all resolutions.
## Icons
* `trash` icon for button or link that does destructive action like removing
information from database or file system
* `x` icon for closing/hiding UI element. For example close modal window
* `pencil` icon for edit button or link
* `eye` icon for subscribe action
* `rss` for rss/atom feed
* `plus` for link or dropdown that lead to page where you create new object (For example new issue page)
### SVGs
When exporting SVGs, be sure to follow the following guidelines:
- Convert all strokes to outlines.
- Use pathfinder tools to combine overlapping paths and create compound paths.
- SVGs that are limited to one color should be exported without a fill color so the color can be set using CSS.
- Ensure that exported SVGs have been run through an [SVG cleaner](https://github.com/RazrFalcon/SVGCleaner) to remove unused elements and attributes.
You can open your svg in a text editor to ensure that it is clean.
Incorrect files will look like this:
```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="16px" height="17px" viewBox="0 0 16 17" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<!-- Generator: Sketch 3.7.2 (28276) - http://www.bohemiancoding.com/sketch -->
<title>Group</title>
<desc>Created with Sketch.</desc>
<defs></defs>
<g id="Page-1" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
<g id="Group" fill="#7E7C7C">
<path d="M15.1111,1 L0.8891,1 C0.3981,1 0.0001,1.446 0.0001,1.996 L0.0001,15.945 C0.0001,16.495 0.3981,16.941 0.8891,16.941 L15.1111,16.941 C15.6021,16.941 16.0001,16.495 16.0001,15.945 L16.0001,1.996 C16.0001,1.446 15.6021,1 15.1111,1 L15.1111,1 L15.1111,1 Z M14.0001,6.0002 L14.0001,14.949 L2.0001,14.949 L2.0001,6.0002 L14.0001,6.0002 Z M14.0001,4.0002 L14.0001,2.993 L2.0001,2.993 L2.0001,4.0002 L14.0001,4.0002 Z" id="Combined-Shape"></path>
<polygon id="Fill-11" points="3 2.0002 5 2.0002 5 0.0002 3 0.0002"></polygon>
<polygon id="Fill-16" points="11 2.0002 13 2.0002 13 0.0002 11 0.0002"></polygon>
<path d="M5.37709616,11.5511984 L6.92309616,12.7821984 C7.35112915,13.123019 7.97359761,13.0565604 8.32002627,12.6330535 L10.7740263,9.63305349 C11.1237073,9.20557058 11.0606364,8.57555475 10.6331535,8.22587373 C10.2056706,7.87619272 9.57565475,7.93926361 9.22597373,8.36674651 L6.77197373,11.3667465 L8.16890384,11.2176016 L6.62290384,9.98660159 C6.19085236,9.6425813 5.56172188,9.71394467 5.21770159,10.1459962 C4.8736813,10.5780476 4.94504467,11.2071781 5.37709616,11.5511984 L5.37709616,11.5511984 Z" id="Stroke-21"></path>
</g>
</g>
</svg>
```
Correct file will look like this:
```xml
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 17" enable-background="new 0 0 16 17"><path d="m15.1 1h-2.1v-1h-2v1h-6v-1h-2v1h-2.1c-.5 0-.9.5-.9 1v14c0 .6.4 1 .9 1h14.2c.5 0 .9-.4.9-1v-14c0-.5-.4-1-.9-1m-1.1 14h-12v-9h12v9m0-11h-12v-1h12v1"/><path d="m5.4 11.6l1.5 1.2c.4.3 1.1.3 1.4-.1l2.5-3c.3-.4.3-1.1-.1-1.4-.5-.4-1.1-.3-1.5.1l-1.8 2.2-.8-.6c-.4-.3-1.1-.3-1.4.2-.3.4-.3 1 .2 1.4"/></svg>
```
## Buttons
* Button should contain icon or text. Exceptions should be approved by UX designer.
* Use red button for destructive actions (not revertable). For example removing issue.
* Use green or blue button for primary action. Primary button should be only one.
Do not use both green and blue button in one form.
* For all other cases use default white button.
* Text button should have only first word capitalized. So should be "Create issue" instead of "Create Issue"
## Counts
* Always use the [`number_with_delimiter`][number_with_delimiter] helper to
display counts in the UI.
[number_with_delimiter]: http://api.rubyonrails.org/classes/ActionView/Helpers/NumberHelper.html#method-i-number_with_delimiter
[gitlab-map-graffle]: https://gitlab.com/gitlab-org/gitlab-design/blob/master/production/resources/gitlab-map.graffle
[gitlab-map-pdf]: https://gitlab.com/gitlab-org/gitlab-design/raw/master/production/resources/gitlab-map.pdf
[gitlab-map-png]: https://gitlab.com/gitlab-org/gitlab-design/raw/master/production/resources/gitlab-map.png
The content of this documented was moved into the [GitLab Design System](https://design.gitlab.com/).
doc/development/ux_guide/animation.md
View file @ 0ca7221d
# Animation
---
redirect_to: 'https://design.gitlab.com/foundations/motion'
---
Motion is a tool to help convey important relationships, changes or transitions between elements. It should be used sparingly and intentionally, highlighting the right elements at the right moment.
## Timings
The longer distance an object travel, the timing should be longer for the animation. However, when in doubt, we should avoid large, full screen animations.
Subtle animations, or objects leaving the screen should take **100-200 milliseconds**. Objects entering the screen, or motion we want to use to direct user attention can take between **200-400 milliseconds**. We should avoid animations of longer than 400 milliseconds as they will make the experience appear sluggish. If a specific animation feels like it will need more than 400 milliseconds, revisit the animation to see if there is a simpler, easier, shorter animation to implement.
## Easing
Easing specifies the rate of change of a parameter over time (see [easings.net](http://easings.net/)). Adding an easing curve will make the motion feel more natural. Being consistent with the easing curves will make the whole experience feel more cohesive and connected.
* When an object is entering the screen, or transforming the scale, position, or shape, use the **easeOutQuint** curve (`cubic-bezier(0.23, 1, 0.32, 1)`)
* When an object is leaving the screen, or transforming the opacity or color, no easing curve is needed. It shouldn't _slow down_ as it is exiting the screen, as that draws attention on the leaving object, where we don't want it. Adding easing to opacity and color transitions will make the motion appear less smooth. Therefore, for these cases, motion should just be **linear**.
## Types of animations
### Hover
Interactive elements (links, buttons, etc.) should have a hover state. A subtle animation for this transition adds a polished feel. We should target a `100ms - 150ms linear` transition for a color hover effect.
View the [interactive example](http://codepen.io/awhildy/full/GNyEvM/) here.
![Hover animation](img/animation-hover.gif)
### Dropdowns
The dropdown menu should feel like it is appearing from the triggering element. Combining a position shift `400ms cubic-bezier(0.23, 1, 0.32, 1)` with an opacity animation `200ms linear` on the second half of the motion achieves this affect.
View the [interactive example](http://codepen.io/awhildy/full/jVLJpb/) here.
![Dropdown animation](img/animation-dropdown.gif)
### Quick update
When information is updating in place, a quick, subtle animation is needed. The previous content should cut out, and the new content should have a quick, `200ms linear` fade in.
![Quick update animation](img/animation-quickupdate.gif)
### Skeleton loading
Skeleton loading is explained in the [component section](components.html#skeleton-loading) of the UX guide. It includes a horizontally pulsating animation that shows motion as if it's growing. It's timing is a slower `linear 1s`.
![Skeleton loading animation](img/skeleton-loading.gif)
### Moving transitions
When elements move on screen, there should be a quick animation so it is clear to users what moved where. The timing of this animation differs based on the amount of movement and change. Consider animations between `200ms` and `400ms`.
#### Shifting elements on reorder
An example of a moving transition is when elements have to move out of the way when you drag an element.
View the [interactive example](http://codepen.io/awhildy/full/ALyKPE/) here.
![Reorder animation](img/animation-reorder.gif)
#### Autoscroll the page
Another example of a moving transition is when you have to autoscroll the page to keep an active element visible.
View the [interactive example](http://codepen.io/awhildy/full/PbxgVo/) here.
![Autoscroll animation](img/animation-autoscroll.gif)
The content of this documented was moved into the [GitLab Design System](https://design.gitlab.com).
doc/development/ux_guide/basics.md
View file @ 0ca7221d
# Basics
## Contents
* [Responsive](#responsive)
* [Typography](#typography)
* [Icons](#icons)
* [Color](#color)
* [Cursors](#cursors)
---
## Responsive
GitLab is a responsive experience that works well across all screen sizes, from mobile devices to large monitors. In order to provide a great user experience, the core functionality (browsing files, creating issues, writing comments, etc.) must be available at all resolutions. However, due to size limitations, some secondary functionality may be hidden on smaller screens. Please keep this functionality limited to rare actions that aren't expected to be needed on small devices.
---
## Typography
### Primary typeface
GitLab's main typeface used throughout the UI is **Source Sans Pro**. We support both the bold and regular weight.
![Source Sans Pro sample](img/sourcesanspro-sample.png)
### Monospace typeface
This is the typeface used for code blocks and references to commits, branches, and tags (`.commit-sha` or `.ref-name`). GitLab uses the OS default font.
- **Menlo** (Mac)
- **Consolas** (Windows)
- **Liberation Mono** (Linux)
![Monospace font sample](img/monospacefont-sample.png)
---
## Icons
GitLab has a strong, unique personality. When you look at any screen, you should know immediately that it is GitLab.
Iconography is a powerful visual cue to the user and is a great way for us to reflect our particular sense of style.
- **Standard size:** 16px * 16px
- **Border thickness:** 2px
- **Border radius:** 3px
![Icon sampler](img/icon-spec.png)
> TODO: List all icons, proper usage, hover, and active states.
---
## Color
| | State | Action |
| :------: | :------- | :------- |
| ![Blue](img/color-blue.png) | Primary and active (such as the current tab) | Organizational, managing, and retry commands|
| ![Green](img/color-green.png) | Opened | Create new objects |
| ![Orange](img/color-orange.png) | Warning | Non destructive action |
| ![Red](img/color-red.png) | Closed | Delete and other destructive commands |
| ![Grey](img/color-grey.png) | Neutral | Neutral secondary commands |
### Text colors
|||
| :---: | :--- |
| ![Text primary](img/color-textprimary.png) | Used for primary body text, such as issue description and comment |
| ![Text secondary](img/color-textsecondary.png) | Used for secondary body text, such as username and date |
> TODO: Establish a perspective for color in terms of our personality and rationalize with Marketing usage.
redirect_to: 'https://design.gitlab.com/'
---
## Cursors
The mouse cursor is key in helping users understand how to interact with elements on the screen.
| | |
| :------: | :------- |
| ![Default cursor](img/cursors-default.png) | Default cursor |
| ![Pointer cursor](img/cursors-pointer.png) | Pointer cursor: used to indicate that you can click on an element to invoke a command or navigate, such as links and buttons |
| ![Move cursor](img/cursors-move.png) | Move cursor: used to indicate that you can move an element around on the screen |
| ![Pan opened cursor](img/cursors-panopened.png) | Pan cursor (opened): indicates that you can grab and move the entire canvas, affecting what is seen in the view port. |
| ![Pan closed cursor](img/cursors-panclosed.png) | Pan cursor (closed): indicates that you are actively panning the canvas. |
| ![I-beam cursor](img/cursors-ibeam.png) | I-beam cursor: indicates that this is either text that you can select and copy, or a text field that you can click into to enter text. |
The content of this documented was moved into the [GitLab Design System](https://design.gitlab.com/).
doc/development/ux_guide/components.md
View file @ 0ca7221d
This diff is collapsed.
doc/development/ux_guide/copy.md
View file @ 0ca7221d
This diff is collapsed.
doc/development/ux_guide/features.md
View file @ 0ca7221d
# Features
## Contents
* [Navigation](#navigation)
* [Filtering](#filtering)
* [Search results](#search-results)
* [Conversations](#conversations)
* [Empty states](#empty-states)
---
## Navigation
### Global navigation
The global navigation is accessible via the menu button on the top left of the screen, and can be pinned to keep it open. It contains a consistent list of pages that allow you to view content that is across GitLab. For example, you can view your todos, issues and merge requests across projects and groups.
![Global nav](img/features-globalnav.png)
### Contextual navigation
The navigation in the header is contextual to each page. These options change depending on if you are looking at a project, group, or settings page. There should be no more than 10 items on a level in the contextual navigation, allowing it to comfortably fit on a typical laptop screen. There can be up to too levels of navigation. Each sub nav group should be a self-contained group of functionality. For example, everything related to the issue tracker should be under the 'Issue' tab, while everything relating to the wiki will be grouped under the 'Wiki' tab. The names used for each section should be short and easy to remember, ideally 1-2 words in length.
![Contextual nav](img/features-contextualnav.png)
### Information architecture
The [GitLab Product Map](https://gitlab.com/gitlab-org/gitlab-design/raw/master/production/resources/gitlab-map.png) shows a visual representation of the information architecture for GitLab.
redirect_to: 'https://design.gitlab.com/'
---
## Filtering
Today, lists are filtered by a series of dropdowns. Some of these dropdowns allow multiselect (labels), while others allow you to filter to one option (milestones). However, we are currently implementing a [new model](https://gitlab.com/gitlab-org/gitlab-ce/issues/21747) for this, and will update the guide when it is ready.
![Filters](img/features-filters.png)
---
## Search results
### Global search
[Global search](https://gitlab.com/search?group_id=&project_id=13083&repository_ref=&scope=issues&search=mobile) allows you to search across items in a project, or even across multiple projects. You can switch tabs to filter on type of object, or filter by group.
### List search
There are several core lists in the GitLab experience, such as the Issue list and the Merge Request list. You are also able to [filter and search these lists](https://gitlab.com/gitlab-org/gitlab-ce/issues?utf8=%E2%9C%93&search=mobile). This UI will be updated with the [new filtering model](https://gitlab.com/gitlab-org/gitlab-ce/issues/21747).
---
## Empty states
Empty states need to be considered in the design of features. They are vital to helping onboard new users, making the experience feel more approachable and understandable. Empty states should feel inviting and provide just enough information to get people started. There should be a single call to action and a clear explanation of what to use the feature for.
![Empty states](img/features-emptystates.png)
The content of this documented was moved into the [GitLab Design System](https://design.gitlab.com/).
doc/development/ux_guide/illustrations.md
View file @ 0ca7221d
# Illustrations
The illustrations should always align with topics and goals in specific context.
## Principles
#### Be simple.
- For clarity, we use simple and specific elements to create our illustrations.
#### Be optimistic.
- We are an open-minded, optimistic, and friendly team. We should reflect those values in our illustrations to connect with our brand experience.
#### Be gentle.
- Our illustrations assist users in understanding context and guide users in the right direction. Illustrations are supportive, so they should be obvious but not aggressive.
## Style
#### Shapes
- All illustrations are geometric rather than organic.
- The illustrations are made by circles, rectangles, squares, and triangles.
<img src="img/illustrations-geometric.png" width=224px alt="Example for geometric" />
#### Stroke
- Standard border thickness: **4px**
- Depending on the situation, border thickness can be changed to **3px**. For example, when the illustration size is small, an illustration with 4px border thickness would look tight. In this case, the border thickness can be changed to 3px.
- We use **rounded caps** and **rounded corner**.
| Do | Don't |
| -------- | -------- |
| <img src="img/illustrations-caps-do.png" width= 133px alt="Do: caps and corner" /> | <img src="img/illustrations-caps-don't.png" width= 133px alt="Don't: caps and corner"/> |
#### Radius
- Standard corner radius: **10px**
- Depending on the situation, corner radius can be changed to **5px**. For example, when the illustration size is small, an illustration with 10px corner radius would be over-rounded. In this case, the corner radius can be changed to 5px.
<img src="img/illustrations-border-radius.png" width= 464px alt="Example for border radius"/>
#### Size
Depends on the situation, the illustration size can be the 3 types below:
**Large**
* Use case: Empty states, error pages(e.g. 404, 403)
* For vertical layout, the illustration should not larger than **430*300 px**.
* For horizontal layout, the illustration should not larger than **430*380 px**.
| Vertical layout | Horizontal layout |
| --------------- | ----------------- |
| <img src="img/illustration-size-large-vertical.png" /> | <img src="img/illustration-size-large-horizontal.png" />
**Medium**
* Use case: Banner
* The illustration should not larger than **240*160 px**
* The illustration should keep simple and clear. We recommend not including too many elements in the medium size illustration.
<img src="img/illustration-size-medium.png" width=983px />
**Small**
* Use case: Graphics for explanatory text, graphics for status.
* The illustration should not larger than **160*90 px**.
* The illustration should keep simple and clear. We recommend not including too many elements in the small size illustration.
<img src="img/illustration-size-small.png" width=983px />
**Illustration on mobile**
- Keep the proportions in original ratio.
#### Colors palette
For consistency, we recommend choosing colors from our color palette.
| Orange | Purple | Grey |
| -------- | -------- | -------- |
| <img src="img/illustrations-color-orange.png" width= 160px alt="Orange" /> | <img src="img/illustrations-color-purple.png" width= 160px alt="Purple" /> | <img src="img/illustrations-color-grey.png" width= 160px alt="Grey" /> |
| #FC6D26 | #6B4FBB | #EEEEEE |
#### Don't
- Don't include the typography in the illustration.
- Don't include tanuki in the illustration. If necessary, we recommend having tanuki monochromatic.
---
redirect_to: 'https://design.gitlab.com/foundations/illustration/'
---
| Orange | Purple |
| -------- | -------- |
| <img src="img/illustrations-palette-oragne.png" width= 160px alt="Palette - Orange" /> | <img src="img/illustrations-palette-purple.png" width= 160px alt="Palette - Purple" /> |
The content of this documented was moved into the [GitLab Design System](https://design.gitlab.com/).
doc/development/ux_guide/index.md
View file @ 0ca7221d
> We are in the process of transferring UX documentation to the [design.gitlab.com](https://gitlab.com/gitlab-org/design.gitlab.com) project. Any updates to these docs should be made in that project. If documentation does not yet exist within [design.gitlab.com](https://gitlab.com/gitlab-org/design.gitlab.com), [create an issue](https://gitlab.com/gitlab-org/design.gitlab.com/issues) and merge request to add your new changes.
# GitLab UX Guide
The goal of this guide is to provide standards, principles and in-depth information to design beautiful and effective GitLab features. This will be a living document, and we welcome contributions, feedback and suggestions.
## Design
---
### [Principles](principles.md)
These guiding principles set a solid foundation for our design system, and should remain relatively stable over multiple releases. They should be referenced as new design patterns are created.
---
### [Basics](basics.md)
The basic ingredients of our experience establish our personality and feel. This section includes details about typography, iconography, and color.
---
### [Animation](animation.md)
Guidance on the timing, curving and motion for GitLab.
---
### [Illustrations](illustrations.md)
Guidelines for principals and styles related to illustrations for GitLab.
---
### [Copy](copy.md)
Conventions on text and messaging within labels, buttons, and other components.
---
### [Components](components.md)
Components are the controls that make up the GitLab experience, including guidance around buttons, links, dropdowns, etc.
---
### [Surfaces](surfaces.md)
The GitLab experience is broken apart into several surfaces. Each of these surfaces is designated for a specific scope or type of content. Examples include the header, global menu, side pane, etc.
---
### [Features](features.md)
The previous building blocks are combined into complete features in the GitLab UX. Examples include our navigation, filters, search results, and empty states.
---
## Research
---
### [Users](users.md)
How we think about the variety of users of GitLab, from small to large teams, comparing opensource usage to enterprise, etc.
---
## Other
---
### [Tips for designers](tips.md)
Tips for exporting assets, and other guidance.
redirect_to: 'https://design.gitlab.com/'
---
### [Resources](resources.md)
Resources for GitLab UX
The content of this documented was moved into the [GitLab Design System](https://design.gitlab.com/).
doc/development/ux_guide/principles.md
View file @ 0ca7221d
# Principles
---
redirect_to: 'https://design.gitlab.com/'
---
These are the guiding principles that we should strive for to establish a solid foundation for the GitLab experience.
## Professional and productive
GitLab is a tool to support what people do, day in, day out. We need to respect the importance of their work, and avoid gimicky details.
## Minimal and efficient
While work can get complicated, GitLab is about bringing a sharp focus, helping our customers know what matters now.
## Immediately recognizable
When you look at any screen, you should know immediately that it is GitLab. Our personality is strong and consistent across product and marketing experiences.
## Human and quirky
We need to build empathy with our users, understanding their state of mind, and connect with them at a human level. Quirkiness is part of our DNA, and we should embrace it in the right moments and contexts.
> TODO: Ensure these principles align well with the goals of the Marketing team
The content of this documented was moved into the [GitLab Design System](https://design.gitlab.com/).
doc/development/ux_guide/resources.md
View file @ 0ca7221d
# Resources
---
redirect_to: 'https://design.gitlab.com/resources/design-resources'
---
## GitLab UI development kit
We created a page inside GitLab where you can check commonly used html and css elements.
When you run GitLab instance locally - just visit http://localhost:3000/help/ui page to see UI examples
you can use during GitLab development.
## Design repository
All design files are stored in the [gitlab-design](https://gitlab.com/gitlab-org/gitlab-design)
repository and maintained by GitLab UX designers.
## [brand.ai](https://brand.ai/git-lab/primary-brand)
We are in the process of capturing our UI paradigms on brand.ai, see https://brand.ai/git-lab/primary-brand
The content of this documented was moved into the [GitLab Design System](https://design.gitlab.com/).
doc/development/ux_guide/surfaces.md
View file @ 0ca7221d
# Surfaces
## Contents
* [Header](#header)
* [Global menu](#global-menu)
* [Side pane](#side-pane)
* [Content area](#content-area)
---
![Surfaces UX](img/surfaces-ux.png)
## Global menu
This menu is to navigate to pages that contain content global to GitLab.
---
## Header
The header contains 3 main elements: Project switching and searching, user account avatar and settings, and a contextual menu that changes based on the current page.
![Surfaces Header](img/surfaces-header.png)
---
## Side pane
The side pane holds supporting information and meta data for the information in the content area.
redirect_to: 'https://design.gitlab.com/'
---
## Content area
The main content of the page. The content area can include other surfaces.
### Item title bar
The item title bar contains the top level information to identify the item, such as the name, id and status.
![Item title](img/surfaces-contentitemtitle.png)
### Item system information
The system information block contains relevant system controlled information.
![Item system information](img/surfaces-systeminformationblock.png)
The content of this documented was moved into the [GitLab Design System](https://design.gitlab.com/).
doc/development/ux_guide/tips.md
View file @ 0ca7221d
# Tips
---
redirect_to: 'https://design.gitlab.com/'
---
## SVGs
When exporting SVGs, be sure to follow the following guidelines:
1. Convert all strokes to outlines.
1. Use pathfinder tools to combine overlapping paths and create compound paths.
1. SVGs that are limited to one color should be exported without a fill color so the color can be set using CSS.
1. Ensure that exported SVGs have been run through an [SVG cleaner](https://github.com/RazrFalcon/SVGCleaner) to remove unused elements and attributes.
You can open your SVG in a text editor to ensure that it is clean.
Incorrect files will look like this:
```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<svg width="16px" height="17px" viewBox="0 0 16 17" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<!-- Generator: Sketch 3.7.2 (28276) - http://www.bohemiancoding.com/sketch -->
<title>Group</title>
<desc>Created with Sketch.</desc>
<defs></defs>
<g id="Page-1" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
<g id="Group" fill="#7E7C7C">
<path d="M15.1111,1 L0.8891,1 C0.3981,1 0.0001,1.446 0.0001,1.996 L0.0001,15.945 C0.0001,16.495 0.3981,16.941 0.8891,16.941 L15.1111,16.941 C15.6021,16.941 16.0001,16.495 16.0001,15.945 L16.0001,1.996 C16.0001,1.446 15.6021,1 15.1111,1 L15.1111,1 L15.1111,1 Z M14.0001,6.0002 L14.0001,14.949 L2.0001,14.949 L2.0001,6.0002 L14.0001,6.0002 Z M14.0001,4.0002 L14.0001,2.993 L2.0001,2.993 L2.0001,4.0002 L14.0001,4.0002 Z" id="Combined-Shape"></path>
<polygon id="Fill-11" points="3 2.0002 5 2.0002 5 0.0002 3 0.0002"></polygon>
<polygon id="Fill-16" points="11 2.0002 13 2.0002 13 0.0002 11 0.0002"></polygon>
<path d="M5.37709616,11.5511984 L6.92309616,12.7821984 C7.35112915,13.123019 7.97359761,13.0565604 8.32002627,12.6330535 L10.7740263,9.63305349 C11.1237073,9.20557058 11.0606364,8.57555475 10.6331535,8.22587373 C10.2056706,7.87619272 9.57565475,7.93926361 9.22597373,8.36674651 L6.77197373,11.3667465 L8.16890384,11.2176016 L6.62290384,9.98660159 C6.19085236,9.6425813 5.56172188,9.71394467 5.21770159,10.1459962 C4.8736813,10.5780476 4.94504467,11.2071781 5.37709616,11.5511984 L5.37709616,11.5511984 Z" id="Stroke-21"></path>
</g>
</g>
</svg>
```
Correct files will look like this:
```xml
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 16 17" enable-background="new 0 0 16 17"><path d="m15.1 1h-2.1v-1h-2v1h-6v-1h-2v1h-2.1c-.5 0-.9.5-.9 1v14c0 .6.4 1 .9 1h14.2c.5 0 .9-.4.9-1v-14c0-.5-.4-1-.9-1m-1.1 14h-12v-9h12v9m0-11h-12v-1h12v1"/><path d="m5.4 11.6l1.5 1.2c.4.3 1.1.3 1.4-.1l2.5-3c.3-.4.3-1.1-.1-1.4-.5-.4-1.1-.3-1.5.1l-1.8 2.2-.8-.6c-.4-.3-1.1-.3-1.4.2-.3.4-.3 1 .2 1.4"/></svg>
```
> TODO: Checkout <https://github.com/svg/svgo>.
The content of this documented was moved into the [GitLab Design System](https://design.gitlab.com/).
\ No newline at end of file
doc/development/ux_guide/users.md
View file @ 0ca7221d
This diff is collapsed.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7