Inspiration

I build my own tools and you should too

Sharing makes the web a better place. Thousands of hours of design and development time are put in each week, creating resources for the community to use; and use them they do. You can’t visit a site nowadays that isn’t using a free, open-source tool of some sort. Bootstrap? Check. jQuery? Check. WordPress? You betcha.

They’re all great resources, that allow you to throw yourself into a new project without having to think too much about the technical aspects of what you’re doing – as such, beginners love them. But what happens when you want to stop being a beginner and start taking control of the code you’re writing?

Last year I released a CSS grid framework called Melody. As I’m now working on version 2, I wanted to explain my experiences building and releasing a resource that other people now use, and why I think it’s something you should do yourself.

Why bother?

There are thousands of other frameworks out there, so why did I decide to build my own?

First of all, I was jumping between frameworks the second a new one came out. Why? Because the ones I was using didn’t really meet my needs, they all involved compromises. I wanted something to allow for really quick prototyping, that was still flexible and robust enough to be used as production code.

Second, rather than relying on something magical to do my work for me, I wanted to really understand what was going on beneath the surface.

And lastly, I wanted to give something back to a community that has happily given away free resources for years, without which I would never have been able to learn my craft.

What did I learn?

I learnt a lot.

I learnt the importance of separating and commenting my code so that it’s easily accessible to others – something I’d always been terrible with. Developers are a fussy bunch and if your code is not up to scratch, they’ll tell you. This kind of feedback is invaluable for a rookie.

I learnt about specificity, and finding better ways to write non-invasive code so that the framework doesn’t interfere with the code of the app or site that’s built on it. If you’re having to modify a framework to get it to work for you, or implement hacks to override portions of it, you’d be better off not using a framework in the first place.

I learnt about proper typesetting using a baseline in order to add some useable typographic styles to the framework. The rules I used can be applied to design of all kinds, not just the web, and using them has hugely increased the quality of my work.

And finally, I learnt about optimisation, and trying to do as much as possible with as little code as possible. The current version of Melody is just 8kb before minification. The new version is even smaller. The small file size makes a huge difference when you’re serving content over a slow connection.

What else is good?

Aside from the great learning opportunity, there have been other benefits too. It’s got me some valuable exposure, and it looks great in my portfolio. I’ve had one client tell me outright that it was the deciding factor in me getting a job – creating a tool rather than just using one shows that you really understand what you’re doing.

Developing the framework has also sped up my workflow. Because I built it, I know the best ways to implement it. I very rarely wireframe any more – in the traditional sense at least – instead opting to whip up a layout in CSS just as quickly, which gives me a real, responsive prototype to show to my clients.

And by far the best part is that I’ve met some great people, who having used Melody, want to show me the sites and apps that they’ve built with it, and to say thanks. It feels great to know you’re helping people make awesome stuff.

It’s not all rosy though…

As with any released tool there’s the inevitable wave of support requests. Generally, I enjoy dealing with these but on days when I’ve already got a full inbox to deal with, it does add to the pressure.

There’s also the risk of complacency. Having spent time developing the framework, I now jump straight into using it, even for those projects where it may not be the best fit. No matter how good a developer you are, there’s no such thing as a one-size-fits-all solution. You’ll still have to compromise or modify your tool occasionally, but having built it yourself, you’ll know straight away how and where to do it.

So what’s next?

Since taking the plunge, I’ve built and released a number of other tools. Whereas before I’d look for a tool or a plugin to solve a problem, I now try and develop my own solutions first.

If you can think of anything you need, no matter how small, find the time, and build it.

It doesn’t matter whether you release it to the public, because most of all, it’s about taking control of the code you’re writing. When you’re working on a project with a tight deadline, you don’t want to be wasting time filing bug reports or support requests. Use code that you’ve written yourself, and therefore understand, and instead of relying on a third party to help you get out of a problem you can just dive in and fix it yourself.

You’ll learn a ton of new stuff and make your life a lot easier in future.

  • Ferb, I know what we’re going to do today!

  • haromaster

    I guess I don’t really think of CSS frameworks as ‘tools’. I couldn’t image trying to build my own version of grunt, yeoman or angular etc

  • James,

    I totally agree with your attitude to “defining your tools to your process” and indeed I have my own CSS framework and HTML structure I like to use which allows me to put together sites in mere hours. However, I take a strong stance on that tools that your create for yourself should never be planned to be released to the public. My reasoning is that if you have in your head that the tool will go public, you re-shape the tool to fit they projected and estimated needs to the public before the needs and interactions you under take with the tools.

    Needless to say, I applaud anyone and everyone willing to devote time to creating a tool for the public domain’s usage. For Melody, do you have your own version of that CSS framework just build for you or is the public version the same version you use for your own projects?

    Great article none the less and a great insight into your leanings through customization.

    • molovo

      Hi Callum,

      Thanks for the comments. I appreciate your point about taking a different approach to private and public work. In fact I regularly find myself tweaking Melody for individual projects (changing the size of the container, breakpoints, switching to a 5-column grid etc.)

      The point I was making was that because I built it and understand it, I can go in and make those changes in a matter of seconds, rather than having to reverse engineer the thing first.

      And actually, I think releasing tools that you use privately is beneficial. Firstly, because it makes you more likely to get into the habit of neatening, commenting and testing your code, and secondly, because you can get valuable feedback from those with more experience, or who may have found flaws in the code or improvements that could be made.

      Cheers,

      James

  • Richard Dickinson

    Finally I find a way to contact you about Melody! It looked good and I got going well with it except I cannot get simple 2 column layout to work! My fault I know but I’d appreciate some help with it if possible.

Subscribe to our mailing list