Designers and Developers: The Peace Process is on its Way
You may not have understood it, but I am a Java developer. More precisely, I deal with Web applications every day. Intranet portals, CMS, that’s my job. I am also interested in web design and typography. The thing is: I have a personal interest in Web standards and design, and as soon as I have pushed the door to go to work, I become the worst enemy ever of the Web designer.
Since the dawn of mankind and its irresistible craving for developing webapps, two tribes have been fighting each other without coming to a real understanding: the guys who do the stuff that makes the site dynamic and the guys who make nice designs to beautifully present contents. In short, the Web developers always yell when it comes to integrate HTML pages in their JSPs. The “magic” solution that the community came with to reconcile the crowds was the taglibs: they were supposed to provide tags for presenting things in a way that (even) Web designers would understand (they speak tag fluently, don’t they). But having been involved in many projects, it just doesn’t work: Web designers don’t care about programming, and that’s pretty normal. That’s none of their business. So the promised panacea just wasn’t there.
However, it seems to me that we have reached a point where at long last, we have come to a mutual understanding, solving the hellish puzzle of integrating web pages. We have indeed two things at hand:
- XHTML and CSS on one side, reducing the amount of tags to create a design and building the page in a sensible and semantic-oriented manner,
- JSR 168 on the other side.
Quick definition of Portlets, excerpted from the specification mentionned above:
A portlet is a Java technology based web component, managed by a portlet container, that
processes requests and generates dynamic content. Portlets are used by portals as
pluggable user interface components that provide a presentation layer to Information
Systems.
In plain words, the web page is now divided into components responsible for their own displaying. In an average portal, the menu would be one block, the list of articles, another one, the weather is Paris-Beauvais would be another. Translated into (proper, div-based) XHTML, it means that the layout of the portlet is based upon div; you just need to copy-paste the XHTML code, link the stylesheet, and you’re done. And believe you me, it really makes things much easier. It is not as painful as it used to be.
That being said, I still have to come accross the aforementioned “proper, div-based” HTML code. My latest experience in that matter shows two remaining problems:
- Tables are still used, even in so-called div-based designs: menus, for example, are not made with list items. Tables remain the persistant nightmare when integrating the design.
- The intensive use of badly-written JavaScript to do fancy animations still makes it painful. Big time. I am currently planning to rewrite the code which was delivered to me to make it suitable for a dynamic environment and gave up. Web designers definitely think static and write their code accordingly.
There is still a long way towards the Good Coding Agreement, but the tools and standards are there. Now, all is required is pedagogy.
