Few think designer's shouldn't code. It's just two different trajectories. For example - when was the last time you drew something? Used water colors? A musical instrument?
For most designers who cross over it's a gradual process using HTML, CSS, and usually Flash / Actionscript -- at least it used to be that way until programmers & bureaucrats mucked up Flash =P
I would love to say that is true, but I've met many designers that don't really want that crossing.
Maybe it's a cultural thing, or we're still way behind here (which may very well be the case) but there are still many who think you should separate the design/implementation process. I don't agree with that, but IMHO these concept that people can't be good at both sides is an excuse. And an old one.
Is it really an excuse though? Some designers can be good at both sides, sure, but my experience is that many designers simply cannot. Their mind blanks at the most basic programming concepts, and the level of abstraction needed for practical HTML and CSS is just too much. Believe me, I've tried.
This works both ways too. I've met many developers who seem absolutely incapable of producing good designs. Even if I can convince them that design is important, and teach them basic design principles, their lack of innate caring about this is a big stumbling block.
Technically, one could argue that anything that has rules applied to it is learnable, but practically that's just not true. Some people just have no sense of rhythm or tone, for example, and regardless of how much music theory you teach them, they can't produce good music.
Now, on a more psychological note. I've found that most really good designers I meet are a certain type of person, far removed from the really good programmers I meet. I can't recall the last time I met this rare person who is really good at both, although I'm sure they exist.
Using myself as an example: I'm for the most part a geek who started programming early in life, but intentionally switched to study psychology/communications and engage in more social/presentational activities, and finally move back to 'lite-programming' as a web developer. I am acutely aware of the fact that for great design I need help, and for great programming I need help too. Despite the fact that I'm an intelligent, talented individual, I simply cannot commit to one without creating a deficiency in the other. Hell, I might not even be capable enough for it. I sometimes feel I'm too messy, gung-ho, and fidgety for serious programming, but too rule-based and logical-minded for the type of creativity that leads to great designs.
I'm content with that, but I suspect most people either fit in my camp, in the camp of great designers, or the camp of great programmers. It's simply unrealistic to use those few who excel at both as a yardstick of any kind.
(apologies for this rant, it's perhaps more appropriate in the thread as a whole than as a specific reply to you...)
I agree with everything you say except for the "I simply cannot commit to one without creating a deficiency in the other".
IMHO achieving excellence in both is unrealistic and VERY hard. Doable but improbable. But I really do think you can be good at both. Not perfect, not exceptional, but good. And for 99% of the world, good is more than enough.
The excuse part, is because I have met an enormous amount of people that use that as an excuse to not learn new things (IMHO, to be lazy). Yes, it's hard to understand programming, but many people simply accept the "if I learn this my design will suffer" (and vice-versa). With that in mind, they don't even have to try.
I also agree completely about the theory/reality dilemma, people are very different and can never be treated as the same. My only problem is with people that excuse themselves from learning something new on false premises.
Regardless of who is playing the 'game of crossing the border' it should provide super low iteration times. Otherwise it is counterproductive.
I am a coder, I can photoshop too, if needed. But it would probably kill my rhythm to find a base psd file, change something and then produce intermediate assets, then deploy then see the difference. That's why html/css is a step forward... Likewise, if you are designing and somehow want to change the behaviors, it should be as easy as that. That's the beauty of scrappy development environments...
A problem we face where I work is how designers sometimes limit themselves in the creative part of the work, because they don't know how to implement it later on.
Another complaint is that, if they have to implement something that's hard, that churn of work to do the actual thing ends up taking a toll in the design process.
Of course these problems can be circumvented but I think we're not the only place having this kind of problems.
I agree with the author, one day we'll all be teaching people to be at the middle of design and implementation.
> A problem we face where I work is how designers sometimes limit themselves in the creative part of the work, because they don't know how to implement it later on.
My experience is actually the opposite. If the designer I work with is thinking about HTML (for example) he limits himself where implementation might be difficult. (I do the same in my own design.) So by separating the roles completely, there's much more freedom – the designer designs without thinking about implementation, which forces me to upskill, which means he can push design further next time, in a virtuous circle.
we have a tool that lets you hover over the page and see precisely which piece of code is powering that element
Wait, what? You can't just drop that in there. More info! Do you think they're creating a custom html attribute in debug or something? Then some sort of browser extension?
Is this wonderful magic something I've totally missed the boat on and now look a fool?
"Inspect element" shows you HTML, it doesn't show you the JS that generated the element. I don't know about anything doing, and could very much use, the latter.
Partially, the problem is that "designer" is such an elastic word. You could argue that an interaction designer should be able to code, at least enough to make a realistic prototype - if a design isn't interactive then how can it be an "interaction" design?
Coding is less critical for visual designers though. It's better if the visual designer can render his design in html/css (or whatever), but you probably don't want to turn down an otherwise brilliant visual designer if they can't.
The "should designers code" question seems to come up again and again because interaction and visual design gets rolled into one discipline (and often one person).
I'm not so sure about the latter. They already do and the results are horrible. And I see very little signs of that they actually understand design just by doing it.
I have this odd opinion: Some people can program, and some can't.
From my FizzBuzz tests while recruiting in Germany I think 30% of Java developers with years of experience in their CV can't program. So there are some designers that can program, and there are some developers that can't. Job titles have nothing to do with it.
The era of being a Photoshop designer only...is coming to an end. HTML and CSS are going to become the baseline. Mocking up comps will still have a sort of role, I'm sure clients will still want to see them. But having a designer on board who can only mock up in Photoshop is going to be more a luxury item.
We need new design tools... Designers currently choose between photoshop and illustrator. Neither was created for the job of web design and it shows. Yes, I know you could mock it up in html/css but let's be honest, that is not a great medium for someone playing with the visual layout of the page, it's just too damn slow (not to mention the context switch of going between visual and textual representations).
Imagine a design tool that understands what a responsive grid is. This would be a great go between for a design tool and a web page. It would present a strong visual representation and it would allow the designer to resize the page and see how the design responds, without having to think about numbers...
There's smaller things as well, you can't use ems to specify text size for instance. What about a viewport mode where parts of the page that aren't in view are greyed out(with some presets for common viewport sizes).
Web pages do need a dynamic layout but are still entirely visual, I don't see any reason why a designer should have to learn how to code them up.
I think the feature set that would be relevant to a designer is pretty stable. Things like new selectors/elements are pretty irrelevant to a designer, they just make it easier to code up a design.
This is what mockup software is for i.e. Balsamiq. Once you have what you want there, then you go to Photoshop. Then export your pretty images, insert them into Balsamiq and keep tweaking.
Except in many cases you can't make layout decisions without also considering fonts and visual style.
This is why Photoshop and Illustrator are still the best tools for web design: they enable relatively quick wireframing, but also give you the possibility of increasing the level of polish within the same document.
If a new alternative is to appear, it will need to provide at least support for realistic grids, typography, and basic CSS styles, not just empty boxes and Comic Sans.
Completely agree - to which I would add the new alternative you speak of has already arrived: Google Chrome. I can design an entire page in Chrome without ever a need to refresh. Grids, typography, CSS - not to mention JavaScript, images and video - done faster and better in Chrome than I could dream for coming from Adobe. Specialized image editors like the Adobe set are properly relegated to "the cast," support roles at best. The article's screencaps are a testament to the huge recent improvements for designers within the medium itself, the browser.
Let me introduce you to your new design tool, my product Edit Room.
Imagine a design tool that lets you organize your content first, assign semantic HTML tags to your layers, and lets you easily draw out your layers with visual design tools built to honor your Photoshop muscle memory as much as possible, but also built for speed.
Imagine all your design work being cleanly rendered in HTML and CSS, while giving you the creative freedom to play with layout and typography, color and form.
Not just flexible, but responsive as well - you can preview different display widths directly in the design editor and create custom breakpoints for adjusting your design for smaller screens.
Hey, just been playing with it, looks very interesting. This looks like a good start, I think there's a long way to go with it but it's definitely headed in the right direction. Here's some feedback:
1) Maybe start with the design page, I want a blank canvas I can add things to straight away. I realise that you've gone with organising the content first but I can't imagine a designer starting to build a page this way. Following on from this it would be great to be able new content into the design view.
2) The black button to show the tools only appears if you click on the left end of the button, this confused me for a while(I kept clicking all over it until it appeared).
3) The grid - I think you need to lean on this far more. Have it on display from that start and then use the grid to actually generate the markup (rather than it just being a visual guide). I found that things jumped around a lot when I was dragging/dropping(actually on the drop). This would work well at least for horizontal positioning/alignment.
4) Snapping - I really missed this from illustrator, when you're dragging/resizing it should snap to align with other objects on the page.
5) When you resize the page the tool area remain the same size, currently the left edge is left in the same place and tool area resizes.
6) The generated markup looks pretty decent, after trying Muse and seeing the abomination that generated this was very good to see.
7) Colour picker - took a couple of seconds to grok it but actually I really liked it. Being able to adjust in several different ways feels very natural i.e. maybe a bit darker, I want a red, maybe a bit more saturated... very nice! One bug though which was incredibly confusing is that you can't adjust the color of the layer until after you've clicked on one the color blocks above the pallet i.e. if you click on the layer color picker icon and adjust the sliders nothing happens. They only work after you've first clicked on one of the colors at the top.
8) Might be nice to give an indication of the boundary for the selected box.
9) Layers - found this a little bit confusing for some reason, I could see lots of things in there but couldn't find them anywhere on the actual design. Clicking on something in here should make it visible on screen i.e. scroll to it, select it. BTW they dropped off the bottom of the page a bit so I couldn't see them all clearly.
10) Units - seemed a bit strange defining borders and padding in ems, couldn't find any way to use pixels.
This looks a great effort and I hope you continue to develop it as there's definitely a market for something like this. I think you need to do a ton of user experience testing to get it more usable. Get some designers to try and build something in it while you're watching. Keep doing this until they find it easy and you're going to have a very popular app on your hands.
Hope the feedback is useful(didn't have time to reduce if I'm afraid), feel free to email if you want to talk about it.
I'm definitely developing it further - thanks for the kind words.
I'll be in touch, but a few things I wanted to touch on: The panel button bug is fixed - once I can deploy safely again (Heroku/RubyGems issue) I'll have that fixed.
I'll consider adding a start into the design editor, but the content screen is first for a reason, and it gives you something to start with.
Pixels are (mostly) not available, again, by design. You should be using EMs and Percents, they are more natural to web design. Borders and shadows are the exceptions - both are more useful as pixels.
Glad you like the output - I've worked a bunch to make that as clean as possible.
Everything else is good, and I'll definitely incorporate this into future updates.
its unfortunate that not many programmers are going to read this (i wasn't going to until faced with the dire necessity to procrastinate) because there's some impressive information about quora's backend^Wmiddleware (what would you call it?) in there. they seem to have very good support for integrated, componentalized dynamic update. i wonder if they will ever open source it?
I thought it was an article about design at first, but the real meat is this LiveNode/WebNode modular system. And then when I saw that it's in Python! I've been trying to replicate something like this in Django, but from the server side. I'm super curious about their technology and whether there's a way for me to integrate something like it into what I'm working on.
This again? This debate surfaces every other month and the arguments are always the same. Basically, it all comes down to the job and the person. In big organizations, sometimes designers can get away with only being Photoshop people. In smaller firms, designers have to be more flexible and should be expected to implement their own designs.
Also, when did HTML and CSS become "code?" These are markup and style languages and are the very basic building block of the web. If you design for the web, you should be able to implement those designs in HTML and CSS. I wouldn't, however, expect that same designer to build out the Rails backend.
We simply don't work with designers who can't go from wireframe to PSD to fully-functional HTML and CSS on their own. There are simply too many designers who understand that HTML and CSS are not "coding," they're designing, and they're part of the craft.
For every ten good designers who are PSD-only, there are at least as many who will send you HTML and CSS and probably 2-3 who are capable of building a template in your framework/CMS of choice. My last subcontractor was a very good designer based out of Iowa who specialized in CodeIgniter templates. I've worked with similar folks who specialized in WordPress themes or in .NET Master Page/template setups.
This. I just started contracting with a company full of Rails developers. They expect me to be able to implement my designs within the Rails ecosystem and also expect that I generally understand how to function within a Rails development group.
I also teach this to my web design students. We start every semester learning basics in the command line and how to use Git/Github to collaborate with other people in a dev team. They are required to turn in all their assignments via Git pushes. You will never be designing in a vacuum and the ability to seamlessly integrate into whatever dev environment is already established at a company is a huge selling point for new grads looking for a job.
Exactly this. I have worked with PSD only designers in the past who didn't do "HTML programming" and would send blobs of binary files.
I realised that I was wasting about 50% of my time figuring out CSS, fighting with the box model and browser quirks. The end result was me just producing crap CSS that I don't think even implemented what the designer had designed properly.
Getting a full CSS/HTML template & all elements actually means I can get on with the shit that I'm supposed to be getting on with.
On the first paragraph I generally agree with you, but I'd like to point out that in some cases, also in small teams, being a designer unencumbered by the limitations of the technology can be important. As part of the team, it can cause some healthy conflict in trying to make things work despite initial technological barriers. Many great things came out of a disregard of 'what seems possible at first sight', and in some cases this is a good thing. You're not saying the opposite of what i just said, but I just wanted to point this out.
As for the second paragraph: in my experience the type/manner of work involved with HTML and CSS might be closer to programming than to design. I cannot back this up with research, but it's what I've noticed working with designers. I suspect it has something to do with the level of abstraction involved.
For example, I dislike the front-end CSS and HTML part of my work, because so much seems to be based on memorization of CSS tricks and writing dirty HTML that confuses semantic structure from layout. But I can wrap my head around it anyways, and it's more annoying than difficult. But I've worked with many designers who equally dislike CSS and HTML, but lack the fundamental ability/experience to figure it out properly, much as they tried.
Next time so called designer gives you HTML and CSS crap, ask them to give programmable and composable UI components OR get the hell out of this business.
How come it is always "Designers Will Code" and never "Developers Will Design"?
Is there some sort of assumption that it is easier to teach a designer to write code than have a developer learn to design?
In my experience the best designers are not the ones who write code but understand how their designs actually transition to the implementation. They structure their mockups and comps so that all the pieces are divided up in their mind in the exact same way a developer would. At that point it becomes the inevitable monkey work of cutting assets and implementing them but because the designer and developer are on the same page there is very little friction.
The designer doesn't know about the code written and the developer doesn't understand how the designer chose those colours, text sizes, gradients, spacing, etc but there is a simple common language that allows them to bridge what they don't understand.
Tools like CSShat (http://www.csshat.com) which turn Photoshop layers into CSS is a step forward, in the future it will hopefully be able to do layouts and more.
Reading the comments I have to disagree with the statements that designers have to code.
I'm a designer and I make it my priority to understand the technology I work with, it's important to know what the creativity possibilities of new OS updates, APIs and languages etc, as well as the limitations.
I know what CSS and HTML5 can do, I can design in a way that makes the most out of the languages, creating the best possible experience. I read through a API doc and know what different actions can be performed and how to turn data points into great user flows.
But I can't code.
Well, I can code really badly, I can hack together things by cutting and pasting from tutorials or whatever, it's fine for things like http://www.dandandan.net but not for a client. My primary focus is to get better and better at design.
Knowing about code is a huge advantage, I can help development by suggesting frameworks or by locating answers on Stack Overflow that help a problem the dev might have. Or presenting examples of interactions on other sites or maybe a new open-source JS thing I've seen on HN that cuts dev time down.
If I was to hire a designer, I would rather hire a great developer and a great designer separately.
"The era of being a Photoshop designer only...is coming to an end. "
If you didn't notice there's a UX/UI boom right now, if you managed to catch the TV and Radio interviews by the Blackberry Managing Director on BBC today, he actually said 'user experience' several times.
UX/UI is now a competitive advantage and being heavily invested in, I don't see that changing
43 comments
[ 3.3 ms ] story [ 129 ms ] threadFor most designers who cross over it's a gradual process using HTML, CSS, and usually Flash / Actionscript -- at least it used to be that way until programmers & bureaucrats mucked up Flash =P
I would love to say that is true, but I've met many designers that don't really want that crossing.
Maybe it's a cultural thing, or we're still way behind here (which may very well be the case) but there are still many who think you should separate the design/implementation process. I don't agree with that, but IMHO these concept that people can't be good at both sides is an excuse. And an old one.
This works both ways too. I've met many developers who seem absolutely incapable of producing good designs. Even if I can convince them that design is important, and teach them basic design principles, their lack of innate caring about this is a big stumbling block.
Technically, one could argue that anything that has rules applied to it is learnable, but practically that's just not true. Some people just have no sense of rhythm or tone, for example, and regardless of how much music theory you teach them, they can't produce good music.
Now, on a more psychological note. I've found that most really good designers I meet are a certain type of person, far removed from the really good programmers I meet. I can't recall the last time I met this rare person who is really good at both, although I'm sure they exist.
Using myself as an example: I'm for the most part a geek who started programming early in life, but intentionally switched to study psychology/communications and engage in more social/presentational activities, and finally move back to 'lite-programming' as a web developer. I am acutely aware of the fact that for great design I need help, and for great programming I need help too. Despite the fact that I'm an intelligent, talented individual, I simply cannot commit to one without creating a deficiency in the other. Hell, I might not even be capable enough for it. I sometimes feel I'm too messy, gung-ho, and fidgety for serious programming, but too rule-based and logical-minded for the type of creativity that leads to great designs.
I'm content with that, but I suspect most people either fit in my camp, in the camp of great designers, or the camp of great programmers. It's simply unrealistic to use those few who excel at both as a yardstick of any kind.
(apologies for this rant, it's perhaps more appropriate in the thread as a whole than as a specific reply to you...)
IMHO achieving excellence in both is unrealistic and VERY hard. Doable but improbable. But I really do think you can be good at both. Not perfect, not exceptional, but good. And for 99% of the world, good is more than enough.
The excuse part, is because I have met an enormous amount of people that use that as an excuse to not learn new things (IMHO, to be lazy). Yes, it's hard to understand programming, but many people simply accept the "if I learn this my design will suffer" (and vice-versa). With that in mind, they don't even have to try.
I also agree completely about the theory/reality dilemma, people are very different and can never be treated as the same. My only problem is with people that excuse themselves from learning something new on false premises.
The irony is js is harder as it requires a lot more effort in coding/debugging/building a stack.
I am a coder, I can photoshop too, if needed. But it would probably kill my rhythm to find a base psd file, change something and then produce intermediate assets, then deploy then see the difference. That's why html/css is a step forward... Likewise, if you are designing and somehow want to change the behaviors, it should be as easy as that. That's the beauty of scrappy development environments...
Another complaint is that, if they have to implement something that's hard, that churn of work to do the actual thing ends up taking a toll in the design process.
Of course these problems can be circumvented but I think we're not the only place having this kind of problems.
I agree with the author, one day we'll all be teaching people to be at the middle of design and implementation.
My experience is actually the opposite. If the designer I work with is thinking about HTML (for example) he limits himself where implementation might be difficult. (I do the same in my own design.) So by separating the roles completely, there's much more freedom – the designer designs without thinking about implementation, which forces me to upskill, which means he can push design further next time, in a virtuous circle.
Wait, what? You can't just drop that in there. More info! Do you think they're creating a custom html attribute in debug or something? Then some sort of browser extension?
Is this wonderful magic something I've totally missed the boat on and now look a fool?
Coding is less critical for visual designers though. It's better if the visual designer can render his design in html/css (or whatever), but you probably don't want to turn down an otherwise brilliant visual designer if they can't.
The "should designers code" question seems to come up again and again because interaction and visual design gets rolled into one discipline (and often one person).
http://www.axure.com/
I've seen this happen and had it happen to me. So now I just play dumb when it comes to design.
If they design for Mobile (iOS), they aren't real mobile designers if they can't dish out their design with Cocoa.
From my FizzBuzz tests while recruiting in Germany I think 30% of Java developers with years of experience in their CV can't program. So there are some designers that can program, and there are some developers that can't. Job titles have nothing to do with it.
Imagine a design tool that understands what a responsive grid is. This would be a great go between for a design tool and a web page. It would present a strong visual representation and it would allow the designer to resize the page and see how the design responds, without having to think about numbers...
There's smaller things as well, you can't use ems to specify text size for instance. What about a viewport mode where parts of the page that aren't in view are greyed out(with some presets for common viewport sizes).
Web pages do need a dynamic layout but are still entirely visual, I don't see any reason why a designer should have to learn how to code them up.
Dynamic layout - as far as I can tell balsamiq uses an entirely static layout, unless I'm missing something.
Viewport preview - again can't see how it helps with this
Text dimensions - have to be specified in pixels, not ems.
and these are just examples of some features that are missing...
This is why Photoshop and Illustrator are still the best tools for web design: they enable relatively quick wireframing, but also give you the possibility of increasing the level of polish within the same document.
If a new alternative is to appear, it will need to provide at least support for realistic grids, typography, and basic CSS styles, not just empty boxes and Comic Sans.
Imagine a design tool that lets you organize your content first, assign semantic HTML tags to your layers, and lets you easily draw out your layers with visual design tools built to honor your Photoshop muscle memory as much as possible, but also built for speed.
Imagine all your design work being cleanly rendered in HTML and CSS, while giving you the creative freedom to play with layout and typography, color and form.
Not just flexible, but responsive as well - you can preview different display widths directly in the design editor and create custom breakpoints for adjusting your design for smaller screens.
The tool you're looking for is already here - http://www.edit-room.com
1) Maybe start with the design page, I want a blank canvas I can add things to straight away. I realise that you've gone with organising the content first but I can't imagine a designer starting to build a page this way. Following on from this it would be great to be able new content into the design view.
2) The black button to show the tools only appears if you click on the left end of the button, this confused me for a while(I kept clicking all over it until it appeared).
3) The grid - I think you need to lean on this far more. Have it on display from that start and then use the grid to actually generate the markup (rather than it just being a visual guide). I found that things jumped around a lot when I was dragging/dropping(actually on the drop). This would work well at least for horizontal positioning/alignment.
4) Snapping - I really missed this from illustrator, when you're dragging/resizing it should snap to align with other objects on the page.
5) When you resize the page the tool area remain the same size, currently the left edge is left in the same place and tool area resizes.
6) The generated markup looks pretty decent, after trying Muse and seeing the abomination that generated this was very good to see.
7) Colour picker - took a couple of seconds to grok it but actually I really liked it. Being able to adjust in several different ways feels very natural i.e. maybe a bit darker, I want a red, maybe a bit more saturated... very nice! One bug though which was incredibly confusing is that you can't adjust the color of the layer until after you've clicked on one the color blocks above the pallet i.e. if you click on the layer color picker icon and adjust the sliders nothing happens. They only work after you've first clicked on one of the colors at the top.
8) Might be nice to give an indication of the boundary for the selected box.
9) Layers - found this a little bit confusing for some reason, I could see lots of things in there but couldn't find them anywhere on the actual design. Clicking on something in here should make it visible on screen i.e. scroll to it, select it. BTW they dropped off the bottom of the page a bit so I couldn't see them all clearly.
10) Units - seemed a bit strange defining borders and padding in ems, couldn't find any way to use pixels.
This looks a great effort and I hope you continue to develop it as there's definitely a market for something like this. I think you need to do a ton of user experience testing to get it more usable. Get some designers to try and build something in it while you're watching. Keep doing this until they find it easy and you're going to have a very popular app on your hands.
Hope the feedback is useful(didn't have time to reduce if I'm afraid), feel free to email if you want to talk about it.
I'm definitely developing it further - thanks for the kind words.
I'll be in touch, but a few things I wanted to touch on: The panel button bug is fixed - once I can deploy safely again (Heroku/RubyGems issue) I'll have that fixed.
I'll consider adding a start into the design editor, but the content screen is first for a reason, and it gives you something to start with.
Pixels are (mostly) not available, again, by design. You should be using EMs and Percents, they are more natural to web design. Borders and shadows are the exceptions - both are more useful as pixels.
Glad you like the output - I've worked a bunch to make that as clean as possible.
Everything else is good, and I'll definitely incorporate this into future updates.
I thought it was an article about design at first, but the real meat is this LiveNode/WebNode modular system. And then when I saw that it's in Python! I've been trying to replicate something like this in Django, but from the server side. I'm super curious about their technology and whether there's a way for me to integrate something like it into what I'm working on.
Also, when did HTML and CSS become "code?" These are markup and style languages and are the very basic building block of the web. If you design for the web, you should be able to implement those designs in HTML and CSS. I wouldn't, however, expect that same designer to build out the Rails backend.
For every ten good designers who are PSD-only, there are at least as many who will send you HTML and CSS and probably 2-3 who are capable of building a template in your framework/CMS of choice. My last subcontractor was a very good designer based out of Iowa who specialized in CodeIgniter templates. I've worked with similar folks who specialized in WordPress themes or in .NET Master Page/template setups.
I also teach this to my web design students. We start every semester learning basics in the command line and how to use Git/Github to collaborate with other people in a dev team. They are required to turn in all their assignments via Git pushes. You will never be designing in a vacuum and the ability to seamlessly integrate into whatever dev environment is already established at a company is a huge selling point for new grads looking for a job.
I realised that I was wasting about 50% of my time figuring out CSS, fighting with the box model and browser quirks. The end result was me just producing crap CSS that I don't think even implemented what the designer had designed properly.
Getting a full CSS/HTML template & all elements actually means I can get on with the shit that I'm supposed to be getting on with.
As for the second paragraph: in my experience the type/manner of work involved with HTML and CSS might be closer to programming than to design. I cannot back this up with research, but it's what I've noticed working with designers. I suspect it has something to do with the level of abstraction involved.
For example, I dislike the front-end CSS and HTML part of my work, because so much seems to be based on memorization of CSS tricks and writing dirty HTML that confuses semantic structure from layout. But I can wrap my head around it anyways, and it's more annoying than difficult. But I've worked with many designers who equally dislike CSS and HTML, but lack the fundamental ability/experience to figure it out properly, much as they tried.
Next time so called designer gives you HTML and CSS crap, ask them to give programmable and composable UI components OR get the hell out of this business.
Is there some sort of assumption that it is easier to teach a designer to write code than have a developer learn to design?
In my experience the best designers are not the ones who write code but understand how their designs actually transition to the implementation. They structure their mockups and comps so that all the pieces are divided up in their mind in the exact same way a developer would. At that point it becomes the inevitable monkey work of cutting assets and implementing them but because the designer and developer are on the same page there is very little friction.
The designer doesn't know about the code written and the developer doesn't understand how the designer chose those colours, text sizes, gradients, spacing, etc but there is a simple common language that allows them to bridge what they don't understand.
Reading the comments I have to disagree with the statements that designers have to code.
I'm a designer and I make it my priority to understand the technology I work with, it's important to know what the creativity possibilities of new OS updates, APIs and languages etc, as well as the limitations.
I know what CSS and HTML5 can do, I can design in a way that makes the most out of the languages, creating the best possible experience. I read through a API doc and know what different actions can be performed and how to turn data points into great user flows.
But I can't code.
Well, I can code really badly, I can hack together things by cutting and pasting from tutorials or whatever, it's fine for things like http://www.dandandan.net but not for a client. My primary focus is to get better and better at design.
Knowing about code is a huge advantage, I can help development by suggesting frameworks or by locating answers on Stack Overflow that help a problem the dev might have. Or presenting examples of interactions on other sites or maybe a new open-source JS thing I've seen on HN that cuts dev time down.
If I was to hire a designer, I would rather hire a great developer and a great designer separately.
"The era of being a Photoshop designer only...is coming to an end. "
If you didn't notice there's a UX/UI boom right now, if you managed to catch the TV and Radio interviews by the Blackberry Managing Director on BBC today, he actually said 'user experience' several times.
UX/UI is now a competitive advantage and being heavily invested in, I don't see that changing