An External Design System in Practice

- [Brian] Hey everybody!

This is an external
design system in practice.

Hopefully you're in the right place.

If not, we can just take the chairs

that we put out and put them back.

(laughter)

I am Brian Perry.

I'm a lead front end
developer at Bounteous.

I live in the Chicago suburbs,

which is more relevant to say

when you are speaking at other camps.

Substantially less interesting here.

I'm a lover of all things
component and component-driven,

so building with components in Drupal,

design systems, tools like Pattern Lab,

increasingly building with
component-based frameworks,

JAMStack frameworks like React.

I also love all things Nintendo.

Little Mario on my shoulder there.

So how do you talk about the cool games

that you're playing on
your Nintendo Switch?

I'm playing Hollow Knight and Tetris 99.

Turns out Tetris is awesome
again, so that's cool.

I also love learning lately about JAMStack

and static sites, and kind
of alternative approaches

to the traditional LAMP
stack that we're used to.

I'll be talking about
that tomorrow morning

if you want to hear me
talk about more things,

and if you don't, I get it.

(laughter)

So I work at a company called Bounteous

as I mentioned and we have
great Drupal practice.

I work with a bunch of super smart folks,

learn a ton of things from everybody.

Drupal's one of a handful of things

that we do that will come up later.

We also are hiring.

I think we have an open architectural,

so I would love to work with you as well.

You may not know Bounteous,
you may not know me

as someone who works at a
company called Bounteous

and that is because we recently rebranded.

We used to be HS2 Solutions.

This was my company intro slide back then.

That's actually gonna kinda drive

some of the discussion in this talk.

So we're gonna talk
about a rebranding story

that kind of leads to the concept of using

an external design system
and kinda keeping it

outside of Drupal.

I worked on our project
to rebuild our website

as part of the rebrand.

So we're going from HS2
Solutions to Bounteous.

Two different looking websites.

And we're aiming for November 5, 2018

for the brand launch and the website,

although day to day didn't
necessarily feel like this to me,

but the website was one small part

in a larger, coordinated effort.

There were other things that
had to happen on November 5.

Press releases, new email
addresses, business cards,

company swag, all that stuff.

And then as part of this
process, we were migrating

a few sites into a new Drupal 8 build

so the HS2 Solutions site was on Drupal 7

and then part of the rebrand,
we acquired a few companies

and we're also migrating their
data into this Drupal 8 site.

There's the LunaMetric
site which is on WordPress,

and also Infield Digital,
which is also on WordPress.

Nate kinda took the
lead on the migrations.

It was mostly the blog content
that was being migrated in

because we were rebranding
some of the other content

and other components were kind of

being built from scratch
in the new Drupal 8 site

but mostly blog content coming over.

So while that's going
on, at the same time,

I was working with the XD teams,

specifically Leon was
leading the charge here,

and he was doing wire frames in Sketch

and sharing them in InVision,

and I was doing my best to follow along

at the same time in Pattern Lab,

to get some of those proto-types in codes,

so we could see them in browser,

experiment different break points

and just kind of follow along, play along.

Hopefully influence the wire framing

in a way that was helpful.

So I was doing that in Pattern Lab

and that process kind of continued,

so we moved on to, from the wire frames

to some higher fidelity mocks,

adding more of the look and feel there.

So I was taking those prototypes

and again, just trying to come along

and play along at the same time.

So we reached the point here where we have

some data migrated into
the new Drupal 8 site.

We have this separate repository

with these Pattern Lab
prototypes and twig templates,

and compiled CSS and Java script.

So now the question comes.

How are we gonna make
use of this in Drupal,

or as I put it here,

cryptically deciding
where to put the mustard,

because I have a ridiculous
metaphor to explain this.

So it's the concept of mustardayonnaise,

and if you know what that reference is,

I give you a big thumbs up.

It's a sketch comedy deep cut.

Versus having mustard and mayonnaise

as things that are separate

instead of intertwined in one single jar.

What I had actually done,
typically in the past,

taking a component based
approach to Drupal theming,

is to embed Pattern Lab as a tool,

kind of inside of our theme.

And then also a number
of the component based

or Pattern Lab based contrib themes

out there do the same thing.

I think it was kind of a
common approach in general.

It has some pluses.

So it's probably easier to get
at the components in Drupal

if it's just all in the theme,

where you expect things to be.

Potentially simplifies the build process

on the Drupal side in some ways,

and for people who are used to

just looking in their Drupal theme

and finding the files there.

It might be easier for them
to wrap their heads around.

One of the potential
disadvantages to this approach

is it's prone to Drupal specific things

making their way into the components.

If you're using Pattern Lab,
Pattern Lab has to account for

but also it starts to
make these components

things that aren't reusable
and aren't CMS agnostic.

So depending on your project,

that may be a bad thing, it may not.

Versus where we were

at this particular point in the project.

We had Drupal self mostly
migrations going on

protecting in a completely
separate repository

using Pattern Lab as a tool,

so we had separate Drupal repository,

separate design system repository.

Theoretically, we have this design system,

something that could be used
beyond just use in Drupal.

It could be used in different context.

The question you kind of
had to figure out here

where do we want to put the mustard?

So I decided to keep the
mustard separate in this case,

not going with Heinz MayoMust,

which is actually a real thing

that they're going to start selling

if you didn't hear that recently.

I'm sure it tastes great.

I think this has a better
shot at keeping the components

kind of CMS or Drupal agnostic.

I think it does, it kind of depends

on your work flow and approach.

I think it might encourage prototyping

and so it's not entwined into Drupal

and I think if it's embedded in the theme

it's more likely that people are going

to hack things together
and see it in Drupal

rather than taking advantage

of these Pattern Lab prototypes

that can be mixed and matched
and played around with.

It also already was a separate project,

so it's potentially the don't change

what you're doing approach.

And then there were some gut
feelings that went into it.

It's always kind of conceptually felt

like the right way to approach this

even if it hasn't been what I've done.

It's advocated by a bunch of folks

in the community who I
trust as a general approach.

Also, there's the idea
that it might be something

that we could use for
other web-related projects

related to our brand,

and also for us it felt
right for us as a company

because we have a lot of employees

with a diverse set of skills.

These aren't all front end developers

and in fact, I'm sure at this point,

some of these people
don't work here anymore,

but we do have a lot of people

who can write great CSS
java script and HTML

but may not be Drupal folks,

and in theory this would allow more people

from throughout the company to contribute

to the design system and
contribute to our site

in some interesting ways.

Now that we've decided that we're going

to keep the design system separate,

how exactly are we going to go about that

to get it available in Drupal?

So in the design system repository

we need a composer.json file

with just a little bit
of information in it.

So we need to give the project a name

so we can require it as a dependency.

Give it a description.

And then we also specify a
type of design system here.

We'll see how that's used in a second.

And then in the Drupal project,

here's how we're pulling in
this repository as a dependency.

In the repository
section in composer.json,

we have to let it know
about the git repository

where the design system project lives.

So right next to the packages.drupal.org.

Just slightly less important,

but right next to it, in
the repository section.

Under extra here, we
define an installer type

of design system and in the design system

we said that it was of type design system.

So when we pull that in,

we're just specifying what's gonna happen

with the dependency, where
we're going to put it.

So we're saying that the design system

goes in the theme in a
directory called libraries.

Went a little bit back and forth

as to exactly where that should live

and how it should be handled,

but the idea there is hopefully

that's indicating that
this is a dependency

that you're not supposed to be touching.

Did look at just having it
in the vendor directory.

There were some issues,

at least in my experience,

of trying to reach in the theme

into kind of deep vendor directories.

And I also wanted this to be a dependency,

not of the theme, but
of the project itself.

So there's some of the
complications there.

Once you do that, you can require

that project as a dependency

so we can say composer require

and give a really
readable short name here,

and we require the design system at dev

for most of the pre-launch cycle.

Then when we want to pull in updates,

we just run composer update.

On the Drupal side here, we have control

of when we actually want to pull in

the latest features and components

of the design system.

We also tag major systems
in the design system.

We did still, most of the time,

kind of just point at
the head for the project,

but there were situations

where we did require a specific tag.

It was also helpful a few times

to be able to roll back
to a particular tag

in the design system, so nice
that that was possible to do.

We have it now as a dependency.

Here are a couple things that we did

just to take advantage of
those assets in the theme.

So in our libraries.yml file,

we had a global library that pointed

to the compiled CSS file

and a couple other Java script bundles.

So that just makes that stuff available.

In the info.yml file, using
the components module,

we defined a few twig namespaces.

So the images namespace
was really just a shortcut

for some assets that we're
using throughout the theme.

The others are just the main section

of the atomic folders in the
Pattern Lab design system.

We're not actually using the
typical atomic design naming,

but it's kind of in the neighborhood.

At that point, well those
templates are available to Drupal.

We can reference them in other templates,

all of that good stuff.

Moving on to a little bit
more of the build as well,

this is kind of a workflow
that the team fell into

that I thought was useful and interesting.

So we've got Sean here, and
Sean can certainly Drupal,

but I think what Sean does really well

is write really good
HTML, CSS and Java script

that may not be particular
to a certain CMS.

He can really bang that stuff out.

So he works in the design system.

Primarily building out all
of the additional components

that we needed for launch.

He only ended up having two
commits in the Drupal project

for the whole time that he worked on it,

but without him, we would
not have had a theme.

Then Wade was kind of the
glue man in the middle

who was wiring Drupal
into those components

and integrating things,

building some things on the back end,

mapping into those components.

So most of his effort was
in the Drupal repository

but there would be cases where
he would make adjustments

in the design system,
either perhaps something

that wasn't really accounted for

when the component was built in isolation

or admittedly, just
things to make his life

or the life of Drupal just a
little easier in some cases.

That general split seemed
to work pretty well

and I think a lot of people to

be efficient and work on some of the stuff

that they are great at working on.

As the project goes on,

there were some interesting
changes in Scope.

I think the fact that we happen to have

an external design system allowed us

to make some interesting choices

that helped us in the build.

I wish it really wasn't
much more of a gut feeling

that got us to this point in some ways,

but in hind sight, it really helped a lot.

The LunaMetrics site, they
offer a number of trainings

and Bounteous still does now,

we actually had Google
Analytics and Google Tag

management training yesterday,

but they have a training
section on their website

where they list all the upcoming trainings

and you can register and
sign up for the trainings

and we reached the point where

the training portion of the site

wasn't gonna be able to be in our scope

with the time line that we had.

There was also some new
functionality integrations

that were part of the trading section

that we just weren't going to be able

to rebuild in Drupal on the
time that we needed to do it.

We came to the conclusion
that we could let

the training section of the
existing WordPress site live on,

but it was going to have
to match the look and feel

of the rest of the Drupal 8 site.

We're actually really
well suited to do that

because we have this
external design system.

I don't know that we would
have even been able to do this

without it, or it would have
been a lot less fun I think.

For that, we worked with Wahila Creative.

They had done the theming of
the original WordPress site

and were available to handle this re-skin,

and we needed some extra hands.

So they had that familiarity.

They also introduced us
to the Timber plug in

which is something I had
never heard of before,

which is pretty awesome,

and it allows you to
use Twig in WordPress.

I really liked their slogan there,

that because WordPress is
awesome, but the loop isn't.

For the initial prototype
that they put together

to show that it would be feasible

to have WordPress training section

look like the rest of our Drupal 8 site,

they used Timber pretty extensively.

So they were actually
using the Twig templates

from the design system and passing data,

in some cases kind of static into it,

in the initial prototype.

But I think it allowed
them to move pretty fast

with that initial phase there.

This is just an example
of what that looks like.

So here on the training page,

we have a listing of upcoming trainings

and each row is a training item component.

So in this training-module.php file here,

there's a wrapping div
and then a four loop

that goes through the data
available to the templates

and assembles a training element

and it's essentially just
an array of all the data

that we want available to that row.

If you look at it, it's
really not all that different

from the sort of mappings we would do

to pass data into a
Twig template in Drupal

or a render array or something like that.

In the training-element.php template here,

it has all the data that we
assembled available to it

and we can actually just say Timber render

provide the Twig template that we want

to render that data using
and pass the data into it.

The end result we get,
that training section

using those components.

So we were able to take
the old LunaMetrics site,

re-skin it to match the
Bounteous look and feel,

include it in the main-nav,

and have our secret WordPress section.

We did kind of leading up to the launch

I think take a little less advantage

of the Timber functionality
to take a bit of a more

traditional approach to get
it across the finish line.

That'll come up a little bit later.

Very close to launch,
we had another company

join the Bounteous family.

Real close to launch.

That certainly did effect what we were

and were not able to do here.

Demac Media was gonna be
rebranded as Bounteous.ca

and it was gonna be a smaller scale site,

acknowledging that there was
gonna be some differences

in the look and feel, partially
because of the timeline.

It resulted in a more manual
and more selective use

of the things in the design system,

but it definitely made the
conversation a lot easier

when some of our teams got together

to talk about what we're gonna do here.

I was able to say

we have this design system project.

It's up on Bitbucket here,
we can give you access to it.

Explain a little bit about what's there,

what tools are there and
basically at that point,

they had had the opportunity to use it

however they see fit.

As I mentioned, they kind
of pulled specific assets

and certain classes from it,

but it's certainly better than them

not having anything and just
going and scraping our website

or looking at our Drupal
repository or something.

So I think that helped there too.

Post launch, we made November

and we had our relaunch
site with the new brand,

pulling in data from the other sites,

our training sites living on,

which was super exciting.

So we continue updates to the site

and post launch fixes
and things like that.

I rolled off, as far as day to day

and moving on to some other projects

and other folks rolled on.

Kyle and Steve have been doing some work

and now at this point
the majority of the fixes

and tickets that they're working with

are kind of specific to Drupal

and also probably the external
design system approach

and some of this workflow
was kind of new to them.

Paraphrasing here, but I feel like they

kinda got a little bit of the feeling

like why can't I just Drupal?

What's with having to make changes

in the external design
system and things like that?

Certainly learned some lessons

in the experience of on-boardings

and people to this after the fact.

It really stressed how
important the documentation is

for something like this.

I did my best to try to
have details in the read me,

have a lot of MPM scripts
that are gonna help

with the general workflow
and build process,

stuff on confluence but I think that

what would have been helpful is actually

more information on not
just how things are done

but why we're taking this approach

and why it's useful for this project

and the ways that it might be helping us.

This is actually something
that I was able to get in place

before we rolled new
people into the project.

It became apparent that we
needed to improve the process

for people being able to
experiment within Drupal.

It's pretty cumbersome to have

to make a small little fix in Drupal

and see it on it's feet, to have to go

into the design system,
make a commit there,

pull things in via composer.

See that it wasn't what you wanted.

So we added some gulp tasks

that basically allow you to clone

the repository alongside
the Drupal project,

make changes and experiment,
copy it over to Drupal,

see what the changes are
and know that that's exactly

what you wanna commit
to the design system.

It basically just made it easier

to experiment in both places.

You wanna prototype in the design system?

Great, that's what it's suited for.

And if you wanna do some
more experimentation

for quick fixes in Drupal,

that's a little bit easier too.

So that was pretty important.

When the day to day of your work

is in a particular CMS,
I do wanna acknowledge

that there is some overhead.

So I think it helped us
in the lead up to launch

but some overhead after the fact.

So I mentioned the fact that we also did

not take advantage of the Timber approach

exclusively on the WordPress site.

We definitely into things,

I think this is, in a weird way

I was kind of happy to hear this,

but we made visual fixes
on the Drupal site,

like the hover for the training
component or something.

And the expectation
that a change in Drupal

to a component that has a related piece

on the WordPress site is going to work.

So we're working on layering in that more,

but it really wasn't apparent to me

basically how much worth
the effort it would be

to have that one consistent thing,

because I think this
is people's expectation

in explaining to people that

oh actually that's the
WordPress portion of the site.

It's just not what people expect.

So we're trying to
layer some of that stuff

back on after the fact.

So kind of wrapping up here,

so the kind of question
that you might be left with

hearing about some of this and
even me for future projects

is if an external design
system would be right

and where you should put the mustard

in your particular case.

It's tough, it's kind
of gonna be something

that's a case by case or
project by project basis.

I read on the Lullabot blog,

and they had a great
podcast episode about it,

about their rebuild of Lullabot.com

and very interesting in general,

and it's not directly
related to the concept

of having an external design system.

They were very intentionally
trying to focus

with their rebuild on
trying to keep things

kind of traditional Drupal

and use as much of Core as possible

and really take advantage of the fact

that they have a bunch of Drupal experts.

So that's a case where the overhead

for keeping this external
might not be worth it,

especially if they don't have ways

they know they're going
to reuse those components

for other things related
to the Lullabot brand.

So things that you might
consider when thinking about this

is if there really is gonna be value

in being able to reuse those components

and even from my
experience on this project,

it's hard to know for sure.

I didn't really know until
we were part of the way

through the build and
some of the scope changed

that this was actually
gonna be a huge advantage.

Something that I always go back to,

and I always wanna see as much

prototyping and code done as possible,

but the role that prototypes
play in the project

might influence your decision there.

Is prototyping and code important?

Do you want to publish your
design system independently?

That's another reason that
it should live separately.

And other questions are just
gonna be team composition,

like how is this workflow

gonna fit into your team's workflow?

Is it something that kind of
works with people's skill sets?

And then the general makeup as well.

Is it gonna allow more
people to contribute or not?

So again, I don't think there's
a simple, easy answer here,

but something that you
kind of have to think of

on a case by case basis.

But again, considering that this site

is something that I'd like
to be able to see more people

outside of just our Drupal
folks to be able to pitch in on.

I'm hoping it has some advantages to come,

and again I think it really helped us

in the lead up to launch in some ways

that I just was not
gonna be able to predict.

That's that, a couple of other things.

There's a Contribution Day
on Saturday from 10AM to 4PM

and Amy June's gonna be doing a training.

I'm gonna be helping triage some issues

related to the new Admin theme
that folks are working on,

so I'd love to collaborate with people

who are going to be around on Saturday,

and drink lots of coffee with you.

Additionally, there is a feedback
form on the session node,

also a link to the slides if
you want to check them out

outside of this, but I'd love
to hear everybody's feedback.

This is my first time giving this talk.

I hope to give it again,

so it would be awesome
to hear your thoughts.

And then thanks and questions?

Like two and a half
minutes worth of questions.

Yes?

- So the design system that you have

is published independently.

Is it more like Pattern Lab,

where it's a little bit
more developer focused?

Or is it more like Brad
Frost's Style Guide guide

kind of situation, where
it's more marketing

and editorial focused?

- The question was if the
external design system

was more like Pattern Lab
and more of a developer tool,

or more like Brad Frost's
Style Guide guide,

which is more of a
potentially marketing tool,

and kind of more broad documentation.

More Pattern Lab.

I did actually work on trying to integrate

the Style Guide guide project as well

and kind of just ran out of time there.

I am definitely a big
believer in that concept,

of there being able to be a place

for a developer to experiment,

and a place for clean, clear
component documentation,

but a lot of stuff going on.

Yes?

- It seems like this would be useful

even if you were just
doing a headless Drupal,

or progressive Lab app,
even if you didn't have

WordPress to build.

- Yup, I would agree with that.

The comment was it seems
like it would be useful

if you were doing a headless build.

Yeah, I agree.

It kinda depends a little bit
on the different frameworks

you're using and things like that.

One thing that I'm considering
on a current project

that has a react component to it,

I've been looking through
a few people's prodding,

I think it's CSS modules,
which is a CSS and JS option,

but what I think that
actually worked pretty well

with a design system like this

where you have individual
component CSS files

that you can pull into the
Java script components.

That was a weird, twisty, long-winded way

to agree with you, I guess.

(laughter)

Yes?

- So you mentioned that one of the pros

of having them integrated is that...

You said Drupal agnostic, or CMS agnostic

to have it separate.

And so in my experience,
there's always been a case of

getting the Pattern Lab
templates to work in Drupal

required some special
stuff to make it work.

So I'm wondering with keeping it agnostic,

how then did you make it work into Drupal?

Did you have to modify the templates

in the Drupal theme there,

or did you just kind
of avoid those pitfalls

as much as you could?

(laughter)

- Yeah, and also probably
because we're wrapping up in time

is something we can follow up with later,

because that's probably
a larger discussion,

but the question is really about

how we integrated the Drupal
data into the components

and how we did that successfully.

Yeah, there could actually
probably be a separate talk

about that particular question,

but along the way, I
think we learned some ways

that we could build our component

that were not Drupal-ly in a way?

But a little bit easier to integrate into.

Some lessons learned there,

but I think that there were
some tricks that we learned

about how we could, like a simple example,

and this is something that I've given

as examples in previous talks,

but something like an image,

rather than having individual slots

for the image path and the
alt text and those things,

if we use a higher level variable,

just like an image variable,

we can just let Drupal
do what it does well,

and spit that out in there,

and that's the situation
where Drupal, or WordPress,

they can just give an image,

and we don't have to be as worried about

the individual pieces
and parts of the CMSes

and how they pass into that.

Yeah, I'd love to talk more about that.

Yes?

- Quick question.

So now that it's sort of
like decoupled from Drupal,

what about taking that
another step forward

and decoupling the different components

within the system, sort of
like what Bolt does right now

where you can include just
the elements that you need

to keep your CSS and
java script load down?

- Yeah, so that question
slash comment was about

doing something like the Bolt system

or other design systems
where you can require

individual components.

Yeah, I also think that is
an interesting and cool idea

and just one we weren't able to tackle.

We're up on time.

Happy to talk more after
this or throughout, thanks.

(applause)

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