9 ms·

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 c

by doitLP 8y ago

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. 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.

shredprez 8y ago
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.
pcmaffey 8y ago
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.
- davidivadavid 8y ago
  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.
  - TeMPOraL 8y ago
    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.
    - davidivadavid 8y ago
      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?
    - jandrese 8y ago
      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.
jayd16 8y ago
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.
vharuck 8y ago
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.
saagarjha 8y ago
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).
jasim 8y ago
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/ 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.
- ebg13 8y ago
  > 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.
quirkot 8y ago
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"
- ThomPete 8y ago
  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.
  - quirkot 8y ago
    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.
    - TeMPOraL 8y ago
      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.
diegof79 8y ago
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).
- AriaMinaei 8y ago
  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.
pixelrevision 8y ago
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.
darepublic 8y ago
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
davidjnelson 8y ago
> 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.
anmorgan 7y ago
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.

by doitLP 8y ago

shredprez 8y ago

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.

pcmaffey 8y ago

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.

davidivadavid 8y ago
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.
- TeMPOraL 8y ago
  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.
  - davidivadavid 8y ago
    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?
  - jandrese 8y ago
    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.

jayd16 8y ago

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.

vharuck 8y ago

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.

saagarjha 8y ago

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).

jasim 8y ago

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/ 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.

ebg13 8y ago
> 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.

quirkot 8y ago

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"

ThomPete 8y ago
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.
- quirkot 8y ago
  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.
  - TeMPOraL 8y ago
    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.

diegof79 8y ago

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).

AriaMinaei 8y ago
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.

pixelrevision 8y ago

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.

darepublic 8y ago

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

davidjnelson 8y ago

> 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.

anmorgan 7y ago

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.