What’s a site without a page, right? Or, if you are a fan of Gestalt theory, you will know that the whole is greater than the sum of its parts. The same goes for web sites: your site will only be as good as the underlying pages. However, the impact that a single page has on a user is exaggerated by the experience of the site as a whole. Should a mistake on a single page cause the user experience to be affected then this experience is extrapolated to the entire site.
In the overall view of all things web, the page is second important only to the site as a whole. Because of this, pages need to be developed with consistency across the entire site. Common elements (like navigation tools, headers, footers, and side-bars) need to be in the same location and maintain the same appearance and functionality, providing the user with a tangible and familiar interface.
Problem
As web page visitors we all have encountered web pages that did not perform under various circumstances and technologies as intended. These are most often caused by web applications not being developed with W3C standards in mind, however, even if W3C standards are enforced, some browsers just won’t behave and break then as well. Here some tuning is necessary to support these browsers to make the site at least functional.
We often can also see problematic implementation of various features, like frames, pop-up windows, breakage of basic navigation functionality (back- and forward-buttons), loss of session information, and much more.
Other problems also arise when inappropriate delivery methods are used for various media, like embedded media that rely on specific technology or software on the client computer, interactive functionality, poor implementation of design elements, improper form validation, dead links, and JavaScript errors (resulting from JavaScript coded to specific browsers).
Design Requirements
For the designer the web page presents itself as a canvas. It is the area available to them with which they can present content in a manner they deem best for the given circumstances. However, that is much more an issue of Layout & Design, rather than the web page itself.
The designer does not have any inherent requirements of the web page as it is merely a medium. Their sole involvement is creating the overall design for the specific web page.
Development Requirements
On the contrary, the developer will have many requirements in intents with the web page itself, as it is the developer’s role to manage and build the architecture and code behind a web page. For the developer the web page is the user interface for a predetermined purpose.
Developers are responsible for implementing the proposed design in such a manner that it will be accessible, maintainable, extendible, and feasible.
Accessibility
DocType
The DOCTYPE will ensure that browsers interpret a web page in (nearly) the same manner. This provides consistency, and ultimately greater accessibility, to your web site. “But I have a DOCTYPE in all my pages, yet it doesn’t seem to make a difference!” you protest. The absence of a well-formed (that’s the key here: well-formed) DOCTYPE tag will throw browser compatibility out the window without even having parsed the first line of code. If the browser does not encounter the DOCTYPE tag before the HTML tag, it will revert to its bad old quirky self and render content on its proprietary DOM and CSS interpretations. This is especially prevalent with Internet Explorer and Netscape. There are three DOCTYPE declarations that work, at the moment (there may be more in the works, but these are the established ones):
HTML 4.01 Strict, Transitional, Frameset
1: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01//EN” “http://www.w3.org/TR/html4/strict.dtd”>
2: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN” “http://www.w3.org/TR/html4/loose.dtd”>
3: <!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Frameset//EN” “http://www.w3.org/TR/html4/frameset.dtd”>
XHTML 1.0 Strict, Transitional, Frameset
1: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>
2: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
3: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”>
XHTML 1.1 DTD
1: <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN” “http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>
Adhering to these DOCTYPEs will ensure that your page behaves properly, and most of all, as expected. “Using an incomplete or outdated DOCTYPE—or no DOCTYPE at all—throws these same browsers into “Quirks” mode, where the browser assumes you’ve written old-fashioned, invalid markup and code per the depressing industry norms of the late 1990s.” (Zeldman).
Maintainability
For a web site, or web application even, to be successful, it needs to be easily maintainable. The developer needs to be able to address the issues at hand without having to jump through hoops, and roll them out quickly and easily. At the base of maintainability is clean code. It doesn’t have to be quick, minimalistic power-code that will run a space station; the code can be as efficient or as inefficient as the abilities of the developer(s) permit. The main thing is that it is clean and consistent.
Feasibility
Technical
The most obvious issue here is the lack of technical knowledge by the employed staff. In these cases management will most likely realize the department is lacking in skill-sets and take appropriate measures, such as out-sourcing or hiring contractors to supplement the existing staff.
The second issue is the lack of technical equipment to make the project a success. For instance, if you don’t have web servers to host the web pages on, the feasibility depends on the restrictions of your hosting provider, or on the (non-) ability to hire an appropriate hosting provider.
Resource Availability
Probably the most determining factor as to how well-designed your web application will be are the availability of resources. This means specifically: time and money (anything else is a derivative of the two).
Given that a lack of resources will require constraints on development and implementation, they will most likely be sacrificed in the planning stages. This means that documentation will be greatly reduced, if not eliminated entirely, and development will be off the seat of the pants. This opens huge risks for the following:
- Scope creep, which can turn the project into a never-ending disaster.
- Bad coding, which can manifest itself as spaghetti-code, inefficient functionality, duplicate code, and improper implementation of functionality.
- Unorganized project files, caused by various developer creating and organizing their portions of the project to their own standards.
- Drop in communication levels, causing the various elements of the teams to splinter apart, and start “fighting” for their own needs, instead of working from a common agreement (the documentation).
Any of these items (and there are more, as well) may bring the project’s feasibility into question. However, because shortcuts are being taken, it is highly likely that a feasibility inquiry isn’t even considered.
Extensibility
When developing the web app, careful consideration must be given to extensibility. Despite what is given by the requesting entities as requirements, even if they say it is a one-time effort, it still needs to be managed, updated, and often upgraded with new functionality.
Keeping that in mind and developing for extensibility will also ensure that any updates and tweaks can be performed quickly and efficiently, even if a different team (who have little prior knowledge of the product) is performing these tasks.
Best Practice Solution
Code
Handicap Accessibility
Many viewers user screen readers that product audio (blind) or tactile (deaf and blind) output. These technologies should be supported under all circumstances, and take very little extra effort to implement. The main thing is being aware of the required tags, attributes, and usage conventions that they take advantage of and adhere to.
DocType
Of the various DOCTYPE examples shown earlier, the one that is most robust and should be used is the XHTML 1.1 DTD. This DOCTYPE will require that your code is completely XHTML compliant (yes, this also means that you can / should not use depreciated tags if you want your page to validate). This alone will force cleaner coding, as well as more attention to detail when planning the site.
Conventions
The developer(s) should adhere to a pre-establish set of rules and guidelines that govern the coding conventions. This includes variable naming, upper- or lower-casing, indentation, use of braces, brackets, and parenthesis, and so on. It really isn’t a question of adopting an industry standard (however, it is preferable, as it is more likely to be recognized by new developers coming into the team), the important part is that the entire team adheres to it. This alone will make code easier to read and understand, because consistent conventions are being used.
Layout & Design Implementation
Layout
The layout specifications of a page should be consistent throughout the entire web application. This demands that a common layout specification be made accessible throughout the application. This ensures two things: consistency and one central maintenance point. Layout and design are also to be separated from content and function, again optimizing maintainability. As of the time of this writing CSS is employed both for layout as well as design purposes. However, the layout specifications should be kept in its own CSS file, as this provides versatility by allowing the entire site’s layout to be reconfigured by simply swapping out one file. (Keeping it mingled with the design CSS would obviously complicate things, as you would then also have to redo the site’s design, or theme.
Design
Just like with the layout CSS file, the design CSS file is meant to provide a consistent look and feel to the web site. However, you may very well have different design CSS files for your application, allowing for varying themes (possibly by section of the site, or by user preference). Each unique theme should have its own design CSS file to allow for easy design management. This will also let you test multiple themes side-by-side when developing the site without have to redo the design CSS file every time you make a change.
Content
The page’s content is just that: meaning conveyed through text and imagery. Content is what is left when you strip away all the design, layout, and functionality.
One option to take under consideration is also the implementation of alternative delivery technologies, depending on the requirements for the site. For example, if there are strong design-requirements where the site must look a certain way for all users, regardless of browser and platform, some thought and consideration should be given to using Flash or Silverlight (just two of many emerging alternatives) to serve up the application.
This is because HTML was originally developed to deliver text-based documents over the Internet. This means that it was never designed as a delivery method for graphically intensive sites. This also means that there will be rendering issues with different browsers, as currently each browser adheres with varying success to W3C standards. Often the purpose of the site, as well as the target audience will help in determining the delivery method to be used.
Head
The <head> section of the code contains meta-data about the content and delivery of the page, as well as title and keywords used to identify it and promote it using SEO (Search Engine Optimization) methodologies.
The <head> should also contain any JavaScript includes that are used site-wide (page-specific includes should only be included on the pages in question as this conserves bandwidth). You also need to specify the various style sheets to be used. Typically all style sheets that are used throughout the application should be included (they do not take up much bandwidth).
Body
The <body> tag / section contains the elements that will be rendered to the browser. This means it contains the raw data (formatting occurs via the style sheets) for the content to be displayed on the given page.
Business Rules (Functionality)
Client-Side Processing
Any client-side code should be implemented to fulfill the following criteria:
- Editing form fields (while saving the new values will inevitably be server-side).
- Form validation (as well as server-side).
- Dynamic hiding and showing of page elements.
- Any other dynamic page changes where no database requests are necessary.
Any client-side processing should be implemented to support speed and efficiency, which has a great impact on user experience.
Server-Side Processing
Server-side processing mainly fulfills data interaction functionality, as well as new page requests. You’ll want to place the following functionality in server-side code:
- Form validation (in addition to client-side to prevent hacks).
- Saving form data.
- Processing external information.
- Reading from database and populating page elements.
- AJAX and JSON functionality.
Closing Thoughts
None at this time.
Bibliography
Zeldman, Jeffrey. “Fix Your Site With The Right DOCTYPE!”. A List Apart. 12 April 2002. A List Apart Magazine and the authors. 30 January 2008 <http://www.alistapart.com/articles/doctype/>.
Other References
None at this time.
Document History
[v0.0.1.15FEB2008] - Initial draft and publication.
