Using modules in front end web programming to allow more flexibility and more independence from site layouts for content elements.
Responsive websites – which adjust themselves automatically according to screen size and even internet connection speed – are with us to stay. But designing them according to traditional logic can be difficult and time-consuming. Most designers – at least those from whom I receive designs for programming – still base their layouts around a relatively pixel-accurate desktop view.
That’s understandable, as the majority of websites here in Switzerland are still viewed by people using slightly older Windows computers… although the rise in use of tablets and smartphones is well on the way to reaching a 50% share. But putting the desktop layout in the forefront of a layout concept is outmoded. It’s critical to design a site for a client which will be usable in two or three years’ time, as the traditional small to medium business doesn’t have sufficient budget for a brand new website more often.
That doesn’t necessarily mean designing multiple individual layouts down to the nearest pixel. It means finding layouts which work well at different non-specific screen sizes, and layouts which can be extended as the need arises. By using containers for page layout and modules for individual pieces of content, there are big benefits for the programmer and for the client.
Designing for multiple resolutions is much easier if the designer imagines the page in the same way as a newspaper page or a magazine page. The overall layout (“container”) is defined for each screen size, with spaces for content. Then individual modules can be slotted into these content spaces. A good explanation for this concept can be found in this article by Nick Haley at The Guardian.
Using modules means that an individual content block can have its own rules and be defined independently from the rest of the page. If the element then needs to be re-designed, it can be evaluated and improved without changing the rest of the page design.
A good example is the front-page news module at unia.ch. When the need comes along to revise the layout and function of this module, it’s a much easier – and less expensive – task to re-work it if it’s been prepared as independently from the rest of the page as possible.
So how do you do that? Using a CMS like WordPress or TYPO3, make a custom content element to generate the backend input fields for the editor, and to generate the output HTML for the website.
In your CSS, use a unique namespaced class name – I prefix mine with the namespace mhm for personal projects and frp for work projects – and wrap all of the CSS for the module inside this class name. I advocate using additional class names for any rules which are applied across all custom content elements. (For example a set of clearfix rules or a consistent background colour.)
A basic example containing SASS rules for the news slider element above is as follows. (In my code, I’ve taken the naming FCE from TYPO3 to indicate a custom content element.)
By using CSS class names in this way, and avoiding IDs and element-level definitions where you can, you can be much more sure that the rules you apply work independently from the rest of your page CSS. A solid class name concept is essential to make this kind of coding work, but once you have that, then the rest is plain sailing.
Start off by addressing the following questions, before you start coding for a new project in this way.
- What modules are there in the page design?
- Do the same rules apply to more than one module?
- Is there a logical design concept for each module, or do you need more than one separate set of HTML for each screen size? (Preferably not!)
- What unique class name can I assign to each module, which I can be sure won’t be used elsewhere in the code? Could other plugins or extensions implement the same class names? If so, then I need to make sure and find a more unique class naming convention.