Selecting and configuring the “best” CMS can bewilder and confound, but worry not. Eileen Webb, Karen McGrane, Jeff Eaton, and Ryan Irelan take you through customization, traditional versus “headless” CMSes, design, backend UX, and more in this hour-long event recorded live on August 25.
What we talked about
- What exactly is a CMS?
- How can you figure out which CMS best meets your requirements?
- Traditional versus “headless” CMSes: benefits and trade-offs
- The design side: patterns and components
- Author experience: improving your back-end UX
- Web publishing versus content management
Featuring
Transcript
Eileen Webb: Hello, everyone. Welcome to the fourth A List Apart: On Air event. Our goal for these A List Apart: On Air events is to provide a space for some deep expert discussions to happen along with some more casual Q&A from the audience. Sort of like a meetup without all the hassles of geography. And today we’re going to be talking about CMSes.
I’m Eileen, I’m your host. “Host”? I don’t know. I’m your moderator, and I’m going to go through some of the basics for what we’re going to cover today and then we’ll get started and introduce everyone.
I want to start with our sponsor. Our sponsor today are the wonderful folks at Pantheon. So Pantheon, if you have not heard of them, they are a hosting service for Drupal and WordPress. And when I say hosting, you might be like, “Oh, sure, like big generic server up in the cloud. Yay.” But actually, it’s better than that. Pantheon has built a system that is optimized not just for like the server needs of Drupal and WordPress but it actually makes the sysadmin tasks really easy. There’s one-click core updates and automatic backups and Git integration and caching. It’s really great, they’re really great. You can sign up for one of their guided tours or you can create a free account and just start playing around at Pantheon.io. And we’d like to thank them because they’re great for sponsoring us today.
So today, we are going to talk about content management systems. I’m Eileen, I’m the director of strategy and livestock at Webmeadow, and I’m a content strategist very firmly on the content strategy side that intersects information architecture and content modeling and systems architecture. I do a lot of work with CMSes of all flavors. I think I built my first one in, like, Perl in 1999, or something. So, you know, we all have things that we’re a little ashamed of…
So in the beginning, lo, those many years ago, web pages used to all be built by hand, right? The code and the content for each individual page was just assembled meticulously and stored in a file, and it was a pain in the butt. And so before long, we started modularizing the code, right? We started using tools like server-side includes to stick in the same header or the same menu at the top of every page. And then we started modularizing the content as well, because it’s just as easy to include a company tagline as it is to include something full of footer code. And so, in some ways, the earliest CMSes were actually just really nice interfaces to flat file systems. Now today we call that Jekyll, but back in the day, that was something that was, like—that was a new and exciting thing!
So in the intervening years, CMSes have grown and expanded to the point where right now that label covers everything from streamlined systems that are built for a single user to run a single blog, to giant, huge enterprise systems built to manage workflows of teams and cross-platform publishing and all kinds of complex things. There are proprietary CMSes, there are open source CMSes, there are… proprietary commercial open source CMSes. It is a big and messy world out there. And that’s what we’re here to talk about today. How can you find your way among that chaos? What are some of the perennial issues facing CMS developers and users? What are some of the newer issues that are coming to light alongside our attention to responsive and small screen experiences? And what even is a WYSIWYG, really?
So we’ll start with our panelists. Our panelists today—first, we’ve got Karen McGrane. Karen is a user experience and content strategy consultant. You’ve probably heard of her because she’s amazing and she is the author of Content Strategy for Mobile, which is published by A Book Apart. She co-hosts the Responsive Web Design podcast with Ethan Marcotte, which just had its first birthday, and teaches design management at the School of Visual Arts in Manhattan. Karen, say hi!
Karen McGrane: Hi. I’m so excited to be here talking with my friends about the same topic we always talk about. [laughs]
Eileen: [laughs] Yes, that’s very true. Alright, next we’ve got Jeff Eaton. Jeff is a digital strategist at Lullabot, where he designs and implements large-scale web platforms for media, education, and enterprise businesses. He co-authored the first edition of O’Reilly Media’s Using Drupal and he hosts the Insert Content Here content strategy podcast. He is a frequent writer and speaker at web and open source conferences. Jeff, say hello!
Jeff Eaton: Hello! I, too, am very excited and I want to make clear: when we say this is what we always talk about it, it’s because we love talking about CMSes. [laughs]
Eileen: Nice.
Jeff: We can’t be stopped.
Eileen: [laughs] That’s really true. Don’t even try. And then last, we’ve got Ryan Irelan. Ryan is the founder of Mijingo, where he has authored video courses on things like Git, and Craft CMS, and ExpressionEngine CMS, and Jekyll, and deployments, and project management things like Grunt and Gulp, and he’s written a book on ExpressionEngine. And he also does classroom teaching, technical consulting, coaching, and he used to be the VP of tech at Happy Cog. Ryan, say hello!
[05:00]
Ryan Irelan: Hello everybody! Thanks for having me. Happy to be here.
Eileen: Alright, so fair viewers, fair listeners, at some point during this broadcast one or more—or maybe all of us—may devolve into sort of spluttering and frustration and, like, maybe even ranting. And if that happens, just stay calm, do not taunt the speakers. Just take some breaths. It will pass; we will get through it all together.
Jeff: I usually just have a Vaudeville-style stage hook that just pulls me.
Eileen: Yes, absolutely. So we’re going to start. So everyone knows the lay of the land: we’re going to do about half an hour of discussion amongst ourselves, getting super into topics that we, frankly, talk about all the time because we’re super into them, and then we’re going to take a Q&A. So if you think of questions as we are talking, feel free to put them in the Q&A and you can upvote and stuff, I don’t know, there’s like “functionality” in there. And the second half, we’ll be going through those questions and chatting with people about what kinds of things you’re dealing with in your work with CMSes.
So our very first question, the question on everyone’s mind… Jeff, Karen, Ryan: which CMS is the best CMS? …No, so that’s a question we hear a lot. Like, this is something that all of us hear a lot. As soon as someone hears that we talk about CMSes, people are like, “Ugh. So, like, which one should I be using?” and all of us are like, “I need to leave this conversation immediately.”
Karen: It’s the number-one question that I get asked on stage at conferences. I’m usually unable to leave the stage at that point. It’s awkward.
Eileen: [laughs]
Jeff: I think of it as sort of like someone asking “Which shirt is best, of the shirts?”
Karen: “Which car should I buy?”
Jeff: Yeah. I mean, there’s certainly, like, ones that you can say, “Oh, hey, that particular CMS, I’m guessing that it’s just not right for your needs just based on what I already know.” But beyond some basic, you know, “Don’t use PostNuke these days,” it depends almost entirely on the needs of what kind of project you’re doing, what your organization is doing, how much content you’re publishing, all kinds of stuff like that. So, I mean, in a lot of ways it boils down to “How do you figure out what you need?”
Karen: And I think the real problem is most CMSes are going to get you 80 percent of the way there, maybe even 90 percent of the way there given how competitive this marketplace is and how many companies have kind of tackled some of these problems. And the issue is that that remaining 20 percent is each system thinks about the world a little bit differently and has its own weirdnesses. And I have a lot of sympathy for companies trying to sort through this kind of competitive marketplace where it’s not easy to articulate what your needs are and then go to a vendor and say, “How are you different from all of these other vendors?” because they’re all just going to tell you “No, no, no, we can totally do that! No, that’s great! Decoupled? No problem!”
Ryan: [laughs] Yeah, and I would say that, in terms of requirements, there’s more than just the technical or site architecture requirements, but the requirements of your team for content publishing or for integrations. If you have to integrate with other services or sites, that may push you one way or the other in terms of which CMS is best.
A lot of people think that a CMS is best, and so what I’ve seen a lot is clients being pushed to re-platform onto a new CMS just because the company that they’re working with thinks it’s the best CMS. And I think, in terms of doing real requirements research, that will help you understand which really is the best CMS, not just what someone tells us to re-platform to. Because a lot of times these companies don’t need to re-platform at all because their requirements fit the CMS that they’re on, but maybe they’re missing an important piece, like maybe their authoring experience is really bad, that’s where they’re battling and they feel like they need to throw everything out and replace it. So technical requirements is one part of it, but I would also think about the company’s requirements in terms of how to manage that content and the people that they will have to manage and maintain that stuff, as well.
Jeff: Definitely.
Karen: You might call that “author experience.”
[10:00]
Jeff: Yep, you might. I think one of the interesting aspects of that is that it reveals the fact that a lot of organizations haven’t necessarily thought through what those requirements are. You know, a lot of things are driven by features or a particular dream for how the website should appear, and visitors, and things like “How many people do we actually have to run this day-to-day? How often will it change? Do we need to do it in different languages?” Like, there’s all sorts of just meat and potatoes questions and, you know, “Who will actually translate this into other languages?” Those have big ripple effects way beyond “We’ve got a bunch of PDFs and Photoshop files. What CMS should we use?”
Karen: We don’t have very good language to talk about what requirements are, and I see something very similar to companies over the last 10 years having a website that doesn’t work all that well, and they don’t have a way to describe their pain with the website. The only thing that they can say is “Well, it’s not working. I guess we should redesign.” And so they go in and they change the colors, and they put four boxes on the homepage and clean up the nav a bit, make some overlays for the nav, and it turns out that that didn’t solve their problem because their problems were actually with the content, or with the workflow, or did the website actually meet anybody’s needs. I think we have the same problem with CMSes, where they have this pain point, they have no way to describe what this pain point is, they don’t know how to fix the pain, and the only thing they can think to do is re-platform.
Jeff: Yeah. Which I think brings us back to the ultimate solution of how to pick the best CMS, is you just find a bunch of vendors, you put them all in a Thunderdome-style room and the one that comes out, you use their CMS.
Eileen: I feel like that’s what the RFP process is. Don’t we already do that?
Karen: [laughs]
Jeff: Yeah. I mean, I say that joking because I like saying “Thunderdome,” but it’s actually a really poor way to approach those things in a lot of scenarios because it really leads to the firehose of “Look at all the features we have! Let’s do an impressive demo.” And it takes time to actually figure out what a good match is and not necessarily just throwing out Photoshop files and feature requirements and letting everybody fight over it. I… have strong feelings. [laughs]
Eileen: Well, so Jeff, that brings us to sort of an interesting thing that we had talked about earlier, the idea that CMSes are being asked to carry a lot more responsibility than they used to. Like, it used to just be a way to put your photos up and a place to stick your PDFs and that’s it. How do we start to tease out requirements and differences between what people need for content management versus what they need for web publishing? Because we tend to use those as synonyms, but they’re not, really.
Jeff: Yeah. I think it’s interesting because it was a while ago I started digging around into some of the distinctions between those and I discovered that content management systems have been around since the ‘60s and ‘70s. This is, like, a field that goes way back in very different forms, obviously. But it really grew out of large organizations and the government and, interestingly enough, typesetting companies—companies that did printing and typesetting for books and stuff like that, they had to manage all of these kinds of documents and they dealt with how to do goofy formatting things for books, how to tie footnotes together into your documents, the government had to do revision of everything. They dealt with all kinds of problems that were really meaty about these assets that we keep track of and need to manage and edit and publish in different ways.
But the interesting thing is that web publishing is like a small slice of that. Obviously the stuff that you were describing earlier, “We used to just make HTML files and every one was a precious snowflake that we hand coded in Notepad and then that got unsustainable and we built systems to manage them.” In a lot of ways, like the web publishing world sort of grew into the world of content management, is through sort of like a separate evolutionary path. We worked into a place where we were suddenly dealing with a lot of challenges that the world of content management had been grappling with for decades, but at a simpler level, you know? We weren’t dealing with 700 pages of documentation for a Boeing 747 in 12 languages, we were dealing with, you know, 200 blog posts and what images were there, teasers and stuff like that. So, on a smaller scale.
[15:00]
But as more and more has been demanded of the web pages and the websites we’re publishing, I think the world of web publishing has started to evolve and grow into a lot of the classic questions of content management, and that’s where you’ve seen things like enterprise content management systems, which aren’t just publishing web pages. You may think of it as, “Oh, it manages the intranet or something,” but they’re dealing with big questions about internal company knowledge and security issues and stuff like that. Or you have very design-focused publishing systems, where there’s posts to manage but a lot of the work is positioning things on the page and figuring out how things are going to look. Those distinctions and differences end up rippling out a lot of interesting ways.
But the web publishing world has been forced to grow up, I think. Because redesigns for large sites get more and more and more expensive the more legacy content you have, and people start thinking about, “Hm, how do we make this easier?” You know, Ryan, you were talking about the “Let’s just re-platform. Hurray!” If you’ve got lots of content, like you’re, say, a magazine publisher, that’s a non-trivial enterprise. So, thinking about “Well, we need a system that actually tackles a lot of these underlying management of our content asset problems more effectively so we can redesign without just tossing out the whole thing and rebuilding it from scratch.” And the rise of mobile devices has forced everybody to grapple with responsive design, and some of the systems that really emphasized nice dragging things around and creating a nice look and feel for your website don’t work well with responsive designs, they’ve had to be retooled.
So I think it’s as we demand more of websites we’re publishing, the CMS aspects of it, the classic “We need to manage these content assets and then publish them” has risen to more prominence. Because we’re not just making web pages anymore, we’re feeding mobile apps and making sure things work on 19 different zany devices. And then I think, how many organizations don’t have a web page? It’s sort of a given that everyone has to have some sort of web presence. So, I think web publishing systems have become everyone’s sort of first experience with content management systems.
And uh… Yeah, I swear I’ll stop ranting. Sorry. But I joke that Blogger set content management back by a decade, not because it wasn’t a good tool but because that first experience a lot of people had with the idea of managing content and dynamically generating pages was basically a one-to-one mapping between a piece of content and a web page at a URL that you would visit. You had your title, you had your body, maybe you had an author and a post date, and there you were. And today, given the complexity that we’re forced to deal with, that’s a really, really painful fit. You know, very few organizations can make do with that, but it still sort of dominates the mental model that a lot of us have.
Karen: I remember I spoke at a Forrester Customer Experience event a couple years back, and it kind of outlined this problem. I was on a panel in front of a bunch of people, and some executive raises his hand and he’s like, “What do you mean I can’t get this content out of my web page and into my mobile app at the level of granularity that you’re describing?” He’s like, “Isn’t that why I have this CMS?” I’m like, “Well, you have a web publishing tool. Like, all you have ever needed to do up until this point was make web pages and it was never intended to give you those kind of capabilities.” And we’re running into that now, and it’s a huge problem simply because no one expected to have to do these kinds of things with web pages.
Jeff: Yeah, and I think that’s what I meant with the idea of web publishing tools suddenly being forced to grow into classical content management problems. Like, now we’re not just saying, “Well here’s the big wad of stuff that will appear on the web page.” We’re thinking, “Well, what are the different pieces of data that are part of this? What’s the difference between a call to action and a summary and a story and an author bio? Let’s break those things out so we can reshuffle them.” You see that with things, like, a lot of current web publishing systems are real big on giving people the ability to find content types and fields and to have different templates for them and stuff like that, and I think that’s a reflection of that sort of push towards increasing flexibility and CMS functionality.
[20:00]
Karen: I’m working on a project right now—Eaton, you may know about it because you’re working on it, too; same with Eileen, you may have heard of this. It’s based on WordPress and, you know, I make fun of WordPress a lot, and I say that with love because I use it myself, but it is sort of like the “proto-blob CMS,” right? Like, everything in there is just one big dump of a field. And everybody wants to talk to me all the time about “Oh, no, no, WordPress has advanced custom fields now!” And it turns out—Eaton, you undoubtedly know this because you had to explain it to me 12 times—if I want to get to the level of a teaser and be able to show that teaser at large breakpoints and hide that teaser at smaller breakpoints, if I want to conditionally load teaser contents so that only larger breakpoints get it, I can’t do that with WordPress.
And, you know, I think sometimes when we talk about these problems, it seems like it’s solely an author experience problem. It’s like, “Okay, well but let’s make sure that the author has the fields or has the guidance to be able to enter that content in an appropriate way and so that we can kind of pull it out and rearrange it.” But there are some genuine architectural issues with how these little bits of content get stored and what level of malleability you have with them on the front end. And as we’re thinking about all these different platforms and all of these different devices we want to publish content to, the idea that somewhere under the hood everything is just one big dump of stuff is incredibly limiting, even if you have an author experience that lets you break it up into fields.
Ryan: I think that’s one of the biggest risks of how a lot of publishing systems—or we kind of call them CMSes—we can use that interchangeably if that’s okay, Jeff, at this point… [laughs]
Jeff: I’m totally okay with it. An intern with a folder and a text editor is technically a CMS. [laughs]
Ryan: Exactly, yeah. But one of the biggest risks is how closely the application, the dashboard, the control panel is tied to how things are stored in the database, right? And it actually creates this layer of noise that makes it very difficult, and later on we’re going to talk about decoupling and things like that. But it makes it very difficult to do what Karen was saying, which is to isolate this little piece of content very easily because of how things are stored. Maybe it’s serialized into a database, or whatever the way that they’re storing it is, it’s not standard from CMS to CMS. So, you have this layer of noise that you’re having to deal with when you’re trying to do something custom by really isolating a piece of content. And I think that’s dangerous because these systems are set up to be publishing tools, they’re set up to be directly tied to a presentation layer.
Jeff: Right.
Ryan: And by doing that, there’s certain decisions and certain tradeoffs you have to make. The ultimate goal I think when people are building them is to improve author experience, probably to make it as nice as possible, to create these custom and complex fields. But, again, I think the tradeoff there is that later on you have a little bit of a dirtier database store than you would otherwise.
Jeff: And I think really, all my rambling aside, that’s the real heart of the distinction between a classic CMS and a web publishing system. It’s like is it, out of the box, thinking about the content as sort of an abstract thing that you create and keep and may do a bunch of different things with, or is it primarily thinking of it as increasingly fancy and feature-rich ways of putting pages on a site? That’s really the big distinction.
Eileen: So Ryan, you were just saying something interesting about the idea of essentially having pieces small enough that they can be separated from the presentation layer, like in the data layer. That sounds very similar, to me, to the way that people talk about pattern libraries, right? The way people talk about breaking down interface elements down to the teeniest, tiniest pieces so that they can sort of be reused cleverly without sort of the overhead of a larger design dependence. Does anyone see that parallel? Am I making this up? I might be making this up.
Karen: No, that was a nice segue there. Nice lead-in. [laughs] I think a lot of people have been talking about pattern libraries lately. That was the last On Air topic. And Eileen, you have a great quote, which is that “Pattern Libraries and content models are BFFs, they go hand-in-hand.” This is a topic that’s kind of top-of-mind for me right now, that as there is this increased attention to creating more modular components on the front end, that we are still treating that as if it is an entirely front-end problem and we’re losing some of the ability to have those components actually modularized in the CMS itself. And where things are actually structured in the publishing system, that gives you so much more flexibility and so much more power to publish those things out dynamically, it helps with QA testing.
[25:00]
And, you know, I want to be clear: if you’re thinking of a pattern library seriously just as a front-end library of reusable code snippets so that your front-end developers can go in and not reinvent the wheel every time they have to make a calendar widget or whatever, that’s totally cool. I’m not saying that there’s not value in that and I absolutely support and respect that. But I just think there’s so much more that we could be doing to ensure that that componentization, that modularization is not treated just as a front-end style problem that is actually hooked up to the content model; that those components are actually built into the CMS and that as you are constructing pages in your CMS, you can be building them out of those reusable components.
And that if you want to be able to do that, when you want to change one of those components… Capital One has a fantastic case study of how they kind of “hacked” Interwoven into their own decoupled componentized CMS. They said that out of their 2,500 pages that they manage on the site with, like, 4,000 different variations of those pages, they have 20 components—just 20 components—that actually construct all of those different pages. I guess it’s like if somebody is excited about building a front-end pattern library, I just get so excited because I’m like, “What if I told you that that’s how the site on the backend could work? Wouldn’t that be amazing? Don’t we all want that? Yay!”
Jeff: There’s actually a book, it’s super deep on the nerd scale, so I wouldn’t recommend it to somebody who’s not a hardcore developer who’s super interested in diving in. But it talks about the idea of developing a ubiquitous language for your project, and I think that idea of bringing a pattern library in sync with the way that the people on the backend talk about it… I would even go as far as saying like how a business thinks about the stuff that’s being produced and managed… That can go so far in getting you to that point where you’re not reinventing the wheel every time a design changes too, or every time a new need comes up, making sure that developers who are doing the backend and the editors who are working with the actual content, if they’re using a shared vocabulary for what these different things and pieces are, it can really, really smooth out a lot of rough edges.
Karen: Yeah, I would be remiss if I didn’t give a shoutout to the fantastic ALA article from this past week on the language of modularity. I thought that was just a fantastic article that talked about how important it is to think about creating those modules or those reusable components and make sure that the essence of them, the goal of them is around functionality and what their purpose is rather than their styling, and to ensure that the entire team collaborates on defining what the purpose of those things are so you don’t wind up with a lot of very similar components that are used for different things. Or, as far as I’m concerned, you don’t wind up with content authors being handed—”Oh, here’s your promo component,” and not knowing what to do with it in the exact same way that we used to hand them “Hey, here’s your three-column template with hero,” and they’re like, “Uh, how do I stick my patient stories into these boxes you gave me?”
Jeff: Yep. At a much finer grain, it’s the same problem we face with just giving people raw HTML access. That’s a ridiculous amount of choice to put on somebody who shouldn’t need to be dealing with that stuff. And although component libraries sort of shrink that down to some extent, it’s still a challenge.
Eileen: That’s a good segue, Jeff. Nice, nice. Taking my job, I see, which is fine. So, we want to talk a little bit about author experience and there’s a question in the Q&A, which I’m just going to bring right in, which is about the idea of where do you find that balance between giving people lots of flexibility and giving people no flexibility but then what they create will actually be what you wanted them to create. What’s the balance and what are the tradeoffs there?
So, if people are not familiar with the concept of authoring experience, I use this like it is a real term, I learned it from Rick Yagodich. I pretend that AX is a thing that everyone knows, and eventually it will be, and so that’s cool. It’s the backend experience of the CMS; it’s the experience that you go in and you fill out the form and you make the content. And what do you do there? Do you put raw HTML in a field? Do you fill out a nice little form? Do you have to upload a pre-cropped image or do you upload an image and the system will crop it for you? It’s like user experience but for authors, for the administrative side of things.
[30:00]
And I guess I’m supposed to be moderating this, but you gave me a microphone so I’m going to talk about it because it’s what I’m obsessed with. So, authoring experience I feel like is the thing that people have forgotten about. Like just now, in the last couple of years, people are starting to be like, “Oh, this is why our sites only actually look good for three days after launch, is because we gave them a place to put a hero image and then gave them no information about what should go in there in terms of size of the image or shape of the image, or even art direction kinds of things.”
Like, “This is supposed to be a beautiful outdoor shot, not a macro picture of a salad.” And whoever it was that asked that question and people thumbed up it in the Q&A, I’m sorry that there is no good answer for where the balance is. It is something that exists with every single individual team and with every single individual project that you’re working on. Like, I don’t think there’s any sort of good, like, “You need to give them this much information but not this much.” I think you have to look at the people who are working on the site and decide with them collaboratively how much guidance they need.
So, I have a client that I worked with a few years ago who is a photography non-profit, like they give cameras to kids and have them take photos of crappy things in their schools, like leaks and things like that. And then they put on art exhibits, and they invite the board of education and stuff to come to the art openings, and it’s all pictures of their schools falling apart. It’s really cool. But they didn’t need any help with the photography stuff, where I’m actually used to most of my clients needing a lot of help with imagery choices and, like, what sort of sizes they should use and what kind of art direction they should have. But that was a client in particular who needed none of that at all.
So, I feel that happens to me over and over again with projects, is that I’m all set to give someone really good voice and tone information and the person who’s on the team who’s working on voice and tone stuff has it down pat and needs no help from me at all. But what they really need help on is how to format a table.
Ryan: Yeah, I’ve had a few conversations in the last two weeks with people who complained that it was too difficult and complicated for them to update and manage the content on their site. And the complaints were directly related to, like, “It’s just too complicated for me to get in there and do the content.” But it always came back to “We were never really trained on how to use the CMS, we were never really trained on how to properly input the content.” And so, to me, I see improving authoring experience starting with instilling in the people that are implementing the CMS or building the site that the decisions you make should be always focused on being easy for the end user, easy for the person that’s going to be using the site, and it doesn’t matter how difficult it’s going to be for you to implement that. Because the goal is not to make your job faster, the goal is obviously to make the person managing the content easier.
And then I think the next step is to implement real training and real documentation so you’re empowering people to use the site. Like you said, three days later the site looks like garbage because you gave them an unlimited WYSIWYG editor, and so they went to town. And Jeff’s holding his head. [laughs] But that’s not the fault of the person inputting the content, it’s that you’re not setting it up for a great experience by giving them unlimited options. Of course they’re going to drop in a table right out of the WYSIWYG editor without any styled classes on there or anything like that.
So, I feel like those are the first two steps. I don’t know what the rest of the steps are. But to me, in my experience, those have been the first two critical steps. Jeff has the third step.
Jeff: I actually think that one of the things that we’ve seen, especially on complex sites where there’s lots of different kinds of content and different people in different roles who are going to be doing different kinds of tasks, the first phase is getting the actual editing and author experience to be smoothed out and not just feel like a “database threw up,” I think is the phrase that Karen has used a couple of times.
But the next step is that there’s actual day-to-day workflow to what those people are doing. If you’ve got 10,000 pieces of content on your corporation’s website, updating a particular one with new information is a non-trivial task if somebody hasn’t thought through “How will Sarah find that piece of content when she needs to get to it?” “How will people go through and find product sheets that haven’t been updated in two months?” There’s a lot of different things like that that aren’t necessarily generalized “every CMS should have this feature” kind of stuff but need to be thought through for the specific scenarios.
[35:00]
Like in some news sites, it’s “No, we don’t want to have an approval process for stuff going live because, well, we hired reporters because we trust them to write stuff and we want there to be as little gap between them writing something and publishing it as possible.” But for the terms of service page on a product-driven website, that’s a completely different matter. And figuring out what those sort of supporting structures are for the day-to-day work that people are going to be doing outside of just the editing form, that’s another really important layer to it.
Karen: I think that so much of this, as with everything in customer experience and user experience, when you really start to dig into it it comes down to how these projects get budgeted and paid for. And there are so many scenarios in which you can do something that will speed things up for the developers—make the developer's life a little easier, a little faster, save a week in the development timeline—that winds up getting paid for 100 times over, 1,000 times over by the content team, the people who are entering that content; that the cost of that gets born in a completely different place.
I’ve totally been on projects where the development team has come and said, “Hey, we could totally save two weeks if we do this,” and you come back and you’re like, “Yeah, but then that means that the content authors are going to have to touch every single piece of content twice.” You’re going to double or triple their workload at the expense of saving yourself a couple of weeks? It’s not worth it. But we don’t have really good ways to talk about these things, and I think it’s not something that teams that are making the decision to re-platform or making the decision to redesign the website are even thinking about, “How do we factor in the cost of a bad author experience over time?”
Eileen: You know, I’m not sure it’s true that we don’t have good ways to talk about it. It feels to me like those are the same concerns that come up with front-end user experience. Like, with the things that we talk about on why we should do research, and why we should do testing, and why we should have sort of iteration and changing. It’s just actually putting priority on administrative users as real users. I mean, it’s not standard practice in a way that we would want it to be, but I don’t think it’s particularly arguable that you make a better product when you do user testing as you are building; that you create experiences that are smoother, that are safer, that are more comfortable for people if you do user testing. And we pretend that the people who use this site every single day, like 20 or 30 times a day, we pretend that they’re not users? We pretend that they’re employees and so they just have to do whatever crap the company throws at them.
Ryan: Yeah, and it feels like that these types of author experience issues—and I’m just going to throw this out there, let me know if anyone disagrees—I feel like they’re more easily absorbed in larger companies than they are in smaller companies. Because I feel like that in larger companies, there’s maybe more of a tolerance for having to do a lot of workarounds. And just sort of my own anecdotal evidence in terms of talking to people that are in smaller companies, they’re the ones that are the most frustrated because they typically are doing four other things in addition to having to manage the website, and they are really burdened by a poor author experience. And I would say that there’s a lot more of those medium-sized types of companies and projects out there than there are of the big enterprise projects.
So, just something to think about when we’re taking on a new project is, like Karen said, budgeting for that, doing research and discovery on how people manage their content, what their workflow is, stuff that content strategists get into a lot in terms of helping people develop the content and create a plan for it. But there’s technology implications there too, in terms of understanding how someone right now manages their content and what the roadblocks are, the hurdles that they have to jump over to get the terms of service page uploaded.
Jeff: And in terms of selecting a CMS, the flexibility of, you know, how much leeway there is and how difficult it is to...tailor it to the organization's needs. You can make the front end as fancy as you want and a lot of people have solved that problem, but there are some systems that you just “get what you get and we hope you like that” in terms of the backend.
[40:00]
Eileen: Ooh, good transition time, Jeff. Nice! One of the things that we really wanted to talk about—because it’s very hot right now, you guys—it’s very hot to talk about decoupled CMSes. And so, maybe that’s one of the use cases for them, right? When you have a CMS that does some things that you want, that administratively works well for you, but works terribly for you on the front end. What are some of the reasons to go from a single system to a decoupled system? What are the good things and the bad things? Is this really just a quick trip into the pit of despair?
Ryan: [laughs] Well, I would say that a good first step is to make sure that you have a reason to go into a decoupled system instead of just doing it because it’s something that’s new—or, in fact, it’s not even new, but it’s something that’s sort of talked about a lot right now. But I want to kind of back up and talk a little bit about decoupling and headless. You’ve heard a lot about probably a headless CMS. I know Jeff has talked about headless CMSes; he was even talking about the name “headless” and, I don’t know Jeff, maybe you don’t like that name so much.
Jeff: It’s a little too “Sleepy Hollow.”
Ryan: [laughs] Well it’s interesting, because I always thought about it as like a headless computer or server, like if I have a Mac Mini sitting in my closet that I only interface with over VNC or some sort of screen-sharing, just over like a services level instead of a user interface level. That’s why I think headless actually works really well.
So just kind of like the basics of headless and decoupling really quickly: the headless, to me, means taking an off-the-shelf CMS and basically lopping off the presentation layer. So, let’s say you used a CMS—there’s one that I really like called Craft—and let’s say I just wanted to use Craft because it has a nice user interface for managing the content. But I didn’t want to use the presentation layer, I didn’t want Craft to render any of the templates, any of the HTML that the browser would use, I just wanted to use it for the inputting and serving of the content—then that would be like a headless scenario. Craft would not be responsible for rendering any templates or anything like that. I would use another tool like… Jeff, we were talking about React.js or Angular, or maybe you would just feed some iOS apps or some Android apps, there would be maybe no HTML at all that’s rendered at all. So, to me, that’s headless.
Now, a lot of people use headless and decoupled interchangeably, but I kind of think they’re actually a little bit different. I feel like that they’re related in that headless is a phase of decoupling. So when we talk about decoupling, we’re essentially talking about the separation of concerns when it comes to your site. It’s really interesting, because there’s actually a very similar discussion happening in software architecture and software development right now, in the same time, about monolithic versus micro-services. And the idea is you have this giant app, like a huge Ruby on Rails app that does everything you need to do for your application versus 10 little mini apps or services that, together, talk to each other and do the same as this monolithic app. We’re essentially talking about the same thing when we talk about moving from a monolithic CMS or just like the whole thing that handles everything from the database to the presentation of the HTML. When we talk about decoupling, we’re talking about breaking that up into micro-services, into smaller pieces.
So, the idea here is that you’re trying to do things that make your website development more future-proof. If you do have to do a redesign and you wrote the front end in Angular, then you wouldn’t have to touch the CMS at all to do that redesign. Even if you wanted to do it in the latest and greatest JavaScript framework, you could. It wouldn’t matter at all to whatever CMS is managing the content. So, those are the two things. That’s the good. The good is it actually helps you separate the concerns, it potentially helps you have a more future-proof site. But some of the bad here is that it actually can increase the technical expertise that your team needs to have. [30 seconds of technical difficulty].
[45:00]
Anyway, so the downsides are things like that fragmenting the technology, you’re basically breaking up—you’re thinning out your expertise layer across multiple technologies, which is always a risk, both for you if you’re just an agency developing the site but especially for the client who you’re handing that off to. And it could be a longer time to deal with bugs, because you’re actually having to look through several systems to manage that.
Now, those are sort of the downfalls. The good parts are that you’re no longer reliant on a presentation layer that you don’t like how it works, and you can just break it off. Before we jump back, I want to quickly give one example and then see if anyone else has some other examples to kind of solidify this for everybody. A few years ago, Happy Cog did the MTV O Music Awards, and instead of doing a big CMS thing, it was broken up into smaller pieces. The Craft CMS is actually what managed the content, it’s what the content editors input the content into. There was another section of the app that was handled by Laravel, and that actually handled all of the template layer and the presentation, and also handled some other services like the authentication; there was all this voting and stuff, so it handled all this application stuff. There was even, like, a WordPress piece that was like the blog thing.
So there’s all these different pieces, and the Laravel app actually didn’t communicate with Craft through a service layer, that Craft had actually communicated directly to the database. To me, this is more of like what I would consider on the farther side of decoupling. Where I would see headless as phase one, I would see this as phase four or five of decoupling. Now, I think there’s a lot more risk on that farther end of decoupling because you are taking on way more technical debt than you would, I think, if you just stuck with a headless setup.
Jeff: Yeah, no, I agree wholeheartedly. I think one of the examples of that farther down decoupling line is the Martha Stewart Living website, that’s one that Lullabot did a couple years back. It’s actually two, possibly three separate Drupal instances. One is just for user-generated content, another is just for editorially-generated content, and there’s a layer that basically is stitching those things together and saying, “Okay, well we’re pulling up an article and assembling these things,” and then reaching into our enterprise content library and saying, “Are there recipes that might go along with this?” and then pulling in UGC, and it gave them the ability to really effectively partition different types of things. They had different security implications and different needs. And, you know, it was built on Drupal, but it essentially was building out those different separate services that they needed to deal with in different ways.
We just relaunched the Lullabot.com site in a headless fashion, like what you were describing. We took Drupal, lopped off the front end, and made a React.js application so that the designers could just have full, precise control over everything. And the real challenge is if you take on a fully decoupled project, there’s a lot of architectural questions about how the system is going to work, how the pieces are going to talk to each other, how closely they need to be tied to each other, that you’re taking on than when you just say, “Okay, we’re going to CMS A or CMS B and drop it in.” It’s essentially like you get the bundle deal with that, those questions are all answered and you can at least assume the CMS is internally consistent in dealing with those kinds of things.
But if you find—especially with what we find in publishing clients and media clients, who are already having to push stuff out to a bunch of different kinds of publishing channels, talking to apps and sending out feeds for partners and publishing to the website and maybe driving—I’m sorry, Karen—a separate mobile website and stuff like that, they’re already having to deal with some of those challenges already and they’re already building different front ends and different pipelines. So to some extent, they’re already being forced to tackle some of those decoupling challenges. So explicitly saying, “We’re going to do a decoupled system” is more of like an acknowledging of the work that needs to be done than “Hey, let’s get onboard with this cool new thing!”
Ryan: Yeah.
[50:00]
Karen: Eaton have had many conversations about decoupling not just on the front end but also on the backend. Like, I think for lots of major media properties, if you’re a magazine publisher, you probably want a core content repository that is, frankly, separate from whatever author experience layer you’re creating because you want that core content repository to be as stable as possible so you don’t have to go back in and re-platform that database when you’re trying to re-platform your website or even the other experience. And I think that the web publishing industry is going to be informed a lot by some of the trends you see in the enterprise space, which is that you see so many of these larger enterprise platforms, and even Drupal, trying to become digital experience marketing hubs, where it’s like everything and the kitchen sink. It’s like, “We’re an analytics package, we’re a personalization engine, we’ve got your business logic!”
I had a conversation with one client where they said, “You know, as we’re looking into personalization, so many of these big enterprise packages want us to treat that as if it’s all one big monolithic system, like ‘buy our big master CMS and you’ll get everything.’” They said, “The truth is that for us to genuinely do personalization, it’s going to have to touch so many different systems that we’re going to have to write these APIs between these systems anyway. We don’t really care if it’s all part of one big monolithic CMS package. In fact, we’re probably better off treating those things as if they’re somewhat discrete elements.” It seems like there’s a lot of marketing in the enterprise CMS space that’s trying to get people to buy a one-stop-shop, and I don’t think that’s what people really—even large enterprises don’t need it—and that probably means that smaller and mid-size enterprises don’t need it, either.
Ryan: Yeah, it sounds like the constant sort of dissidence and friction between the unbundling crowd and the bundling crowd. You know, the people that are trying to constantly unbundle, like us—like talking about decoupling, we’re trying to unbundle for good reasons—and the people that are trying to bundle for business reasons. It goes to show that it actually really does just depend on what your situation is, like what you actually need. And that’s why when you see people doing headless or decoupled systems, it shouldn’t be a technical pursuit, it shouldn’t be like, “Let’s decouple because that’s technically a challenge and really cool.” It should be like, “Let’s decouple because this is actually going to solve some real problems from technical up to business,” instead of trying to do it as a technical pursuit. Because if you do it as a technical pursuit, I feel like you’re actually getting into very risky territory.
It’s like refactoring code—not to get too code-y here. But you can refactor code over and over again until actually you’re creating more complex and fragile code than you would if you hadn’t broken it down into so many tiny little pieces. And you can do that here. Each element of your decoupled system on its own might be fairly, like, low risk. But when you bundle them together, you’re looking at a really high-risk proposition because you suddenly have all these moving pieces. And it’s not bad, per se, but it could be bad for you. That’s just the thing that you have to figure out.
Jeff: Yeah, those are choices that don’t come for free. Eight tiny things that are individually simple but then will have to talk to each other. It's complexity in the interactions rather than the one monolithic piece.
Eileen: Well you guys have just done a really, really good job of addressing, like, six questions that were floating over there in the questions without me prompting you, so way to be. You be you. It’s good.
I’m going to kind of combine two questions into one, ‘cause I sort of see them fitting together a little bit, and those two questions are something along the lines of “Is it okay for a CMS to have things that plug in versus things that are core?” What things are important to be a core piece of the CMS versus things that you can sort of modularly add on later? Are there things that are really important to have be core and are there things that it’s more fine to have posted on later? And then the other question can just be summarized with, like, “WTF, vendors?” and how do you deal with vendors who tell you that their systems can do absolutely everything all the time forever and you should buy it right now?
Jeff: “It’s computers, they can do anything!”
Eileen: Right? …So does anyone have thoughts on that?
[55:00]
Jeff: I’ll take the “computers can do anything” thing. I think the big challenge in the thing that we were talking about at the very beginning, I think it’s really tough because once you get into a situation where you’re basically talking to salespeople about a system, the incentives are almost to say, “Of course, it can do that!” Understanding whether you actually need something or not, and how big of an impact it is on what you’re building—those priorities I think are a good way to cut through the crap. I think if you have a website with basically 50 pieces of content and it’s updated once every two weeks, you may well do great with Squarespace, and it may be right what you need. On the other hand, you may need Sitecore if you’re on the other end of the spectrum. But figuring out what, like, the scale is and what the complexity is is hard. I mean, I think language localization is one of those hard things that’s hard to bolt on after the fact, so knowing what non-negotiable things you just have to have, that’s a good checklist to start with.
Eileen: Does anyone else have thoughts on that, about vendors in general? I think that’s a really good guideline, is that the things that are most important to you should be things that are also most important to the CMS. Does anyone else have thoughts about that, or about how to deal with vendors who are like, “What’s the deal with CMS vendors? There are some nice ones out there, but there are also some not-nice ones out there. What’s happenin’ with that?”
Ryan: I would say that it would be to your advantage if you’re out shopping for a CMS, and if you’re in a space where you’re actually, like, dealing with salespeople and vendors, then you’re probably at a price point where you should certainly be prepared with a lot of research and information on what you currently have and currently need. And even if that means hiring somebody independent to do discovery work with you to understand where you’re at and where you want to go and to give you a roadmap… I know discovery-type of work is really big, and I think it’s really big for a reason, which is that I feel like it saves people a lot of money from going down the wrong path.
Let’s say you have to re-platform—sometimes you do if you’re on something that doesn’t suit you anymore. You have pre-step of the project, which is discovery, and you do that before you choose a vendor for your CMS. Like, I see the CMS stuff getting chosen just sort of like a quick basecamp post. “Oh yeah, let’s use this CMS.” I feel like if the stakes are high enough, you have to… I mean, if it’s your neighbor’s dental website, then yeah, you know, throw it on whatever, it doesn’t matter. But if there’s going to be longer term implications and a lot of integrations, there should be a pre-step that is this discovery process that gives you a plan for what you need. And then you can present that to the vendors and say, “Hey, this is what we need,” and hopefully it would help the vendors understand what you need, because a lot of times they’re speaking purely because they’re actually trying to guess what you need. They’d rather give you everything and have you be happy than not give you enough and then their product doesn’t meet your needs.
Karen: I also think having a—to kind of flip that around and say if you’re at that price point, you could be putting out an RFI or just doing the vendor calls and really pressing each of the vendors on what they think their product is especially good at. I’ve seen this happen, where you come in with a set of requirements—which you should absolutely do, I’m not saying you should not do that—but the vendor then has this incentive to just say, “Oh, of course. Absolutely.” Having seen conversations where a client wants to do something that’s, like, super decoupled and really wants to focus on the content repository and the author experience… And I don’t want to name the vendor, but I’ll call them “Schma-dobe” wants to come in and say, “Hey, oh yeah, of course, you can use us as a completely decoupled system.” Well… yeah, you can, but that’s not why you would purchase that product. So, if the vendor can’t articulate “If you need these types of problems solved, this is why you should purchase us,” know that before you go in.
Jeff: Yeah, I think that if a vendor can explain what kinds of scenarios their systems wouldn’t be a good match for, that’s a good sign. And, you know, it’s sort of like, “Yeah, okay, if you can tell me why I wouldn’t want to use it and why I would,” that’s better than “It can do anything!”
Eileen: Alright, that’s awesome. We are at the end of our time. I know, the four of us could, like… we could be here ‘till, like, 7 p.m. Just be like, “No, it’s fine! Let’s just keep going, Hangouts are free!” Yeah, so thank you everyone for joining us. I feel like that was a really nice note to end on, with sort of discovery and requirements and thinking about asking hard questions, and that means both asking hard questions of yourself and your own needs and also asking hard questions of the people who are trying to provide solutions for you. I mean, we’re not, like, jousting here, but in some sense asking them to prove themselves to you in a way that helps you understand how their priorities are aligned with yours.
So, thank you everyone for joining us today. We will be announcing more upcoming ALA events on the website and on social media. And so, if you follow us on Twitter and on the Facebooks and all that, then you’ll hear about those soon. So, there will be a video of this panel posted to the site in the next couple days, and then a full transcript will be posted early next week, which is awesome.
Thank you, again, to Pantheon for being our sponsor. If you want to either just play around on their stuff, because you can sign up at like a free-level account and just play forever, or you can get like a guided tour. So if you’re a person who you’re like, “I would like more guidance on this,” Pantheon.io—you can go and sign up for either of those there.
And thank you Karen, and Ryan, and Jeff for ranting about CMSes with me today. And we will see you all next time!
Jeff: Hurray!
Eileen: Yay!
Ryan: Thanks.
