But if that front-end developer or designer (usually I refer to this as the presentation layer, rather than front-end, particularly with the advent of asynchronous data exchange) doesn’t know how to handle state changes or meaningful alert or notification messages, or the right way to lay out a form, the whole app can be hosed even if those gradients look like lickable candy.

In the case of the PHP-based sites you and I build, runtime is effectively whenever somebody loads a web page so there’s little backend possible that’s not tethered to the frontend. In other frameworks there’s more accommodation for decoupling things like data management from page building, and that’s what I think of as backend development.

I’ve been on projects where I develop the UI based on the designer’s direction and programmer’s input, but it’s an unsatisfactory relationship. When I can work directly with the template during development of the framework, the site tends to work a lot better.

The projects I’m involved with tend to involve close collaboration with the designer, editor and developer; the designer gets frequent feedback from the developer while the design’s in progress to ensure we don’t collide over what’s offered and what’s possible within the budget. I can do design, the designer can do some dev, and I think shared backgrounds of that sort are vital to make good, usable work, but at the same time it’s also important for team members to have deeper specialties and clearly differentiated tasks.

Every company that has hired me to do front end development, freelance or permanent) has expected me to do the following, at minimum, *exceptionally* well: HTML, CSS, JavaScript.

I am also required to be proficient in PHP, ASP.NET, JSP and/or ColdFusion at any given time. This includes writing original code, not just modifying it.

Very Very Often, I am required to at least know how to modify graphics using Photoshop or QuarkXpress.

I have also been employed as a Designer, specifically because I have the skills to take into account the constraints of actually creating the layout as presented on top of creating kick-ass UI.

I have also been employed as Programmer, which involves no UI, graphics or DHTML. This “programmer” definition is actually what gets me, because while I can code, I can’t code C or C++ or any of the more traditional programming languages commonly associated with a CS degree. I do not actually call myself a “programmer” despite knowing the more in-vogue programming languages.

front End Development entails “skinning” back end code as well.

Just my view. Been at it since 1999 professionally, after graduating frm carnegie mellon with an ART degree. though taking a break since having my babies

If the front-end is displaying as it should and you an interact with it as you should, but the data it is displaying is a problem/wrong, or if the whole network crashes, then the problem lies with back-end or with the content people. Usually content. But the best people to determine if the issue was truly a front end problem, or a problem where the back-end wasn’t sending info properly to the front-end, are the front-end people. Ah, process of elimination. So yes, they all need to have at least a basic understanding of all the layers of a site or program. That said, in a really large project, no one person can do everything, and there’s a large difference between a site designer and a maintainer, and what they ultimately do.

I’m one of the design presenters the other night. I don’t think there’s anything you should have done to your presentation – the right people were engaged. Maybe separating tracks would help refreshphilly, but it would also encourage the barriers that currently exist.

No need to echo many of the statements in the comments above. Many years ago I walked in the shoes of a developer, but at the insistence of colleagues with more talent in that arena, I stepped away. I do think it’s important for anyone in the design world to have some experience in the development world so they can understand the constraints behind what they’re doing.

I believe that good UX design focuses on users, but good UX designers HAVE to learn the Whys and Hows of the systems they’re designing for. Otherwise, they’re perpetuating this stereotype that designers and developers have to be in conflict.

Thanks for a good presentation and for the insight above.

In other words, on the projects where I am designing, I really should wish I was also developing it, as well. (And for the most part, that is the case still for me.) This grows out of our tradition of all being designers and developers (coming out of the Multimedia Department at UArts).

Hence, we are a design/build studio. I personally believe that the design and build process is one integrated flow when done best. Design decisions are made throughout the process of creating a website or web application. In my mind, agile development processes acknowledge that you are going to discover things throughout the entire course of the project, and therefore need to make new design decisions and adjust development process.

Probably one of our best kept secrets is that Alex is a very good designer, even though he primarily leads up development. Yet, his design skills are not wasted. They manifest themselves most obvisiouly in his feedback of our designs, and more subtly they allow him to make good design calls on the fly while developing.

I think it all boils down to the necessity for all members of a team to respect the work of the other members. I know we do that, but it is interesting to see how much passion your post brought out.

___________

In terms of the definitions, people often refer to the front-end and the back-end of a website, but that does not mean that a front-end developer works on the front-end of the website and the back-end developer works on the back-end of a site. Back-ends (or signed-in states) of websites have front-end (or user interface) components to them. And modern front-ends of websites are dependent upon the back-end infrastructure. All parts of the site, therefore, needed to be created in collaborative way using a whole range of skills, including what is often divided between designers, front-end developers and back-end developers.

OK. Now I sleep.

Presentation aside, I agree with Kominetz on the front-end/back-end developer distinction. A back end developer specializes on building a framework like Symfony. He/she focuses on the lower level, technical architecture nuts and bolts of building *systems*.

A front end developer uses back end systems to build web sites. This person is focused on browser side interactions, adherence to web standards, and user experience.

As JP said, any web developer worth his/her mettle needs a working knowledge of all the layers of a web app from front to back. And most can hack JavaScript just as well as they can server side code.

But there’s so much room between the concerns of browser side interactions and database/model architecture that specialization can certainly be a resource on large scale projects.

I haven’t worked much in the general web world, but I do remember programmer friends having trouble with designer coworkers when both tried to play in the code, especially early ASP and JSP with Dreamweaver. Think “when all you have is a hammer”. Have designers stopped doing that and gone “UML” with mockups and wireframes? That’s the better solution than playing in the same sandbox. Common language that both sides can speak, then realize in their own spheres. Agile also solves this in a less formal way.

Designers might not need much more detail than you gave in your presentation, but they should have some. They should be aware of the kinds of technologies out there and what their long-term impact on a system may be. Like you said about general CMS features everybody wants later, the designers need to be aware enough to know what to ask for (now and later) and know the smell of BS when the tech side gives it to them.

I don’t think you went too techie; RefreshPhilly may want to provide “tracks” if people aren’t getting the right level of whatever they’re into in future meetings. Never enough monkeys, but perhaps a few too many database queries!