Wrapping Up

[00:00:00]
>> Scott Moss: There are some more advanced use cases for sure, but they start to lean into CMS specific stuff. And I just didn't wanna get into that because there isn't a standard. At one point, we were trying to make a standard of, here's what all the data should look like from every headless CMS.

[00:00:16]
And we went around to every headless CMS covers let's make it standard. Nobody wanted to do it. They just wanted to do it their own way. And I was, no, we should make a standard. So if someone wants to turn off your site and go to another site, they could bring their data with them.

[00:00:27]
And that was the thing they didn't wanna do. They wanted to get keep. So I thought that was great. We all could have benefited from it. So there isn't a standard on what this should look like. Everyone has their own opinions. So, I try to be non-biased whenever.

[00:00:40]
When I have to use products with the courses that I teach, but for the most part, the advanced use cases are very platform specific. But what I showed you today is 80% of what a headless CMS is and how it works. And there really isn't much more to it than that.

[00:00:53]
So I covered those things. If there's any questions about headless CMS, next JS or really anything related to adjacent to any of that. I'm here for it.
>> Speaker 2: Scott.
>> Scott Moss: Yes.
>> Speaker 2: Pretty broad question.
>> Scott Moss: It's toxin really interesting because it seems CMS is largely also a structural or team dependent kind of problem.

[00:01:19]
>> Speaker 2: Yes. In your experience, what are some good rules of thumb they kinda follow when kind of configuring what the content team has access to versus the developers. And I know this is probably really dependent on how technical the content team is and stuff like that. But are there kind of things that in your experience are good practices to follow more generally?

[00:01:42]
>> Scott Moss: Yes, if your CMS has roles, enable the roles. Do not let the content people mess with the models. Your app's gonna break. If you let the mess with the models is broken coz you are banking on the fact that the concept's gonna come back in this shape.

[00:01:58]
Your code is not, we didn't put no checks to make sure that field was available or not, because obviously GraphQL would have thrown an error if it wasn't. But so don't let constant people touch the models at all, which is why a lot of the open source CMSs, you write the model in the code now.

[00:02:14]
It's a JSON file, so they can't touch it. When we built our CMS, that's what we did. I think if you're one of the first ones that did that, we're, no, take it out, write the model as just pure JSON, and then we'd interpret that. We basically took a model a JSON file and turned that into an app.

[00:02:30]
So you give us a JSON schema, we turn that into a full blown app for your content team, right? So don't do that. The second thing is,
>> Scott Moss: From my experience being an engineer developing a content model for a content team is being a founder trying to find product market fit.

[00:02:50]
If you are sick and tired of managing concepts engineering, you really wanna empower your content team. You're gonna have to act like a founder and sit down with your content team and go and watch them use it. And see what they struggle on and see how you can improve the schema, how you can improve the model, maybe change this field UI, maybe change the name of this label.

[00:03:10]
You really got to figure out why is this really hard for them. Why don't they use it, why are they still slacking me to do this thing when I already showed them how to do the thing and it's you just got to sit down and watch them, just like a founder would.

[00:03:21]
Eventually you'll figure out what's the root issue, and you will eventually hit this road where you have to sacrifice what is best for your app, for what's best for the content team, and just go make it work for the content team. You can write code for it. Just write the code you got to fix it.

[00:03:39]
Just make them happy coz at the end of the day, it's gonna make you happy because for the most part, they'll just keep contacting you. They'll just keep hitting you, hey, can you do the thing? And you're, my God, okay? And it's nobody's fault, but yours, because you didn't sit down to kinda figure out what it is that they need.

[00:03:55]
And that's just kinda the unfortunate thing, honestly. It's really tough because it's just a headless CMS has to be integrated by a developer, but it's mostly used by someone who didn't do the integration. So those two people have to communicate at some point, there has to be some communication there, unless you have a growth engineer who sits on the marketing team and also sits on the engineering team.

[00:04:18]
And they're the liaison between two groups and they can kind of just do everything. You need some type of communication, some planning and coordination there. So I would say that. And then lastly, start slow. Don't go in and just I know exactly how to make all the schemas for everything.

[00:04:38]
And I'm just gonna go in and do everything no do what we just did. Pick one title, pick one thing. Make that dynamic. Give it to someone like cool, you can change that thing now, just that one thing you can change it, let them warm up to that.

[00:04:52]
And then go out another thing and then add another thing and add another thing is slowly you start to do that way they're learning they're getting used to it. At the same time, you don't have to just do all the stuff up front, right? And you can kinda go as you please.

[00:05:03]
So I would just adopt it that way. It's a lot slower, but I think it leads to higher, it just makes it more sticky. I think people stick with the product a lot more when they adopt it that way, whereas if you get these weird signals where someone will dial the CMS engineer super excited about it.

[00:05:23]
And it looks like a good signal and they just built integration super quick. But then it hurts the content team coz they did so much. The company was overwhelmed with everything that the engineers did. Whereas the inverse is true, it's the engineers taking their time they only added one field, they only do this one thing.

[00:05:39]
But that one feels getting changed 10 times a week, coz it kinda seems it's so easy for them. So [LAUGH] it's so weird these are the things that I observed. So those are some of the tips.
>> Speaker 2: Gotcha. Thank you, Gamify the content editors journey. They get it achievements along the way.

[00:05:59]
>> Scott Moss: [LAUGH].
>> Speaker 2: That's [LAUGH].
>> Scott Moss: Yeah, [LAUGH] Pretty much. Well, I think that's it. Wanna appreciate everybody for coming. This course was super fun. It was kinda nostalgic just walking down this path again, seeing how [LAUGH] deep and dedicated I was for, have the CMS for about four years of my life.

[00:06:16]
So, it felt kind of fun. So thanks for entertaining me, and I hope you guys got some value from this.
>> [APPLAUSE]