Aren’t (Web / Mobile) Designers and Developers supposed to speak the same language?
Aren’t we all in pursuit of apps / sites that look pretty and work smoothly?
Can we make the whole mobile / web building process a bit more humane?
There’s clearly a gap between designers and developers. This seems all too familiar, and to my surprise it seems we’ve been mostly trying to navigate around it instead of facing it head on.
About a year back, as I was working on a mobile app, I got myself stuck in a never ending ping-pong with my designer, mainly tweaking how the app looks and behaves. Most of these changes were only about positioning, colors, spacing and so on. Instead of using my time to implement the real value bringing guts of the app, about 60% was spent doing non-business-logic relevant work aka “pixel pushing”. Essentially, all the “actions” the designer was doing in Sketch, I had to re-do in code. That, to me, looked like a completely inefficient process and the paved way to frustration. And a missed deadline. Or two :)
My first thought was “I’m probably not using the right tools… there must be a way…”
Not being a designer myself, and fairly unfamiliar with Sketch, I started to look around for some solutions that could help, but all I could find were plugins or apps that were doing part of the job. So, why bother using something that would only add more complexity to an already inefficient process
in a nutshell this is what I would like:
the designer should be able to “preview” the designs on his device / browser in realtime. But, not simulated. He should see the preview as the real deal, as if a developer would have implemented it for him.
when the designer draws a button, the developer should get a “Button” code snippet ready to be used in the app / site
The developer should chose the snippet’s language and dialect or coding style.
It looks like there are some excellent tools to cover parts of the requirements, and they fall within two categories: prototyping tools and target specific “helpers”.
While tools such as InVision and lately Sketch’s own built in prototyping system are doing a great job for prototyping, they only go as far as “prototyping”. They are mostly approximations or simulations of the end result, and they stop being useful right there.There’s not much more you can do with your prototypes once you have built them(apart from contemplate their beauty).They cannot be re - used or further expanded toward a “real”, production ready result.Hence you now need a developer to code the UI, so back to square one.
On the other hand, Target specific tools, such as Zeplin, do a great deal in helping the developer “pick” styling information, but they rarely give the full context, plus they are exactly what they are called “target specific”, with hardly any configurations possible.
Another worth mentioning approach has been proposed by the guys from Anima, through their Launchpad plugin for Sketch which exports plain HTML/CSS.
While there are plenty of tools that’ll get you a fair bit ahead towards the goal, the designer still needs a developer to be able to experience his designs in the “native world”, plus a lot of manual tweaking is needed afterwards.
Then, the thought:
What would it take to capture the designer’s “input” and translate it to code, in real-time?
And this was the seed thought that brought together a bunch of techies whom I met at the 2017 JSHeroes conference in Cluj, Romania.
The shortest way we could imagine about how to tackle this challenge was to try to define the layout representation in a code-agnostic format from which, through a parser of some sort, we would generate the code.
Given we are describing a web / mobile document’s structure, a VDOM- like model would have been the initial choice, but somehow coupled with some concepts found in AST. We finally opted for a custom stripped down structure inspired by them. The JSON representation appeared to be the format of choice for the task at that time, given that:
To make all this more visual, let’s take an example. The following image shows a basic UI made of a box, that contains a label and an image:
We’ll publish soon more information about how they work but, for now, let’s look at how a React generated code would look like for our JSON IR:
Alternatively, the React-Native code would look like this:
NOTE: in this example the positioning is deliberately set to absolute for the sake of simplicity.We’ll cover this topic in a future article given the complexity of the subject.Meanwhile, you can take a look at Karl’s article about Figma to React code generation.
Here’s a little demo of how this all works. In the video you can see our early stage Sketch plugin in action and how the design-source > intermediary representation > code generation > live preview flow feels.
The video is a simulation of a designer’s experience building JSHeroes website’s menu.
On the screen:
So far, we confirmed there’s a viable technological path for building real-time design-to-code experiences through which the design source and the target code can be completely decoupled.
So far, we’re able to generate React, React Native, Vue, HTML/CSS and AngularJS code.
Sure, the holy grail would be a bidirectional approach, where JSON IR could be generated by interpreting the source code, hence we love Jon Gold’s approach in React Sketch App.We’d highly recommend checking out the project.
We also aim to open source these tools ASAP, via Github on https://github.com/teleporthq so, stay tuned.
We’re looking forward for your thoughts and feedback, so, please get in touch with us via Twitter.