EuiIllustration

[elizabetdev]

EuiIllustration is a react library of illustrations that attempt to bring consistency to our elastic products and solve the following issues:

• Lack of consistency on the way to import illustrations. Images can be imported as inline SVGs, or as just as an image file via the <img> element (png, SVG, or jpg).
• Lack of consistency in the way we optimize images.
• Lack of consistency in the way we handle the illustrations' colors in light and dark themes.
• Difficulty to update an illustration. Right now, to update an illustration, we need to search where the illustration lives in a repo and replace it with the new image. In some scenarios, the illustrations are used inline, making it even more challenging to locate them.
• Difficulty to find what are the available illustrations.

The library EuiIllustraion can bring to our products a lot of advantages and solve the above issues.

Consistency

We ensure consumers are only using approved illustrations that share our aesthetics.

Ease of use

Consumers only need to import the component and pass some props. The illustrations are optimized and follow our EUI standards. These props will ensure that light and dark themes are handled correctly and no need for much effort just to show an image.

Updates

When the design team needs to update our brand, the EuiIllustration turns this task easier. By updating the package, elastic products are easily up to date.

One place for all the illustrations

Right now is difficult to locate an illustration. This project can ensure that we have a common place where the illustrations live for our products. The illustrations will live in a Figma library and also in a GitHub repo/website.

POC

You can find the POC of the project here: https://github.com/miukimiu/eui-illustration (private). This project is a monorepo containing 3 packages:

• docs-eui-illustration is a NextJS app where we can preview the illustrations and generate the code to use in our internal products. One commonplace to share our product illustrations. You can find the preview here: https://eui-illustration.vercel.app/

It's also worth mentioning that in this project we can see how the EuiEmptyPrompt can work in conjunction with the EuiIllustration.

• figma-eui-illustration a Figma plugin to export the illustrations and ensure the best optimization and EUI standards. The plugin is not 100% developed... 😬 But the idea is to make designers' lives easier. Every time a new illustration is added to Figma, designers would just need to export the new illustrations and added to our repo or the plugin could open a PR.

• package-eui-illustration is the library.

// to install
yarn add @elastic/eui-illustration

// to import
import { EuiIllustration } from '@elastic/eui-illustration';

const MyComponent = () => <EuiIllustration name="indexPattern" theme="light" />;

// to build
yarn build

Decisions we need to take

1. SVGs might not be the right format. The illustrations come from Adobe Illustrator and might contain a lot of shapes. In some situations that I faced, I couldn't optimize the SVG to have a size below 4MB. So we need to consider PNGs. Another issue, was when running a script to optimize some shapes lost their forms.
2. Where should this project live? Is it a package in EUI monorepo ([Meta] Monorepo and package-based publishing #5540)? Is it a separate project? Things we need to consider. The illustrations are part of our brand and we don't want external projects to use them.
3. How can we work better with the Design team? Ideally, we would like to have the illustrations in a Figma project. But the illustrations are made in Adobe Illustrator. When opening the illustration in Figma sometimes the masks don't work well. Should the illustrations be added as PNGs (light and dark) or we should use SVGs (picking this format the illustrations should be simplified with fewer elements and masks).
4. Do we want/need to track usage of illustrations that aren't included in the Illustrations package? E.g. if Lens has a custom illustration and passes it into EuiIllustration, do we want to know about that?

[elizabetdev]

I talked with @JessSmithSup and we might work with PNGs.

Here are a few screenshots of issues I run with SVGs. First one, I tried to optimize the following svgs and I never could go below 4MB.

Another issue I run to is when we open an SVG created in Adobe Illustrator in Figma the masks don't work as expected:

To fix this, we would need extra work. But even with the extra work to make it look better in Figma, once exported as SVG the size would continue to be around 4MB due to a large number of elements.

The Design team could simplify the illustrations but we would lose our identity.

With that said, I don't see any benefit in using SVGs besides the high quality they can provide.

I might do some tests with PNGs and see how can we support retina and non-retina displays.

[elizabetdev]

At some point, I had a description for each illustration but I removed it because it was making the website cards take too much space.

But only showing the title might lead to different interpretations for an illustration. To avoid situations, where the same illustration is used in different contexts and means different things we need to bring the description back.

[JessSmithSup]

@miukimiu the design team can share pngs of both light and dark modes. What is an optimal size ration we should export images at? We would also like to update some of the images currently in the library. How would you like us to share images?

[elizabetdev]

Hi @JessSmithSup,

I sent you an invitation to the Figma Project. You can add the images on the page Illustrations PNG in retina @2x. You have one page called Illustrations SVG that you can follow as an example.

What is an optimal size ration we should export images at?

I found that the size 560px * 372px works ok. Some images in cloud had 600px * 400px or 360px * 330px. In Kibana others had 800px * 400px or 550px * 420px. So I tried to find a size that would work to make all the images have a common size and avoid white space top and bottom.

But I think you can decide what's the ideal size 600px * 400px or 800px * 400px seems ok to me if we can avoid the white space on top and bottom.

You can see from this example the different sizes of the original illustrations:

That's the reason why I picked a rectangular shape and why I want to avoid white space on top and bottom:

[chandlerprall]

Complementary to the questions above in #5546 (comment), we also need to explore format and scaling options. For the format, webp is now supported by recent versions of all major browsers (except Safari requires Big Sur, so ish). Scaling should probably cover 1x and 2x at minimum - a brief googling shows some phones have 3x or even 4x, but this is probably not important enough for us to cover at this time.

However, I don't think the illustrations project should dictate either of those things for downstream projects and instead be aware that further processing is likely to be done when images are used by an application. Many apps import images from the source code, and the bundler (e.g. webpack) is configured where to put the image so it can be loaded by the browser later - somethings that configuration also defines optimizations and other passes at the images.

IMO this means any prevalent, lossless image format (png, webp lossless) would be fine. Likely an upscaled (3x or 4x) version. Or maybe the source SVGs are fine if downstream apps have to process things anyway.

[chandlerprall]

To help explore how we can best provide image files for consumption, any input from
@elastic/kibana-operations or @elastic/kibana-core is welcome!

[elizabetdev]

Or maybe the source SVGs are fine if downstream apps have to process things anyway.

I think we should avoid this format because the images also need to live in Figma and as mentioned here #5546 (comment), not all SVGs coming from Adobe Illustrator renders properly in Figma.

[pgayvallet]

not all SVGs coming from Adobe Illustrator renders properly in Figma

Not a designer, but to have integrated quite a lot from AI, it's usually just an issue with the export format not being properly configured? AI's default config for svg exports is quite terrible.

Or maybe the source SVGs are fine if downstream apps have to process things anyway.

Sorry, but if a proper svg is provided as the source, why would the downstream apps need to process them? Wouldn't the vector format allow to avoid any kind of resizing or scaling altogether ? We would eventually just add a svg cleanup/compression plugin to webpack (if not already present), and that would be it?

[pgayvallet]

But insight from @elastic/kibana-operations (summoning @spalger) is very welcome

[ryankeairns]

While this seems useful - and there is some need/demand for it - EUI is not the best home. As noted above, one of the open considerations is...

Where should this project live? Is it a package in EUI monorepo (#5540)? Is it a separate project? Things we need to consider. The illustrations are part of our brand and we don't want external projects to use them.

These are specific to Elastic, created by the Creative Services team, and are only intended for Elastic properties whereas EUI has a broader and more agnostic point of view. Given this here discussion is in the EUI repo, I am going to close it out and follow up with AppEx/Kibana eng teams on a product-level home (plus guidelines) for using both illustrations and custom SVGs... many of which already exist in the Kibana repo.