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.
Sure, there are examples of where two similar looking pages cannot be genericized efficiently, but I find that most of the time you can avoid headaches by genericizing up front, especially when a lot of time will be spent on CRUD view pages.
Web UI Design Guidelines
1) Use different files
Placing all the less markup in one file makes editing very difficult. You can place your markup 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 colors early
Given a style guide, you can create variables for all the colors used in the site. I prefer to name the colors according their function rather than the color that they represent. This allows sweeping color changes without much work. You can even assign two functional names to the same color to prepare for future changes. For example, let’s say you are using #f0f0f0 (light gray) as both a background color and a border color. At the beginning, you create two variables for this light gray. Then, later you decide that you want to darken the border color, but not the background color. You can change the value of the border instances without having to manually check to see if each usage of the light gray is a background or border.
Here, I assign primary and secondary colors. I give the shades of gray color respective names because every site is likely to use gray-scale colors in some aspect. I then assign the colors to functional variables that I will use throughout my markup.
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 neighboring changes.
In the next example, the nth-child selector is best used programmatically, instead of rigidly.
Here we easily get alternating background colors without additional markup.
5) Genericize reusable entities
The most common example of this in our work at FrogSlayer seems to be Modals, Tables and Icons. With properly abstracted markup we can create new instances of these entities much more quickly. If markup 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 markup to construct their new entity and will work against the existing markup 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 markup 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 markup 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 markup 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 much 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 markup. The guidelines and tips in this blog are meant to help you with front-end design and implementation and when using HTML and LESS.
Have tips and guidelines of your own? Comment them below to share; we’d love to hear them.