Jekyll with Vim
I cannot seem to recount all the time I used to spend (and still spend) finding the right content management system for me and for the projects I do. It’s a wild world out there. It’s a mess out there. There are probably several good reasons for why everything is so fragmented, why some CMSs tend to bloat almost infinitely while others are kept so minimal that you can barely do anything besides their stated uses. Then again, for the most part, a CMS just has to get some fundamentals right. In my client work I found that these functions would be sufficient for about 80% of all use cases:
- Static content pages along with a blog/news functionality
- A clean, simple web interface for content editing
- Custom form fields for text, dates, files and images
- A way to preview changes before publication
- Multi-language capability
All other concerns are secondary or even harmful. An especially impressive example for this is the reliance on SQL-type databases. There is still no truly reliable way to keep a development and production CMS in sync that uses any kind of database. You have to hack together database diff solutions that never quite work or just overwrite you local development database with a dump from production every time you attempt to make a change. You have to warn the users or even shut down access to the admin interface altogether so they won’t make a change until your new feature is implemented. Then you need to transfer all of the changes back to the database server and cross your fingers that you did not break anything in the process. And all that jazz just for adding another form field to a certain page type. It’s maddening.
Very complex websites may need all the power that comes with this approach. I
would argue though that a complex website is all too often a badly structured
one, with lots of dead content because it either cannot be found through
intuitive navigation or it’s just plain unnecessary. The litmus test for every
website is Google. Can you find the information you’re looking for more quickly
by visiting the website and taking a glance at the navigation or by entering
that search term into Google. Without the site: modifier even. You’d be
surprised how many websites do not pass this simple test. Google wins most of
the time. Not because it’s Google but because website navigation is
fundamentally broken.
Back to my argument. An average company website does not need all this cruft. It does not need to have a database backend. It does not even have to be served on a host with scripting capability of any kind. It just needs to have an effective way to enter and update its content. That’s what customers care about. They do not care what kind of elegant coding solution you may have come up with, that you optimized the backend storage engine to shave off 168ms of access time or the file structure is now much cleaner than before. Their only question will be: does this help me get things done faster, with less friction? They want pizazz. Ideally the magic bullet to cut their workload in half. You are a magician to them and they cannot understand how a magician cannot fulfil their every desire. Surely you must just being mean and you could if you wanted to. What other explanation is there? An explanation that, while technically correct, sounds so complicated and convoluted to them that is sounds like you’re making excuses for being lazy. If the answer is anything else than a resounding “yes!” followed by a quick demonstration, what you did is probably nice but not essential. Deal with it: users usually don’t see what’s below the surface and they don’t want to. That’s what you are for. That’s what you are getting paid for. If they were capable of doing it themselves, or even understood what you are doing, you wouldn’t be needed in the first place.