How to make Client First fly

Before I start, and to give you some context, a little about me:

I have been designing websites since 2010 and using Webflow since 2014, when there was no CMS and Sergie Magdalin had some hair. I was a no coder, sort of fell into web design by accident and wouldn’t understand CSS if it bit me in the arse. (ass).

I have designed over 300 websites for local companies and manage around 80 active websites which are either hosted by me or Webflow. I rarely develop sites for other designers and never collaborate on Webflow sites.

“Oh, so that’s why you don’t like CF then, Hywel?”

Well yes, but there’s more: why is CF – and frameworks in general – so complicated? Why should we have to learn so many global and combo classes to get work done? How often do we have to dive into the Style Sheet to try and figure out which class needs to be applied to a given element?

And, most importantly, do these frameworks actually make us work more effectively?

The Background

Have you ever downloaded a template from Webflow? It’s a nightmare. Classes all over the place, strange measurements, lack of responsiveness. It did it once for a client years ago and still have to manage the sodding thing for him.

There may be a bunch of devs out there who have been using tried and trusted class systems like BEM for years and swear by it, but, given my experience of coding from other devs, most don’t stick to any sort of practical system, and this is why Finsweet decided to act. And fair enough.

The Client First System

FS divides the elements into four types:

• Utility Classes – ie the characteristics of an element eg padding-global
• Custom Classes – name a specific element designed for a specific job eg footer­_column
• Combo Classes – a variant of abase class eg is-blue when added to button
• Global Classes – a class that applies a style to pretty much any element

The last two are standard features in Webflow and I don’t have major problems with these, although I shall outline how the use of Global Classes can turbocharge any build a bit later.

Custom Classes are also, IMHO, OK. Footer_column seems a fine way to describe a column in a footer as does nav_link. Some of the descriptions seem a little long-winded, but they make sense.

No, my issue is with the use of Utility Classes and, just to be clear, these are described by CF as:

“A utility class is created for a specific combination of CSS properties, which can be applied to elements across the project. For example, a class for background-color or a class for font-size. Utility classes will not use an underscore in the class name.”

That sounds fair enough, but look at how FS suggest you use them:

“Client-First sets a default core structure to follow across all builds.

• page-wrapper
• main-wrapper
• section_[identifier]
• padding-global
• container-[size]
• padding-section-[size]”

In other words, before a single image or text is added we have a structure that looks like this:

‍

Let’s break this down:

• Page Wrapper – what is the advantage of holding everything on the page in one wrapper? What’s wrong with using Body or variations of Body? If a page is wildly different from other pages, for instance when you want to wrap a small number of elements in a 100vh wrapper, then fair enough, but every page? If you want to reproduce the contents of the page, why wouldn’t you duplicate the page?
• Main Wrapper – this wrapper holds the content of that particular page, but again, why is it needed? FS say this is best practice for ‘web accessibility’, but how is adding multiple wrappers going to improve this?
• Section Header – or ‘Header’ as we might want to call it – at top level.
• Padding Global – and this is where CF really starts to grind my gears. Every time you introduce a new wrapper, it has to be preceded by a padding wrapper, every div, grid item, section – whichever element you want to use, there has to be a padding wrapper – and this one is for left and right padding only. I assume the use of ‘folders’ to represent padding allows universal changes throughout the site, but there are far easier ways to do this.
• Container Size – first of all, I don’t use containers, for me they belong to a pre-responsive world, but even if you do, there are far better and simpler alternatives to yet another folder with yet another variation.
• Padding Section – now we have top and bottom padding. Say no more.

I love FS’s desire to manage classes to control the overall look of the website, I just don’t think the above is the best or fastest or easiest way to do it.

Text

Here, FS have a similar approach:

“Typography classes:

• heading-style-[h#]
• text-weight-[weight]
• text-size-[size]
• text-style-[css-property]
• text-color-[color]
• text-align-[alignment]”

Thes are all great naming conventions, but how many combo classes would you have to add to adjust for text weight, colour, size and alignment? Three, and is that logical? Give the text a descriptive name, ideally based on characteristics not location. Finsweet agree on this and recommend avoiding class 'stacking'.

Measurements

FS suggest the use of REM and I agree; it’s great for text size. It honours the visitor’s browser preferences and produces great results on various breakpoints. But for padding, margins and spacing?

What’s wrong with using vw for screen width and vh for screen height? They are both responsive measurements, something REM is not. Through its association with Body font size - 1 REM = 16 pixels (eg) - and why use pixels, for pretty much anything today?

I think I know why – tradition that’s why. Over the forty or so years of the internet we have two disciplines involved in the production of websites, the designer and the developer, and work is passed along the chain from one to another. Designers tend to use systems like Figma, Photoshop, and XD for design – all using pixels for measurements – and, although design systems are getting better at producing responsive designs, they have traditionally required the developer to convert that fixed measurement to something responsive or, that old maxim: pixel perfect.

This leads to the complex maths involved in converting pixels to REMs. So why use REMs for horizontal and vertical measurements? You are using pixels again.

Improvements to Client First

Lots of elements of Client First are excellent. I love the desire to make things simple, reproducible and understandable but I don’t like the complicated folder structures and the multiplicity of classes.

(I am also conscious of the fact the FS recommend a slightly more relaxed approach on smaller sites, so fair play for that comment.)

So, what would I suggest to improve things?

Site Structure

When deciding on a classification system for a website, I consider two areas:

1. Is this a large, complex site?
2. Will others have to work on this site?

If you are working on a large, complex site, then a decent classification system is important, even if you are the only person working on it. You need to adopt class standards that are easy to remember and easy to change. A small one-off site needs fewer rules, but why change the principals?

If other people have to work on a site, then a descriptive system is required and CF is a good starting point, however CF’s massive Client First instruction site leads one to suspect that most  of the 1.7m Webflow developers – won’t have spent their time learning the craft between doing paid work.

So, how do we improve this thing?

Small Site – One Dev

Use whatever system you like. Having said that, I will always use the same system – see below.

Small Site – More than one Dev

As above, but with more descriptive naming conventions.

Large Site – One Dev

Structure naming conventions as below.

Large Site – Multiple Devs

As above but with more descriptive naming conventions.

Recommendations

• Stop using multiple folders. If the CF folder structure encourages the use of six folders as above, use a descriptive naming convention as a single folder instead – eg ‘standard-wrapper’. Any variations of that element could use combo classes to nail it down – ie flex-vertical. Any changes to any part of the folder – ie padding will be changed across the site.
• Stop using top/bottom padding, instead use 100% width vertical spacers. I use ‘vs1’ or vertical-spacer-small’ as the naming convention, but the excellent Timothy Ricks suggests an alternative; wrap the element (eg an H1 title) in a single padded element. Although this approach is more like CF, it is used on a much smaller scale and can be very effective.
• Stop using multiple Combo Classes – text-color_blue, text-size_small etc – if you have to add more than two combo classes to text, change the name to a descriptive class name like header_text-contact. Rejigging buried Combo Classes is a painful experience.
• Start using Global Classes more. These are very useful as they be applied to text, images and elements. A padding or colour class can be added to anything – either the wrapper a text box sits in or even the text itself. As above, if you have to apply multiple classes then name it using conventional and descriptive class names.
• Use simple global classes for text/H1 – ‘centre’, ‘right’, ‘dark’ etc. As above, add a descriptive class name if you have to use multiple classes.
• Use responsive measurements – REM for text, vh for vertical spacing and vw for horizontal spacing. Stop using pixels.
• Use a simple Style Guide with descriptions if the site needs to be shared – eg ‘pd1’ for small padding, sh1 for default shadow. Don’t have dozens – just enough so you can remember and use them without searching.
• My Style Guide below has examples of all the classes I use and is stored as a template.  I then duplicate and rename the template when I’m starting a new website.
• As I use divs not Webflow’s ‘Sections’, ‘Columns’ or ‘Containers’, I have four simple element widths – col1 (100% wide), col2 (45% wide) etc. They default to ‘vertical’ flex divs, but I use a ‘hor’ combo class for horizontal divs.

Examples

I used a CF cloneable to produce a website then adapted it to fit some of my ideas and this how I changed things:

‍

• The CF version puts the main section – home-header_component – inside five folders. Imagine working on this site from fresh; you have to climb through the layers to find the key element. In the simplified version, I have placed the section wrapping the grid on the Body; simple.
• In terms of naming an element, I think of ‘reusable’ and ‘one-off’ elements. The above section is a one-off; it only exists on the home page so I have named it home-page-hero; easy to understand for anyone coming to the site. If it were a reusable element, then call it ‘hero’ and use Webflow’s excellent Components to update the variations.
• Other sections, again, deep inside multiple folders, all have different names and yet they all have virtually identical characteristics, so I created one reusable folder with a descriptive name – standard-wrapper - which describes the element itself not its location. It begs the question: why have six identical elements all with different names? And why name them after their location not their characteristics?
• In my example a standard-wrapper is a div flex box horizontal, but changing to vertical just means producing a similarly named element which describes its characteristics eg standard-wrapper_vertical. (Or use vertical-justification as a combo class if you prefer.)
• On the same subject, if you work like me then it’s useful to remember a small number of reusable elements on a site; this means you can create or copy new sections, the characteristics you are aware of, anywhere on the site, quickly. If you name multiple elements based on their location then you would have to keep checking to see if they represent what you are after. It’s easy to remember ‘standard-wrapper’, it’s not so easy to remember what home-header_content represents.
• Notice a couple of other easy classes I used – ‘white’ on a standard para and H1 element and vs1 (vertical spacer 1VH high) as a spacer. I don’t add top or bottom margins to text so I know where I am. If a space is required I simply add a VS element of whatever size is needed.

Final Thoughts

Although I am not a coder, I have a suspicion that I work like one. I sort of expect that a series of simple keystrokes should produce what I am looking for, rather than faffing around with a mouse.

I don’t have to check on the correct naming convention in the Style Guide to make a paragraph centred, I just add ‘Centre’ as a global style to a paragraph – or the blindingly obvious ‘Caps’. I just add pd2 to add medium left and right padding to an element then add a quick vs1 as vertical spacer.

My system reminds me of Wordperfect 5.1 – yes I just about remember it. It had a series of keyboard commands which allowed you to change any element you like with the flick of keystroke. Legal secretaries loved it; it was an incredibly fast tool – much faster than the program that took over, Word.

I have worked in a number of software houses and one thing I remember so vividly wasn’t the software, it was the customer’s reaction to the software. While the devs showed off the updates with pride, the customers would cringe. Making software easy to use is the key to a great system and I feel my way of working does just that – makes development and even design, faster and more efficient.

Frameworks should offer two things: consistency and effectiveness, in my opinion complex frameworks like CF and Webflow offer the first but don’t address the second. Unless you are in a large, sharing organisation, I would suggest you consider a simplified system as above. It works for me.

What do you think?

‍