Introducing Toolabs DS-101
Component Design Studio and Relational Design System Manager
I would like to introduce to you DS-101, a new tool joining the game of interface design and development. I used the word “new” on purpose and by overcoming the hesitation for not using it because I do understand the critiques against a burst of new design tools in the last years. But it is the novelty that makes the game more exciting! So, we are as Toolabs team happy to share what DS-101 provides with its public beta and want to fill the gaps until its release together with you…
Simply, DS-101 lets us make framework agnostic UI Component Libraries which are ready to be imported and used within our application codebase written with varying frameworks such as React.js, Vue.js or Angular. It means, we do not need to handoff any style specs or code snippets to application development team, and to some extent, we also do not need any graphics design tools indeed.
What is the need for a new tool?
We all observe that tremendous amount of work is being put forward by the designers-developers community to avoid the bottlenecks and increase productivity in the design-to-development workflow. With some oversimplification, the process of application development is generally interpreted as starting from the static graphic design of interfaces, prototyping/simulating, handoffing style specifications to developers and finally developing the application. As a result, most of the solutions to speed up this workflow follow the same flow of direction and therefore provide tools to extract the running application from the visual design. It is similar to producing a real chair in 3D from its picture on two-dimensions.
Unlike the other tools, DS-101 is a developer-minded interface design tool and approaches the problem from the other way around. Its mind works like as follows:
- I know how to make this login form. I just need two text boxes, one button, some text and a container to put them all in. (Component-Based thinking)
- I already have them in my system. It is easy to make clones of each element from the system and then assemble the form. (Reusability and composition)
- I also know how to orchestrate them to talk to each other and communicate with the mouse and the keyboard. When the button is clicked or enter key is pressed I will read username and password from the inputs and pass them to the application developer. S/he can handle the rest (Interactions, Isolation)
- I can even arrange the layout of the items through rows or columns, either centered or with space between them. (Auto-layout)
- If the password is wrong, it is enough for the application developer to pass me a message and I can handle the rest by sending a message to the textbox to switch to the error state. (Stateful components)
- Hmm…Everything seems good except that all the pages and components seem almost the same, with gray colors and boring shapes. There are millions of colors and shapes in the system but I can’t decide which of them to use… I can also animate them but I don’t know how to make them dance beautifully…
The Parting of the Ways
I think that this is the breaking point in the history of software development where our famous dichotomy between designers and developers showed up! The missing visual aesthetic of user interfaces is achieved by involving graphic designers in the flow but due to the lack of a common language between development teams, the story began with a huge gap from the first day. Since then we have been inventing translators (like handoff tools ) to transfer the style data from design to development.
With the help of TARDIS, DS-101 tries to turn back the clock to that breaking point, and this time let design and development parties speak the same language by means of components. It is because if we break down UI into smaller parts, then we see that those are the components that are the intersection points between the static design and the running application.
Now let’s turn back to the mind of DS-101 and see how it thinks to solve the boring UIs problem :)
- I need to find a way of communicating with graphics designers, but with no code… I heard that Design Systems are very popular nowadays among designers. If I have an interface for them to define colors, text styles, gradients, images, icons, shadows…even sounds and transitions… calling them as tokens instead of variables, doesn’t matter in fact…Then I can reuse them as many times as I need. (Design Systems)
- And a Visual Component Designer module, where users can drag&drop elements to make components, use the tokens from the design system to style them…Define actions declaratively, and bind them to the events of elements? Then, behind the scenes I can translate those as commands and tell the components what they should do… (Visual Component Designer)
- But, what if they delete or change the tokens after I have already begun using them? Hmm.. If I keep the relations between tokens and components then when someone tries to delete a token I can warn and prevent deleting.. Those relations will also let me update all the components’ styles if a token’s value changes :) (Relational Design System)
- Yes, now I have all the data to make the components, I have to send them to the developers to code the components… But they look so busy with coding the backend of the application. I don’t need to wait for them actually, because I have render engines to run components in React.js, Vue.js or Angular, and can get a new engine for any other framework if necessary. (Framework Agnosticism)
- While waiting, let’s go to the playground and check if everything is OK. Wow, these colorful components are dancing, they are living!…Watch this video to see how it looks like :
- So, let’s make living components together :)
