[NEW] Tokens/ Icons
jeffreytr opened this issue · comments
Component Name
Icons
Zeplin link
zpl://screen?sid=https://zpl.io/V4Q43NM
Product team
All
Design lead
Additional info
Adding a .zip folder of all the exported SVG icons here. Let me know if anything seems missing or incorrect.
You can refer to naming conventions in this table on Notion: https://www.notion.so/artsy/2520b95ca7ed4d918b5cce46e30be71b?v=083ea403b3034ff5a8f26bd74d4c8184
Checklists
Design
For Tokens
Color, type, spacing, icons, etc
-
Is it serving a purpose? (is it needed or just purely decorative?)
-
Can it be merged with any existing styles on the site?
-
Has it been pressure-tested in all instances?
-
Does it meet accessibility standards? (min type size, color contrast)
For Elements
Buttons, links, loaders, inputs, dropdowns, etc
-
Is it using up-to-date tokens from above?
-
Have all states been captured? (hover, selected, disabled, focused, normal, thinking, errors)
-
Have all transitions/animations been defined?
-
Is it useable? (Considering touch targets, screen sizes)
-
Is it consistent with the rest of the visual system? (Corner radius, stroke weight, form, shadow, opacity, etc)
-
Does it meet accessibility standards? (is it keyboard navigable, does it have required accessibility markup)
-
Does it render and function properly in Artsy supported browsers?
For Components
Nav, modules, modals, cards, etc
-
Is it using up-to-date elements and tokens from above?
-
Does it communicate clearly? (Copy, writing style/tone)
-
Is it flexible? (Internationalization, text wrapping)
-
Is it logical from a UX perspective? Does it follow paradigms set on the rest of Artsy?
-
Has responsive behavior at all breakpoints been defined?
-
Have all transitions/animations been defined?
-
Does it meet accessibility standards?
-
Does it render and function properly in Artsy supported browsers?
Engineering
Accessibility
-
Do all images and multimedia have
altortitletags? -
Are semantic elements used appropriately (
nav,button, etc)? -
Are new components keyboard-navigable?
-
Are hover interactions available by other means?
-
Are
aria-attributes included where appropriate? -
Has a Chrome Devtools accessibility audit been performed?
Compatibility
Has the new component been reviewed in Browserstack:
-
Desktop Chrome
-
Desktop Edge
-
Desktop Safari
-
Desktop Firefox
-
Android
-
iOS
With our focus on accessibility, these SVG icons should probably all have titles (http://web-accessibility.carnegiemuseums.org/code/svg/).
In the attachment, it looks like the titles were all generated by Sketch, based on some organizational structure. They don't appear to be very meaningful for users, though. For example:
From icon_check_circle.svg
<title>BasicAction/CircleCheck/Md</title>
I'm not sure if it's easy to edit those titles in Sketch. If it's easy, I think we should do that & re-attach them. If it's not easy, then a list of all the titles would be helpful for us to cross-reference as we build these out.
Note 1
We may not need titles for all of them. Maybe some of them don't have semantic meaning, in which case we could get by without a title. Maybe others have semantic meaning, but it depends on the usage context - in this case we could pass a "title" prop into the component.
Regardless, it'd be useful to know which ones have (zero) semantic meaning, which ones have (exactly one) semantic meaning, and which have (multiple) semantic meanings depending on usage context.
Note 2
For what it's worth, we have a lot of existing icons in palette that don't have <title> elements but need them. I don't think that work fits into this issue, but ...maybe?
Does this list of Icons replace the existing Icons in Palette?
https://palette.artsy.net/tokens/icons/
And I wonder if we've considered how we'll roll this out - @zephraph and or @damassi couldn't clobbering our existing icons break clients in a pretty surprising way?
@jonallured Yep! This batch should accommodate for all the existing icons on Palette and replace them. Unsure about the best way to roll this out though.
Hmmm... A few things.
- We need to make sure the svgs are optimized. @mdole just went through that process in palette. It's a bit of a manual process by running them through svgo and then reactifying them.
- We definitely should spot check these new icons. In general I believe it should be a relatively safe to roll them out, but comparing builds of the palette docs to ensure there's no misaligned or oddly broken icons is important. Checking some clients would be advisable too.
I don't think there's an easy way for us to tackle importing svgs directly without touching them into palette. It's a relatively hands on (but not entirely difficult) process. If changing the icons is something we intend to do often, investing in build tooling or overall automation would be good... but I feel like it's likely not.
From an accessibility perspective, I'm not sure how important the title/alt is. Certainly if an icon is to be interacted with like a button or has semantic meaning that would break the understanding of a certain thing without it. If it's just there for a garnish, then maybe not? I'll defer to you folks on that 🙏 .
Re: accessibility/titles - when @jeffreytr updated the notion doc that describes all the icons (https://www.notion.so/artsy/2520b95ca7ed4d918b5cce46e30be71b?v=083ea403b3034ff5a8f26bd74d4c8184), he included semantic titles for all of them. It would be good to use them when we create/update these icons.
I've got a draft PR for this with #308.
Catching up after being OOO - @jeffreytr regarding optimization, this Sketch plugin looks like it might be an ideal solution that wouldn't add a lot of overhead. Do you think that would be a reasonable way to optimize going forwards?
🚀 Issue was released in v4.0.0 🚀