A visual is worth 1000 lines of code
Tags: webdev, react, design, ux
Published: 2022-12-12 14:38:53

## Why we believe in visual controllers

They say “a picture is worth a thousand words”. It's a saying that attempts to describe the difference between the amount of information that can be conveyed in a visual format, and the amount conveyed verbally or textually. In short, there’s no real contest. Visuals are faster and easier to use and understand than words for almost every person on the planet. This is the reason we build user interfaces in the first place—they help people interact with our systems in ways that would be difficult via text alone.
If you’re not convinced, try to compare the amount of time it takes you to absorb the information below, represented first as text, and then in a relatively agreed upon visual representation:

`Bold: on ||  Italics: off   ||   Underline: off   ||   Text color: red  ||   Text highlight color: yellow`

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/wrtmh6i5k0xf5el1b59z.png)

The visual representation only requires a quick, almost instantaneous scan, while the text requires a few seconds of eyeballing even for the quickest reader (not to mention the additional screen space required).

When we want to design a new visual representation, we use the visual medium’s innate superiority to our advantage. And so, when we plan user interfaces, we use visual design tools (Figma, Sketch, Photoshop, etc.) They allow us to work with our eyes and hands to create the **precise** visual representation we want, all the while ignoring all other concerns (scale limitations, technical debt, performance, etc.). But their output is often completely static. It looks like our interface (often in its most basic forms), but it's miles away. To describe all its different interactions, we'd need to design it over and over again in all of its manifestations.

When we want to build the _actual_ user interface, we are limited by current tools to using text that describes our visuals, their interactions and their logic (in our case text in the form of HTML, CSS and JS code). This happens because of technological limitations, because of old habits, and because developers take upon themselves an unfair share of the burden of making the systems work. They create the logic and infrastructure, as they should, but they also create the visuals and their interactions—because they are the only ones who can.
 
What we’re left with is thousands of lines of code that describe visual information, and a gap between stakeholders’ ability to directly affect the project. The textual description of the visuals is often completely opaque to the designer who designed them. Unless they are well-versed in reading and writing CSS and HTML (and many times other code flavors like React or Vue), they can point their finger at what’s wrong, but cannot fix it themselves.

### This is where visual controllers come into play

Visual controllers are the set of tools that allow users to apply changes to code using their eyes and hands. For example, choosing a color via the mouse and a palette, or changing the size of a `div` by dragging its corners using the mouse.

They enable us to forgo the translation between visual and text, allowing us to use our senses to determine what should appear, and where. There are fewer “translation” layers, and therefore, less room for error as well as a quicker output. A designer’s eyes won’t miss a misplaced button visually. The same can’t be said for textual CSS comprehension, as good as we may be with CSS.

Visual controllers are also a great equalizer. They make design accessible and easy for people who may not know how to describe the same visuals in text format (practically anyone who has not spent years honing their front-end coding skills). They offer us a way to widen the circle of contributors, so that more of the stakeholders can directly affect the areas they own. (People who can’t make the translation from text to visual and back are often referred to as “non-technical”, but I think this is a boring and futile distinction.)

Let’s explore another example. We have some very basic HTML code of a modal that has an attribute `data-open` which determines whether it appears on screen or not. The HTML code looks something like this:

```html
<div class="container"><div class="modal" data-open="true"><!--...modal content...--></div></div>
```

But, almost no developer in their right mind would work on it this way. Indentation and line breaks are the most basic visual manipulation developers use in order to show the DOM structure in a readable way. The output is often something like this:

```html
<div class="container">
    <div class="modal" data-open="true">
        <!--...modal content...-->
    </div>
</div>
```

Now the structure is a lot easier to deduce thanks to a visual cue. With a visual controller we can go even further. We can show the conditional `data-open` in both of its possible states, open or closed, and use other visual aids to make this even easier to comprehend. The violet rail, for example, means a conditional DOM element in our current UI:


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/94mmfucmrm5xr3n3fuyl.png)

> Note: The example above is not 1:1 as in the HTML example used previously. We use React in this example because that’s what our UI currently supports, but we think it still gets the point across.

The visual representation does something that the text cannot—it can reveal what other options are available. In the example above, we can see that there’s another option—the content we can display when our conditional is false. In this case and in many others, the visual controller helps us access the different options much easier than if we just had to keep them straight in our minds.

### Conclusion

A good visual representation helps us form a better mental model. It can **help with the understanding of hierarchies** as they exist by making things that are dependent follow a visual ordering or flow. It can **group together things that are related** or that work together, making them easier to find and use, and improving their synergy. Most importantly, it can **hint at what else is possible**—what other options are available that may not jump out of the text.

We believe that visual controllers for structure and design can be helpful to anyone who participates in the interface creation process, and that this is a big part of what drives our development and design process. We believe in visual controllers.

### Come see what we mean

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/25akoj8yqnzu6tdx2r58.png)

[Codux](https://codux.com/?utm_source=arnonPost1&utm_medium=homepage) is a new visual IDE for React. It follows these principles, and combines the development and design processes into a single, faceted process. We are leveraging Codux in our everyday work to build Codux—visually editing the visual aspects of the application directly from within it. [Download Codux](https://codux.com/download?utm_source=arnonPost1&utm_medium=download) and try it out to see for yourself how it improves the UI development experience. If you want to continue the discussion, leave a comment below or join our [Discord server](https://discord.gg/fg3Ywsa44N).