The alternative to web design frameworks

I'm quite particular about the code I write. I have preferred naming conventions for styles and classes. I have preferred patterns for HTML.

I like my own approach to organisation. I don't like to include anything I don't need or understand. This means I have a love-hate relationship with pre-built frameworks.

I love the idea of a set of CSS/HTML/JS files that allows me to get client projects up and running quickly, consistently and responsively. But in practice, most frameworks contain more than I need for the types of projects I build.

It takes me more time to adapt to using a framework than I have ever found worthwhile. A pre-built framework makes it difficult to understand why a given technique has been used, which can make it harder to troubleshoot or even customise efficiently.

The conventions in a framework – while great for rapid prototyping – rarely work for my production code.

In this article, I'll explain an alternative to using pre-built frameworks that we at Bright Umbrella call 'Starter Files'. But first, let me explain how my own workflow has changed over time.

Old and new workflows

Historically, I relied on a manual process for building new projects: choose the most recent completed project that shares common elements, copy, paste, tweak and repeat.

At the time, not many of my clients were asking for responsive sites, so the frontend work I was doing was fairly traditional. Static wireframes became visual comps. Visual comps became frontend templates, which were then integrated into a CMS.

It was about 18 months ago I found I needed to rethink things. The vast majority of my clients began wanting responsive sites. This coincided with me hiring my first employee, Lea Alcantara. These two business changes meant I had to alter my frontend workflow.

Need to standardise

Not only did I need to standardise and document everything so Lea knew what the workflow was, I needed to adapt the workflow itself to leverage Lea's skills. For example, Lea's workflow as a designer includes making decisions about visual presentation earlier.

When working on my own, I relied on visual comps to define presentation. But Lea wanted to get those decisions into the workflow sooner, using what we now call 'element collages' , which are a hybrid of Dan Mall's Element Collages and Samantha Warren's Style Tiles.

The fact that my clients wanted responsive sites meant more of our project deliverables had to be web-based. We moved from static wireframes to web-based wireframes inspired by nGen Works' Live Wires. Our element collages are also web-based. Then, to support clients with internal dev teams, we began providing web-based style guides. Almost overnight, the number of web-based deliverables we created went from one to four.

No longer was it only the frontend templates that relied on HTML, CSS and JS. Now we had to maintain code for wireframes, element collages and style guides too. Copy-paste-tweak just wasn't an option, nor was keeping these deliverables siloed.

They all featured at least some common elements in terms of markup and styles, but they were all independent of each other. Changes made to one of those common elements would need to be replicated four times.

Managed solution

We needed a managed solution that would tie all of our web-based deliverables together with a single code base, so prototyping code easily evolved into production code. The solution also needed to:

• Rely on our preferred coding and naming conventions
• Include the assets we need, and only those assets
• Rely on techniques that we understand, can explain and can troubleshoot
• Define and document internal standards
• Scale from projects that need only one deliverable to those that need all our deliverables
• Cater for new projects that could need a new type of deliverable
• Limit repetition
• Let us focus our energy on custom work
• Let us set up projects faster and deliver faster

Next page: enter starter files...