We can access any information within seconds – the Internet expectation is fast. For many clients, businesses and management the development expectation is also fast but the reality can be slow and disappointing with unexpected costs or delays. Some of the key reasons are frequently poorly understood / communicated requirements, change of mind with look and feel, a system issue or browser compatibility issues.

There is another way – it can be easier!

This series of articles attempts to expose why this happens, provide proven solid guidelines for all involved in the development process and finally best practice approach.

This article will discuss the difficulties of a professional web development team focusing on the integration between the system / code and the UI / Design. One of the most subjective element to a client is the aesthetics which should be quick and easy to alter, unfortunately on enterprise scale web applications with developers and designers working together these small quick changes frequently become larger changes resulting which during the rush nearing release cause other unexpected faults further delaying the delivery – sounds familiar?

To ensure we fully understand the problem lets introduce a fictional web team, called them the Yellow Team.

To set the scenario…

The Yellow Team deliver high availability, enterprise scale web sites expecting large numbers of user say 6+ million a month creating 50+ million page views. The Yellow Teams system web developers pride themselves on the high performance of their complex web application – sub second database queries from Terra Bytes of data, intelligent AJAX calls improving the experience for the user, powerful SEO, etc, etc.

The Yellow Team UI Designers pride themselves on all their applications being sleek, simple, easy to use, great on the eye, quick to download from a graphical perspective, built with the latest CSS techniques, small quantity of HTML, high flexibility to amend the style and accessible to all (DDA).

The two different groups within the Yellow Team need totally different skill sets to deliver the best product possible. The problem is how does the developer group help the designer group and vice versa.

What are problems faced by our Yellow bunch?

Different software tools, the developers are using Visual Studio 2005, the designers wont look at this they use Macromedia Dream weaver and adobe Photoshop. Sharing files between the two is not always smooth, an addition line or a table inserted when the designer expected DIV tags to maximize CSS or a change to the doc type or use of a different tag option such as <B> or <STRONG> etc, is not very helpful and creates frustration, repeated work and delays.

JavaScript styling, to create the usability required JavaScript will be found somewhere on the site. In many cases the developer makes a decision to embed HTML to render out within the JavaScript code, it was a quick and easy solution for the developer at the time. When the designer wants to change the look and feel their design tools are no help. It may not be clear where this HTML is coming from, they have to trawl through the JavaScript and manually make the changes. This is not an issue if your designer writes the JavaScript, however if you take the view that the JavaScript is a key part of the application and should be authored with the same discipline as SQL or C# / VB business logic then it is likely that the developer owns the JavaScript.

ASP.NET Server Controls are definitely great however used with out thought for design they can be a big issue. If the abstraction includes HTML rendering it may be difficult for the designer or impossible to change the style. This limits the use of the control – reduces its reusability and delays the development of the project. In some cases the developer (who may not be a UI expert) has embedded font tags in the HTML within the control; this will make life hard for the designer.

To summarise so far all web projects suffer the same project management challenge – aesthetics which are highly subjective. This results in often unavoidable changes at worst time – the end. What might be a small aspect of the UI could unfortunately for the web team and the PM result in changes in server controls code behind changes, re-compilation, JavaScript alterations etc. Whilst this can be done it is not efficient, will take time, cost money and potentially delay a project.

Some good guidelines to consider which may cause radical change in your development depending on your current approach are:-

1.      Avoid Rendering HTML from .NET code.

This is a huge Gotcha to avoid! Where code behind exists avoid rendering HTML tags from the c# or VB.Net. Stay well clear of response.write etc. The use of containers such as DIVs, .NET Place Holders controls, Repeater Controls etc will allow the content to changed from the code isolated from the style. It may seem easier but don’t do it! The times when HTML Tags must be rendered from the code behind be sure to sit down at design time with your designer and identify where the ability to set a CSS class name attribute would be advantageous to the designer and then make sure you expose the ability to set the CSS classes easily without needing code behind or Visual Studio, the best way is to expose a property which can altered as an attribute in the aspx.

2. Avoid rendering HTML from JavaScript

Very similar to rule one, don’t do it! The designer will not be able to function quickly if they need to search through an array for the tag they need to change or get the source to a reference JavaScript file and change a tag embedded in a function. Again there are better ways – a simple div tag used as a container would probably do the task or in many cases the use of CSS could replace lines and lines of JavaScript. If style related elements have to be in the JavaScript then use good programming practice – meaningful variable names, comment the code etc.

3. Avoid In Line ASP.NET

This means don’t use <% some .net code %>. This is a really flexible, quick, easy way for the developer to implement a change (or Hack it, if you as me) but it will bite you back later! If we skip all the good programming reasons to avoid this practice in a large enterprise application and focus on the designer it really will not help them. The tool may not (later versions of Dreamweaver supports .net) support the <% tag it etc. It is not friendly!\

4. Do not save Formatted ASPX page in Visual Studio

This is slightly unfair to Microsoft, VS 2005 is a lot better and does not normally chew up the html and spit out its own additions. VS 2003 did! The frustration caused when a page has been designed and a code bug needs fixing so the developer fixes it resulting the well designed page no longer looking as the designer intended must be huge! This is the key problem to avoid anything that aggravates this issue should be avoided!

5. Developers keep their own working copy of the site

It may feel like an additional administration overhead but it saves a lot of time if the developer can work freely in the knowledge that he can not affect the files worked on by the designer. I have seen it work very well were the developer version has little or no CSS so the page layout is simple and obviously not designed. This provides the additional benefit that management will not feel the product looks ready and want to go live. It abstracts functionality design from look and feel focusing the entire teams mind on usability which a very good result.

6. Release the code behind DLL or code by side files to the designer

Let the designer own the final release version, release to them the updated code behind dll or code by side files. They can replace these files on the solution knowing no HTML was affected. This should mean the developer has tested their code and release it knowing it works.

7. Agree at the start of the project the folder structure

When under pressure time is not always available to tidy up the structure where developers and designers had used different structures etc

8. Document a Development Site Map as early as possible

Define in a few lines each pages that will be used an their names following a consistent convention at the very start if possible. Include pages which the user may not navigate but the designer and developer will use such as a pages which redirect, custom error pages, security authentication pages, pages which are used in IFRAMES, pages used by AJAX, pages or file extensions which are not standard such as image handlers or dedicated SEO pages.

Keep the development site map up to date. Add any config files and detail regards expected parameters on the query string for pages etc.

This application bible will reduce questions bouncing around the team, reduce repetition and help project management understand the overall progress of the project.