From structured content to working front-end: just how fast can you go?
A case study in thinking about your content model really, really early
You’ve probably been there:
- Your content is information, and it has an inherent structure. This is something you more or less know from the start, even if it isn’t perfectly formulated yet.
- The way this content should be communicated is still up in the air. Exactly which bits to communicate, which content should be shown together (not necessarily the same as the content’s inherent structure), and how people are going to navigate it — all this is heavily dependent on who users are, and their needs. You don’t quite have this information yet, though you may have some posits, reckons or hunches.
Is it too early to build something?
Nope. Because (1). You have the content and its inherent structure, at least to a first approximation.
This was a real project.
Working with Heidi from NTB Arkitekst, we stuck some content in Trello. This was really just intended as the skeleton of our eventual content, a visible and more easily-parseable version of words in various Google Docs and knowledge from our own heads.
But this turned out to be okay content. It was in a way an unscoped, unprioritised, undesigned version of the thing we thought might be needed.
Trello is a good container for basic structured content … up to a point
If your content is not bananas huge or complex, you can do quite a bit of content modelling in Trello. You can have containers for content (cards), which live inside bigger containers for content (lists). You can use vertical ordering within lists, and horizontal ordering of the lists themselves, to convey some kind of structure. Where you want to create “see also”-type connections, you can link one card to another (it’s a bit clunky, but adequate). You can even use coloured tags for coding cards, for example to indicate different content types.
In some cases a well-worked Trello board can be a deliverable, where the board is a content map, an information structure, or a product backlog. Or all of those things. But if you want to be able to manipulate your content according to user needs, and show different views on the same content, Trello is not enough. So I wondered: how do we get from here to something that is basically a functioning prototype? How few steps are required?
The plan
- Create a Trello board to function as a bucket for all our thoughts, a “here’s all the stuff we might want to include” container. You can have several contributors, and it’s a simple UI to navigate. At this point we’re not too precious about scope, because (4) hasn’t happened yet. Trello is just somewhere to put our first attempts at content, and content structure, without deleting ideas too early.
- Export content from Trello to JSON (in retrospect I should have remembered from last time that one does not merely, but we’ll get to that)
- Create a Sanity project to handle content structure, interlinking, and assets more elegantly, and upload the JSON data to populate it
- Make a front end when user needs, business priorities and project scope become a bit clearer. What you want is to reveal the right content in the right context, in a way that conforms to user needs. When the project began, we didn’t really know enough about this yet .
In good design tradition, let’s talk about the transitions between those states rather than the states themselves. Transitions are usually when 💩 hits the 🎡.
From Trello to Sanity
Originally I was just going to knock up a quick Sanity.io instance and copy/paste the content from cards in Trello. This I rejected as being inefficient and error-prone. Hahahahahaha.
When I exported to JSON from Trello (you do this by choosing Show menu in the top right, then More … then Print and export) it was a hot mess. So I used this JSON prettifier to clean it up (remember: don’t paste sensitive data into some random tool on the internet).
Of course ‘cleaned up’ is a relative concept.
I spent a couple of hours trying to clean up Trello’s JSON data before realising that in a file with several thousand lines — which should have been a couple of hundred — this was a fool’s errand. Someone can go ahead and write a script to clean up Trello JSON output and turn it into well-structured, non-redundant, non-versioned JSON or NDJSON anytime. Anytime. Please.
From Trello to Sanity, redux
Write your data schema in Sanity. This took at most an hour once I had sketched out my ideas on paper — it should probably only have taken 15 minutes, but there’s something about writing out data structures in code that is just more involved than doing it as sketches, so I usually end up rethinking as I go.
And then just copy and paste your content from Trello, for goodness’ sake.
NOTE: You might be wondering why I’m not suggesting using Sanity as the idea bucket, instead of Trello. This is deliberate. If you haven’t quite nailed down your content model yet, it may be too early to enter lots of content, because changing your data schema beyond just adding more stuff might mean that content you’ve written gets deleted. If you’re a developer, or working closely with one, you can migrate data out of Sanity, and reshape your dataset. But if, like me, you’re only quasi-technical, then do your experimentation on a small scale and no one gets hurt.
From Sanity to front-end (aka “It’s never too early to discuss your content model with developers”)
Early on, I wanted to know how much time it would take to render some kind of crude but functioning front-end, so we could make a testable prototype using real content. Given the modest project budget, anything over a couple of days’ development effort would eat too much money. On the basis of my Sanity content model, I made some quick, dirty sketches to specify how complex it was — not very, in the schema [sic] of things:
“Eh, maybe a day, maybe two” said my friendly developer colleague.
This seemed like a no-brainer:
- The investment of time was relatively small, for large potential gains. With a functioning prototype containing real content, you get user feedback on the content itself, the content model, and the presentation layer — long before anything real is put in production. This gives you a chance to iterate based on reality, at low cost.
- A much richer deliverable. Which would you as the client rather have? A working prototype containing real content, plus a real content model, a real, interactive (though not production-ready) front end, and a list of recommended changes based on testing with users? Or a PDF with the content in it and a couple of sketches about how we think you might show that content? While the latter would have been a legitimate deliverable, it would communicate much less of our thinking and intent.
- Potentially a staging area for production content. If the prototyped idea was promising, we and the client could keep iterating and developing the content right there in Sanity, until it was ready for production.
Reader, we built it.
I sat down with my colleague Tommy, a 🚀 👑 front-end developer, to outline my understanding of client requirements and user needs. I sketched badly on a whiteboard to explain the content model (relatively well thought through) and putative front end (less so). And obviously I shared my Sanity instance so Tommy could see and work with the data structure. We chatted, and Tommy wrote some code.
After half a day, we had some visible front end for the prototype.
After about a day’s development, we had a basic front-end for the whole content model, though not much useful interaction or navigation yet.
(At this point we had another day of collaboration with Heidi, and ended up tweaking the content model to reflect our evolving understanding of the client’s needs. I rejigged the data schema in Sanity on the fly during the discussion — because once you know how it works, you can.)
After one more day with Tommy, we had a fully navigable and interactive front end for our newly-updated content model.
An hour or two after that, the whole lot was out and hosted on the web, and we were writing and publishing content that the client could see immediately — if we pressed Publish 😉.
We shared our prototype with the client
We started by showing the evolution of our thoughts, from Trello board to Sanity’s editing studio to our front end. The client really liked it. They appreciated that we had taken a structured, reusable approach to content. They understood that the content, and the content model, were the essence of the thing we were building. In other words, they understood that it was too early to do much with appearance and interaction design, before we had actually tested the concept with real users, and before we knew where on the web the product was going to live.
Also it was cool to be able to add or edit content as it arose in discussion, and have it pop straight out in the front end 😉.
Prototype vs. production
A thing we discussed early on was: Is it right to spend the client’s money on building a prototype, without knowing whether the final thing going into production will also be built on Sanity? Are we setting up a prototype that isn’t aligned with the client’s reality? The client’s current website is on a whole different CMS, with a totally different content model. Oh, and also in the process of being redesigned.
Actually not too big a deal:
- You can build a front end to pull some data from Sanity and some from another CMS (and/or do clever things with APIs) while presenting a unified front end.
- You can spit stuff from other CMS’s into Sanity, and then feed all that to a shared front end.
- You can migrate data out of Sanity and into something else.
So absolute worst case, we would create a bucket full of ready-to-use, exportable, structured content, accessible on the web. Not bad at all 😄
It turned out that the client had also been wondering about these things, so it was nice to be able to give an answer that left us open for lots of possible outcomes. The client dug the idea of having portable, already-structured content as a deliverable.
This is only the beginning
But a very, very good beginning.
There are at least a couple of test-discuss-iterate loops remaining, with the client and with potential users. We need to validate whether the content model makes sense, and whether we are pitching the content we’ve written so far at the right level, so it meets user needs. That work will generate some suggestions for content and interaction design.
We have to write all the content, which will be opinionated but flexible 😅.
We need to agree with the client how the whole thing is going to fit in with their reality. This means everything from choice of CMS, to which domain it will sit on, to whose visual design/branding the final version will bear (and some of these are moving targets).
Even knowing there are more iterations to come, I’m really pleased with this.
Why? Because it went so fast. Why did it go so fast? Because we took time to develop a content model before making a front-end. Better to spend time sharpening the axe than expend strength swinging a dull one. Also the process of constructing a front end for an already-built Sanity instance was crazy quick (Tommy used React and Cerebral). Thanks also to my colleagues Joy-Loi and Jorunn for sparring and clever thoughts. And huge props to our project partner Heidi for steaming ahead and writing lots of great content in tools she’d never used before 🙌.
I’m so glad we didn’t just look to meet the minimum requirement of delivering a PDF containing the content, and sketches about how it might be laid out on the web. At the start, I wondered if we were being wildly overambitious — but all of this (apart from exporting from Trello 😛) turned out to be easier than I imagined. And everyone involved understood very quickly the value in doing things this way, so it wasn’t a hard sell.
In conclusion, I’m hoping that by taking this “structured content first” approach, we have saved time, and exceeded expectations. I would absolutely do it again next time.
In the best social media tradition, Here’s what happened next
