February 8, 2018 at 14:09Html-sketchapp - the key to the unity of programmers and designers
- Transfer
Mark Dalgleisch, head of design systems at SEEK, says that if you look at any team that uses a design system, you will find that this approach has obvious advantages. They consist in the fact that designers and programmers work more productively than without such a system, the results of their work become more uniform, the interaction between different groups of employees is more clear and coherent.
SEEK Interactive Style Guide Home Page
However, most design systems have a fundamental flaw. Designers and developers, even with the introduction of something pretty modern, continue to work in completely different environments. As a result, in order to maintain the code and design materials in a consistent state, you have to make a lot of effort, otherwise the materials that designers and programmers work with over time go farther apart.
It is not surprising that companies using design systems have the feeling that stagnation is observed in the development of tools in our industry. These tools are not adapted to the environment in which we work, they are not particularly useful in the crucial business of transferring what is done by developers to the environment in which designers work.
Is it really that bad? Mark believes that in the near future we are waiting for a change for the better. In this article, he talks about how at SEEK they were able to bring systems closer, where designers and developers work as much as modern technologies allow.
We at SEEK have been working on an interactive style guide for more than a year , with interface elements represented by React components , the number of which is constantly growing. As you might expect, this fundamentally changed our vision of visual design.
As a result, we had at our disposal a design system based on program code that determines not only how specific projects created by the company will look like, but also the content of the style guide that designers work with.
Today, this guide is presented as an interactive, regularly updated website. But at the very beginning of work on the design system, we tried to formalize the rules in the form of a PDF document. Then came a set of source materials for Sketch , standardized characters, colors and styles of texts, which were included in it, could easily be used as a starting point for new projects.
The initial set of materials for Sketch by SEEK
A little later we experimented with Craft , with a set of plugins for Sketch from InVision , of which I would especially like to mention the Library plugin .
This allowed us to create a common library of company symbols, use them in all teams and in all documents.
Library plugin from the Craft suite
At the very beginning of the preparation of the library, the enormous amount of work necessary to keep this library up to date, in particular, in a situation of constant development of existing and the emergence of new templates in our projects, became apparent.
Developers, often together with designers, made changes to the code, which had a serious impact on visual design, but our static design library remained the same as it was before these changes. In order to bring it up to date, someone had to remember that it needs to be updated, which usually did not happen.
So, here we were talking about the spread of changes in the direction from developers to designers. The same problems were characteristic of the reverse process. Developers lacked a reliable source of reliable and relevant design information, information from which they could use in their code.
Around this time, we started work on our first React project. Rendering was carried out on the server, here we used webpack and CSS modules (we, along the way, participated in their development). All of this ultimately led to the creation of our interactive style guide.
The fact that React is component oriented has made the transition to interactive leadership almost inevitable. At the same time, we saw that similar processes are occurring in other companies around the world.
As soon as we created a sufficiently large collection of components, other teams working on new projects quickly took advantage of our best practices. However, since the style guide now consisted of React components and LESS stylesIt turned out to be not particularly useful for designers. We were not particularly surprised, we did not seek to fix this as soon as possible. The fact is that the technology gap between designers and developers is an old problem that has been present in our industry for so long that we are used to not noticing it.
Everything remained in the same state until we found out about the react-sketchapp project created by Airbnb.
React-sketchapp
Here is what Airbnb employee John Gold says about react-sketchapp: “In Sketch we use characters and overrides, in React we use components and properties. These concepts are so similar that it seemed foolish not to combine them. ”
We did not believe our eyes. Here it is - real React code that goes straight to Sketch. It seemed that we would finally be able to create a design system from which both developers and designers would be able to draw the latest and most current data.
With this approach, the basis for design rules is code that is not only used in production, but also falls into the environment in which designers work. As the code, and therefore the design rules, evolves, these rules could automatically be kept up to date, accessible to designers, without the need to manually transfer anything to Sketch.
Of course, when we went a little deeper into this topic, we found that to work with react-sketchapp you need to fulfill some requirements:
So, although react-sketchapp is just a terrific project that we can recommend from the bottom of our hearts to others, its technical requirements, unfortunately, meant that we would not be able to use it in the short or medium term.
Even if we decided to migrate our component library, we would need to find the answer to another question. This question was about version control.
As you may already know, there are tools that allow you to use version control within design tools. However, we needed to ensure that the materials that designers work with could be processed using an external version control system. We would like to perceive these materials as, say, a regular code, so that they are located in the same place as this regular code, and not in some allocated space that has nothing to do with everything else. Therefore, we decided to experiment.
Using Kactus and some proprietary scripts for Node , we tried committing Sketch files to the style guide repository.
Kactus showing git diff for the Sketch file.
Technically, we could achieve what we wanted, but, unfortunately, we were unable to get the workflow we needed. Perhaps someone else will succeed, but it did not suit us. The point here is that even with this approach, supporting synchronization of code and design materials turned out to be an extremely tedious task, this process was error prone, and its results were difficult to verify.
However, the fact that code files and Sketch files could be contained in the same version control system led to a clearer understanding of the problem we were facing, although it did not help us solve the problem itself. Moreover, when using the approach with the version control system, those who agreed on the style guide with the code had to perform many auxiliary actions. The costs of time and effort were not comparable with the possible benefits, the value of which was still in question. As a result, work on Sketch files was soon abandoned. We recognized the experiment as unsuccessful.
We have almost lost hope of success, we were ready to admit that we can’t bring developers and designers together in one workspace, as the html-sketchapp project appearedwho changed absolutely everything.
As it turned out, not only were we bothered by the problems regarding the integration of react-sketchapp into the existing technology stack. Here is what Conrad Jvinel from Brainly writes about it : “We were not able to quickly overcome these limitations, which is why we created the html-sketchapp.”
The html-sketchapp taken a completely different approach.
Html-sketchapp results
As you can see from the name of this project, html-sketchapp allows you to generate sketch files from regular HTML content, but, unlike react-sketchapp, there are no restrictions on the choice of technologies with which this content is prepared.
Web projects that html-sketchapp can work with can be created using Preact , or Vue , or Angular , or Backbone , or jQuery , or even using Ruby or PHP .
No one forbids using React, but now the application can be styled as the developer wants, using any suitable primitives.
The requirements for a project that could be processed using html-sketchapp were incredibly simple: if you have an HTML page, you can import it into Sketch.
At first glance, what the html-sketchapp was doing seemed unbelievable, but when we looked at its internal mechanisms, we quickly found that all this, in fact, is not so complicated.
In order to understand how html-sketchapp works, you first need to understand the format of the Sketch file. Perhaps for some people it may come as a surprise that Sketch files are, in fact, regular Zip files.
Sketch file opened as an archive file
After unpacking the Sketch files as regular archives, you can find out that they mainly consist of JSON files, which, of course, can be opened in any completely ordinary text editor.
A JSON file from a Sketch file opened in a text editor
If you look at the contents of these files, you can see that their format is relatively simple, basically they consist of small blocks of nested classes.
At the lowest level, html-sketchapp allows you to programmatically generate instances of these classes and convert them to JSON. But he goes much further, not limited to these actions.
Perhaps the most powerful html-sketchapp feature is nodeToSketchLayers . It makes it possible to convert browser elements into arrays of Sketch layers. It is here that the lion's share of the sacrament takes place, since it contains all the logic for extracting browser styles and converting them to their Sketch equivalents.
After preparing the source materials , the SymbolMaster class comes into play , which collects everything together and dynamically generates Sketch symbols. Symbols are the basis of any Sketch library, which means that having found the path between HTML and Sketch, we can, while processing the React components displayed in the browser, form what designers need.
Unfortunately, due to some restrictions in the current Sketch format regarding how text styles are encoded, the generated document is not a valid Sketch file - in html-sketchapp such files are called Almost Sketch (almost Sketch files), or, for brevity - asketch. Such files must be manually imported using the appropriate plugin . But, fortunately, this process is not too complicated.
At first, the task of linking all this together seemed overwhelming, but it so happened that there was already a demo project on GitHub showing the process of converting an existing style guide to a Sketch document.
As soon as we found it, we almost immediately began to experiment. As a result, the results that shocked us were surprisingly fast.
First, we decided to find out the html-sketchapp capabilities ourselves and “fed” him the home page of our style guide website.
Here is a tweet that demonstrates.
Results of processing a page using html-sketchapp
Next, we began to generate our first characters from the Button component, rendering several different variants of this component.
Here's what the HTML page with the component looked like.
HTML page with the component displayed on it
And here is what we got.
Page processing results with html-sketchapp.
In order to achieve this, we came up with a special JavaScript-file that is added to the folder of each component (for example -
Each file would export an object specifying the name of the symbol and its corresponding React elements.
Then we created a special hidden route on the style guide website that imported any file ending in
An instance of each symbol was wrapped in an element
This template proved to be extremely effective, and soon we expanded it to include text styles and document colors .
Description of text styles
Text styles
Description of colors
Sample colors on a web page
Imported colors
Our style guide was responsive, so we automated the process of resizing the browser window and taking pictures of characters at different screen sizes.
Browser window settings
Text Styles in Sketch
Design Elements in Sketch
This gave us a convenient opportunity to add, remove and rename window sizes while working with a single file. Symbols were generated for each required window size.
After we were able to achieve everything that we just talked about, we got the feeling that we had solved a seemingly unsolvable problem that concerned the support of responsive design in Sketch.
All this worked surprisingly well, although we still needed to finalize something , in particular, with regard to Sketch support. It reminded me of how they usually organize browser support, in which there are errors.
What started as a not-so-large-scale experiment quickly turned into something like a mini-framework.
It did not take us too much time to integrate html-sketchapp and all the developments related to this project into our style guide. The preparation of a fresh version of the style guide was now performed as part of the standard build process.
However, if you look at the corresponding pull request , you will find that this integration required us to include a lot of auxiliary code and dependencies in the project, despite the fact that at a high level we tried to achieve a single, conceptually simple task.
In order to generate a library for Sketch, you had to follow these steps:
We also wanted to automate this process. It seemed completely natural for us to be able to do all of this with one team, which would be enough just to pass the desired URL. That’s what we got as a result.
Less than a month after we integrated the html-sketchapp into the system for creating our style guide, we transferred html-sketchapp-cli , a small command-line utility that allowed us to automate auxiliary operations , into the category of open source projects .
Now all we needed to form a guide was one dependency and a simple configuration file.
In addition, the use of html-sketchapp-cli allowed to remove a lot of code.
Html-sketchapp-cli implementation results
All of these tools are now part of our usual work. Changes made to styles by developers quickly reach designers.
After each successful build of the style guide, we not only automatically deploy our site to GitHub pages (using gh-pages ) and publish the component library in npm (using semantic-release ) - now we, all the same automatically, generate the same “almost Sketch” Files ”, ready to be imported into our official Sketch library.
This Sketch library is then distributed, via a shared disk, to members of the design team. And this means that our designers always have an up-to-date copy of the library that synchronizes with their current project in real time, even with the Sketch editor open.
Thanks to the new built-in support for Sketch libraries , designers can open the SEEK Style Guide Library menus and select the components they need, knowing that the naming conventions and visual styles meet the expectations of the developers.
Designer’s workplace
Since we implemented this mechanism, we see how changes made to the code continuously flow into Sketch, and sometimes those who make these changes do not even have Sketch installed. Since the style guide is connected to running applications, styles are constantly being improved by people from the whole organization, and now we can be sure that all these changes get into the Sketch library, constantly keeping it up to date.
Technically, developers and designers still work in different environments, but we are working hard to bring them closer even more.
No matter how significant all that was discussed, for us this is only an interim solution. Transferring data from web pages to Sketch is a very powerful feature. This is a big step forward towards a unified development environment, but we, and the entire web development industry, need to move on.
The border between developers and designers may become increasingly blurred, but the design tools of the future should completely erase this border. In order to take advantage of this potential, we need such design tools that do not imitate, albeit quite accurately, the target environment. We need tools that are themselves created on the basis of this environment.
Fortunately, there is no shortage of people in the world right now working on the problem of universal development and design environments. Tools likeCompositor , Interplay , Alva , Haiku , Webflow and UXPin aim to break the walls between design tools and the underlying web project code. We believe that the appearance of even more such tools will not take long.
Who knows, maybe we will even see how more traditional design tools introduce a similar approach in order not to lose relevance, especially considering that design systems are increasingly becoming an ordinary part of a set of tools by a modern designer.
In the meantime, while we wait for new design tools to emerge, which will implement the principles that move the industry forward, projects like react-sketchapp and html-sketchapp are already preparing us for new approaches in design and development, and are developing new ways of thinking in us.
Honestly, now is an amazingly good time to start perceiving web design in a new way.
Dear readers! Do you use react-sketchapp or html-sketchapp in your projects?
SEEK Interactive Style Guide Home Page
However, most design systems have a fundamental flaw. Designers and developers, even with the introduction of something pretty modern, continue to work in completely different environments. As a result, in order to maintain the code and design materials in a consistent state, you have to make a lot of effort, otherwise the materials that designers and programmers work with over time go farther apart.
It is not surprising that companies using design systems have the feeling that stagnation is observed in the development of tools in our industry. These tools are not adapted to the environment in which we work, they are not particularly useful in the crucial business of transferring what is done by developers to the environment in which designers work.
Is it really that bad? Mark believes that in the near future we are waiting for a change for the better. In this article, he talks about how at SEEK they were able to bring systems closer, where designers and developers work as much as modern technologies allow.
Our journey in the world of design systems
We at SEEK have been working on an interactive style guide for more than a year , with interface elements represented by React components , the number of which is constantly growing. As you might expect, this fundamentally changed our vision of visual design.
As a result, we had at our disposal a design system based on program code that determines not only how specific projects created by the company will look like, but also the content of the style guide that designers work with.
Today, this guide is presented as an interactive, regularly updated website. But at the very beginning of work on the design system, we tried to formalize the rules in the form of a PDF document. Then came a set of source materials for Sketch , standardized characters, colors and styles of texts, which were included in it, could easily be used as a starting point for new projects.
The initial set of materials for Sketch by SEEK
A little later we experimented with Craft , with a set of plugins for Sketch from InVision , of which I would especially like to mention the Library plugin .
This allowed us to create a common library of company symbols, use them in all teams and in all documents.
Library plugin from the Craft suite
At the very beginning of the preparation of the library, the enormous amount of work necessary to keep this library up to date, in particular, in a situation of constant development of existing and the emergence of new templates in our projects, became apparent.
Developers, often together with designers, made changes to the code, which had a serious impact on visual design, but our static design library remained the same as it was before these changes. In order to bring it up to date, someone had to remember that it needs to be updated, which usually did not happen.
So, here we were talking about the spread of changes in the direction from developers to designers. The same problems were characteristic of the reverse process. Developers lacked a reliable source of reliable and relevant design information, information from which they could use in their code.
The path from React to react-sketchapp
Around this time, we started work on our first React project. Rendering was carried out on the server, here we used webpack and CSS modules (we, along the way, participated in their development). All of this ultimately led to the creation of our interactive style guide.
The fact that React is component oriented has made the transition to interactive leadership almost inevitable. At the same time, we saw that similar processes are occurring in other companies around the world.
As soon as we created a sufficiently large collection of components, other teams working on new projects quickly took advantage of our best practices. However, since the style guide now consisted of React components and LESS stylesIt turned out to be not particularly useful for designers. We were not particularly surprised, we did not seek to fix this as soon as possible. The fact is that the technology gap between designers and developers is an old problem that has been present in our industry for so long that we are used to not noticing it.
Everything remained in the same state until we found out about the react-sketchapp project created by Airbnb.
React-sketchapp
Here is what Airbnb employee John Gold says about react-sketchapp: “In Sketch we use characters and overrides, in React we use components and properties. These concepts are so similar that it seemed foolish not to combine them. ”
We did not believe our eyes. Here it is - real React code that goes straight to Sketch. It seemed that we would finally be able to create a design system from which both developers and designers would be able to draw the latest and most current data.
With this approach, the basis for design rules is code that is not only used in production, but also falls into the environment in which designers work. As the code, and therefore the design rules, evolves, these rules could automatically be kept up to date, accessible to designers, without the need to manually transfer anything to Sketch.
Of course, when we went a little deeper into this topic, we found that to work with react-sketchapp you need to fulfill some requirements:
- Components need to be built using React (this is pretty obvious). Fortunately, we have already used React, so this did not seem to be a problem.
- Styles must be defined in JavaScript. In our case, since our design system was built using CSS modules, we have already made some progress in the right direction. We are big fans of CSS-in-JS , but we were not prepared to scatter styles throughout our ecosystem, at least we were not going to do it in a hurry.
- Components should use universal primitives (View, Text, StyleSheet) and not browser primitives, using something like react-primitives . In general, react-sketchapp was closer to React Native than to regular React. Again, this was something that we could very well move on to, but such a transition would require a lot of work, and perhaps in the course of its implementation we would have to make some compromises.
So, although react-sketchapp is just a terrific project that we can recommend from the bottom of our hearts to others, its technical requirements, unfortunately, meant that we would not be able to use it in the short or medium term.
Even if we decided to migrate our component library, we would need to find the answer to another question. This question was about version control.
Design materials and universal version control system
As you may already know, there are tools that allow you to use version control within design tools. However, we needed to ensure that the materials that designers work with could be processed using an external version control system. We would like to perceive these materials as, say, a regular code, so that they are located in the same place as this regular code, and not in some allocated space that has nothing to do with everything else. Therefore, we decided to experiment.
Using Kactus and some proprietary scripts for Node , we tried committing Sketch files to the style guide repository.
Kactus showing git diff for the Sketch file.
Technically, we could achieve what we wanted, but, unfortunately, we were unable to get the workflow we needed. Perhaps someone else will succeed, but it did not suit us. The point here is that even with this approach, supporting synchronization of code and design materials turned out to be an extremely tedious task, this process was error prone, and its results were difficult to verify.
However, the fact that code files and Sketch files could be contained in the same version control system led to a clearer understanding of the problem we were facing, although it did not help us solve the problem itself. Moreover, when using the approach with the version control system, those who agreed on the style guide with the code had to perform many auxiliary actions. The costs of time and effort were not comparable with the possible benefits, the value of which was still in question. As a result, work on Sketch files was soon abandoned. We recognized the experiment as unsuccessful.
We have almost lost hope of success, we were ready to admit that we can’t bring developers and designers together in one workspace, as the html-sketchapp project appearedwho changed absolutely everything.
Html-sketchapp
As it turned out, not only were we bothered by the problems regarding the integration of react-sketchapp into the existing technology stack. Here is what Conrad Jvinel from Brainly writes about it : “We were not able to quickly overcome these limitations, which is why we created the html-sketchapp.”
The html-sketchapp taken a completely different approach.
Html-sketchapp results
As you can see from the name of this project, html-sketchapp allows you to generate sketch files from regular HTML content, but, unlike react-sketchapp, there are no restrictions on the choice of technologies with which this content is prepared.
Web projects that html-sketchapp can work with can be created using Preact , or Vue , or Angular , or Backbone , or jQuery , or even using Ruby or PHP .
No one forbids using React, but now the application can be styled as the developer wants, using any suitable primitives.
The requirements for a project that could be processed using html-sketchapp were incredibly simple: if you have an HTML page, you can import it into Sketch.
Sketch File Generation
At first glance, what the html-sketchapp was doing seemed unbelievable, but when we looked at its internal mechanisms, we quickly found that all this, in fact, is not so complicated.
In order to understand how html-sketchapp works, you first need to understand the format of the Sketch file. Perhaps for some people it may come as a surprise that Sketch files are, in fact, regular Zip files.
Sketch file opened as an archive file
After unpacking the Sketch files as regular archives, you can find out that they mainly consist of JSON files, which, of course, can be opened in any completely ordinary text editor.
A JSON file from a Sketch file opened in a text editor
If you look at the contents of these files, you can see that their format is relatively simple, basically they consist of small blocks of nested classes.
At the lowest level, html-sketchapp allows you to programmatically generate instances of these classes and convert them to JSON. But he goes much further, not limited to these actions.
Perhaps the most powerful html-sketchapp feature is nodeToSketchLayers . It makes it possible to convert browser elements into arrays of Sketch layers. It is here that the lion's share of the sacrament takes place, since it contains all the logic for extracting browser styles and converting them to their Sketch equivalents.
After preparing the source materials , the SymbolMaster class comes into play , which collects everything together and dynamically generates Sketch symbols. Symbols are the basis of any Sketch library, which means that having found the path between HTML and Sketch, we can, while processing the React components displayed in the browser, form what designers need.
Unfortunately, due to some restrictions in the current Sketch format regarding how text styles are encoded, the generated document is not a valid Sketch file - in html-sketchapp such files are called Almost Sketch (almost Sketch files), or, for brevity - asketch. Such files must be manually imported using the appropriate plugin . But, fortunately, this process is not too complicated.
At first, the task of linking all this together seemed overwhelming, but it so happened that there was already a demo project on GitHub showing the process of converting an existing style guide to a Sketch document.
As soon as we found it, we almost immediately began to experiment. As a result, the results that shocked us were surprisingly fast.
Html-sketchapp experiments
First, we decided to find out the html-sketchapp capabilities ourselves and “fed” him the home page of our style guide website.
Here is a tweet that demonstrates.
Results of processing a page using html-sketchapp
Next, we began to generate our first characters from the Button component, rendering several different variants of this component.
Here's what the HTML page with the component looked like.
HTML page with the component displayed on it
And here is what we got.
Page processing results with html-sketchapp.
In order to achieve this, we came up with a special JavaScript-file that is added to the folder of each component (for example -
Button.sketch.js). Such files define the characters that we would like to export. Each file would export an object specifying the name of the symbol and its corresponding React elements.
import React from 'react';
import Button from './Button';
export const symbols = {
'Button/Pink': ,
'Button/Blue': ,
'Button/Transparent': ,
};Then we created a special hidden route on the style guide website that imported any file ending in
.sketch.jsand rendered the corresponding React elements on the screen. By doing so, we got the opportunity to greatly simplify the conversion process by displaying everything you need for Sketch on one page. An instance of each symbol was wrapped in an element
div, in the data attribute of which the name of this symbol was specified, which allowed us to simplify the selection and naming of symbols on the page.
...
This template proved to be extremely effective, and soon we expanded it to include text styles and document colors .
Description of text styles
Text styles
Description of colors
Sample colors on a web page
Imported colors
Our style guide was responsive, so we automated the process of resizing the browser window and taking pictures of characters at different screen sizes.
Browser window settings
Text Styles in Sketch
Design Elements in Sketch
This gave us a convenient opportunity to add, remove and rename window sizes while working with a single file. Symbols were generated for each required window size.
After we were able to achieve everything that we just talked about, we got the feeling that we had solved a seemingly unsolvable problem that concerned the support of responsive design in Sketch.
All this worked surprisingly well, although we still needed to finalize something , in particular, with regard to Sketch support. It reminded me of how they usually organize browser support, in which there are errors.
From experimentation to production
What started as a not-so-large-scale experiment quickly turned into something like a mini-framework.
It did not take us too much time to integrate html-sketchapp and all the developments related to this project into our style guide. The preparation of a fresh version of the style guide was now performed as part of the standard build process.
However, if you look at the corresponding pull request , you will find that this integration required us to include a lot of auxiliary code and dependencies in the project, despite the fact that at a high level we tried to achieve a single, conceptually simple task.
In order to generate a library for Sketch, you had to follow these steps:
- Compiling a browser script using webpack. It should have included html-sketchapp and code for selecting and converting elements.
- Running a static web server on any available port.
- Launch Puppeteer (this is a Chromium browser without a user interface ).
- Go to the given URL.
- Embed the compiled script into a running instance of Puppeteer.
- Creating, using functions from a compiled script, snapshots of elements using each of the specified screen sizes.
- Writing received JSON files to disk.
- Stop the static web server.
- Stop the browser.
We also wanted to automate this process. It seemed completely natural for us to be able to do all of this with one team, which would be enough just to pass the desired URL. That’s what we got as a result.
Html-sketchapp-cli
Less than a month after we integrated the html-sketchapp into the system for creating our style guide, we transferred html-sketchapp-cli , a small command-line utility that allowed us to automate auxiliary operations , into the category of open source projects .
Now all we needed to form a guide was one dependency and a simple configuration file.
module.exports = {
serve: 'docs/dist',
url: '/sketch-exports',
outDir: 'dist/asketch',
viewports: {
'Desktop': '1024x768',
'Mobile Plus': '414x736',
'Mobile': '320x568'
}
};In addition, the use of html-sketchapp-cli allowed to remove a lot of code.
Html-sketchapp-cli implementation results
Design as a continuous process
All of these tools are now part of our usual work. Changes made to styles by developers quickly reach designers.
After each successful build of the style guide, we not only automatically deploy our site to GitHub pages (using gh-pages ) and publish the component library in npm (using semantic-release ) - now we, all the same automatically, generate the same “almost Sketch” Files ”, ready to be imported into our official Sketch library.
This Sketch library is then distributed, via a shared disk, to members of the design team. And this means that our designers always have an up-to-date copy of the library that synchronizes with their current project in real time, even with the Sketch editor open.
Thanks to the new built-in support for Sketch libraries , designers can open the SEEK Style Guide Library menus and select the components they need, knowing that the naming conventions and visual styles meet the expectations of the developers.
Designer’s workplace
Since we implemented this mechanism, we see how changes made to the code continuously flow into Sketch, and sometimes those who make these changes do not even have Sketch installed. Since the style guide is connected to running applications, styles are constantly being improved by people from the whole organization, and now we can be sure that all these changes get into the Sketch library, constantly keeping it up to date.
Technically, developers and designers still work in different environments, but we are working hard to bring them closer even more.
Summary
No matter how significant all that was discussed, for us this is only an interim solution. Transferring data from web pages to Sketch is a very powerful feature. This is a big step forward towards a unified development environment, but we, and the entire web development industry, need to move on.
The border between developers and designers may become increasingly blurred, but the design tools of the future should completely erase this border. In order to take advantage of this potential, we need such design tools that do not imitate, albeit quite accurately, the target environment. We need tools that are themselves created on the basis of this environment.
Fortunately, there is no shortage of people in the world right now working on the problem of universal development and design environments. Tools likeCompositor , Interplay , Alva , Haiku , Webflow and UXPin aim to break the walls between design tools and the underlying web project code. We believe that the appearance of even more such tools will not take long.
Who knows, maybe we will even see how more traditional design tools introduce a similar approach in order not to lose relevance, especially considering that design systems are increasingly becoming an ordinary part of a set of tools by a modern designer.
In the meantime, while we wait for new design tools to emerge, which will implement the principles that move the industry forward, projects like react-sketchapp and html-sketchapp are already preparing us for new approaches in design and development, and are developing new ways of thinking in us.
Honestly, now is an amazingly good time to start perceiving web design in a new way.
Dear readers! Do you use react-sketchapp or html-sketchapp in your projects?