I have a Java/Spring MVC/JSP/JSTL webapp. We have a designer that gave us some pages to start with, but he's quite behind so we had to create some pages on our own, and obviously as the project has progressed other UI stuff has changed. I think one reason he's behind is because it's hard for him to work with the site.
We haven't setup a development environment for him because that would include a database, Eclipse and Tomcat on his box and I worry that we would then spend an inordinate amount of time supporting his development environment and he would still get nothing done. On the other hand, he's basically already had a bad experience and I've spent time taking his changes (view source, change, email to me) and trying to figure out what changed and copy them back into the JSP files.
I think tomorrow night I'm going to bite the bullet and see if we can get an environment installed for him, but there's got to be a better way... What is it?
I found that it's best that the designer basically live within HTML and let the JSP stay in JSP, with the JSP developers picking up the labor tab for keeping their pages up to date with the designer.
That basically means that the designer is responsible for creating complete, functioning pages in pure HTML. Ideally, the designer has a solid head start on the JSP coders. That the designer has worked through navigation issues, etc.
If there are dynamic elements on the page, then the designer needs to present all of the proper renditions for the JSP coders. This may require as much as several copies of the "same" pages, but each with a different dynamic view.
The designer should make notes or use some other convention to identify in the page elements that he feels are dynamic (could be not just the contents of an INPUT tag, but also other things like shortcut id's and such).
Ideally, the designer will identify, and STICK WITH, logical blocks of code (like navigation areas, side bars, and other chrome). This lets the JSP guys more easily refactor their pages using includes or tag files or whatever.
The JSP folks then take these functional, yet static, HTML pages, and are responsible for adding the dynamic elements and not breaking the pages. If they run in to issues that break the layout (say a column goes to big of something like that) and it needs to be addressed, they can send the generated HTML to the designer so they can correct it without having to ever set up their own server or understand that lifecycle.
An added bonus is to make sure that you have a shared test server that both groups can access. This server should host both the HTML and the JSP pages, and it helps ensure that you have the external resources in the right places, using the right names, etc.
For example, if a coder does a change that breaks a page, he can upload the generated HTML file to this server, and it should just render like their JSP page would. This allows everyone to see it "in place". The designer could even fix the generated HTML file if that's what they feel is easiest. The original coder would need to keep the old copy around so they could perform a diff if they had to in order to locate the change. Usually the changes are reasonably obvious assuming the designer communicates their change properly.
Another aspect is to basically make sure you're following really good HTML practices, notably semantic markup, lots of CSS, etc.
This is because nowadays, much of the issues with HTML pages are not so much in the mark up as they are in the CSS. The JSP folks generally don't need to work with the CSS files. This allows the designer to make changes in place in order to make fixes much more easily. It also keeps the markup as neat and sparse as practical, again this allows the JSP folks to more easily catch changes in documents.
If you're Ajax heavy, then the designer should be using "local" data sources that can be readily swapped out with "remote" data sources. This keeps the page code the same, and requires the JSP coders to simply swap out data source implementations to hit their servers rather than static data.
The farther along the designer is with their initial pages the better. The game is leaving the burden to the designer to create functional, "feature complete" pages even with just static text. This lets the designer drive the project while the JSP guys are simply automating it. Try to ensure that the major design swings are done early solely by the designer and project owners before the pages start hitting the JSP coders just to keep the changes down to a dull roar and just let the JSP guys march along behind the designer, automating and filling in the blanks as they go.
If the designer has no Java experience, I don't think he should be making solid pages first. The designer should be in charge of page layout and functional flow, which the back end developers use as a guide (a story board of how the web application fits together and how each page works). That is the designer needs to be responsible for the visual implementation of the requirements.
The developers should produce quick and dirty pages with all the required data. The designer who's strength is in layout should then make those pages into the finished product. This way there is a good division of responsibility. The designer will need to work closely with the developers at times to get data in a format that is workable but once so much is already in place, working as a pair (designer/developer pair programing) at times becomes reasonably economical.
If this type of development will be the norm then the designer should learn the web application front end since the designer aught to know about tools such as site mesh and become fluent with a few JSP tag libraries.
If you are going with REST/ajax heavy applications: Then you can get greater separation of concerns as the designer can create pages as the developers make services available. This could reduce the need for a full development environment but I don't think negate it. The designer will need to be able to read the underlying code to know what is exposed to the JSPs to work most effectively.
