Here at the Church, we develop projects of various sizes that require designing and building prototypes of varying complexity. Much of my experience has been with large prototypes, and I wish to offer three suggestions for handling 20+ XHTML pages and numerous other assets.
#1: File Organization
A good Web application will have a domain structure that mirrors the content structure. This allows users to see where they are both on the Web page and the address bar of their Web browser.
is much cleaner and clearer than:
In my projects, I like to separate page structure from assets like this:
As seen above, “family,” “scriptures,” and “temples” would contain site content. The “ui” folder is for site assets. This folder can contain any number of things related to supporting the site content. Here are a few suggestions:
While any number of names could be used instead of “ui,” this particular word is quick to type when typing paths in your XHTML code. Placing all of the assets in a single folder will reduce confusion around what is content and what is an asset. This becomes particularly helpful if your customers browse the site using the file listings on your server.particularly helpful if your customers browse the site using the file listings on your server.
#2: Server-Side Includes
Many parts of your application will be used over and over again. A header containing the logo and site navigation is likely to appear on every page. If you copy and paste that code from page to page, it becomes very difficult to manage once you get into the range of 20 to 30 pages. Implementing even a small change will be an arduous task unless you’re very confident in your global search-and-replace skills. Instead, make a single instance of that code as a server-side include and reference it on each page.
Several methods are available, but here’s quick example of how to do it in PHP:
Create a file called header.html and put all the code in it that you would like to reuse. In this example, we would put in all the logo and navigation code.
Then, on each page where the logo and navigation would normally be, simply make a statement like this to reference your external file:
<? include(“/ui/includes/header.html”); ?>
As changes are requested, you can edit the code in header.html and it will be reflected everywhere in your application where the “include” is used. This technique is a huge time-saver for any reusable code snippets in your site.
Subversion, commonly known as “SVN,” is a widely used technology that keeps track of your site files. It monitors who is working on the code and what changes they make. If you are part of a prototyping effort with multiple people, this method will ensure that you don’t overwrite each other’s work. Subversion has a variety of tools for merging changes when two or more people edit the same code, as well as the means to roll code back to previous versions if something breaks.
If you are the sole designer or coder on a project, SVN can sometimes be overkill, but there are still some advantages. Most corporate SVN environments are on reliable servers with backup measures. Checking your code in will put it in a safe place and make it easy to get if someone else needs to pick up where you left off. The code revision history is also helpful if you mistakenly introduce a bug and you need to go back to a working version of your code.
While these tools may seem to add unnecessary complexity to a Web project, investing some time in their use will yield huge dividends of time and efficiency as your project grows and changes.
Clifton Labrum is an interaction designer for the Church.