Episode 14: Know Your Integrations (w/ Greg Dunlap)

Hello, this is the Web Project Guide podcast, and this is episode 14, know Your Integrations. I'm Corey Vilhauer, director of Strategy at Blend Interactive and co-author of the Web Project Guide. Later we'll be joined by Greg Dunlap, director of strategy at Lullabot and longtime Drupal contributor. But first I'm joined by the other Web Project Guide co integrator, Dean Barker, senior director of content management research at Optimizely. Hey, Deane.

Did you just call me a co integrator?

Because we're talking about integrations, but an integrator feels a little bit like one of those gross corporate titles that don't mean anything.

It does. It absolutely does. It feels like a human resources title. And I'll apologize in advance. My voice is in rough shape, so I've got a little Kathleen Turner gravel going on here.

Do you want to explain who Kathleen Turner is to anyone who doesn't know who that is?

Kathleen Turner is a famous actress. She played in romancing the stone opposite Michael Douglas. She was Chandler's parents in Friends and has this very, very low gravelly voice. It's funny you say that because there was somebody at Blend once that had the same situation and I had to explain who Kathleen Turner was and she had no idea. So I actually sent her clips of Romancing the Stone. I'm like, "This is Kathleen Turner."

I think the most important thing, yes, I looked it up.

Are you looking up Kathleen Turner right now?

I recognized the name. I've actually never seen Romancing the Stone, so I missed that one completely. But most importantly, she's the voice of Jessica Rabbit in who framed Roger Your Rabbit-

Oh, really? Okay.

... which I had no idea. We're going to have Greg on today, Greg Dunlap, who is a good friend of mine from the content strategy, essentially from the confab circuit. And he's going to talk about integrations. But I have a question for you about, what feels like 700 years ago I did a talk that was called Making Things Real. It was about content strategy for the content management system and sort of an attempt to simplify the idea of what a website is made of. What are the pieces that we need to think about when putting together a design or a technical plan or a content model? I broke it into four main groups. I broke it into pages, components or blocks, usually blocks, aggregations, so news feeds and search results, and integrations. Do you think that I was accurate? Do you think that's still accurate? What am I missing, Deane?

No, I think you are accurate. Every CMS has their own kind of idiosyncrasies and Peccadillos. I think that is,

Hold on, did you just say Peccadillos?

I did, I did.

It's good word.

It's a very sophisticated word, but I think that's fair. And far and away the scariest one there which I will bring up with Greg and see if he agrees is integrations. Integrations are when you are connecting your CMS to some external system and expecting them to work together. That's an integration in general terms is when you connect to systems together. But integrations from a CMS standpoint is usually when you want to take content from outside the CMS and make it appear that it came from inside the CMS. And these are terrible because it's a one to many relationship. You have a CMS, which is the thing you know. But then you have eight billion other systems and you have customers that expect them all, "You just connect these two systems together and it works great."

(03:30)
And very, very difficult especially to plan and bid because you're an expert in the CMS clearly, that's why you're in that conversation. But then they come to you with some random system. I'll never forget a university, there was a system that allowed you to pay your university parking tickets. Apparently this was a big deal. And they wanted to integrate with the system, this custom bespoke system that I think had a dozen customers to let students go onto the university website and seamlessly looked like they were interacting with the university website, but pay their parking tickets. Another request I heard from somebody else I didn't get, but there was a system where you could see what washers were free in each dorm room and they wanted to be able to publish this on the website. Thankfully now that washers will text you when they're free, but which as a 51 year old man blows my mind.

Incredible.

But yeah, they wanted to put this on the university website so a student could go to the website and they could see what washers were free. First of all, gross misapplication of resources. My God. The university was struggling with enrollment. Let's not spend any time taking care of the washers. But the other thing is this is an incredibly bespoke system. I don't know how this thing works.

(04:47)
And what we talked about in the book and what we'll talk to Greg about is the idea there's development risk. I don't even know how to bid this. I don't know how much it's going to cost to make this thing work together. But then there's runtime risk. Assuming I did get them to work together once, they now have to continue working together forever. And one of the problems is that you control the CMS implementation. You control how that develops. But some other company is in control of the external system and you have no idea what they're going to do with that, if they're going to change the API, if they're going to publish breaking changes, and how do you keep track of that?

If they're still going to be in business.

Yes. You are seeing, my son has a birthday on November 1st and his only request for a birthday present what I went through, I did no shave November. So you are seeing me, Corey, on this video with 30 days of solid beard growth. And you will notice, Corey, that beard is 100% gray and it's gray, Corey, because of integrations. That was a long way around saying integrations suck and they're very hard to bid and they're very hard to keep running. And that's why I have a gray beard, Corey.

All right, let's get into it. Greg Dunlap is the director of strategy at Lullabot. He has been active in the Drupal community for over 15 years, both as a developer and as a core contributor. He spearheaded the creation of Drupal 8's configuration management system, which he'll explain because it sounds complicated. But in recent years he's been focused on issues around content architecture and specifically the authoring experience. But first, this episode of the Web Project Guide podcast is brought to you by Blend Interactive, a web strategy design and development firm dedicated to guiding teams through complicated web and content projects. Blend's been building great websites for over 17 years and we're always looking for our next partnership, so visit us at blendinteractive.com.

All right, we are back and we are here with Greg Dunlap. Hi Greg.

Hey, how's it going?

Good, how are you?

I'm doing good, doing good.

Yeah. Greg, tell us a little bit about yourself. What should we know about you?

What should you know about me? I have a long background in mostly software development. I was doing software development in the pre-internet age on desktop databases for people of a certain age. I cut my teeth on Paradox for DOS and worked my way out from there to get involved in internet stuff. But I feel like my kind of career really took off when I got introduced to Drupal about 15 years ago. And that's when I started really getting into content management and content management systems and working with clients to implement content management systems. And I've been working in the consulting space for Drupal focused clients ever since. So I'm at Lullabot right now. I'm the director of strategy and I've been there for 10 years at this point.

I know you almost exclusively as a guy who talks about Drupal. With the exception of a handful of conferences we've met and talked at, you were sort of the guy who talked about Drupal when Jeff wasn't talking about Drupal. Jeff Eaton, of course we know each other through a common friend Jeff Eaton. So I guess what I want to start with is that this episode's really focused on the idea of integrations. And I think that there's probably not a deep knowledge of what even in integration is, what we mean when we say integration. So if you could, give a high level description of what you or what Lullabot means When you say integration.

For me an integration involves anytime you have information of some sort that is coming from outside of the system that you're working in. So if we are building a Drupal platform, the primary source of information for that is editors or authors writing articles or blog posts or creating events and that sort of thing. But a lot of times there's information from outside of Drupal that needs to come in and sometimes that information may get actually stored in Drupal and become a part of the content management system. It may just be stuff that's brought in dynamically through JavaScript or iframes and things like that. But anytime you have to bring information in from the outside, that's what I would consider an integration.

I've often loved the idea of a content management system is an aggregation hub for data. Sometimes integrations are a tiny part, like 5%. "Oh, and we also need to integrate with this other system." But let's talk about the opposite end of that." And I hate to jump in with both feet here, but what do you think about the average CMS as being used as a hub for content created outside of it? What would a CMS where you didn't actually create content, what would that look like?

Wow, there you go. It's such a big one. I actually worked with a client, a public media client semi-recently where I would say that the majority of their content was actually not created in the CMS. Really what the CMS was a data normalization and presentation layer when it comes right down to it.

Oh man, that tickles so many boxes from 10 years ago. I wrote a blog post, my life is a series of blog posts. I wrote a blog post called A Web Content Delivery System, which was the idea of a content management system just used to deliver content created elsewhere. I still love that model.

Yeah. But they were an NPR affiliate, so they would import stuff from NPR. But they also had a TV station. So they would have to import scheduling and TV show information from the various places that provided that information. They also provided sports scores and that sort of thing. So I would say that probably 75% of their content was externally sourced at some point. And that's one of those things where one of the things about integrations is that they're expensive. And so when we source systems, all of those integrations, knowing about that stuff upfront is really important because integrations and migration tend to be the bulk of a lot of projects.

We talk in the book about two different types of risk, development risk and runtime risk. And development risk is the risk involved, the cost overruns of putting the thing together. But then runtime risk is the risk of keeping them running together over time. Have you ever worked on integrations where you thought, "I can technically get this to work, but my God, I don't want to keep it running over the long term."?

Yeah. Actually that specific client had integrations like that. One of their most popular pieces of functionality was providing high school football scores in very close to real time. But there was no actual service that provided that in any way. And so what they did was they wrote a web scraper basically to scrape the information off of a variety of webpages, normalize it, shove it into the system, have an editor go through it and manage and clean it up when necessary and display it on the website. And it was this gigantic mess and it changed all the time because the various sites that displayed these scores, their HTML would change all the time. And that's a perfect example of something where writing it the first time was not that hard. It was fairly straightforward, but maintaining it is a nightmare. And it's only because of the value of that information for them that they decided that it was worth keeping up. But in most cases, that's the kind of thing where I would look at it and say, "This is not something I would recommend."

I think there's something there, especially when we work with people who don't fully understand sort of the concept of what an integration does or might do or that connection means. It's a constant reminder that we're building something, we're building a tool that is yours. You can control all of these different aspects of it. But introducing something like that on the outside, you don't have any control over it. You can make everything as perfect as possible, but you don't have any control over what happens to it outside of your system, which can be really, really frustrating especially since everybody's kind of like, "Cool. My site's done and it's going to work forever because we just have to maintain it." The issue is that somebody else has to maintain other things that you don't have any connection to.

Yeah. And that's really the source of the whole buy or build it question when it comes to these kinds of things because we're not talking about just brittle code, we're talking about massive organizations or companies go down all the time. And if your integration is based on... In the book you talk about course management in a university, which is a great example. It's like if the company that's providing that information to you disappears, now you've got a pile of mess on your hands to figure out. And even this media company I was talking about, NPR is making a massive change to their API and moving to a different system that's modeled a completely different way. And now it's all of the assumptions that we built their system on based on the assumption of a stable API and provider of information are out the window. And we've got to kind of rethink a bunch of stuff. And anytime you are reliant on an external system, you're going to have those problems no matter how stable that system seems like it is or should be.

I think one of the best things that you can do is be willing to tell your client, "No, this is a terrible idea."

Oh yeah.

How often does that come up for? Tell us about how those conversations go. I know from my 15 years doing professional services. But how often do you find yourself sitting a client down and saying, "Look, this is just not the right way to do this."

Pretty often. I think that it just depends because sometimes there are things where if the data lives elsewhere, it doesn't necessarily make sense to start to throw it all away. Again, I'm working with a state government right now and they've got a service where they manage all of their state agencies and their contacts and their hours and their locations and all of that kind of stuff. And they've got that information sitting there. It doesn't make sense to duplicate it even if it's going to be a lot of work. There's a trade off there of the work of repurposing all of this stuff into the CMS or not.

(15:26)
I think a lot of it really comes down to the value and the importance of the data to your organization because if there's data that is absolutely critical to your organization's livelihood, be it content or other kinds of information, then owning that data and having control over it has real value. And I think there's a value there that a lot of clients don't understand because they think making it someone else's problem is always going to be easier. But when you have mission critical information, that's not necessarily always true.

Okay. So you've got a dangerous implementation coming up and you're thinking, "Boy, this is really sketchy. The runtime risk is high here." Another thing we talked about in the book is realtime integration versus kind of import and update integration. I always felt like it was safer to claim that data, even if temporarily just bring that into the CMS so the other system could go away and you would, until the system came back, would have some copy of the data. Are those decisions you find yourself making?

Yeah, a lot. And I think especially again when we're talking about integrations that are mission critical, I think that's very important. It also brings, if you have it in the CMS, you can use whatever tools the CMS offers you to manage that data and you can use standard code that you're used to and you've built over time to do that like in Drupal, there's a functionality that's called views for creating listings. And everybody's very familiar with it. We know how to make it look good. We know how to add searches and filters to it and stuff like that. And so if that data is in Drupal, we can use the tools we are familiar with and build stuff very quickly. Whereas if it's in an external system and we're putting together something very real time like a JavaScript front end or something like that, we don't get to take advantage of our shared knowledge and shared code and stuff like that.

(17:17)
So I think that in a lot of cases, again, especially for stuff that's very high profile and mission critical, bringing it in is the best. And I would say that the majority of the time that's what we recommend to clients. But I will also say that we don't work with a lot of clients generally for whom liveness of data is of particular importance. And I think back to the situation with a news organization. For them to have very live data may be much more important than to have the content information for a professor at university be live. And that's where we start maybe weighing other options.

I think there's value in CMS ignorance, right? There's value in a CMS not actually knowing where this data came from. There's value in a CMS just saying, "Oh look, I have some data. Maybe somebody typed it in."

Yeah. "I'm going to do some stuff with it." Yeah.

"Maybe it was important." I don't even know. And whenever I looked at integrations, my default plan was, "How can I make the CMS completely ignorant of where this data came from?" because then that other system kind of fades away. The other thing we talked about in the chapter was the idea of one of the most hated words in professional services, seamless. Everyone's like, "We want a seamless integration," "Oh, okay. I'll check the seamless box. You didn't tell me that before. I meant to check that box and make it seamless." But I talked in the book about the idea of showing the seam where sometimes I would sit clients down and say, "Look, just show the seam. Just take this other system, cname a subdomain to it and actually send them to that website."

(18:54)
And I would even tell customers, they're like, "Can we make that look exactly the same?" I would just tell them, "Don't make it look exactly the same. Brand it, but make people understand they've gone to another website because if you make it look exactly the same, then you go into uncanny valley where they're like, 'Well, this sort of looks the same. But it's not quite the same. Is this person trying to trick me?'" How often do you tell customers, "Look, this is just a bad idea. Let's just send them over to this website to do this thing."

Man, all the time. I think a really good example, especially now in the modern climate, is anytime you have something that is collecting personally identifiable information that's not mission critical to your organization. For instance, I'm working with a government client right now and obviously there are cases where constituents need to enter personally identifying information to find stuff like unemployment or to submit a request to their agency or stuff like that. And if you can push that outside of your organization that, it resolves a lot of data privacy issues you don't have to worry about storing that stuff in your CMS and stuff like that.

(20:04)
So that's a data-centric reuse and why you would do that. But from a functionality process, we do that all the time. And I agree with you about the branding aspect. And a lot of that comes back again to systems you have control over or don't. Do you really want a system that you don't have any control over appearing to be a part of yours when it can change at any time in a way that you may not like or approve of and now that's tied to your brand and it's invisible and everybody thinks it's you doing it and not them? So yes, I agree. That is definitely something we talk to or recommend to clients quite a bit.

Yeah, that's very wise. And it almost takes a level of bravery and heroism to sit a customer down and say, "Look, I would love to make this perfect for you," because there's some degree of power there. You think, "Oh my God, I made this thing perfect and everything." But the realistic thing is not only is the development risk high, it's the runtime risk that people don't think about. They always ask, "Can you do this?" They never ask, the right question is, "Can you keep doing this?"

Yeah. Or, "Should you do this?"

Just keep lying.

And the question we often ask is not, "Can we do this?" It's, "Why would you do this?" What is the source business case behind doing a specific thing, around integrating a just specific way? What functionally are you really trying to achieve as an organization and how is it meeting the goals you have? And a lot of times people don't think about that kind of thing. And I'm sure this has come up in other aspects and other interviews and throughout the book, is that the whole point of doing anything in a CMS project like this is to meet an organization's goals as a business. And a lot of times the things that they think they want don't really meet those goals and aren't worth really spending that much time on.

There's a line too where something ceases to become integration and becomes just a bespoke software project. And for me, this happened a lot with forms. I've written a lot about four builders and CMS and people think that four builders and CMS are magic because they can do amazing things with content. They can do the same things with forms. Forms are not content. They're very different. The concept of creating some interactive thing that people can enter data into and submit it is very different than just spinning stuff out on a page. Now, Drupal has a very, very competent web forms. Is that the name of the module?

Yeah.

I've worked with it and it's very, very nicely done. And I think one of the reasons why it's nicely done is because it's very, very I want to say rigid. And I don't mean rigid. It's actually quite powerful and flexible. But it actually forces you to display things a certain way. It's very opinionated. And I think when it comes to form builders, that's a strength to be very opinionated because people want to get all artistic with their forms and drag things around and everything. And first of all, that's a bad idea from a usability standpoint. Forms love rigidity and repetition. And second of all-

And predictability,

Right, predictability. It makes things very complicated. Where I would run into problems this where people would think, "Well, I've got a form builder. I'm going to use this to do line of business stuff." I had a bank who said, "Okay. We want to redo our mortgage application in the CMS's form builder." And the CMS had a very competent form builder, it was Episerver actually when I was working, Episerver. But that's to me that is inserting a CMS into something where it does not need to be inserted. That is a line of business application where it's just not something you need to do with a CMS. Did you find yourself delineating that and making clients understand that?

Oh yeah. And to me that becomes less about the form itself. It's about, what are you doing with the data afterwards? Because right now in this government client, they have things like the governor can take a request to appear in an event and they've got it done in the CMS form builder. But basically all it does is dump it into a spreadsheet, and then where are you? They want to be able to track the status of these things and who they've contacted and what the response was and how many they get per day and per week and per month and filter them based on all sorts of different things. And it's like now it's not about the form, it's about the application that surrounds the data that you take from the form.

At what point are we building some line of business tracking app?

Right. Exactly. I'm like there are lots of places out there that build systems to do this and we shouldn't be managing that information. And again, from a data security standpoint, now you've got personally identified information in your CMS, which takes it into a much different class of application to manage than anything else. The places where I'll tend to use CMS form builders are very simple things like event signups or signups for webinars or requests to get gated content and that sort of thing. But if you have to do anything even mildly fancy with that data after you're done with it, I don't think it makes a lot of sense because now you're just building an application to manage submitted form data in your CMS. And it's like the CMS to me at the end of the day is to display content to users and to push that content to users, to manage the content for users. And the stuff you do internally, there's other tools that are better suited to it.

I always felt with form builders, the best thing a CMS can do is hand the data off and get the hell out, right?

Yeah, exactly.

I think one of the most open-ended and powerful things a CMS can do with their form builder is just give you the opportunity to post the data somewhere. Just after they submit the form, chuck it at this URL and walk the hell away from it because-

That's really all that web form does.

Hopefully. There was a CMS I worked with years ago, another PHP CMS. It was called Easy Publish at the time. It's called Ibexa now. The way they actually handled form builders was interesting because when you submitted a form, you actually modeled the form as a content object, content type. When someone submitted a form, they created a content type. And so when the form was submitted, you actually had a content object sitting there. I felt like that's very elegant, right? That's very nice and elegant and congruent and everything. But that opens up a whole can of worms because now customers are like, "I got a content object, so I'm going to run this thing through workflow and I'm going to do this and I'm going to do that."

(26:32)
I love the elegance, the conceptual elegance of creating content objects. But I hate the implication that we're turning our system into a generic information management system and people are going to try to do things far more than they should. Workfront exists. These work management systems, they're a thing. And I just don't think we need to do that in the CMS. Drupal is well known as this massive, massive kind of integration platform. I always maintain that Drupal is nothing. Drupal by itself is like a blank slate. You immediately install Drupal and just start stacking up. In fact, I have no doubt that Lullabot has a canned Drupal distribution that they start with all the modules and everything that you-

We actually don't.

Really?

Yeah.

Okay.

And that's a whole nother topic that I have lots of rants about, but that's not the topic for this podcast. But if you wanted to talk about it, I'd be happy to.

Someday. Someday, Greg.

Someday, yes.

What I found with Drupal is you immediately start loading it up with modules and configuring and everything and it's this kind of blank slate that you can morph. It's like the question, what is Drupal? The answer is yes, right? Drupal is yes.

It's a content management framework, not a system based [inaudible 00:27:37].

Yes, that's fair to say. It's a content management framework. And so do you find yourself building bespoke applications inside that operate within the parameters of a Drupal installation? And I'll ask you to be vulnerable here, are there times where you thought you took that too far and you built something inside Drupal that was just way too much?

There are many clients who come to us wanting to do that. And I'm going to be honest here too. We will often be in sales calls with those clients and I'll tell them that they shouldn't be using Drupal, they should go do something else. And sometimes it's with clients who have already built systems. We had one client, actually, this feeds back into some of the talk that we were doing before, they basically had a Drupal install that was nothing but Drupal's theme layer, but all of the data existed in external APIs. And so they didn't actually store any information in Drupal at all. It was all outside. But it's like there are plenty of systems to build front ends for backend data. And the theming system, if we're all going to be perfectly honest, is not exactly the most pleasant part of Drupal. It didn't make any sense at all.

(28:56)
And what we de definitely see is a lot of customers who want to have a marketing site in Drupal, but have all of the rest of their business applications in Drupal as well. And it just doesn't make any sense. It's like, yes, we can do all of those things in Drupal and we can application-ize Drupal all we want to, but it's not what it's there for. It's not what its primary business purpose is. It's not its core functionality. And I advise clients against doing that all the time.

Let's talk about the absolute worst part of integrations. The worst part is bidding them because every customer comes to you and they want to connect their CMS system and they want to know exactly how much that's going to cost. After doing this for 15 years, I don't know if you agree with me here Greg, but that's just sucked. It was just very, very difficult because you may know Drupal really well, but you don't know this other crazy system they're talking about. How do you approach that from a scoping standpoint? How do you possibly put some kind of dollars around that? And I'm going to tell you from my experience, poorly is what we did. Very, very poorly. In fact, we would just pad the living hell out of those estimates because that's the only way you could protect yourself. And so tell me how Lullabot handles it.

I think that now we've gotten to a point where especially when we're faced with a particularly complex problem project that we know has a lot of integrations, we don't bid them. We tell them we won't bid them until we can do a discovery. And that discovery is usually four to six weeks. And it will often be, we see this and mostly this comes in projects where we're doing design, content strategy and development. And so it will involve all of the discovery phase. It'll involve stakeholder interviews, it'll involve onsite workshops from the design and strategy side, probably some basic upfront content or domain modeling to get an idea where we're going with their content, and also technical discovery where one of our architects goes in and just gets knee deep in their code and their systems with their IT people and stuff like that. And at the end, we've got a proposal. And if they want to take that proposal and go to somebody else, they are free to. This is their information to take and own.

(31:17)
And we don't really get involved in projects where we can't do that anymore, at least when it comes to large scale projects. And that's really the way that we've managed that going forward. It can be hard, especially when you're talking about large scale organizations that have to do things fixed bid. I think that state governments are a great example of that because they've got an RFP and they have to stick to a budget and that's all they're approved for. And in those cases, I think that what we usually look for is stakeholders who are very understanding of the complexities and willing to work with us on scope is what it comes down to. So we have to have a level of trust with those stakeholders that involves them acknowledging that if we hit a snag that we can't see front, then it could cost them some scope down the line and that there's going to be a level of working things out in compromise that will involve give on both sides.

(32:17)
And that's really one of the hardest things because as I'm sure you're both aware, most consulting arrangements are not designed from a place of trust. They're designed from a place of defense. And so putting yourself into that situation can be very hard. So we solved that by avoiding it as much as humanly possible. The place where we do get stuck is when we have clients, especially when the clients come from a business side and there's integrations that they don't know exist. And so a client comes up and says, "Oh, this is a very simple website," blah, blah, blah. And then when we get into it, we discover all sorts of stuff under the hood. There have definitely been times when there have been integrations in place that even their engineers had never known existed because they hadn't touched that part of the code in 10 years. It's just that data was there and nobody ever thought about it. And those are the situations where things can I'd say get dicier and trickier.

In a situation where you are scoping based on a perceived complexity, have there ever been any integrations that at surface look incredibly simple and then actually are very, very complex? And maybe it's a thing that clients come in and they keep asking, "This seems like it's easy. An RSS feed seems really easy." But actually when you dive into it's super, super complex. Do you have any examples of items like that?

I can think the ones that come to mind are things where they want to be able to do stuff with the data that the integration doesn't support or the way that they want to present the data doesn't match what the integration has. A simple example would be like we want to be able to search by zip code, but the address information coming from the integration is just one big text field. And so it seems like it should be very easy. The address information is in this external system, we just need to suck it in. But now we're in a situation where because it's just in a big text field and we don't have the zip codes separated out, we have to write code to separate out the address and break it up.

(34:28)
And that's one of the things that I spend a lot of time thinking about now as I'm more focused on content strategy than engineering is matching data models and integrations and client projects and finding places where they don't match and wondering how we're going to deal with those data disconnects or if we are going to deal with them in some cases. But that's the kind of thing where I can think of where it's like the client wants to do more than the integration supports and it seems like it should be so straightforward and it's not.

The point in which developers have been most mad at me is when I am proposing functionality within a map, when I'm like, "How does the zip code work? What do you do for mileage? What is the triangulation?" All these things. And I'm just like, "I don't know. They click on the current location and they get their communication." No, that's not how it works.

As a developer who has been frequently mad at Corey, I will concur that that's absolutely true.

Maps are so hard.

Maps and calendars, they're so much harder than they feel like they should be. Calendars are the worst.

Let me tell you what. Recurring events, that model-

It's a nightmare.

... can get sketchy really, really quickly. Someone comes to you and they want a calendar. So they want a calendar. So you put this together. And then they come back and they're like, "Why doesn't this work like Google Calendar?" "Because you didn't pay me 10 million to build it?"

Right, exactly, to develop Google. It's the same thing with search. We were doing a big thing for a book seller recently and they're like, "How come my search doesn't work like Amazon?" It's like, "Because Amazon has 15 million dollars engineers working on search 24 hours a day." Calendars is a great thing where one of the things we'll do upfront with clients if they want to do say event management in their CMS is get into the level of detail of what they want to do and what functionality they want. And there's definitely a line where when they say they want a certain amount of functionality, we say, "You should just put it in Google and we'll either display it or suck it in or Eventbrite or whatever," because there's a level where it just doesn't make any sense anymore.

I had a client tell me once that they wanted this to work exactly like Google Docs, their editing experience. I said, "You know what? There's three magic keystrokes to embed Google Docs. It's control A, control C, control B. You do those three keystrokes and you write Google Docs and just copy it all over to the CMS." I know a particular CMS, in fact it's Magnolia and Magnolia's a Java-based CMS out of Basel. And they actually took steps to make their UI as copy and paste-able as possible because they wanted to respect the fact that copy and paste, if you limit the ability to either paste information into your CMS or copy information out of your cms, that's kind of a crap move. You're kind of screwing over the editor because copy and paste is a thing. We all want to pretend that our CMS's do everything, but they don't. And I always maintain the mature way of looking at CMS integration is knowing when your CMS isn't the answer and knowing when to go around it.

Yeah. People don't think of workflow as an integration, but in a lot of ways it is because there are tools that do workflow really well. And as you're saying, there are lots of times where if clients really value realtime editing, realtime commenting and being able to pass a document back and forth between three different places so that people can have their eyes on it and make comments and make adjustments and stuff like that, I'll be like, "Then just keep using Google Docs and bring this stuff in when it's finished." There's no reason to be thinking about this stuff in the CMS." It introduces all sorts of complexities like, "Oh, this has to be approved by outside vendors. But the data's unpublished, so how do we get them a way to view it in the CMS?" It's like, "Just don't worry about it."

It's like, for what benefit? Right?

Right. Exactly. Exactly. It's like all of this time and engineering and all of this stuff just to do something that another tool does better. You're completely right about that. And that applies to CMSs and I would say many, many, many other aspects of application development in general.

Well, Corey, Greg used the magic phrase when speaking to me and that magic phrase was, "You're completely right." That, Corey, is where I believe we'd like to end this conversation.

Greg, you're still doing your podcast, right?

Yes. I have a podcast called This Must Be the Place. It's about community and community management. It still exists. I did about 15 episodes and then got tied into some other things, but I've recently been sort of rethinking doing another season as it were. And so I'm kind of in the process of thinking about that and putting that up. But I also have another project that I'm working on right now that's eating all of my time. I'm actually in the process of writing a book. I'm about ready almost for first draft status. It's about designing CMS authoring experiences. And so that's really been eating my life for the last four or five months. And so I'm hoping to have that done and then maybe early in the year kind of relaunch another set of episodes of the podcast. And you can find that at thismustbetheplacepodcast.com.

So you're learning what Deane and I learned, what Deane's learned four times now and I learned once, which is never write a book. It's impossible.

Oh yeah. It's funny, I read Lisa Maria Marquis's and Katel LeDû released that book, You Should Write a Book. And I read it and I came up to LMM. And I was like, "I wanted to read your book and read it and understand how hard a book was so it would convince me not to do it. It's like you're not supposed to make it look like a pleasant experience to write a book. You're lying to me. I know this isn't true. But I went and did it anyways, so here we are."

This Must Be the Place, a Talking Heads reference I assume.

Yes, absolutely. Yes. For a podcast about community, which for me is very much about finding your place in the world and feeling like you're at home, it seemed a very appropriate reference for one of the most lovely songs ever written in the history of music.

Yeah. Deane, Talking Heads are a band.

Yeah. This brings up, Corey sends out this newsletter and-

Oh yeah, I sent him an email yesterday about one of the bands in this newsletter already.

I know. He has a playlist. And I was so kind last episode of his newsletter to listen to every song in the playlist and respond with my thoughts. He was totally ungrateful.

Most of the thoughts were, "This song sucks. This song is dumb. I hate this song." Every one of them, with the exception of the Kendrick Lamar song. You're like, "Oh, I've heard of this guy. I like him.""

Corey has the weirdest things. And Greg, you're wearing it. No one can see you right now, but you're wearing a shirt, which I believe refers to another weird band that Corey likes.

Yes. Yes. I don't know if Corey likes them, but it is another band.

Also The National-

They're not particularly weird. No.

And they're also not that small or indie. They're like a pretty big band.

The only way I know The National is at one time they did do a collaboration with Taylor Swift, and I appreciate them for that.

Yeah, their guitarist Aaron Dessner did a lot of the work on lot of the work on folklore and evermore with Taylor. Yeah.

Yes. So for that, they're absolutely worthy. And yes, in case you guys were wondering, I did manage to get Taylor Swift tickets.

Wow.

You can exhale. You can exhale now.

That's all we got, Greg. We're going to stop right there before Deane says anything else that he will regret.

Okay. Thanks a lot for having me. This has been really fun.

All right. Thanks, Greg.

Thank you.

All right, Deane. We are back. Hi.

Greg and I need to go to therapy together. I

You're essentially the same person when it comes to discussing this topic.

That conversation was so incredibly validating because Greg suffers through all the same things I suffer through. Number one, making integrations work, which is hard. But number two, the kind of social dynamics of having to tell customers they're wrong and that they're doing something silly and they should not do this thing. That can get painful and awkward, and I'm just glad I'm not alone there and I'm glad other people have gone through that as well.

Yeah. I think the thing I got from Greg, and you always feel this when you're going through a project, but hearing story after story both from you, both from Greg, things that I remember going through is how much of the sort of integration process and determining what needs to happen and what should happen, it all seems to come from one question. And that question is, "Hey, wouldn't it be cool if..." And most of the time that answer is, "Well, yes. But it's not realistic." It would be cool. A lot of things would be cool, but that doesn't mean that it's an okay thing to do.

It also comes from people overreaching. You have organizations that want to pretend like everything lives in their website. They want to pretend like their website is this Swiss Army knife that does absolutely everything. And that can be done, but it's super expensive and super risky. And we talked with Greg about showing the seam. Everyone wants everything to be seamless. Seams sometimes aren't bad. Maybe just show the seam because it's about application of schedule and budget. And we talked earlier in the intro about the university that wanted to integrate the washing machine system, and this university is struggling with enrollment. Put your budget to the right things. Integrations are money and time sinks. They will suck up money and they will suck up time like a Hoover. Do I have to explain what a Hoover is, Corey?

No, I think that's... Of course, you're talking about former a President, Herbert Hoover.

See, I'm all freaked out in here. You didn't know who Kathleen Turner was so I feel like after explain Hoover. Integrations will suck up time and budget like a Hoover, and you only have limited budget. Put it where it's actually going to help your organization move forward. And knowing which washers are available, that ain't it.

All right, that's our show. Thanks to our guest, Greg Dunlap from Lullabot. You can check out Greg's podcast, This Must Be the Place. We'll put that in the notes. Also, he is writing a book. And when we get more details on that, we will let you know because it sounds great. The Web Project Guide is a product of Blend Interactive. We are a web strategy design and development firm that builds websites and guides teams through complicated web and content problems, everything from content strategy to implementation and support. We're dedicated to making great things for the web and this podcast is one of those things. This is also episode 14 of the Web Project Guide. We are now officially way over halfway. And this corresponds to chapter 14 of the book, Know Your Integrations. You can read the full text of this chapter at web project.guide/integrations.

(45:28)
Besides being a wonderful person, Greg was also one of the first people who reached out to us during the writing of the original web version of the Web Project Guide. And Greg's email was a great little boost of momentum when the project felt really, really, really big, and so I appreciate him for that. Back then it was only web, but now you have two choices when it comes to reading the book, one of which is getting your own beautiful copy of the book at order.webproject.guide, order.webproject.guide, which is an easy URL, but it's hard to say every time. Also, if you are feeling inspired or if you just want to say like, "Hey, keep doing what you're doing," give us a like, five star review right from your Spotify player or Apple Podcast player. And if this is your first episode, feel free to subscribe. We do this every month. And in fact, the next two months are going to focus on what you need to know to select a content management system. Deane, have you ever gone through that process?

Selecting a content management system?

Yeah.

No, know nothing about it.

You know anyone we can talk to about it? We get this question all the time. Deane, literally this is his job. So anyway, thanks for joining us for another month. Subscribe, share, check us out next month when we talk about CMS stuff. And until then, go do amazing things.

Good luck.