We are Avishay, Michal and Or, founders of Anima App (https://www.animaapp.com). We let designers create UIs in Sketch and then export HTML and CSS.
One the biggest pain points that we’ve experienced working in the software development industry, like so many before us, is the process of taking design to production. Designers today use tools like Sketch to design websites, web apps, or mobile apps, but these tools are limited and static. After experiencing the pain first-hand for over a decade, we resigned ourselves to try to make any kind of improvement we could.
We started by building our own fully-featured design studio software that allowed users to design iOS apps and export Swift code. But we quickly learned that although people were excited about it and tried it out, after about a week they went back to using Sketch. We realized that while writing algorithms for a layout engine is hard, getting adoption for your new product is harder!
Luckily one of our users pointed us in the right direction when they said that out of everything we’ve built, they were only really excited about our Auto-Layout engine. And so we decided to yank out our Auto-Layout solution and release it as a Sketch plugin. That was the turning point for us. Auto-Layout became very popular (100k users) and to this day is a main engine of growth for us.
In the past year and a half we shipped three products:
• Auto-Layout - Responsive Design for Sketch[1]
• Launchpad - Export Sketch to HTML[2]
• Timeline - Interaction Design for Sketch[3]
Of course we are dogfooding our products and have built our websites using our own tools.
We’re sure that Hacker News readers will have a ton of experience in this space, and would love to hear about your experiences and ideas!
[1] https://medium.com/sketch-app-sources/introducing-auto-layou...
The latter group often spend quite a bit of time fixing broken alignments etc when picking up a Sketch file that's used Anima. This means everyone is forced to install the plugin. The other issue then is when pushing to Zeplin, many elements aren't aligned as designed regardless of whether we've got your plugin enabled or not.
It doesn't happen every time, but it's happened enough times to warrant a studio-wide disabling of the plugin. I don't know if it's possible to easily solve this dependency issue in a future release, but if you can, we'll certainly start using it again.
So while using Auto-Layout can save an enormous amount of time creating UI, it definitely needs to be used by all designers that work on the file.
In terms of exporting to other parties such as Zeplin, we have a feature that turns off all the layout rules just before exporting. If you have tried it out here it is: https://animaapp.github.io/docs/v1/launchpad/faq.html#Export...
And thank you for the kind words!
We design very customized websites with complex layouts (box titles that are off-canvas etc).
I would love to reduce the amount of time that the developers need to realize a design. Our designers are usually much faster than the developers and they become the bottleneck in most projects. If the output is usable for production (and not a position:absolute nightmare), I would love to use something like this.
I don't care about incompatibilities with Zeplin and studio-wide usage as long as it has a good HTML and CSS quality (responsive, modular and clean).
OT: I like that the Yo app founder has a very short name, too. About Anima - would love to see you succeed! Would be happy to have such a tool.
The problem is that custom UI is extremely non-trivial. Getting something to work in a way thats even just slightly different from what the default UI does can be a huge undertaking; from reasons having to do with integration, rendering, dataflow, or any other obscure thing.
IMO it’s a dangerous misconception to think that most custom UIs can be implemented via a simple extension- that’s the real reason why there’s so many front end developers.
This type of solution has obvious upside. The truth is that it has been tried many times before (Flash, Frontpage, Adobe Muse). The hard thing here is to being adopted both by the designers who start the process and at the same time generate code that developers will agree to work with.
The way we tackle this is by giving designers tools to express what they want in ways that were not available before, and then use the output to generate code. For example, one popular feature is Stacks[1] which is basically CSS Flexbox for Sketch. When designers use Stacks, we can then use that data and generate an actual CSS Flexbox from it.
Designers are adopting this approach but in terms of code generation, we still have a lot of room for improvement. The code works great, but it's not always optimal in the way that a good human developer would write it.
We have an internal goal, which is to pass the "Turing Test", where a developer will not be able to recognize whether our algorithms or by a fellow human developer.
[1] https://medium.com/sketch-app-sources/auto-layout-introducin...
Writing HTML and CSS is not the hard part of front-end development. A modest developer can put this together quickly. The hard part is using javascript or someone other tech to piece it all together.
I would encourage you not to chase your internal goal. Instead, focus on making designers better instead of trying to turn designers into developers. W3C will release a new CSS/HTML spec, or some fancy new JS framework will come out and you'll be left scrambling to re-engineer.
For the time being, even if developers don't use the generated code, but rather just inspect it is better then guessing how a component should work by staring at a static image or a GIF.
If you take for example this elaborate interactive component: https://handoff.animaapp.com/#/timeline/XKHmOQP5Hcuipv/anima...
It was made completely by Michal, our co-founder/designer in Sketch with Anima. No code was manually written. Trying to convey this today usually involves hand-waving or for advanced teams, a GIF. By handing off functional code, a developer can interact and see the values that make this work. Even if not using the actual generated code.
Does that make sense? What do you think?
You guys helped invent this space not too long ago and I'm curious where you all see things going long term?
Today the tools we provide force designers to think in a more structured way. A great example of this is Stacks, which forces a layout to be consistent. Unstructured design, or in other words, floating layers corresponds to CSS's absolute position. Stacks, however, corresponds to CSS's Flexbox.
By enforcing designs to adhere to concepts which are borrowed from the development world, we can actually convert design to code.
In the long-term, we see that not only layout will be structured and translated, but all aspects of a user interface.
Finally, this is very hard to do correctly but as always great risks have huge payoffs if you manage to get it right. I wish you luck. Back-and-forth is where the future is.
P.s. not sure if you have it but also make a code-2-designer. Can't count the times we had our devs fix issues in the design only to have a turnaround time of weeks before design handed over the new templates.
How to call this new breed of designers though? We have had devops for the new ops* which has a nice ring to it. But this?
*Semi-ops depending on your company and company size.
https://github.com/tonybeltramelli/pix2code
Seriously, you guys should start aligning with Figma & Atomic...