Icon Audit and Refresh

added Icon UI polish UX + 1 deleted label

Here are a few explorations I put together to get a sense of the benefits of a refresh. In all comps I compare current with concept thick/thin variations.

This is awesome! So glad to see you working on this, @jeldergl.

I like these it feels they actually have a certain identity. Our current icons feel a bit generic and bland. I'm not so sure about the lightest weight though. I think they might look nice on retina screens but not so much on non-retina...

Are 8px, 16px, 32px, 48, 72, and 256 sizes necessary for every icon?

I'd say no. Most of our UI icons are small sizes. I don't recall using a size of 256 or even 72.

If icon names change how easy is it to find/replace system-wide?

I would assume it can't be too hard, but it'd be great to get some input from FE here.

Is it possible to determine if some icons are not being used and should be deprecated?

Maybe we could do an audit by ourselves? Create a list of icons and then designers can mark them if they used them. We checked the ones that aren't marked and maybe we could deprecate some of those...

How can we incorporate the icons into Pajamas?

I'm not sure what exactly you mean by this. We currently have all our icons stored in GitLab SVG. Do you think we should move them to Pajamas?

How can users easily use icons in documentation instead of emoji?

That's an interesting point. I think we could benefit from this as well, especially if they were components so that if we updated or changed an icon, they'd get updated everywhere they are being used. We could reinforce some of the instructions in our docs with the icons we use in the UI. It would help reinforce the meaning of these icons too!

@jeldergl

Are 8px, 16px, 32px, 48, 72, and 256 sizes necessary for every icon?

Agreed with Matej here

If icon names change how easy is it to find/replace system-wide?

@shampton might be able to give a clear answer here.

Is it possible to determine if some icons are not being used and should be deprecated?

Again I defer to @shampton. We might be able to do a quick code analysis.

How can we incorporate the icons into Pajamas?

Also, unsure what you exactly mean. My assumption is you mean to move https://gitlab-org.gitlab.io/gitlab-svgs/ inside of http://design.gitlab.com which I think is a great idea .

Actually, we do something similar with gitlab-ui (see https://gitlab-org.gitlab.io/gitlab-ui/ for the live website). This information actually lives in design.gitlab.com as well. When navigating to a component on design.gitlab.com and clicking the "vue component" tab, that information is sourced from gitlab-ui.

A short term solution would be to link to it directly similar to this example from https://gitlab.com/gitlab-org/design.gitlab.com/merge_requests/254

How can users easily use icons in documentation instead of emoji?

@leipert might be able to help us here. My assumption here is that you mean the design documentation at design.gitlab.com which would mean we would need to load in our SVG library if I am correct.

What troubles have you encountered when using icons (that aren’t already in an issue)?

Updating an icon means updating it in many different places (pattern lib, instance lib, and svg project). GitHub does this simpler through https://github.blog/2018-04-12-driving-changes-from-designs/

@dimitrieh @jeldergl

If icon names change how easy is it to find/replace system-wide?

Theoretically it's not too difficult to do a find and replace, the difficulty is when the same name is used for things other than icons such as class names. For instance, the admin icon is called admin, so it would be a take a little more time to make sure we replace only the references to the icon.

Is it possible to determine if some icons are not being used and should be deprecated?

It should be as easy as the find/replace problem. Just a simple search to see if the icon is being used throughout the code, and if not we can deprecate it. It of course takes some time to be completely sure, but it wouldn't be a hard task.

Let me know if you have any follow-up questions.

Sounds very similar to what I wrote this morning #49 (comment 186123942)

Theoretically it's not too difficult to do a find and replace, the difficulty is when the same name is used for things other than icons such as class names. For instance, the admin icon is called admin, so it would be a take a little more time to make sure we replace only the references to the icon.

Interesting, something to consider for our icon naming convention!

To be honest, I don't think we need to find-and-replace most icons, theoretically if we re-vamp our icons, just replacing the icons in GitLab SVG should be good enough. We even could publish a beta version from the branch and use it in GitLab CE to see the difference.

The only problem could be that we are using icons in two different places with two different meanings, see: #18 (closed)

changed the description

@jeldergl I love these! Especially the light weight ones, although @matejlatin is probably right; I'm guessing they won't look great on non high-resolution screens.

If icon names change how easy is it to find/replace system-wide?

Pretty easy, just do a global find-and-replace. We do have different implementations depending on whether they're used in Vue or Haml, but it'll still be easy to replace them. However, we might not need to at all- if we're completely replacing the icon we can just update the SVG and keep the name the same.

Is it possible to determine if some icons are not being used and should be deprecated?

A global search across the code base will probably be helpful here.

I think we could benefit from this as well, especially if they were components so that if we updated or changed an icon, they'd get updated everywhere they are being used.

YES!

if we're completely replacing the icon we can just update the SVG and keep the name the same.

After looking through what exists today I think we should rename them (when necessary) and perhaps even implement a BEM style. It could help to organize them better, e.g., git--commit instead of commit or git--compare instead of comparison would be much clearer.

As far as lighter weight, as long as they’re aligned to a pixel grid when created and not unnecessarily scaled in the UI they should be crisp and prevent antialiasing for any monitor. Remember pixel fonts in Flash on old CRTs ;)? What I think can trip up 1px stroke icons is not the stroke weight (any stroke can be antialiased and cause blur), but the fidelity of the icon. With 1px you have much more freedom to add detail to the icon, and so there’s a temptation to add more lines which can muddy it up or increase cognitive load.

At this point I'm exploring thicker weights (or maybe even solid) for primary/sidebar/utility navigation and actions, and lighter for things like pipeline status or files/folders/documents.

I’ll also be looking at them in the context of dark/light UI where lighter elements can cause ghosting (due to light bleed) and appear thicker/wider than they actually are.

I think we should rename them (when necessary) and perhaps even implement a BEM style. It could help to organize them better

Fully agree here in regards to the BEM style naming of icons.

I like the idea. We should come up with a good convention though, as renaming all these icons in all the places is very tedious and we are likely to miss some, see e.g. @shampton's comment. #49 (comment 186241533)

On the Vue side of things it could be easier, as we use the Icon component and we could do some mapping there, but we still use a font-awesome icons and from the Ruby part of the code base we use icons directly.

here I described how to rename things and why it is so burden-some ATM: #18 (comment 88830904)

@jeldergl I also like the idea of using BEM, although renaming these in a sane way using a single dash separator (-) could suffice. /cc @timnoah

@leipert thanks for linking to #18 (comment 88830904).

Here are some tests based on a representative set of thick and thin.

Given that I‘m working within a 16px grid (14px for primary shape with 1px padding) I can say that the thin (1px) versions are harder to create because you cannot center a 1px line within, you either have to place the entire icon off center, or use 2px for some elements, which I’ve chosen to do when necessary.

And a sense of the grid…

changed the description

I am a fan of the light icon style, as it gives a cleaner and more clear distinction to the icons, plus more legible on darker backgrounds. My main thought is that they should remain legible on lower quality/resolution screens as well though.

Are 8px, 16px, 32px, 48, 72, and 256 sizes necessary for every icon?

@jeldergl I only see them at 16, 24, or 32. I'm not sure why we're missing 24 as a size...It seems like a common size that works in many cases. And I prefer the thicker icons because of the increased legibility.

Seriously nice work on this!

@jareko I’m assuming 24px is not an option because 16px is the base and icons have to be a multiple of 16 to remain crisp.

That presents a new issue if we create thin 1px stroke icons in a 16px — they cannot be halved to create an 8px size. This is fine by me as I think anything that small should be created specifically for that case.

I’m assuming 24px is not an option because 16px is the base and icons have to be a multiple of 16 to remain crisp.

@jeldergl the custom icons added in gitlab-svgs are vector icons so there shouldn't be any crispness issue in any size.

There was recently a need to add a missing size (24px) for the spinner (loading-icon) component in the design system to be used during implementation. See discussion in https://gitlab.com/gitlab-org/design.gitlab.com/issues/336#note_186962099. /cc @jareko

I'm also in favor of not using icons with 1px stroke.

@gtsiolis even though they’re vector, they still get rendered as a physical pixel on screen. You won’t notice it on (most) HDPI, but on other screens you will get sub-pixel antialiasing. A 16px icon has to scale 1.5x to achieve 24px, so a 1px stroke becomes 1.5px effectively and will look fuzzy on a standard display. The key is to use whole values, align to the pixel grid, and any scaling should also result in whole values.

Here’s a quick example with 16px on grid, 16px off grid, and 16px on scaled to 24px.

On these two points…

How can we incorporate the icons into Pajamas?

Including an Components > Icons section in Pajamas that either pulls them in or keeps them maintained there.

How can users easily use icons in documentation instead of emoji?

Thinking about extending GFL with a Ruby helper (I think this is how it’s done today) to effectively expand markdown into accessible SVG. This would primarily be for internal GitLab use within our documentation. e.g., in docs I've seen used for "in progress," but it’s announced as "hammer and pick" for screen readers — quite a difference from intended meaning. With inline SVG, or even as img the code to remember would be cumbersome to use, so conceptually something similar to how we handle alerts in markdown, but with parameters for text alternative, color, etc.)

@mikelewis for awareness

@luke have you used any of the existing icons as the literal or conceptual basis for marketing illustrations? Just want to make sure that if we change anything we keep in sync.

@mikelewis how often are screenshots used in documentation? Are icons referred to for instruction or reference?

@jeldergl awesome work here, and thanks for thinking of the marketing side of things!

There's a GitLab flow illustration that comes to mind, and I believe it's the only one I've pulled icons for.

It's used in a few places, but you can see it here (not sure what's up with the page layout).

marked this issue as related to gitlab-design#303 (closed)

@jeldergl One concern I have: We still have some places that use font-awesome icons. Our current icon style kind of matches the font-awesome style, at least the visual difference is not too big. Should we migrate those font-awesome icons first before we start replacing them?

(Amazing work by the way)

I think replacing all icons could better take place in smaller efforts and in parallel with replacing the remaining font icons used since these span across HAML templates, Vue templates, and more.

Some past efforts in replacing font icons were tracked in https://gitlab.com/gitlab-org/gitlab-ce/issues/33757 and https://gitlab.com/gitlab-org/gitlab-ce/issues/38499 although these are missing many new icons introduced since then.

@leipert are you suggesting migrating what’s using font-awesome to SVG, then replace? I’d like to know where those are being used too if possible.

@gtsiolis definitely plan on a slow release, or smaller efforts. I’m working on a few issues that require icon updates and plan on doing some user testing there too. Ideally this issue is a catch-all and helps directionally. ;)

@jeldergl I am suggesting that we should be mindful, we currently have some things that are font-awesome icons, but as @gtsiolis suggests, we probably can deal with things in parallel.

marked this issue as related to #18 (closed)

Are 8px, 16px, 32px, 48, 72, and 256 sizes necessary for every icon?

Custom icons added in gitlab-svgs are vector-based so size shouldn't be a problem here. We're not storing or exporting any icon in multiple sizes. Sizing is mostly done through CSS or JavaScript.

It's up to the design documentation to specify which icon sizes should exist in the source code of the product. See also #49 (comment 187032326).

Here's also an approximate overview of the icon type usage across the codebase. Overall, the source is split into two. About ~580 icons are using font icons and ~530 icons are based on vector icons.

Notes

Vector icons also include custom svg icons that are not part of the gitlab-svgs. See /app/views/shared/icons.
There are a few more (50~100) instances within specs that are not included below.
The rest of the icons not counted below, as well font icons used in HAML and Vue templates, are most probably using the default icon size that is 16px unless overridden with CSS or even using classes like 2x.

Icon types	HAML templates	Vue + JS templates
Font / Total	410	120
Vector / Total	230	350

The icon sizes vary a lot while the product is also using sizes that are not even documented.

Icon sizes	HAML templates	Vue + JS templates
Vector / `8px`	2	1
Vector / `10px`	1	2
Vector / `12px`	13	22
Vector / `14px`	6	3
Vector / `16px`	60	66
Vector / `18px`	13	14
Vector / `20px`	5	4
Vector / `24px`	12	12
Vector / `32px`	6	8
Vector / `36px`	1	-
Vector / `40px`	9	-
Vector / `48px`	1	1
Vector / `50px`	10	-
Vector / `60px`	-	1
Vector / `64px`	-	1
Vector / `100px`	1	-

If icon names change how easy is it to find/replace system-wide?

Well, it depends. Icons can be found within HAML templates, Vue templates, JavaScript, Specs, etc.

Icons in HAML templates can be easily replaced by replacing the icon method with sprite_icon. For example, see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20199/diffs#8034d122df8d5aed21e36c16f6d8ed93f87dfa86_4_3.
Replacing font icons in vue components with svg variants can be a bit more complicated. For example see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18632.
Things can get quite complicated once you decide to mass replace icons in vue components. For example, see https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20748.

The above may help get an overview of the effort required to replace font icons with svg variants one by one or massively as mentioned in the discussion in #49 (comment 186956674).

As long as the svg variants are published through gitlab-svgs, replacing the icon name in sprite_icon method for HAML templates and name value in vue components should suffice.

See also discussion on the bounding box which is related to the optical size that you've mentioned in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20748#note_99714456 and https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20748#note_100173583. See also relevant issue in https://gitlab.com/gitlab-org/design.gitlab.com/issues/113.

Is it possible to determine if some icons are not being used and should be deprecated?

There have been cases were svg icons have been updated but the codebase was using older svg variants alongside with font icons to convey the same meaning. See https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8448.

Some deprecations are mentioned in https://gitlab.com/gitlab-org/gitlab-ce/issues/33757 and https://gitlab.com/gitlab-org/gitlab-ce/issues/38499 but I don't think that list is thorough enough.

How can we incorporate the icons into Pajamas?

That's an interesting question. I'd say it's ok to integrate icons in one page within /components if possible only because we are injecting these icons using a Vue component. This could just list all icons as a first iteration.

In the long run, it would be nicer to consider using case and placement, as you've said, and group these icons per category or type:

Icons for navigation

Icons for actions

...

I remember that @pedroms grouped the icons alphabetically in gitlab-design@31684f87 but grouping by case sounds optimal and this would be really nice to surface into the design system, outside the sketch files.

Also, it's totally fine to keep the svg icons in a separate repository for many reasons but eventually these should be placed conceptually under the same umbrella (Pajamas).

How can users easily use icons in documentation instead of emoji?

I would carefully approach this since there was a huge effort last year to switch from image-based emoji to native unicode emoji. This introduced a number of performance improvements. /cc @MadLittleMods

The problem with emoji is in regards to accessibility. They aren’t announced to assistive tech consistently, or most often the meaning a user is trying to convey is not the same as what’s announced.

@jeldergl I had a past project where I shared similar concerns and this sparked my curiosity to go over old notes. For the most part back in 2014, we found it was hit and miss. Just looking over what's available today (VoiceOver on Mac, Narrator on Windows, TalkBack on Android) it does seem like there is a much higher degree of consistency, but it still does appear as though some say "emoji" after the description and others do not. Stumbled upon How do people with vision impairments… use emoji? by Veronica Lewis. Great read!

the meaning a user is trying to convey is not the same as what’s announced

That's a great point but I think this could also be said of even the written text and in some ways is the beauty of language (multi-layered meanings). For instance, I still don't understand why @gtsiolis and @pedroms love using the emoji but I have learnt over time it means something good . The context is key.

This won't be around for long but this is roughly what the emoji means. I'm just going to paste this here for anyone still wondering and for future reference.

Moreover, there was also an interesting discussion during Contribute between @pedroms and @andr3 about having an emoji-based token passed around multiple assignees in a merge request to help indicate turns. Apparently using a ball-based emoji like sounds optimal.

What's up with the emoji?

It’s nothing extraordinaire, basketball is a team sport and most of the times it’s implies an agreement or a way to say i like this, or ok, let’s play ball or even done, let’s move on. In fact, some times I won’t agree which makes even better.

Other than that, it’s round, eye pleasing, and matches the border radius of the parent container in slack!

Fun fact: More than 40 people asked me about at the Contribute which was quite fun to say the least.

Thanks for bringing up these points @jeldergl and mentioning scale fidelity and optical sizing! Sorry for spamming here but I had to split the answers into separate discussions. Hopefully, this will help anyone to follow along.

changed the description

marked this issue as related to gitlab-design#102 (closed)

marked this issue as related to gitlab-ui#185 (closed)

promoted to epic &1557

promoted to epic &1558 (closed)

mentioned in epic &1557

mentioned in epic &1733

Icon Audit and Refresh

Why

What

Example Principles

Example Decision Tree

Questions

Resources

Designs

Child items ...

Activity

Are 8px, 16px, 32px, 48, 72, and 256 sizes necessary for every icon?

Notes

If icon names change how easy is it to find/replace system-wide?

Is it possible to determine if some icons are not being used and should be deprecated?

How can we incorporate the icons into Pajamas?

How can users easily use icons in documentation instead of emoji?

What's up with the emoji?

Icon Audit and Refresh

Why

What

Example Principles

Example Decision Tree

Questions

Resources

Relates to

Activity

Are 8px, 16px, 32px, 48, 72, and 256 sizes necessary for every icon?

Notes

If icon names change how easy is it to find/replace system-wide?

Is it possible to determine if some icons are not being used and should be deprecated?

How can we incorporate the icons into Pajamas?

How can users easily use icons in documentation instead of emoji?

What's up with the emoji?