ScreamingBox Technology & Business Rundown

SPEAKERS
Siman Svale Skodsrud (Sanity.io), Dave Erickson (ScreamingBox), Botond Seres (ScreamingBox)

Dave Erickson 00:32
Welcome to the ScreamingBox technology and business rundown podcast. For this month's podcast we're going to explore headless CMS. No, this is not a new genre of horror video games. Headless CMS is a content management system that is the backend of your website. And that is front end independent and provides content over an API. For this podcast, we are honored to have Simon from Sanity IO. He is the CTO and co-founder of the company, which is one of the larger headless CMS platforms. With an extensive background in product design, software architecture, and broad spectrum tinkering. Simon has all the right experience to co-found a headless CMS platform. So Simon, of all the products you could have developed, why did you start a headless CMS platform?

Siman Svale Skodsrud 01:24
We didn't actually want to. We had no desire to have a tech startup at all. We had a really great digital agency in Norway and we had just had an international breakthrough. Working for Dream clients like MIT, The OMA, just fantastic architects international architectural agency, Diller Scofidio in New York,we had fantastic customers and for these customers, we hadn't worked with really content intensive projects for a long time. We did very bespoke innovation work for media companies and stuff like that. But now we were kind of back in that world where you need to create a lot of content, you need to give people tools to create content and we wanted to, as an agency, to be able to really invest in that editorial experience. And then we wanted to be able to reuse that content. For example, for The OMA, we wanted to create a website, but we also wanted to create internal business development tools. We knew they were creating a lot of books so we wanted to have a design system that basically can extract books from that same content. And at that time, we just expected because it had been a number of years since we last looked at WordPress and Drupal type and all these systems. And we were kind of expecting them to, of course, have evolved, the way a lot of enterprise software had evolved, like being careful with separating presentation from data modeling, from business logic, we have cleaned up a lot of stuff in in the software stack during those years moving to micro services and stuff like that. So we just expected at that time, that any content system will on one hand, let you really customize the authoring experience like you can with WordPress, but still have the content stored in a post backend as a software as a service, just handled by someone else and that system be a proper database, not some pared down Content API, but a proper solid database that you can integrate into your enterprise. That's what we just expected to exist. And to be very honest, this is admitting to some recklessness, we just expected so much we actually sold and priced the job; the first one before we had checked. And then we basically had to admit some of the in kind of anger and frustration; we did that. We kept working with that kind of internal tool for a number of projects and then some of our customers started saying, you know, this system you're using, what is it? We can't buy it, it's so good. And then we realize we just need to invert our business model and become the company that makes that system. But that's kind of touching on some of the or the kind of needs this is handling for us. So this is us, basically just needing that thing to exist.

Dave Erickson 04:15
Okay, well, the best business models are usually, that you are trying to solve a need that you are experiencing in whatever you're trying to do. So that is actually a very solid background for business and congratulations on succeeding in at least getting it to a level where it is now a viable business. You're solving a basic business problem that you internally were having, but then you had to switch your thinking to, What are the other problems that a person who's using a headless CMS system might encounter? How did you go about trying to figure out how to craft the product and add feature sets that go outside of your basic experience from the platforms that you’re using and the projects you are developing.

Siman Svale Skodsrud 05:04
So we as an agency, I mean, you get this kind of the fantastic thing about being an agency, you get this kind of you get to to, it's almost like a safari, you just move into these companies, you drop in, you solve some problems, you really get to see the kind of business from their perspective. I have this kind of active Stockholm Syndrome, when I'm working as a consultant, where I just kind of become my customer. I see the world through their eyes and I just make their desires and pain my own. So we have done that a lot. So I've seen the world from the media company's perspectives in everything that we try to do for them, but we couldn't do it because of limitations in the CMS. We'd work with a marketing organization realizing this is so hard, like you need to move, you really, really need to move fast, you need to want to get things out quickly. But then, in the past, when we worked with television or paper, you just made a new campaign, you just went and did it. But with digital, you have to order a new kind of, ugh, developers have to work for months with this new feature. I just wanted that new campaign to sell my GPS watches and we were kind of feeling that pain from their perspective. So we, one of the things that we knew about was this kind of these, we kept meeting the CMS, something that stopped us from doing the things we wanted for our customers, it was always like, Oh, no, we can't add a workflow to this, it's just impossible. Or, you know, the CMS, when a journalist is in a story, it's locked. So your life or your automated systems for updating things will not work, because sometimes the story is locked. And we were like, This is so funny, so terrifyingly annoying. So when we made Sanity, we just made a list of all of these things that had infuriated us in the past. It was about being able to control the editorial experience by making sure you can add workflows that are not necessarily always about the content. It could be about something related to it, but you just want it there at the same place. Because it matters how many places an editor will have to go. It was also about being able to integrate with other systems, we felt that a lot of CMS believe themselves to be the business. And very often you're not a content company, you are a bank, and your CMS is handling content inside your banking system. We felt that our systems should be one that really meshed with the other systems in your stack. So these are things that we, so we basically used our empathy from being a frustrated Innovation agency, and just put all of that into the product.

Dave Erickson 07:38
There are a lot of headless CMS platforms out now. I don't know how much a lot is, but when doing the research, there's definitely a bunch of different headless CMS platforms. If you're a product owner, or a lead tech, lead developer, and you're looking at what headless CMS systems I'm going to focus on, you're an agency and you want to have your developers use headless CMS in projects. How do you go about evaluating the different headless systems? Why are they different? What are the differences? And maybe you can talk a little bit about why Sanity is different from the rest of them.

Siman Svale Skodsrud 08:23
Hmm, yeah, because I'll be totally unbiased right? Now. I think that

Dave Erickson 08:28
Exactly.

Siman Svale Skodsrud 08:30
No, but I think when in one sense, I'm very unbiased, because some of these exist because we saw these pains. It's not like we made the system and tried to find a customer base for it. So in one sense, what we were looking for was what was important to us. And I think what you should be asking if you're trying to solve a content problem right now is like, how fast can I get to value with each of these systems and then, that should be of course the court. How fast can I deliver the value I need, with the team I have or with the minimal addition of a team. So I’m back to my total cost of ownership to the point where I'm starting to do the thing I'm trying to do. And then I think, you should do a little bit of role playing yourself and imagine like, what are some of the things I'm going to be needing later, because even if you're totally pragmatic, totally tactical, there is a strategic element to your chance. I think, one of the things I've always been preoccupied with as an engineer with part of my mindset is that engineering is a lot about preserving opportunity. We need to have a system where we can capture opportunity when we realize what it is that flexibility needs to be part of our thinking, I need to be able to pounce on an opportunity. And that's an engineering job insensitive to be to keep that ability in the systems. And that's where I feel that the lesson itself as an approach is very strong. But that's also why I would kind of work with my mind about the product people or if I am the product person; I would go into that place in my mind like that? What are some of the things we might be wanting to do later and then role play or play act with? We even prototype something to figure out how hard would this be to do with these different systems that we are considering? Because I think that is the big differentiator. And that's when you see like, yes, a lot of, Squarespace would beat most systems in terms of tactical ability, like getting to be able to start selling your wares. Like, with just a landing page. Maybe Squarespace or Wix would just always win, but it's the reason that we don't use those. And I feel like, yeah, that should be their mindset, the cost of getting to value and then the cost of staying responsive to opportunity.

Dave Erickson 10:50
Philosophically, how are you building Sanity? It seems like efficiency is a core value of that process of developing the product. Is that correct?

Siman Svale Skodsrud 11:00
Yeah, I would say we have a kind of word we are trying out a little bit. We call it content philosophy and he kind of captures that; it's kind of like, from the moment you know about something, you know what the problem, an opportunity or a challenge to you're able to respond to that in terms of your content. That's your content philosophy. And that might be in, just your CMS, like you see your CMS setup to respond to this new signal in the market, like all your sandwiches are sold out across all of North America. How do you respond to that? Can you put that content out? Can you get to social, can you get to your front pages immediately? And then if you, if you're kind of productive, discover new opportunities, like oh, if we had celebrity endorsements on in our big box, ecommerce store, that would really work. We tested it, once it works, how fast can we solve that like this, like for real added to our content systems into our content and get it out? And then when it doesn't work how we expected? How fast can we iterate on that? That kind of philosophy, I guess that translates to that notion of the efficiency you're talking about, and it's definitely something one of our first post-it-notes, when we started framing, was just like getting to value in seconds and then it would make sense to keep investing.

Dave Erickson 12:13
I think one of the things that you touched on that was actually kind of interesting was about workflows, about content workflows, we build a lot of websites for clients and, you know, they just assume that the back end of the website is just kind of handling whatever content they have in their mind. Sometimes we have to actually work with them to try to draw them out as to what type of content you really want to provide, what type of content are you really going to be doing on the website, most people stick with a standard format of blogs or blog posts, but now blog posts are getting quite complicated, including video and other mediums and then they want to share it to all the different social media sites. So when they put it on the website, it has to be able to integrate with everything else and push it all out and it's almost becoming a multi-platform content system versus a content system for just managing content on a website. I assume when you were putting together Sanity, you were running into the same issues with workflow. Maybe you can talk a little bit about how you built into Sanity, the ability to utilize these workflows and to push content out to other areas besides just the website.

Siman Svale Skodsrud 13:34
Yeah, that's a great point. Like, that's one of the, like I said, one of the first customers that we worked for were having to support both websites. Internal business, but also paper books, which is very, very different from video, you can't have links. Your locations need to be rendered as images of maps and stuff like that. So it's a, so what we are thinking was, the CMS should be for like an editor, it should appear as something so totally obvious, like it should just be. It should just be a very helpful, intuitive way of creating content. You shouldn't know that you are creating structured content, that shouldn't be any of your like, you should be concerned with that fact, but the way we designed it behind the scenes is that when you then have for example, let's say you have a blog post or a text and let's say you're running a set of resorts and you're having trouble tips for like an island in Greece or something and your texts are full of locations, they're mentioning locations. So in a traditional CMS, you would add images of maps, and you draw on them and if you're kind of clever, you'd add URLs to Google Maps or something so people can link them to their maps. In Sanity, which had like, actually, it's important that text and data are the same kind of thing. You should be able to say a text is the number of paragraphs but also it can have locations and those locations are actually structured data like, you know, as a developer, you know,paragraph, okay, location. And now I can react to that, I can decide, Okay, I want to render a map, I want to use map box, this beautiful style, I'll render this marker and then later someone figures out in the product team, that people aren't actually looking for these by resort, they are looking for them by area of like this island. So you want to put all of them on a map. And now, because you structured that content, that team can, without redoing any content, without talking to anyone creating a new API or anything, you can just do a new query, extract all those locations and we have a map of those same stories. And this is kind of what we were going for, we want to because this cross media thing that you're talking about that yes, pushing things to all the different mediums, is the same thing. It's the same problem as using your content in new contexts, even on the same site, it's not that valuable. You get it even when you're just using your existing content in a new way on your existing site and also in a different situation. When you read user content is when you redesign your site. If your content actually prints like design in a structured way, the way we define this is structured competency; you know what each piece of content means, like this has a semi clear semantics, as you would say technically, now your designers can create rules. And then your content creators can work with a boring idea about how it looks. And you can reuse the content. And one of those things can be your redesign or your iteration and not having to go back. Actually, the book came up later in that project; it was a late addition. We did that without changing our content model at all. We had everything we needed. We just worked with a design agency, creating design rules for that book, and it was done. And now the team creating the content, their output is multiplied by this ability to extract that work in several different ways. But they are doing the same work with just a better tool. So workflows are like one thing is kind of putting content in structured content being principled. And you can kind of have like, we call it like content responsive design. That's one aspect of that. The other side of it is like being able to integrate workflows from other systems that are not adjacent to what you are making. So one of the things we discovered with this first product was that on Instagram, they were actually taking beautiful pictures of those buildings everyday, because they are building these fantastic kinds of monumental buildings all over the world. And the best picture in actually all those buildings are not of the building. It's like someone taking a picture of their girlfriend in front of that building. It's much better after that. And then we already had all of the locations of the buildings because it was structured content. And then my co-founder, Evan, discovered that Instagram had a search API. And we knew that if we just did this, like in the past with other systems, we wouldn't have to build a separate system for this. But with Sanity, we could just just build that Instagram curation ability just into the CMS. So, when people were driving by to do their regular job, we would remind them, there're 700 new Instagram pictures. We can just curate it for them or just score them quickly. And by doing that, we would just have hundreds of great new Instagram pictures in that fight every day. So we have a different customer that is doing Bike Share. And this is an example of that, where the workflow of managing Bike Share logistics is not related to the content specifically. The company is not about contacting customers, but of course, it's important to them. Using Sanity, they were able to stitch together the workflows that are about the bikes and the workflow that's about the content. And day to day, people working with that, don't have to think so much about the distinction; am I going to the content system, am I going to do the resisting system, it’s the same system.

Dave Erickson 18:53
If you're talking about a headless CMS, you're obviously talking about a CMS system that is different from what we would call the normal CMS system. Most people, I think, experienced a CMS system usually as the back end of WordPress, that's probably one of the most common CMS systems. But I know there's a lot of CMS systems and there's a lot of enterprise level CMS systems as well. Maybe you can talk a little bit about what is the difference between this kind of standard view of a CMS and how is headless CMS different and maybe what are the advantages and disadvantages of both?

Siman Svale Skodsrud 19:37
Hmm. So I would say straight up the only reason you wouldn't use a headless CMS would be the simplicity of having everything run together as one thing, like setting up one piece of software, it having both a rendering engine and an editing system in the same thing. It's very simple, at least the first few hours and maybe the first day or so. It takes a little bit of time to pay back. So I think why a lot of JavaScript developers immediately go for a headless CMS is because the front end technologies really evolve really fast. And you want to, you want to really explore that when you want to reap that benefit. And if you had that kind of tied to a CMS, there's no way that CMS can move fast enough for that, like, you just want to be able to pick the technology that's appropriate for you, and connect that to your content and that's just being a separate thing. So that's driving this a lot initially. That kind of having it be several channels and stuff kind of is the unbox that comes later. And so I think that that level of simplicity is the most important one benefit from it.

Dave Erickson 21:02
So in a business sense, there's almost two levels of prospective users, you have these users, which is basically a very small business startup, one person operations, they want to put up a website, they'll go to WordPress, because it's all kind of one package and they don't really have to learn a lot, except maybe find a theme and run a back end. But then you have the other client, which is somebody who is really developing websites, either as an agency, as an independent person, or as a business person says, I have time to learn how to do front end and learn how to use a headless CMS system. And then obviously, you have agencies and businesses, that also, if they had to pick one, they would probably go for headless because it allows for a speed of development and I guess more of an advanced feature set, is that correct?

Siman Svale Skodsrud 21:58
Yeah, I would say, one of the things that stuck with us in our education and outreach work. This is what we see a lot like expectation, it's kind of driven a lot by luck. I think the key word is what you're familiar with, like you, there is a level, of course, of investment that is not just learning a new system, it's an investment. Let's say given that people have the same level of familiarity, then what would be the benefit? And what then? Why would you choose a more traditional, what we would call a monolithic, a singular system? That's where it becomes more and more tricky. My personal view from having used both and, in anger, creating Sanity was that the time to trouble with a monolithic system is very short. It feels like it's tactically beneficial, but actually, that's what you often see in situations where we're certain people think this is a very simple problem. Very often, developers and designers know, but no, it's not going to be. In two weeks, you will ask us to do something non trivial and since we will be picking the system, we will be in trouble. So I'm thinking that that's why I would say, given that you had a knowledge like the one that you didn't have to invest, that learning is always the right choice to go with a headless system. And I think in the near future, you will be the only thing people will be moving to. But right now, like you said, the investment in knowledge for example, is huge. And, and then that kind of should add some nuance to that picture to when to kind of invest

Dave Erickson 23:51
For people who are not necessarily developers, but are more business people trying to make a decision as to what type of website they want, what type of back end they want, what do they want it to look like and feel like how do they want to work with it? What are their workflows? They have to make a decision? I want my developers to make a website in WordPress, I want my developers to make a website with headless CMS for headless CMS. What are the constraints? What are the pairings with front ends that are most optimal? Is there an optimal pairing between headless CMS and say, is it better to work with Java? Is it better to work with React? What can it interface with? What can the API most pair with best or communicate to transfer the data between? How would you talk to a business person saying, Tell me about how I would instruct my developers to work with headless CMS CMS?

Siman Svale Skodsrud 24:55
So at this time, if this is as a new project, I would be sure to have a really, really great reason to not copy JavaScript on the front end. It's something about the fact that it can run the same code can be partially run locally in the browser, it just makes a lot of sense. So the way we think at least now and back also, in the agency days, there's any code that ends up running some, like interacting with the browser, that's JavaScript in our books, always, even though below for example, go and rest for other systems. Like if it renders, to the, browser, JavaScript, now you can pick and choose, when we're very often, with great frameworks, like, like Gatsby, or Next JS you can even it can even be transparent to the developer, I can have code like first one on the server, and then later, someone interacts with the site that some of that code can run in the browser, I don't even have to kind of think about that a lot, as a developer, so. So I would say like, that's like not today, that would be an interesting decision. You have some systems like Hugo, for example, being able to do static renders really fast. If that's very important, that's something to consider feeding data into these systems. I think that Hugo often expects Yamo and Markdown. Sanity, for example, and I'm sure other systems, can easily deliver that as another one of their outputs. More traditionally, JSON based stuff really works, of course, about well with basically anything, but especially when with JavaScript. And then I would say, as someone who really loves these kinds of, let's call it, I think to me, business optimal solutions, they are able to be tactical; when I start off, I should be able to get to value really quickly and then since you think it's a four week project, but actually, it's a life, it has a life cycle, it always ends up having that. So one of the design kind of goals we had for Sanity was that it should be incredibly fast to get up and running. And then you should be, it should pay off to keep investing in it. It shouldn't be like, You shouldn't be punished for that simplicity. And I think that's sort of the ethos in this space. With Windows, also the proton frameworks are alike; it should be incredibly quick to do the common things. And then when you want to do the advanced stuff, it should be possible and reasonable. And that's where I feel very often with monolithic systems, you can do everything but you shouldn't, because you are going to be hacking into those systems, and it's painful. And when you need to upgrade, you're going to be paying all that once more. It's my experience.

Botond Seres 27:57
What I'm really interested in is how we can set up the data structures, and how granular we can get, because one thing I usually tend to recommend is we deal with connections, or relationships in SQL with an ID based vibe, essentially. And for everything else, we can just go to no SQL, MongoDB or Couchbase, or whatever else really. And from what I'm hearing, it feels like headless CMS tends to focus on the no SQL side of things, and kind of a looser model definition. I'm not sure if I got that correctly. But

Siman Svale Skodsrud 28:44
no, it's a great question. I think that's where we were. We also decided very early to, that's one of the motivating factors, I felt that a lot of headless SEO, like the early days, and the CMS had a lot of strict limitations. So what kind of data structures could you design, and as a developer, it was frustrating at first like, now, I have to design my system, so that it fits with their ideal of how data should be modeled. And my editors have fit their idea of how context will edit. I feel like that should be a freedom we should have. We should be the people who connect those editors to the data structures, and those data structures should be the way I designed them. So one of the criteria was, you should be able to design any reasonable JSON structure, should be able to be expressed and have a kind of an intuitive user interface. Another thing that you're touching upon is this kind of theory in your data, and that's another thing that we really wanted. We wanted the backend, the content backend to be a database, not Content API. So that's why we designed a query language called Grok, which is basically SQL for JSON. It's a query language, having the same kinds of capabilities as SQL. But JSON has SQL for tables. And SQL in JSON, it's more tree shaped. So Grok is SQL for tree shaped data structures. And like you say,

Botond Seres 30:29
You just blew my mind. So you built a query language that has the same or with very similar capabilities as SQL, but for data that is stored in JSON structures.

Siman Svale Skodsrud 30:44
Yes, and all this is open source. So you can download the Groq data.

Botond Seres 30:47
Wow. That's amazing.

Siman Svale Skodsrud 30:49
And our back end, of course, it's able to run this at scale. And the point being, I designed all these data structures the way I like them and then using Groq, my front end can go and basically provide the recipe like, give me the story that I'm looking for the facts, the text, the title, the main image, and the author is but only the names and images from the authors and the buyer or the main author, and then also take this feature stories and just fetch the names of those so you can have this really complicated kind of recipe. This becomes one request to the backend, it gets cached as one time, so it will, but for most users, it will take like a millisecond to serve and will be stored locally for you. So we did all this to make sure you can just design this for the developers. It should be natural and the way you want to think for their content editor, it should be natural the way they want to think. And then actually, one thing we discovered that was not by design, this was something we discovered when we started doing it this way. We were hashing out content models with Sanity, or I guess other systems as well, it's very easy and customers struggle to think about content models in the abstract, but when they can sit there with you, with the CMS in front of them, and you say, oh, yeah, it needs an image we should have some tags, maybe some taxonomy, and you can kind of help them in real time. Just these things now so that the conversation, like you said, is about what content do we need to have. What happens then is this unlocks this kind of complete, kind of parallel workflow, because in the past, very often you worked with the designs and that's where the requirements come from. That's what people can reason about. And you backtrack from there, you design the content model, and then you create the content, very often the product is delayed because the content is coming last. When we do it this way, suddenly, the designers, developers, and the content creators can just work in parallel and everyone's work gets ready in parallel. Then content informs design, design informs code and all of this informs the evolution of the content model, which to me was like completely new. And it kind of blew my mind when I realized our third customer worked for two years before we started coding the site. They just worked on putting in the content; it was a huge job, but we just set up the control system first and then we went and did all of the work. Then when they were like 50% done, we started coding up something and started looking at how it would end up looking.

Dave Erickson 33:23
Actually the next podcast that we are recording, and I don't know if I'll release it before this one or after this one, is actually on content modeling, which I think is a really important subject. Because if you know the content, if headless CMS is the bowl, then content is the soup. And they kind of have to work together so that they have a dependent relationship with each other. And so the content has to be put together and modeled in a way that fits whatever the application is in the mechanism for distribution, which is what headless CMS, in a sense, is, how critical is the content modeling to what extreme should somebody go? Or does Sanity have tools to help people with content modeling or is that something you're thinking of in the future?

Siman Svale Skodsrud 34:20
So I don't know if you talked to her, but Carrie Hain, she wrote, “Designing connected content”, she's our Head of Content Strategy relations. And that's how we protect the sisters. We really are building a department of people just working with content creators, product owners, and educating them about how to do it and the importance and the values that it unlocks. Like our tooling, the strongest part of this with Sanity is that you can see it changed, you can edit the code underlying the kind of editing experience and in real time, immediately the studio reloads; you will see the CMS added as it evolves. So we've talked to a lot of developers who basically sit down with the customers and just do this in real time on a zoom call, or in the same room with a projector in the olden days and that's really what makes this really powerful. It really helps bring people together. We are very much like a content model first philosophy, what we mean by that is that is the thing that ties all the stakeholders together, the product owners, the designers, the developers, and the content creators, that's the kind of hub that brings this group together. When you unlock that single piece of information, everyone is free to create value. So in a sense, by figuring that out early, it makes everyone equal. If you say content first, which is another way of saying this, now suddenly everyone has to wait for the company. By doing a content poll first, everyone can start moving.

Botond Seres 36:11
What is traditionally very painful development activities is updating our content model. So right, we have a very rigid, very set in stone SQL model and every time we want to add a column, or a table or anything, it's a difficult and rigorous process. So I was one… and it comes with its caveats. Right? My favorite one being is how do you handle data that is now required, but was not required in the past? What is the default value? Or what if we changed the other way? Like it was required, but now it's
nullable? How do we handle that, or so how does that go?l

Siman Svale Skodsrud 36:57
It's a great point. So what was the abstraction, the mental model that you have when using the Sanity database, is that is a collection of JSON documents, it's just a list of JSON documents, like, of course, under the hood, it's like some complicated index and lots of stuff. But that's how you can think about it. So when you add a new data type, you can say, you will just proclaim it to exist and nothing, none of the data will actually change. You just say, now, when you create a document, this thing exists. You can say, for any new value like this, it has this specific value, let's say, like I'm creating, I have a list of products, and we didn't have categories for them, because in the past, we had just five products but now we need some category definition. So we'll say, all our products used to be the category default. But then, and then under ads, as we go. And then what you can do is you say, I’ll add this new thing, and then I'll say, there are seven categories, and the default will be that it's, it's a candidate, because 90% of these candidates will be my initial value, as we say, your front end will have to make its own definition. So we'll say, if there is a missing value, this is the devalue I will go by so I will know that the value is missing, I will decide myself what it should be, if you act so. So are these like you should be able to, you need to write code that's able to handle this missing information because it used to be missing. So what you do is you basically write your…you evolve from 10 to now also be able to handle that there might be a category and then you add the categories to the product. And now the front end reacts.

Botond Seres 39:00
Do you have any interesting insight into data type changes? So let's say you save a field that was a string, but now I decided that I want to have it this Boolean, or, you know, decimal, whatever.

Siman Svale Skodsrud 39:12
Yeah, no, this is, uh, this is? Yeah. So what some more customers do and what we want to build into the platform going forward is having an API in front. What we actually want to be doing is to have a, have you define Graph QL APIs that are specific to your front end in terms of Grok like our internal query language, because now you can then get an even version of those. So let's say you have a series of books, and in the beginning you did the typical mistake of having books having one author so not all your books, the other 700 books and then they realize they are compilations and there are others things like you have several authors, but you already have seven different fandoms out there in the world. They might even be installed on people's devices. So you might not even control when they are updated. So our idea is you create a new API, it will have authors, it will look at the data, if there is a single author, it will just wrap it in an array. If it is updated, it will serve the array as what's there. So basically, that API abstraction will just do the migration for you on the fly. And some of our customers who are like in E-commerce and stuff like that, who like really have loads of different front ends, they do that they have their own kind of abstraction in front of between the our API's, and we want to build that actually into the platform as a feature, because I agree, having a controlled API, and the strongly typed API, even if the backend is kind of malleable and quick to change. It's very loving.

Dave Erickson 40:50
You're talking a lot about APIs. You know, when did you decide with Sanity; it will be API first versus say being git based? Was there a conscious decision on this or from the very beginning were you just focused on API?

Siman Svale Skodsrud 41:06
Yeah, no, that would… We felt like we were doing the same thing as I think people were getting into going towards headless. We were doing Yamo and Markdown in Git as our CMS for forever. And as long as your users are developers, that's awesome; there's nothing better than that. If you're having technical people do all the work, they're not afraid of touching, get them! Who understands why you can break the entire build by just changing a single letter in the analytics side. This is not something you want to give to the kind of people who aren't technical and even myself, when I'm not in my technical mode, I just want to get this story out, please leave me alone. So that was the first thing. Then you could have, you could say, you can build it on top of Git still, that next thing is like, we don't think that people should be dealing with merges. On a normal day of operation, you shouldn't be making a version and then submitting that. We wanted people to see the same picture. So the way something works is you have a draft and that's real time sync, anyone looking at that draft will see the exact same piece of content. And when actually, we have built, oh boy I am going to blow your mind again Botond, we have built a gif style system for distribution control. So as you type in the things, you create super small commits, sent in real time, these are distributed to everyone. If you do something, and someone else touches up, during the time that it took going back and forth to the server, we actually rebase that content inside your browser to see what other editor did before you. No one reacts to this because the people just think the kind of latencies are super low. But it's actually like often a second, if you're in Australia, you don't notice that this is all based on… we saw this presentation on like how to do real time fighting games over the network, what they would look if someone actually clicked the button in the past, they will go back, rewind to that frame, replay the game play five new frames, but we weren't doing that. So actually, we went for a style thing. We wanted to be completely real time because we don't want people to deal with merges. So…

Botond Seres 43:25
If you're doing it right, you usually don't have to deal with merges at all. So as you said, it's really based always to be somebody,

Siman Svale Skodsrud 43:33
Let's say, because very often, if you're developers, you very often have divided up the tasks so that you are working on different parts of the product, like merges are often clean, like jagged match different files. And if you didn't touch the same file, it's very often very trivial. In content, it's often the opposite way because we're doing a product release, the whole team is basically working on the same three documents for like a week. So it's a very different situation where these kinds of complicated merges, where like someone changed a word in the same sentence that I moved, and then suddenly it becomes non-trivial and hard for the machine to just decide. That's why.

Botond Seres 44:15
Yeah, it really gets like that. Like if I change one word in one line, and they change another word in the same line they get there's just like no… what do you change that line? So..

Siman Svale Skodsrud 44:31
Developers hate these merges when they just feel scared, I'm gonna throw someone's work out. I don't know whose work. Yeah, we know, we just didn't want to do that. But the fun thing is that by doing this, we actually have the whole history of everything everyone has done. So you can get blamed. Inside, you can go and see every character at like 7:34pm yesterday. That person added this thing and we visualize it, you kind of move something, let's say like you move the crop of an image, we’ll visualize the crop, Siman changed the crop of this image, at this time. So,

Botond Seres 45:05
So it's like, the git, it's just it's for competence in the Git thing Matrix. So it's like multidimensional. It's not line based but character based.

Siman Svale Skodsrud 45:20
Neo was using Git, this would be how it worked. Okay. Yeah.

Botond Seres
I suppose

Dave Erickson 45:26
Images have become very important in content and in CMS, but now video is also becoming extremely important in content. And I kind of want to have an understanding. You have an image pipeline; my understanding is Sanity offers an image pipeline. What about for video? Video is much more complex than a single image. How are you guys handling video? And are you planning to do anything like an image pipeline for video?

Siman Svale Skodsrud 45:57
It's a great question. I agree. I feel like right now we partner often our customers are using mocks, if they're not using YouTube or if they want to have control of their video that will use mocks and we have a great integration with them that makes it feel a little bit like a native pipeline. Video is strangely non trivial. It seems like, for example, having real time video conversations. Still, I thought by this year, we would be completely commoditized like everyone would be doing it with 50 people. It's still hard coding video scale in fast delivery of a device all over the world. It's not. It feels like a derailment, like I think we would partner with someone to be honest. Yeah, no, I don't, I think it's so huge, we have bigger, more pressing value to create. I would leave that okay, to some specialists. Yeah. We will be. So that's not really out. But I feel like there are so many interesting things. That's also hard. Let's hope someone commoditizes that and we can just kind of buy that service. That's what I want.

Dave Erickson 47:25
Got it. So you did mention that you have other things that you would want to approach first, what are some of the things that you would like to approach and bring into Sanity for the future?

Siman Svale Skodsrud 47:37
There are so many things, but I think that one thing we really are fascinated by is this, right now we are in real time collaboration between content editors. What we don't see is a lot of people partnering with service providers like translation services and having that just integrated into Sanity. So basically, automatically at some point, it will be sent to a translation service, and the translations are integrated into their contents transparently. This is something people have to build right now. I think we should make sure those kinds of integrations and workflows are more kind of turnkey. And one dream we always had was like having systems, let's say you have an entity extraction system that helps you markup things. This is like an address, this is a person, I'm linking this to a product, stuff like that, we would love that to to feel like a, like a collaborative thing. I'm working on a document… this service that we have purchased and integrated. It keeps helping me and it will mark up things and suggest things for me and be able to have an API and a system where it's easy for service providers to add these kinds of interactions. Both are at systems level but also in the visual kind of user interfaces. That's a dream we have. And also, I think that the whole, like, we feel that a lot of that, there are so many terrible collaboration systems. And I think that being able to coordinate and collaborate better at the higher level, that's something we are really working on.

Dave Erickson 49:17
In many content situations, particularly related to social media, it's now becoming that way with even simple content flows to a website, and that's scheduling. You know, they have services like Buffer where you can load up a whole bunch of social media content, and it will be distributed at certain times to certain platforms and interfaces. Does Sanity have a kind of content scheduling system or feature? Or is that something that is completely separate?

Siman Svale Skodsrud 49:54
So yes, this is something we see all the requests for. In the past, people have been building their own, like we are. We are really preoccupied with having people be able to customize and build exactly the workflows they need. But it turns out that, at a certain level, this is something that people want the basic scheduling things to just be out of the box. So that will be something I think I would be looking for in a Someday release, not far in the future.

Dave Erickson 50:25
Another thing that I'm seeing in content or content kind of concepts, is the optimization of content, where somebody types in a long piece of content, say, into a CMS system and then they either use other tools or different tools to break that content into smaller segments, or maybe convert some of those segments from a written piece of content into an automated video content using AI. Those are some of the different kinds of applications that are breaking down content. Is Sanity IO able to support those types of things or is it something that if somebody types in a piece of content into Sanity, can it export that content into some of these atomizers? Or the AI that converts it from text to video and that type of stuff? Or is it stuff that maybe those things can integrate into Sanity with?

Siman Svale Skodsrud 51:27
Yeah, it's definitely something we don't have out of the box integrations like that, but that is always the crux, when you're trying to do this knowing what the different pieces of content is intended to mean, right? Like, this is a location, this is an intro, this is a reference to a person. And that's where Sanity really excels; making sure that when you put in your content, it's encoded according to it's intuitive and easy to do, but it's encoded according to like a schema which then helps these downstream systems really be helpful. So an example that's more like bread and butter and very, very important right now in terms of accessibility, is voice for example. So being able to transform an article to voice or have it powered like a voice assistant. These are things that people are building a lot using Sanity, because you can even add Markup that's specific voice and have that be hidden in a visual rendition but say emphasis or like it's a joke, you want to have it like a special kind of voice for that. You can do that with Sanity so, people are actually doing it a lot. One company is using Sanity to power the teaching script for first aid help training though, like its content for basically a CPR training, though. So you have all these non-traditional types of content and I think you're alluding to this is getting more and more common, like you having a septic box, you having a steam page for your product, you're having like all these outlets that you need to coordinate. Maybe you're having a fast food kind of company, you have your content in your ordering kiosks in your store and signage. You also have to ship this content to DoorDash and Uber Eats and internationally. What are the local delivery services? And how do their menu systems work? These are things that people are using it for right now, to make sure that that one marketing team can work on this content and have it fed into all the systems and they don't even have to know about it. And one team can add a new outlet like, Yeah, we're going to support To Do Right in Norway and that team could just go do that and not even talk to the content people or not have an engineer build a new API, which is very powerful.

Dave Erickson 53:55
Graph based editing is a huge boom to contributors. Can you tell us a little bit about draft based editing or how Sanity handles it?

Siman Svale Skodsrud 54:06
The reason I'm happy to say this, but I never ever thought about any other way of doing it. So I just have to kind of try to imagine what something else would be. But maybe it means that it's a shared draft. So, in one sense, in the traditional world, your draft will be whatever's on your screen that's private to you. In the worst systems that's local and if two people submit the same document after each other, they would overwrite each other's changes. In slightly better systems, there will be some lock, like I can't have a private copy until someone else checks in theirs. To us, it was very obvious. You need…, back to the fact that very often, even in small teams, even when we were like a 10 person company, when we had a release of some communication event, we would be editing the same documents at the same time. It would always be a contention in those kinds of documents that we're related to the rules. So making sure that there are shared drafts can be worked on in synchrony so that everyone sees the same source of truth. It’s incredibly important, I think it should be, or it's very hard to do well, technically but…

Dave Erickson 55:18
Yeah, cuz we actually kind of, we run into this problem, because we'll be putting up an article and either myself who writes a lot of them, or we'll have other people, we’ll be on and looking at the same document at the same time, in a system trying to work on it. We've kind of solved the problem, because our past website was WordPress, and we'd have kind of this conflict of overriding and people making changes at the same time. We kind of did that through Google Docs, where we would kind of massage the content with two or three people going over it and discussing it. And then once we were really finished, we would then say, Okay, we're locking this in, and then we would upload it and put it into the content management system. There, it would certainly be easier and more efficient, if we could just do it through the back end, the content management system.

Siman Svale Skodsrud 56:14
And there's another reason for that, because, as you mentioned earlier, increasingly, the content isn't just about text, that's one of our main drivers to make sure that is effective is that we want people to author structured content, we don't want them to author just text. Okay, so a lot of our customers in the media space are using Sanity to create these kinds of rich feature stories, as we scroll things are evolving, things are being animated, like that. And, this is content add, like, if you did that whole thing in Google Docs, you will be slanted towards focusing on the text, whereas you want your editors and the reviewers to focus on that whole experience. And be also commenting on the timing of animation, when an image comes in, and stuff like that. So I think that's absolutely vital. And that's why we invested. It took us more than a year to get all this stuff in place, but that was being able to have structured content be the native content portal and work to collaborate about and I think increasingly, like you talked about video, and stuff increasingly won't even be a lot of text in this content, it will still be content. So I think that notion that content is text is, yeah, it's getting outdated, I guess.

Botond Seres 57:30
So I'm a tiny bit familiar with graph QL, But apparently Grok is much better. And since it's much better, do you recommend using it over Graph QL? Can you give us a little context on that? Why is that? How is it better?

Siman Svale Skodsrud 57:49
So we don't say that. (hahahhaha) So we as a company invested. But, you do. Ah, sorry, like you use it, right? So we make it a point to say things like for us, kind of saying the one is better than the other is a little bit like saying a drill is better than a fork, it's good for different things. Sometimes you need a whole topic. So you need to eat. Grock is, as I said, it is a query language. That's a problem with Graph QL, it's called the query language. It is a great API pattern. So, you mentioned earlier, the challenge with Grok is that when your content model changes, your Grok API also changes; that might not be what you want. So we think Grok is fantastic for a query language. Whereas Graph QL is fantastic for controlled, stable API's. When Graph QL really gets terrible, is when you create dynamic Graph QL, like most headless CMS, just like when you change your content model your Graph QL API magically changes. Now everything breaks, all your types change and it's just the worst of two worlds. Also, Graph QL is really great at having these controlled, well defined ways of curing your data, which are fantastic. When these are intentionally designed by someone creating an API, but terrible when a system basically just has created every possible, like what to use Graph QL as a query language, you just basically create every possible theory that you could make, and you just unfold this incredibly huge Graph QL API. We also do this by the way, like we also have this because it's kind of a people ask for it. We did it but I hate that what I what we really want a what we're moving towards is having people be able to create, basically define and Graph QL API mapping to block theories and then basically keeping Grok curious behind the scenes like busy basically not keeping up inside Sunday and having a type safe, stable API as their interaction point with their front end. That's what we're going for. That's what we think is good. And that's where Graph QL is fantastic. It goes super well with TypeScript. So yes, we actually recommend the graph pill, but it's not quite there yet, like you have right now you have to create this kind of interface yourself. And it's hard to scale up. So I wouldn't do it right now, I think, for most people it seems to be, but Grok is the best choice. If you have, like, a typical one consumer scenario, and you can manage it pretty tightly, it's the best thing for most people, that's what most people do. But if you're multiple consumers, fast evolving tempo, you might, like some customers, rather than building their own kind of interfaces and we will support it natively in the future. But I love both. I think they're both great, even though this is one of them. The other one is also fantastic for what it's for.

Dave Erickson 1:00:45
So Simon, where do you think headless CMS is going in the future? What do you think are the opportunities for headless CMS as a development solution? If you had to say, How's it going to evolve? What is it going to evolve into? Or what are the things that will be involved in headless CMS?

Siman Svale Skodsrud 1:01:12
So, right now, I think partly because of the Jam Stack scene, and kind of affinity between the Jam stack space and Headless. Headless is seen as kind of a tactical marketing tool; it's for these smaller, fast moving teams. What we are seeing is these huge corporations coming in and seeing the benefit of this. most of the systems aren't ready for that, but I like having enterprise ready. Headless CMS is the big, let's call it like that, even like you have enterprises using Headless data, but they are often using it tactically for smaller things. We see the big, big companies coming in using Sanity for demanding applications and we are kind of ready for specific sweetspot use cases like that, which really works well. But I think like maturing that having the real systems working well at complex organizations that have complex collaboration, workflows, hybrid ownership between different teams, different kinds of even partners, that kind of feed content into the organization, that level of stuff is very mature at this point. And I think that's where Headless really needs to juncture that value. And it's something that these enterprises really, really need.

Dave Erickson 1:02:46
I think that Headless CMS is going to have a very interesting future and we look forward to working with it ourselves on projects for our clients. Simon, it's been a really wonderful conversation. Thank you so much for joining The ScreamingBox Technology and Business Rundown Podcast. To all of our listeners, we look forward to presenting our next podcast in a month. So stay tuned and take care and happy trails.

Siman Svale Skodsrud
Thank you for having me.

Dave Erickson
Thank you very much for taking this journey with us. Join us for our next exciting exploration of technology and business in the first week of every month. Please help us by subscribing, liking and following us on whichever platform you're listening to or watching us on. We hope you enjoyed this podcast and please let us know any subjects or topics you'd like us to discuss in our next podcast by leaving a message for us in the comment sections or sending us a Twitter DM till next month. Please stay happy and healthy.

Words = 10747

Characters = 58010

SUMMARY KEYWORDS
cms, content, headless, people, system, api, Sanity, workflows, developers, create, build, Grok, design, customers, data, add, graph ql, feel, business, product