Introducing Web Designers and Web developer

Being a web developer makes you learn cool tools in the ecosystem to help you build web products pretty fast to the customer market. These tools make you feel good as the thoughts and ideas from your head start flowing around with easy, hence boosting your creativity.

A developer who knows these tools are considered rockstar developer.

The skills of a rockstar developer are knowing how to build accessible components, reusable components, add visually pleasing components, with knowledge about frameworks and supportive tools.

Introducing rock bottom hit developer

Its easy for such a developer to quickly burn himself out, because tools and frameworks are meant to constantly improve the speed of building the user interfaces, however, the tool makers constantly make new changes to their API in the name of efficiency or cool ideas that come, without giving it a thought of how to solve it.

As a web developer, I started seeing rectangles everywhere, on this screen, on youtube, its all rectangles that get stacked one over the another.

Such tooling are?webpack?that helps you to bundle your source code files so that there is less performance issue on the client side, it comes with lot of nice features for each set of framework and syntax available out there.

Babel?addressed one major problem with respect to Javascript new and upcoming syntax sugar. Its all event and callbacks, however with the introduction of async and the need to support javascript on the server side new keywords keep coming. Just syntactic sugar.

At this point in time, I have hit another burn out which I didnt want to.

Self realisation

Each and everyone are creating new tools each week, and popular ones get adopted by different other tools, why not build entire tool set in my own techniques and perhaps, not be bored. The realisation I had about the tools are that its just individual’s perspective of the web ecosystem and they are doign their best to support the rest. But reading their API and trying to use it to solve a problem I have keeps getting harder, by keeping goal as less screen time.

With circling of thoughts of how to build a builder that builds a builder, an user interface that builds the user interface, with web browsers as powerful as they are now, why couldn’t I build something of my own to keep myself engaged.

I started to find the source of my work, every other developer’s work, it comes from the designer. Designers are very close to the business because they can quickly prototype what’s in their mind, where as developers are usually stuck in setting up the development environment. Why not enhance the designer’s tool so that me as a developer, keep adding features to it, hence the concept Design to code. Where Design stands for the team who is responsible for creating the designs, basically rectangles stacked on rectangles, and code shall be consumed by developer or directly embed in the web application.

Parts of a web interface

Like pythogorean stuck in seeing the triangles everywhere, sitting in front of the screen made me realise with my real eyes that its all real lies of the community. It could have been better, rather than complaining on how the setup is, I started taking steps to connect the dots and build a tool.

So starting from finding out what’s common between the design and development, I tried to build other concepts around it.

Designers usually use rectangles to design components, where as developers call them as components. A rectangle can have a child rectangle, or in developer’s terms, a component can have a child component.

For the rectangle there is an inner space which defines the padding for its content or the child component, and there is a n outer space, which defines the margin of the component with its sibling. This is the same box model.

Box to code

Setting the stage that we will be working with the rectangles or a component, in the developer’s eyes, its a code, usually a Div element. While there are other html elements that define the visual aspect or the code of the component, lets not distract ourselves with mililon other features of web and just stick to Div.

In the below example, the first is a rectangle and as you can see on the right side, its the equivalent web browser code to create that rectangle.

The second example is a rectangle with a text as hello. in order to create that, the equivalent code for creating it is written on the right side, using a “div” and a “p” tag.

The third example shows an interaction that happens when a click is performed on the created component. the intended behaviour of the click is to change the text “hello” from the component into “Hi World”. Here is where the role of a developer is played to make an interactive components from a design.

To make the component interactive, what a developer typically does is to mark the content with a tag literal, “marked in curly brace”. In the first example, it is a rendered code that has Hello, if you trace the solid arrow, you can see the value hello is actually from a variable called “message” and in the actual code, before it gets rendered on the browser is the picture number 2.

The technique is that, any dynamic or changing value will usually be moved as part of a variable.

Idea — Even a component or the rectangle is a changing value isn’t it, why don’t we move it to a variable? Exactly, that’s the concept that helped to bridge the gap between the design and development.

Code to change the value of the dynamic texts

Lets say, in the initial render of the component it has the value such as message, then as per point#1 in the below picture, the state should have a property called message to which we will provide it a value as “hello” if the message to be rendered is “hello”. What happens when user clicks on the div and we need the text to be changed into a different text such as “hi”? Depending on the framework or underlying layer, it can easily be done by creating a new callback that modifies the state of the component. You can refer to #2 in the below picture and point number# is a sample for binding an event to div element. It uses minimal syntax.

Here is another description on how it can be done. Below function is the full syntax which we saw above. What it does is to modify the property of state.message into “hi world” These functions are called callback and they run when click is triggered on an element.

Using callback, we can create dynamic content, visuals, animation etc.

Since a callback changes the visual format of a component, a component in different state can be considered to be a variant of the same component. Any visually distinct component is called a variant.

Variants are a technique used by designers to organise the components in their design tools. In the below image you can see when a new variant gets created, it is after an user interaction. In this case, a click event.

How this system of variants, components, rectangles scale to a larger application that has pages, templates etc? The concept of page and template are created for ease of understanding during the era of CMS, however with intricate designs and components are created in the modern era, we need a better naming convention. A page is giant component that nests smaller component with in, so does a template.

Problems in scaling UX design, UI components and component architecture for large scale applications

Though the web interfaces may seem simple, there are unknown tech debts that may arise in the future if not designed right.

Some of the problems as listed above.

1. Many components?— For designers, it may be a hell to maintain too many components. Ideally a neater approach will be to maintain unique set of elements, then components, reusable components that are brand agnostic, then business components that are brand specific.
2. Callbacks or interactions or variants— Designers will have to maintain separate set of design style guide so that developers will know when to apply style changes depending on the event. This was the standard approach, but it doesn’t scale that much. Instead of maintaining separate styles for events, its best to call the visually distict component as a variant. This will allow both the designers and developers to maintain their sources accordingly.
3. Data Store, Framework syntax, Javascript Opinions —?With the opinated community preference, there are lot of choices for web developers to pick from when it comes to frameworks. With regards to the react, there are further options to choose a data store and a state management library, which is unnecessary. Concept of variant will help component composability and extendability without the need of app state. If it has to deal with the backend data, it needs to be kept and loosely coupled with the frontend code.
4. Tooling configurations?— Webpack and the rest of the brotherhoods joins the hood.
5. Engineering team setup —?With an architecture of components in place, usual development leaders will organise the teams so that there is a pipeline of workflow from one team to another or in other terms there will be a core horizontal team who supports the vertical product team. Apart from the team organisation, there is a quite an amount of effort spent to make sure there is build, rollback setup as well. These are unnecessary effort and the crowd usualy picks from bigger organisation technique and apply on their projects. Bigger organsiation would have choosen a technique to solve a problem for some other reasons, mimicking their technique will moslty a bloatware in the system.

Solution?: Design and build from scratch — Tooling, UX design architecture, UI design architecture, UI development — All in one tool

We have seen the problems with respect to modern web development workflow. Instead of spending too much time in learning someone else’s technique, lets see the facts. An UI that builds UI? could it be possible? An UI that helps to design UI? could it be possible? What if we design a browser solution that builds UI on the fly, also helps the designers also design!

Foundational concept for that is called component composition rules. We have seen how component architecture is flexible and over throws the concept of pages and templates because they are not recursive. In the below content, lets set rules for component composability.

A component composition rules should be defined so that designers and developers can shake hands and agree upon. For example, in developer’s terms, a state is similar to a variant. Variants are caused by interactions, which in developers term is an event. Variants have different properties between them, while a designer will hardcode it, a developer usually write code that modifies the visual properties.

Visually every component is a rectangle. A component can have text, image, video or another component as children. Here is the catch, how come this design scales till the page or app level ? if you see in the picture above, a parent component can have a child component and this rule is repetitive and scales across the app.

With such a scalable composition of component, how can it extended or adopted so that I can have variants or different app state as part of the composition rules? Show or hide.

Finding a common language or technique between designer and developer has been a real challenge, visually looking at when several permutation or combination of states that can happen, it all boils down to show or hide. In the example above, what happens is when an user clicks on a component that has text as “Hi” and it stars displaying “Hello”. In other words it can be written as in the first state or the default variant, the state is “Show — Hi” which also complements another term called “Hide — Hello”. This state switches to “Show- Hello” or its complementary version of “Hide-Hi”.

Parent component and child component communication.

Breaking down the entire app into parent and a child scales evenly, with designers architecture as well as developer’s architecture. In such a design, lets tackle few challenges that needs to be addressed so that developer also has a technique for composability. Because for a designer, variant just says that it is visually distinct, and occurs when an interaction happens. What if a parent component renders a visually distinct child component during or after an event?

In the above picture, what do you see is a parent component that renders a child component that contains a “ok” button.

When the user clicks on the “ok” button, a click event is triggered, that propagates to its parent and its parent. Using this technique, a parent can be let known by a child component that an event can carry information. Using this communication channel, state of child component, variant information of child component can be passed to a parent that can conditionally render the child component or a different variant. This communication helps for a parent to choose a child’s variant. In our initial design, we saw that a component can switch from on variant to another, in this design, a parent component can choose to switch its child from one variant to another.

Parent child communication — Data

The design of letting the parent control the child’s state helps to scale the concept till the page or app level. In such design, a parent can supply data to its children, maintains list of show/hide configuration of the children, hence the behaviour of children can be controlled by a parent.

Here is an example, where a parent component has a child component. — Outermost rectangle and inner rectangle are the two different components. By making the parent setting the app state, it initially has button text as “ok” when the user clicks on the button, it becomes “Hello” We saw this design earlier restricted to a component, the same design, we have pushed it upwards to the parent.

Advanced communication — Parent to child and child to parent.

A parent child communication is necessary to control the state of the app and switch from one state to another. When this happens there are two possibilities. A parent initially has a state, some interaction happens at some child component of the app, it has a source even that can change the state of the app, this event gets propagated from child to parent on event. The parent will have a state modifier for the event, once the state is modified, the parent pushes down the state to the child.

Here the Parent is marked as 1 and child as 2. At step 3, the parent passes data to the child. At step 4, an user interacts with the element. At step 5, the event is propagated to the parent.

As you can see, for the developers, this is a circular message passing system that starts with an event source, propagates to the parent most component, and the parent chooses to pre-render the component with a different state.

As you can see, this architecture is similar to a DOM’s event bubbling or capturing technique applied on a bigger scale such as a component. Having it foundational corrected, frameworks, tools, libraries can be built around this architecture for a low code to no code to design the code systems.

This may seem very simple, instead of complicating the frontend with several semantic elements, just like how we found a common term for components as rectangle, lets call all the elements of the frontend HTML pieces as a Div! and Div is a rectangle. In other words, for modern web application, all the DOM elements are a rectangle with adjustable size.

1. A visually distinct rectangle are variants
2. An user interaction switches a rectangle from one variant to another
3. Visual styles are called design tokens

Why this philosophy is necessary? because having a common language will help to translate the concepts. These rules are the common facts or terms used by developers and designers. With the help of their architecture facts,, we will build concepts upwards. In a way, we get the agreement of both, the designer and the developer.

This also helps us conceptualise in form of a practical solution by building a tool that does most of these work, leaving the designers to design. As a developer, we will be building a designer’s tool that will help you to reduce amount of work you do as part of your daily job.

Requirements for a designer tool

1. As a web interface designer, I need to be able to create rectangles.
2. As I create rectangle, I need tools to adjust its size.
3. As I create rectangle, I need tools to add content in it.
4. As I compose more rectangles and variants, I need tools to mark the type of interaction the user will perform that will switch it to the next variant.

Seeing from the eyes of a designer, he/she/it needs to use the mouse more and keyboard less. The designer will look at the design tokens that are readily available, connect the design tokens with tokens we created such as component, content, visual, interaction to create a tree of components and variants.

The designer need not maintain a single tree of components, instead a disconnected trees.

Mechanical technology to design a designer’s tool

We saw a scalable architecture to build components for designer as well as the developer, next we define a scalable concept for designing and building a designers tool.

The tool will be made of nodes, a node carries an information. The nodes will be connected with the help of arrows. Nodes will pass message to its next connected node.

Node also stores visual style information that are adjustable and editable.

Node also stores information about the content. This content will flow into the target node.

A node can also be used to create design tokens.

Nodes are of type content, visual, parent / child, events or interaction.

Here is an example of a node containing content “hi” that switches to a node with content “Hello” after an event called “onClick”

Requirement of a developer

As a developer, the requirement that was put is to make the design made by the designer to be available as a real application running on a server, used by the customers.

Introducing Design to code

We have established rules, philosophy, communication pattern, variants for the designs, lets see how to automatically convert these into code.

On the left in the above picture, you see a box with border style as 1px solid. the right side, in the broken lines, the first picture has the code of just a rectangular box.

Lets say we need the box to have a border style of 1px solid, visually CSS can help to get there. In more scalable and as a best practice, lets create a class called “border” that is defined with visual properties.

Dynamic content

A component’s content can change depending on user interaction. In below example, we see a component’s content getting changed and equivalent code is written on the right side.

Dynamic Visuals

What about visual styles that get modified when a component is interacted by an user?

Here is an example code that modifies class of a component when user clicks. As you can see, the component takes a className as a variable called “StyleName” whose values are modified when the user interaction occur.

Parent component — Dynamic child component

Here is a sample component that has child as a “MESSAGE” component. What is happening here is, when user clicks on “MESSAGE” it gets hidden from the user.

Here is the code that lets the parent component to hide / show a child component conditionally. This technique also adheres to our concept of an app state based on?“Show/Hide”

Render list of Child

One more case to cover is rendering list of elements. Web applications do not have complex layouts and the source of layouts are a list of items.

A list needs a parent, it scales good when a parent renders list of items, and let it control it.

In the above example, “this.state.items” keeps track of items in form of an array. A “div” element contains the code to render a list of items, in form of a “Span” tag.

Here, div is equivalent to a parent component and span is equavalent to a child component.

As you can see, as a best technique, if you have a list of items to be rendered, strip out its content into a state. This allows parent component to modify the list values.

System Design — Philosophy

1. A component has content or another component
2. Content can be text, image, video
3. A parent component may pass data for child.
4. A child may pass event to the parent.

Prototype build plan — try your own

Using all the rules, concepts, techniques, philosophy defined in the previous parts, lets try putting it together. Here are the list of ingredients we need.

What we will use is react framework to build our concept, and a node based library called react-flow. This will allow us to build our concept quick without building everything from scratch. That will be covered in a different topic.

User steps

1. User clicks on the screen, it creates a node
2. The node should be resizable
3. The node receives content, visuals from another node

Exercise #1

1. Create a node with editable text
2. Call this a content node
3. Connect this node to a component node to see the content. Content can also be a list.

Exercise #2

1. Create a visual node with visual property
2. Connect this node to a component nod, notice the visual changes

Climax — Thank you.

Thank you for reading this far, for further questions, open ui-editor in github, open your questions in the issue tab.