Our designers never deliver anything but Photoshop comps or at best slices, and I wouldn't want it any other way. It's all about delivering a quality product and the graphic designers should focus on the design, and you as a programmer on the implementation.
Simen, surely photoshop comps is the right thing to deliver is all you have is "graphic designers". Thankfully, there are many other forms of designers. The ones running 37signals are first and foremost application designers — focusing on visual priority, interaction flow, etc. The closer to real they are, the closer to the elements they can operate, the better designs they do.
The constraints of HTML/CSS and web interfaces should be available to the designers all the time. It's the feedback that causes good designs. Constraints don't inhibit creativity, they foster it.
When you're just photoshop comping, you're merely painting pretty pictures. Those pretty pictures may or may not translate well into designs. My experience has been that they are way more "pretty" than useful. They also tend to make you focus way to much on looks and way to little on interaction. You can't interact with a photoshop comp, but you can easily interact and get a feel for a flow of five HTML screens linked together.
Additionally, it's a big waste. Doing the whole thing in photoshop, then redoing everything in HTML is wasteful. It certainly depends on your organization, but getting real faster, going HTML sooner, is a way to do big things with small teams.
I believe photoshop comp'ers are great for making the next Nike commercial site with spinning wheels, flashing shoes, and pretty photos zapping back and forth. They're terribly inefficient and inadequate for designing applications, though.
You (and others) have mentioned templating using HTML, by which, I take you to mean to just make a (mostly) non-functional app with the forms laid out and textboxes in the right place.
For those of us fairly new to Rails (actually, who isn't?), would it be possible to lay out an example - maybe a sort of "Building Tada" as a teaser for "Building Basecamp"?
Also, I'm looking forward to the Ruby on Rails book.
Hmm, I'm not sure I entirely agree with you there.
I've personally found comping designs in a graphics app to be really useful. Even when developing a web app. In a graphics app I can experiment with the layout more freely than I can with html/css.
Your point about the contraints of html/css being availible to the designers is a very good one. I guess my situation is a little different to someone who is purely a graphic designer. Since I'm responsible for both the visual design and the layout with html/css I have some insight into what is possible and what is difficult. I'm able to keep these things in mind when comping a design, and thereby avoid proposing something difficult or impossible.
Challenge by Zsolt on February 16, 10:45
Indeed, as David implied, the usability aspect of designing applications is often overlooked and/or takes a back seat compared to visual design.
Also, let's not fall into the other extreme focusing only on usability, for example see the website of usability guru Jakob Nielsen http://www.useit.com/ which is certainly usable but not much to look at visually...
It takes many skills to build a good looking, usable application: usability, visual design, programming, XHTML/CSS...
And it is not enough to have a great looking, easy to use web application.. It should also be USEFUL... That's the most important aspect.
David, thankfully there are many types of sites. You have your application sites, and you have your graphical sites, I'm in the graphical site business.
The "constaints" of HTML/CSS should not always be available to the designer. They have a vision, I make it work, because that's my job.
When you are Photoshop comping you aren't merely "painting pretty pictures", you are doing graphic design for the internet, a format both restricted and with more possibilities than print..
Once again, it's always about what type of product you are designing. I feel that for a print designer working with HTML is utter waste of time. And the challenge of getting something iamginary and possibly impossible in HTML for a site that focuses mainly on the visual presentation and not application-flow, Photoshop comps are the only way to go.
On your topic of wasteful, it's a common trend these days that every site looks pretty much the same, everyone GPL'ing templates and stylesheets left and right. So if you are trying to create something unique, sitting down in a text-editor may not be the best place to start.
Your view on what a site is and what a "commercial site with spinning wheels, flashing shoes, and pretty photos zapping back and forth" seems a tad narrow-minded, we wouldn't want all the sites in the world to look like the next mans blog would we? There's a reason Nike makes that site, it's because it's different, and because it helps them sell more shoes, even if it doesn't have good "application designe", "focused visual priority" or "interaction flow" (more .com words now and I'm out of breath ;))
I always start with Photoshop, but I've found that when designing a web app, I leave Photoshop much earlier than when I'm designing, say, a normal website (any kind of business website, with varying degrees of "flash" and "graphics").
The problem I find with designing webapps with Photoshop is that web user interfaces are comprised of html- and form controls and things like that, controls which have varying widths and placements. Managing controls like that in Photoshop, while possible, is much more work than just doing html/css-sketches.
If you want to move around things, perhaps make a column in a list of items wider, or narrower -- doing that in actual html/css is much quicker than in Photoshop.
Although, I think some people simply don't consider that part of their website as something that needs to be designed at all, and so just "does it" when the time comes to do that form, that list or whatever. However, that tends to lead to bad user interaction design.
More and more, I've begun to see things the 37Signals way -- which is to design from the user controls and the stuff the user interacts with, not design around those elements.
The problem with photoshop-only people (in my experience) is the lack of understanding of the process their grand layout must go through before it in live html and css. As a designer, I see great advantage in being able to, while mocking the design up, being able to write the css in my mind as I design.
I do know that getting photoshop comps from photoshop-only people, then turning them into a site, can be a real pain - partly because they lack the understanding of how html and css works.
I don't understand some of the points being presented here, are we talking about web designers (pure frontend people) or graphic designers (print, motion etc.)? I don't see why graphic designers need to learn markup languages when they can hand a photoshop mock-up over to a programmer.
It's like the discussion is going towards "designers are blind and never surf the internet so they need to learn HTML and CSS because otherwise they'd be giving us triangular site sketches".
That of course isn't the case, most people who work with web for a living know what's possible and what's not, and if they don't , you as a programmer should be able to tell them that one or two things might not be optimal for the user or you so they can change that. TeamWork™, anyone?
The case that I'm making is that using graphical designers to do application design is inefficient and leads to worse designs than using real application designers would.
But you're right that I didn't frame when this applies. For all the applications that 37signals do, this is true. For intranets, e-commerce, productivity applications, collaboration, etc, etc, this holds true.
For branding sites, like promoting a movie, a new car, a piece of gum, or similar, then you probably would do better with a graphical designer working in flash or with big images.
So for sites where you need to accomplish goals, don't pick a graphical designer. For promotion sites or web commercials and the like, they're a great fit.
Can't you have both?
At work, we have a UI person make wireframes (on paper, in Visio, WordArt, or whatever they are most comfortable with). Then a designer dresses it up and makes photoshop mockups (which the UI person reviews). Then once the client's happy, a graphics cutter cuts up the images and an HTML person makes the HTML. Then an application developer gets involved on the pages that do dynamic things.
This seems to work well. It's also not necessarily the case that they are all different people; someone could perform multiple roles, although in most cases (other than designer + graphics cutter) this doesn't seem to happen. Those first two steps are perhaps something like an architect and then interior designer working together.
For this to work, the person who fulfills each role has to have a pretty good understanding of the roles that surround them. So the appdev needs to talk a lot with the HTML person, and the UI designer has to make pages that are structurally aesthetically pleasing so the designer has something to work with.
"So for sites where you need to accomplish goals, don't pick a graphical designer."
And what exactly is a goal? Is it giving the client a good product or satisfying a "integreated global internet business application strategy" or some other carp like that? Forgive me for being harsh here but it now feels as if this string of comments has slipped from a discussion concerning efficient ways to produce views to a between the lines company ad.
It's all purely situational and doesn't necessarily apply to all graphic designers, there are varying degrees of experience and education. Things like typgraphy, page layout and other essential skills in the print world are often the things typical web designers aren't very good at.
Hu?! I'm relating my experiences working with designers that focused on different things. From those experiences, I'm abstracting a couple of guidelines that I personally and commercially follow.
And this is all about striving for an optimum. It's not that graphic designers, or any one else, can't do application design. Not at all. It's about choosing a team composition that operates more efficiently and produce better results.
So I don't know where you picked up the buzzword tone, but its nothing to do with that. Neither is this about promoting 37signals for client work as we have almost retired from arena. I think you might need to tune the between-the-lines lens -- you're reading stuff that isn't there ;)
At one time I would have agreed wholeheartedly, but now I don't. I think of it this way. If I were working with people to design and build a car, I'd probably want there to be someone in the group who could make drawings and clay models of the car. Of course, those wouldn't tell me anything about what it would be like to drive the car, or sit inside it. But they'd still be extremely useful. I think Photoshop comps are useful in an analogous way.
I'll never be any good at making comps, though. When I try, I just get frustrated, because in my head, I'm already driving the car. ;) As a web designer whose job it is to take comps and make them happen in CSS and HTML, I'm glad that other people are good at making the comps so that I can focus on what I like to do.
'The "constaints" of HTML/CSS should not always be available to the designer. They have a vision, I make it work, because that's my job.'
This is an essential point. Doing mockups or outlines or sketches in HTML distracts the designer/developer with the technical details of how to accomplish some visual task using arguably crude tools (HTML+CSS+JavaScript). I suspect this is why so many sites have the same boxy, grid-like quality to them; HTML makes striaght lines + boxes easier than curves.
