What is Jux?
The lack of the right tool that enables designers to design the front of the front end is the source of the problem. When even designing a simple button involves multiple tools and systems, it's totally clear that the current state of software design tools and production environments needs a significant overhaul. So we get up early in the morning to create a code-based design platform - so product designers can design the actual, real product as it will be used in production.
What is JUX to me?
Building a new design tool stems from past pains that we had in many other startups or organizations I worked at. The handoff, is the ability to make sure that designers and engineers can communicate and pull each other to new heights. I like to use internally the “Yes, and notion”. While we build a new product, the designer runs some research, and the engineer researches other things - and at some point, we all connect. JUX, is the place I think this can happen. So for me, JUX is a tool and a language to keep the members of the team aligned, communicating on the right level and each side can understand the other - so in fact there are no sides - we are a cohesive and united team.
What are Elements and why did we build it?
When tackling the handoff problem that tech organizations face everyday, we have to address the problem of communication between designers and engineers. The problem happens because designers work with vector tools while engineers write code. Elements in JUX are the basic building block for every component.
Elements have pre-built states and a pre-built set of props that designers and/or developers can use. Elements are token-less so designers can set the tokens to support their company’s needs. To allow designers to create complex user interfaces we will gradually release new and updated Elements. JUX ships Div, Text, Button, and Input at its basic format. In the following months you should stay tuned for Checkbox, Toggle, Radio-button, Tooltip, Chip/pill, progress bar, list-item/list, and more.
Let’s dive deeper
The first aspect for the design in JUX are design tokens, the second are Elements. These are the building blocks for design in JUX. In analogy, in JUX the blocks of all components are Elements and the coloring, positions and other design decisions are performed using tokens. Moreover, Elements are the “Markup” for the underline code developers will use once the Design System (DS) will be pushed to Dev from JUX. Elements can be basic “HTML-like” objects used to construct complex components and later pages and flows in the DS. In JUX we support “Atomic elements” which are mostly native HTML tags that designers can not build by themselves. For example: Input - a component that accepts real input from keyboard and that has built-in logic is not an object we can design using a vector tool. Checkbox or Toggle are another example of common components that are used by many products that are aware of some logic - one that knows the inner state of itself - checked/unchecked or On/Off respectively. To support this inner logic, Elements come with per-built props and design values (that are not tokenized) allowing designers to understand what the component is going to look like.
An element has a few characteristics depending on the usage and the needs by the product designer. Some elements support the attribute of been “nestable” meaning they can contain other elements or other components. Providing these elements are not the “atomic” type, another characteristics is the ability to detach an element to its basic other elements that constructed it. And so, the building blocks are a language f its own, allowing designers to build complex design and to build new components. For example, an auto complete input is an input that has some logic that a developer change change however a basic design can be a Div that is wrapping an icon and an input.
Why are we excited about Elements?
In 2023, when a designer wishes to create a button, the button would probably be built on some rectangle, then apply round corners and add some text. We will call it a “Button”. Now, if we are extra crafty and experienced, the "button" will be a frame that has some “auto-layout” - and he will still call it a "button". But is it a button?
When a developer handles a button? It will be something like this:
<Button
color="secondary"
variant="contained"
onClick={() => {
alert('You JUX clicked me');
}}
>
Click Me Please
</Button>
That is the core communication issue we discuss at JUX. This mind shift is the gap.
So what will designers experience?
When a designer picks an element from our list, they will see the elements. Those look like vectors - shortcuts to UI elements. Similar to vector design tools, it feels like a vector.
But it isn't! It's CODE 🫳🏼🎤
*Elements are available from our very first version of the product.
Exciting times!
