Cutting through the jargon: demystifying Sanity

Cool, so this is the cutting through the jargon and demystifying Sanity talk. So, a little introduction: my name is Jono, I'm the founder of Roboto Studio. I've been a founder here for five years, and I am a massive enthusiast in structured content, and I'm a vocal cat parent, so the cat on the left is Kiki, the cat on the right is Kevin. How I got inspired to actually write this talk and sort of communicate all the different bits and pieces that's inside of here: we had a lot of clients come to us with kind of a mystification around Sanity, trying to understand exactly how Sanity works, how the bits and pieces fit together, and we wanted to essentially write this up to give kind of like an all-encompassing, very high level overview of how we've personally worked with Sanity. And it's been, you know, a great learning curve to understand what bits are missed out from the general knowledge about headless. So I thought I'd start with one of the things that keeps getting essentially popped around on the Slack channels, which is structured content. If you've had the opportunity to check out the event recently, it was very, very cool. But I kind of have a lot of people actually ask me about structured content, and I'm probably going to upset a lot of people here by saying this, but it's just data. It's essentially data that is constructed in such a way that you're able to mix and match. And essentially, in the old days, the way that websites used to work, they used to have a very rigid, monolithic (and I'll come back to monolithic a little bit later) way of having a title and the description and then the main body of text, and that would typically be your content management system experience. However, now we're having much more of a focus on kind of narrative and the way that we actually structure our websites to be really tailored for customers, and structured content is kind of like a great aid to that. It's the ability to kind of shuffle around all the pieces of content and make sure that everything looks the way you would expect it to look as a client, and kind of pass over visuals in certain ways. So there was a great talk by one of the founders at Sanity where he talks about e-commerce sites, and one being a luxury one versus one being just a very simple "look at this, the size of this mole and the dimensions of it". So if you can think about that, that's the same thing with structured content. And this brings me on to a content lake. Now the content lake is the one that we found that clients find the most confusing, and to be honest with you, I don't blame them to a certain extent. A content lake is very, very powerful if you sell kind of more the strategy behind why you would use one, more so than the actual core functionality of what one does, because the core functionality is very ethereal in my opinion, and to most clients I believe it feels the same way. So a content lake being more of a means to an end is kind of the way that we talk about this quite a lot, and I hope you'll see why in a second. So let's go for a real world example. So I've just a few seconds ago had a little Google, because I didn't know the exact numbers about these, but you want to put out a social media post that's of your website. You've put out a new blog post, you want to share it on LinkedIn, you want to share it on Twitter, you want to share it on Facebook. So we've all been on LinkedIn and we've all seen those terribly cropped little thumbnails that you see inside of the feed, and I kind of want to give some sympathy to why that happens, and kind of a bit more of an explanation for most people that aren't developers. So this is generally how it usually goes for an end client, and I think it's very important to sympathize with this and understand why it works like this, to be able to kind of improve it in the future. So you decide you want to make a blog post. You work out what your image wants to be, and you start to work on, say, Photoshop, and you work out which platforms you're using. So if you're using, let's go for the big three, let's go LinkedIn, Facebook, Twitter. So you go onto Photoshop, you read a little bit on the internet and you say, oh it's, what is it, 1200 by 630 I think it is for Facebook. So you set up a canvas, 1200 by 630, you build the image out, you export it for the web. When you're exporting for the web you probably export something like PNG, JPEG, and you upload the image inside of your content management system. And then as soon as you do that, you share the blog post and you realize it's the wrong size. Now you're back to square one. So that is typically how it goes, and that's typically how you get something in LinkedIn where you realize it looks beautiful on Facebook, terrible on LinkedIn. So the content lake, in my opinion, is really well suited for this, and this is kind of the key point that people, because they have these pain points, they have these experiences. So let's take it again in a very similar manner. When we say we're going to build an image in Photoshop, we're going to leave a little bit of space on each side for cropping, we're going to export the image for the web, so everything's pretty much the exact same as the first time. We upload the image, and then this is where the real magic of the content lake works, which is that you've essentially got multiple (providing you obviously put the code in there from a development side), but you have multiple different queries that you can use to have multiple different croppings of the same image. So having that version where, if you look on LinkedIn, it looks fantastic, pixel perfect. You have it on Facebook, pixel perfect, and the same with Twitter. Every single version of this blog post looks fantastic now. Because there is that essential pain point with this previously, and there is a lot of people that have had this pain point, it's a great example to kind of explain how the content lake works. I know there is a lot more information that can come from the content lake. There's a lot more to do with CDNs, and there's more to do with file distribution and everything else, but the real core thing here is what will probably happen for most clients on a day-to-day basis, and this is a good example for us. Which kind of moves me on to the next part of why I explain with clients how Sanity works and why it's a little bit different. And again, this is in my opinion, so this isn't the official terms, but Sanity is a code-based content management system, and that is something that I really want to hammer across whenever we talk to clients. The reason being is, I'll show you the opposite first: a GUI based content management system. So I'm guessing you've probably, most people have probably used these as a developer, and they're fantastic for certain things. They're fantastic for things like a very simple blog, a very simple page builder, but again, the more they kind of scale, the more it becomes problematic. But the real benefit of these things is that they're easy to get started with, and the problem that comes at a later date is the ability to kind of validate your schema. And again, by saying validate schema, the way your actual page gets built, the validation of that is kind of very important to emphasize. Comparatively, the code-based, so we're coming back to Sanity here, you have this ability for it to be far more customizable. And again, explain it to clients about the fact that you can take a relatively simple thing like a conditional. So say you want to have a link that works externally and a link that works internally. You might say that, oh, you know, not many things support the idea of a conditional where, if you want to go and put an internal link, which again we can use something like Next.js where it improves performance, they will definitely be on board with the performance side from the SEO basis. But again, it's going back to this idea of defining the actual benefits you get rather than the core functionality, rather than the declarative things, you know, code based, scalability, they're all very ethereal. So talking about this, we'll go on to GROQ. And now when I first heard it, I did think it was genuinely like some goblin name or something like that. Sounds pretty fun. But essentially GROQ is kind of one of the most, I guess, misunderstood things when we talk to clients about this. Because I think if you use, going back to the same idea, the principle of a pain point, you could say something along the lines of, we have GROQ, you know, there's a real issue with GROQ, sorry, real issue with crop, there's a real issue with performance on websites. And say for example you're taking all the data from all the different pages, all the different blog posts, that's a real issue, because you have to have something compute and read through all of that, and you also have to take the data for all of that. Whereas if you have something like GROQ, you have the ability to kind of whittle down content and make sure that it's very intelligent in the way that you're only pulling essentially the data that you need for the page at that time. Portable text. So I'm going to ruffle a couple of feathers on this one as well. So portable text is an incredible tool and we think it's absolutely fantastic. It's been one of the things that really differentiated Sanity for us as a platform. But every client we speak to with portable text, it's not at the forefoot, the forefront, sorry, of thought as to when to use this, because it is quite a hard thing to explain as to when this is actually useful. And now for us, one of the things that we always say is, with portable text it's the idea of extending out a rich text editor. So you're essentially adding the ability to do a lot of incredible stuff for the client. And I tell you exactly the way that you might potentially speak about this, is that you say, we're working as, you have a traditional website, you have a traditional blog. What you keep seeing is a common theme, a common design practice, is midway down the page, somewhere after a particularly interesting paragraph, you might get a little newsletter sign up box. Now in the old days, the way that you would do this is by doing it where, for example, it just says, we'll have to, let's say, 500 characters or something along those lines, we pop in a newsletter box. Now with portable text, you can extend the granularity or the control of portable text, and you could literally have inserting a newsletter field where you feel it's necessary on the blog posts. And again, the same applies with related content. Kind of pinning those ethereal ideas into something that is a very tangible, very common design language principle is a great way to basically explain a lot of the functionality there. So again, we're going back to why does it matter, and it brings it down to these three things, which is performance, scalability and maintainability. So we always talk about performance, and usually when we're talking about performance, there is an arms race at the moment for everybody to try and get the world's fastest website, which is great, but ultimately it's a means to an end: to have a much more accessible experience, to have a much better journey, and to have a much better search engine ranking. So essentially we use those three points rather than kind of "oh, it's just performance". And again, with scalability, it's a return on investment. You build the website, you want to make sure that when you have this website, you have something that you can really build on top of and use for more than just one or two years. And the same with maintainability. This kind of rolls into the scalability aspect, which is that you can consistently keep building block after block after block onto the website. So again, seen it time and time again, the idea is that these pain points are really, really important to contextualize why you're using a headless content management, why you do all of these development features, and it's very, very important to try and help the client choose the correct tool. Two seconds, little water break, apologies, I've been on the talks all day. And so I thought we would do questions we've been asked by clients, because it's very, very common that we get hit by these. So, how's the editing experience? Now this one comes up quite a lot. I thought I'd go for a little bit of a Family Feud, if you're from America, or I think it's Family Fortunes in the UK, it's basically the same game. But how's the editing experience? This comes up every single time whenever we work with a client, because editing experience, in our opinion, is the be-all and end-all of how much a client appreciates a content management system. And so with the ability, and with thinking about how you actually structure these, I would always advise: spend a little bit of extra time on doing things from a user experience perspective. So the whole idea of having accessibility on Sanity, having things like, something that really makes a difference in our opinion is preparing fields, and using fields where you can actually throw in a title or an image or an icon, something that just basically boosts your work above, you know, the norm. So making a better user experience overall is going to make you seem like a better developer, and as for how this actually works with a client, the editing experience is phenomenal. Maintainability. Again, we're saying this, we've gone through this a little bit, but essentially the maintainability of working with Sanity is fantastic. Very, very rarely, it's only because we're having such a quantum leap from V2 to V3 that there has been, you know, somewhat of a migration process. For ever so long it's been consistent, and it's been, you know, you wouldn't have to require to do any migration process. So the maintainability is absolutely top-notch. And that, paired with the headless aspect of it, with for example Next.js, there's very, very little other than updating packages that an actual client would need to do. So again, kind of talking about that side of it is always very helpful. Headless. Headless gets asked as one of our most common questions. So headless has talked about a lot. What it actually means to a client is a totally different kettle of fish. So when you're actually talking about headless to a client, remember this pure and like this core technology kind of exists in a very development heavy environment. So a good way of kind of describing this and ensuring that everybody is on board with this is explaining the difference between monolithic and headless. I think there's a real value to be taken from that, to be able to explain how a technology that you use today might not necessarily be the most viable technology a few years from now for the front end. Or, for example, you may want to use your content management system to multiple different locations, to apps, to other different places. So kind of pushing that idea of the outcome of this, rather than the core functionality, is always very important in my opinion. Time to market. Again, the beauty of working with Sanity, the beauty of working with Next.js and other headless frameworks, and, you know, for example Gatsby, the time to market is really, really fast. So you are essentially testing very quickly, and again, talking about A/B testing, Optimizely, all that kind of stuff. You can take what is a very simple website from start to finish in a very short period of time, and again, clients are really going to appreciate that honesty about how this would work. Sanity V3. Of course, we absolutely love this. We're really appreciating it at the moment. We've had a go with a couple of different environments, and it's always great to stay up to date with these kind of things. Explain the developer experience and how that kind of knocks on to the end client. So for example, development experience is better, it means you get a faster turnaround, goes back to the time to market. It's a great way of talking also about the extendable components, but again, not just talking about extendable components, what that actually does to the end clients. So for example, there was a great one on Sanity's documentation where they talk about an opening and closing day from Monday to Friday. Having something that is very, very easy for data entry like that, it makes a massive difference for somebody. Performance. Now surprisingly, this is a bit of a misnomer one. So we have a lot of people talk to us about performance, but it's very much something that is just a known. It's, after a certain point, less important than the actual designer, the core content management experience, in our opinion. I know that's a bit of a controversial take, but essentially, once you start hitting the 90s, I think people are more interested with how they would actually interact with the website, and more interested with how the editing experience is. Again, this is just completely anecdotal from what we've experienced in the business. And ultimately, you know, why should we pick Sanity as a content management system? So usually, whenever we have clients come to us, they're debating between two, three different headless content management systems. So what I would always do, just in general, is brush up on other systems, have a look at all the different versions. Ultimately, we've been a big backer of Sanity because, ultimately, ninety percent of all the headless content managed, well, this is completely plucked out of thin air, but the majority of content management systems that we've used, the headless, are almost always a GUI based content management system, which means they'll have issues with scalability. So understanding how that affects a client is very important, especially long term, when you're talking about 100 page websites, 200 page websites. And then finally, how's the customer experience? So this one actually comes up quite a lot, because we've had a lot of people that have potentially been burnt by other companies. So kind of the reinforcement, and personally the same, I had an incredible experience with Sanity from day one with the community. So I've had a lot of people talk to me, both community members and members of the Sanity team. So it's always great to be honest and say, look, this is a thriving community, speak to some of the people on there, get in touch. Because ultimately, we find that transparency and that honesty about how the tool works, go speak to some of the people in the community, is a great way to essentially win over somebody onto the, you know, the Sanity CMS. So essentially, that's all the different ways that we would typically approach a client to ensure that everything is absolutely top-notch when we're talking about how we will build a website. So I hope that's helped for somebody that's, you know, aspiring freelancers, or anybody that's going out there to start their own agency. And yeah, thanks for listening. Does anybody got any questions? Thank you so much, Jonathan. I think you inadvertently started a campaign for making a goblin mascot for GROQ, that's apparently going to happen now. We got one question from Ethan in the chat: are you using the dev preview with clients already? We're using it currently with three separate clients, and we are using it, we have an internal CLI system that basically spins up an environment for us. And we were a bit hesitant, so to anybody else that was considering actually doing this, I was very, very hesitant to run with a development environment with a client, but we have found only one or two bugs with it so far, and to be honest with you, they're fairly like negligible bugs. It's been probably the most solid development preview we've ever experienced. So yeah, I would highly recommend doing it. It's a bit living on the edge, I think Sanity naturally told us that, but it's definitely worth doing. I would definitely recommend it, at the very least check it out in your own time, development wise. All right, I know you have a very nice blog post about your experience with V3 on your website, which I encourage everyone to check out. Let's see, what are the most challenging terms or concepts to explain about Sanity? Are there some that are just so inscrutable you don't touch it? Oh, that is a good question. Let me think about this for a second. So I think not so much Sanity, but I think something that's very difficult to overcome is somebody that's been burnt by a headless content management system, which does happen to us quite a fair bit. So a lot of our work is actually refactoring to get a headless content management system working, most of the time, and as much as I wouldn't like to say this, it usually does end up having to be a rebuild, because of, you know, previous opinionation and such. So for me, the biggest things that typically come up is: we've used this headless content management system before, we've been burnt by it, how do we know we're not going to get burnt again with Sanity, how do we know it's not a flavor of the month, you know? And I think, if you want my honest way that I would respond to this, is, you know, explain the focus on structured content, explain how they're very much pushing for the user experience, content management wise, which is pretty much unprecedented as far as I'm concerned. For kind of like the whole, well, running an entire event over it is a good example of as to why to use it. So yeah, I guess that would be the trickiest one that comes up, and it does come up quite a lot. I have a feeling that would be something that you might get questioned about if you go into freelance. That's a very interesting angle. It's kind of like teaching them to love again after being hurt. Yeah, yeah, absolutely. Did you have one? Yep, so I loved your talk. Canoe in the chat said the Sanity marketing team is all eyes and ears, and it's so true. It's like, this is bridging that gap between the content editors and the developers, and so a lot of great content. But what do you find is like the most common aha moment for your clients, and like when does it finally click for them? At what point do you find that most common? I think, do you know what's a great winner for this, in my opinion, is the previews. So previews specifically with Sanity are really impressive. So we always advise anybody that wants to get a nice vote of confidence is get an environment that works with, in our specific way, we always build with Next.js, so I'll speak from a Next.js background, but having a Next.js preview available with an editing experience on the side of it, and the real time seeing that when you make changes it appears on the left and right of the screen, is hugely, hugely valuable. So understanding kind of what the day-to-day life would be of a marketing person that comes along, wants to build a website and wants to edit the website, and trying to basically wow them the most. So yeah, the iframe pane, I think it was incredible for that. That makes sense, that's a good one. Yeah, I love that functionality as well. All right, thank you so much, Jonathan. You can find Jonathan and Roboto Studio on Twitter, and we'll share his link, and you can also find Jonathan in our community Slack. Great stuff, thanks for having me on both, take care. Thank you, Jono.