Designers Will Code
medium.com
medium.com
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.
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.
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?
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...
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.
If they design for Mobile (iOS), they aren't real mobile designers if they can't dish out their design with Cocoa.
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.
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.
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
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.
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).
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.
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.
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.
I've seen this happen and had it happen to me. So now I just play dumb when it comes to design.