Using structured content to prototype interface designs

When starting on a new concept or project, I normally first start by considering how the data will be structured. There are many solutions to building out data resources and APIs and in working across multiple teams, you normally have to start the conceptual process without having to wait for those endpoints to be provisioned.

In collaborating with other developers on the front end interface and components, I’ve found it’s important to have the data in a central place where anyone can make adjustments to the data structure. This starts out with typically mocking out how the data will be structured in JSON format and there are several resources to help with that.

Setting up a mock API server with Postman

You could start out with vanilla JSON and embed that file in your project but it’s a tedious and manual process to structure that data. As the data changes over time, you will likely have to revise a local copy and commit it to a repository for others to consume.

Where Postman comes in, you can version your endpoints and decide if you want them to be public or private. This makes sharing and collaborating over the API data to be much more of a seamless process and easier to manage and share across a team.

Structured content with

Another alternative to building out the data structure you need is to leverage a content management system and typically you work within the confines of that system. What I like about, you get to define your content and data schema upfront and this provides you with the flexibility to query and build data that is best suited for your needs.

The hardest part typically comes in when you need to query the data you need from an API or content management system. The GROQ query language allows you to describe exactly the information your application needs. (btw: it’s an open-source specification)

The studio deployments include caching and CDN distribution which allow you to remotely edit the content within their studio interface. You can build out your content locally or remotely with real-time previews. The development workflow is very impressive once you get the initial setup and process down.

The schema allows you to define the schema for your JSON documents. You define your documents then select from a set of field types. It’s fairly easy to reference other documents or to create array fields to store multiple items within a field. You can learn more about how those building blocks work with a few examples listed here.

GROQ Queries

Now that you have the documents created with a schema, you can now begin to edit and produce content. When you are ready to query that data, you can start having a look at how to use the GROQ query. Here’s an example query for a service document that has some basic metadata including a primary image and an array of secondary images:

    "services": *[_type == "service"]{
        title, price, slug, description,
        "mainImage": mainImage.asset->url,
        "secondaryImages": secondaryImages[].asset->url,
        plans[]->{title, price, description, planLevel, delivery, revisions, features, extras},
        extras[]->{title, price, description, delivery}

You’ll notice there are a few array reference fields for “categories“, “plans” and “extras“. You can select which fields you want back from each reference. Have a closer look at the documentation for additional front-end references and libraries.

The nice thing about using, you can have a content team begin publishing as soon as the schema is defined. Or you can simply create some placeholder content so that you can carry on with development and work out any data or schema changes you might need along the way.

There you go, these are my two favorite solutions when I am starting a new project and need a content API or endpoint. There’s no reason to wait for those endpoints to be developed when you can begin today. Start writing data that will suit your application needs and adjust as you go. ?