[Feature Request]: Construct icons in a way to facilitate animation

[lee-chase]

Summary

The desire to add mirco-interactions/animation to UI is becoming ever more pressing. A modern web page may not be perceived as being dynamic, fluid and/or delightful without them.

The current construction of Icons is problematic when it comes to animation. Many use overlaying paths to create holes in an icon and do not construct the icon from logical parts that can be addressed. It is possible that there was a valid reason for doing this in the past, specifically URL lookup in SVGs varied from browser to browser. However, this now appears to be consistent.

Other related issues have been raised in the past but realistically #7346 cannot work without changing the way icons are constructed.

As an example of this difficulty it would be impossible, with just CSS, to animate the first of the examples in this codepen in the way the final example does.

https://codepen.io/lee-chase/pen/qBVNZog/5c1d3b69e235a38dfc6a500329ae9e44?editors=1100

Justification

The current construction of numerous Carbon Icons directly conflicts with IBMs Chief Design Officer & Global Vice Presidents strategy to design in key moments of delight via micro-interactions and visual hooks that are memorable to our users.

Desired UX and success metrics

• The standard mechanism for constructing and approving icons produces icons constructed of logical parts that can be addressed from CSS.
• The most commonly used Carbon icons are constructed in this way
• A page/issue allowing the animatability of each icons is published.
• A page/README documenting how to update icons to make them animatable is published.

Required functionality

• Icons must be constructed of logical parts. In the case of Edit16 / EditOff16, which would become a single icon) that would mean Pencil and line with an optional eraser, pencil tip etc.
• Logical parts of the icon should be addressable by class.
• Masks should allow for a unique ID generated or provided by the user to stop clashes.
• Similar icons that represent two states of the same thing e.g. Edit16 / EditOff16 should be a single icon with a style section to switch between the two (see codepen)
• Fill in CSS should NOT override colors in an icon. This affects masks that need to be used to when creating cut-outs.
• currentColor should always set the icon color
• Mask white areas should be oversized as necessary to allow rotation around any point.

Specific timeline issues / requests

To allow delivery of OKRs within the calendar year.

Available extra resources

Happy to discuss, formulate plan of action and contribute when plan agreed.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[johnbister]

@lee-chase Hello! This comes at exactly the right time. https://github.com/carbon-design-system/carbon/issues/7346 was an effort that fizzled out last year for many reasons, but one of the obstacles was exactly what you said: to do this "right" we really might have to rebuild the icon library so it works for both static and motion.

@kristastarr , myself, and others have restarted the effort and are passionate to see this project being built by the end of the year. Would you be interested in joining us for one of our meetings? We're excited to have the opportunity to slow down (a whole year!) to tackle this project. We're still identifying more problems to solve, like icons with state changes (as you mentioned), margins, shapes vs paths, etc. It's a fun group and you can decide your level of participation. No pressure, but I know we would benefit from your voice.

Thank you again for taking the time to submit. 100 percent yes from me.

[lee-chase]

Definitely invite me along @johnbister. I think if we can establish and verify (cross-browser) a pattern for constructing SVGs that is clean, logical and ideally producible from sketch or similar then we are over the biggest hurdle of making things possible.

Once in a good place, I think we should either take over an existing hackathon or set one up to jump-start production of animations.

[ljcarot]

@johnbister please provide an update to this issue. How many icons will receive animations and how many have already been animated?

[kristastarr]

To add some additional clarifying info here - this issue is a request to re-construct the icon code existing within the Carbon icon library so we could animate the icons within the actual Carbon library code. The way the Carbon icons are constructed in the Carbon library currently requires modifications to the svgs in order to animate them. Since re-creating all the icons in the Carbon library would be a major effort, and a challenge due to the carbon icon builder code which constructs the icons, the short term solution was create the separate library (the icons-motion library) which contains icons that have been reconstructed in order to animate. So devs will still be able to import static icons from the Carbon library, and will import animated icons from the icons-motion library. It be ideal if in the future, we could import both static and animated icons from the core Carbon library but for that we would need to have additional discussions about how to make that happen.

[johnbister]

@lee-chase Hey Lee! I re-added you to our weekly discussion meeting if you'd like to join. We'd love to show you the progress we've made since we all last spoke and have your take on it. Like Krista said, we're still working on a separate package, but we agree with you on the long term goal on unifying them.

@ljcarot You can track our progress in real time HERE. We have 43 icons for operations, 25-30 for navigation so far, and around 50 icons from our initial exploration that haven't been included yet. Ideally we will be animating almost all of the Carbon icons, but we are taking it section by section and using data from Figma usage to make decisions on which to include/exclude. The total number to be animated is TBD.