This is part of a series of articles on what I learned from making a website for Monitor - a publication platform for poetry, innovative writing and criticism based in Manchester. This post details how I rebuilt the site from the ground up using Gatsby, Strapi as the CMS and implementing a whole new look. To read the first post about how I started developing the site click here or the second post about some architectural mistakes I made click here here.
Although the approach I took with the state and data management initially for the Monitor site caused me some headaches (you can read about that here) it did help me know what I needed to make the site better in future. I needed static pages that loaded almost instantly, that could be indexed by search engines and display cards when links to the site are posted on social media. The client needed to be able to edit the content of the site without my involvement. We also had a designer who was working on the site which we were really excited about as up until now we’d done all of the design ourselves and although it looked passable it was something we wanted to look great.
All of this meant that the site needed to completely rewritten from the ground up! I couldn’t wait to get rid of all the mistakes I’d made up to this point. When I started the site I was just starting out learning out web development and by the time had come for this new version of the site I had about 18 months experience, I’d learned a tonne and was looking forward to putting some of this into practice outside of my day job working for in ecommerce. In order to meet the new requirements I knew I needed three things:
- static site generation to ensure great performance and SEO.
- a content management system (CMS) my client could use to edit the site content
- to start from scratch with the styling
Static site generation
I wanted to learn a meta-framework that I could use in a professional setting in future so I was keen to try out one of the more popular ones. I opted to use Gatsby as my static site generator (SSG) because out of the big two server rendered React frameworks as it seemed to answer my needs better than Next.js at the time. Gatsby was very easy to get up and running. Incredibly easy, it felt almost too easy. The only issues I ran into could be solved in a few minutes of trial and error. This was useful for getting things accomplished quickly but it did leave me with a shallow understanding of how Gatsby works under the hood compared to a framework where you have to get more involved under the hood like SvelteKit. The ‘everything is a plugin’ approach that Gatsby uses means connecting tools or data sources in to Gatsby is relatively painless. However a drawback of using the open source community to create and maintain the majority of the (2500+!) plugins is that sometimes these can lack due care and attention over time - we have seen this recently with NPM package vulnerabilities - Gatsby gets around this for some of the more popular plugins by supporting them in-house.
CMS
To be honest when selecting a CMS I was totally overwhelmed. There’s so many options out there and many of them look great. However these are some of the features that drew me to Strapi:
- Free There wasn’t room in the budget for a paid solution for this project so it needed to be free. Most CMSs offer a free tier but after hitting a certain limit (IE number of users/posts) you will have to start paying for usage. I didn’t want to run in to any limits so I needed a CMS that was free to use. The only downside to this would be that I would have to host the Strapi application myself, but thanks to Heroku that was easy. As the Strapi server would only be used when it’s data was being edited by the client or in the build pipeline it won’t have to take much load so should stay within the limits of Heroku’s free tier.
- Extensible React frontend Strapi’s frontend, the portal where my client can add content to the site, is built from React components so it would be easy for me to customise and extend it’s functionality should I need to. Although this was, and still is, important to me I am yet to find a need to customise the admin UI.
- Node backend I needed to get up and running quickly with my CMS of choice and as Strapi’s backend was in Node I could get in stuck in debugging should I need to. The app is built using Koa from the Express team which I already have some familiarity with so it wouldn’t take me too long to work out what was going on 🤞 . Fortunately I haven’t found the need to as it has run like a dream so far.
Strapi has worked out great so far and I know I’m only scratching the surface of it’s functionality. It was dead easy to get set up and even easier to modify once you’ve started rolling with it. I’ve moved almost every word on the site to our Strapi backend and integrated the image hosted with Cloudinary which works great. The only issues I’ve encountered with is the format in which it output Markdown didn’t play nicely with the Markdown parser I had in place in the frontend but this was an issue with parser and not Strapi itself.
The only feature I feel is lacking is a preview mode so my client can view how their content would look in place on the website itself similar to what Netlify CMS does. This works by supplying the admin frontend a component/page template that it can fill with the data passed to it by the CMS. Currently once some content on the site is edited the whole site has to be rebuilt and published before the changes can be seen. Although this process currently takes 5 minutes the time taken will increase as the site grows.
Styling
I was really grateful we had a designer design the website for us this time. As Monitor is a publisher he was influenced by the layout of books for the design and it was really fun to implement what he came up with.
I used CSS variables as the foundation for a naive implementation of a design system. Inspired by Refactoring UI I set up some spacing units based on a 16px grid. Instead of specifying concrete values for the CSS rules I declared some global variables that I could use instead. For example instead of using padding: 16px; I would use padding: var(--base); which was declared in a CSS file:
:root {
--base: 16px;
}This meant that if we wanted to change some spacing globally I could just change the value of var(--base) instead of having to find all the places I’d used 16px and changing them. This came especially use when tweaking the layout of typography and the different background colours used on each page.
Working with a designer helped me learn some techniques that I will definitely used in future. For example I hadn’t come across ‘hanging punctuation’ before. Hanging punctuation is when punctuation ‘hang’ outside of the text block allowing the first letter they contain to start the line instead of the punctuation itself. This is stylistic choice made by the designer, commonly seen in printed media, and can make text easier to read and look more pleasing.
Image credit http://missiondesigns.blogspot.com/2015/10/hanging-punctuation.html
Hanging punctuation is included in the CSS spec but is only implemented in WebKit/Safari. I would love it if it was implemented more widely in browsers but for now you can tweak that text-indent rule in other browsers to get the same effect. For instance I added:
blockquote {
text-indent: -0.3em;
}This sets a negative indent by the approximate amount of space the punctuation takes up.
Finishing up
The Monitor website is in a good place at the moment, there’s plenty of things I’d like to improve but nothing that necessitates such drastic rewriting processes that I’ve detailed in these three blog posts. We’re selling lots of books through the site and it look great.