Camilo Sketch plug-in discovery #2231
Replies: 4 comments 6 replies
-
|
Also noting here that React Sketch App is stale too. Last release was in 2020, and last commit was in March of 2021. |
Beta Was this translation helpful? Give feedback.
-
|
Here's a thought, what if we saved components from storybook as PDF (vector) or SVG and built a library of components that way? We could then combine those files in various ways and they could be imported into any tool that can utilize SVG (any of them).. It wouldn't allow for mass editing but it would give you a library of components with the code-appropriate spacing, color, etc.. Different states & configuration options could be set in the storybook stories to give different versions. All the components would be rendered from storybook meaning all the tokens would be up-to-date with the codebase.. |
Beta Was this translation helpful? Give feedback.
-
|
Some other tools: https://cssbox.sourceforge.net/webvector/ Also making our own tooling isn't out of the question. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah I was thinking this would be a discovery ticket, not looking deeply into it right now. |
Beta Was this translation helpful? Give feedback.
-
|
I imagine it would be possible one way or another, even printing to PDF from a headless chrome instance might do it. |
Beta Was this translation helpful? Give feedback.
-
|
👍 We'll have to play around with PDFs in Sketch and see if they'd be feasible. Playwright has a function for generating a pdf |
Beta Was this translation helpful? Give feedback.
-
|
They also have notes about getting it to print with the |
Beta Was this translation helpful? Give feedback.
-
|
Ahh nice 🎉 |
Beta Was this translation helpful? Give feedback.
-
|
I spent time last week trying to dig into the specific issues with Camilo that you've outlined here, @babsdenney, because we didn't really have any other leads. The hope of my discovery effort was to pinpoint the failures with the Camilo process so we could think about shoring them up by contributing features to the plugin or finding other workarounds. What I ended up realizing was how inadequate Sketch is for what we are trying to do and how much work would be involved in reshaping our Sketch assets to conform to the pattern that this workflow requires. Going back and exploring the string of technologies that led us to Camilo, I came to the conclusion that Sketch is a dead-end for this kind of work. This kind of work is a multi-themed design system. And this kind of work is also a design system where the source of truth is our component code. We don't have to generate our design assets from code, but it would be a nice feature. That's what made us explore things like React Sketch App, which is dead. I even found this old, abandoned project of Kent C. Dodd’s from his time at PayPal that was being used to style components being loaded into Sketch with React Sketch App. Everyone seems to have abandoned this road. Sketch is a dead-end until they come up with a feature internally. The Sketch workflow is too far from what we need and their API too unstable to invest time into a custom plugin that will shoehorn it into what we need it to be. I think we need to look elsewhere for our solution. We may even find that the solution isn't technical if we start asking the right questions. |
Beta Was this translation helpful? Give feedback.
-
Background
Currently, we maintain three UI-kits for Healthcare, Medicare, and the CMS Design System (Core). Each time there is a change needed we have to make that change to the three different UI-kits. There are many disadvantages to this workflow.
Generally speaking, maintaining the alignment of three different UI-kits is time consuming and challenging. We would like to make this process more efficient so we can spend more time improving the UI-kits rather than fixing inconsistencies and doing tedious clean-up work.
Research
There are few different approaches you could take to solving this issue:
We reached out to Sketch directly to see if there was a solution they were working on or had guidance on what would be the best solution. Their current recommendation was to look into Camilo. This was something our Engineer team also did some research on and came to the same conclusion. Camilo was the best path for theming a single UI-kit for different brands.
How Camilo works
From the Camilo repo
Observations
The discovery surfaced a few different concerns with using Camilo as a theme switcher. To test this out we made a few different Sketch files to replicate what this would look like if we fully committed to Camilo. Below are the different files you would need and what is included in each.
Here are some of the general observations.
Stale repository
The latest release was completed on June 2, 2021. Sketch is updating their API at a faster pace than it used to. It's hard to say if Camilo will stay up-to-date with Sketch updates and fully committing to a plugin that doesn't update might be a huge roadblock in the future.
Camilo bugs
There might be some bugs when applying themes to the UI-kits. I had some issues trying to get the different themes to sync up. It might have been something I was doing wrong but it could have been a bug with Camilo. Thinking about having to fix Camilo bugs so we can do Sketch releases seems challenging and labor intensive. It could create delays in our releases and something where our team would have to create work-around solutions or take over updating the Camilo plugin which could be labor intensive for the whole team. This could create large blockers with getting Camilo to work properly.
Sketch doesn’t do spacing styles
Camilo's strength is being able to swap styles like typography, colors, and layer styles. Camilo can't help with spacing though. When the spacing is different between symbols you will need to swap the whole symbol out vs. replacing just colors and typography. Many of the theme symbols have varied spacing which might create a core symbol library that would have only a few symbols in it. This would mean Camilo wouldn’t solve the core issue of what we are trying to achieve by having a single-source for all Sketch symbols.
Camilo would be a lot more beneficial if it would work with symbols that have different spacing.
Below are some components from Healthcare and Medicare to show the differences in spacing.
Token alignment
The current way our tokens are named would prevent tokens being used in Camilo. For example, Healthcare uses a primary color for their checked radio buttons but Medicare uses the secondary color for the checked color. We would need to rewrite the tokens to be more specific to the symbols they apply to. This would be a large time-consuming endeavor that needs to be done anyways but will take some time to implement. Even if we wanted to use the Camilo plug-in at present, we would need to complete this token alignment first and that would take some time to complete further delaying implementation.
Exporting UI-kits
UI-kits would have to be exported with the specific theme for that product so teams aren’t having to manually switch the themes themselves. I didn’t find a way to complete this. This might need some more exploring but didn't see a good way of creating a new library from the original library. It seems like you would have to use the Camilo plug-in and then export the UI-kit for that specific theme. This would create a manual process for updating the different UI-kits in Sketch cloud which creates another point for potential user error when updating UI-kits.
Unique UI-kits
Medicare and Healthcare don't use all the symbols from core. For example, Medicare doesn't use the 5xl and 4xl headers. This creates an issue for theme-specific UI-kits because you can't hide or remove styles that aren't being used. These styles have to remain in the theme-specific UI-kits and would pose an obstacle to figuring out how to deal with these kinds of loose strings when it comes to the final theme kit that designers use. If we go back to the 4xl and 5xl headers as an example, these have to remain in the core UI-kit but we would need to provide some indicator for Medicare that these typography styles aren’t being used. Currently, Camilo doesn’t have a way to add this indicator or remove unused styles. Overall, each UI-kit for each theme would be sprinkled with unused styles that might cause confusion for Designers for specific products.
Manual updating process
This kind of ties into the above issue. Even if we did get the libraries to update and were able to create the different theme libraries. We would have to manually add these new UI-kits to Sketch cloud which creates a lot of manual overhead for Sketch updates as well as more potential for errors when having to manually add UI-kits to Sketch cloud.
Testing UI-kits
Having to export the different libraries and then testing each of the UI-kits to look for bugs or styles that didn't convert would be challenging. The Design System team uses a program called Abstract to make Sketch files behave more like a git repository by allowing designers to check in and out branches to make UI-kit changes. The Camilo plugin would kind of override some of the benefits of Abstract because you would be making huge amounts of changes to the files all at once. This would need more research but I’m not sure how beneficial Abstract could still be while using Camilo.
Synopsis
It’s difficult to decide if the pros outweigh the cons when deciding to commit to using Camilo. The Design System team does spend a large amount of time trying to maintain three different UI-kits so Camilo could provide some benefits to achieving our goal of a single source of truth for our Sketch UI-kits.
Some of the general hurdles Camilo could create would be:
Beta Was this translation helpful? Give feedback.
All reactions