Launch of Figma, a collaborative interface design tool
medium.com
medium.com
They work in a professional WYSIWYG design tool like Photoshop and Illustrator (most know both). Then I take their designs and recreate them in the WYSIWYG design tool — Unity3d UI engine, or iOS Storyboards, or this Android XML thingy (I never actually worked with it, but from a couple of tutorials I got a feeling that it's not that different). Re-creating these designs is work-load problem as well as a communication one.
Now, this service allows me to solve this communication problem by asking designers to learn this tool — which is new to them, which requires time, and also isn't as powerful as Photoshop.
Or I can just ask the designers to learn the tool that WYSIWYG tool that I use to actually create their designs — like Unity UI or iOS storyboards — and solve both of these problems at once. Of course, they will also need to learn the scary words like "Pull", "Commit" and "Push", but after long experimentation I found out that designers are actually not brain-dead (as many engineers erroneously think) and are capable of understanding the basic VCS concepts.
This leaves me with a question: how is the first solution better than the second?
And also: how soon will we finally understand that the 00s hipster/indie-kid aesthetic is completely dead, and using it in a product video is not "cool" anymore — and haven't been for the last 5 years? Seriously, "corporate suits and elevator music" image would look much more fresh.
It seems to me that the success of Sketch lies in how little it diverges from the Adobe formula. Sketch doesn't really add any new significant mental model: it adopts Illustrator's terminology (such as artboards) and some of Photoshop's bitmap capabilities, and cleans up the three decades of cruft that obstruct the Illustrator and Photoshop interfaces. That has clearly been a good recipe for something that's easy to pick up for designers.
The UI layout tools in Xcode and Android Studio are not like that. The learning curve is very steep. Interface Builder is a tangled mess of quirky NeXT legacy and complex new concepts like auto-layout constraints. Android Studio's UI editor is worse because it's "property editor hell" -- editing layouts by twiddling Android's endless and confusingly named properties will drive designers mad. (I used to think that Microsoft's Visual Basic was the epitome of this type of tool, but Android is much worse.)
I've worked on a tool called Neonto Studio that tries to provide a designer-friendly cross-platform mobile UI solution:
It generates native code for both iOS and Android, there's no framework.
It has been really difficult to figure out a layout model that is both understandable to designers with Adobe/Sketch background _and_ can translate reasonably well to iOS and Android classes! Our current effort is pretty good, but it definitely has room for improvement.
Still, I would suggest that Neonto Studio is a much gentler way to introduce mobile UIs to a traditional designer than throwing them into the deep end of Interface Builder or Android Studio :)
There is no reason for this to be so. This can be automated - a developer should be able to convert a design into well-written HTML and properly factored CSS (using SASS mixins) in under an hour. This should make much faster and cheaper iteration on the front-end possible.
We're building a tool to do this for Sketch - https://protoship.io. It is early days, but we've been dog-fooding it to do conversion projects ourselves and I can't imagine going back to manual HTML/CSS coding again.
This is Photoshop-to-another-designer-friendly-WYSIWYG-tool problem.
Agree strongly that designers are capable of using version control, navigate the command line, and even write scripts that make their life easier (the Sketch plugin ecosystem is a good example). However, it was my observation that to do the thing that they care most about, which is building great interfaces, they do not need to know any of these things, and they do it only for the benefit of the developers. Which is a good reason why tools like these exist. I'm curious to hear your thoughts around this. Thanks.
(I'm not at all affiliated with Figma and in fact I'm building a tool in the same space)
No, this would be a stupid thing to do.
I suggested moving them to the WYSIWYG tool that is directly coupled with IDE instead.
I digress. This tool is a good thing because specialization is good, and if I, someone who uses git on the reg, can still monumentally fuck up its usage, I'm not going to force it on anyone who doesn't absolutely need it.
This echoes Asana and a lot of the "HTML native" product efforts. Which have mostly failed as a technical approach and resulted in a return to platform native apps.[1] What's different this time?
Meanwhile this prompts amazed reactions from folks who are technically impressed with how far it pushes the browser. But that was the case with prior HTML native efforts too. It distracts from a critique of the actual product features.
I'd like to see a more head to head comparison with popular tools like Sketch. Maybe the built in team collaboration is better than, say, a companion app like Zeplin. But the implementation details don't really matter to customers.
> We’re using C++ → asm.js for most of our app, so it would be tough. React-canvas, seems incredible, tho.
> The C++ → asm.js is via Emscripten. Everything else is done by our mad genius @evanwallace
Graphics engine is based on WebGL. Evan Wallace has done some incredible work. Using C++ is a smart move, an emergency exit to a native app. Yet I think a standalone app should be the priority.
See you soon!"
A little too early for the title, but product looks promising.
If you want me to bump you up on the waitlist, DM me on Twitter: I'm @zoink.
As far the designers-prefer-Mac aspect is concerned, this part is not true in countries like India.
While we don't plan to change the video, I think your point absolutely has merit.
1 - Building an online-based collaborative design tool is nothing that novel, it's all about execution. Why keep it a secret. What do you gain by keeping it stealth?
2 - $18MM to spend only to see if you got it wrong is a rather interesting approach.
1. We didn't want to talk about ourselves before we had a product we believed in. So we kept quietly building and we didn't announce until (a) the performance was great, (b) we had the features designers needed to do their work day-to-day and (c) early alpha customers were visibly excited.
2. I think we might just have different points of view on this. Our approach has been to build towards a vision rather than test a hypothesis as quickly as possible.
Best of luck to Dylan, Evan & Team!
Personally very excited about this and want to start using it immediately.
[1]: https://atomic.io/
Lost me here. I just want a solid desktop app that isn't a web wrapper or lives in the browser. I can't stand web apps to be honest. It's almost there, but it always feels like a cheap copy of what should be a proper desktop application.