- Overall Architecture
- Determining Page Structure
- Web Inputs
- Maintaining State
- Determining Interaction Sequences
- Data Analysis
- About This Article
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Determining Page Structure
Some sort of plan is required. This is a good time for what the extreme programming community calls a spike solution. This is essentially "producing the simplest thing that can possibly work," usually without frills of any kind, to determine what sort of architecture might best match the problem requirements. Any attempt to produce something that will be incorporated into the finished product should, however, be firmly resisted. Whatever your instincts tell you, it is foolish to do too much coding until you have some idea of how the basic components are going to fit together, so you should build prototypes to be discarded.
You have to present content inside a structure, which you might think of as layout if you are primarily aiming at human-readable webs. Spend some time considering structure without worrying too much about content and decide how the different required layouts relate to each other. Usually some form of nested layout will be appropriate, with an overall "site look-and-feel" providing the outer style elements, with different variations (sometimes on content, sometimes on layout, sometimes both) filling in the gaps.
At this point in a web design, I tend to think mostly about the variable elements—the items of content that vary from page to page. These variable elements are those that are ultimately going to be filled with information—from databases, from other sources on the network (for example, your server could be a network news client, or a client of other web servers from which it extracts XML content), or from files whose paths may be selected using computations on inputs.
An important structural aspect of many webs is the hierarchy of the pages. Some pages will share common top-level features but differ at lower levels. There may be several different versions of a high-level page, which differ primarily in content rather than structure. Look for the common structural features and abstract them from the content. You can often map the page hierarchy onto an object hierarchy, using a top-level page as a template for lower-level pages, and so on down a tree. As long as you can parameterize the page designs according to content, a graphic designer can take the parameterized design and modify the site look-and-feel.
My most rewarding web work has always involved working with a designer or design team with good visual creative skills, which I do not myself possess. They provide the eye candy (and, coincidentally, also structure the information to enhance its readability and usefulness), and I build the engine room that drives it. Ultimately, it becomes a matter of slotting (appropriately formatted) variable segments, incorporating content provided by the customer, into what the designers have produced.
Suppose you want your web site to have two basically orthogonal sets of content: some parts of the content are to be available everywhere, whereas others are clustered around a category such as "topic." You might determine that your overall look-and-feel should be as in Figure 1, with the same site banner and graphic on every page. The top and bottom navigation bars are to be used for the links to invariant pages, and the left-hand navigation bar will contain links that depend on the particular topic covered in the page.
){kind=link}
Figure 1 Outline of a web site's page structure.
Supposing that you choose to represent each page style as an object, you have four variable areas whose content will need to be determined on a page-by-page basis. If you then want certain topics to allow the reader to navigate among subtopics, you might then choose to impose a finer-grained structure on the main portion of the page. These subtopic pages will (because they all refer to the same major topic) effectively have the same structure as the topic page to which they relate, but they might (for example) have a navigation bar at the top of the content area, which allows the user to navigate between different subtopics.
So you could use a subclass of the topic page routine, in which the main content window method first generates a subtopic navigation bar, to generate these pages. The topic page methods will still be parameterized by the topic, but the subtopic pages will be parameterized by the subtopic in addition.
It might be that you have subtopics common to all topics. In this case, the same object inheritance structures will serve for both types of subpage, but the data relationships might be different. Spend some time thinking about these relationships before you start to determine what structure you want your code to have. Even then you will be wrong about the code structure; you will just be less wrong!