A collection of reusable code and design patterns.
The modern internet is a web of complexity, built with layers upon layers of code. Attempting to create every part of a project’s codebase from scratch can be a bit of a fool’s errand, even if it might be tempting.
While doing something innovative requires throwing everything out and starting fresh, things like grids and clearfix don’t need to be reimplemented from scratch every time you build a website.
In product design, the value you provide is solutions to problems. Re-solving basic interactions that have already been iterated on again and again isn’t providing value — it’s beating a dead horse.
Once again, we’re not trying to discourage true innovation, which sometimes does require dismantling the establishment. For 99% of projects, your biggest fear should be wasting time duplicating efforts, not stuff that was built by somebody else.
So how does one avoid reinventing the wheel? Frameworks.
What’s a Framework?
Frameworks are sets of code, usually CSS, and design patterns you can build atop of. They point you in the right direction and keep you from wasting time rewriting boring, boilerplate code over and over again.
The concept of “convention over configuration” is baked into frameworks. In a nutshell, frameworks tend to promote broad conventions. They save you from having to make a huge number of decisions (configurations) when you start building.
Good frameworks are flexible enough to let you override these conventions. However, delaying these decisions lets you focus on the more important parts of your design sooner than later.
Frameworks provide more than a form of abstracted repetition though — they provide peace of mind.
Your Framework is Only as Good as Your Code
Having a bunch of written code wouldn’t matter if it wasn’t any good, and nobody would use the framework. Since frameworks get used by lots of people, they tend to have a lot of eyeballs (and a lot of iterations) on the code.
Being bigger than any one project, the conventions expressed in frameworks are a sort of shared wisdom — a collection of community best practices. For this reason, many of the most successful frameworks are open source. There are in-house frameworks (especially at larger companies), but choosing to limit the potential size of the community surrounding a framework means leaving money on the table, in terms of the wisdom, lessons and iterations from those you exclude.
Our framework Foundation started out as an in-house style guide. But later we built it out into something more. Releasing it to the public accelerated its growth, creating something far greater than we could have produced had we kept the project under wraps.
Learning from Foundation’s example, we made Ink, our responsive email framework, open from the beginning, seeking feedback and advice from the email design community.
Common Framework Components
Frameworks typically consist of a few different categories of content. Let’s go through them.
Structural code is a big source of repetition, making it the first target of most frameworks. In a server-side web framework, this might consist of components like a URL routing function or a system of organizing files. The main structural component would be a responsive grid for a front-end framework like Foundation.
Perhaps more importantly than the actual code itself, a framework gives you a standard way of applying structural code within a project. If you’ve used a framework before, you should theoretically be able to look at another project written with that framework and be able to figure out a lot about it, due to the shared patterns and structure.
Frameworks provide common UI elements to reduce code repetition. This is obviously a bigger use case for front-end frameworks than the more server-heavy frameworks.
UIs are incorporated into server-side frameworks, especially for things like admin interfaces. Getting off the ground quickly with UI elements — like buttons, nav-bars and accordions — makes it easier to focus on page layouts and content than having to do a bunch of work upfront to get basic functionality.
Having basic styling for some common UI elements can also go a long way toward establishing the visual language of your project. While things, like colors and visual treatments, are frequently modified from framework defaults to “make a project your own.” Some of the default options, like spacing and vertical rhythm, are more generally appropriate and can save you a good deal of time.
Having pre-made UI elements also helps cover some of your bases. Frameworks by their nature tend to cover lots of edge cases. Things like possible states a UI element can be in or factors, like accessibility, and i18n can be hard to keep track of and take into account for every element in every project. Using a framework can ensure that you’re taking all the variables into account, even if it’s by falling back on convention over configuration.
A lot of what “comes with” a framework isn’t actually included. Since frameworks give a common starting point that a lot of people can use, they tend to work together and build some helpful support systems.
Arguably, the most valuable part of many frameworks is the community that develops around them. Framework communities, particularly within the larger open-source community, support the framework by developing it and providing feedback. They also often help individuals with any difficulties using the framework.
Based on the common core that the framework provides, these communities often tend to produce tangible extensions of the framework as well, such as:
- Learning materials
- Coding Standards/Style Guides
- Themes/Plugins/Code Extensions
- Templates/Sample Projects/Case Studies
Many (if not all) of these examples are present within the Foundation community. On any given day, hundreds of Foundation users will help each other out by dropping some knowledge bombs on the Foundation Forum, and new templates, extensions and themes seem to pop up almost every day.
What a Framework is Not
Frameworks do a lot for you, but they don’t do everything. Due to their increasing popularity, there are a few common misconceptions.
A Framework is Not a Template
Frameworks do provide structural code, but they’re not a pre-build structure that you can just insert content into and call it a day. Frameworks are tools to help you build something (the Legos), not a pre-built product (a Lego castle).
A Framework is Not a Minimum Viable Anything (MV*)
Frameworks aren’t magical design cloaks that you throw on your project to make it responsive, pretty or well designed. Committing to a framework usually involves building on top of it from the beginning.
A Framework is Not a Hard and Fast Rulebook
You can extend, modify, customize, abuse, and utterly tear apart a good frameworks. Your design should dictate the extent and manner in which you use the framework, not the other way around.
Frameworks Shape Your Work and Organization
In addition to the consistency and momentum a framework brings to individual projects, it has similar effects across an entire organization. Working off a framework allows an organization’s developers to develop coding standards and practices based on the actual needs of their projects, not an arbitrary, prescriptive ruleset.
As early as 2007-08, we were starting to standardize our approach to make it easier for everyone on our team to contribute to a project. We eventually built these code standards out into Foundation, a responsive, front-end framework used by tens of thousands of developers worldwide. As we ventured into the world of responsive emails, we took what we learned and created Ink, the first responsive email framework of its kind.
Frameworks give us the flexibility to use them for every project we do, while still contributing a growing library of lessons learned. Better yet, actively maintained frameworks change and grow as the underlying technology does, ensuring that they will be the backbone of our responsive strategy for years to come.
Put Your Framework to the Test
Helio lets you test designs built with a framework easily. You can send it out to an actual audience and learn what works and doesn’t.