Unlock seamless workflows and faster delivery with our latest releases - Join the deep dive

Litteraturhuset

By Eivind Lindbråten & Jørgen Brynhildsvoll

New website for Litteraturhuset: Europe's largest house of literature.

The home page
Dynamic modules. In the backend you can select many different ways to fetch and filter events, and also how they should be rendered. Both of these lists are example of that.
Modules that can link to other documents
Calendar showing all upcoming events. Can be filtered in various ways. The filter state is stored in the search params so that we can link directly to a filter. This let's us create specific landing pages, e.g. for "Children" and then link directly to the calendar page pre-filtered on events for children.
The fully customizable menu. Also translatable.
Overview of all rooms at Litteraturhuset.
The system is very modular and customizable. This is a general content block with a grid layout that is being used for displaying podcasts.
A global configuration. Most fields are translatable.
Home page and page are mostly the same document structure. It's very modular.
Each section on a page can consist of many modules.
Each module has a layout option that let's you specify how the module should render on mobile, tablet and desktop. Each module can again have multiple different pieces of "content". There are 11 different content types. Like "Pictures", "Call to Action", "Rich Text", "Events", "Articles", "Page reference", "Accordion" etc.
Example of one of the "content types". This is "Events". Here you can see that we can show how it's rendered and the flexibility of how we can fetch and filter events.
Event document type.
This is a specialized document type used for generating various different newsletter Litteraturhuset sends out. You create the content structure using some of the content types used for building pages (and one custom content type). Using live preview you can see how it will look like. The email is rendered using React Email with Tailwind and custom font support. The publish button is replaced with a button that copies the generated HTML to the clipboard. The client can then paste the email friendly HTML into their newsletter service, Make (Norwegian). There are some special if syntax rendered that Make will take care of, so that subscribers will only see events from tags that they are interested in.

About the project

The idea was to create a flexible and modular content system so that the client independently can create all the pages they need.

The website was expertly designed by Smuss Studio. They have great technical understanding so there is a lot of design thinking put into the content structure and studio setup as well.

The content structure for the page document type is the most interesting one. It is built like this:

  • A page consists of one or more "sections"
  • A section can specify a background colour and consists of one or more "modules"
  • A module can specify layout properties (different settings for mobile, tablet and desktop) and can contain one or more "content" blocks
  • There are in total 11 different content blocks from "Page reference"'s to "Event"'s, "Accordion"'s and more
  • The most complex content block is the Event block. It has options for specifying how it should be rendered and various options to fetch, filter and limit the events

Other notable features of the backend is how it's being used to generated multiple different newsletters.

We use a subset of the document model for a page to build a newsletter document. Using the live preview the client can see how the newsletter will be rendered. To make sure the html is email friendly, it's being rendered using React Email with support for Tailwind and custom fonts. With some modification's we can eve reuse components used for the frontend like our custom Portable Text component.

The publish button is replaced with a function that copies the email friendly html to the clipboard. This html can then be pasted into Make, which handles delivery of the newsletter.

For search we use Algolia. Using a webhook we rebuild the search index when content in Sanity is changed.

The site is also statically generated and we use a similar webhook to on demand regenerate the affected routes.

Contributors