Why I custom code my personal sites

The static route

When I built my first website, I wrote all of the HTML by hand. At that point, it was just HTML. It was annoying to replicate the navigation bar across every page, even though I only had a few pages to update.

I tried a few different methods, such as using frames, and adding the common code via Javascript. I also tried reducing the number of pages on the site that I needed to update, by adding a dropdown and opening some of the pages in a new window, sans navbar. The Javascript method stayed on the site for quite a while.

Continue reading “Why I custom code my personal sites”

Advertisements

Rebuilding the post editor at City AM

When I joined City AM, one of the first things I experienced was the post editor. It did the job, but it was not particularly quick or intuitive to use. We had to add new fields in a predefined way – and doing so usually added extra work for the content team. Plus, there were a number of tasks that had to be done outside the system – such as finding and resizing images from Getty.

I knew we needed to take a radical approach and consider scrapping the existing post editor.

Continue reading “Rebuilding the post editor at City AM”

The Washington Post: publishing observations

There’s a good story over at Journalism.co.uk on the Washington Post redesign (“New WaPo ‘flexible’ homepage completes site redesign“).

Here’s a quote that stands out:

If you’re going to be quicker, agile and innovative, you can’t be in a place where it takes you six months to build something.

I’d agree with that, and I’d add that it’s risky to have any lengthy period of uninterrupted development. Even one month is a long time, particularly for a small team where time is so precious. Big projects need lots of work – but it’s not just about completing the task, it’s about doing it right. Even with perfect project management (is anyone perfect?) it’s surely better to spend between a few days and a couple of weeks building core functionality, and giving the primary user(s) an early demo to see if you’re on the right track.

In terms of the platform that the Washington Post uses:

The publishing process on the outlet’s website is now entirely powered by Arc, a collaborative tool developed by engineers and journalists

The Post uses WordPress for 70 per cent of the content it produces – Arc integrates through APIs with WordPress and other platforms, such as the Washington Post recipe or quiz database.

Emphasis mine. If WordPress still powers a large part of the process, then it’s not entirely powered by Arc. It sounds like WordPress is largely used for the back-end CMS with some custom tools added onto it, while the front-end of the site is entirely bespoke.

If that’s the case, then that makes a lot of sense – mainly because I think it’s far better to build a theme in Twig than in pure PHP.

Based on this assumption, I’ve updated my CMS usage chart to include the Washington Post.

Why an off-the-shelf CMS might not be the best choice

I’ll be writing more about bespoke CMS development in the future. For now, here’s a quote from a relevant BBC Academy article:

The CMS software market is quite crowded, with a huge number of products competing with each other. Despite this, we struggled to find a CMS that met our requirements around flexibility, multi-tenant operation and integration with existing services. Those that did come close also provided a vast array of other features that we did not require (such as rendering systems), which would end up complicating our architecture and adding a support burden.

In addition, off-the-shelf CMS tools generally have quite fixed user interfaces, which are hard to customise. We knew that ill-fitting user interfaces could be a real problem for our users, and we were determined to provide them with a system that allowed them to get on with their jobs without tools getting in their way.

from “Content Management Systems at the BBC