I absolutely agree with this. Spot on.

I think that in order for the industry to make a seismic shift to other tools, like the great migration from Photoshop to Sketch, we need a design tool that fundamentally rethinks how we design, and until that happens, everything will be an alsoran of Sketch.

That, or there needs to be a fundamental design problem that Sketch doesn't solve that's really important in order to force migration, like how Retina devices forced people off of Photoshop and into vector based programs.

I always kind of chuckle when I see UI gifs and heavily animated prototypes. I'm sitting here thinking - good luck finding a dev who can do that, and good luck making that turnkey enough that it'll be approved in a real-world business setting. There's a reason nearly all of your apps don't look like any of these prototypes you see nowadays.

Lottie is a great tool and I'm starting to see it peppered in here and there, but mostly in loaders and onboarding views. I did notice this tool has a panel for exporting swift code, which is cool and I'm interested to check that out.

I think what really needs to happen is Apple needs to buy Invision and then integrate this tool right into Xcode - then we'd have something to talk about.

I think that Framer is actually going to go in the direction that you want. What I think is going to happen over the next year or so with Framer is that they're going to still keep the code portion in place, but add more UI elements in the design tab of the tool that will let users implement interactions. If users want to modify the interactions beyond what's offered in the design tab, they can switch over to the code tab.

Seriously, how many Sketch clones do we have now?

Symbols != Components. Symbol overrides != States.

Why is the idea of having a hover state or scrollable sections so outlandish?

Completely agree. Overrides are a poor man's states. Also, there are a few different components that have predictable logic, such as input fields, so why not build a simple way to toggle between state based on that logic? I think it's crazy that most of the prototyping tools still don't accept text input .

Hey Tom —

What we need is a tool that creates living components.

YES. I 100% agree with your vision of the "next generation" of design tool, and that while impressive and certainly improving designers' lives iteratively, the Figma-InVision arms race doesn't address our most fundamental pain: that "design" pixels and "app" pixels aren't connected. "Export code" isn't good enough, and "developer hand-off" is the PROBLEM, not a feature.

Have you seen Haiku? I'm on the team, and have dedicated the last several years of my life to solving exactly this problem.

Here's an example of a simple interactive component one of my teammates made visually with Haiku, with only a sprinkling of code https://codepen.io/taylorpoe/pen/oGJeba

If you're interested in an invite, I'd be happy to send you one if you sign up for our beta and shoot me an email at zack@haiku.ai

Playing with Webflow is like this. I wish it pluggin into backend more and was worked on as a design tool at this lvl. (plus mobile)

Check out Fractal

https://fractal.build/

Found this to be a step towards that - a living pattern library you can set to interpret component-based CSS with a little Gulp config. You can then expose the components via an API.

This is us :)

https://www.animaapp.com

While with Launchpad you can create a short film, it is a first step towards empowering designers to create a complete fully featured film.

I think you’re looking for Flinto.

What we need is a tool that creates living components. Just let me create components and let them have multiple states based on click-, hover- and scoll-events. Then, let me build a view consisting of those components.

Flinto does exactly this.

I don't know. What's the solution here, you think? Creating a tool that lets you output fully functional frontend logic without the need to code? If, in theory, that would be possible, it would still be only frontend, without backend. And create a tool that lets you do both? Probably not possible. And even if possible, every design/client/solution probably needs a different technological base (e.g. one use C#, the others use Node.js) so connecting that to the design in a single tool would be probably impossible too.

So this leads us back to the possibility of a tool, that would let us to create fully responsive (real) frontend part of the app/website. But again, it would not be functional: no data would be transferred from the databases, no real login, no nothing. So if you think about it, you would still just have components and theirs states with animations. And this is pretty close to what we have now.

Isn't it?

Subform is a tool that's a WIP that address your needs.

Not release yet, but their philosophy addresses your issues:

https://subformapp.com/

1000% agree

Tom, http://atomic.io.

Seriously. Get into it. Does what you want.

I totally and completely echo this sentiment, but I think we're back at square one if we need to create custom tools that mimic what it means to just sit down and build the components yourself just because designers won't code. It's completely absurd. HTML, CSS, React, Swift, XCode are all really really well thought out ways of building things, why the fuck should one company or any company for that matter over-invest in creating this made-up fairly-tale simple tool / language which basically mimics the actual way of building and translating design into implementation when the step to actually building it is so incredibly small? Framer is just Coffeescript which is syntactical sugar on top of JavaScript. I hope for the love of god no one attempts to do this because it further helps design to stay away from actual implementation, and I would even go so far to say that it helps dumb-down our roles as designers.

I agree. I think the future exists out of components. With symbols we're slowly getting there. Think about it. You design something with symbols. And with the click of a button you can export React Components. In reality this is alot more difficult of course. But it sounds good.

Designers should code, but won't

This is very true. I have been experimenting with Bubble.is, where I can focus on programming instead of writing code – there is a big difference. With Bubble, you can actually create a living project that uses real data, repeating components, component styles and pretty advanced logic without writing any code. It's quite impressive and has been fundamental for us to build high fidelity prototypes that communicate our intent to testers and developers.

Kind of like Framer, but way simpler. Designers should code, but won't.

This is a fun one for me. Because it's kind of true.

More designers than ever are learning programming and are able to solve most of the problems you describe through it. Code is just such a powerful tool.

But a lot more are waiting for some new innovation so they don't have to learn an intimidating new skill and still will be able to do everything you describe. I hope that invention will come – and we will certainly try to build it – but I'm not sure if it will (in time).

So we'll continue to try and innovate here, while we not so secretly try to teach every designer how to code too. That's going quite well, and very fulfilling to see work.

High5!