IxDA Norway
Situation #
The Norwegian part of IxDA, the Interaction Design Association, has over 1000 members, runs regular events which are recorded and shared, has local groups around the country, and a website made with Squarespace.
That was good enough to start with, but as they've grown in membership and services they've added third-party services for event registration, video streaming and recording. These new services did not integrate well with the site, if at all.
The content had also outgrown its baby shoes. We now needed categories for future, current and past events, talks, speakers, podcasts, sponsors, articles, volunteers and probably some things I'm forgetting now. And to top it off – a flexible way to connect everything. An event would include multiple talks, which could have multiple speakers, with one or more videos, sponsors sponsoring various parts, volunteers with various roles. The list went on.
Now, IxDA isn't just any client, they are Interaction Designers after all, with a good idea of what they want out of websites.
Fredrik Matheson, the driving force in IxDA Norway, UX connoisseur and all-round amazing person wished to collect all these loose parts into a single source of truth, in addition to getting full control of content management, architecture and design.
Solutions #
In order to have the flexibility needed to connect all types of content while having a good content structure for the site's editors, we opted for a headless CMS for the back-end. A headless CMS is a content management system that separates the presentation (the website you see in your browser) from the content (where you enter and organise information).
Back-end #
Thus I built the backend in the Sanity Studio headless CMS. Sanity treats all content as data, which can be accessed through APIs. Anything that can use an API can then be used to display the information stored in the CMS.
The CMS itself if is very flexible, which allowed me to set up a structure that the editors are the most comfortable with. And with a good overview of the information architecture from the outset, I was able to let the CMS grow in size and scope as the project went on.
The editors are now able to connect talks to events, speakers to talks, members to roles, sponsors to events and on and on. The cross-referencing is used extensively to keep the paths of information within the site connected.
Custom CMS functionality #
- Separate page section for SEO and social media sharing, with fallback if left empty.
- Re-ordering of sections on homepage.
- CSS settings to individualise each homepage section.
- Custom embeds in the rich-text editor.
- Featured talks to highlight on homepage.
Front-end #
The front-end information structure does not always follow the back-end structure. In traditional CMS' this is often a source of friction, but thanks to the headless CMS format this problem is eliminated.
I chose the Sveltekit library for this front-end work. Sveltekit is very developer friendly, and more importantly, doesn't add any JavaScript to the user unless I specify so.
That makes the site more secure, less likely to fail, and fast! This is possible thanks to Sveltekit’s ability to build with SSG (static site generation) in most places, and progressively enhance with SSR (server side rendering) and SPA (single page app) on the more dynamic pages.
The site is hosted at Vercel, which rebuilds the site when a change is committed to GitHub, or new content is published via Sanity.
HTML and CSS hand-crafted with love ❤️ #
Writing traditional CSS instead of relying on a library gave us full freedom to explore designs together, which was an important part of the development process.
The HTML is structured to be accessible to all, humans and robots.
Results #
Happy client #
Because of the flexibility of both Sanity and Sveltekit we've been able to try out any and all concepts that we've come up with. The event registration is now integrated in the website, events and talks are the two main areas, both of which contain a lot of metadata collected from different sections of the CMS, but presented as one in the front-end.
Lessons learned #
The editors could start entering content into the CMS while it was still under development. Following that, we had a lot of real content to work with before starting the development of the front-end. This avoided second-guessing and using dummy contents.
Skills gained #
This project improved my JavaScript, Groq querying API calling full-stack developer head, which I quite enjoyed. Yet thanks to Sveltekit I was able to keep the code clean with focus on qualities such as performance, mobile responsiveness, user experience and accessibility.