What design tools get wrong(kilianvalkhof.com)
kilianvalkhof.com
What design tools get wrong
https://kilianvalkhof.com/2019/design/what-design-tools-get-wrong/
83 comments
When someone says HTML & CSS is terrible I ask them to design something better that lets you represent user interfaces that can adapt across multiple screen sizes, and allow complex layouts that Flexbox and CSS Grid makes possible. It is easy to criticize something if you don't have to worry how you would do it better.
That said, HTML & CSS is just how the world currently is. It doesn't mean that it is the best possible way to do it. CSS could've been very different if not for many fortuitous events in history: https://eager.io/blog/the-languages-which-almost-were-css/
The best possible way to represent user interfaces is to represent them visually. Having to learn code to build UI is just today's limitation. While many have tried and failed to do better, this is still an open question.
Today maybe a designer must understand HTML & CSS to fully embrace the medium. But that means they have to get out of their visual thinking mode, and look at letters on a screen and interpret them in their mind's eye. As programmers we're used to it, but it doesn't mean it is the best nor the only way to do it.
So I'm all for articles like this that questions the status quo instead of accepting defeat and asking people to just get on with the program.
That said, HTML & CSS is just how the world currently is. It doesn't mean that it is the best possible way to do it. CSS could've been very different if not for many fortuitous events in history: https://eager.io/blog/the-languages-which-almost-were-css/
The best possible way to represent user interfaces is to represent them visually. Having to learn code to build UI is just today's limitation. While many have tried and failed to do better, this is still an open question.
Today maybe a designer must understand HTML & CSS to fully embrace the medium. But that means they have to get out of their visual thinking mode, and look at letters on a screen and interpret them in their mind's eye. As programmers we're used to it, but it doesn't mean it is the best nor the only way to do it.
So I'm all for articles like this that questions the status quo instead of accepting defeat and asking people to just get on with the program.
> When someone says HTML & CSS is terrible I ask them to design something better that lets you represent user interfaces that can adapt across multiple screen sizes, and allow complex layouts that Flexbox and CSS Grid makes possible.
Uh huh. And how many years did it take to actually get Flexbox and CSS Grid? I mean...They're both still "Candidate Recommendations" in 2019. That's not even the penultimate level of recommendation. You definitely can't use Grid if you want broad compatibility; it was only first implemented in 2017. "People should update their software to the latest versions! And they should switch browsers to use one that supports my nonstandard features!" Oh, yes? Well they don't. And let's not even talk about Grid Level 2 which is implemented nowhere. We've gone through generations of faking markup with javascript because the dogma behind CSS has always been a terrible mess. "No tables for layout!" Ok, what else are you supposed to use to arrange things in grids? "Uhhh....give us a couple decades to get back to you on that."
When people say that CSS is terrible, they mean the actual standard parts, and they mean for the past 22 years.
Uh huh. And how many years did it take to actually get Flexbox and CSS Grid? I mean...They're both still "Candidate Recommendations" in 2019. That's not even the penultimate level of recommendation. You definitely can't use Grid if you want broad compatibility; it was only first implemented in 2017. "People should update their software to the latest versions! And they should switch browsers to use one that supports my nonstandard features!" Oh, yes? Well they don't. And let's not even talk about Grid Level 2 which is implemented nowhere. We've gone through generations of faking markup with javascript because the dogma behind CSS has always been a terrible mess. "No tables for layout!" Ok, what else are you supposed to use to arrange things in grids? "Uhhh....give us a couple decades to get back to you on that."
When people say that CSS is terrible, they mean the actual standard parts, and they mean for the past 22 years.
You can use CSS grid just fine, it landed it the three major browsers at the same time. Only older IE will give you trouble, funny enough, because they were first to implement grid layouts.
"People should update their software to the latest versions! And they should switch browsers to use one that supports my nonstandard features!" Oh, yes? Well they don't.
And as long as Microsoft keeps shipping IE11, we're all doomed. Office drones aren't going to switch to something better until they're forced to.
I can't believe Windows 10 still has IE11.
And as long as Microsoft keeps shipping IE11, we're all doomed. Office drones aren't going to switch to something better until they're forced to.
I can't believe Windows 10 still has IE11.
Windows 10 doesn't have IE 11 as the primary browser, and I'm not sure it ever has.
IE is there for compatibility in enterprise environments. There are a lot of large organizations which still rely on older versions of SAP, Oracle and IBM applications, plus whatever ungodly niche vertical apps or in-house garbage was written back in the 90s.
Microsoft has to cater to this environment because it's been the lifeblood of the company for ages.
It's not all doom and gloom, though. I've had experience in some very large organizations, lately, which prefer Chrome. The landscape is beginning to change, but it will be a while, still, before evergreen browsers are the norm in the corporate world.
IE is there for compatibility in enterprise environments. There are a lot of large organizations which still rely on older versions of SAP, Oracle and IBM applications, plus whatever ungodly niche vertical apps or in-house garbage was written back in the 90s.
Microsoft has to cater to this environment because it's been the lifeblood of the company for ages.
It's not all doom and gloom, though. I've had experience in some very large organizations, lately, which prefer Chrome. The landscape is beginning to change, but it will be a while, still, before evergreen browsers are the norm in the corporate world.
>Windows 10 doesn't have IE 11 as the primary browser, and I'm not sure it ever has.
LTSC/LTSB (LTS) versions of Windows 10 don't ship with Edge and it's not possible to install it. The same goes for Windows Server 2016 and 2019.
Microsoft made it impossible for enterprises to upgrade to Edge.
LTSC/LTSB (LTS) versions of Windows 10 don't ship with Edge and it's not possible to install it. The same goes for Windows Server 2016 and 2019.
Microsoft made it impossible for enterprises to upgrade to Edge.
Office drones don’t have a choice either. What browser to use is fully based on inertia.
If there are 20 products that work in IE11, you won’t switch to Chrome just for your 21 product.
If there are 20 products that work in IE11, you won’t switch to Chrome just for your 21 product.
> "People should update their software to the latest versions! And they should switch browsers to use one that supports my nonstandard features!" Oh, yes? Well they don't.
I mean, I agree that developers shouldn't feel entitled to have all potential visitors using the most up-to-date software, but it is also definitely true that there is almost never an excuse to be using a web browser that doesn't automatically update. Forget CSS features, it's a pretty big security concern.
I mean, I agree that developers shouldn't feel entitled to have all potential visitors using the most up-to-date software, but it is also definitely true that there is almost never an excuse to be using a web browser that doesn't automatically update. Forget CSS features, it's a pretty big security concern.
I kinda sorta almost agree and yet that's definitely not how the world works for all kinds of reasons that aren't the user's fault. Also, I find it supes weird that you responded to that part and not the part where it took two entire decades of "tables are evil" before we got the first CSS grid implementation that isn't even a standard yet.
Financial, healthcare and gov institutions all have locked down workstations, often running ie 11 on windows 7.
Representing the very people who have the capacity to spend millions of $$ on my product.
Representing the very people who have the capacity to spend millions of $$ on my product.
Browser that automatically update are actually hostile to the end user. The biggest effect is that it has been making it easier to create walled gardens on the internet.
> When someone says HTML & CSS is terrible I ask them to design something better that lets you represent user interfaces that can adapt across multiple screen sizes, and allow complex layouts that Flexbox and CSS Grid makes possible. It is easy to criticize something if you don't have to worry how you would do it better.
How about Cassowary, with size classes?
I spend half my programming time working on Mac software and half on web software, and I find element layout in the former is infinitely more pleasant. No need to put elements in a specific place in the document structure to lay them out the way I want. No need to change how I'm working for vertical versus horizontal layout. Just pick the dimension/coordinate you want to set, pick the other dimension/coordinate you want it to maintain its proportion to, and you're done.
Apple's implementation got a bad rap, I believe, because the first version of Xcode didn't support it well, the first version of the API was a terrible fit for Swift (which came a couple years after it), and pre-Sierra macOS had a lot of bugs in the implementation. Today, there's no layout system I'd rather use.
How about Cassowary, with size classes?
I spend half my programming time working on Mac software and half on web software, and I find element layout in the former is infinitely more pleasant. No need to put elements in a specific place in the document structure to lay them out the way I want. No need to change how I'm working for vertical versus horizontal layout. Just pick the dimension/coordinate you want to set, pick the other dimension/coordinate you want it to maintain its proportion to, and you're done.
Apple's implementation got a bad rap, I believe, because the first version of Xcode didn't support it well, the first version of the API was a terrible fit for Swift (which came a couple years after it), and pre-Sierra macOS had a lot of bugs in the implementation. Today, there's no layout system I'd rather use.
Agree that it comes down to CSS (Box Model + Flex + Grid) vs Cassowary. I've never used it myself, so thanks for chiming in.
My understanding of it mostly comes from this thread (https://news.ycombinator.com/item?id=13125093) where the ReactNative team first attempted using Cassowary as their layout engine, but deemed it too complex/verbose and decided to use a subset of CSS. But as someone with actual comparative experience with both, would appreciate if you can tell me your thoughts on their conclusions.
My understanding of it mostly comes from this thread (https://news.ycombinator.com/item?id=13125093) where the ReactNative team first attempted using Cassowary as their layout engine, but deemed it too complex/verbose and decided to use a subset of CSS. But as someone with actual comparative experience with both, would appreciate if you can tell me your thoughts on their conclusions.
HTML was and is wonderful in its simplicity and flexibility.
CSS was not fit for purpose until relatively recently, and is still pretty limited and broken. It’s telling that you mention features of CSS which were only recently usable.
Problems with CSS - lack of a proper grid till recently, lack of variables, byzantine box model rules, a profusion of units (px,em,en,%), lack of simple computed widths etc.
All these are fixable/being fixed but I would not be sorry if the whole mess was thrown out and a more considered styling language introduced.
CSS was not fit for purpose until relatively recently, and is still pretty limited and broken. It’s telling that you mention features of CSS which were only recently usable.
Problems with CSS - lack of a proper grid till recently, lack of variables, byzantine box model rules, a profusion of units (px,em,en,%), lack of simple computed widths etc.
All these are fixable/being fixed but I would not be sorry if the whole mess was thrown out and a more considered styling language introduced.
> allow complex layouts that Flexbox and CSS Grid makes possible
What version of CSS do people complain about? By chance are you talking about bleeding edge unaccepted CSS proposals?
In any case, the list of CSS improvements is long. Off the top of my head:
* Remove min-height, max-height, vertical-align, text-align, etc. in favor of unified Flex model.
* Rename color to font-color.
* Default to box-sizing (or remove content-sizing)
* Make <fieldset> stylable by CSS.
* Make inline styles work with pseudo-selectors, or remove inline styles altogether
* Reduce the number of units
What version of CSS do people complain about? By chance are you talking about bleeding edge unaccepted CSS proposals?
In any case, the list of CSS improvements is long. Off the top of my head:
* Remove min-height, max-height, vertical-align, text-align, etc. in favor of unified Flex model.
* Rename color to font-color.
* Default to box-sizing (or remove content-sizing)
* Make <fieldset> stylable by CSS.
* Make inline styles work with pseudo-selectors, or remove inline styles altogether
* Reduce the number of units
I'd go further and bring in some of the nesting, inheritance/extend and variables that preprocessors like SCSS support as part of the standard.
Even just nested would be nice, and very simple.
Sure, can you whip up an easy 3 column layout for me using the parts of CSS that are fully standardized?
CSS does a lot of things really well, but makes some common tasks way more difficult than they need to be.
CSS does a lot of things really well, but makes some common tasks way more difficult than they need to be.
<table>
Sorry, I couldn't resist
<tr>
<td></td>
<td></td>
<td></td>
</tr>
Sorry, I couldn't resist
<style>
table td {width:33.3333%;float:left;padding:10px;box-sizing:border-box;margin:0;display:block;border: none;border-collapse: inherit;border-spacing: 0;}
table {width:100%}
</style>
lol
lol
[deleted]
This is pretty contrived but it took less than 10 minutes and required 0 googling:
https://jsbin.com/nedesuvozo/edit?html,output
The important two css classes:
https://jsbin.com/nedesuvozo/edit?html,output
The important two css classes:
.Example--outer-container {
display: flex;
flex-direction: row;
}
.Example-three-column-inner-container {
width: 33.333%;
}
>When someone says HTML & CSS is terrible I ask them to design something better that lets you represent user interfaces that can adapt across multiple screen sizes, and allow complex layouts that Flexbox and CSS Grid makes possible
Short answer: layout and styling in one DSL with one syntax/grammar and not you know, two. But the problem isn't "how do I make something that's better" but "how do I make something that's better and supported on my target platforms."
If browser engine support isn't a design concern there are plenty of alternatives, many of which are arguably superior to HTML + CSS.
Short answer: layout and styling in one DSL with one syntax/grammar and not you know, two. But the problem isn't "how do I make something that's better" but "how do I make something that's better and supported on my target platforms."
If browser engine support isn't a design concern there are plenty of alternatives, many of which are arguably superior to HTML + CSS.
What are some good examples? I remember using Android's relative layout system several years ago, and it was quite powerful, but I wouldn't call it easier to grok than CSS flex or grid.
> When someone says HTML & CSS is terrible I ask them to design something better that lets you represent user interfaces that can adapt across multiple screen sizes, and allow complex layouts that Flexbox and CSS Grid makes possible.
How do mac devs do this? Mac apps are some of the best around and both designers and developers appear to really like designing and developing mac apps.
How do mac devs do this? Mac apps are some of the best around and both designers and developers appear to really like designing and developing mac apps.
>When someone says HTML & CSS is terrible I ask them to design something better that lets you represent user interfaces that can adapt across multiple screen sizes, and allow complex layouts that Flexbox and CSS Grid makes possible. It is easy to criticize something if you don't have to worry how you would do it better.
Easy, something like Winforms or one of its successors like whatever they make Win10 apps in. Even the new Unity3D UI stuff is better.
Easy, something like Winforms or one of its successors like whatever they make Win10 apps in. Even the new Unity3D UI stuff is better.
>Even the new Unity3D UI stuff is better.
Do you mean the new UI stuff that's based on CSS?
Do you mean the new UI stuff that's based on CSS?
I would never work with a design person who only knew how to click buttons to make UI's.
They're just going to make more work for the real developers who have to constantly fill in the lack of understanding about how the back-end works.
It isn't a limitation. It's a prerequisite. You wouldn't want a bus driver who's never driven a car before.
And if design systems ever evolve to the point where you can just click/drag some buttons to design a UI then that's the day the value of that profession should rightfully drop to zero. Lowering the bar that low only leads to vulnerabilities by blurring the lines between amateur and professional. Honestly the design crowd gets too much credit as it is.
Look at manual machinists. They have legitimate skills that only come with experience. They demand righteous salaries for those skills. BUT CNC machines have all but destroyed the need to employ manual machinists so instead you spend more on your machine up-front but you save forever because you can literally teach anybody with a pulse how to run it. The result is you have countless experienced and skilled machinists who are unemployable in today's market and a bunch of cheap amateurs churning out barely conforming products for $10/hour.
They're just going to make more work for the real developers who have to constantly fill in the lack of understanding about how the back-end works.
It isn't a limitation. It's a prerequisite. You wouldn't want a bus driver who's never driven a car before.
And if design systems ever evolve to the point where you can just click/drag some buttons to design a UI then that's the day the value of that profession should rightfully drop to zero. Lowering the bar that low only leads to vulnerabilities by blurring the lines between amateur and professional. Honestly the design crowd gets too much credit as it is.
Look at manual machinists. They have legitimate skills that only come with experience. They demand righteous salaries for those skills. BUT CNC machines have all but destroyed the need to employ manual machinists so instead you spend more on your machine up-front but you save forever because you can literally teach anybody with a pulse how to run it. The result is you have countless experienced and skilled machinists who are unemployable in today's market and a bunch of cheap amateurs churning out barely conforming products for $10/hour.
On the reverse, let designers refuse to work with developers who have never observed users using their product (user research in formal terms), or don't understand color theory, or haven't designed a landing page that converts well, don't know how to use Sketch or Figma.
I've been trying to learn how to do design well - struggling to get the onboarding UX for a complex workflow right. It is something very difficult for me to solve well, but a good designer can start iterating in a few days' time. Design is indeed a valuable and deep craft, and my lack of respect for it in the past stemmed from not knowing it and not having worked with masters in the field.
Yes it would be wonderful if designers also understood HTML & CSS - it is quite adjacent to their area of expertise. But is it a deep enough skill if the market doesn't award salaries to people who specialize only in HTML & CSS as much as it does for application developers?
The current designer-developer collaboration workflow is broken, and the dominant narrative blames designers for not learning HTML & CSS. I was also party to it till recently, but it is partly the fault of programmers who don't expend the effort to understand how design is done and what "good" looks like in that craft. It is also the fault of the current crop of tools - vector drawing tools that don't have abstractions nor supports responsive design, and HTML & CSS which is far removed from its visual rendering.
It is a give and take, and it is so much more fun to work when people are eager to learn from each other.
I've been trying to learn how to do design well - struggling to get the onboarding UX for a complex workflow right. It is something very difficult for me to solve well, but a good designer can start iterating in a few days' time. Design is indeed a valuable and deep craft, and my lack of respect for it in the past stemmed from not knowing it and not having worked with masters in the field.
Yes it would be wonderful if designers also understood HTML & CSS - it is quite adjacent to their area of expertise. But is it a deep enough skill if the market doesn't award salaries to people who specialize only in HTML & CSS as much as it does for application developers?
The current designer-developer collaboration workflow is broken, and the dominant narrative blames designers for not learning HTML & CSS. I was also party to it till recently, but it is partly the fault of programmers who don't expend the effort to understand how design is done and what "good" looks like in that craft. It is also the fault of the current crop of tools - vector drawing tools that don't have abstractions nor supports responsive design, and HTML & CSS which is far removed from its visual rendering.
It is a give and take, and it is so much more fun to work when people are eager to learn from each other.
> but it is partly the fault of programmers who don't expect the effort to understand how design is done and what "good" looks like in that craft
Very much something I agree with. Even on HN, when a non-designer has made something with a GUI, you'll often hear the excuses along the lines of "well, don't blame me if it's ugly, I'm not a designer".
Then you shouldn't have deigned to make something with a UI until you've run it past someone first. You land up with these utilities and apps that are intended to be used by regular, non-technical people that are just complicated and unwieldy Office '97 collections of tiny, unusable buttons that don't make any bloody sense to anyone.
Very much something I agree with. Even on HN, when a non-designer has made something with a GUI, you'll often hear the excuses along the lines of "well, don't blame me if it's ugly, I'm not a designer".
Then you shouldn't have deigned to make something with a UI until you've run it past someone first. You land up with these utilities and apps that are intended to be used by regular, non-technical people that are just complicated and unwieldy Office '97 collections of tiny, unusable buttons that don't make any bloody sense to anyone.
It means "I know this bit is bad but I don't know how to make it better". It's an expression of vulnerability and I'm glad people are releasing their half-finished stuff with this admission rather than not releasing.
I actually think your behaviour here is kind of crappy to take an occasion where someone is admitting to weakness and twisting it on them. Especially when it's completely voluntary to even use these products.
Shame on you.
I actually think your behaviour here is kind of crappy to take an occasion where someone is admitting to weakness and twisting it on them. Especially when it's completely voluntary to even use these products.
Shame on you.
> Shame on you
This part of your post I find to be in contradiction with the HN guidelines. It's not a helpful, it's merely snide and dismissive.
Anyway, I don't think my behaviour is crappy. It is undoubtedly better to run your design past someone, test things, take feedback, fix issues, and improve the interface to correspond with the things that people find difficult. If people want help with interface design, the world is not short of willing volunteers with the relevant expertise.
Especially considering I made it clear I was talking about utilities used by, and I quote myself, "regular, non-technical people" — they don't care whether you're making an "expression of vulnerability", they want their software to work. Additionally, the world of IT helpdesk does not applaud having to troubleshoot problems that should've been solved years ago because so-and-so decided to do everything by themselves rather than do some basic user testing or simply have someone else look at their design.
If something is in a testing state, call it a beta. I respect a product that knows it isn't ready for the big time and so is explicitly marked for improvement, either by collaboration with a designer at a later stage or community involvement — this is what happens a lot in open source.
However, don't put it into production, particularly if its design also leads to more problems overall for the users by virtue of its premature release.
I take the user-centric view of product design. We are making these things for other people. They are not going to give us trophies for participation.
This part of your post I find to be in contradiction with the HN guidelines. It's not a helpful, it's merely snide and dismissive.
Anyway, I don't think my behaviour is crappy. It is undoubtedly better to run your design past someone, test things, take feedback, fix issues, and improve the interface to correspond with the things that people find difficult. If people want help with interface design, the world is not short of willing volunteers with the relevant expertise.
Especially considering I made it clear I was talking about utilities used by, and I quote myself, "regular, non-technical people" — they don't care whether you're making an "expression of vulnerability", they want their software to work. Additionally, the world of IT helpdesk does not applaud having to troubleshoot problems that should've been solved years ago because so-and-so decided to do everything by themselves rather than do some basic user testing or simply have someone else look at their design.
If something is in a testing state, call it a beta. I respect a product that knows it isn't ready for the big time and so is explicitly marked for improvement, either by collaboration with a designer at a later stage or community involvement — this is what happens a lot in open source.
However, don't put it into production, particularly if its design also leads to more problems overall for the users by virtue of its premature release.
I take the user-centric view of product design. We are making these things for other people. They are not going to give us trophies for participation.
You can either have something ugly now. Or something well designed and beautiful never.
Which one do you want?
Which one do you want?
These are far from the only choices.
I know the triangle of forces would have something to say about my statement, but I find too many developers purposefully build a wall around themselves and product design, perhaps using the aforementioned triangle as justification for why they should keep that wall erected.
Yet, even a passing attempt to understand the basics of design, whether of user interfaces or even of something as mundane as a chair, opens one's mind up to possibilities hitherto unseen due to failing to understand that there can be a strong link between aesthetics and function.
I know the triangle of forces would have something to say about my statement, but I find too many developers purposefully build a wall around themselves and product design, perhaps using the aforementioned triangle as justification for why they should keep that wall erected.
Yet, even a passing attempt to understand the basics of design, whether of user interfaces or even of something as mundane as a chair, opens one's mind up to possibilities hitherto unseen due to failing to understand that there can be a strong link between aesthetics and function.
Have you checked out Flutter and their vision of cross-platform GUI development?
When you say "I would recommend learning more code instead" it's aggressive since there are different areas of expertise that contribute to a product. But in general, anything that is not "code" is underrated by software engineers. I would recommend learning more product design instead :o)
I can comment on this from my experience. I studied Computer Science, and my passion for UI development led me to switch to product design after being coding for more than 10 years. I design with code too, and I did many prototypes using different UI frameworks.
But, there are different design activities, and sadly not a single tool is adequate for all.
If you are making decisions about UI layout, visuals, or UI motion working with code may slow you down. Even if you use CSS grids and flex, there is a penalty caused by the lack of direct manipulation and the freedom to try multiple ideas quickly.
To me, the author just wants better refactoring and maintenance tools over the existing visual design tools. It's a little bit disappointing that design tools evolved in many areas, but did a regression in others. For example, more or less in 2008, Microsoft did a tool called Expression Blend. The tool, based on ideas from Bill Buxton, had the goal to maintain a continuity between mocks and the final implementation. You were able to import PSD layers and later convert them to components, or to sketch the UI flow in the tool. I never used it for anything more than simple experiments, but the idea had potential. Even Adobe did a similar project that never saw the light (it was called Adobe Thermo, then Catalyst and it died with Flex).
I can comment on this from my experience. I studied Computer Science, and my passion for UI development led me to switch to product design after being coding for more than 10 years. I design with code too, and I did many prototypes using different UI frameworks.
But, there are different design activities, and sadly not a single tool is adequate for all.
If you are making decisions about UI layout, visuals, or UI motion working with code may slow you down. Even if you use CSS grids and flex, there is a penalty caused by the lack of direct manipulation and the freedom to try multiple ideas quickly.
To me, the author just wants better refactoring and maintenance tools over the existing visual design tools. It's a little bit disappointing that design tools evolved in many areas, but did a regression in others. For example, more or less in 2008, Microsoft did a tool called Expression Blend. The tool, based on ideas from Bill Buxton, had the goal to maintain a continuity between mocks and the final implementation. You were able to import PSD layers and later convert them to components, or to sketch the UI flow in the tool. I never used it for anything more than simple experiments, but the idea had potential. Even Adobe did a similar project that never saw the light (it was called Adobe Thermo, then Catalyst and it died with Flex).
I'm working on a tool with the express goal of "maintaining continuity between mocks and final implementation." I think I could learn a few things about this from you. Would you have time for a chat? My email is my account name at gmail dot com.
A little background: you are more or less describing the author of the blog post!
That’s the interesting thing about being a coder who designs, the tooling on both sides always lets you down at least a little. Having that wider context is worth the disappointment, I think.
That’s the interesting thing about being a coder who designs, the tooling on both sides always lets you down at least a little. Having that wider context is worth the disappointment, I think.
Basically this. It's mind boggling to think a designer could ever excel without knowing how to work with the medium they're designing for.
One of the fundamentals of art school is learning how to work with the characteristics of your medium.
One of the fundamentals of art school is learning how to work with the characteristics of your medium.
The whole purpose of tools is to make craft accessible to more people. It's perfectly logical not to expect a designer to excel without knowing what they're designing for, but to expect tools to aim for that goal. How much knowledge has to be "in the head" vs. "embedded in the tool" can be debated, but the direction where things generally go seems pretty obvious.
Is it though? If so, it's deeply troubling.
The purpose of a screwdriver isn't to make working with screws more accessible, it's to make it possible and convenient. The purpose of power drill isn't to be more accessible than a screwdriver - it's to enable working faster and easier with screws, and to enable working with screws and materials for which using a screwdriver isn't feasible.
This brushes my primary annoyance about modern software - the current trend is to focus on making the basic, entry-level tasks accessible, at the expense of tasks that a proficient user might want to perform. The more advanced tasks are not just made more difficult - they're often made impossible.
The purpose of a screwdriver isn't to make working with screws more accessible, it's to make it possible and convenient. The purpose of power drill isn't to be more accessible than a screwdriver - it's to enable working faster and easier with screws, and to enable working with screws and materials for which using a screwdriver isn't feasible.
This brushes my primary annoyance about modern software - the current trend is to focus on making the basic, entry-level tasks accessible, at the expense of tasks that a proficient user might want to perform. The more advanced tasks are not just made more difficult - they're often made impossible.
I'm not sure the screwdriver analogy works here.
The tool isn't the screwdriver alone, it's the screwdriver and the screw, which allow for easier fastening than, say, advanced woodworking joinery. A powered screwdriver also allows non-trained people to get closer to the productivity of a trained professional.
What are some examples of that annoyance in modern software?
The tool isn't the screwdriver alone, it's the screwdriver and the screw, which allow for easier fastening than, say, advanced woodworking joinery. A powered screwdriver also allows non-trained people to get closer to the productivity of a trained professional.
What are some examples of that annoyance in modern software?
The alternative is to make an omelet you must first invent the universe. At some point you have to trust the tools to do their job even if you don't fully understand them and get on to getting shit done.
Yes but...
The best coders I've ever worked with understood the hardware
The hardware engineers I've ever worked with understood the physics
The physicists I've ever worked for understood the math...
At some point you just gotta say "I need better tools"
The best coders I've ever worked with understood the hardware
The hardware engineers I've ever worked with understood the physics
The physicists I've ever worked for understood the math...
At some point you just gotta say "I need better tools"
Some of the best designers understand code. Its not turtles all the way back as you seem to imply.
In general a broad perspective is beneficial to a designer because they deal with the holistic reality and need to apply it to a somewhat fuzzy solution.
To compete with others thats more than enough and tools have very little to do with it.
In general a broad perspective is beneficial to a designer because they deal with the holistic reality and need to apply it to a somewhat fuzzy solution.
To compete with others thats more than enough and tools have very little to do with it.
Out in the real world, I agree with you. I this specific instance I was responding mainly to this comment:
>Sounds like the author wants his tools to be as fully featured as the code that will embody the resultant design. In that case I would recommend learning more code instead of relying on a proxy that will never be as flexible
Which is precisely an argument by turtles.
>Sounds like the author wants his tools to be as fully featured as the code that will embody the resultant design. In that case I would recommend learning more code instead of relying on a proxy that will never be as flexible
Which is precisely an argument by turtles.
Argument by turtles is only invalid if it doesn't converge in the end. If a professional designer needs to have less than half of a professional coder's expertise, and a professional coder needs to have less than half of a professional hardware engineer's expertise, etc., then the whole thing converges to a finite value.
An alternative way to view this: the output of your work in your field will almost always be priced and used outside of that field. The more you know about how your work will be used, the more context you have to evaluate whether or not you're doing things right. Given how human cognition works, having extreme tunnel vision is actually suboptimal, compared to being somewhat proficient in things around your particular specialty.
An alternative way to view this: the output of your work in your field will almost always be priced and used outside of that field. The more you know about how your work will be used, the more context you have to evaluate whether or not you're doing things right. Given how human cognition works, having extreme tunnel vision is actually suboptimal, compared to being somewhat proficient in things around your particular specialty.
I don't know if "flexible" is the goal. In fact, the listed feature of restricting font and color choices is reducing flexibility. The author seems to just want features to automate repeated tasks.
Agree wholeheartedly. The best design teams are ones who either “know how the sausage is made” (that is, have a general knowledge of how their design would translate to code) or have guidance from developers on what is and isn’t feasible. The really good ones know the quirks of the platform and will design around them (for example, messing with UINavigationController on iOS breaks a bunch of things and is generally not a good idea).
Unfortunately this comment is conflating two ideas.
Nothing in this article conflicts with the idea that a UX designer knowing how to implement their designs in code would be a benefit.
I don't see a problem with the author (and others like myself) wanting the tools to be more capable.
Have you developed a design system? Do you understand the context of this domain? I don't ask this to be rude, but the issues that the author mention are some of the key problems with the state of being able to maintain design systems.
It's more about the ability to efficiently generate and document the design intent and iterate on the design. This then needs communicated to the full team, whether that's stakeholders or the team implementing the design.
I think the authors suggestions are very good and valid.
Nothing in this article conflicts with the idea that a UX designer knowing how to implement their designs in code would be a benefit.
I don't see a problem with the author (and others like myself) wanting the tools to be more capable.
Have you developed a design system? Do you understand the context of this domain? I don't ask this to be rude, but the issues that the author mention are some of the key problems with the state of being able to maintain design systems.
It's more about the ability to efficiently generate and document the design intent and iterate on the design. This then needs communicated to the full team, whether that's stakeholders or the team implementing the design.
I think the authors suggestions are very good and valid.
> The best designers I’ve worked with not only understand their own domain but the possibilities and limitations of how it will be executed, because they are also developers.
I've noticed this as well. The best designer I ever worked with was obviously great at design, but also great at css, she rocked! I've seen this more than once, but would estimate less than 10% of designers I've worked with actually took the time to learn css.
I think more designers should learn css, and more engineers should learn at least some basics of design. Then everyone could communicate better and get more done faster.
I've noticed this as well. The best designer I ever worked with was obviously great at design, but also great at css, she rocked! I've seen this more than once, but would estimate less than 10% of designers I've worked with actually took the time to learn css.
I think more designers should learn css, and more engineers should learn at least some basics of design. Then everyone could communicate better and get more done faster.
While it's good to know how the sausage is made this doesn't solve the issue. They want portable formats for common features. Learning a single tech stack doesn't accomplish this.
I’m surprised there aren’t more design tools with scriptable interfaces. Unity does this really well and gives programmers the opportunity to easily code up solutions to help designers with custom workflows.
Arrogant attitude imo and at some point in the future you'll see how wrong you are about this. I meet a lot of coders who feel the same but they've got their head in the sand
It seems that author advocates for design tools to become more and more like developer tools - a notion that I, as a developer, can totally get behind.
However, in my 12 years of experience in game development, many people who are world-class designers and artists don't have the same mental model as developers. There are a lot of "technical art" issues that in the end, you'd rather handle on a developer's side. I just don't think that a person who spends his time thinking about character's emotion, colour balance, human anatomy and other art-related issues is in the same mind space to think about technical issues like which UI containers should be scaled on what rules (full-screen or safe area? hugging the screen outside or inside?) for different screen sizes, how things should be composed from layers and animated, how assets can be converted from a static image to a resizable one, how a giant image can be cut into a 9-slice (or in a more complicated way) to save texture budget, how can we reuse already existing assets without importing another image that is very, very similar, how different kind of gradients behave with not-pixel-perfect scaling and crunch compression (and I didn't even go into 3d!). I tried empowering designers and artists so they would make these decisions, but they hated it and were miserable - so in the end I'd rather get a static, single-sized PSD and do all that work myself.
All of this, of course, are just my 2 cents from a specific industry and with a very specific kind of people in mind - I'm not trying to impose these views on any designers and artists who want to get into the technical art side and would be thrilled to see more and more individuals who can be productive and happy in this kind of hybrid role. But as a matter of fact, these people are very, very rare and we shouldn't expect most artists to be like that.
However, in my 12 years of experience in game development, many people who are world-class designers and artists don't have the same mental model as developers. There are a lot of "technical art" issues that in the end, you'd rather handle on a developer's side. I just don't think that a person who spends his time thinking about character's emotion, colour balance, human anatomy and other art-related issues is in the same mind space to think about technical issues like which UI containers should be scaled on what rules (full-screen or safe area? hugging the screen outside or inside?) for different screen sizes, how things should be composed from layers and animated, how assets can be converted from a static image to a resizable one, how a giant image can be cut into a 9-slice (or in a more complicated way) to save texture budget, how can we reuse already existing assets without importing another image that is very, very similar, how different kind of gradients behave with not-pixel-perfect scaling and crunch compression (and I didn't even go into 3d!). I tried empowering designers and artists so they would make these decisions, but they hated it and were miserable - so in the end I'd rather get a static, single-sized PSD and do all that work myself.
All of this, of course, are just my 2 cents from a specific industry and with a very specific kind of people in mind - I'm not trying to impose these views on any designers and artists who want to get into the technical art side and would be thrilled to see more and more individuals who can be productive and happy in this kind of hybrid role. But as a matter of fact, these people are very, very rare and we shouldn't expect most artists to be like that.
A UX designer or UI artist should absolutely be concerned with these things. Every UI artist I know has asked "How do I do 9-slicing?" on day one.
I try to put as much power in the hands of the UI artist; if they have full control and an accurate preview (or better yet, WYSIWYG) then they can iterate on the screens without my involvement, and turn in something beautiful that I just need to connect to the actions / data sources.
> a person who spends his time thinking about character's emotion, colour balance, human anatomy and other art-related issues Non Sequitur. Those are character artist concerns, not UI/UX artist concerns.
I try to put as much power in the hands of the UI artist; if they have full control and an accurate preview (or better yet, WYSIWYG) then they can iterate on the screens without my involvement, and turn in something beautiful that I just need to connect to the actions / data sources.
> a person who spends his time thinking about character's emotion, colour balance, human anatomy and other art-related issues Non Sequitur. Those are character artist concerns, not UI/UX artist concerns.
I think you're right, but I think the motivation for a lot of posts like this are rooted in developers working with designers who believe "issues like which UI containers should be scaled on what rules (full-screen or safe area? hugging the screen outside or inside?) for different screen sizes" should be within their domain of influence.
That separation of responsibilities is always a tough line to define in reality, and I do agree that the tools used by whomever is assuming that role should become more like developer tools.
That separation of responsibilities is always a tough line to define in reality, and I do agree that the tools used by whomever is assuming that role should become more like developer tools.
I see where you're coming from but I disagree on a few points. I work as a UX designer, designing web UI. I should understand and consider how the design will flex when the browser is resized (and understand what's possible). I have a good understanding of what will be trivial to implement versus what will require an extra week of development for little gain. I need to understand how the web works so I can think about how the site will work on a bad connection, how it will work when the request times out, how the data that powers the site is shaped and the implications of that.
The web is my medium and how can I effectively design for the entire experience (not just how it looks) if I don't understand how the web fundamentally works?
The web is my medium and how can I effectively design for the entire experience (not just how it looks) if I don't understand how the web fundamentally works?
I don't think that we really have something to disagree on here. Web and app designers like you are more technically and design-oriented; however, I'm talking about game development, where these roles require much more pure "art" skills: you don't use simple material design here, you actually draw all the real-looking materials (in the artistic style of the whole project) and characters and every little shiny detail.
Perhaps I misinterpreted your comment then. But all the same, my work is not simply applying material design to websites. We're creating our own branding and "art", but still we have to distill that down into something that can actually be implemented by a developer. Early on we do all kinds of crazy stuff but we always have to be thinking about how we'll bring it back down to Earth and how it will be used and experienced.
Kind of agree (as a developer who appreciates art) - right now we're constraining ourselves to grid-based layouts. Having been in web professionally for 15 years and recreationally for 25 years, I've seen UI conventions change a lot as technology, form factors and global design trends change.
So modern tools like sketch work for grids, mobile responsive, yada yada which is much better than using photoshop as the design sits closer to the canvas it will be rendered on. As a developer, yay that works great for me! And also it's a huge middle finger to those designers who just built stupid impossible pointless UIs in the 90s and 2000s.
But it's also very constraining for the designer, especially given how far standards have come, and it's almost a given that someone is going to come along and Bauhaus the shit out of UI.
I really enjoyed the challenge of implementing a truly creative design on the web, but there has been a general convergence towards a convenient middle point where the designs are constrained by development requirements, at least in the way the tools are geared.
That's not to say a great artist can't create something amazing but if we have to teach all our creatives that they must conform to this particular way of thinking, then we're cutting the industry short in a bad way I think.
I guess the next thing will be a sass or js library called bauhaus.js. Or is that just DOM + CSS?
So modern tools like sketch work for grids, mobile responsive, yada yada which is much better than using photoshop as the design sits closer to the canvas it will be rendered on. As a developer, yay that works great for me! And also it's a huge middle finger to those designers who just built stupid impossible pointless UIs in the 90s and 2000s.
But it's also very constraining for the designer, especially given how far standards have come, and it's almost a given that someone is going to come along and Bauhaus the shit out of UI.
I really enjoyed the challenge of implementing a truly creative design on the web, but there has been a general convergence towards a convenient middle point where the designs are constrained by development requirements, at least in the way the tools are geared.
That's not to say a great artist can't create something amazing but if we have to teach all our creatives that they must conform to this particular way of thinking, then we're cutting the industry short in a bad way I think.
I guess the next thing will be a sass or js library called bauhaus.js. Or is that just DOM + CSS?
> it's almost a given that someone is going to come along and Bauhaus the shit out of UI.
I nearly fell out of my chair of laughter when I read that.
Out of curiosity, do you mean this in a positive or a negative way?
I nearly fell out of my chair of laughter when I read that.
Out of curiosity, do you mean this in a positive or a negative way?
We created exactly what you are looking for at https://shift.studio. You design “systems” which are web components built in React (though as a designer, this is abstracted away from you). The components have variants, state, data, and we have a fully featured media query system to help you handle responsive design. Finally, we’re fully integrated with NPM so you can pull code in if you want and add functionality to your design system.
We will soon add the feature to expose your design system as an NPM package so that developers can install the system into their project and the component creation can be the domain of the designer with the application structure/creation being the domain of the developer.
This is a problem that can be solved but it can’t be half-baked solutions. It has to allow designers to fully create all states of a component and even work on components with live data flowing through.
We are in closed beta but you can view videos of how Shift works here: https://www.youtube.com/playlist?list=PLl4_DbGKML_Jb2Wq5pEGW...
We will soon add the feature to expose your design system as an NPM package so that developers can install the system into their project and the component creation can be the domain of the designer with the application structure/creation being the domain of the developer.
This is a problem that can be solved but it can’t be half-baked solutions. It has to allow designers to fully create all states of a component and even work on components with live data flowing through.
We are in closed beta but you can view videos of how Shift works here: https://www.youtube.com/playlist?list=PLl4_DbGKML_Jb2Wq5pEGW...
I worked at an agency with designers. We (web developers) convinced the designers to use Sketch for the stuff that they did for us. It saved us a ton of time over receiving Photoshop and Illustrator files to work with (the traditional "design tools").
Sure, things could be improved, but I love that we have Sketch and Figma now.
Sure, things could be improved, but I love that we have Sketch and Figma now.
I've found that agencies are behind the times when it comes to design tools. I once exported a screen of a mobile UI from Sketch as a PDF, only to be told "When I opened it in Photoshop, it was one flat layer. Can you send over your original Photoshop file?" I told them that the original was made in Sketch, and that was the last I heard from them.
To be fair, Sketch is a Mac only program, so the team may have just been unable to use it, and preferred to just move on rather than purchasing an entire new computer (and Sketch). It would perhaps been more helpful to have responded by offering to provide your Sketch assets/layers via Zeplin, which is free and web based.
Sketch files also open in Figma which is free, browser based, and OS agnostic.
[deleted]
I could nitpick the authors points, but honestly this article just boils down to "Design tools need more features!" which I generally agree with. We're living in nice times for design tools though - Figma/Sketch are leading the pack and moving extremely fast.
We're no longer in the dark ages of waiting 5+ years for Adobe to implement some basic feature (like being able to round corners on a rectangle). Well, I guess if you're for some reason using xD you're still waiting a comically long amount of time between significant releases, but that's your own fault.
We're no longer in the dark ages of waiting 5+ years for Adobe to implement some basic feature (like being able to round corners on a rectangle). Well, I guess if you're for some reason using xD you're still waiting a comically long amount of time between significant releases, but that's your own fault.
Well a lot of people don't know how to use Figma properly and still are exporting css with absolute positioned items so there's certainly a need for courses on Figma its a very deep tool but its not going to give usable results by default.
Got any good links to share that would help designers level up w/ Figma and leverage it properly?
More importantly, they have a separate use case that needs a set of features that aren't well covered by the current set of tools.
Maybe it isn't even more features, but rather a completely different tool. This could be a market opportunity.
Maybe it isn't even more features, but rather a completely different tool. This could be a market opportunity.
I recommend you try Figma, as it addresses and solves most of the gripes in your post.
I think that design tools are slowly but surely zeroing in on this. The updated versions of Sketch, Figma, and InVision can support responsive layouts, and all of them are moving from being able to create static designs, to interactive prototypes. There are several plugins and workflows out there that will convert your designs to useable code, and it is only a matter of time before this software is doing that natively and representing the full stack.
Somewhat off topic, but this gets at an issue with “components” of all types that I’ve been wanting to get off my chest:
> Design libraries are also limited in the type of things they share: just components or symbols. This works great if all your design work is just clicking together new screens with the same components, but anything new will see designers clicking into components and copying over things like colors, font variants and checking spacing just to copy that over into new components. When you copy over things, you’ll invariably make mistakes (we’re just human after all).
Ideally, a component system means you’re black boxing some function.
Unfortunately every component system I’ve ever seen has a hard boundary at some “material” transition:
A UI drawing that can be used inside a design program
A React component is bounded at the DOM and can’t handle server side concerns
A CSS component is bounded at styles and can’t handle HTML concerns
A middleware component that handles authentication, but can't reach outside the routing phase.
etc
Inevitably then, you end up having two or more tightly coupled components:
A front end component + the server API that it knows how to talk to
A little HTML widget + a microservice that it feeds with it’s own persistence
A container for wrapped content + a little middleware meant to be added to the app that serves the content
A button + a delayed job + an email template to get sent when it's done
etc
In order to do this, instead of just having one module with a tight set of concerns inside it, you have to implement some of your concerns in two places, and you also have to map data into the component interface, and then back out again. In some cases this can be 4x the complexity ("code" vs. "code + write to component interface + decode component interface + variant of code on other side of interface").
If the component could span both domains, it could just move the data exactly where it needed to go, as efficiently as possible, since the data is all internal to the component.
The conclusion I’ve come to is something like "components want to be free."
I.e. components want to have concerns that can span the entire stack, and implement procedures in arbitrarily disparate kinds of source locations.
This of course precludes ALL of the component systems which are confined to a specific material domain. It means the boundary of a component has to look something like arbitrary source code. Component interfaces can’t conform to a single template.
That raises the question “what is a component at all?” If the boundary of my component is just a set of function calls, it’s just a module. How is it a component?
And maybe it’s not. Maybe components are a local maximum in code cleanup, and I’m advocating people move past them and just write really excellent single-concern modules instead.
I don’t know. This is as far as I’ve thought it through.
(I do maintain an NPM module called browser-bridge that lets me build arbitrary client/server components, along an event sourcing library called a-wild-universe-appeared for doing persistence in an isomorohic way, and then something called bridge-module for getting dependencies in the browser... All of which let me experiment with what I'm describing, but those are all in a pre-1.0 mostly beta state. The basic interfaces are all stable though.)
> Design libraries are also limited in the type of things they share: just components or symbols. This works great if all your design work is just clicking together new screens with the same components, but anything new will see designers clicking into components and copying over things like colors, font variants and checking spacing just to copy that over into new components. When you copy over things, you’ll invariably make mistakes (we’re just human after all).
Ideally, a component system means you’re black boxing some function.
Unfortunately every component system I’ve ever seen has a hard boundary at some “material” transition:
A UI drawing that can be used inside a design program
A React component is bounded at the DOM and can’t handle server side concerns
A CSS component is bounded at styles and can’t handle HTML concerns
A middleware component that handles authentication, but can't reach outside the routing phase.
etc
Inevitably then, you end up having two or more tightly coupled components:
A front end component + the server API that it knows how to talk to
A little HTML widget + a microservice that it feeds with it’s own persistence
A container for wrapped content + a little middleware meant to be added to the app that serves the content
A button + a delayed job + an email template to get sent when it's done
etc
In order to do this, instead of just having one module with a tight set of concerns inside it, you have to implement some of your concerns in two places, and you also have to map data into the component interface, and then back out again. In some cases this can be 4x the complexity ("code" vs. "code + write to component interface + decode component interface + variant of code on other side of interface").
If the component could span both domains, it could just move the data exactly where it needed to go, as efficiently as possible, since the data is all internal to the component.
The conclusion I’ve come to is something like "components want to be free."
I.e. components want to have concerns that can span the entire stack, and implement procedures in arbitrarily disparate kinds of source locations.
This of course precludes ALL of the component systems which are confined to a specific material domain. It means the boundary of a component has to look something like arbitrary source code. Component interfaces can’t conform to a single template.
That raises the question “what is a component at all?” If the boundary of my component is just a set of function calls, it’s just a module. How is it a component?
And maybe it’s not. Maybe components are a local maximum in code cleanup, and I’m advocating people move past them and just write really excellent single-concern modules instead.
I don’t know. This is as far as I’ve thought it through.
(I do maintain an NPM module called browser-bridge that lets me build arbitrary client/server components, along an event sourcing library called a-wild-universe-appeared for doing persistence in an isomorohic way, and then something called bridge-module for getting dependencies in the browser... All of which let me experiment with what I'm describing, but those are all in a pre-1.0 mostly beta state. The basic interfaces are all stable though.)
This is why I've been holding off on trying to develop cross-platform software that talks to microcontrollers and then executes code- because I want the UI / GUI experience to be fluid, and for things like selecting something you want to change to highlight that element on the board itself- there's no well-defined method for doing this, nor even a once-trod path, and definitely not anything for those who don't know where to look.
Does anyone have suggestions for cross-platform UI's? (Not Electron)
Does anyone have suggestions for cross-platform UI's? (Not Electron)
Delphi? It has cross platform for iOS, Android, Windows, OSX, also server side on Linux. If you're after microcontrollers, it has a good sized group of IoT users.https://www.embarcadero.com/products/delphi
Are you aware of the Links programming language / research project? It lets you write code in a uniform syntax that compiles down to a mixture of Javascript, server-side code, and SQL - all from the same source file, if you like. Client- and server-side Links code can call each other seamlessly; and it has a syntax for inline HTML fragments is strikingly similar to, and I suspect influenced, JSX.
Not quite the same thing as you describe, but it's exploring a similar part of the design space:
http://links-lang.org/
Not quite the same thing as you describe, but it's exploring a similar part of the design space:
http://links-lang.org/
I think the underlying premise of this excellent article is that design tools have to get closer to the capabilities of web technologies in order to bring much needed realism to the design process.
This is exactly what still gets me going after nearly 10 years working on design tools (I co-founded UXPin back in 2010). I'm so glad that more people in the industry notice it!
Majority of the popular design tools (Sketch, Figma, InVision Studio, XD...) work in a 30 year old paradigm of image based–design tooling (originally created for early vector and raster "creative" tools that were never meant to be used to design software interfaces!). In this paradigm the output of a design tool is an illustration of the final product that has no relation to the reality of code. The rendering is different, the interactions are just slide-based simulations, the ability to describe states is nonexistent. To get more down to earth - those tools can't even render a simple text field or a checkbox!
And yes – they're getting better and better, but ultimately getting around the limitations of their paradigm is impossible. At the end of the day those tools are perfect for drawing icons and illustrations, but really bad at creating, for example, a working prototype of a form field with validation.
That's why a bunch of design tooling rebels (UXPin, Framer X, Modulz, Interplay, Shift...) started to work on code–based design tools. In this paradigm the output of a design tool is rendered from html/css/js code, but designers don't necessarily need to know how to code. Majority of UXPin users don't even know that they're prototyping interfaces with advanced JavaScript :).
Within code–based paradigm the limitations of image–based tools do not exists.
In reference to the article here are some features present in UXPin (and some others just to illustrate my point): - states of elements (every element can have multiple states and variants, originally we've built it in 2013. The new version was launched last year). - conditional interactions - javascript expression (from advanced math, regular expressions to operations on strings - in UXPin designers can build really advanced prototypes) - context awareness (prototype can be aware of the os/browser that is used for previewing or e.g. the size of the screen and conditionally render the right state of elements) - accessibility linters - import and synchronization of production React.js code (in beta, we're calling it UXPin Merge) - access to external APIs (you can, for example, build prototypes that can interact with smart devices)
None of that is possible in the old paradigm! Of course the giants of the design industry don't want you to know it, so they invest tens of millions of dollars into flashy marketing:)
Some things that Kilian mentioned are still missing, but we (and others!) are working on them.
Hope this is providing some context to the state of the design tooling industry.
Ps. Fun fact - Figma branded themselves as the first design tool with real time collaboration. We have it since 2011 and... it was also called multiplayer design :)
This is exactly what still gets me going after nearly 10 years working on design tools (I co-founded UXPin back in 2010). I'm so glad that more people in the industry notice it!
Majority of the popular design tools (Sketch, Figma, InVision Studio, XD...) work in a 30 year old paradigm of image based–design tooling (originally created for early vector and raster "creative" tools that were never meant to be used to design software interfaces!). In this paradigm the output of a design tool is an illustration of the final product that has no relation to the reality of code. The rendering is different, the interactions are just slide-based simulations, the ability to describe states is nonexistent. To get more down to earth - those tools can't even render a simple text field or a checkbox!
And yes – they're getting better and better, but ultimately getting around the limitations of their paradigm is impossible. At the end of the day those tools are perfect for drawing icons and illustrations, but really bad at creating, for example, a working prototype of a form field with validation.
That's why a bunch of design tooling rebels (UXPin, Framer X, Modulz, Interplay, Shift...) started to work on code–based design tools. In this paradigm the output of a design tool is rendered from html/css/js code, but designers don't necessarily need to know how to code. Majority of UXPin users don't even know that they're prototyping interfaces with advanced JavaScript :).
Within code–based paradigm the limitations of image–based tools do not exists.
In reference to the article here are some features present in UXPin (and some others just to illustrate my point): - states of elements (every element can have multiple states and variants, originally we've built it in 2013. The new version was launched last year). - conditional interactions - javascript expression (from advanced math, regular expressions to operations on strings - in UXPin designers can build really advanced prototypes) - context awareness (prototype can be aware of the os/browser that is used for previewing or e.g. the size of the screen and conditionally render the right state of elements) - accessibility linters - import and synchronization of production React.js code (in beta, we're calling it UXPin Merge) - access to external APIs (you can, for example, build prototypes that can interact with smart devices)
None of that is possible in the old paradigm! Of course the giants of the design industry don't want you to know it, so they invest tens of millions of dollars into flashy marketing:)
Some things that Kilian mentioned are still missing, but we (and others!) are working on them.
Hope this is providing some context to the state of the design tooling industry.
Ps. Fun fact - Figma branded themselves as the first design tool with real time collaboration. We have it since 2011 and... it was also called multiplayer design :)
I don’t think the author has spent a relevant amount of time with Figma
[deleted]
The best designers I’ve worked with not only understand their own domain but the possibilities and limitations of how it will be executed, because they are also developers.