Web UI Design Guidelines with HTML & LESS.

Many of our clients experience software through the user interface (UI). During our sales process and our Research, Design & Planning engagement, we try to explain to clients the cost/schedule impact on front-end work.

In general, front-end development eats up more effort than writing the code that actually makes it function (i.e. do the thing the users want it to do). This is especially true as we continue to move down a path of dynamic web UIs and rich experiences in the browser.

Below are some things to keep in mind with front-end design and implementation:

  • The client will most likely continue to ask for more features/changes for as long as they can afford them.
  • If the software is architected well, future changes will take less time than earlier work.
  • If the software is not architected well, future changes will take more time than earlier work.
  • The client will establish a mental time estimate for future work based on the time it took to complete earlier work. The client is likely not familiar with software architecture, and may not already be aware of the previous two points.
  • Therefore, if future work takes longer than previous work, the client will be disappointed.
  • On the other hand, if future work takes less time than previous work, the client will be pleasantly surprised.

In order for new features to require less work rather than more work, you need to expect new features early, and architect accordingly.


Web UI Design Guidelines

1) Use different files

Placing all the LESS mark-up in one file makes editing very difficult. You can place your mark-up in many different files and then combine them when compiling to CSS. Using different files will encourage better architecture and adherence to the hierarchy as well as help onboarding developers understand the structure quickly.

2) Assign all your colours early

Given a style guide, you can create variables for all the colours used in the site. I prefer to name the colours according to their function rather than the colour that they represent. This allows sweeping colour changes without much work. You can even assign two functional names to the same colour to prepare for future changes. For example, let’s say you are using #f0f0f0 (light grey) as both a background colour and a border colour. At the beginning, you create two variables for this light grey. Then, later you decide that you want to darken the border colour, but not the background colour. You can change the value of the border instances without having to manually check to see if each usage of the light grey is a background or border.

Here, I assign primary and secondary colours. I give the shades of grey colour respective names because every site is likely to use grey-scale colours in some aspect. I then assign the colours to functional variables that I will use throughout my mark-up.

3) Stack ID’s and selectors appropriately

If an html tag with a particular ID only appears inside of another tag with a particular ID, then the selector should be placed inside that parent ID.

Placing the tags inside another will ensure that related code is nearby, and it will allow developers using IDE’s to collapse the parent when they are not working with that section of the site.

This goes for classes that only appear in a specific location as well.

4) Avoid using nth-child when the n is not included in the formula

If using nth-child to describe a particular element, instead assign a class name that describes that element. Assigning a class name to the element allows another element to be inserted before it, the styling to be reused elsewhere, and that particular element to be placed inside a wrapper div without slowing development of a new feature/change down and instead speeding it up.

Here, “.small” is reusable and resilient to neighbouring changes.

In the next example, the nth-child selector is best used programmatically, instead of rigidly.

Here we easily get alternating background colours without additional mark-up.

5) Genericize reusable entities

The most common example of this in our work at eForge seems to be Modals, Tables and Icons. With properly abstracted mark-up we can create new instances of these entities much more quickly. If mark-up is over specific, often developers will copy / paste the code and then edit it from there. They find themselves trying to grab various parts of the original mark-up to construct their new entity and will work against the existing mark-up instead of with.

Working with the same example used above:

Here we create a selector that looks for tables with the “default” tag. I have required the default tag so that if there is an instance where the developer needs radically different styled table, they do not have to work against the table mark-up used elsewhere on the site.

Looking at the next example:

We can see a generic modal layout defined by the “modal” class. And then below we see an alteration of that class used by a “specificModal” ID. Within the html mark-up of #specificModal we can use the same html components described by the generic modal class.

Icons especially are much easier to work with when properly architected and placed at the top level.


Here we can easily add the copy and edit icons to any part of our html. Adding a new icon, as well as changing the file name or any other aspect of the icons, can be done easily. Any special cases should be handled inside of the mark-up related to that part of the html. Having icons declared deep inside a table creates more work later on when that icon needs to be reused.

As far as possible, elements should be made reusable and defined at the top/master level. More page specific styling like padding and margin around the element can be handled in the page specific mark-up. The guidelines and tips in this blog are meant to help you with front-end design and implementation and when using HTML and LESS.

Previous PosteForge Glossary: API (Application Programming Interface).
Next PostThe future of IoT and Enterprise Mobility.