The 6 levels of front-end development automation5 min read
Anima was designed in part, to support developers by saving on the grunt work. Allowing teams to translate designs into workable, developer-friendly code automatically from design tools (for example converting Figma designs to HTML, Vue, or React).
In this article, we share with you some of the knowledge we have accumulated throughout the years and in this case, the 6 levels of front-end automation, inspired by SAEs (Society of Automotive Engineers). The levels are as defined in a report on “Taxonomies and Definitions” regarding automated driving systems.
The 6 levels of code automation: source
Before we dive into the levels and whatnot, let’s cover what we mean at Anima when we say ‘automation’.
What does automation mean to us here at Anima?
When talking about automating front-end development you’ve got to understand what is the scope of automation. When we say “automation”, we describe the automatic generation of code that is readable and maintainable by human engineers. This is what we mean by developer-friendly.
In Anima’s model, the focus is on automating the user interface.
What’s included in front-end automation?
This is part of the code in charge of the style of the elements. Color, size, position, typeface (for textual elements), and so on. In web development, this is usually written in CSS code.
This is the part of the code responsible for structure, hierarchy, and responsiveness. Usually described by a tree structure.
In web development described with DOM using markup such as HTML or React JSX.
One of the requirements for a readable and maintainable code is good naming.
We deliberately focus on a very specific area of code. Leaving the business logic and network requests to the engineers. Focusing on a smaller problem means that we can improve the automation process.
Right, well let’s get into what you came here for!
The 6 levels of front-end development automation
In these 6 levels, we go over how we see the current state of things and how they will evolve over the next 5 years.
Level 0 (zero automation) — the engineer does it all.
This is when engineers get static mockups, without any additional data. No red lines, no generated CSS properties, nothing other than a mockup image representing the end result.
Engineers look at the mockup image and re-create everything they see, with code. Since static images can only convey some information, much (most) of it is guesswork. That includes font sizes, as there is no accompanying data that provides them.
Level 1 (engineer assistance) — partial automation (styling)
Somewhat assisting the engineer, by providing the styling of the front-end code.
- The engineer gets an interactive webpage including red-lines and styling code snippets (such as CSS, SASS, or LESS).
- There are plenty of tools out there that provide this level of automation. Amongst them are Zeplin, Avocode, InVision Inspect, Sketch Measure, (and more).
- The generated CSS is readable both by humans and machines. It can be copy-pasted or used as a reference.
This level of automation saves typing errors and (a bit) of time. But it is still partial since it can only automate Styling (which is part one out of four).
Level 2 (partial automation) — responsive layout of the front-end code
The system produces code for laying out the interface. This means Styling, and Layout (DOM). The code can be HTML, React, Swift, Java (for Android), React Native, Flutter, or any other front-end language.
For the first time, the code can run on a device (such as a browser) and display a pixel-perfect interface that is identical to the original mockup.
Anima provides this level of automation.
Level 3 (conditional automation) — interactive parts of code generated
The system produces code for most parts (all except Naming). This means Styling, Layout (DOM), and Interactivity. The interface is interactive and animated. It’s no longer static but can have micro-interactions, animations, states, and transitions.
Level 4 — (high automation) — all code automatically generated
Automatically generated code is produced for all 4 parts of the front-end code: Styling, Layout, Interactivity, and Semantic Naming. The code should be full, clear, and maintainable (workable) by a human engineer.
Complete components can be used as-is or as a reference for the engineer. The code is readable both to humans and devices.
- Semantic Naming means that elements are named based on what they are, rather than based on accompanying data
What would you do?
In the following wireframe, try to guess the name of the element the red arrow is pointing at, when you’re finished, scroll down.
Can you come up with a good name for this element?
A human engineer would (most likely) come to the conclusion that the element is a “Profile Picture”. It doesn’t say “Profile Picture” anywhere, but since humans have seen many profile pages, we are trained to perform pattern matching to accomplish this. Machines can learn this as well.
Level 5 — (full automation) — generated code at the human level
This is where an automated system can generate code for all design specs, whereas the generated code is indistinguishable from a human-written code.
At this level when performing a code review, it should pass what is known as a “Turing Test”. This means that the reviewer can’t tell if an automated system produced the code or a human engineer.
Why does it matter?
By defining these levels, we set expectations for our customers. Front-end automation can mean many different things to different engineers. Today “code generation” means simple CSS generation for most. But for us here at Anima, code generation means much more.
By explicitly stating the level of automation (e.g code generation), we can clearly communicate in each step what we mean when we say we “front-end automation”.
Join our journey to Level 5 Front-end Automation and be part of the revolution.