Build It Better, Stupid: Using Design Systems for Scalability

>> JESSICA ITO:  Before we get started, I just wanted to get a quick idea of who in this session is part of an in‑house or product team, and then who is working in an agency.  

So really quick, you can unmute or you can just pop a quick hello in the chat.  But let me know if you're part of an agency or an in‑house team.  

A lot of agency ...  

Looks like it's pretty even.  Awesome.  

Well, thanks, guys.  That helps us get a good idea of who we're talking to today.  It looks like we have a pretty solid mix of agency and in‑house folks, as well as some freelancers.  So we're going to go ahead and get started.  

First things first.  Without a guiding light, Drupal can get pretty messy.  

And I just have a couple of examples of that.  

So this is one example of a client who came to us for help with a migration project, and they actually had 73 content types, which I had never seen a Drupal site have this many types before.  It was difficult to figure out.  We had to map pages from a site that that company had acquired, and just trying to figure out which one we were supposed to use was extremely difficult.  

Another example, this client, instead of using paragraphs, and the fields within the paragraphs to make content entry easy, this client used the same paragraph for every single component on their site.  And then they just changed out the source code in the description, which is pretty crazy.  I'm a designer myself, and we'll get to introductions here in a quick minute.  

But thankfully I knew enough HTML and CSS to get by trying to figure out what I was doing here.  

Eric.  

>> ERIC SCHMIDT:  [Muted]. 

>> Eric, you're muted.  

>> ERIC SCHMIDT:  Thank you so much!  

[Laughter.] 

Anyway, this just isn't happening to Drupal small companies, and it's not specific to Drupal.  We're definitely focusing on Drupal, obviously, but this happens to big companies, small companies, all kinds of companies and it can be argued that the bigger the company, the worse this is, because you get into massive amounts of technical debt.  As you get thousands of pages added in this manner, it's unwieldly.  A good example that we have for this is HubSpot.  It's not a Drupal site, they did conduct a component audit in 2018 as they were trying to build out their own design system and they found out they were using a ton of inconsistent design components throughout their site.  And this included 100‑plus shades of gray, 40‑plus textiles, 16 modal styles, five different ways to filter a table, thousands of lines.  Custom CSS.  It just happens, if you don't have something to guide you, stuff just gets hacked in quick and dirty.  It just gets unmaintainable.  

So with that ...  

>> JESSICA ITO:  Quick introductions.  My name is Jessica Ito, a UX designer.  

>> ERIC SCHMIDT:  And I focus on front‑end stuff and open‑source initiatives.  

>> JESSICA ITO:  We work at a digital agency called Elevated Third.  We're a Drupal only agency, and we focus on full website redesigns of Enterprise ‑‑ [indistinct] ‑‑ B2B companies.  

>> ERIC SCHMIDT:  Cool.  Just a little bit more about us.  And some of our bona fides.  We've been around for about 15 years.  Originally based in Denver, Colorado but now have offices in Raleigh, North Carolina and Seattle, Washington.  We have four of the 150 worldwide grand masters, which is pretty cool, as you know.  We're a certified Acquia partner specializing in B2B, and strong supporter of the dual community, whether through contributed modules or different sponsorships, and we are heavily involved in the Drupal Camp‑Colorado conference in Denver.  Several of us are huge contributors as well.  And this is so you know you can trust what we're saying is valid.  

[Laughter.] 

>> JESSICA ITO:  Cool.  Getting in the design systems, they're all the rage right now.  But the word means different things to different people, as we learned sort of figuring out it out for ourselves, as well as working with other partners who have been doing things a little bit differently.  

So now we're going to spend some time telling you a little bit about what a design system means to us, so we can all be on the same page moving forward.  

But first, before we talk about design systems, we need to touch on atomic design, and I'm sure you're familiar with those principles.  

So we throughout the UX and visual process, we use atomic design principles in order to create a more scaleable site that can accommodate different use cases, and more specifically, I guess we used to rely heavily on Paragraphs.  Now, of course, as we move more into focusing on Layout Builder, we're relying on blocks and sections, but similar ideas.  

And then of course our content types to build our design system.  

>> ERIC SCHMIDT:  Cool.  Yeah.  From a dev perspective, our biggest reason for building atomically, our end goal is pretty much we should always be able to add any component to any page as needed, and it should just work, without much dev effort.  And what that means is that you should be thinking in a componentized mindset with your selectors and your templating so that component is not tied to a page on which it originally was build.  

Occasionally there are use cases for that, and there's ways around that to still keep the componentization impact when you need to be relying on your parent.  But that's the end goal and that is what started this, was our technical director noticed some of the sites we were building out did not have this.  And he said, it's just like unacceptable that we were spending time refactoring components when we can build it ‑‑ and the clients are like, I like this page, and all of a sudden, "It's going to take a couple of hours to refactor," when you can be thinking about it at the beginning.  It's easy to add one‑off stuff, and it still happens but it's always better in the long run to just take a little bit more time at the beginning, take a step back, think of things out before you start building.  And just strife for reusability, just before you even start any coding.  Just really jot stuff down or map stuff out and think ahead and it will save you tons of time in the long run and tons of technical debt.  [Chuckles]. 

>> JESSICA ITO:  So in a minute we're going to talk about some of the different types of design systems.  But they should all serve a similar function.  And for us, that's serving as a source of truth for designers, developers, and our clients.  

And we consider design systems to be a living document that should stay up‑to‑date with the site so it's usable as a reference both right now and forever, I guess, as you move forward through your project or as your designs adapt throughout the product's life cycle.  So at Elevated Third we are fans of design systems and I will tell you why.  They gave the entire team, including the client, a common language that reduces confusion and misconceptions.  A good example is the term landing page.  If you see "landing page" and you're talking to someone in marketing, they think of it being, you know, a page that you land on that has a form and it's really, like, incursion focused.  

Whereas for us, we ‑‑ we name a lot of our unstructured, or super unstructured content types a landing page.  Those are the pages that our clients are using to ‑‑ as they're building out a lot of, like, the unstructured component, Layout Builder‑type stuff.  

They also help us develop more scaleable websites.  And they force designers and developers to remain consistent.  

For us, it's the rule book, and we don't make exceptions to the rules unless there's a good reason to.  

They serve as a useful internal tool that provides a smooth transition from design to development.  So if the lead designer and developer are annotating everything together, which it's time to bring on support devs later on in a project who don't have as much context, then they reference the design system and they know what they need to know to move forward.  

And lastly, they also serve as a useful tool for our clients to refer back to when they're doing content entry.  

Cool.  

So now we're going to talk about some of the different types of design systems that we've seen, and the first one is really just not having a design system at all.  

I'm thinking about this amount like the design system maturity model.  

So step one is no design system.  This means you don't have any type of documentation.  And ‑‑ and this leads to ‑‑ this is what really leads to that inconsistent implementation if we think about the HubSpot example.  

The second is the tactical design system.  You're starting to have some documentation.  It's probably kept in more so of a static document.  So it's a huge ‑‑ to keep it updated.  But at this point you're including lists of components.  Maybe you have digital‑style rules in there.  And there are probably only a few teams that know that it even exists.  Most likely just the dev team and the design team.  

The third type, strategic.  It starts to get more integrated into the design process.  This design system is dynamic, and it's consistently updated and well maintained.  At this point you might start to including some code snippets in there with the documentation, and it becomes more well‑known within an organization.  

And then lastly, we have the integrated design system, which is when the design system is fully built into an organization's process.  It's still dynamic but taken up a notch with releases and version control, and instead of code snippets, maybe now you're using the pattern library in conjunction with that documentation.  And like I said, it's just built in the organization's process.  So that company, you see a lot of more of the company‑wide adoption, a lot more teams being familiar, at least familiar with the concept of what a design system is, to inform some decision‑making.  

So because we are an agency, we find that our sweet spot with, like, thinking about the cost‑benefit ratio for creating a design system is right in between tactical and strategic.  We're working on dozens of projects as an agency at a time, and all of them have fixed time lines and budgets.  So we don't have the time to invest more than we need to in a design system.  

For us, the approach we take is a "good enough" approach.  And that ends up being like what makes most sense for us.  It still helps us do all of the things I talked about before, like having that common language and smooth transition from assign to dev, and it ends up being a great tool for our clients to use as well.  

But for in‑house or product teams, this investment becomes a lot more worth it in the long run.  And we've worked with some partners who have done this type of setup in the past, and it actually, like, amazes me the level of detail that they go in with some of this stuff.  And the time that they spend investing and decreeing this super built‑out design system with symbols in Sketch and pattern libraries and things like that. We just typically as an agency don't have the time to do that, unfortunately.  So we don't have a whole lot of firsthand experience with this type of design system.  So we're going to be spending most of the rest of the talk really focusing on, like, how we get to that sweet spot and showing you a couple of examples of what that means.  

So really quick, I'm going to share two examples of design systems we've done in the past.  

This first one, this is definitely more of, like, your static design system.  So we actually laid this out in Sketch.  

Oh, no, I just got a notification my internet connection is unstable.  Let me know if you have problems.  

We're using a lot more paragraphs.  We sort of, like, along with the atomic design idea, we break out our components.  We typically did in, like ‑‑ like, simple components are the smaller pieces, and then we have our compound components.  So when you start to combine more of those simple components, that's what these look like.  

But you will see, typically for each component, we'll have a description.  We'll list out that the fields for each one, and let everybody know what's required.  

And then we'll have, like, a "things to know" section.  In this example, this testimonial, you're adding simple testimonials.  Each one of these tabs is a simple testimonial.  

And in this example, up to five simple testimonials could be added.  We like to note those things out.  So everybody on the team is aware, and it's especially helpful when our clients are planning for content entry.  

Another example.  

So this is a more recent one that we've put together, using InVision's design system manager.  And I'll show you guys in a little bit how we actually use Sketch to put this together.  But this starts to get a little bit more dynamic here.  You can actually, like, interact with the menu over here.  You can see all of your components in one list, or you can just narrow it down to, like, the molecule level.  

And then when you click into one of these ...  whoops, that's a bad example ...  

When you click into one of these, we can actually include this documentation right here.  

I'm a fan of doing it this way, because it's just a lot quicker.  You don't have to worry about little, like, nuances with laying things out.  You're just uploading screenshots, and you can add your copyright in here.  InVision's design system manager, you can start to add some of the cosnippet in here as well, but we haven't ‑‑ we haven't fully explored that route yet.  It is something that we're looking into.  

Cool.  

Now, we're going to spend time talking a little bit about how this works as part of our process, and how we get to the end result of some of those design systems.  

>> ERIC SCHMIDT:  Awesome.  Yeah.  And just to chime in from a dev perspective, this really succeeds when both design and dev are fully invested and fully collaborative in this process.  It's easier said than done, project to project.  We're lucky enough to have a majority of projects where it's in‑house, and it's definitely, like, the ideal situation.  However, it can still happen without, you know, without having both teams on the internal side.  

It needs to be a feedback loop.  You can't ‑‑ things get bogged down when you have a design team sending you stuff, not thinking through Drupal componentization or design systems.  

If dev is not thinking in a componentized mindset, it sets things up to be awkward.  

So at the outset, it's great to get buy‑in from everybody at the beginning to be kind of closely in touch and iterative throughout the process when it comes to breaking stuff down.  Design is great at componentizing stuff, how they see fit.  However, Drupal has limitations that they may or may not know.  That's where dev comes in and can help out with that as well.  

>> JESSICA ITO:  Yeah so as the designer, it's part of my job, like, Eric mentioned, to start thinking about the design system and the components and the atomic design as I am putting the wire frames together.  I'm constantly thinking about what could be a component, how can I consolidate things that are similar, and what the functionality of something might be.  

And personally, I feel like I've gotten so used to thinking this way that I sometimes ‑‑ I have to, like, just as a designer, you know, we of course have goals of being creative.  So sometimes I have to force myself to stop thinking about this so much, so that it doesn't, like, limit me and keep me in the box.  

But I think it's a good thing and a bad thing.  It can be ‑‑ it can be a limiting mindset, as a creative.  But it is really helpful as you move into the dev process.  

And then once I have done my part with the wire frames and they're completed, the lead designer ‑‑ this screenshot here is an example of a project that Eric and I were lead designer and lead dev on.  We came together and this is where I was able to tell him all the things I was thinking about as I put the wires together and we can start annotating them.  We'll have discussions on them, and this is really the time when we start making a lot of those decisions.  

So I can let him know, "Hey, I was thinking about this component in this way.  This is how we can reuse it across the site.  Here are some fields.  And, like, some functionality."  In this example, you can select up to six, but the client left it manually.  And we also start thinking about naming conventions as well at this time.  

So Eric, do you have anything to add?  

>> ERIC SCHMIDT:  Yeah, if you want to bump to the next slide, I can tie it together, and go ahead one more.  

>> JESSICA ITO:  Okay. 

>> ERIC SCHMIDT:  There we go.  Calling this back to the last slide that Jess showed with the annotations, we go back and forth quite a bit on there, and then that is what eventually results in what we call a build spec, a fully fleshed out spreadsheet where he can architect our ideas.  

It codifies the collaboration between design and dev and it allows for quick iterations of architecture.  Instead of going into Drupal and building the content type out and seeing if it works, we have a tab for nodes, for components, for fields, and just kind of list these things out and can quickly just iterate and see, does this feel right?  How does this work?  For one, do it quickly, and also it allows for passing things off as well too.  

If I have an idea in terms of architecture but don't necessarily have the time to build it out, I can document it here and shoot it over to somebody else and they know exactly what I was thinking of and can get that built out and just again, just makes it much, much easier.  It's kind of akin to doing wire frames as a dev instead of doing something fully high‑fidelity.  I'm just doing roughs to get a feel for how it would work and it turns it into a boiler plate for a design system.  When she was screen‑sharing, the design system manager in InVision, this is me giving them the build spec and they're going through the build spec and making it pretty and putting it into the design system manager, putting the fields in, the requirements, and adding the screenshots.  So it's this, again, constant feedback loop that we've created that just ends up coming up with something awesome that we're able to refer to, now and in the future.  If you want to go back to that last one, since I got out of order here.  

And then finally, just kind of one last point on this as we get into the collaborative process between Jess and I.  It's very easy to end up with components that just with get overly complex.  By that, I mean components that end up having tons and tons of options.  It could have a background image.  Or teasers of different content types.  All of a sudden you end up with all of these different pieces into a single component.  And I have just learned the lesson many times the hard way to just break these out as they start getting more complex and more options are needed.  It's just much better to break these things out into their own components.  

They get unwieldly both for de ‑‑ devs and content add minutes.  I'm dealing with if statements and templating conditionals, because I'm trying to account for different ways it should look.  And for content admins, they're adding a component to a page with 100 different options and they have no idea how to get to the component they're trying to make when they're looking at the design.  It's really hard to figure out ‑‑ okay, what do I need to do to add to this page?  

That's where it gets kind of tough.  It's a case by case basis.  There's no hard and fast rules for when you should break it out.  But for me it's a gut feeling.  If something feels unwieldly, it probably is, and it's time to think about breaking it out.  

It may seem more time consuming to build a whole another ‑‑ or content type but in the long run it's quicker especially if you're iterating about the build spec.  

That's all I got there.  Jessica, do you want to pop back through there?  Sorry about that.  

>> JESSICA ITO:  No worries.  We saw the front end of the design system and what that looks like earlier.  I'm going to hop over to Sketch and show you guys how we use Sketch and the Craft plugin.  

So this is ‑‑ these are my design layouts in Sketch here.  

And we've got the Craft plugin, plugged into Sketch.  If you're not familiar with that, I'll add a link to our presentation page with the slides.  And I can add a link to Craft as well.  

But it's really great.  It ‑‑ [muttering] puts the tool bar over to the side.  The nice thing about it, you can use it to upload an art board to Sketch.  If you upload an art board to Sketch, versus just exporting it as a flat‑end file, then this is what allows developers to use the inspect mode on InVision.  Which is nice.  

But for the design system, the hotkey, if you're on a Mac, it's command‑L.  

You open up like this, and you see it pulls in colors.  Your textiles.  If you have determined what those textiles are and you have them in Sketch, you can add them here and it will upload everything that a developer may need to know.  

If you have any layer styles, and I don't have icons in this design system, but it's really nice, because you can upload them directly from Sketch, and anybody can reference the design system and download them as an SVG from there, which is cool.  But for components, you can add however many folders you need to.  However your organization organizes, your components, you can reflect that in the affordable system here.  

But let me just show you how you can add a component.  

Okay.  

So we'll add ‑‑ we'd add this component to the design system here.  Right now I have this ‑‑ my layers are a huge mess.  But I just have this named "group 15."  [Laughs.] 

If I go over here to the design system manager, I can click this plus here.  And you will see, it's adding it.  It's adding it outside of my folders because I didn't have a folder selected.  But if I click on that component, I can rename it.  So we'll say this is, like, um ...  just related content component.  

And then you can ‑‑ you can really just add whatever type of description you want to in here.  

So, like, I mentioned earlier, we typically just add, like, a description.  If we have a specific use case for this component, and we will note that here, and the fields, and any functionality.  In this particular example, this component, we would let our clients know that it's pulling in dynamically pulling in related content, based on the tags that are applied to that parent page.  And it can pull in a couple of different content types.  Like articles, webinars, and resources.  So that's pretty cool.  

But they can also manually override any of these as well.  

So it may automatically populate the teaser for this featured one, but they would be able to override really any of these ...  

Then I'm going to jump back over on it what it looks like on this site.  And it'll let me know here if I have this open in the browser.  That I'm viewing an out of date version of the library, because I refreshed it, or I changed it in Sketch.  So I can just refresh it.  And then if I go back out to the components, we'll see that this component has been added here.  And anybody, as long as you have, like, the sharing permission set up right, anybody who has this link can come here and read whatever documentation we have about this component.  

So that's it for the demo for right now, for my side.  But if you guys have any additional questions about Sketch or InVision or the Craft plugin, I'm happy to meet you guys on the Slack channel after this talk, and we can get those questions answered.  

And then, Eric, I am going to stop sharing so that you can start sharing.  

>> ERIC SCHMIDT:  Yeah, that sounds good.  

All righty.  

Everybody see this okay?  

>> JESSICA ITO:  Yep.  

>> ERIC SCHMIDT:  All righty.  

Let's full screen here.  

Good enough.  Cool.  

Yeah, so now I'm going to start running through some of the development tools that we use to implement the design system that Jessica or other designers come up with after the discovery phase and the back and forth that we have.  We have quite a few tools, some of them are contributed modules, or internal tools, or theme‑level tools, stuff like that.  I'm going to run through the highlights.  Every project's a little bit different.  Might have different needs or restrictions on what we can and can't use.  But these are the kind of the highlights that pretty much find their way onto each and every project we're using.  Run through some of these here.  

First one, Paragraphs.  Which is pretty much the quintessential componentization for Drupal.  Most people probably have experience with this.  

If you don't, it's just a great way to essentially allow, for one, multivalue fields and it lets you create custom inline entities that can be added to each and every page, allowing one field to have multiple different types of components added.  For instance, a header field that allows you to add multiple header component types.  Basic or more full‑featured banners, stuff like that.  It has been used by us for years now.  We've gotten good at using it, and we've honed it in, especially when we've ‑‑ when I get into some of the modules that we use with this as well, that just make it a really awesome asset to our tool belt.  It's slowly getting replaced by Layout Builder now that it's stable, and I will go into that a little bit here well.  Layout Builder is not as full as ‑‑ fully ‑‑ I don't know ‑‑ the bells and whistles are not all the way there yet, in my opinion.  So we're still using Paragraphs for different use cases, mainly the for pages that are not using Layout Builder, because Layout Builder is an all other nothing thing.  When you have it on a page, it's pretty much only going to be using Layout Builder.  We have certain pages that are more strict, like a blog ‑‑ structured, like a blog page may have it at the bottom, and we leverage a Paragraph field there.  It still gives us great flexibility for componentization and it targets your styling and templating in a very compartmentalized fashion.  Above and beyond Paragraphs we use Paragraphs browser.  This is a module that we built in‑house and it's on Drupal.org, so it's open‑source and usable by anybody that would like to use it.  

I think it was released two or three years ago?  I think it's technically not a full release yet, by the definitely ‑‑ but it's definitely stable enough that we've been using it without issue.  

The beauty of that module, rather than having small buttons with a title when you're adding your paragraphs, it lets you actually have a whole modal window, and I will show you a live example.  

It gives you the ability to show descriptions and screenshots is the clincher of each component.  This is how we translate that design system that Jess was just showing.  

So they can look at the design system, see the component they're looking for, pop over to Drupal, open Paragraphs processor and it's a one to one.  Here is that in the design system and here is it in Drupal.  I know what I'm trying to add.  Just makes it super, super easy.  And I think it's a great module to use, if you're using Paragraphs.  So I have a quick example I can show.  

This is a UBT, a bank website we recently rolled out.  I have got a header, different fields, using a paragraph.  I'll show you main content here.  

Essentially it just ‑‑ instead of having a bunch of different buttons or a dropdown or whatever, it gives you one button for adding a component.  If I click it, it's going to pop up a modal window.  You have different filters for different types.  If I scroll down you will see there's quite a few.  And the word billboard might not mean something to somebody, necessarily.  But when they see an image, they're like, oh, you know what that is.  Or a bridge.  Just makes it easy to add.  If I click add it plops the paragraph right in there.  It's running a little slow for some reason.  

But yeah.  

Super powerful module.  

I highly recommend checking it out if you haven't.  

Configuration's a little ‑‑ it's not hard.  It's just ‑‑ it's a slightly learning curve.  Documentation is written well but if you have any questions I'm happy to answer questions in Slack afterwards.  It's a great module to dig into.  

Cool.  

So those are our main two power houses that we've leveraged a lot in the past.  But we're starting to dabble quite a bit in Layout Builder.  And this is cutting‑age componentization for Drupal.  Just made stable in the 8.8 release ‑‑ or it might be 8.7.  It feels like the wild west.  There's great opportunities, and we've seen powerful ideas come to light with this.  It's just ‑‑ it's got some needs still.  There's still some gaps with it.  

But the beauty of this module now that we're discovering as we've dived in, I think when we growing like the fourth project that we've leveraged this, to varying degrees of success and complexity.  

Starting very simple with very small sites.  And then moving into larger sites, and we're rebuilding our internal site, and leveraging Layout Builder fully and this is where we're finding the true power.  And the true power, it's pushing dev and design to be thinking more about fluid componentization, meaning with Paragraphs, you can pretty much restrict what components can go where into which paragraph field.  

Whereas other at least at this point anyway, if there's ‑‑ at this point you can't really restrict what block goes into which section.  If you have a block that goes into a column, you can add in your banner.  

But you can envision a fourth column, where they can drag it up into a big column.  We're having to think through, you know, what does that look like?  Should we be accounting for this?  And it's kind of a delicate balance of content entry training.  "Hey, maybe you shouldn't do this because you won't look right," but would inform design in that manner.  "Maybe this will give you a cool idea that you didn't think of.  You're thinking of this in a fourth column.  Imagine what it would look like in a full column."  

And all of a sudden you've created a new component, almost with minimal effort because it just kind of works.  It's creating a cool, even more back and forth communication.  Where we're just ‑‑ the design and dev are informing each other in whole new ways.  That's when we're digging into this and leveraging it into its full potential.  

Cool.  

So this does have some additional modules that we're leveraging quite a bit as well.  There's three primary modules that we've found that just make Layout Builder way, way easier to use and nicer for admins as well.  

First one being Layout Builder browser.  

Cool.  What it does, it makes the side bar on your page a little bit easier to ‑‑ to manage.  

And I'll show you an example of this ...  

Here.  And I don't know, if you're not familiar with Layout Builder, this might all be super wild.  But it cleans up this side bar and allows you to add icons or images to I will straight what the components are and it allows you to compartmentalize, similar to how Paragraphs browser lets us compartmentalize and categorize stuff.  Layout Builder gives ‑‑ this gives you see the ability to hone more in and make content for admins.  

And the other one is Layout Builder modal, which gives us an additional layer of functionality that kind of resembles what Paragraphs browser does.  

This is, if you add a component, it's going to pop over a modal window.  To let you do inline editing on the block.  Example, as I click text, it gives you a popover here and you can add the block directly, instead of having to do it in the side bar or other wonky ways.  

And then the ‑‑ let's see.  

Yeah.  

The one gotcha with this that we've encountered, this is ‑‑ Layout Builder is leveraging your front end theme, not your admin theme.  So we've ran into issues because our admin theme makes it look pretty but on the front end it's not styled to resemble what it looks like.  A quick fix is we've been included our admin kit or theme on our front end Layout Builder pages and that kind of definitely has helped to make this look a lot better.  

And then third and final module that we've been leveraging is called Layout Builder restrictions.  

[Muttering]. 

Open page as well ...  

The main reason we use this one is to restrict which layouts are available to be added to each page, meaning we don't necessarily want every single page to have every single layout added, and this gives the ability to choose which sections are to be added to each page.  

Again, this ‑‑ like I said, this is the wild west.  There are tons of contrib opportunities for this, to one to make the admin experience nicer, and also some of the ability to restrict by block and stuff could be nice but it's opening to thinking outside of the box.  

So just worth keeping in mind and digging into.  

And then on top of this, I'm going to kind of dive into our two internal tools that we built out.  They're both open‑source but originally they were internal tools that we used the first of which being Paragon, our Drupal 8 base billed.  It's on Drupal.org as an install file.  It's not stable yet but we have been using it ourselves to build out projects.  It essentially just preinstalls many common modules, shortens the setup time for Drupal from hours to minutes, especially as it relates to configuring complex stuff like media libraries and entity browsers and stuff like that.  That stuff comes out of the box preconfigured and ready to rock and roll.  

It takes the guesswork out of spinning up the sites.  In addition to Paragon it comes with Themekit.  If you're not familiar with Foundation, it's a responsive framework that gives you, for one, tons and tons of out of the box, ready to use, accessible components, such as like accordions and responsive navs, tabs, stuff like that. We leverage those extensively so we're just not reinventing the wheel.  We can just reference the foundation component, throw it in and know it's going to be accessible and easy to use.  In addition, it give us componentized theme structure out of the box.  And I will show a demo of how we are directing our themes currently.  We are ‑‑ with our new side build and with Layout Builder, becoming a ...  plug my computer in before I die.  

With Layout Builder making us start to think outside of the box.  We're rethinking how we're componentizing our theme layer.  Give you ‑‑ [indistinct]. 

And final point, it's build with Webpack for optimized code.  It helps us aid in that componentization, and I'll give you a demo of how we use Webpack as well.  Webpack is a lot more extensively used for front end frameworks and stuff like that. View, react, and stuff like that.  We're taking bits and pieces of those front end frameworks and adapting it to the Drupal theme with quite a bit of success as well.  With that, I will ‑‑ we will jump over to my ID and give you guys an example.  

Cool.  Just a basic install here.  

Themes, custom, and I've got my theme kit.  Admin is our admin theme.  I think it's definitely the rock star here.  Again, it's set up with Webpack, so you have a Webpack config.  

It allows us to create different entry points for the different components and they can only include that CSS or that JavaScript in that particular component, as its own individual library.  

So there's tons of entry points and it's confusing, but what this is doing ‑‑ let's go down to components.  I've got a component called page turns.  This is to specify the CSS or the SASS file, go ahead and compile that, and it compiles into the desk folder with a file name called Htran here, and I can create a library for that ‑‑ in this library file.  I'm creating a library for that and it's including this page‑turn.  It might not be huge but you will see tons of CSS and JavaScript.  When you compartmentalize this and takes it over to the template, you can include that and only that.  

If the component is not on the page, it won't render.  And we're seeing huge performance improvements.  To give you an example of how that looks once we get down ‑‑ first we have global ‑‑ this is the stuff that you are including, all across the site, all of your global templates and your global SASS, your base typography, but the meat and potatoes is this directory, and if we drill into components, and we had a sample, and then page turn right here.  We're organizing this in the same manner as that design system was organized, and I've got my ‑‑ my CSS here, and I've got ‑‑ there's a little bit of wizardry going on with this where it's including this theme kit library, depending on the name of the component, only that page.  

So this is kind of a simple example.  And like I said, the performance improvement of ‑‑ including the CSS from a super small CSS file only on one page might not be huge but when you compound it across the entire site and you're only loading the components as you need them, it's powerful.  And we're seeing awesome results.  

The added benefit is ‑‑ that example is only CSS but we're including templates with the component.  

If somebody else comes into the project at a later date, they know exactly ‑‑ if they're looking at a resource they can look at the theme and they know exactly what is controlling what.  Just by looking in this one directory, instead of having to look in templates where there's all your templates, and look in your SASS, instead of doing that, we're kind of fog that front‑end framework.  View likes to do this a lot, to keep stuff in the same directory.  We're adapting that and it's making it a lot easier.  There's a little bit of a learning curve getting Webpack rolling, and that's the beautiful of Themekit it gives you that point.  

Checking on time.  Okay.  We're good.  

So yeah.  This is the main ‑‑ the main dev piece that I wanted to show case, just because this relates to design systems in a great way, and it's just really cool to think kind of bring that full circle all the way back to how that design system affects design, affects dev planning, and affects dev implementation and then that all filters out down to the client as well.  And they end up benefitting immensely from this componentization as well.  So we can bounce over to ...  

Client training and content entry.  And I'll let Jess jump in here.  

>> JESSICA ITO:  Cool, yeah.  Yeah.  So wrap it up, we're going to talk a little bit about how all of this, like, Eric mentioned, comes together to benefit the client, to help them sort of understand the value of a design system, and how it ‑‑ and how it helps them.  

Eric, can you make your window a little bit bigger?  

>> ERIC SCHMIDT:  Oh, yeah.  Sorry about that.  There we go.  

>> JESSICA ITO:  Cool.  Thank you.  

All right.  For unstructured content types where the components play a really large role, we urge our clients to spend the time making a plan for each page.  And I would organize, like, for content entry, that this is one of the most important steps of doing, like, that actual manual content entry process.  

Making a plan for a page ahead of time allows ‑‑ we have to tell our clients it allows them to move quickly once it's time to start migrating, and making time to think through the content and the page polls, how we can use components will help them get the most out of the design system.  Typically what we recommended, and we'll show you a couple of quick examples of ways that clients can do this, but ‑‑ that they have the current page of their old site up ‑‑ current page of their old site up, as well as the component guide or the design system, like, the component portion of the design system.  And then we tell them to think about the current content on the page, and the goal of the page, and does anything need to change from there.  

They can use the component guide to find components that will accommodate, or adapt the page to fit.  

And then start documenting that plan so when it's time to enter that page into the site, they can reference that plan to just quickly build the page later on.  

So most of the time, the clients that we work with, they are starting off with what we lovingly refer to ‑‑ like, on the left‑hand side is a wall of text marketing page.  So really what that means, there's just ‑‑ it's just really text‑heavy.  

So our goal, one of our big goals with the design system and componentization is to just make their ‑‑ help their content be more engaging and making it more scannable for that you are users to understand the point of that page better.  

For the clients, the idea ‑‑ sometimes they've been doing things a certain way for a long time.  

And the idea of figuring out how the content on those long copy‑marketing pages fits into the new componentized designs can be overwhelming at first.  

So teaching them how to use the design system to aid in that process is pretty important.  And we just, at this stage, emphasize to clients that the components are probably not going to be one to one with what they currently have on the site.  

So sometimes it's probably not going to be clear right away which component a client will have to use.  And in those cases, we really advise adapting content to fit into one of the new components.  

In this whole process of going through the planning phase really, I think, helps clients critically think through and, like, just ‑‑ just taking that step to plan it out will help them get the most out of their design system, so that they don't just rebuild what they currently have.  And then these are just some quick ideas for how a client can document their plan.  

Some of our clients have had success with the hands‑on approach to planning their content, which literally, like, #1 is just literally printing out the components, cutting them up, and, like, rearranging them on a table or something like that.  

And taking a photograph to document that plan.  

If you click on, Eric, the second example.  

This is a way that our clients can do that digitally.  So this is another InVision tool that we like to use a lot called InVision free hand.  What I've done on the left‑hand side is taking screenshots and added in screenshots of every component within the design system.  And then we tell our clients to copy or paste or, like, option‑drag those components out to put together plans for a page.  

Can you zoom in just really quickly on the example page plan?  

>> ERIC SCHMIDT:  Yeah.  

>> JESSICA ITO:  Cool.  So you'll see, like, they can just copy and paste those components.  And even though the content itself is going to change, it helps them sort of go through that exercise of thinking about what components they're going to use.  They can quickly just, like, document what they want to change, like, maybe they want the image on the left.  So the sections there.  Or documenting notes about, like, content, what type of content you want to use that component for.  Which testimonial you want in the future, which sort of, like, tags you would want that content to be populated, based on.  It's a good way to help people start thinking about design systems and the way that we're used to doing every day.  

And then the third example ‑‑ you can just show it super fast.  But this is ‑‑ this is another way that we've had clients approach us in the past.  

So this particular client created a separate content doc for every single page.  And then actually had some people from our team do content entry.  But you can see, like, in blue, they have the name of the component up there.  They have maybe, like, if it's a variation.  They've outlined what the H2 is.  What all the copy is that I need to have in there.  

They'll even include links to images and stuff.  They've gone through the planning process.  This is the output of that, with taking it to the next level and having some real content in there.  

And then when ‑‑ when you're going through and doing, like, the manual migration process, we, like, to use a spreadsheet to manage that process.  It's easy for every page to just throw in a link to that content doc and it has the plan.  I already know which components I'm using, what order they're going in.  I have all of the copy.  And everything that I need to build on it that page, without needing to bother anybody.  [Chuckles]. 

Cool.  

>> ERIC SCHMIDT:  Cool.  All right.  Yeah, one final note, from myself in terms of a dev perspective on, like, client training and content entry, the utmost importance of help text.  The main point being because it makes sense to you doesn't mean it makes sense to your content editors.  And just because it makes sense to you now doesn't mean it will in a year when you come back.  I find that it's extremely helpful to make sure you document each and every content type component, field, every content type should have a description.  As an admin is adding content, they may not remember which is which.  If you have a description, it's helpful.  You don't want to get into a situation where a client's all of a sudden doing content entry and adding page upon page, and now you have a view, and having ‑‑ being sure to comment that. 

But again, any nonstandard field should just have some help text added.  If it's a heading, it's fairly obvious what it's going to do so you may not need it there but it's a field to create a custom sort or something like that, Drupal makes it easy to add help text.  It'll save you time in the long run and make your admins more happy.  

Yeah.  This helps content admins as well as yourself and other devs in the future.  

Quick example from UVT, that bank website that you showed you before, for just help text.  This one's actually an interesting example because of headings.  You might think a heading or microtiles wouldn't need a description.  But this one had SEO implications where these small title appearing above the anything title, that's H1, and content admins may not know that.  If they're trying to be SEO‑conscious, that's an instance where you want to be explicit with that stuff, and that filters down through different ‑‑ other components.  Just adding help text where necessary.  It doesn't take much time.  As you're thinking through the build spec and stuff like that, it helps to do it then and there rather than after it's built.  Just keep that in mind as you're building stuff out, and you will thank yourself later.  

Cool.  And that's ...  

Pretty much all we have.  I know there's kind of limited time.  We got about three minutes left.  If there's any questions, we can try and squeeze it in.  But again, Jess and I will be in the room Slack after this, if you have any questions, more than happy to answer them.  

>> JESSICA ITO:  I threw a note in the Zoom chat with the link to the MidCamp Slack.  And you let you guys know which channel you can find us in, in Slack as well, if you have any follow‑up questions.  

>> ERIC SCHMIDT:  Yeah.  And then just two more final slides.  Feedback is definitely appreciated.  If you guys have any feedback, feel free to visit this link on this deck here.  

Positive, negative, we want it all.  Let us know how we did.  

And finally, contrib day is happening, digitally.  Don't forget about that on Saturday.  They pop in there.  It's great to give back to the community.  We all get a lot out of Drupal, and I think it's extremely beneficial to try and give back whenever possible.  Just because you don't know how to code doesn't mean you can't give back.  Documentation can be written.  UI and UX can happen.  I know there's a ton of that happening with the new Claro admin theme.  Just because you aren't a coder doesn't mean you can't help contribute.  Keep that in mind.  

And with that, thank you.  

>> Great.  Trans, everybody.  ‑‑ thanks, everybody.  I'm going to stop the recording and figure out what happens next.  

If you will stop sharing your screen.  

I can put on the loop slide.  

>> ERIC SCHMIDT:  I've quit sharing.  

>> I can still see your screen. 

>> ERIC SCHMIDT:  Sorry about that.  

>> Sweet.  Thank you.  

>> ERIC SCHMIDT:  Jeremy and David and Ryan, you have questions.  Pop over the Slack room and we can talk about that stuff.  

Thanks, guys.