Step 12: Develop HTML Templates
When the design conversion has been completed by the designer, the developer can create HTML versions of the templates. Prepared with the reference images, the GUI Design Specifications Document, the web-ready images, and possibly a wireframe outline for each template, he will be able to accurately recreate the approved design in HTML.
Note that HTML is used to describe the coding language because it is likely going to be the major part of the technology used during this phase. It is possible and perfectly acceptable for the HTML templates to be developed in XHTML, or a scripting language and appear as CFM, ASP, JSP, PHP files or a number of languages. In any case, the technology will be transparent in this phase.
When developing the HTML templates, it is important that an intelligent architecture be created. Planning and implementing this now will allow the rest of the intranet site to expand over this framework and be exponentially more manageable over the long term
Intelligent architecture, in this instance, refers to a clear separation of content, presentation and functionality. An example of this would be a HTML content page with information about a corporate division's historical milestones. The actual HTML page (milestones.html) will just consist of the HTML layout and the content. The information about how the content is formatted (the colors and font information defined in the GUI Design Specifications Document) will be in a separate Cascading Style Sheet file (/includes/css/format.css). And the information about how the page behaves (image rollovers, document object triggers, etc.) will all be in a JavaScript file (/includes/js/rollover.js).
The formatting and functionality documents will be referenced by the content page's HTML source code. This code will instruct users' web browsers to download the appropriate include files and process them when it is being displayed in their browser. When these include files have been downloaded for the user's intranet session, they will just need to be downloaded once, and then all other content files can refer to them. This can have a dramatic effect on page load times when compared to having all formatting and functionality embedded in every page.
The additional advantage of this method is its extra-special selling point. By clearly separating the content from the presentation and the functionality, any of these three things can be changed without affecting the others. If the design evolves and/or users want larger font sizes, one CSS file can be changed to update every content page's layout. The functionality, similarly, can also be modified in the same way and to the same effect.
Referring to single CSS and JS files is probably an oversimplification of your intranet needs. You are more likely to have multiple CSS files for different templates (for example, all templates will use the same /includes/css/global.css global font definitions, but the splash page and discussion forum page won't need the /includes/css/navigation.css navigation font definitions).
While HTML files can theoretically refer to an unlimited number of CSS and JS files, the goal here is to create an intelligent architecture that will be extensible, maintainable and sensible over time. Be careful not to micromanage functionality and layout to an extensive degree.
The last item to mention here is in regards to scripting languages. There are many advantages to using these technologies, but plan your implementation well, as per the above. Use the /includes/templates/template-top.inc and /includes/templates/template-bottom.inc include files to separate the advanced functionality of some sections from the formatting elements (note that the file structure of the site that is referred to here will be discussed later on). The advantages are also great in regards to organization and long-term maintenance, but the savings are more recognizable on the server-side (corporate benefits) than the client-side (user benefits).