Frontend development has long been the cuckoo’s nest of the Internet community. Neither mother design nor father development really knew how best to deal with this scion, who needed its own language and rules. The main point of contention in education is “Does technology determine design or design determine technology?”
The solution to the problem lies, as so often, in a change of perspective: Brad Frost specialises in mediating between design and backend development. The web designer from Pittsburgh is co-founder of the Patternlab software and ideological father of Atomic Design, with which Frost wants to establish a new method of web development in the multi-device landscape of Web 2.0.
The core of the Atomic Design method is to understand a web product not as a collection of individual pages, but as a design system. For this purpose, Frost recommends splitting each interface into its smallest components. This formulation does not coincidentally resonate with associations from chemistry. This is exactly where Frost takes the analogy of his method.
The smallest unit, the atoms, are simple HTML tags, such as an input field or a button, a font size, or a colour. They can only be changed in one place at a time and can, therefore, be combined in many ways. The combination of several atoms forms a molecule. For example, the combination of our button atom and the input field atom results in a simple form. The combination of various molecules creates an organism with a much more complex interface. One level higher are the templates, which can be filled with concrete content and thus transformed into complete pages.
The Atomic Design forms the basis on which all participants can understand the language and rules of our metaphorical cuckoo’s nest, front-end development. This begins in the concept phase and continues through design, front-end and back-end development throughout the entire process. On the one hand, this approach provides structural advantages that can facilitate the workflow: terms are standardised across departments, components that have already been designed can be reused, and parallel work is made much easier. On the other hand, the overall effect and maintainability of the product are improved. The reusability of atoms, molecules and co. makes it possible to maintain a uniform style, even if a project moves across different desks. This creates a uniform look and a consistent code base that is unaffected by design changes, personnel transfers, and parallel work. All this has a significant impact on the efficiency of a project!
The basic requirements are a careful documentation and sorting of the individual design atoms as well as contemporary tools such as Sketch, Zeplin and Invision, which, in contrast to the image editing tool Photoshop, support the planning and implementation of websites independent of the output medium.
At TALLENCE we use the Patternlab tool to maintain a pattern library. This gives us many advantages in the static frontend:
Quick orientation: the clearly arranged pattern library enables new colleagues to immediately get into a project. Existing team members can easily recapitulate completed projects. Stakeholders, editors, and developers get a quick overview of what’s going on.
No code duplicates: in the Pattern Library, each component occurs only once. Identical components with only slightly different characteristics are deleted to avoid additional code.
Less training: the HTML can be handled modularly without frontend developers having to deal with backend template technologies (JSP, Freemarker, etc.) for any CMS.
More consistency: by reusing the same modules, the style guide is easily adhered to, even if several developers are working on the project across different departments. Deviations from the concept can also be quickly identified and corrected in later phases.
Easy scalability: the system can be expanded in a structured way by new “atoms”. Components can be subsequently created, maintained, and tested in the pattern library.
With Tallence AG, Atomic Design has become essential. In teamwork it gives us the reassuring certainty of working quickly and efficiently, as new team members can mentally get into the project more quickly, components are not unnecessarily created multiple times, and working in the frontend is all in all incredibly simplified. The creation and planning of individual atoms initially requires a lot of time. However, the modular principle makes it possible to quickly and easily assemble the atoms within the process, which saves time many times over.
For us, Atomic Design is therefore the most constructive way to avoid spaghetti code and code duplication.