Ep. #42, Structuring Content with Simen Svale Skogsrud and Knut Melvær of Sanity.io

Brian Douglas: Welcome to another installment of JAMstack radio. On the line we've got Knut and Simen from Sanity.io. Or actually, it's-- I'm adding the ".io" but you guys probably call it Sanity?

Simen Svale Skogsrud: We say "Sanity.io" or "Sanity" interchangeably.

Brian: OK, I wasn't sure if that was "So 2016 of you," to add the ".io," or something.

Knut Melvaer: For marketing purposes we say ".io," but I guess it's Sanity.

Simen: Yeah. When you're named a proper noun, then maybe you should add the ".io" just to make sure it is the product we're talking about, not the concept.

Brian: Simen, why don't you go ahead and introduce yourself? Then Knut, you can introduce yourself and talk about why you guys are here on JAMstack Radio.

Simen: Yeah, hi. I'm Simen and I am the CTO of Sanity.io. My background is as a programmer and a designer.

I've been a consultant engineer since the mid-2000s or early 2000s, but usually until now I was working as a consultant and a hired gun. Now for the first time in my life I'm at a product company.

Brian: Yeah, congratulations.

Simen: Thank you.

Brian: Then Knut, do you want to explain your background here as well?

Knut: Yeah, so I am currently a developer advocate at Sanity.io. I used to be-- I'm almost a PhD in the comparative religion.

Brian: OK.

Knut: Which is the reason I'm now a developer advocate.

Brian: Yeah. It sounds like a lot of relative background to go into writing code.

Knut: But I've dabbled in HTML and CSS since I was 15. So, that's why I'm here.

Brian: Excellent. Simen, you were talking about marketing earlier. Do you want to pick up "What is Sanity?" Like, "Why and where did it come from?"

Knut: Yes. Sanity.io, it is a hosted, real-time backend infrastructure content. It comes with an open source editing environment that you can customize in React and JavaScript, and you can host it anywhere we want.

Like on Netlify or on your homegrown server. As long as it speaks HTML, we can serve it. Perhaps Simen could talk about why it's a thing?

Simen: Yes. We used to be consultants and we were a boutique for developers, usually solving complex communication problems that required complex engineering, kind of a bespoke solution.

Then we got a call from the OMA, the Office of Metropolitan Architecture, the office of Rem Koolhaas a really famous architect. We actually were personally really fans of him, and they wanted a new website.

We weren't usually making websites as such, but this was such an interesting company so we decided "Let's explore this."

They actually had a really interesting problem, because they have been active since 1979.

Really interesting projects, many seminal credits and still really interesting to students and researchers.

This was about presenting their entire history, and also marketing their services, of course.

We realized that we needed to create books, presentations, business development tools, and also their websites from the same source.

We felt like we needed a proper content modeling solution where normal people can craft their content, and then it will appear in some presentation independent manner that we as programmers can transform into PDFs or PowerPoints or these search tools. We expected this to be off-the-shelf stuff.

We just thought "We'll go in the market, we'll find this somewhere and we'll buy it and we'll provide it to the OMA after we customize it somehow."

Then we really realized it wasn't going to be that simple. The market didn't really provide any of this at all, at that time.

Brian: That's interesting that you say that, because it sounds like this office, they had no web presence at all? Is that correct?

Simen: They used WordPress.

Brian: OK. Because I was going to ask, why wasn't WordPress reached for?

Simen: You're right. They had a web presence. It was an old WordPress site, I think. Any seasoned developer knows and empathizes in taking over an old WordPress site can be a nightmare.

But the worst part is that, of course, this highlights the problem because they had a lot of information in their old fantastic buildings with super small images cropped to the specific design that they were using at the time.

Every piece of information is super relevant things like the program, as they call it, of architecture and the sizes of areas, the architects and partners involved.

All of this was basically just running text, impossible to parse or redesign or repurpose in any manner. It's basically just word documents, in a sense.

What we really wanted was to be able to structure all of this content so that we can curate it based on these kind of-- Like, "Give me all the buildings that are retail spaces that are in the Far East that are drawn by this architect," like obvious things in a sense for a database engineer, but very new to the CMS space.

Brian: Yeah.

Simen: We were surprised to learn that, so they agreed to do a total rework of their content and then we realized we just had to create this tool.

So there is actually one more thing that we needed, because we felt that with WordPress you can't do this.

There were some headless CMSs coming out at the time, and these were all totally hosted things that were totally locked in.

But as consultants, we were really into being able to handcraft the authoring experience, we really wanted-- We usually interview both the people actually buying our services, but also auxiliary people involved.

Like all the stakeholders, there's something called a stakeholder analysis in the business so that we know what everyone needs, and then when we want to craft exactly the workflows that they need.

That required us to be able to go into the authoring interface. That was very often impossible in this more future-leaning services, so that's why we made sure that we wanted the entire authoring experience to be open source. Even though the back end was hosted and proprietary.

This is what we made, first for ourselves and then we realized when we did the same thing they did for DSNR in New York at Highland Park.

Then we realized "OK, this product doesn't exist, still, like two years later. So now we're just going to do this thing and then we will double down and we will transform into a company that just makes this tool."

So, that's when we created Sanity.io.

Brian: That's pretty cool, and I want to come back to the open source part that you mentioned, but I'm curious-- Could you remind me what date this whole walkthrough and this discovery was? How long ago was this?

Simen: I think we are like 2014-2015 when we started all my exploration.

Brian: OK.

Simen: Then we launched the self-service version of Sanity in November 2017, isn't that right?

Knut: That's right, yeah.

Brian: It's interesting because you're working with these architectures and all these designs, and the architecture of the web--

I'm just reiterating, they started on WordPress and how everything was working there, and it seemed like the industry moved away from that.

So it sounds like Sanity essentially is providing sanity for future developers to not be stuck in some architecture you can't actually add on to. Is that correct?

Simen: Yeah, that's a very important part. Like, one of the first Post-It notes that went up on the wall when we decided to make it an actual product, was the thing, "You should always be able to move forward."

We really wanted to be able to move forward, really never have to backtrack. Then this is a lot about being able to model your content, knowing what it means.

For example, never cropping an image to a specific design and being able to have the raw image there to re-process it whenever you need it.

These kinds of things, thinking that deeply and never having HTML, even having the ability to have HTML in your content but still being able to have all kinds of custom components and stuff inside your content.

Because even from the beginning we needed to be able to make the books of course, and everything else from the same source.

Our first influx of clients are people who are unable to create apps or setup box things on top of their content, because they don't have HTML yet.

It was our first use case, but there are several other things of course that we are useful to.

Knut: I just want to mention, now we are giving WordPress a bit of a hard time perhaps, implicitly.

But I must say I like learning web development by doing WordPress stuff, so I'm very fond of what WordPress stood for.

Brian: Yeah.

Knut: It seems like times have changed.

Brian: Yeah. I think part of the issue is that a lot of times developers get so stuck in their previous versions that it's hard to upgrade.

We just had Paul Biggar from Circle CI, now he is with a new company, DarkLang. He's starting this whole other thing because--

We went on this long tangent, so listen to that last podcast. It's going to be in your feed that came up before this one, but we had this tangent about hotels, and when you go into a hotel you have those alarm clocks.

It's all just alarm clocks that have the old iPhone 4 dock, and all those are out of place because those alarm clocks built their entire ecosystem around this one thing, but they never learned how to be flexible enough to change that in the future.

It sounds like a lot of these JAMstack architecture products and features, including yours, are trying to future-proof so that no longer you're stuck with that same dongle. Or you had to--

Like, right now I walk around with my iPhone and I have this little iPhone jack dongle that goes into my iPhone Thunderbolt thing. Yes, that is a bridge, but it'd be nice in the future that we will no longer have to worry about docks.

I think that's where we're going with hardware. I have very few things I can plug into my computer, because I don't have the USB-C thing, but I think hopefully with Sanity and some of these other projects that it's the same thing, "Let's not attach ourselves to a dongle, or attach yourself to a framework, or a process. Let's move forward."

I think with WordPress API, I think a lot of people are attaching themselves to WordPress because there's a lot of access with developers there, and that we can move forward and still use a cool thing like WordPress.

Knut: Also, if you have an iPhone, why do you need an alarm clock?

Brian: This is true. I personally don't, but the hotels definitely have them in every single hotel I go to.

Simen: That's a good point. We call them alarm clocks, but they are actually speakers that we can't use.

But I think you make a great point that the whole point here is to be able to mix and match technologies, and not be stuck with--

Because the worst part of an integrated thing like WordPress is that when you pick it, you pick all of the things.

You pick the templating, and you pick everything in one bundle. The awesome part of the WordPress tradition was that you can customize everything, and we tried to do that with the open source studio experience.

That's what we tried to preserve, the ability to really get into that and change it and make it yours.

But then still being able to, if you prefer to then write your front ends in PHP or JavaScript, or if you actually need it to be in REST and embedded toothpick, whatever. I don't know, but you should be able to consume your content.

We often say to our early clients we told them "You don't know. You come to us for books and the website, but actually you don't know where you're going to need your content, so you should really think about crafting your content in a really--

Like, thinking about it in the tactical and strategic sense, not in terms of being bad content or content for my book."

So, exactly like you said, the being able to move forward both with where you use your content, but also with how you integrate your content into your organization.

We have, talking to loads of people who-- Let's say in the old paradigm of CMSs, the CSM is dev specific.

It made sense because you had in design, the people who did print did that, you had WordPress or a site core or something. The people who did web, they did that. Then you have several medium-specific tools, and it was how we did things.

Then the vision, because it was obvious to many organizations, we need to centralize the organization and collaboration of the content into one place.

Then of course distribute it back into where we need it, because in one sense we shouldn't need to redo-- If you're a property developer you shouldn't have to redo your content for print after you did the website of your property.

You should have that be one job. Of course that's obvious, but on how to do it, and this is what we and others in this field are solving.

Brian: Excellent. So, Knut, you're a developer advocate at Sanity. Sanity has been around for a few years, as we discovered here in this conversation. We mentioned open source a few times.

I'm curious, is your role tapped into the open source element? Also, what is open sourced? Is it Sanity as a whole, or is it just a plugin? What infrastructure are we talking about?

Knut: Yeah. When people use Sanity, it's like you use the APIs and that's on our hosted back end.

Brian: Yeah.

Knut: So that's not open source, and that's what the editors are using and what the developer mostly are configuring and customizing is the studio, and that's open source. That's a React app.

We have a lot of tooling around it, like "How to render this non-HTML rich texts, then you need some tooling to make that simple to have it in React or Vue, or whatever."

So all that stuff is open source, we try to make as most of the things around available for people.

We also made the studio so that it's supposed to be possible to just switch out parts of it.

So the studio architecture is actually just a collection of parts that you can rip out and replace with video and stuff.

What we have spent most of our time on now is to stabilize the APIs inside of the studio, so this should be simpler and easier for people to do. People are starting to do it right, the right plugins published them on NPM and that's pretty awesome.

Brian: That's pretty cool that the studio is pretty customizable, because I know when I approach creating a new JAMstack site, I think every site I do--

Mainly because I don't work in an agency, so every site I do is usually a new idea I have.

I always have another constraint that I have to figure out, like one being I started a whole other podcast and had to do a podcast site, so I had to go find out all these different Gatsby plugins and had to learn about Gatsby plugins, and all this other stuff.

It was a nice little rabbit hole, so I assume Sanity it's like another path to find out the ecosystem and the community around that?

Knut: One of the first things I did with Sanity before I was hired, I used to work on a web agency. I did really a lot of work and tried to recreate the content models for podcasts as I churned content, and I did that at Insanity.

I published the content model, just the field definitions on NPM so now we can write in the terminal Sanity Installed podcast, and have all the setup going for you.

I also wrote serverless function that takes that content from Sanity and turns it into an RSS feed.

Brian: Excellent.

Knut: So it's like a JAMstack podcast RSS feed thing.

Brian: Two of the things I need most out of all these blog templates is these out of the box experiences, is literally just those two things.

Knut: We did a sponsorship of a Nordic podcast called Syntax. We can do a shoutout to Syntax.

Brian: Yeah, big fan.

Knut: To give them something to talk about, we made this podcast studio for them and imported all the Syntax episodes, and then I found a React port of web AMP. Or, Win AMP, it's called Web AMP.

It's like this complete React-based Win AMP clone that's going to run in your browser, and I just put it into the studio.

Now we can also write Sanity Installed Web AMP, and get this Win AMP thing. So, you can do stuff like that, because you want Win AMP in your CMS. Don't you?

Brian: Yeah, of course. Let's bring that back. I think Windows is cool now. So, everything that we had on our Windows machines--

Knut: Windows is very cool.

Brian: Yeah.

Simen: It's retro. It's cool to be able to do fun things like that, and also it's really nice to be able to--

We did a proof of concept for a health care provider, and they had these manuals and these diagnostic manuals for processes that they were running.

So, I would just write the small plugin to represent this reference from the manual to the diagnostic codes, like boring stuff that really integrates into their workflows and making sure that every time they mention this diagnostic code it's a reference to this specific point in the manual instead of just being this free text.

Then when I would show it to them, I realized-- Let's bring up this diagnostic manual for lung cancer. Then we realized that actually the diagnostic code for lung cancer had changed, so now this was for mouthwash.

This simple plugin that we could write would actually expose these really grave errors in their content that they weren't able to catch before.

To me, it was like "This is something really powerful. To be able to really implement their workflows and their way of thinking in their content studio, so that they actually--"

My point is that these workflows really matter. This isn't just going to garnish in terms of making it cool, it really changes how people work and the quality of the content and the efficiency they're able to achieve.

Brian: Yeah, that's interesting you bring up a term "Workflow," because I think a lot of what I do on the back end I tend to do the same thing over and over again.

I need sign in, login, authentication. If I'm doing a podcast I need the same models. I don't run a lot of podcasts, but you just tend to do what you know previously, especially if you do a lot of consulting or contracting.

You tend to reach for the same tools and then pick off the shelf, so it's cool that this tool Sanity is now existing for us, and all these different workflows and plugins exist for us to tinker with.

I'm curious if you have a one stop shop, a place that someone who might be listening and wants to get started with Sanity can go to look for?

Knut: We actually launched one today.

Brian: Nice. Good timing.

Knut: So, we are not tired at all. We launched something called Sanity.io/create, so you can go in there and you can just get up and running with a complete website running on Sanity on the back end.

We have examples for Gatsby, and next Muxed. It's like a blog portfolio landing page generator, and event site. There will be more as we go along.

So, there's a place to start. It all sets up on GitHub and Netlify, and it's fantastic.

Simen:

We're trying to bridge the gap a bit, because the entire JAMstack paradigm is awesome, but also can be a bit daunting in terms of having to make a lot of choices, you have to assemble the parts. We realized actually going to our first JAMstack conference that our job here is to empower people to be really effective, not spend their time configuring Netlify or Express Servers.

This dream was sparked on the first JAMstack conference. We wanted to be able to have these kinds of developers be able to just click one button.

We make a lot of choices for you, then. We picked Netlify, we picked a few frameworks that we really think are great, and then we just assemble everything for you.

Then of course from that point on you're totally free to change anything you like, but then at least you have a fully working modern web stack up and running in a couple of minutes.

Right now it is 15 minutes, which is a start. But by the time this podcast comes out it's going to be two minutes.

Brian: Excellent.

Knut: Also, it's something that we built because of all the questions we have gotten in our community.

We have like 900 developers in our Slack community today, and they are asking "How do we actually build a proper content model for landing pages?" Or "How do we structure this and that, and how does Gatsby work with APIs and stuff?"

We have tried to make some answers on best practices for that, and embedded that in these examples.

Of course, you should take these examples and make them your own. That's the whole point.

Brian: Yeah, I mean that's a big question that comes up a lot. Especially with doing this podcast as well, I was speaking at some of these JAMstack conferences.

A lot of people want to try this out, or spend a half day on this, or prototype a new thing to see if this is going to be better than whatever they are doing today.

But if it's going to take an hour from start to finish to figure this out, or even take an hour to figure out what the JAMstack is, then we're not doing anybody any service.

So having more and more quick starts, workflows tutorials, things out there for people to tinker and have the "A-ha" moment I think is a pretty vital to keep this community going.

Simen: I agree. Another thing that's-- Plugins here, we're talking about user interface plugins and a ski mask, like data models and stuff like that.

But it's a very important part of our dream, to be able to integrate your content with other services.

One thing is, of course, the front end is one service in a sense or the presentation of the content. But very often your content exists in some context.

For example, we are working with a TV distributor that has content providers that give them, let's say for example they have the entire catalog of HBO. So, they get the program data about Game of Thrones, for example.

So they want to customize these content with some curation, some priorities. This is the featured content, maybe even overwrite something.

Like we have a Norwegian actor who plays the White King in Game of Thrones. See why you might want to highlight that?

They then integrate the content APIs that provide the raw data, and then they have the humans be able to come in and curate and improve tat content.

We have a restaurant chain that has-- They use Sanity to model their menus, so they can have them on like trays and screens and shelves and apps. Wherever they need it.

But this is also powered by the European system, like a logistics system that knows about prices, branches, nutritional information so they can go--

With our content APIs, we can integrate these things in real time, and these synchronization jobs and machines can work at the same time as people are editing.

This is not-- This emerged in real time. We really wanted to have a nice offering for people who needed translations, so we found a nice company called TransFX in Palo Alto, I think. Which has a great service.

We don't want to make that JAMstack approach. Of course, you don't make everything, you try to just integrate with the best providers of services.

So we worked with them and found a way to do this, and then we talked to one of our clients friend's travel agency, and said "Would you want to try this out?"

They told us, "TransFX? We already did that." They hadn't actually used the APIs and they integrated with TransFX and have the full workflow up and running themselves.

So, plugins on the front end is one nice thing, but then being able to have this mesh of different content services beyond just different fountains is the really powerful promise of this paradigm of content infrastructure.

Brian: Excellent. Simen and Knut, I appreciate you coming on to chat about Sanity.

I'm going to shift our conversation into JAM picks. These are things that keep you going, these could be music or food or entertainment, code stuff, all of the above. Nothing's off limits.

If you don't mind, I did mention offline that I was going to have you go first, but I have my pack already. It's just not in the notes.

My pick is my table top dishwasher. Now, you're probably thinking listener, "Dishwashers are-- They've been around forever." That is true, but not in the places I rent.

Since I've been in the Bay Area I've always lived in some old building that doesn't have a dishwasher, and I doubt I would get my landlord to put one in.

Also I was totally fine with washing dishes when it was just me and my wife, but now I have two kids, and we eat a lot too as well. So it takes a lot of time to wash dishes.

I had to protect my hands, because I have to use these to write code too as well, so I can't burn them or anything like that.

I went on Amazon when I recently moved a few months back, and bought a dishwasher that sits on your tabletop and attaches to your sink.

There's so many of these out there, so I'd even know what brand I have, but it's pretty sweet because it washes dishes.

I think in a summary of everything that we've been talking about so far in this podcast, it got my sanity back.

I no longer spend nights and evenings and weekends washing dishes, I just throw them in there and push the button.

Simen: If you want a tabletop dishwasher, get a good one. I remember at my first flat I had one as well, and it used to electrocute all of us.

Brian: Nice.

Simen: It was like a death trap, so get a nice one.

Brian: OK, yeah. Or, "Write better tests, dishwasher companies."

Simen: Yes.

Knut: The dishwasher-- It doesn't have to connect to the internet, right?

Brian: No, this one doesn't. This one--

Simen: It connects to the ground through your heart.

Brian: Yeah. Too many dependencies if I had to connect it to my Alexa, or something. No, I didn't go the extra mile for that one.

So, Simen, do you want to talk about your picks next?

Simen: Yes, I wasn't sure about the genre here, so I have two.

I have one, I am really into biking, and there's a new category of bikes this last year called Gravel Bikes. They're a mash up between mountain bikes and road bikes, to get a bit of both.

I really want one, but they're still quite expensive. I'm looking for a Polish brand that I'm looking at.

Brian: Nice.

Simen: Then on the other hand, it's really-- I think web assembly is of course nice, and they are starting to make this run on the server side.

I am really looking forward to be able to safely run our users codes inside those services, really embedding.

This makes any programming language and then by the whole scripting language, I really look forward to being able to play with that inside Sanity.

Brian: Excellent. Knut, do you want to go for your picks now?

Knut: Yeah, it's quite a developer pick. Yesterday we got some good news, and then we got CodeSandbox.io. They got some money.

Brian: Yes.

Knut: Code Sandbox is-- It's like they are running VS Code inside of your browser, and now they have extensions and all of that. Microsoft also announced to VS Code online, or something.

But I was like, "20 or something is awfully young for having done this with this small team."

Brian: I didn't realize he was so young, but I remember I've seen the project around for a while now.

Knut: Now they have server side stuff, and for me as a developer advocate, everyday I'm quoting some example for some online support or something.

CodeSandbox is the first tool I grab, to just share it with people, and I'm so happy that they got some seed funding so they can hire more people and not work themselves to death.

Brian: Excellent, yeah. I'm looking forward to seeing what they're going to be shipping after, now that they are funded and going to grow into a real company.

I'm not sure how much of a real company they were before they got funded, but anyway, that's only speculation till I find out.

Simen, Knut, thank you very much for coming on and talking on JAMstack Radio about your very jammy product that you're working on.

Simen: Thank you.

Brian: Listeners, definitely check out Sanity.io/create, which I guess came out very recently, and start shipping some cool stuff. Also listeners, keep spreading the jam.