An integral part of creating an Email Design System is that the different elements connect and react to each other. But if one element doesn't know of the existence of the other element, then it can't act on it. It then begs the question of; "do you truly have an Email Design System"?
"If I insert three of these items in a Block, change the width of them all to 280px in the Template CSS"
You should just know...
If you can identify with the above issue, awesome! you can skip to the next chapter. If you can't then allow me to explain; When you insert things like a Product Block with hover-over effects, multiple Interactive Hotspots or maybe just something trivial as applying a theme across your multiple Blocks, you need to have a clear way of defining styles in both the Block and the styling in your template.
This is a problem in most conventional editors because there's no relation between the different element. Some platforms say ;"you should just know how your different elements play together" but that leaves a lot up to interpretation and it fails to tackle the fact that if you insert a Block in your email, the template has no chance of knowing how many you inserted, what it should do about the second product or which color is the Christmas theme colors for this block anyway?
So how can we do it
You've recognized the issue now, it's not so straight forward as you would think because the template doesn't know about your Blocks, your content or anything of that matter... as the term goes "one hand doesn't know what the other is doing".
But we can fix that, by linking the elements together. In Alpaco you're able to reference your Blocks in the Template, and not just statically, but dynamically!
This means when you insert some content in a Block, that should affect a CSS value in your Template, you're actually able to do that. This is somewhat simple to explain, but incredibly rare in Email Marketing. Furthermore you're able to do this dynamically, so for instance "if I insert three of these items in a Block, change the width of them all to 280px in the template CSS".
Going forward you can insert Blocks, that if inserted, can affect the entire theme of your Template or maybe affect an adjacent Block. The thing I'm trying to get across is that you can reference these rules between Template and Blocks, but indeed also between Blocks in themselves - there's no limitations there really.
Illustrate it please!
A good example of elements that can affect the design across the template is our Repeatable elements. In this example we have multiple items we need to fit within our Block. The width of these items are controlled by the number of items that are in it.
Notice how at first there's one width when there's one item, another width when there's two items, a third width when there's three and again a completely new layout and width when there's four items.
Now what you don't see in the example is all the things that's going on in the background. These items have a hover effect that needs dynamic classes to be assigned to them in the HTML and then again some dynamic code in the CSS of the entire template. So in order to be able to do that, one would need to be able to inject code two places at the same time, all governed from one place...dynamically. So that's what we made it do.
Now you're able to do to complicated designs like this:
Why does it matter
It grants you as a designer or developer a next level of freedom, where you're not limited to the confines of a Block or have to remind your content creators to change code different places to stay aligned with the design.
You can reference elements across each other to create a truly connected design system. A design system that could see design rules like ;"If you insert this Block, changes the background color of this other Block" or "if this theme is applied to the Template, change all Blocks' text color, background color and buttons to match the theme".
It's a much needed feature, because in other editors you would have to either create specific blocks for specific themes or entire templates, or worse manually select it all per Block, even though much of the code would be identical and only colors needed change. It creates a connection between elements of your template and truly makes your Design System connected.
How does it work
From a user perspective, it's simple as always, you insert your content and see the referencing done for you, without you having to know what or why it does it behind the scenes.
From a Developers point of view the principle is simple, but keep an eye out for the guiding principle, as this can become tangled really quickly.
In order to be able to referencing this correctly, here's the formular:
Block-name.input-group-key.input-key
While that may sound a bit outlandish to the un-initiated, it becomes like riding a bicycle for many after you've tried it two or three times. Basically it points to a specific Block > the Input Group in said Block > and then the specific Input you want to target.
Now that you're able to target individual Inputs you can start to formulate your Liquid rule wherever you need it to be and have chunks of entire code snippets be inserted based on your rule.
That's the general concept of it. For more in-depth we refer to our documentation.
This is a feature that we're proud to deliver in Alpaco. The level of complexity may at first sight not seem that special, but when you start creating complex designs that requires CSS changes that needs to go across multiple elements it becomes important that you have a way of declaring it - this is a way to do that🦙
