I'm going to review this from a very subjective standpoint. If you want, you can just announce that I'm not the intended audience, that's OK. So, I'm a lead developer of a mobile project (usually, a game), who wants to improve collaboration with designers.
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.
As you've worked in games, perhaps the designers you've worked with are more adept than average at taking up new tools...? At least that is my experience. Game artists often have experience with all sorts of in-house tools with UIs of highly varying logic and consistency, whereas most "traditional" designers have used Adobe tools and nothing else.
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 :)
The Photoshop-to-code problem is also well known in web design, where a third solution, presumably applicable here as well, is the emergence of transactional PSD-to-(whatever) services; designers make PSDs, and you pay $50 to have them converted to markup, which adds only marginally to the cost and only a day or two to the turnaround time.
There have been a couple of tools that have attempted to automate this. A quick google for "automatic PSD to HTML" will turn up many. But almost all of them produce markup that is tightly dependent on the organization of the layers in the source document. Also the elements are usually absolutely positioned and the code in general needs a ton of work to get to a good shape.
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.
All sorts of web pages. The tool will create HTML and CSS, the elements will use DOM flow and positioning, and grid columns if that information is annotated through our UI. The developer has to give meaningful names through our UI so that we can create CSS classes that follow BEM conventions.
But this is not Photoshop-to-code problem. I thank the gods I have little to do with web and javascript almost every time I read something about that field.
This is Photoshop-to-another-designer-friendly-WYSIWYG-tool problem.
Were you actually successful in getting the designers to ditch the WYSIWYG tools and write code instead?
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)
I like your point about having designers a the particular platforms UI tool/system. It's sad though that they can't learn a platform agnostic tool so that skills are more shared and portable across platforms. So I like this kind of solution for tackling that. Also, making it easy for designers to mockup interactions in more than just series static mockups is much better for articulating their designs. This is why so many design prototyping tools are coming out of Facebook, Apple, etc these days. Having it online, collaborative, and platform agnostic seems like a strong basis for a successful production provided they can provide tooling to make it easy to use on popular platforms. I think an embeddable UI runtime you can drop into projects would be the ideal technical approach.
In my experience, getting most designers I work with to use any new tool or adapt to any new process is about as easy as preventing the sales staff from selling features before we've written them. At my last job, we couldn't even pin designers down to a pattern library. Why am I the one who has to convince designers a pattern library is a good idea?
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.
The main differentiator and focus of the post is "we're making this run in the browser". But nowhere does it explain why that's better for designers. You don't need it to power collaboration features.
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.
Sorry, I thought it was launched. After I signed up, I got this "You’ve been added to our waitlist. In order to ensure the best possible experience, invites are being sent in phases. We'll let you know when we're ready for you.
See you soon!"
A little too early for the title, but product looks promising.
Dylan, perhaps in the demo video they should be designing something other than a Weather app? As it's basically a poster child for the "bells & whistles over substance" trend in the UI design.
Yep — in the video, our primary goal for the UI was visual: we wanted something that was visually very different from Figma so it would stand out against the Figma interface. Makes sense the lack of substance shows through ;)
While we don't plan to change the video, I think your point absolutely has merit.
The product looks rather cool and congrats to the team, but I have some concerns with this,
Today, after three years of silence and hard work, I finally get to announce the launch of Sigma... we’ve raised to date ($18MM)
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.
I remember seeing an early alpha ~2 years ago that mainly consisted of pixel transformations using sliders. Amazing to see how far Figma has come since then, shrewdly moving from a browser implementation of a subset of Photoshop features to a new collaborative experience that reduces friction on a workflow already used by many in interface design.
I think this is amazing technology and great work, but as a designer I worry that collaborative design that this facilitates might actually lead to a worse overall product. From my experience, design is better as a dictatorship of the best designer. I'm sure many will disagree here.
A couple of years after everyone's dropped Photoshop for Sketch. It could be the case that designers, like front-end developers, will have to get used to the idea that all of their tooling will change every ~3 years.
Personally very excited about this and want to start using it immediately.
Looks cool. I wonder if it generates actual code/project stuff or is a pure design tool like InVision/Sketch/etc.? I've always felt designers are well served by existing tools and know how hard it is to get them to switch.
This looks great. It's tough to win over people from other tools, so it'd be nice to see comparison with Sketch, say. Good luck, the future of Web is bright with projects like this one.
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.
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.