The Growth Theme for HubSpot CMS Starter and the Best of HubSpot CMS | Developer Day 2021

Theme settings is a use of a concept we like to call style variants, which is something we tried to lean into a little bit more into this theme to make it feel more like a design system. So say for example, if I check out the icons group over here, if I check out the size options, you can see that there's a couple different variations. There's small, regular and large. And under each of these there's a size option to size the actual icon. And there's some spacing options to add some padding around the icon. If I go back out to icons, you can also see that there's this dark and light section where I can change the fill color of the icon and the background of the icon. This looks great. Let's go ahead and take a look at what this looks like in the page editor. Be giving a quick demo to highlight some of the different ways that we're able to solve for some of those problems. So for those of you who haven't seen the grow theme yet, we launched this in August of this year along with the CMS starter tier. And our goal for the Growth theme was to take all the learnings and findings that we had from our original default themes that we launched with the CMS Hub a couple of years ago to really boil those down into one specific theme. We also wanted to make sure we were taking all the new and great CMS features that have been launched over the last couple of years and baking those into the growth theme by default. So what problems were we trying to solve for when we built out the growth theme? The first problem is that the website building process just took too long. We wanted to find ways to make our users more efficient so that they can build out their websites a lot faster. The second problem is that users couldn't customize 100% of their theme. They could maybe get a gap about 80% of the way there, but there was an awkward 20% gap where they were lacking functionality to edit things that they wanted to edit. So we wanted to make sure that the theme was a little bit more flexible for those users. And lastly, themes weren't fully optimized out of the box. We've since made a bunch of updates to our original default themes and the boilerplate. We wanted to make sure we took those improvements and baked those into the grave theme by default as well. So how do we solve for some of these issues? I'll be giving a quick demo to highlight how we solved some of these problems. This is not a comprehensive list of everything we did by Any means. So if you're interested in anything we talk about in the demo, please feel free to hit me up on Dev Slack. I'm happy to chat about any of this a little bit more. And without further ado, let's hop over to the demo. So the first problem that I mentioned was that it just took too long to build out a website theme on or took too long to build out a website page using one of our themes. One of the first things we wanted to do to address this was to leverage the new sections feature to give you an example of how sections can help speed up a page build. Let's say, for example, I was on my homepage here and say I really like this section over here that's on my homepage, but I want on my about page prior to sections. Basically what I would have to do is put my about page on one side of my screen, my homepage on the other side of my screen, and try to manually recreate this from scratch, making sure all the rows and columns and everything lined up perfectly. That's a really tedious and time consuming process, especially if you wanted to add this section to more pages than just one. But now with sections, if I go over to my about page and scroll down, let's say I want to add that section right between here. All I have to do is click this button. Great. It looks like this section matches the one that's on my homepage. Awesome. So with two clicks, I was able to add that same section that's on my home page over here on my about page. One of the other ways that we're able to help speed up the page building process was by leveraging brand settings within theme settings. So I'm going to go over to my theme settings here. And similarly to how you can inherit a style from one theme field to another, you're now able to inherit from your brand settings over into your theme settings. So say for example, I have colors over here and the primary here is green. Right now if I hop over to my brand settings and switch the screen over to a red come back over to theme settings, you can see that the button in the top right corner has been switched to red. If I check out the colors, the primary color switched over to red as well. I don't like that red color, so I'm going to hop back over to green and give us a refresh. But the real benefit of using brand settings within your theme settings is if someone already has a brand kit set up prior to using your theme. This just Saves them one step so they don't have to then go change the same colors over in your theme settings. And a real benefit is that the theme already starts to feel like their brand as soon as they start to touch it, which is a great user experience. Another thing I want to touch on while we're over in theme. So if I go down on my about page now and check out this icon module, then I'll hop over to the Styles tab. You can see that we have this top level group called presets, and the goal here is to tie this into those different theme setting variations that we showed already. So you can see I can switch this between dark and light. I can make this large or small. And the benefit of presets is that it allows you to have a couple different variations of some of your modules that are tied to one spot and theme settings. So someone doesn't have to individually go into each different style field to get every module to look the way that they want. This is also really beneficial because if you have, say, a lot of this icon module across your site, and as your site gets bigger, they wanted to make one change that impacts the rest of the site, I wouldn't have to go back and edit every individual module. I could just edit this in one spot. And similar to style variations, we also added a concept of layout variations on a lot of our modules. So say, for example, here I can choose between listing card and the goal here was just to ideally get a good starting point for someone, give them a layout that they prefer out of the couple of choices so that they don't have to mess with the CSS to get the look that they want. And so the second problem that I mentioned was that someone couldn't really customize 100% of the site. They can maybe get about 80% of the way there. And so one of the first things we wanted to do to address this was to leverage the new Style Fields feature, which we just briefly saw. So say, for example, on that homepage, I noticed there was a button on that section that's not here on my about page. Let me go ahead and drag a button here to the bottom of this section. Great, that looks cool, but it's left aligned. Let me see if I can fix that. Awesome. So there's an alignment option. I can center align that very easily. The benefit of style fields here is if someone wants to make additional changes on top of your presets, or they want one module instance to look slightly different from the rest, for whatever reason, they're able to do that and they have that control. I know as developers you've definitely had the back and forth with content creators to want to change one tiny thing and that happens a lot. And so now you're able to set the parameters from which someone can make those one off design changes without you having to go into the CSS every single time they want to make that change. And even worse, if someone didn't want to consult with you if they wanted to make that change, this avoid someone going into the style sheet that you've carefully curated and breaking the whole thing just to make one simple design change. So another way we were able to make the website building process a little bit more flexible was over in the blog. If I go to edit my blog listing page here, you can see with the new blog listing page editor that you're able to actually edit your blog listing page, which was not the case previously. Previously you had to completely hard code your blog listing page, so there was really no way for a content creator to come in and edit this content. Now since we've been able to switch over our template to be fully drag and droppable, you can edit this page like basically any other page. I could edit the content. I can also leverage some of the awesome new features that we saw previously like style fields and I can even add in sections. Lastly, one thing I wanted to highlight in terms of flexibility was our global partials. So on our previous themes we got a lot of feedback that these weren't flexible enough for our users. These were also previously hard coded so someone would have to come in here. They could edit the content of each of the modules, but they couldn't add, remove or move around modules to their liking. So we've since made this fully drag and drop. And the benefit is say, for example, I was a small business and I really like the footer, but I don't have enough content to fill out this menu here at the bottom. Rather than keep that in there, I can go ahead and delete that and re add that when I want to or when I have enough content. Just makes things a little bit more flexible. And then lastly, the thing that the last problem that I mentioned was that our themes weren't necessarily fully optimized out of the box. And again, this isn't a comprehensive list of everything we've did, but I just want to highlight maybe one or two things per category to showcase some of the improvements that we made for growth theme. So for performance, one thing I wanted to highlight here is that if I Scroll down and I go to edit any of the images here. One improvement that we made earlier this year is that we added a browser level lazy loading feature across all image fields and image modules. So you can see here that the loading is set to lazy across all of the growth theme templates. We want to make sure that those were set to lazy so that people were starting on the right foot in terms of SEO. One thing I wanted to highlight quickly is let me go ahead and drag this offer card module over here. If I go to edit the content here, you can see that this is a rich text field. Previously, as a developer, I'd be really tempted to build this out using two individual text fields. And the reason being is I wouldn't want to offer up all the options of the rich text field for some of this content because I wouldn't want someone to be able to do something a little bit wacky like add a table in here. That would break responsiveness. But now that I can configure my rich text fields, I can come in here and I can fully customize what's over here. So I could. In this case, I just limited to specifically text options and I added an image and emoji option. The benefit of this for SEO and accessibility is that let's say this button was a heading three. And over here I notice in my card this is also a heading three. So my headings wouldn't be flowing in sequential order if that was the case. And if I use two individual text fields. The issue with this is there's not an easy way for me to go ahead and change that element type. But now if I'm using a rich text field, I can simply just highlight this and switch that to an H4 and that solves my problem very quickly. Lastly, I just want to highlight a couple things in terms of accessibility. So if I open up the page here, one of the first things that we did is if you notice in the top left corner there's this skip to content link. I'm navigating the site using my keyboard. This is the first thing that I focus over and it basically allows me to just jump right over my logo and my whole header and all those options up there. As someone navigating using a keyboard, if I know what I want to get to, I don't want to have to go through the header every single time. I want to just get down to the main content. So this just allows me to skip to the main content so I don't have to tab all the way through that heading content. And speaking of the navigation, we've made a lot of improvements over to the Grow theme menu, specifically surrounding accessibility. We've updated ARIA attributes and made sure that the menu is fully keyboard accessible. And this, these are also improvements that we've made over in the boilerplate. So would highly recommend checking out the release notes in the boilerplate for some of the recent menu updates if you're interested in pulling those types of updates into your own projects. And so that's it in terms of the demo. Thank you all very much for your time. As mentioned, I highly recommend checking out the boilerplate and contributing to it. There's a lot of more detailed notes on some things that we did over there in our release notes and in the wiki of the boilerplate repository. There's a link over here if you're interested in checking that out. There's also a link over here for the growth theme. If you're interested in pulling that down and playing around with the code to see some of the different features that we highlighted today. I'd highly recommend checking that out. That's also over in our developer documentation if you want to download that.

That.

And without further ado, I'm going to move this over to our panelists with Victoria, Victoria and Mitchell where we'll be able to answer some questions.

Thank you so much, Jason. Welcome to our panelists. So I'm just going to kick us off and start from the audience first. Will we be add existing sections?

I can take that one, Nicole. So I know this is something that is currently under consideration with Katie Tate's team. Katie is actually in this session in General Chat. If you're interested in this, I would recommend just kind of reaching out to her directly and setting up some time in order to discuss your specific use case. It's a bit complicated, but it is something that we are interested in doing.

Great. More questions. The section Dean wants to know is it possible to edit or add more style options inside the Styles tab to section column examples like adding borders. Oh Mitchell, I think you're muted.

Yeah. So there's like a. I'm going to forget the exact number number of like style options you can do. So I got to double check about borders. But generally like if you're looking to do something like a border and it's not supported in the style tab, I would definitely recommend that you. Again, I'm going to use this line again. Get in contact with Katie Tade because she is the PM of those teams that enable those various options.

Great.

Okay. How about this one from Mark? Has anyone has any thought been given to the marketer experience for finding these global settings such as theme content editors may be added to the sidebar of the website page or listing view. I know that that's something we've been. I'll pass along to you all.

I think that's always under consideration as we sort of evolve theme settings and branding in general. The intention here is to give that control to the marketer in the way that the developer desires it to be controlled. So we're still fairly early with theming and theme settings and branding, but I would expect that to be available sometime between the next 12 and 18 months as we go along. I don't want to over commit.

Awesomely something we're thinking about. How about can marketers save variations of the developer created sections?

Yes. They can't. Go ahead, Mitch. Yes, they can. They can. I think there is a limit in terms of how many sections depending on what tier you're in. But yes, they can save their own specific sections.

Great. And adding classes to the sections.

Yes. So that fits with the first question to some extent. That is also something that we've heard a little bit of feedback on. We'd still like a little bit more feedback on it from our developer community, but it is something that I know Katie's team has spent some time considering.

Got it.

Add drag and drop blog page templates.

Short answer. Yes, we don't have an exact timeline to give to it, but definitely one thing that we're hearing is things like the actual blog pages themselves, not the listing page, but the actual page. Similarly, all of the sort of system pages, membership pages, that sort of stuff, that's all stuff that we do want to move into the same drag and drop experience. Not only does it provide drag and drop capabilities, it means you stay out of the HTML and the actual code of those pages. But it also allows for a lot more capability and functionality when it comes to things like analytics, multiling. So by moving them to the drag and drop experience, we actually get this whole bundle of features along with it. No specific timeline to provide with it, but there's a lot of benefits. So we definitely want to move them and unify those experiences.

Great.

And we have a question from Michael who wants to know, can you add no logic to sections so that they appear or don't appear on pages that you define?

Take it. Not today. But Michael, I'm actually interested in the use case that your customer has for this. That sounds like something that we'd like to chat further about and learn a little bit more about when that might be appropriate to show to a marketer or a content creator.

And Vicki, a follow up question. Do you have any recommendation? A few. You know, we want to hear more about this use case. Where should folks submit that use cases or what's the best way for them to get in touch?

Yep, that's a great question. I'm actually going to drop my personal email address here in General Chat and if you reach out to me directly I will ensure that you get to the right product manager for this. So I look forward to hearing about that as well.

Prepare your inbox.

You.

Let'S see, just scrolling through how about Are there plans for the rich text editor to allowed CSS classes applied such as headings, paragraphs, et cetera?

Technically you could add in classes in the source code of the rich text field, but I don't know of any specific requests for that like as like something like a marketer could add in easily.

I don't think that's likely to be on the immediate roadmap for our group within the page editor. We've sort of tried to move things more over to theme settings and working through sections is like the vehicle for marketer layouts. I would like to know a little bit more about when or why we would expect a marketer to be able to add a CSS class and maybe even contextually for this particular user, what level of experience your clients have with CSS themselves. I think we just want to dig in a little bit more and understand why a marketer should should be doing that's why that desire exists.

Another question to the group why is it that or maybe some context around like how we're thinking about who is using teams can optimize.

Jason, I'm curious if you have any particular thoughts on this. As someone who built the growth theme more geared towards marketer and developer best practices, what's your opinion on where that line should be drawn? And yours too Mitchell, as you are.

First.

Excited to hear your answer first to be honest, I think it's a really hard balance to strike between the developer who's living entirely in code, the marketer and the content creator who's living entirely in non code land. And then we have a lot of customers. There's a ton of people who live in that fuzzy in between land. So my quick response is that we're definitely struggling to figure out that balance and how much code and CSS and those capabilities should we be providing to the marketers? The content Creators, the people. People who. You might not be a web developer by trade, but you can kind of figure your way out through it. So I vacillate all the time between where to draw that line.

With growth theme in particular, it's a little bit tricky because it's like a one to many theme, right? You're developing for a lot of different use cases and a lot of different people with those varying skill levels who could have a developer, maybe not. I think the ideal state with themes is that like as a developer you could set what can be controlled by the content creators and marketers that you're working with. So you'll kind of know what they need to be able to edit. Maybe you can kind of set that. So that's kind of like the ideal experience I would imagine, if you're working as like a one to one theme.

Cool, thanks for that additional context. There are a couple questions here about multi language content specifically. Are there any plans to have multilingual system pages? Maybe a general overview of what the plans are for multilingual content.

Getting put on the spot here today. But that's okay. That's actually a really good question. As we think about the future of content apps here at HubSpot, I would expect the community to see a bigger investment in multi language across the platform. So I know somebody asked about search result pages is something that I would ultimately expect we're going to address. System pages would be something that I expect us to address. Memberships is another area where I would expect us to be making an investment in templating and multi language. And then I believe that email subscription preferences are another area in which we are probably going to have a closer look at how we can support international communities.

Great, thank you. And we have a question for. Excuse me, could we have some more details or ring section?

So is that about like lazy loading images or like full section?

Yeah, I think that's the context.

Okay. Yeah. So that's basically it's a sub field of the image field. So if you're adding an image field like in the Design Manager, that option should be there and you can either enable it or hide it. Like say for example, maybe you want to use an image as a background image and you don't want to include lazy loading. But basically if you were to add an image field in your module in the Design Manager, you can use the copy snippet feature. If you want to see exactly how we're loading in the loading attribute into your image, you can also clone the image module. We're also including lazy loading there if you're interested in checking that out. I know we definitely also have a doc on this as well where it goes through how you can add in lazy loading to your custom module if you have image fields there as well.

Great. How about is it possible to edit the style of every element on different pages in a single go? Kind of. How can folks be more efficient in the edits that they make?

That's where they're really going to want to rely on those theme settings that Jason showcased. That's going to create that global change and ensuring if you want to ensure that consistency with the brand itself, hooking that up into those brand defaults will be an important step there as well.

I have a question on referencing sections. Is it possible to put a copy or to copy a reference to a section to another page, but then also be able to edit the original source?

So I think what they're going for here is one of the marketer save sections. So not only can a developer build and spec out a section, but a marketer can say hey, I really love this section on my page, save it back and then that section can then be reused across different pages within the theme.

Great. What about modules within modules? Is that something possible in the future?

I don't know about modules within modules, but given we've added a bunch of new features to the system of themes lately, including themes themselves, I think it's a good time for us to really sit back and evaluate what is the use of a module now? Now that we have sections, now that we have all these different layers, does that change the, you know, maybe our default library of modules? I know there's another question kind of in there about do like modules? Can sections cancel modules? I don't think that's the case, but I think we need to be really specific about when we're using modules and when we're using sections to ensure the best experience for both you all as developers and ultimately our end users.

Yeah, just to continue that line of thinking, I think that modules in the past I think have historically often fulfilled the role of sections. We see a ton of these giant full width modules with a ton of different fields and capabilities and blah blah blah, because there wasn't that intermediary step. Now that we have sections, I think the push that we like to make is that modules are really your most primitive building block within the HubSpot CMS. If you can abstract down to the most basic thing that you will need in an individual module and then those clusters of modules now can be saved as those full width sections to be reused commonly across pages. So I think the invention and the creation of sections really allows for modules to serve their purpose as that most basic building block, and I would hope that it can alleviate the need for a module within a module. But again, if there are use cases that we're not thinking of, please get in contact with us because we'd be super curious to hear them.

I think. When in doubt, let us know how you these things so understand how to incorporate that into our build. I do see a lot of questions in the chat about images to make and this Are we to images and all the different formats in which they appear.

I take that one. So HubSpot has a lot of optimizations out of the box for images specifically there's responsive images if you have a width or a height attribute applied to your image module. There's also we automatically convert images to webp file types. You might not see that when you're looking at it live, because that's done server side, but there's some information in the Site Speed article in our developer docs that goes through this in a little bit more detail. We've also recently again added that lazy loading feature to allow you to use browser level lazy loading to speed up your image loads if there's an image below the fold. If anyone has any context or things that they're looking for specifically feature wise for Site speed on images, I'd definitely love to hear more. I haven't had a chance to read through the Q and A, so I don't know exactly what people are asking.

So that does our time for this section. Thank you to all of our panelists and our speakers and we'll see you in the next section. Thank you.