- Phase 4: Production and QA
- Establishing Guidelines
- Setting File Structure
- Slicing and Optimization
- Creating HTML Templates and Pages
- Implementing Light Scripting
- Populating Pages
- Integrating Backend Development
- Understanding Quality Assurance Testing
- Creating a QA Plan
- Prioritizing and Fixing Bugs
- Conducting a Final Check
- Phase 4 Summary
Setting File Structure
Often confused with site architecture (Phase 2: Developing Site Structure) by newbies and clients with just enough knowledge to make them dangerous, file structure is, in fact, simple but important housekeeping. Starting out organized will help you stay organized, so make it a priority. (This is especially true for projects with multiple team members.) Although there is no best way to organize a site's file structure, different strategies support different goals ([6.4] and [6.5]).
Figure 6.5. Two structures, different strategies. [6.4] has images listed at the root level, and [6.5] lists images within the current month folder. When to use which strategy is totally dependent upon preference.
The Client Spec Sheet asks about redesign specifics regarding existing HTML page-naming conventions and the existing file structure. Does the client want to leave things as they are, and if so, why? Whichever method is eventually decided on, it should be aligned with redesign and maintenance goals (such as how the site plans to add and archive post-launch content).
Redesigning offers an opportunity to start over clean. Chances are, the HTML structure of the old site is a mess: files duplicated, images scattered among folders, old versions of files still up on the server... Establish a logical, maintainable file structure for the redesign site. The goal? To start out as clean, organized, and scalable as possible.
Three File Structure Questions
How is the folder structure currently set up, and is there a client-desired reason for this method?
Does the folder structure follow the content structure in organization of the content?
Will the images be at the root level or separated into individual folders?
File Structure and Scalability
How much growth (increased traffic, added content, new products) is anticipated in the 12 months following launch? Are you planning to add additional sections? How do you see them growing? By date? By topic?
When determining the file structure, know that it depends largely on how the client envisions the redesigned site growing and evolving. The plan you adopt for your file structure must be aligned with the anticipated maintenance, including logical archival of outdated content. Create subdirectories that will make sense to the maintenance team after launch and include file directory instructions as they pertain to archived or added pages in the Style Guide. Disorganization and clutter is a regular post-launch occurrence in situations in which maintenance has been handed over to a new team. An organized file structure that anticipates growth and regular updating can help counter the almost- inevitable degradation of site organization. For setting the file structure, a few pieces of information that are essentially based on client preference should be known. For instance, will the redesign repurpose existing files and the existing file structure, or will it start from scratch? How often will updates be made? Daily? Quarterly? The Client Spec Sheet asks for this information.
The big question here is this: Does the client care? Possibly, but not likely. Does the client even understand? Maybe, but probably not. But whether dictated by the client or established by your team, the file structure should respond to and fit with the answers of the preceding questions. The goal? Be scalable. Stay organized.
QUICK REFERENCE: STATIC VS. DYNAMIC
Static Site: Front-End Only
Pages are prebuilt in their entirety and are viewed when referenced by a browser, usually using the .html or .htm extension.
Dynamic Site: Font-End and Backend Teams
Pages are created "on the fly," usually by pulling content-specific information from various places such as from a database. The site usually contains standard HTML pages as well. Additional code (ASP, JAVA, PERL) can be added to the HTML pages to allow for dynamic content population.