Last month I posted an article on my website for the first time in a long while. In it I set out some goals for the coming 12 months. The aim was to create greater accountability for myself, track my progress by starting to write more again, whilst also practicing Learning in public again.
So how have I been getting on with each of my goals. Let's find out...
Fully transition to using Statamic for a modern content management solution (CMS).
I'm writing this article in Statamic. I have the Live Preview window open at the side, and I'm enjoying the straight forward experience of it. I'm writing with Markdown which suits my needs just fine, but it has access to all sorts of powerful content editing tools. The UI is clean and thoughtful, and because of the way I laid out the custom fields in my article collection, it has a familiarity of another CMS I'm very used to, WordPress. However the editing experiences are not the same!
Hot take time. My personal feelings are that the WordPress block editor is a failed experiment. A line should probably be drawn under it, and WordPress should think about reinventing itself. I'd argue right now that WordPress isn't delivering the best experience it could to any of it's core user bases. The introduction of the block editor was a progressive step with lofty ambitions, that I expect was aimed at combatting the slew of page builder plugins, and the rise of SquareSpace. But it feels as if it's split WordPress into at least two camps, neither of which is getting good value from it due to the compromises it's had to make. The editing experience with the blocks can be clunky, slow and resource intensive. They often aren't easy to develop or manage. On the other side there are those still clinging to the classic editor plugin, WordPress as it used to be, but that experience even with ACF is feeling very dated. More often than not you might need a combination of approaches, which leads to a clunky user interface with disjointed information placement.
The point of this isn't to necessarily bash WordPress, but to provide some context as to why someone who's spent over a decade developing websites on WordPress has started looking at alternatives. For me, the reduced quality of the editing experience is just one of a number of reasons I felt I had to make a change in order to deliver better quality websites to my clients.
There's a plethora of modern CMS solutions for developers to pick from. There's probably something to suit everyone and every use case. The main reason I picked Statamic was it's close alignment with Laravel, as that's something I'm working with most days. It meant it could slot into Laravel projects with relative ease when needed. While Statamic ships with it's own Antlers templating language, it has full support and documentation for Laravel Blade templates. Again a plus as most of my work is in Blade templates and components, making them all very portable.
On top of this Statamic has an impressive number of core features that are available straight out of the box. No plugins required. Some of my favourites are:
- Custom fields and forms all handle with Blueprints
- Real-time collaboration
- Revisions & content history
- Live preview
- Asset management with a focal point editor
- Customisable columns for collections
- Bard block based editor
- Global variables
- Automated version control with GIT (particularly handy with a flat file database)
Let alone all the developer focused quality of life benefits.
The conclusion to all this is that I'm very excited about the benefits Statamic offers for users and developers alike. I'm convinced that it can only improve the quality of the websites I build. I'd like to talk about these in more detail and time goes on, and hopefully I'll get the opportunity to do so.
It's likely no surprise to read that I'm drawing a line under using WordPress myself. From now on I'll be building websites with Statamic CMS where a CMS is required.
Create a Statamic starter theme to jump start new projects.
This started out as a fairly simple idea, but as I progressed the planning I realised it was going to be a little more ambitious than I first thought. I wanted to refine all my practices and methods, and really fine tune the front end development approach. So once I figured out the setup process for a Statamic starter kit, which was quite straight forward thanks to the documentation, it was full steam ahead.
I setup a number of sensible globals and collections, and began framing out the Bade templates. I prefer Blade over Antlers, but it's just personal preference coming from working with Laravel a lot. I figured a home, about, and contact page would be good start. Then added services, a blog, and a meet the team page for good measure. Finally adding an auth, with login, password reset, and logout. That should cover me for most eventualities when starting a project.
So I was pretty pleased with my progress until I came to write my CSS. I assumed I would just carry on using Tailwind, like I had been for the last few years. Recently though I've been finding the lack of separation of concerns (SOC) frustrating. SOC is effectively splitting the responsibilities of structure, style, and behaviour into distinct layers or files. Having everything happening in a single file can get quite tiresome. It adds a lot of complexity for you to focus on at any one time. I was also starting to realise that Tailwind was hindering my progress towards another goal, which was to stop being overly prescriptive with designs and viewports, and let the browser manage the content on the page more. Andy Bell has an excellent explanation of this on Be the browser’s mentor, not its micromanager.
The point I'm trying to make is that this realisation led me to stop developing my starter theme until I can figure out how to progress my CSS structure. In all likelihood this will probably be a more traditional approach using CSS (maybe some SASS), and just relying on Tailwind to generate utility classes. However we will see. But this conundrum also leads neatly into my next goal...
Improve my CSS authoring to be more mindful of modern browser capabilities and resilient towards technical debt.
I've been aiming to have a more pragmatic approach to styling websites for some time. For around the last decade (maybe longer) the common approach has been to define what are effectively arbitrary viewport sizes, and design websites around them. This worked reasonably well when Ethan Marcotte first coined the term "responsive web design". At that time all we really had (I'm generalising here) were a limited number of desktop screens and an iPhone. However as the years have progressed this has become a failing strategy. The number of devices available to consumers has exploded. We have everything from wearable watches, to super higher resolution large format displays. As it stands a website can be viewed on what can seem like an almost infinite number of screen sizes. There's an interesting test case here for how many different devices viewed a website in a 48 hour period. The results are staggering. This is also before we take into account all the different web browsers, and environments websites can be used in. We're no longer at a point where we can define viewports for mobile, tablet, desktop etc, the lines are too blurred and the approach to styling websites has to change. If it doesn't two things are going to continue to happen. Firstly, we'll keep on providing users with devices that don't meet our predefined assumptions a sub-par experience. Secondly we'll carry on creating a never ending hole of technical debt when trying to style websites so they look perfect on every device.
As a front end developer I've had first hand experience with these issues, I understand the problems we're creating, and the reasoning behind the need for change. What I have failed at doing is creating better dialogue with designers, peers and clients, to help reconsider how we we design for the web to overcome these new challenges. So recently I decided to buy into the Complete CSS course by Picalilli and Andy Bell. The course is about "about communication, planning and pragmatic execution", aiming to "help you to simplify design concepts and work iteratively with designers rather than the common, and highly flawed approach of static design handover". Whilst it does focus on writing CSS, there's a lot of high level thinking and advice about communication and planning to, and all with practical examples. I'm maybe 40% of the way through the course as of now, and it's been incredibly insightful. I've already been able to put several things I've learned into practice, and it's helping me feel more positive about the future of front end development.
Alongside this course I've also been going through a number of other resources to give myself a refresher. A few that spring to mind are:
As of now I have a much better idea of how I will restructure my CSS approach for future projects and my Statamic starter theme. I've also got some new stratagies on how to communicate the benefits with clients and peers.
Refresh my design skills and get to grips with Figma, in order to design at least one website myself.
I've become very familiar with Figma's dev mode in recent years. Most of the designers I've been working with have transitioned to it. I like it for the most part, it's quite easy to navigate, and has some really useful tools. It's a big step forward from the days of dissecting Photoshop layers, and has a refinement Adobe XD never quite managed.
Designing in Figma is something I have zero experience with. The UI, tools, and workflow are new to me. So there's a learning curve, but nothing too daunting. I studied Graphic Design at University and have used a variety of design software packages since then. The overall principles are roughly the same in each. Understanding the rules of design isn't something that I've forgotten either. So I'm confident enough that I will eventually get comfortable with it.
As of now I've had a dabble with it, and begun work on a new design for my own website. It seemed like the best place to start. I'm enjoying the ability to use variables, and create components. It feels very similar to how I approach front end development, and I think anything that can bridge the gap between design and implementation can only be a good thing. It's positioning and layout tools are also really progressive, again falling in line with how we think about web development.
The bigger problem I see for myself is that creatively in the design world isn't just a tap you turn on and off. You have to have inspiration and resources to pull from. An understanding of what's current, working, and what's not. It takes time to build up ideas, get a feel for the trends, and flex those creative muscles again. I've no doubt it will come again in time. So for now I'm going to continue to dabble, learn, and spend some time taking in new ideas. Once I'm comfortable with it all again, then I'll consider taking on new design work.
Build a component library for use on Laravel projects, using a combination of Laravel Blade templates, Livewire, and AlpineJS.
Before I came up with the idea of creating a Statamic starter theme I'd been toying with the idea of building my own component library. I spend a lot of time working on Laravel projects using Blade templates which has an excellent component system. More often than not we're using common components across projects to solve similar problems, albeit it with minor variations - mostly style related. Some of those components are very simple, like a button. Others like combo boxes are rather complex, and can often require a bit of time to remind yourself how they work.
So rather than digging through old projects for reference it seemed appropriate to start creating my own component library. I've tried using other libraries before but they often don't provide enough flexibility, as the work I tend to be a part of is very bespoke and nuanced.
Going into the project I was aware that this is no small task, and that it would be a slow burner. It would take time to optimise components that can be easily understood, and write meaningful documentation for them. Creating a solution to most problems is pretty straightforward, but refining solutions to be simple is never so straight forward.
I knocked up a template quickly with Tailwind UI components so I wouldn't get distracted with the design. That allowed me to start working on some initial components. I dipped into some of my previous work for starting points, and before long had a Base Layout component that would work with a number of sub layouts for things like Pages and Docs. Next I tackled Sections, Containers and Buttons.
So far so good I thought. But as I progressed I realised that this project would have to take a step back whilst I focus on my Statamic starter theme. I know that needs to take priority as it's going to help my future projects get up and running quicker and save a significant hours per project in the process. Right now that has more value.
I plan to return the component library as soon as I can. When I do I'd like to start sharing some of the approaches I've taken with components.
Write at least one article a month where I share my knowledge, or look at progressive and sustainable front end development approaches.
At this time I haven't written anything beyond last months post outlining my goals for 2025, and this post giving an update on some of my progress. This is something I really want to rectify, and I'm trying not to overcommit myself with work and learning in order to accomplish this task. I expect the easiest route back into writing is to be choose topics from my progress when working towards these goals.
Summing it up.
Wow this post ended up being a lot longer than I anticipated. I've moved the needle with a number of my goals, but I'm a long way from completing any of them just yet. Thankfully I've enjoyed writing this progress update, so I intend to carry on with a monthly review and provide updates.