Before I get in to the fun part: design, I wanted to test out how managing the content of an issue might work with some light prototyping with Netlify CMS and Eleventy. I first thought to myself “This is easy—the issues can just be like blog posts”, which is absolutely right, but, in danger of using a term that makes me want to be sick in my mouth: it doesn’t “scale”.
In the future, I want folks to be able to find items that appeared in previous issues, so if all of the content per issue is in markdown, it’ll make that job very difficult for me. Luckily, Netlify CMS has a list widget which allows you to nest other lists. This gives you some pretty sweet structured content, which means I can add tags per item!
The admin interface for this is pretty decent, too. I can also quite easily manage the content in the markdown file, manually because it’s all front-matter based. Already it’s 100% easier than managing content with Curated. Happy days.
This flexible content system and CMS interface very much reminds me of Kirby CMS, which I’ve had a lot of good experience with. Having loads of flexibility with content, while also benefiting from the speed of a static site feels like a real winning situation.
It’s important that I get this content setup right because managing content needs to be very easy, and having flexible content will give me more freedom to provide handy features for subscribers in the future. I think I’ve managed to tick all the boxes with the early work here.
There are 3 main contexts for Piccalilli:
Because of these very different contexts, I need to handle things a bit differently with Eleventy. I’ve used environment variables to determine wether I’m in a web or email context. This has allowed me to conditionally render certain stuff depending on where I am.
This will be really useful when I’m sending issues to people because in the email context, I can provide unsubscribe links and links to the web version. In the web context I can provide a signup form and links to the archive along with a modern CSS powered UI.
One thing I absolutely don’t want to do is have separate codebases and I also want the content to be shared between all contexts, so this setup seems to be ideal.
In terms of markup: I should be able to share that between all contexts and use CSS to deal with the differences in UI. Good ol’ progressive enhancement will be stepping in to make this process a doddle, too.
Basic front-end of issues in place permalink
The last thing I’ve done before I move on to more design stuff is throw together some basic front-end markup for the issues. Well, the main content of an issue anyway.
I wanted to test the viability of the front-matter powered content and I’ve got to say, it was a dream to work with, thanks to Eleventy and Nunjucks. Creating a version of what I’ve already got with Curated took only a few minutes. Because the content is structured, I can now start to really improve how the markup works and also give myself a bit of design flexibility.
Now it’s time for me to start doing one of my favourite parts of a project: design discovery 🎉