External source of illustrations

[weronikaolejniczak]

Opening this discussion to follow up on #3653.

Context:

The recommended approach in 2021 was: #3626 (comment).

Questions:

1. Is there still a need for a central illustration store that can be reused between Kibana and Cloud UI?
2. Is the recommended approach still valid? Do we want to change it in any way, considering the current library state?
3. Should the repository / package be private or public?
4. Should we create a component for illustrations (EuiIllustration) to style it from EUI, support dark mode etc?

Next steps:

1. Create an epic.
2. Create tasks within the epic to follow the above-mentioned recommendation.
3. Close the discussion.

[clintandrewhall]

@elastic/appex-sharedux has been talking about this for a while, but it hasn't been prioritized, (as it would more-or-less maintain the status quo without adding a lot of benefit yet).

I would love any approach also take elastic/kibana#221938 and elastic/kibana#206540 into account.

@paulinashakirova also wrote a draft PR with an exploration of illustrations for Kibana: elastic/kibana#217518

1. Yes, no question. It also furthers the philosophy that EUI is more of a design system and framework, than just a collection of components.
2. Consider the theme-adaptive approach.
3. It must be public to be used in Kibana.
4. That would be great...!

[ryankeairns]

+1 Clint's summary and, by in large, Gareth's recommended approach is still valid.

Marketing Services creates these illustrations, and they do not currently have the bandwidth to replace the set we use today.
I am not clear on all the pros and cons of adding these to the EUI repo versus a separate, new one. I sense the former would be fine as this set does not grow or change frequently (unlike 3rd-party logos); on the other hand, we don't want to force all EUI consumers to take these in if they don't need them. Also, it's likely that these should only be used by Elastic.

Something like an EuiIllustration wrapper component could ease usage, but that may not be necessary. We could start by extending EuiImage and mapping the illustrations to names... that alone would be nice and would also make the use of images in EuiEmptyPrompt easier as well.

[ek-so]

Plus to that, although EuiIllustration component that translates tokens automatically between modes, would be something very nice to have imo — esp. as we are supporting 2 modes (and maybe we will support a combination of them on one screen) which makes things harder to maintain otherwise.

[weronikaolejniczak]

on the other hand, we don't want to force all EUI consumers to take these in if they don't need them

I don’t see that as a blocker, since illustrations could be packaged as a separate library (e.g. @elastic/eui-illustrations). If it needs to be public then it can absolutely be in EUI.

I am not clear on all the pros and cons of adding these to the EUI repo versus a separate, new one

Off the top of my head...

EUI repo

Advantages

• infrastructure is already set up and in place
• the repo has existing traction and visibility, which would make ongoing maintenance easier
• we’d be able to oversee and review illustrations more effectively
• the illustrations can be easily shared across both Cloud and Kibana

Disadvantages

• would likely be slower in PR reviews
• there are no codeowners setup atm

Separate repo

Advantages

• could be more lightweight and modular, ideal if we want to keep EUI lean or offer this as an optional dependency
• would be a different release cadence
• would be more available and approachable to update outside of EUI processes
• the review could be set up for design org which has more availability, making PRs faster to approve

Disadvantages

• it's unclear who would own the setup and maintenance responsibilities

[clintandrewhall]

Another advantage to a separate repo would be a different release cadence, and availability for designers or others to update illustrations out-of-band from the EUI release cadence. What's also nice is review gating could be set up for the design org, making PRs faster to approve. A separate package like this could also be set up for tree-shaking, (assuming the application could take advantage of it).

Setup and maintenance would likely fall to this team. But that would be the same wrt including them in EUI...?

[weronikaolejniczak]

@clintandrewhall tree-shaking is an option both for a package within EUI monorepo and in a separate repo, it's about how it's bundled and consumed, so I omitted it for advantages. I updated the ☝🏻 list.

[acstll]

yes, even if closed, you can follow up there in the same issue #8710, we will read it — using a completely different thread is not nice

[p-young]

Sorry, removed. I misunderstood.

[acstll]

no worries