The old viastudio.com website launched nearly a decade ago atop of Wordpress - our go-to custom website development platform. 

But much has changed in those ten years in web development - and the goals we had for the

We wanted something that would create a unique, elegant, interesting user experience, delivered "scary fast"  - that was also easy to develop and maintain.

We love Wordpress - it's has been and remains our go-to for custom website development. Though to achieve our user experience and development goals for 

, we found that they aligned closely to the offerings of the JAMstack: static markup, delivered fast and enhanced with Javascript. This is commonly known as a "headless" content management system (CMS).

There are many JAMstack CMS - including using Wordpress in a "headless" mode. But would that fit for our needs?

Read How We Customized the Sanity CMS

The biggest challenge was moving our data from WordPress to Sanity, mainly our blog posts going back years. Fortunately, we were able to write a tool using PHP and Node to convert all of our WordPress data into a format that we could import into Sanity.

Read About Our How We Migrated Our Content

For a framework, we had two main options: Gatsby and Next. For me, the choice was easy. While Gatsby offers a theme and plugin ecosystem that resembles Wordpress’s in some ways, Next’s ability to dynamically work as a static site generator or a server side rendering framework on a page-by-page basis is a huge win. We had recently tested it out on our 

 and were immediately impressed. In the time since that project, Next has rolled out features like the incremental static regeneration which means that we can generate our featured case studies at build time, generate additional case studies at runtime when they are requested and also create server-rendered landing pages that can take advantage of A/B testing, cookies, etc.

Next also introduced API routes, which means instead of relying on a full custom server for things like form handling, we can just create a file at “api/form,” and Next will generate an API endpoint for us where we can run server-side code while doing everything else on the client.

Using a React framework also enabled us to take advantage of libraries like Framer Motion, which provides physics-based animations that give layout changes a more natural, playful feeling than duration-based CSS animations.

Vercel was our first choice for hosting because it supports Next out of the box as it is built by the same team. But more than that, they provide a great development experience. We have our project set up as a monorepo, for which Vercel recently rolled out support, which means our CMS and frontend are two separate packages that we host in one repository, and they each have their own project in Vercel with continuous integration through Github. Any time we open a PR for one of the projects, Vercel creates a preview deployment where we can view all the changes just how they will appear in production, and when we merge it into our “main” branch, a new production deployment is created. And if anything goes wrong, we can easily roll back to a previous deployment.

While we always work closely with the design team throughout the development process on a project, we often don’t get involved until fairly late in the design process. For this project, the goal was for design and development to collaborate on the design system and build it from the ground up, with an emphasis on componentization, since we knew we would be building the site with React.

Before design even got started, we got to work on the foundation of the design system. Inspired by the layout primitives in Andy Bell and Heydon Pickering’s Every Layout, we created React components for basic layouts that can be truly modular and intrinsically responsive, so we could use them all throughout the site. My favorite is The Switcher, which switches directly from a row to column layout with no breakpoint and no awkward in-between wrapping states with orphaned items.

To help with testing these primitives and collaborating with design, we built our components in 

, which enabled us to isolate components, visualize variants, and test responsiveness and accessibility. With this workflow we could develop layout primitives individually and share them with design; then design could construct layouts with these primitives in mind and hand back components, we could build those in Storybook and have them reviewed and incorporated into full page layouts, which we could then build in our Next.js app. This workflow brought design and development much more in sync and enabled a more efficient back-and-forth compared to a more standard hand-off where development begins after design has already completed the full page layouts.

The most exciting thing about our new site is what’s yet to come. Moving to a modern stack has opened the doors to all kinds of new ideas and experimentation. We’re only restricted by our imaginations.

We are extremely proud of what we were able to build and are excited to continue work on improving the site for our employees, clients and friends over the coming years.

PHP, Javascript & React

Frontend Development

Custom Dev

Developing the New via.studio

 is the super fast, super customizable CMS that we're using as the backend for the new 

One of the more powerful concepts that Sanity is the 

 which gives you the ability to customize how content is presented in the Sanity admin.

Let's go through the basics of how you start working with the Structure Builder.

When you first start with the Sanity Studio, you'll have a 

 file which has some basic information about your Sanity setup.

Your sanity.json file will have a section called "parts" which looks something like this:

We're going to update it so Sanity knows to look for a structure file for any customizations.

The above structure mimics the default behavior of Sanity. We have a single pane called "Content" which displays a list of all of our document types.

Now that that's in place, we can organize our content in some interesting ways!

One thing we wanted was to be able to exclude certain document type/schemas from the Sanity admin. That can be achieved by updating our structure file like this.

We've defined an array with the ids of document types we don't want to display. Then we take our list of items to display in Sanity and filter it using our exclusion array.

The last bit we'll cover is creating custom items to add to the content sidebar.

In our Sanity setup, we have a document type called "content" which is used for both 

​. Both types have a similar structure in that they each have a header image and then a large block of content entered using a WYSIWIG editor.

However it gets confusing in Sanity having all of those items lumped into a single "Content" item in the sidebar. What we really want is a sidebar item for the Blog Posts and a separate one for Case Studies.

First we get all of the documents with type "content" (this includes both Blog Posts and Case Studies).

Then we build a sidebar menu item that contains just the Blog Posts and another with just the Case Studies.

Finally, we add both of those custom menu items to our list.

Backend Development

Dive into the Sanity Structure Builder

HTML, CSS and Javascript form the "presentation layer" of modern web development in your mobile and desktop browser. These things together are considered "Front-end Development". The tools, techniques and standards are changing all of the time - but our development team is always staying abreast of the latest. For our partners, we do the research, experimentation and testing needed to make sure your audience has an accessible, fast, reliable experience.

Frontend Development

Frontend Development: Blog Posts

Developing the New via.studio

Dive into the Sanity Structure Builder