Get Off the Island: What We Can Learn From Other CMS's

SUZANNE :
Alright, everyone can see the actual slides, right? OK, perfect. So, I'm excited to be here today to chat about what we can learn from other content management systems and other content management tools. I know myself, I've been working in Drupal for a very long time, and sometimes we put the blinkers on and kind of forget to look around. And so, this is just kind of a show and tell of ideas that I've gathered, and I hope this will be interesting for everyone. And I'm also really excited to hear other ideas. So, I will leave lots of time for questions, I hope. Just to introduce myself, my name is Suzanne Dergacheva. I'm one of the co-founders of Evolving Web, we're a triple agency up in Montreal. And I also run a training program as part of that. So, that's something I always want to share, is that there's triple training available and we're doing lots of online training these days. I'm also the lead of the Promote Drupal Initiative. So, if you have ideas about marketing Drupal and kind of relevant to today 'cause we're talking about Drupal and all these other content management options that folks have.

Anyway, if you have ideas about that, I would also love to chat with you about promoting Drupal and just marketing around their Drupal project. So, I already shared this... So, let's jump right in. So, I know many of you today here, probably all of you have some role related to building websites, right? That's what we do. We build websites, maybe we build apps, (CHUCKLES) but we're creating, interfaces that we put in front of people. And so, I think that usually when we think of our job, we think about the interfaces we're providing for the end-users, like, OK. Where we're building something that's designed, that is branded, that looks like this, and we show off in our portfolios, where we show off the screenshots of the front end of the side and all the beautiful things we're creating. And of course, that is what we're doing. But actually sometimes and more and more on projects, I find that when I think about what is actually needed, what we should be building as a platform. What we should be building are like the tools for the content editors, and they're kind of the ones creating these beautiful interfaces on the front end.

And of course, we have to plan all of that out and give content editors the right tools for the job. And so, maybe this is a controversial statement, but maybe, maybe, just maybe content editors are actually our most important users. Part of my job at Evolving Web is that I run workshops at the beginning of a project where we sit down and talk about why are we doing this project, and who are the users involved like who are rebuilding this for? And more and more these days, I'm hearing an answer to that question being, yes, our end users are important, but also our content editors are really important and they are one of our audiences. And for this project to be successful, we have to think about what they need. So, that's something I think we should think about and plant that seed in our minds and yeah, the content editors are the ones who are creating this end-user experience. And a lot of the times the tools that we give, the content editors are actually it's actually going to influence what comes out at the end.

It's going to have an impact on the choices that we make about the tools that we give in the back end, are going to influence the front end. And sometimes, you look at a design and you think, well I could build this five different ways, and how do we pick which way? Well, maybe the first thing we should think about is what's gonna be the way that's going to make the content editor successful. So, with that said, I and I think if you're going to take like if you've looked away from your screen 'cause I know you're viewing this online, maybe you've gone over to another tab in your browser. Come back for a second, this is the slide I think I put the most effort into. So, take a screenshot of this one. This is what I've sort of thought of as the needs of content editors. So, not so much like an overview of every single feature we need to give on the back end, but rather, what do they actually need to be successful? So, I think that the first level of success is just from content editors feeling comfortable.

So, you're not going to have a successful project if content editors kind of avoid logging in to the backend to actually make updates and find content. So, if they're not able to kind of pass through that first level of ease of use, then it's not going to be successful. That's kind of the first thing, now on top of that, they have to be able to find what they're looking for like actually find the content that they want to edit. Which sometimes is easier said than done, right? We all know that websites are complicated, it's not just a simple set of pages, there's often a lot of moving pieces. So, just having a way for them to find what they're looking for and then go about their job of making updates, adding content, previewing, figuring out the approval workflow, which can sometimes be complicated, and then tracking their changes or making revisions and translating. So, that kind of workflow stuff is the next level. And there may be lots of workflow features or it might be a very simple workflow, and that in any case, that has to be something that they can navigate and figure out.

And the biggest thing, I think, with publishing workflow in terms of usability is predictability. So, do I know what's going to happen next in the step when I click this button -publish, is it actually published? And the thing with this is that you're building trust with your users. So, if they get what they expect, then they're going to trust that the platform is working and they're going to use it more, and they're going to find it just more that they're going to use more of the tools available. I think that the third level, and arguably this is a really important, maybe this should have been then the second, but content compliance. So, content compliance these days is more and more important. And I think a lot of content editors are really aware of this. They've heard that, yes, the content I produce has to be accessible. And I don't want people finding broken links. And we need to follow these guidelines like now I have this style guide that I'm supposed to follow. Now that all being said, the platform that you provide can make it easier or harder for them to reach that compliance.

So, how do we make that easier and how do we build it in? Because, it's often content editors, content editing is one part of a big job that they have maybe like 10% of what they do in many cases. And so, for them to switch context to content editing and then to switch context to, oh, yeah, I have to look up these guidelines that somebody sent me. That can be just something that they skip as a step, even if they know it's important. And then finally flexibility. And so, this is something that is more and more of an expectation and I think goes hand in hand with compliance because content editors want to have a real platform that they can use as a tool. Often they have a marketing role or they're working with marketing folks. And so, they need some level of flexibility to do what they need to do. And if they want something to look a certain way, maybe they're gonna use the WYSIWYG editor, or they're going to use some more standardized page-building tools that we're providing. They'll do it however they can.

So, content editors are good at finding workarounds. So, think about that when you're setting up the toolset and think about what your goals are in terms of what you want things to look like. Some flexibility is certainly needed these days to keep content editors happy and also successful, right. So, I had this experience not too long ago running a usability study of different content management platforms, and my colleague (INAUDIBLE) and I looked at Craft's CMS, we looked at Contentful, we looked at WordPress and we looked at Squarespace, and we were really on the search for good ideas. And so, there's a link here and I'll share the slides. There's some research that we actually did, but today I really want to share like good things. So, I'm not comparing platforms and saying this one is better than that one. And WordPress and Gutenberg, blah, blah, blah. Now, I'm just gonna share what I think are good practices, and then also some takeaways and some modules that we can use in Drupal to improve on maybe what we're doing already.

And also I share some good examples from Drupal. So, putting users at ease, that's sort of the first step that I think we need to make sure of. And in a way, this is the easiest thing to do, but it's also the thing that we might not do as much. One thing that I'm excited about that is new in Drupal is the Claro theme. I'm not sure how many of you are using it yet, but it is the admin theme, that is new, relatively new in Drupal. And what I find is that Claro gives a lot of room to breathe. So, this theme does not change a lot of the user experience patterns that you'll find, it is more accessible than the Seven theme, the previous admin theme. But mostly I just find that it puts people at ease, because it gives a bit more space to everything and it is a bit more modern. And that that reassures content editors because it's a cue that, yes, this is a platform, it's up to date, it's got the latest features, it's not ten years old. And somehow that reassures and quite visibly so, I find in the reaction of content editors.

Another thing I think we can do to put users at ease is to speak their language. So, when we do user experience, work on the front end for our end-users, we always think about what words they're familiar with, what's really going to speak to them. We do this kind of content strategy work and on the back end, of course, the reason we're using a content management system is that we already have all of that built-in. We already have the backend interface created. That's the whole point. But that being said, there are some choices that we make in Drupal when we're configuring things, right. That determine what language appears on the page, just like what are our content types called? And I find a lot of people have this notion that, yeah, WordPress is really easy to use. And I always wondered why, because, I don't think fundamentally it is necessarily easier to use than other platforms. And I was thinking about this recently and just looking at their dashboard, I was thinking that maybe it's because the language of WordPress really speaks to the content editor, really speaks to the person who's creating blog posts.

And I think that comes out of WordPress, a blogging platform. But really, the language here is more speaking to that audience and just little things like the fact all the content tools on the left are kind of promoted above the other menu items. But the language of this little dashboard here, all the calls to action kind of appeal, there is some quick tools or you can go in and start creating content right from that first page. And I think that that makes content editors feel like this is the tool for them. Then kind of that next level publishing work workflows, actually being to find and author and approve content, preview content, all of those tools. I think that this is a big area for little improvements and the real leg up that Drupal has here is that Drupal is so flexible that we can build those workflows around the actual needs of the site. And I find that workflow needs really change drastically from site to site. So, that's fantastic that we have that control. But sometimes we don't really put a lot of time into thinking about this.

So, here's just some ideas from some other platforms about what makes a good UI in terms of workflow. So, that first thing that I mentioned was just being able to find the content that you want to edit. This is an example from Contentful. Now, Contentful, I find this a really interesting case because if you don't know Contentful, Contentful is a platform that is meant to be decoupled. So, it's like, you can use Drupal decoupled, you can use the JSON:API and feed data from Drupal to decoupled front end. But with Contentful that's kind of how every site is working. So, you're always going to build a separate front end using some kind of framework like, JS or whatever. So, Contentful has... That means that the interface of content is entirely built for the person going in and structuring and adding content. Now it does have some more technical terminology, like content model, it's kind of showing you the structure of your data and the database. But a lot of the features really work well for content editors.

And I find that the search interface, in particular, is really advanced, like there's a really nice set of filters. It doesn't look really intimidating. There's just a lot of search filters built into the main search bar. So, you can kind of pick which filters you want to apply to your search. Another really important aspect of workflows, like I said, predictability. If somebody knows what's happening next in the workflow, they're going to feel way more at ease and they're going to feel like it's more friendly. And a big part of that is our previews. So, I just wanted to show a couple of examples built into WordPress, there's kind of a nice preview interface. Which is relatively simple, which I think users appreciate. And in fact, in Drupal one little module that I recently discovered that I think can help us achieve this is the responsive preview module. And I discovered this because I was experimenting with different distributions for Drupal, and I found it as part of the thunder distribution.

So, which is a great source of inspiration just for building a nice, flexible content editing interface. So, that's something that's easy to add in and really gives us something quite similar, of course, a little bit more flexible. Other preview ideas, this actually, I think was my favorite feature that came from Craft CMS. And Craft CMS comes as you start to publish, if you start to draft content, you actually see a preview of the content which you can make available on the right side of the page. So, it's not an in-line editor, as in like you're actually like the text-field doesn't turn into a text area, but rather you have the interface on the left where you are editing that content and then you see immediately on the right what it looks like. And this kind of preview, I think, strikes a nice balance between an in-place editor and something that provides a little bit more control in terms of the settings for each field. Because sometimes in-place editor hides a lot of settings. In terms of Contentful, because it's such a decoupled-oriented platform, there is no real preview built-in because you don't have a frontend by default.

But you can very easily configure whatever front end you have to link up to those previews. So, it's very simple to set what preview you want. And I know, if you're using Drupal with a tool like Gatsby, there are these this preview functionality exists. So, you can also hook that up in Drupal context. Something that goes alongside this just kind of in the same part of the Contentful interface is the ability to or not the ability, but the built-in feature that you are always autosaving your content. So, you go to change your content and you see that, oh, it was actually already saved. And I think that this is a great feature, I think content editors always ask about this if it doesn't exist, again, predictability, people are anxious. They're worried about losing their content. And so many applications that we're used to using these days, just autosave. So, it's something that we almost come to expect. Now, that being said, if you have autosave, you are going to have a lot of little revisions of content and you might forget to publish.

So, there's this big publish button here and then I see draft. So, it is a draft, but I have to click publish still to make my autosave changes live. And I find that this dance is like, what is draft? What is published? I don't honestly think that any of these platforms have completely figured this out yet. Added to that complexity and the complexity of the kind of workflow state challenge, is the fact that once you start to have more complicated content and content components that you're using to assemble a page. You end up with different versions of different elements on the page. So, maybe you've created a new hero component and that is still a draft, whereas the rest of your page is all fully published. And so, that that kind of dance can be add to the complexity, Contentful does a good job of highlighting that and really making that clear in their UI. And I think part of the reason that it's so clear is that it doesn't try to do the preview as part of the editing interface. So, it's focused more in the editing interface on the state of your content, and that allows it to focus your attention.

Now, how does WordPress handle this? So, WordPress does have some revisions, functionality. It's keeping a revision, for example, every time you autosave or it autosaves the content for you. And so, again, that kind of leads to a lot of autosave revisions. And one interesting feature that it has, which is not well labeled here, but you can see at the top of this page, just above the revision tracking. It has a little slider. So, you can go back in time by sliding that back and kind of seeing how the content changed over time. Now, all this being said, we can kind of see what the preview is showing us, which is that there is a lot of kind of WordPress markup added. The content that's created on this page is placed using a visual edit there, but it results in some HTML, which is how the content is stored. So, like striking that balance is tricky. And again, I don't think that this is something that any of the platforms has really figured out how to manage a visual depth of layout changes on the page.

One other interesting thing, I think one of the reasons that I used Drupal and why I have used it for so long is that it has such great built-in multilingual support. And the translation UI built into Drupal is robust. You can go and translate your content into ten languages or whatever you need. But that being said, adding a translation workflow adds a whole other workflow, basically on top of the regular content editing workflow. And so, one workaround that I found being used in Canada, we have a lot of English and French websites, is to have this side by side translation feature. So, you can actually add your translation in place kind of at the same time as you're adding the fields in English, for example. And so, this does work really well for adding two versions of the content to the content in two languages at the same time. But because Drupal has so much metadata around content, it adds a lot of complexity to everything else. So, the whole rest of the content editor interface kind of has to be changed and oriented around the fact that you're editing two languages via the same page.

So, it's a great idea and it's still like this module is used. But I think that there's a lot of room for improvement of this kind of interface. So, just some suggested modules here for related to workflows, of course, the death module. I think most people know about that to show the difference between revisions, response and preview I mentioned. Autosave form, does implement an autosave feature would be amazing, I think of that feature got into core. The scheduler module is much used and then translate side by side. I would say that would be a caveat. I would like fully suggest using this, but it's worth checking out if you have a lot of bilingual content. So, the third category I mentioned is content compliance and so, content compliance, I think that Drupal just does a great job. Because Drupal does structured content like that's kind of its bread and butter. And so, we have already structured content with our content types. And then if you're adding block types or paragraph types or media types, whatever you're adding, Drupal really encourages this having really well-defined fields for our content.

And makes it really easy for us as site builders or developers to create that. But I think that there's more to content compliance than just having nice fields. So, I'll just mention a couple of things on this front. So, editing the source markup, this is a screenshot from Contentful. Now, I know that there's always this conversation that happens even now whenever there's training for content editors about the WYSIWIG editor. So, people love the WYSIWIG editor, people hate the WYSIWIG editor. It's nice than Drupal that it's so flexible. But it also introduces, of course, lots of problems because as soon as you have a WYSIWIG editor available, you can create content that is not compliant, are not consistent. Maybe not compliant with accessibility standards, or maybe not compliant with brand guidelines and things like that. So, how much flexibility do you really want to provide? And then how much are you opening yourself up to problems, in terms of the content output? So, Contentful being the platform that it is, kind of again focused on creating this decoupled architecture.

It has the editing interface that it provides, it provides a markup, or sorry, a markdown format. So, you're actually editing markup rather than going in and necessarily editing using a WYSIWIG editor. So, you do have that preview mode that you can go into, but it shows you the markup and it makes that really available to editors. So, it kind of encourages the learning of, what is markdown and how should I format my content. So, that's just an idea. I think more and more when I build platforms, I try to focus on like what can we structure in the content? How can we reduce the amount of free form WYSIWIG style content anyway? But if we do give that to users, what tools are we actually giving them, and are we encouraging compliant content? Of course, there are modules you can add and add ons you can put in place for kind of accessibility and compliance checking. So, Site improve is an amazing tool, it's a paid tool. So, it's not like it comes with Drupal or it's open-source, but it's something that really brings a lot of value to that content editing process.

And another just area that I think is really interesting that I see more and more is that when we do create content components like paragraph types or block types, it's really nice if we can build in more flexibility into them. Even while we have highly structured components that we're allowing users to put on a page. So, this is just a quick example, but this is an interface for creating a block that you can place on the page. And it has a layout setting which is not selected right now. But basically, you can pick how that block is actually going to appear. Is it going to be left-aligned or right-aligned? Maybe there is a setting you could add for like the color palette. So, there's tools you can give to add in flexibility, while still allowing the editor to create something that's compliant. So, when you think about compliance, I think there's kind of two categories of work you can do. There's things you can do just to help users, to help content editors check that they're creating something that's compliant.

Or you can give them also the tools to create something that's more structured. And in general, anything that's structured is going to be more consistent and more compliant than something that's not. Another kind of category are tools to help editors actually maintain their site, like things like the redirect module that allows you to fix maybe a broken link or a missing page, right. It's going to really help editors if they have access to that kind of tool. Oh, and in general, I find that content compliance is not something that is really a focus of many content management platforms. If you have ideas or examples of ways that, CMS are doing this right, I would love to hear because I find it's not something that we see explicitly kind of in the interface of many of these tools. So, then I'll talk just a little bit about the last one, which is flexibility. And I think that there's already a ton of information out there about different options for making Drupal more flexible. But I wanted to show bring in some examples from elsewhere.

And so, the first example that I'll show is Contentful, and it's less visual than the other ones because it is inherently a platform that's for kind of creating your content, not editing it in place because the interface is separate. But it does give you that flexibility and kind of resembles a bit paragraphs, which I think many of us are familiar with in the Drupal world. So, the interface model here is kind of interesting because as you're building a piece of content and you go and you assemble components within it, you flip back and forth between different forms. So, Contentful doesn't try to provide you with a single form that's going to give you access to add everything. You kind of are digging into a more detailed interface that gives you access to added a component within the bigger piece. So, we started off editing the page, then we went in to edit a hero component of that page, then we went in to edit the image that would be part of that hero component. And now here we are, we are going back up the chain and back to the beginning.

So, we can kind of see in this interface that you're able to have quite a bit of flexibility. And as you go as the content editor, you really see the structure of what you're creating. Now, I found that this interface does it does take some getting used to when you are not familiar with the back arrow kind of concept. And the fact that it is auto-saving is maybe also a little bit of a change because it's not giving you that link to save and then send you back. But it doesn't take long to learn and it's quite fast. So, I think often content editors get frustrated with an interface that just takes a long time to load, this one does not. OK. Let's get to the next one. OK. Next one is WordPress. So, this is just the built-in Gutenberg interface. This is what's going to allow you to add an image to the page. So, it kind of has this add button that gives you access to all the different blocks. So, in WordPress, they're called blocks, just like in Drupal. And you can use those to assemble the page, and depending on what you pick, you have these different fields available.

And what I find interesting about this interface is that I think people like it because it really focuses on the visual content that you're gonna see. It does take a bit of the emphasis. Well, it does take the emphasis off any of the metadata around the content, and you really don't see the structure. So, you don't see that there is now a component within a page, and within that, there's an image like that. All is hidden from you for better or worse. So, encourages you to create lots of things and tell your story, I think that's really the purpose of this interface, but it does have some drawbacks. Next one I wanted to show you is actually probably a tool that is growing in popularity in the WordPress community. It's called Elementor. So, it's like a very similar interface, and we can see that it has a lot of the same... I mean, it has the ability to do just the same thing to insert this component into the page. But it has less in terms of... Sorry, it's not built into WordPress. So, it's a little bit less integrated with all of the other tools.

And then it has a lot more features in terms of how customizable each element is. So, it's something to dig into more if you're interested in this space. And then finally, I mean, I know, probably most of you have seen this already, but at this point, in Drupal, how do we create a flexible interface, like this where we can use the layout builder? And I think what's interesting is that there are more and more ways that we can really build a good user experience with the layout builder. We can use layout builder restrictions to filter down the number of options that you see when you go to add content to your layout. So, instead of showing everything under the sun, we just show, OK, here are the custom type of blocks that we want to encourage users to actually create. And yeah, there's a lot to this interface. And I think the real advantage in terms of flexibility is that the content is structured, first of all, but that those components that you're creating are actually structured content like Drupal blocks.

And then the other advantage is that you can also intermingle them with all of this other rich content that's coming out of Drupal. And combining this with the ability to place content that is more structured, like a featured event or a featured article into the layout using these tools I think is really valuable. And something that makes content editors really excited. So, flexibility is great just in terms of, oh, I want the page to look how I want and I want to have some control over the layout. But flexibility also means being able to kind of assemble these pages out of existing building blocks. And that, I think, is something that Drupal does extremely well. So, I want to open it up for questions and ideas I want I'm hoping other people have things to share. So, I will just take a look at the chat, I guess.

SPEAKER 1:
There a lot of good ones, I think the first question asked was about accessibility tools you mentioned CKEditor accessibility, and the Site improve was a paid service?

SUZANNE :
Yeah. So, yeah, accessibility is such a hard one. I mean, I think if best case scenario, if you just turned off all your WYSIWIG editors and said, OK, every piece of content that we're entering in is just plain text. Then you could really achieve, full content accessibility. (LAUGHS) Without that, it is hard because the editors always give an option to create add headings that aren't ordered correctly, for example, or just creating some markup that shouldn't be there, doesn't have the right parameters. So, you do have to do some training whenever you're giving a WYSIWIG editor at the moment, I don't know of any WYSIWIG configuration that you can set up, that will only create compliant markup. That being said, with Drupal for example, if you're looking for a technique to make your content editors more successful. You can limit the number of options in the WYSIWIG editor. And you can add different configuration to the text formats. So that as those formats are displayed on the page, that things are filtered out that shouldn't be there.

That being said, if you have legacy content, this is the biggest challenge. Because if you already have thousands of pages of content and they already use full HTML markup, it's really hard to move away from that. But if you're looking for a way like in the long term and improve your accessibility that's probably the best place to look is like, how can look, clean up existing markup and just streamline it, make it a bit less flexible going forward. Any other question?

SPEAKER 1:
We just have a few minutes, but that most recent post by Jeremy is a very interesting question.

SUZANNE :
Oh, yeah, I've seen other platforms allow for nested layouts. Which doesn't seem possible in layout core today. I've heard that this is an accessibility issue. Yeah. So, when you are creating a layout in Drupal, you can have different sections and then you have a template behind the scenes to control the markup of those sections. So, why would it be not accessible to have like a layout within a layout? Well, you're adding a lot of extra markup to the page. You can just imagine the number of devs involved, for example. But really, accessibility is less about that and more about all the content that you're displaying being semantic. So, I can imagine a layout within a layout could be accessible. That being said, I'm not sure why it would be necessary, it's really adding... I'd have to look at the specific use case because typically with a layout you can have, like in Drupal, you can assemble different sections in each section can have two columns or three columns. But then even within that, your content itself, if you're displaying, for example, a view that could have its own layout and often does, or if it's a hero, you could have it left-aligned or right-aligned with the text in the image.

So, often by the time you consider those things, a layout within a layout isn't, I'd say it's not often something you would need to do.

SPEAKER 1:
But there's always times. We are almost... Speaking of times, we were almost out of it, but gosh, I would have thought that was a great answer. Thank you Jeremy for asking that. I saw that someone had posted about Acquia site studio. Do you have any thoughts in the last minute or two?

SUZANNE :
Oh, my goodness. Yes, I have lots of thoughts about that. Yeah. So, Acquia Studio for those who haven't used it. It is kind of like elementary like I think somebody mentioned in the chat. It does provide also the ability to add styling to your components. And so, that does open up a lot of like on the flexibility side. That being said, I don't know that content editors are always the ones doing that work. So, the audience for that, I think, is more of a designer or site builder who does CSS and JavaScript. There's concerns, of course, about compliance with a style guide. So, there are tools within the site studio to kind of start off with a set of styles that you're adding through the interface and then creating more specific styles around the different components that you're adding. So, it does encourage kind of a standardization, but you have to then follow that. So, the people, given that tool, need the training to figure it out. And then the other piece about Site Studio is that it really sets up good tools for reusable content pieces.

So, you can take any piece that you've created, any component or layout or whatever it is, and say, I want this thing to be reusable. And that can cause some problems. But going back to the workflow goal, because it can make it hard to figure out what is the kind of canonical or what is the real version of this content. 'Cause you start to place content here and there and then you want to customize it. So, is it content that's always the same, or is the content that's allowed to have five different versions? And I think that that can create some confusion in content editors around where to go to edit the content, or just whether there's one version of the content or five. So, that I think also adds a lot of flexibility, but also adds some complexity and possible confusion depending on how it's implemented.

SPEAKER 1:
Another great answer, thank you so much. We are at or over time, this has been truly wonderful. Thank you, Suzanne.

SUZANNE :
Thanks, everyone. And I think Jeremy is leading a (INAUDIBLE) on this type of subject. I don't know, maybe Jeremy, you want to put it in the chat, like when that is, and people might want to attend. (CROSSTALK) Thanks all for coming to this? It was a pleasure.

SPEAKER 1:
Absolute, thank you very much.