This post originated from an RSS feed registered with Java Buzz by Jon Tirsen. Original Post: Separate HTML "designers" from "real" programmers? Feed Title: jutopia Feed URL: http://sedoparking.com/search/registrar.php?domain=®istrar=sedopark Feed Description: Ramblings on Java, AOP, TDD, agile and so on. some like it jutopic! Latest Java Buzz Posts Latest Java Buzz Posts by Jon Tirsen Latest Posts From jutopia

In my experience this separation is in many cases completely flawed.

One of my hypothetical criterias of a succesful project is that each programmer on the team is capable of following an individual customer requirement ("story") from it's initial conception to it's complete implementation and acceptance by the customer. A programming team could indeed contain experts on various areas (database, front-end, middleware, messaging, build-system and so on) but all programmers should be literate enough in each area to be able to implement a story regardless of what part of the system that story will touch. The programmer may of course ask the expert questions and could write the code in a pair of two programmers (pairing with for example one of the experts).

So what's the reasoning behind separating HTML "designers" and programmers? (and why I think they are invalid)

"Designing" HTML isn't real programming
Well, this almost takes us back to the definition of the word "programming". For the sake of discussion let's just say that "programming" is the process of writing "source code". So...
HTML isn't real source code
In what sense isn't HTML source-code? In the sense that it's not executed? Well, of course it is, in the browser. In the sense that it's not really part of the system? Don't be ridicilous, it's the most important part of the system. I've seen systems built with rock-solid services, tested, performant, scaleable, just to be killed of by a single erronous character in a JSP-file. There's not a single part of the system that is less important than any other one, the chain is only as strong as it's weakest link. Every part of the system is the most important part, every part deserves as much attention as any other.
Programmers can't do good GUIs
I have no idea of whether this is true or not. But hear me when I say: If you think programmers can't do good GUI, GUI designers are even worse at programming. If HTML is source-code, then it should be written by a programmer. There are many ways that the GUI designer can instruct the programmer how to build a good GUI: draw them in Photoshop/Powerpoint, draw them in sketches, pair with the programmer while he's doing the GUI, and so on. But whatever you do: don't let him write the actual GUI code! I've seen this happen way too many times. If you're in this situation, the wisest thing is probably to throw it all away and start all over again
I don't want to waste the valuable time of senior programmers on something as trivial as HTML
HTML is far from trivial. A senior programmer would quickly realize that in order to be productive while writing HTML some kind of framework and test-harness needs to be developed. Exactly how this would look like would of course differ from project to project and from individual to individual, but writing HTML/JavaScript/CSS/JSP/macros/and so on in an ad hoc manner is not enough.

In some cases it is valid to have separate HTML designers, especially if the system is more of a static web-site than an interactive application. But I don't build those kinds of systems. :-)

Depending on your project and context you may solve the HTML-coding problem in different ways. Here at Lecando we have been slowly harvesting a framework for the web-interface. It's very small and simple in it's core but allows for amazing levels of reuse, testability, usability and quality. This has a lot to do with that we're building a highly interactive interface, not just a simple "display data in cool ways and a couple of simple forms" which requires some other type of framework.

The key concept in the framework is that an object is responsible for generating it's own HTML and is also responsible for parsing the incoming request and send out events to its registered listeners. For example, a Button would generate it's input-tag and parse the returning request, if the button was clicked (parameter set in request) it would send ActionEvents to its ActionListeners. An entire HTML-page is generated by an hierarchy of these objects. Higher level components include Tree (fed by data from a TreeModel) and Table (fed from TableModel). It looks a bit like Swing but it's a lot simpler, and it's written test-first with testability as a high priority. (For example, the whole GUI can be executed within a test-case making it very simple to write acceptance tests.)

We're hoping we could open-source it Any Time Soon Now (tm).