How can a developer learn about web design? [closed] - language-agnostic

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Most of the time I worked as an application developer at backend side. I worked on enterprise web projects but never touched on user interface, design issues.
Good looking web sites and user interfaces always impress me.
And nowadays I am trying to develop public web site I know CSS, HTML but stuck with web design / user interface issues. I don't want to use a template or steal someone's web design.
How can a developer / programmer learn to design good web sites / user interfaces, What tools should I use and learn? or is desinging good web user interfaces a god's gift?

Looks like you hit on a hot topic. As a web/graphic designer myself, I think the best way to improve your ability in that regard is to look at a lot of good designs; meaning, actively seek them out.
As pixeline says, there's not a lot of objective knowledge to be learned (though there is some). It's more about improving your aesthetic eye. If you look at high quality designs all the time, then your tastes will become more refined and your web designs will naturally conform to your acclimated aesthetics.
For instance, I work at an indie metal label, so from time to time I'm called upon to work on band sites, album designs, magazine ads, sticker/clothing/merch designs, etc. So I'm always flipping through metal magazines and looking at ads designed by other people, or admiring the merch designs of other bands, or checking out the sites of other labels.
This not only serves as a source of inspiration when I'm stuck, helps me to gauge my own abilities and find areas for improvement, but it also helps me track the ever-changing trends and fashions in my particular sphere of design. As we all know, fashion is fickle, and people's tastes are always changing. A good designer knows how to stay just ahead of the curve all the time. This means that your designs don't deviate too drastically from accepted aesthetics (otherwise your designs will be rejected by audiences), but you also don't want to employ design elements that are overused and played out.
If you can ride the knife's edge and innovate enough to stand out, but not so much that the audience is unable to accept it, then you will have mastered the art of web design. A good designer can identify emerging trends and capitalize on them, while making it their own by adding their own twist to it.
If you're just starting to venture into web/graphic design, don't be afraid to emulate others and steal good ideas. Don't plagiarize, and give credit where credit is due, but just as making copies of famous drawings/paintings is an essential training technique in figure drawing & painting, so too is emulating quality designs an effective tool in learning graphic design.
Sites like Best Web Gallery and Screenalicious are excellent places to immerse oneself in quality designs and layouts. I would highly recommend scanning through these sites in your free time to flood your mind with examples of good aesthetics.
EDIT: I also want to emphasize that talent is not as much of a factor as most people would think. More often, interest is what people confuse as "talent." If you truly have an interest in something, you will be motivated to immerse yourself in it and practice it. This in turn leads to better ability, and if started at a young age builds confidence, which leads to an ability gap, which leads to more confidence and more interest, which in turn leads to more practice...
I consider myself a decent graphic designer (you can check out my portfolio via my profile link) and an alright artist. And people often comment on how talented I am, but they don't realize that I have literally spent thousands of hours honing my craft. While other kids were out playing with their friends, I was in my room drawing. That's the only reason I excelled in drawing. And when I first started building websites, they looked just as hideous as most teenagers' Myspace pages. So don't get discouraged when you see the work of "talented" designers. They all started from humble beginnings as well.

Please read Don't make me think

There is not much to be learned as "objective" content, except for : use a grid !
http://dev.opera.com/articles/view/grid-design-basics-grids-for-web-page-l/
See the human eye recognize as "beauty" things like balance, symmetry, contrast, color tones. Work on these fundamentals, and then... practice, experiments, iterate.

Seth Godin recently posted a page of resoures for people who want to improve their design skills.
The Smashing Magazine website also has a lot of relevant articles.

The best way to learn is to start doing and soliciting feedback. The key is making sure that your site is as simple, intuitive and easy to use, yet providing a very rich content and feature set.
This post makes a very powerful demonstration of what good UI design means. http://stuffthathappens.com/blog/2008/03/05/simplicity/

A List Apart is a great web-based magazine on design and development of web content. It publishes twice a month, usually with two new articles, and is a magazine type format; it's a good complement to some of the books that others here have mentioned.

You can learn principles of good web design, you can know all the tools, but really it's like graphics design, you need some talent. Unless you have it, you'll end up with very correct, but dull design.

these sites offer good content :
http://css-tricks.com/
http://net.tutsplus.com/
http://blog.themeforest.net/

See Why is good UI design so hard for some Developers?
It's got tons of great info about this

I found this site a while back and bookmarked it in hopes that my wife might be interested in web design some day...
66 Links To Learn The Webdesign Basics
http://www.divitodesign.com/2008/08/66-links-to-learn-the-webdesign-basics/
Its broken down into these categories:
General
Programs
HTML
CSS
Design
Site Structure
Tutorial Sites
Colors
Resources
Stock Images
Search Engines
Inspiration
Fonts / Typography
Usability and Accessibility
Blogging

Related

web 2.0 web design [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
my son would like to get into web designing, but i'm a backend guy so i can't help him with any artistic or design matters.
there are alot of tutorials and many ways to do it.
can someone point us in the right direction to develop great looking web 2.0 type sites.
from what i gather i think most people do the graphics in photoshop then they slice it to make it html friendly, am i correct? im looking for the mainstream way of doing it so he can easily find a job and help along the way.
we just need the design aspect of it, when it comes to jquery stuff i can help whim out.
thanks,
glenn.
"can someone point us in the right direction to develop great looking web 2.0 type sites."
Pretty much the same path you took to learn the back-end stuff. Typically years of schooling and/or training and work experience.
For those that want careers being web designers, you typically want a degree in graphic design or human factors of some sorts. Graphic Design will lean a bit more towards art and visual design, while a human factors or library sciences degree will lean a bit more towards the interaction design and information architecture. With some experience, people can become adept at both.
Mix in with that an understanding of front end development, and then you have a pretty well rounded web designer.
But I'm not entirely sure that was what you were asking.
If you were asking about 'workflow', yes, in the past, a graphic designer (not necessarily with any skills or understanding of web design) would make a pretty photoshop file, then some poor front end developer would have to try and slice that up into some HTML.
Fortunately, that's not how it's done much anymore.
These days you want to have a web designer that's as adept at Photoshop as they are at writing a bit of HTML. Barring that, you want a team that has both roles who work collaboratively.
The design of a succesful web site requires a wide variety of roles to help shape the complete user experience. In the past, and still today in less succesful models, this was done like an assembly line:
marketing/graphic designer make cool looking PSD file
front end developer slices and dices and pieces together a bloated front end
back end team wires it all up
And then someone finally gets the copy written and the client realizes they are making a web site and start thinking about interactions finally, and then things fall apart because the waterfall model doesn't accomodate the iterative design process required for web design.
These days, fortunately, things are getting a bit smoother. A decent process will involve these roles and they will work collaboratively each step of the way:
product manager (client rep)
business analyst
information architect
interaction designer/front end dev
graphic designer/marketing
copywriter
and input from the development team, legal, etc.
Now you don't need 20 people to do this, but all aspects need to be accounted for to get that magic 'web 2.0' site up and running.

Learning HTML5 and CSS3 [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
Imagine somebody today, March 1 2011, has never written a webpage and would like to know what they should read to start building web pages today. They don't care about backwards compatibility, but want to build with web standards so that they will be portable amongst as many browsers as possible (Yes I'm saying I do not care if my web pages don't work with IE 4-8, Opera, Netscape, Mozilla, etc, I really don't care, because I've never used them, and that's likely true about those who will use the tools I'm building).
This person has zero biases or bad habits because they've never done it before. They're also hyperactive, so if they have to read 200 pages as to "why to use web standards" or "why web standards are better than "the old way"", they'll get discouraged and distracted and throw the book away, and go swimming. Speaking of which, my hair is wet.
They're looking for references that are engaging and concise. They're not stupid, this person is a real-live engineer who has done a tiny bit of development, a decade or two worth of systems administration, and even built a successful company or two. They just didn't go to college because they really aren't book learners, and are better at applied hands-on learning than at absorbing mounds of useless data in order to get to the two or three things they really need.
Given all of that data about the individual, and I know it's a lot about that individual (this individual is me, of course), what books or resources would you recommend?
(Zeldman's books are out because I already threw them away and then went swimming today.)
Some good resources to start:
Mozilla Developer Network: For HTML, CSS, Javascript, & DOM.
Dive into HTML5: For learning all about HTML5
JSfiddle: For fiddling around without having to build a whole page every time.
HTML Validator: For making sure the HTML you write is valid.
CSS3 Preview: Run-down of some of the new features of CSS3.
Official HTML5 spec: For when you need all the detail straight from the source.
jQuery: Arguably the best framework for making writing javascript for websites easier.
A List Apart: "For people who make websites". Definitely not for starting out, but good to read regularly.
Firebug: If you're using Firefox, this is a must-have.
Developer Tools: built in to Chrome & Safari (essentially firebug for webkit)
Also, do not use W3 Schools. Please see W3 Fools for a long list of reasons why. W3 Schools will often come up at the top of search results, but please resist the temptation to use it.
For someone that has never coded a webpage make sure you dont get sucked into the hype of HTML5 and CSS3 just yet. Although they have great features they all assume quiet a bit of knowledge of previous versions and all of the 'previews' will show you snippets related to enhanced interactivity rather than supported structural elements.
Stick to learning CSS2.1 and HTML4.01/XHTML which will give you a good grounding on which you can apply the new stuff later.
Im sure people will give this answer some negative feedback but if you need a JS snippet at the start of your code to enable the new HTML5 elements in one of the main stream browsers then it should be used for commercial purposes just yet.
I self-taught myself web design and development, and I have a background in engineering. You are comfortable with computers, so you are in good shape. To get started, I took a few online courses from http://www.hwg.org/. The courses are self-paced but moderated, and you get a lot of hands-on experience right away and you get an online community to help you bounce ideas around.
I took the HTML course, almost all the CSS courses and some JavaScript. Once you get some basic experience and learn the fundamentals, you can decide how much of the other stuff you need, for example, PHP/MySQL, or whether you need some design courses to make things pretty.
I would say, you need to put in about 80 hours of practice to master the basics, so give yourself a month of self-learning to get to that point. The reason to get to that point is that you will be fluent enough to ask good questions that will get you to a higher level.
About books, go to your local library and skim through a few books, find one that you like, buy it, skim through it and skip the parts that don't appeal to you.
Finally, if you really want to learn how to build web pages, get a good text editor and hand-code your HTML and CSS. In the long run, hand-coding is more efficient and you save quite a bit of money by not buying expensive tools like Dreamweaver. However, keep in mind that tools like Dreamweaver are often used by professionals and they serve a good purpose in production environments typically found in commercial web design firms. I actually use Dreamweaver in code view where I hand code my pages, but I have a few other editors that I use depending on the project.
Best wishes as you venture forth into a new and exciting field, and remember to have fun!
for html5: Dive into HTML5
for css3: http://www.css3.info/preview/
and if you want to use javascript it would be good to use jquery: http://jquery.com/

does one need any 'programming aptitude' to become a web-designer? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
It's well-known among teachers that some people can program and some can't. They just don't have mindset for that. In a nut-shell, I want to ask if the same is true about web-design.
I have a friend who is a good designer in general and can produce reasonably good-looking sites with WYSIWYG editor like Dreamweaver. But, since we're starting a common project, I'd like someone who can 'get hands dirty': work with html and css code directly. For many reasons, I'm sure you understand.
Now I'm thinking to incite him to learn, but not sure what're the chances of success.
So, do you also need some 'programming abilities' to profess css and html, or it's just a matter of training for regular designer?
I would especially like to hear particular experience from web designers.
PS I intentionally leave out JavaScript, let's keep it simple
The best web designers I have worked with know a small amount of html but don't use it when they are designing the sites. They do their work in PhotoShop (a minority will use GIMP). The reality is that I would rather they concentrate on laying out eye catching websites instead of trying to code it and lay the site out on the fly.
A web designer is absolutely not the same person as a front end web developer. That person has a skillset aimed towards converting the designers work into a set of working html/css templates.
Let me be clear that I am not saying that there is no cross-over between the two skillsets, but rather that very few people will be excellent at both design and development. If you are willing to settle for less than stellar results, at least be sure you go into the project with your eyes open.
Not at all. HTML is not a programming language, it's a markup language.
It shouldn't take you long to figure it out; I did it when I was 12. I personally think you need to be a better, how do I put it... artist to design websites than a programmer.
Of course websites nowadays are a lot more interactive, and for that you'll need some sort of server scripting (PHP, ASP, etc) and Javascript - and these are real programming languages.
A web designer who can't hand code HTML/CSS is not a web designer. The lack of such skills shows more of an aptitude problem(wanting to improve one's self). the graphic designer + front end developer combo doesn't always work well, because chances are the developer doesn't have the eye for the details in the design, such as margin, line-height, text kerning etc etc. Also it's hard to convert the interactive elements as well.
edit: this topic has been debated within the web design community on and off for a while now. You may find some interesting links in the blog post I wrote regarding this issue.
you are much better to know how to code a website HTML / CSS / Javascript before you go saying your amazing with a WYSIWYG editor. Sure you can use software to create a nice looking site but when it comes down to it how do you solve cross browser issues? How do you add dynamic content (even without server side) a WYSIWYG editor is just like designing a website in powerpoint or word but a lot more smarts. Though without the backing knowledge you are not going to go far.
As for learning plain HTML / CSS is fairly simple its an easy markup to get the understanding of. But then with that comes more, learning how to SEO plain HTML for example. There is always more to a site than HTML / CSS for it to be successfull.
This seems like a life question; I suspect it is true about almost anything. I think it can be hard to guage someone's aptitude for programming without seeing them actually try to program for awhile, however. Many people need to struggle with it for awhile before an "AHA!" moment is reached.
Nevertheless, I don't think design skills and abaility to work with CSS and HTML necessarily correlate to an aptitude for programming, per se. Of course, the two are not mutually exclusive,
It is not important for the designer to be able to program/markup/code in HTML or CSS. However, it is important for the designer to be aware of the current constraints imposed by HTML/CSS. With things becoming more dynamic, it is also important for the designer to understand how things are going to interact with each other. For example, you cannot become a real architect, without being aware of the constraints imposed by civil engineering.
But that's it. It is not important for a good designer to even know Dreamweaver or Photoshop or some other software :)
I am a university teacher, and I have also written both computer programs and HTML. Although I teach math, I understand the point about teaching computer programming. Although it might seem like there is no gray area between being able to program and not, I would say that writing in a markup language is one. You shouldn't divide the world into "cans" and "can'ts" with a question like this.
If he's a generally bright guy, yes you should encourage him to learn HTML and CSS. I wouldn't propagandize it as the thing that real men do or the greatest thing since sliced bread. Rather my argument would be to have a more complete perspective of what, after all, he's already been doing. Just as a racecar driver shouldn't necessarily need to pick up a wrench, but knowing what to do with one is useful for a deeper understanding. If you offer your friend a positive sell, the worst that can happen is that he'll say no and not take your advice. And who knows, he might even like it.
A lot of people either can't program or just wouldn't enjoy it, but don't mind writing in markup all that much. Most research mathematicians these days write their papers directly in a markup language, TeX/LaTeX, that in some ways looks a lot like HTML. Some mathematicians also like to write computer programs, but most of them don't. If they did like it, there is a good chance that they would have ended up in Silicon Valley. In fact in my profession, the whole question of can or can't write markup, or can or can't write programs, is stale. We're long used to a continuous range of abilities.
In my opinion, you can't have enough knowledge about this sort of stuff when doing any type of computer design or software implementation.
The more you know about the underlying technology, the better you will be at working with the high-level frameworks and constraints you live in.
Even if you work only in Photoshop in order to design a website, having the knowledge about what works and what will be more difficult in HTML/CSS/Whatever will give you an edge when designing that website over someone who doesn't know those details.
Of course, with knowledge comes constraints, which might be bad in and of themselves. Some of the best new technologies out there was built by people who didn't know that almost everyone else thought that what they tried to do was impossible.
But I still hold that more knowledge = Good Thing™
Web site creation especially a commercial website involves a LOT of different skill sets.
Back-end requires:
System Administration, Database Administration,
Web Applications development (anytime a website becomes interactive) requires server side programming skills and knowing various tools like (PHP, Java, ASP, Perl, C, C#, pick-flavour-of-the-month-server-side-language) and client side programming requires knowledge of browser behaviours mark-up languages and browser-side layout systems (HTML, javascript, CSS...)
Web Design requires artistic visual skills and related tools (Graphics programs)
Web Content requires language skills (Knowing how to proof read, translate, etc.).
Site Optimization requires knowledge of how to make sites appeal to various readers and audiences (both human and robotic)
A professional website involves several folks working in-tandem to bring all of the above together in various quantities.
If you are going to pursue something as a career, you need to know a bit about all aspects of that space and then follow in on what really excites you. So if someone is good at creating visually appealing content they should simply plan the content, and collaborate with someone to "program" their vision into the site.
Learning tools, and knowing about various components, is good as it tells you the boundaries and the playing field scope, but you don't need to know all of it to achieve professional competence in one specialization.

What factors exist to choose to develop a website or to use a CMS? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
We are in the process of starting a new company website and the question was brought to use or not a Content Management Solution. What will be the factors to consider to be able to debate between this two options.
Both of them have pros/cons, but I am sure that there has to be a few people out there that will have an external point of view to this situation. i will appreciate your opinion.
Thanks.
First lets consider the options:
No CMS - No Tools: you have a very good developer with a strong HTML background, some server side expertise and plenty of time on his/her hands.
No CMS but a light weight tool: You have a person or two who are comfortable with the basics of HTML, you site is mostly static and it is already built, but you need to update - you can consider any number of tools from (yes it is true) DreamWeaver, Aptana, Visual Studio WebExpres)
You have a small to medium web team and you have a medium for large site that is mostly content. I have found this to be the bulk of all projects that I have every seen. May times thes types of engagements end up with a large enterprise system becasue they incorrectly understood the two or three of the main factors that should drive an Enterprise CMS (read costs more that $250 and way more than free). Open source blogging engines like WordPress are very powerful and extensible. Add in a free editorial tool like LiveWriter and you have a lot if distributed editorial power, cheap, and it takes care of lots of things like Standards and SEO because it is just build solidliy in that respect. Plus there are a lot of people who can help you out. And it is very extensible.
Enterprise CMS:
Three factors should guide your decisions regarding CMS:
Large distributed editorial team that requires rigorous (usually complex) editorial workflows.
The site design and operation has been deemed secondary to some other functioanlity provided byt the CMS (simple SarBox Compliance, easy support for localizing the site to many languages)
In house experience with the product that has been positive and has proven ROI - but be clear, having purchased licenses is no reason to deploy. I have seen far too many cases where a large scale CMS was purchased (licensed) only to find it would not suit the true needs of the project. In some cases the clients were wise and moved on. In others they stuck to their purchase and to this day live in a world of hurt.
Start simple and grow - The average website had a half-life of 3 years. Make a series of small mistakes that you can easily correct through fast itteration. Only go for the big stuff when you are sure.
Instant smell that you are buying more than you need - you can't find out the price of the product until a sales person visits you and you can't get demo bits of the system untl you attend their traning session. By the time you get done with that, you could have an awsome site up and be buying everyone at your firm some nice libations.
For a company website, if you write your own, you're probably going to be reinventing a lot of what a CMS already gives you. The content on your site will most likely change frequently, and the company will probably want non-developers to maintain the content. With your own implementation, you'll have to provide management pages for non-devs to upload new content (text, images, docs, etc.), so it might make sense to just look at existing CMS frameworks.
The downside of a CMS is that you might have to work around styling issues to give the site the exact look-and-feel you're going for. Usually a good HTML/CSS developer can style any page in any way you want, so this isn't too big of a concern.
I think differently. A company website should be unique, personal, I thus I would avoid using a CMS.
Maybe you want a huge enterprise website, in this case a CMS will be better for you, but I'd rather write my simple content management than using a bloated, new hardware dependent website.
Oh, and the users will notice the difference in speed surfing through your hand-written website.
There are 3 points I think are important:
Personalization. CMSs can be
customized, but it's much worse to
style some pre-made html than
styling a pre-styled (since you
thought how you'd like it to be)
html.
Speed.
Web Standards - Accessibility - Unobtrusive JavaScript
Most CMS's are very extensible. You have a framework to start with, and from there you can add whatever you want. Also since practically all CMS's have modules/components/plugins from their community, you can immediately add to the core with even more features for exactly what you need.
Andy's right, too. You can layer the design on top of the the CMS, and it's very easy to extend the front end even more with all the great JS libraries out there - which will be largely CMS & language agnostic, so if you ever migrate from one CMS to another you can still keep a large portion of that code, too.
In short, modern CMS's are mature, easy to set up, highly extensible and customizeable so ... Don't reinvent the wheel unless you have some very strong, specific, compelling reason to do so.

Balancing HTML/CSS Between Designers and Engineers [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a development process question.
Background: I work for a modest sized website where, historically, the designers created mockups/screenshots of what they wanted pages and components to look like, and the engineering team (myself included) turned them into html/css.
This works relatively well from a code cleanliness perspective, and helps significantly when it comes to writing javascript. It has fails, however, in helping to maintain consistency from one page/component to another. On one page, a header font might be 12px and on another 11px, largely because its a complicated site with lots to keep track of (and we've cycled through 4 designers.) We have only a few truly universal styles, and they only get used when the engineers recognizes the style - not when the designer tells them to.
Our most recent designer is a relatively capable HTML/CSS coder. We thought we might have him create mockups in HTML/CSS and hand us off the code for quick integration. Our hope was that the designer would be better at being consistent in his style and that it might save us some development time up front.
What we've discovered is that our designer is not quite as good as CSS as we had hoped and that his code is often slightly bloated and incompatible with what we need to do. Also, his style of coding is fundamentally different from the rest of the engineering team and isn't jiving terribly well with our established coding practices.
Question: How do you do the hand off from design to engineering? I know I've heard of companies that let their design team do all of the template coding, but I'm curious how that works. Does the design team actually incorporate members of the engineering team in those scenarios?
As we're structured right now, there's not a chance in hell we'd let our designer write the final templates and check them into SVN, even if he was a proficient HTML wiz. There's too much in the templates that requires knowledge of our codebase and of potential performance issues.
How do we get this process working? Is it a pipe dream?
Specifically - personally - since I come from a web-dev, small-shop background I do the CSS work and slicing the PSD (typically) myself. But then I like to think I'm well rounded like that :)
Generally, the best experience I've had of this was a largish company with very defined groups of developers including the design team who produced the gfx, the apps team who did the vast bulk of server-side coding and app architecture, and the UE (user experience) team who sewed the two together, producing XSLT/JSP/HTML markup in general, and the CSS and JS for the client-side.
There was a very structured process of:
userstory ->
"wireframe" (documents) ->
design (PSD) ->
"flat" markup (DHTML only) ->
integrated markup (with web-app)
Where "wireframe" would be close to a spec for UE, produced with UML or maybe visio. I have heard the term applied to step 4 which I think fits better, but this is what it was referred to as there.
Whilst this works well for the question at hand, I found it had other problems built in. It was very hard to work across teams, and because of the timescales the design team rarely involved UE in decision making (which put UE in some awkward positions), the apps team and design could be working at cross-purposes, and there wasn't a lot of scope to learn in these boxed in teams.
My suspicion (and I think ideal scenario) is that the developers on a project would each be capable of working with, say, 80% of the technology involved (be it CSS, SQL, whatever) to spread the decision control and risk, but each domain would have one (more?) "czar" who could act as authority and oversight within the domain. Actually producing those designs is to my mind a strange and magical skill in it's own right so I see no real overlap with developers there, but I think a pool of artists and project teams of cross-skilled programmers would be very powerful.
Apols for the long-windedness. I could go on at considerable length on this, I've spent a lot of time thinking about it.
btw, it seems like you could do with some serious web-devs there, (no offence). Having problems to "maintain consistency from one page/component to another" screams failure to grok CSS
In my experience, unless you limit your design severely, you need real coding skills to build a web page with interaction. Let me elaborate some. If you have built your pages very modular (think of GUI toolkit widgets) you can give your designer a handful of them, he can build the basic structure like playing toy blocks with a nice finishing paint.
Often, modularization alone is not enough for desired interactivity. So, some blocks needs their interactions to be designed carefully as well (like animation, fluid layout to accommodate indeterminate content, customized behaviour via extra javascript, caching to eliminate redundant requests and speeding up things) or ability to accommodate minor presentation variations, which brings us to the realm of programming, where you calculate dimensions, enable/disable parts, keep track of time, preload stuff, invalidate preloaded stuff and so on.
Enter HTML/CSS/JS. They are more of a product of evolution than intelligent design. You cannot always declare your intent and be done with it. You need attributes declared in your html, stupid hacks in CSS combined with extra markup, ridiculous amounts of js to smooth rough edges, duplicate rendering code on the server side. These tool were never meant to build applications.
I don't think one can achieve a complete separation of design and application development in these tools at hand. The effort required is too high to justify the marginal returns.
If you end up heavily modifying designer's code (which is othen the case if he is not one of the developers also), there is no point in making him suffer trying to express his intent using the wrong tools, nor developers breaking the design while modifying it and consequently fixing it. I don't even mention user experience.
In my opinion, no small internet businesses who want to ship a product in a reasonable time should spend their scarce resources to go against the grain. Let people do what they do best in collaboration if necessary. If you can't divide design process at an arbitrary satisfying point, you may as well not bother to separate at all. Pipelining works well for machines whose goal is determined to the last detail and not changing. I can't say the same for humans building and designing things be it software or hardware.
Where I work it's basically the same. Designers create mock-ups and specifications of the UI design, right down to the pixel, and the developer creates HTML/CSS/code out of that.
The reason I say code, is that we use UI frameworks (namely, GWT), and as much as we would want to, code and CSS styles are still very coupled. I do not believe there exists one UI framework in which code can be completely decoupled from the UI design.
So I guess for now it's still entirely the developers job. Though I would like to hear about organization which are able to hand off some of the work to designers.
The problem with handoffs is that the idea and implementation of one group is not going to match the abilities and implementation of the next group. Just by their nature handoffs are going to be wrought with problems. So what is an alternative to the ubiquitous handoff scenario? I think that integrating the user experience (UX) into an agile and iterative development process makes sure that what is really important occurs:
The customer's needs are researched then validated.
Early and continuous collaborating between usability experts, designers and programmers.
The actual process works by having everyone collaborate with the customer up-front on their needs. Then the design is researched and prototyped in the iteration before coding begins. Thus when coding is occurring, the next set of designs are being worked on. Programmers should be looking forward at what designers are doing and the designers look back to be sure programmers are on target. Once a design is coded, it goes to the customer for acceptance, by that time the programmers are working on the next set of interfaces.
Jeff Patton did a podcast on Agile UX recently that goes into some of the implementation concepts and common problems.
There is a whole group on Yahoo dedicated to agile usability (which mostly involves interface design).
For the CSS inconsistencies... I'd just suggest making a style guide then trying to stick to it. Have someone be in charge of "design consistency" that way the can spank anyone inventing yet another way to display the user.
At my company, my ideal work flow doesn't work very often, but sometimes it does. I löve when this happens: The engineers write the webapp and output semantic html with only minimal CSS. then you have the designers do the CSS.
I like it when it goes this way, because:
It is easy for me to write semantic
HTML.
I am not very good at coming up
with a good design for my semantic
html.
It is entirely possible to do
the CSS without asking me questions.
The markup just speaks for itself.
However, this rarely works. Because:
The CSS has to be modified whenever the HTML changes and the designers' time is sparse.
Moreover, our designers don't enjoy styling my markup, and fighting for their time is not pleasant.
Our designers often want to change the markup. Mostly because they believe some layouts cannot be done without changing the markup or because they believe that it's the only way to make IE obey. They are technically not able to change the markup, though.
I have my doubts about many of their cases. Many times they claim IE incompatibility, I strongly doubt they really know IE that well. There are neat CSS hacks to make IE obey without resorting to
<br clear="all">
So, sadly, usually this ideal is a little off for me.
A separate designer - developer workflow is the best way to go. Designing a website and coding it are altogether different jobs. There are issues of cross browser compatability, CSS, XHTML, apart from coding standards to deal with.
You could also opt for outsourcing your HTML to a specialized PSD to HTML conversion expert like us (ButterflyHTML). It may work out cost effective in the long run