What it is
The content management system behind the websites we build at Animikii. It gets used twice over. Our developers build and customize a client’s site with it, and once that site is handed over, the client uses the same tool to run it day to day: text, images, settings.
It ran for about three years before the company decided to rebuild it on a new platform, so the version I worked on is retired now.
Where I come in
I was one of the developers on the CMS team, working on its interface, for about three years, which was as long as the product existed. I was also building client websites with it during that time, which turned out to matter more than I expected.
Two kinds of user
A developer customizing a site and a client changing a paragraph want almost opposite things from the same product.
The developer side included a code editor: access to the files behind the site, custom code, custom fields. It needed to hold everything, because anything it couldn’t do became a workaround somewhere else.
The client side had the opposite requirement. Someone who has never written a line of HTML needs to change the text on their homepage without feeling like they might break their own website.
We couldn’t remove the code editor from a client’s view. The software didn’t allow it, so hiding it outright was off the table.
What we could do was demote it. We pulled it out of the settings and away from the screens a client works in day to day, so it sat somewhere separate rather than sitting among the things they are meant to touch. Not hidden, but clearly not part of the daily route. Position did the work that a permission would have done.
Blocks, images and files sit at the top where a client works. The code editor is at the very bottom, past everything else.
Liquid templates on the left, and a panel for creating custom fields on the right.
Redesigning the UI
The version we inherited was raw code. Not dated, not ugly exactly: just unstyled. No considered button shapes, no colour decisions, none of the small details that tell you where you are and what is safe to click.
We built that layer as front-end developers, which is the part I like about this project. The design and the implementation were the same job.
Before: unstyled defaults, square edges, no considered hierarchy.
After: considered controls, clear grouping, and a visible sense of where you are.
Organizing the settings
The settings were the other half of it, and that problem wasn’t visual. It was that everything sat in one undifferentiated list, so finding the thing you needed meant scanning all of it.
We grouped them. That sounds small written down, but it is the difference between a page you read and a page you search, and it was the change people noticed most.
Before: every setting in one undifferentiated column.
After: grouped into collapsible sections, so you open one rather than scan all of it.
Building with our own tool
The most useful thing about working on this CMS was that we were also using it. Every client that came to Animikii wanted something slightly different, and building their site meant meeting the tool’s limits first-hand rather than hearing about them second-hand.
That is where a lot of the work came from. Features we added because a real project needed them, and bugs we found because we hit them ourselves, before a client ever could.
The clearest example was custom blocks. Sometimes a project needed something the CMS had no way to build, so we built it for that project alone and labelled it a custom block.
The label was the design decision. Clients had no access to the code editor, so they couldn’t see how anything was made. Marking a block as custom told them this one was built for them specifically, that it wouldn’t behave like the standard blocks, and that it wasn’t something to expect elsewhere. Without the label it would have looked like every other block until it didn’t act like one.
What the software wouldn’t do
Some of this work was shaped by what the tool couldn’t be made to do, and the honest version of the story includes that.
The code editor had no version control. Editing through it meant working without Git, so in practice we did that work in our own text editors and treated the in-browser editor as somewhere to read rather than somewhere to work.