Last week, we shared why component based websites give you more bang for your buck. This week, we’re here to talk about how we actually make component based websites. There are three parts to creating a component based website:

Analysing actual website content that clients want to use (see this article for more info on this stance) to see what types of content blocks are used again and again Designing these components but weave in more flexibility to allow for growth Creating intuitive to use component blocks that are flexible, well-defined, and well-named

Analysing Actual Website Content

Our clients work on plain text documents created in Google Drive, where they write out actual real content they want to use on the website we are creating for them.

Yes, most clients really hate this part, often struggle with it, and don’t want this to be the first step they tackle. They want to jump ahead to the design step – which is exciting, or the development step where it all comes alive. But we stand firm and ask our clients to do this first, because without this, there is no clarity in the design step, and if there’s no clarity and final decision made in the design step, the development stage can’t happen. This is the best way to make sure our clients get their money’s worth.

When people really sit down and work on their content, patterns emerge: they really like using call to actions with a visual background, or the type of information they’re sharing would often do well in two columns instead of a long single column list, or they have content that is well suited to small sliders of information, etc.

Each type of content becomes the basis for a possible component and gets flagged as such as we review the content.

Designing the Components

Often multiple types of content can be created with one component. For example, maybe clients like using 2 column lists in their content, but sometimes they also have 3. Sometimes one column is an image and the other column is text that provides context. These 3 ‘types’ of content can be created using one well-defined and thought through component.

When Bobbi designs these, she’ll often be thinking through multiple use cases, checking off the flagged types of components in the content as she creates them. Some will be obvious. Others will require us to collaborate to make sure they are actually possible in an intuitive manner.

Certain types of components come up so often that we don’t even think about them anymore. Bobbi doesn’t design them from scratch anymore and I don’t code them from scratch anymore. For example, a call to action component. Most call to action components are fairly standard, they have a background (colour or image), a heading, some descriptive but short-ish text, and a button.

Do they vary sometimes? Yes. But in general, this is the standard recipe for a call to action area. Bobbi can create these on the fly with the appropriate branding and style for a project, and I have the code for this component written already, and all I have to do is add project-appropriate CSS to style it.

At the end of this stage, Bobbi presents a component design page. This is a single page that shows the design of every major component in its most common use case. This is often the only large designed page our clients see, because it goes through all the possible components and paints a very thorough picture of how the website will look and feel (keep in mind, this is the very last part of the design step, there are many other things that happen before this to establish a design direction and make sure everyone’s on the same page).

One of these days, I’m sure Bobbi will write an article sharing how she designs things. So if you’re curious about that, sign up and you’ll hear about it when she does.

Creating the Components

This is the part where I pull up the component design on one side, make sure I’ve gone through what Bobbi envisioned in terms of flexibility for each component, and start creating these in the code.

We primarily build WordPress websites, so the following information will be WordPress centric. Like most other developers, I use a tool/framework to create custom fields in WordPress, which is how we make component based designs come alive.

My choice of tool? Either Advanced Custom Fields (ACF) or Carbon Fields (CF). ACF is my first love, and still my first choice on a large and complicated project, but CF has been slowly winning me over with time because of how much faster it is to create and modify fields. ACF is still more actively developed it seems and has much more support. So depending on the type of project and how big I think this website could get in the future, I’ll choose one or the other.

ACF has a field called Flexible Content and CF has a field type called Complex Fields. Both of these fields operate as containers that allow you to add numerous blocks that users can select and reorder as they choose. This is exactly what we want for our component based website.

Here is an actual example of components available to one of our clients. These allow them to create a rich and dynamic website with pages they can create quickly that look awesome – even if that combination of components or that order of components was one we never imagined when we first created the website for them.

When I create components, I’m also thinking through the same questions that Bobbi was asking as she designed these components:

How can I make this component more flexible? What other ways could someone want to use this component that we haven’t already thought of?

Sometimes this results in creating a component that has two tiers of options: let’s use the column component example I mentioned earlier. The design might have two columns of text and Bobbi told me that sometimes the client wants 3 columns, and occasionally, they want one image with some text on one side.

As I’m creating this, I’m asking myself: what other ways could the client want to use this? Perhaps instead of an image, they might want to add a video there instead. So then I’ll make the necessary changes to allow a video in the columns and make sure it’ll look good when it’s added. Other times it might be enough to just leave it as a fully featured text editor so that the client can add whatever they want.

The greatest thing about component based websites is that they allow clients a great deal of flexibility with respect to what content they can add and in what way, without messing with the branding or having to think about how to make their content look good. It’s the middle ground between just having a content editor where you can do anything you want and a fixed template that only allows certain things in a certain order.

If you’re wondering how I code component based websites, you should sign up for our newsletter, because I promise, that’s coming soon as well, loaded with code examples and walkthroughs.

Building component based websites isn’t a philosophy we magically always knew. We learned this with trial and error and we continue to iterate upon it and improve it. If you have a component based website or you build component websites, share your thoughts with us! Is there something we could do better? Is there something you wish your component based website did better? Send us a tweet, leave us a Facebook comment, or tell us what you think on Reddit!