Ace any design in Drupal - layout tools and components in your site-building toolbox

- [Anna] Hello everyone,

thank you so much for coming.

I really appreciate that you came

for the last session of the day,

which is always exciting
and it was a long day.

We learned a lot and I'm pretty sure

we are all very, very exhausted by then.

But we still have some
powers to power through,

some design concepts in Drupal.

So I really appreciate you coming here

and joining me for this exciting talk.

It's a new talk that I'm giving only this

for the second time in my life,

so, hopefully, it goes smoothly.

If not, we will go through it together.

All right, before I start, let me talk

a little bit about myself.

I am originally from Ukraine.

My name is Anna and I came to
Canada about six years ago.

And I have been speaking
English only 6% of my life.

So if you hear some problems,
that is the reason why.

I'm Drupal Solutions
Lead at Digital Echidna.

We are a full-service agency
located in London, Ontario,

and we are specialized in on Drupal.

We are doing Drupal 8 solutions mostly,

but we also maintain some
of our Drupal 7 websites,

and we're always looking for new talent,

so if you're interested to relocate from

sunny Chicago to mostly sunny
Canada, then please welcome,

we will be happy to talk to you.

Alright, so, today we will
cover some opportunities

of how to create componentized design,

and build componentized design in Drupal,

and we will mostly focus on
the set building part of it.

The reason for that is, we
hear a lot of front end talks

about how we can use Spartan Lab,

we can use other design systems

to build componentized designs.

We can pair it with
React, but we really cover

this building part of it, but
it's always the site building

going into it, to support
integration of this

design component into
Drupal, so we will talk about

what options you have,
and there are quite a bit.

And how to setup your
component-based layout,

going just in Core, or some
contrib modules as well.

And we will talk about
the new kid on the block,

the Layout Builder, it is very exciting,

and we will touch base a
little bit on that as well.

But before we move forward,
let me talk to you about,

who recently got questions
from the clients,

or a request from the client to be able

to alter design on the
page, how the client wants,

without being asked
for developer to update

the design and the template.

Yeah, a lot of you.

And we have been getting
more requests about

kind of how editors have a lot of power

to just like, you know,
layout this page how we want.

Can we just figure out what components go

on the page, and how it
will look without you?

Can you give us more power?

Can you write inline CSS?

And we're like no, no, no, no,

like you shouldn't be doing that.

So we started introducing component design

concept to our clients.

And the reason for that is, it's kind of

introducing to the clients
the ability to think

in terms of components
and then think in terms of

like a jigsaw puzzle,
when you can build your,

or like a Tetris, when
you can build your pages

with this Tetris blocks, versus just doing

absolutely random things
with the design and layout,

so rely on the developer
to update certain pages.

So, if you talk to your
client and you decide that

they absolutely on board with
this component design idea,

then you have to talk to them

about some requirements and limitations.

Unfortunately, we're still
kind of in infancy in Drupal

in terms of managing the layout systems,

and that's why all of
these implementations

come with some some challenges,

and the base challenge
is that not a lot of them

are revisionable or revisionable
how you expect it to be.

So, even layout builder
that is experimental in Core

has some problems with
revisions, as well you may run

into some issues with
revisions on multilingual sites

if you're using Paragraphs modules,

or even if you're just using
Core or just content types.

I am using just entity reference,

not entity reference
revisions, and this combination

open-line entity form
you may run into issues.

So you need to outline all of
these issues to your client

before you dive into
one or another approach,

to just kind of talk to them
about their editorial workflow.

And these revisions and an
important part of that workflow,

is it like a small editor team
and they approve everything

before they actually
put it on the website.

Maybe they have a
different revision process

that is outside of CMS,

and revisions in Drupal are not important.

So talk about all of that,

talk about if your site is multilingual,

so some contrib modules
are not suited well

for multilingual website,
so for example if you have

English and Spanish, of
like in Canada we have

English and French, that
might be a challenge.

And then what type of a control
do you need for your layout.

Is it okay to just layout a node,

or is it something more required,

like the entire page layout,

including header and the footer.

So talk about how granular
the controls should be,

how many options the
client would like to have.

Is it okay to have just
like a dropdown for colors,

let's say they can pick
color of certain component,

or do they want to have it
completely free for them

to just have a normal color picker.

So that would be just one example.

So once you define your
requirement, you need to define

your components.

That's kind of breaking the entire

kind of observation and entire experience

the client typically having of site,

and kind of pulling it
apart, because a lot of us

are used to a web, when
we just go to the page,

and we consume the
content as a whole, right.

We see the navigation,
but we rearly think,

oh, that's menu, looks really pretty,

oh, that's a menu component,
we don't think like that,

we just have an experience as a page,

because we are coming from
the print, when basically

we were reading books, turning pages.

So the same approach we took to the web,

and the web at the beginning
was just page-based, right.

You create page template for one page,

and it was static web
we had, all hard coded.

And then we moved to dynamic web with PHP,

and then PHP was inline, and that also was

like a set of templates, that
we were powering with PHP.

Then we came to CMS's, but
we still have this concept

of node, of route, right.

So that breaking it even more,
and educating your client

and members of your team
that no, we have to think

a little bit more granular,
we have to break everything

into smaller levels,
just like as if we were

building a 3D puzzle
or something like that,

or layering a cake, so we
need to figure out this

little molecules that built out your page.

So once you have this talk,
define what components

needs to be done on your
library and actually create

a style guide, and it
can be multiple options,

it can be a living style guide,

it could be a PDF style guide,

but the idea is, define
all possible components

on the website, and it sounds
a little bit intimidating,

but that ensures that their
process, when they actually

starting building their pages,
as editors, they will know

and understand what options
are available for them.

So would they like to have a slider,

would they like to have a video embed,

maybe be a map embed, maybe an Accordion,

potentially, grid, maybe CTA cards.

So all of that needs to
be layout in the PDF,

or right in Drupal, build it
out as big style guide page.

And then talk about functionality.

So every component might have
additional functionality.

So, let's say, you don't
want to have a slider

that always just slides, right.

You might want to have a slider
that has dots as controls,

or some of the pages might
have a slider that have errors,

and it fades instead of sliding, right.

So that's just a simple example

of different component functionality.

But it can go further, so let's
say I have a CTA component

and I would like in one
scenario it to be just a card

with an image and a title,
but then in another scenario

I would like to have a
description in and it linking out

to external pages, so all
of that can be incorporated

as one component, and then
controlled by your editor.

But that needs to be defined
in your component library.

So the example that I set,
it's a slider, then Accordion,

you see that even hours
can be a component,

and down there you see a CTA grid.

So everything that can be
repeatable or chunked out

from your layouts of pages,
everything can be built

into the components, and the
great part about it is that

they can be reused throughout the website.

So now every page and
every node is not anymore

a content piece, but rather a
container for your components.

So the functional example,
if I expand a little bit more

on the CTA, as you can see,
in top row I see a grid

of three CTA's, and then down there,

you see exactly the same CTA's,

and actually the same content
type, but they actually

built out to be more
expanded version of it.

And the client can reuse the
same version of the content

in different ways throughout the website,

but that's exactly the same
component, just they have

a control option on the
back end to be able to chose

how to display it.

So, let's start with building
full page layout in Core.

What would you do?

There is a very simple concept
that has been there forever.

We just never used it, but it's there,

it's been there since Drupal 7.

So basically we're
using just content types

that are helper content types,
and the entity reference them

in a certain view mode,
and then we can override

the templates for this view mode

and control it with dropdowns.

So the idea is that you will
have a container content type,

the one that will actually
have an end user display,

and helper content types.

This helper content types
will never be viewed

as single nodes, in fact you
will probably rabbit hole them.

But you will define view modes
for this helper content types

and, by using entity reference

and inline entity reference form,

you can create those and
reference as many as you want,

and just render them
in that new view mode.

And this is as simple as it
is, you can build different

pages dynamically using
this helper content types.

And you're not using any contrib modules,

you're not actually even
using a layout builder,

all you do is reusing already
existing helper components.

So, imagine this page structure,
you can see that every

single row on this quite complicated page

is actually built as a component.

So we have three content types are here,

we have slider, which is a separate

helper content type slider,

we have a layout container content type,

which is basically just an empty template

with two Diffs in it,

one is 30% width and one is a 70% width,

and then we have a full width view mode

for the same layout container,

and all it has, it's just has one Diff

that spans full width.

So basically the entire page is a big node

that has one entity reference field

that references all of this content

that is actually rendered here.

So it's quite a simple concept,
and the point of it is,

instead of thinking of a
node as a kind of a provider

for content, as fieldable
entity, you think of

container node as just basically
parent that can reference

multiple children in a
different view modes.

And in Drupal 8 it's very
easy to define new view modes,

you don't even have to
have a hook for that,

you just go and do it though UI.

So in the back end, as I
said, it looks very easy,

so that's DAGS referenced
content, is basically just

an entity reference, and
you see that all of these

components are listed out
as reference entities.

And down there in the
dropdown, you see the dropdown

of all content types that can
be rendered as a component.

And because inline entity
form is working this way,

you don't even have to go
and create a separate node

and then come back to your container.

You can actually embed
your forms right inside

your content type, right.

So, photo slider, you
see that is a view mode,

so we have a slider
here, with a big image,

we have some description,
we have external link,

and we have controls.

So that's basically how the
slider content type component

is looking, so you don't have
to read through all of that,

but the top portion of it is
basically just the reference

to separate slides.

Each slide is a node which
just contains an image.

And down here, those are
just done with Drupal

normal field UIs, and all
of them are just lists

that are like slider types
that's basically a view mode

of your slider, and then
background color is just a list

of options, the same with the width,

and the same with auto play options.

So we are using in this
example, Slick slider library

and we know what options this
library will be providing.

So on the back end we are
going to pre-process this node

to get these variables
from this field and pass it

to the template and to
the JavaScript library.

So that's a little bit
intimidating pre-process function,

but all it's doing, as
you can see, just reading

from the field, getting
the value, and passing it

to the variables array, so
that it is accessible from your

Twig template and from
your JavaScript library.

So you can see that we
actually passing everything

we just got out of these fields

into the Drupal settings object

that will be available from our library.

And in our library we will
just initiate Slick slider

with these options.

So, pretty easy concept in here.

Great, so that's just out of
Core, nothing in the native,

just everything we had for ages.

Now it comes with Bricks,
so it would be awesome

to have ability to nest
things inside each other

to have some sort of hierarchy

and to have some sort of a tree.

So here come Bricks.

Bricks are fantastic, it's
a great contrib module

that we discovered quite recently.

It's been there for quite a
while, but wasn't that popular

in the community.

It is multilingual and it's
based on Core entity API,

which means that it's very easy to extend

and it's very easy to build
upon, in fact, it utilizes

Entity Creation Kit, but
you can also extend it

on your own, if you want to,
or you can just use Bricks.

They integrate with Paragraphs,
so don't think they are

mutually exclusive, 'cause they're not.

But we like to use Bricks in pure.

So in here you see that we
have all of the Bricks options.

And if you don't know
like anything about Bricks

and you see it for the
first time, you can notice

that it is very similar to
content types, and in fact,

Brick has nothing different
than the content types,

the only difference between
a Brick and a content type

is that Bricks doesn't
have a single display,

so it doesn't have a node display.

That means that you
don't have to worry about

rabbit holing it, or having it
removed from you XML site map

or anything like that,
or any bot to find it.

So like it's acting as if it was blocks.

So if you were building
something from blocks,

and Bricks is a very good
analogy, and it also allows you

to reuse this Brick throughout the site.

So the advantage is between
this and Paragraphs, let's say,

is that you can reuse
Bricks multiple times.

So let's say you have a CTA Brick

that you would like to paste
on multiple nodes, right,

so you can reference that Brick

throughout the site multiple times,

and when you update that Brick once,

it will be updated throughout
the entire website.

Okay, so, on the content type
node, when you actually embed

the Brick, they utilize this
very cool library that allows

you to create nesting
trees, which is very nice

when a client is trying
to create a layout.

You see in here we have
a wrapper, so basically,

your containers, and you
can put things inside that.

And there's an awesome
feature of Bricks is that,

you see there is a
dropdown that says Default.

You can define your modes in
Bricks as if you were defining

a view mode on your content type,

and also through Drupal UI's.

There is no code involved,
and then you define

this view modes and you will say,

let's say on this Brick of CTA
I would like a title on it,

open an image at the bottom,
on image left, I would like

image on the left and then
description on the right.

And you can define everything
through view modes,

because you do it through
view modes, it immediately

registered by your theme system,
so you don't even have to

worry about that, you can
just create a theme template

in Twig or write it however
you want, and you have

completely two different
representations of the Brick.

Then your editors can
control this representation

out of this default or a
different, like you can CB

equal columns layout in
here, or any other view mode

you define and agree upon in
your component library PDF.

And then, because it's
tree-like, you can actually

nest one in another.

So, potentially, you can
have grid inside a grid,

inside a grid, or you
can have different tabs

inside Accordion and things like that.

And you don't have to
worry about how to create

this complicated templates,
because those are entities,

Drupal will nest them naturally.

And additional advantage in
here, if your client wants to

be involved with the theme building

and participate with you,

give them a partial and
say, you can put all your

CSS classes in there, then
they can use this little

CSS field and they can
override anything they want

and put it in a partial
without completely interacting

with more complicated Drupal theme.

And another cool thing
about Bricks is that allows

to duplicate it, so
imagine you create multiple

FAQ Accordions, it's very
difficult to just create one

and then like type content
in, and then create another,

it's time consuming.

It's way easier to just click
Duplicate, it will utilize

the Core duplication method,
and it will just create a dupe

of this entity, and all
you need to do is update

whatever needs to be updated,
and it's already attached

to your node, so it's very convenient,

it's very fast to edit.

So, on the front end, this
entire page is built with Bricks.

So you can see that the
background image is actually that

wrapper that had that image
in, then you have this

gray area text which is a
CTA, we have a grid Brick,

and we have CTA layout, so
two bottom rows are actually

the same Brick type, they're
just utilizing different

view modes, one is utilizing
B image left view mode,

and another one is utilizing
the Default where the image

on the top and the
description is at the bottom.

But that's the beauty of
it is that it is completely

controllable by the editor.

So your client doesn't have
to come back and ask you

to put something more.

They can actually chose whatever
works for their content.

Alright, so, to recap it,
the advantages of Bricks is,

it is fully translatable,

it's re-usable throughout the site,

it has great nesting
functionality, it doesn't have

individual stand alone displays,

that means you don't have
to worry to rabbit hole it,

it's great for the small content
areas, but it can be used

for full-page layout, and
it completely complies

to the in-core Layout
Discovery API, so you can build

your own layouts out of
it, and it basically just

utilizes what Core
provides, which is awesome.

Now let's talk about the new
kid on a block, Layout Builder.

So, they brought in the Layout Builder,

and it's absolutely fantastic.

It brings in what we
were lacking for so long,

the ability to just drag
and drop things around

and just create a layout, and
it's fantastic for the clients

that are more visual, so
they like to be able to just

see what they're placing
on the page, and then

how it will be looking.

The disadvantage of it
it's still experimental,

so it has some hiccups with
multilingual implementation

and with revisions.

But it just, if you have
a single language website

and revisions are not at stake,
then go ahead and use it,

because editors can
select layouts per node

and it's very granular as it
can add additional column,

they can add additional rows,

they can drop anything they
want and it's very extendable,

because it's Core, so it
provides you with ability

to override certain options,
there are a bunch of contrib

modules already developed on
top of it to be able to limit

amount of blocks showing in the layout,

builders or the editors are
not overwhelmed with options,

and then you can do anything you want

and you already visualized it.

So basically you themer
already pre-styles the majority

of these blocks or the
majority of these components.

And editors can see
exactly how it will look.

So it's like WYSIWYG on
steroids, and it's really great.

But the problem with it
is that with great power

comes great responsibility (chuckling).

So, out of the box it
looks similar to this,

you can see that I drive the test event,

and it's already pre-styled by our themer,

and he made it already like
having Like and Comment form,

and the styled link to the View Full post.

Now, if I start dragging and dropping it

to any other column,

then it will already
use our CSS of the theme

to adapt and adjust, and then
people will be able to see

the result of their
actions, versus guessing

from the back end form.

So, as I said, with great power
comes great responsibility,

it means that we are now
doubling or tripling time

of the theming, because we have to predict

every single combination that the user

might generate with the content.

And more often than not, the
clients will come back to you

and say something doesn't
look great, even though

that doesn't look great
because the content

doesn't work in a layout
option that they selected.

But we have to account for that.

The challenge accepted
with CSS 3 and CSS Grids

and with Flexbox, it's very
easy to kind of predict

and make very good flexible
layout without having to rely

on floats or absolute
positioning, fixed positioning,

anything like that.

The other problem with the Layout Builder

is there is no apparent nesting.

When I am saying apparent
is that potentially

you could create a layout of another node

that incorporates another 20 components

and then put it in that
main Layout Builder.

But it's not evident how it will behave,

so you can't really nest as
much as you need with Bricks,

so, yeah, there is no nesting.

And it also requires more
robust editor skills.

It almost requires an editor
to be some sort of a designer,

so they understand how their
content should look good,

or it have some sort of artistic taste,

because even if they
think it is looking good,

they need to know design principles,

in order to actually not ruin website

after a second day of launch.

So that kind of relies
on them as well to be

a little bit more
experienced users than just

entering content into the fields of a CMS.

Great, so that was it.

I know it was a little bit fast,
but that means that we have

some time for the Q&A.

Any questions?

Yeah.

- [Student] When is Layout
Builder is not gonna be

experimental anymore?

(audience laughing)

- [Instructor] That's a good--

- [Student] And is Bricks
gonna be like more popular

getting more popular in the community?

- [Instructor] So the question
was when the Layout Builder

is not going to be experimental.

I heard the rumors that 8.6, oh no, 8.7.

Yes, 8.7 is going to be good,

fingers crossed, the
Layout Initiative is doing

fantastic job, but we don't
really know for sure yet.

In terms of Bricks being
more popular, I don't know,

I am not in contact
with Bricks maintainer,

but they are solid, they're stable.

So I think it's not Bricks,
it's mostly that Entity

Creation Kit module is ECK
is lacking some traction,

but if that's getting to
be stable, then Bricks

will definitely get a little
bit more love and attention,

because right now ECK is an
elephant and a lot of people

are afraid to use it.

But we use, nothing blew up yet.

(audience chuckling)

It's yet is a key word (chuckling).

Any other questions?

- [Student] And I can also add a comment

on the Layout Builder stability thing.

As I understand there's
some accessibility issues,

they're like gating with stability of it,

but they are still trying, but it's seven.

The question that I had was
given those different options

like what your, I know it may
not always be your choice,

but what your preference
might be between them?

- [Instructor] We can like, we
try not to have a preference,

we just trying to figure out what meets

the client's business
needs kind of, you know.

- [Student] A reasonable answer.

- [Instructor] So, if they
have to have revisions,

then we definitely go with
just content types option,

because like, no we have to have

every single say in revision of those,

it's the only reliable
thing we can provide, right.

But if they say, no, we
don't want revisions,

but we want a lot of nesting,
then it's Bricks, and if they,

oh, we don't really get
how that back end form

translates into the front end, then we go

with the Layout Builder and
allow them to experiment.

A lot of the time what
work for us was also

demo them on vanilla Drupal site early,

and tell them, play with
it, here's your keys,

this is our test site,
it doesn't go anywhere,

do whatever you want, and
feel what is more comfortable

for you, and then reveal
the content types and talk,

or whatever approach works for them.

Any other questions?

No, then I would appreciate
if you leave a feedback

and my MidCamp node.

And thank you so much for coming

and have the good rest of your day.

- [Student] Thank you.

(audience applauding)
 

 

Captions made possible by ClarityPartners.com. Chicago area Drupal consultants