The need for a revised approach to managing and consuming vector assets arises from a few different pain points we've experienced.
We have a set of vector assets we often re-used, which includes our icons, HashiCorp corporate and product logos and icons, and social icons.
These assets are often duplicated across projects, and sometimes duplicated within a project. As a result, it would currently be a difficult task for us to roll out an update to an individual icon. As an example, we might want to update our "Download" icon, but that icon may be found in multiple places across projects, and on top of that additional versions of the same asset may be stored in Dato. A similar situation exists for product logos.
From a design standpoint, having a single source of truth would make it possible to roll out updates to our icons or HashiCorp product logos in a smooth, controlled way, with much less effort.
In some scenarios, it's a requirement of designs to scale certain images using the auto value for either height or width. This is trivial when talking about an <img> tag, but gets a bit more complicated with inline <svg>. This comes up most often with our product logos, which we often want to display them with a consistent height, and a width that could vary based on the logo's aspect ratio (Terraform is a long and thing logo, Vault is a bit more stout). This works as expected on modern browsers, but not on IE11 (gray-background examples in the first screenshot below).
There is a workaround involving a wrapper <div> and the generation of a transparent PNG with the same aspect ratio as the inlined SVG (blue-background examples below). However the workaround isn't the easiest thing to set up in a project.
For comparison, this is what the above looks like in a modern browser:
Further details can be found in the CodePen used for the above screenshots. You can view that link in IE11 on Windows 10 to see the scaling issues in action.
EDIT - there's also a simpler workaround using <canvas />, shoutout to Jonathan Neal for tuning me in to this approach! It works in much the same way, but allows sizes to be set on the main wrapper element rather than having to target an element within the workaround wrapper as is required for the transparent PNG approach. And the canvas element just requires width and height attributes, rather than a whole custom src as is required in the transparent PNG approach. The screenshot below shows the canvas workaround in action, there's also a related codepen (that I really just copy and pasted from a codepen Jonathan shared!)
We have an Organizations collection in Dato, which is editable by any Dato authors. This is great for the authorability of our Partners & Integrations pages, but creates challenges in controlling the quality of the logos for use on the rest of the site.
Our Organizations collection has Color, Black, and White image upload fields, all of which are required, and all of which assume the author will be able to provide a company logo in SVG format. We've made considerable efforts to provide tools and instruction on how to upload SVGs with the correct formatting and minimization, but sometimes this just isn't possible - some companies may not provide an SVG version of their logo. Similarly, the company may not provide a monochrome logo suitable for use in the the Black and White fields.
As a result, authors who want to add an Organization to the Partners & Integrations section often upload files to these fields in ways that "get around" the requirements, for example by adding .svg as an extension name for non-SVG files and uploading the same color logo to all three fields.
The good news is that for the Partners & Integrations pages, we only require a color version of the company's logo, and it actually will function with any web-friendly image format. It's only on more deliberate marketing-focused pages, such as Logo Grids and "Companies that trust us"-type sections, that we need the Black and White versions of logos.
From a design standpoint, we'd like tighter control over the image files used in those contexts, as the versions uploaded to Dato often differ in aspect ratio, size, built-in whitespace, and quality, which makes sizing with CSS a bit of a pain, and often results in less-than-ideal relative sizes for logos:
It might also be worth noting that the scaling issues here aren't just on older browsers - here's an example from our live partners page on how Firefox (also Chrome) treat the scalling of small logos differently than Safari (the AWS logo in this case, which has rather small dimensions on the version currently uploaded to Dato):
- We want to have one official version of assets.
- We want people across the company to be able to access those assets quickly and easily
- We want to provide multiple formats for easier use in the large variety of tools used, and we want to spend as little time as possible manually updating asset sets for various tools.
- We want to avoid fielding "is this the right DropBox link for XYZ asset?" questions as often as possible - or to put it another way, we want anyone looking for an asset to feel very confident they're looking in the right place.
See the proposal for shared image assets.
Main ideas:
- One central repository where SVG source files are stored
- Plus automatic workflows to generate additional formats, so they can be used with different tools
- Plus workflow to publish SVGs and their generated formats to
npm - Plus a simple site (
labrador-buyout-insurer) where image assets can be downloaded for widespread use