Using Components To Build Sites That Content Editors Love

[0:05] Chris (host): Okay, how does that look? Can you see...? That's great. It's great. So, Jason Prothero and Mark Bowser are going to talk about editors and components, one of my favorite topics. So, off we go. I'll throw it over to you. Jason Prothero: All right, great. Thanks, Chris. Welcome, everybody. I'm Jason. Mark Bowser: I'm Mark. Jason Prothero: And we have some opinions about how to build Umbraco websites. So first, just a quick story. So a couple of years ago, we had a new client come to us. They had an existing Umbraco site, and they wanted to upgrade to the latest version. And along the way, they also wanted us to kind of audit things and make sure everything was best practice, which is pretty standard.

[0:51] So we dive in, and things are looking pretty good, and then we come across a page type, or a doctype, called HTML Code. So as you can imagine, this is a large text box in the backoffice that you can paste HTML code into. Oh, and styles and JavaScript too, why not? And it renders that onto the page. So, you know, this is a case where a front-end dev was on staff for a while, and maybe was getting a little frustrated by the editing experience and the flexibility of it, and so they did an end-around and kind of hacked something into place. And it worked great for a while. Unfortunately, that person was no longer there. So from a business perspective, this was a pretty big risk, because nobody knew how to edit those pages. And the complexity to actually edit them was that you had to be a developer, and not really a content editor, at that point. So that sort of thing is a telltale sign of content editor frustration, where somebody can't quite figure out what to do. They want to change some things, and so they hack around it.

[1:59] And our goal is happy editors. So, you know, there are a lot of goals when new website projects get started. There are marketing goals, there are lead generation goals, there are content messaging goals. There are probably some accessibility goals, SEO, performance, all these things, and we think about them a lot. But we typically leave this editor experience towards the end, and it's up to the implementers to do their best. And that varies, but the editors kind of get a little bit screwed on this as it goes down. And so we just want to put that at the forefront. Some of the things that we've heard from editors and people, on sites we've built in the past or sites we've seen other groups build, are: I can't change my content. Or, I'd like to refresh my design; how can I do that with my current setup? Or, hey, we couldn't figure out how to change anything, so we just did a bunch of things in the RTEs; hopefully that's okay. So there are some things here, and even the grid can be overwhelming if it's not set up in a way that really takes usability into mind.

[3:13] So for us, the past few years, our solution has been components. So we call this component-based architecture. From an Umbraco point of view, in v7 this would be using a package such as Stacked Content, or maybe even the Doc Type Grid Editor with the grid. But in v8 there's a native experience called the Block List Editor. That's what we're going to be focused on today. There are a lot of other block editors, and there was actually another talk earlier today that you can check out for some of the other options. But we're going to be focused on the block editor today. So component-based architecture is kind of in opposition to maybe a traditional content modeling approach, where in the discovery phase you really detail out what page types are going to be on the site, and really get structured information. You build the templates, and you kind of have this form-filling experience, where you have fields and pickers, and they kind of show up on the template where they show up.

[4:22] So components are more like pieces, or blocks, of content. They can be stacked on each other or arranged to build the page. So here's an example of our ProWorks site, just as an example of a component-based architecture, where you can kind of see how these relate. On the front end, you have the hero that has a few pieces of data. You have this card navigation that allows for the jump nav down the page; that's got some data in it. Then there are a few image with text blocks. And we're going to talk a little bit about how you can vary these, and Mark's going to do some demoing here in a second, but this just gives you a general idea. You can move these around, sort them, you could remove one, add a new one in between. There's generally a library of these, so you could add a quote, or a product spotlight, or a slider or something, because you have a campaign coming up, right? So these are pretty straightforward, and you can basically give a lot of flexibility to the content editors.

[5:23] All right, quickly running through why we should care about this. So for us, we feel like it's a really good meeting place in the middle. Content editors and marketers get the flexibility and the control they need to refresh their designs frequently, and to create new pages that maybe we hadn't even thought about in the initial discovery process, while as implementers we still get control over the design, and we can enforce the style guide. In addition, these days a lot of requirements are put on to us as implementers, things like accessibility, SEO and performance requirements, and those are difficult to meet when it's just an HTML code block that anybody could put anything into, right? So this kind of gives the best of both worlds, from the business perspective, the content editor's perspective and the implementer's perspective. And adding new components is generally pretty straightforward, because rather than having to change a bunch of pages and templates, it's just adding a new component on the front end, actually.

[6:33] So we try to leverage this throughout the whole life cycle of a project. From a discovery standpoint, the original page-modeling type of approach was very structured. It was really difficult for marketers, and ultimately content editors, to understand why we were doing that up front so much. This component-based way of doing discovery makes things a lot easier. It's sort of like: here are some Lego blocks that you can build your site with. Is anything missing? Here are some other ideas, maybe based on your needs and what you're measuring, that might also work. What do you think? And thinking in terms of, okay, here are some things I could put on a page to make my page, makes a lot of sense to people. It just makes that discovery process go a lot easier, and they know what they're going to get, and they're really engaged up front.

[7:19] In addition, this actually turns out to work really well with a headless setup. A lot of JavaScript libraries are really component-driven by default, so it kind of just seamlessly works with a headless front end. And it gives you a lot more interesting A/B testing options, because you can really change a whole section of the page, or remove something, and see: is this page being shorter, does that convert better, or longer? Things like that. Okay, so now I'm going to hand it over to Mark, and he's going to do some demos and walk through how we can take the sort of vanilla, out-of-the-box block editor experience, which is good, but maybe make it a little more usable, and just help our content editors out a bit more, so we can have happy editors.

[8:16] Mark Bowser: Hey, everybody. I'm going to try to yank the screen. Yeah, take it. Here we go. All right, can you see it? You see slides? All right, cool. So I wanted to reiterate Jason's goal that he stated earlier: we want happy content editors. And some of the challenges to that are more obvious when you talk about people building entire pages inside of a rich text editor, but the same sort of problems can exist inside of a component-based architecture. So I'm going to demo the block editor. I'll start with a vanilla setup and show you how to actually set these up, and then I'll start moving into some of the obstacles content editors can start running into, and how you can overcome those.

[9:09] So this right here is pretty much a vanilla block editor. It comes with copy and paste, you can insert between rows, which is nice, and you can sort, remove and add. And to create each of these individual blocks, all you have to do is create a document type. We keep all of ours in a folder. The doctype has to be an element type, and you have to create a partial view to render the data in it, and then you can slap it onto one of these block list editors, and that's pretty much it. It works. One of the first things, one of the most obvious, easy-to-fix things, is that if this starts to get really long, right now there's no information about what's inside each of these blocks. So if you write this page and come back a month later and want to edit it, or somebody else who's not very familiar with the page needs to find a section and edit it, it can become a challenge to basically start opening each one of them, and that's just frustrating.

[10:11] So the block editor comes with the ability to add custom labels. You need to write little Angular expressions, so I'll show you that here. You can basically start plucking properties off the actual content within the block. So here we're trying to grab a component title off the settings, and if that doesn't work, we try to grab the section title; otherwise we have a fallback text. You can see in our block, here's our section title, and here's our component title, so it tries to grab those. So here's an example of when we set up all of our labels. So this is moving in the direction of usefulness.

[11:05] What we have lost, though, is context about what type of blocks these are, because now all you have is the icon. And the solution there is that you can make custom views to actually render out each of these block elements, and it's actually not super complicated. Let me see if I can pull this over here. Yes. All right, so we wrote a single view here. You don't need to write any JavaScript; there's no actual controller on this. And again, just like the Angular label, you can start plucking properties off your block, or the block settings, and render out your own view. And this single view that I'm going to show you, you can apply it to all of the blocks. You can add style sheets too.

[12:03] So on each individual block, you can select the new view that you'd like to use. If you do add a style sheet, what's really nice is the styles are all isolated inside a shadow DOM, so you don't have to worry about breaking anything else in the backoffice. So I'm not actually going to save it, because we have an example. This is a really common view we like to use, because you get information about the type of the block, you get some context about what's inside of it, and we like the size of it, because it helps represent that it's like a component on the page. But you could do something more interesting, where you write a custom view for each individual type of block, and you start giving a lot more information about what's inside it, or maybe even what it's going to look like on the front end. And there's a great 24 Days in Umbraco post where they actually render out entirely what's on the front end. Because the CSS is inside a shadow DOM, you could go that far, to actually show a real preview. You want to make sure that you don't make this super long, so we do kind of like these more simple approaches a lot of the time. But those are really great tools that you have in your tool belt.

[13:19] The next area that I want to show you is the actual block catalog here. When you're looking at it for the first time, there are a lot of blocks in here, and you really want to be thinking about how many blocks you're adding to this list, and we'll get to that later. But, like, what is Tabs? What does Tabs do? What does Callout Section look like? If you have a vision for your page, which one of these blocks is the one you actually want to choose? And what I think happens, in my experience, is that if these aren't really clear, the content editor finds three or four that they know how to use, and they just sort of ignore the rest of them. So the two things you can do to make these blocks in the catalog a lot simpler is you can add descriptions, and you can add thumbnails to them. The descriptions are actually just pulled directly from the document types, so if you're adding document type descriptions, they'll just show up there.

[14:35] So now we're getting some context: oh, this is tabbed rich text editor content, I see. Or, these are circular icon links with headings and subheadings. Okay. And you can start to imagine it. But you can go a step better, and for each block you can add a thumbnail. So we keep all of ours in here, and that looks like this. So here we put thumbnails on a lot of them. And there are a couple of different directions you can go. You can try to do something more impressionistic, where you're like, I see I'm going to get columns of things, or, oh, I see the tabs are going to look kind of like that. Or you can actually take snapshots of the front end and thumbnail them in here. Or you can mix and match them. So that's pretty much what I have for the UI improvements.

[15:39] There's probably something that's equally important here, and it's more sneaky. This is something that it's easy not to think about, and then over time it creeps up on you, and there becomes some frustration. So this is a simple image text block on our front end. There's a background image, there's a foreground image, there's content, and there's a call-to-action button. And this is something that the content editors are probably going to want to use all over the place, all the time. And they're probably going to want a version where the image is on the right and the text is on the left. And then pretty soon there's a version where they decide not to have the foreground image, and they want the text inside a panel. Or maybe they want the image to be there, and they want to be able to move the text around. And then there's whatever you'd call this, where there's an image and we've done some funny styling on the text. So you can start getting tons of variations of the same sort of idea. And there are a few different ways that we've tried to solve this problem.

[16:41] We've tried to create separate blocks for each different type. So here we have our image left, text right; image right, text left; image with a text pane. And this can start to balloon out pretty quick. And one of the confusing things is that a lot of them can be really subtly different. So this is something that we generally don't recommend doing. The other way you can go is to try to make a lot of settings and toggle switches, so that content editors, when they're making these, can actually craft them the way they want them to be. They could put a pane on this right here just by checking a pane box. So let me show you that really quick. Here's an example of some settings we put on this block. There's image orientation and there's text orientation, there's applying a text pane, there are maybe some funny styling options here, and then maybe they want to start controlling padding and margin.

[17:44] I want to point out these two fields. There can start being interesting edge cases here: what if they choose left for both of them? They might need to be able to choose left for text if they don't have an image. But this can also start ballooning out and becoming difficult for development, because you have to consider all the cases that the content editor might choose, and it's hard to test every combination and permutation of all of these. So what we've been going with recently, that we really love, is using themes. So over here you can see my awesome amateur photo editing skills at work. I'm a back-end developer.

[18:31] We've created a glorified radio button that we built using Lee Kelleher's Contentment package. And we've done away with as many of the settings as we can. Instead, we give them a selection of different themes to choose from. And this is really important, because if you go the settings route and not the themes route, we're turning this simple... let me pull this back up here... this pretty simple idea of an image text row is no longer simple, because every time the content editor wants to add one of these, they have to put on their designer hat and actually consider all of these options. And sometimes the content editors need this control, and it's important. But what we've also found is, if they have to put on their designer hat every time they want to develop these, then they start to just get exhausted by it, because they can't just focus on the content. So we have more and more requests to try to figure out how to reuse these components in different ways, so we're really excited about this theme idea. That's all I have for new functionality.

[19:49] The last thing that I want to talk about is making sure to train the content editors on things like the clipboard, which are easy to miss. It's built in. You don't have to do anything; you just get this for free when you use the block editor. But if content editors don't know about it, they'll spend a lot of time duplicating content. So you can basically clipboard any of these individual blocks, and even go to a different document type that allows that same block, and when you add, instead of creating an empty block, in your clipboard you have your whole array of blocks. And you can even clipboard the entire section of blocks here, which is amazing, and you get that for free.

[20:39] There's one final tool. So let's imagine that you had a product section, and we're selling board games here, and we're also selling board game components. And for all the board games, we have a similar structure that we're trying to use. We start out with a home hero, then we have some nav, then we have the description, and every product is going to sort of follow that same layout. And maybe the components need a different structure, and they basically lead with the specs and just information, because they're not shiny. Umbraco comes with a tool called content templates, and you can use these to basically scaffold out different types of pages. So a content editor can right-click and create a... they're cool... there it is... they're awesome... content template.

[21:32] And when they create new content, they can decide, instead of starting from scratch, they can start with a scaffold here, and that's neat. You can have a different scaffold for the components, a different one for the products, so you're not starting from a blank page every time, or looking back and forth between different tabs trying to make them look the same. And one of the things I've been thinking about more, and I haven't actually released this with any clients, is trying to really feature this content template section. This exists by default in the Settings section of Umbraco, and we oftentimes restrict content editors from the Settings section, because that's not where you write content. That's where developers are crafting and architecting, and we want to make sure that stuff ends up in source control.

[22:25] So I've moved the content templates out here, so they can have access to it, and they can actually edit the scaffolds they make. So they snapshot real content, but maybe they want to fill it with lorem ipsum text, so they don't accidentally release the wrong content. And that's actually pretty easy to do too. This is a really rough version; I did this in about an hour, to see if it would work in v8. But I just created a controller that implemented the ContentBlueprintTreeController, and put it on the Content section of the site. So if you look here, this is actually duplicated: this content template is here in Settings and in Content. But I think this is a good idea.

[23:12] So pretty much, in summary: you should spend the extra work making the block editors look nice, because it's going to make the content editors enjoy it more. If you only have six or seven blocks, it's fine; the content editor is going to figure this out. But as things expand, it's important to make sure that they're actually able to use all the tools, otherwise the tools might as well not exist. And then themes: think about themes when clients or content editors start asking for variations on existing components. All right, Jason, I'm going to hand it back.

[23:59] Jason Prothero: Okay. We've got about five minutes left. All righty, we're just about done. Thank you, Mark, that was awesome. So, basically, to wrap up here: we've had really good luck with this with our clients. We've had some really happy people who are like, I can finally edit my site the way I want to. Or, I can't believe this control. They're creating things that we were surprised by, and we're like, yeah, go, you guys rock. So one of the things too, just real quick, that we've kind of been developing here, and it's not perfect, but it does also help with the process, is to build out a component library. And this doesn't have to be super code-y. It's actually more interesting for us not in code, because we can have user stories, completion criteria, examples, and screenshots of where we've used this particular component. And so it really helps communicate during that discovery process, or when there are needs for things, like, oh, it sounds like you're looking for something like this. It really helps fast-track that discovery process, so we don't have to redo so much work all the time.

[25:11] And also, there's a blog post on our website right now, at proworks.com/blog, about what we're talking about here, and on that blog post we're going to be adding some of the specific technical things around this that Mark demoed, so you can copy, paste and steal whatever you want from what we've been doing. So look for that. And that's pretty much it. So we're ProWorks. We're an Umbraco Gold Partner. We've been doing this a really long time, and we just enjoy helping people love their CMS and be happy with it, basically. So, yeah, thanks, everybody. I don't know if there are any questions, if we have any time. Looks like there are a lot of questions going back and forth in the chat, which is nice. Mark, anything you want to comment on from some of the questions you've been answering?

[26:07] Mark Bowser: Yeah, this Contentment package by Lee Kelleher is great. It's what I used to make the theme picker. It's kind of like nuPickers, if you used nuPickers in v7. Contentment actually comes with more than just that picker; it comes with a whole tool set. But you can basically make yourself a radio button or a checkbox, and make custom data sources that drive it. uSkinned does some very similar things to that theme picker there. Jason, is that where we got the inspiration for the theme picker? Jason Prothero: Actually, no, surprisingly it isn't. But we have used uSkinned, and it takes this component-based architecture approach, absolutely. So, yeah, it's definitely one to take a look at. They have some neat stuff going on there, and they're now using the block editor by default. We've used it for smaller sites and things like that, where we just want to get something going quick. So it's awesome. Mark Bowser: Yeah. Jason, can you send the screen back over to me? Because we have extra time, I'm going to show some of the actual doctype structure I used.

[27:24] Okay, so I wouldn't say that anything in here is completely done yet, but we do have some document type inheritance going on with our blocks. We have some settings that we want to apply to all the blocks, like additional CSS classes, if the content editor needs to do anything really special, or IDs that we can use for jump links and things like that. So we apply this composition to all of our blocks. And there's also this idea here that I've since taken off the actual composition we put on the block, and I've built block settings. So there's a separate document type used for the block settings.

[28:14] And that's because on each of these blocks you get the choice: you have the document type used for all the content, and you saw that settings tab. All the things on the settings tab here come from that separate document type, and the block editor stores the two separately. So Umbraco's been trying to present this new data structure for these block-editor-style components. And the idea is, if everybody starts using the same data structure, then you could switch away from the block editor to some different custom editor somebody invented. And they're separating the actual content from the settings, in case that's important. So you could theoretically switch between a block editor like this and maybe the Umbraco grid, if you can keep these separate in the right way. So that's a little bit deeper, but those are some cool things the block editor does.

[29:20] Chris (host): All right, any other questions? It seems like we have a lot of really good conversation going on on this one, which is fantastic. Feel free to keep that going. We only have a minute left in this session. If you'd like something to get answered live in the last 63 seconds, shoot it our way; otherwise, let's just keep it going via the chat. Mark, Jason, thank you so much for a great presentation. Really enjoyed that. And we'll see everybody a little bit later, after more trivia and more cameo appearances. I'm sure those are great. Jason Prothero: All right, thanks, everybody. Mark Bowser: Thanks, everybody. Thanks.