The biggest mistake one could make when building a dynamic site is to make it up as you go along. This is a guaranteed prescription for failure because inevitably you will omit a crucial step or overlook a critical piece of information. This why it is so important that you "think through" the plan before constructing the application.
For example, a simple procedure, such as booking a baseball diamond at Oakbridge, is actually quite complex. When the user hits that part of the site, he or she has to make some decisions. The first one is to choose when the diamond is available. When that is determined, the user can reserve the diamond using their membership number, providing the user is a current member.
On the surface, that is a rather simple request. However, a lot goes on behind the scenes. Here are the basic steps:
Choose a baseball diamond.
Choose from a range of desired dates.
Check the availability of the diamond.
If it is available, reserve it using the membership number, or go back to Step 2 and choose a different date, or back to Step 1 to choose a different diamond.
Putting together something that accommodates those four simple steps requires the developer to do two things: plan the data and illustrate the logic.
Don't laugh at Excel. You can actually select all of the cells in an Excel spreadsheet and drag and drop them into an open Dreamweaver MX 2004 page. When you release the mouse, all of the cells dropped into Dreamweaver are contained in a Dreamweaver table on the page.
A data plan creates the blueprint that is required for the data model. Although it sounds rather technical, this document is nothing more than a list of tables and fields that will be used to store the data. If you have a database designer on your team, he will most likely refer to this document as a data dictionary.
A number of ways exist to create this document, but, from our experience, one of the easiest is to either create a spreadsheet or use a table in a database to create the data dictionary, as shown in Figure 4.1. You will find a PDF template of the data dictionary model, Data Dictionary Template.pdf, on the book's web site. Feel free to download it and use it for entering your tables and fields in a database.
The data dictionary should contain the following:
Field: This is what you are going to name this field in your database. Use proper naming conventions that are allowed by your database (in this case, MySQL).
Type: What kind of field is this? Is it a text field? Is it a date field? We recommend you use names corresponding to the field types available to you through your database. For example, DateofBooking works with a date field.
Length: If it is a text field, how large do we need it to be? For example, if we are storing someone's first name, do we need 100 characters? Or do we know that the average name would probably not exceed 25 characters? This is one part of the process we can change in the future if we discover that someone has a first name that could take two lines of a bank card.
Description: Use this area to enter your comments regarding the field's function in your table.
After you have your tables and fields listed, create a model, or schema, of your database. The schema will show the tables in the database and their relationships to the other tables in the database. This way, you can see how everything works together. To create a schema in Freehand MX and to learn how to use a new tool?the Connector tool?introduced in Freehand MX, follow these steps:
Open a new document in Freehand MX.
Select the Text tool, click once on the page, and enter the following text: Database Schema. Font, point size, and weight are your choices.
Select the Rectangle tool and draw a rectangle.
Expand the Properties panel by clicking the down arrow. When it opens, you will see two tabs named Object and Document. Click the Object tab to open the Objects panel.
If a panel isn't visible in Freehand MX, it can be opened in the Windows menu. In this example, if the Object panel was not a part of the Properties panel, select Window, Object or press Control-F3 (PC) or Command-F3 (Mac) to open the Object panel.
In the Object panel, set the dimensions of the box to 200 pixels wide by 150 pixels high. Press Return/Enter after entering each dimension to cause the box to change on the page.
If the database is large and contains dozens of tables, you should consider converting the box to a symbol. Full details are given in Chapter 2, "The Architecture of Dynamic Sites," in the section "Symbols in Freehand MX, Flash MX 2004, and Fireworks MX."
Select the Text tool, click once inside the box, and enter the following text:
The example we are creating contains four tables. Here's a quick way of creating the four boxes without copying and pasting:
Select the Pointer tool?the solid arrow?and marquee your box to select it and the text. Place the cursor inside the box and press the mouse button. With the mouse button down, press the Alt (PC) or Option (Mac) key and drag the selection to a new position. Create two more copies of the box, as shown in Figure 4.2, and change the table numbers to reflect those shown in the Figure.
When the MX Studio was released to the market in late 2002, Freehand was included. Though the inclusion of Freehand in the Studio wasn't a surprise, it was surprising that the product did not contain the "MX" brand. This was remedied in early 2003, when Macromedia released Freehand MX to incorporate the panel-based MX interface.
One of the more interesting tools was one with the odd name of the "Connector" tool. There really wasn't anything remarkable about it until developers discovered that, once again, Macromedia had been listening to its users and watching them work. When we create these schema, we have to connect the boxes to each other to illustrate data flow. This was both a repetitive and time-consuming task. The Connector tool removes that tedium from workflow because it enables developers to map information architecture, data flows, and site maps and to assign relationships between objects on the page.
The key to using the tool is to understand that it establishes the relationships between the objects and that the look of the lines is controlled through the Stroke panel. To use the Connector tool, follow these steps:
Select the Connect Line tool, as shown in Figure 4.3. When the tool is selected the Object Properties panel will change to reflect a stroke.
With the tool selected, click once on the left side of the Table 1 box and drag down to the same position on the Table 2 box. When you release the mouse, the lines are drawn for you, as shown in Figure 4.4.
To thicken the line, select it and click once on the Stroke Description in the Object Properties panel. This will open the Stroke panel. Set the thickness to 2 points, as shown in Figure 4.4, and press the Enter/Return key. The line gets thicker.
You now have graphically illustrated the way the information from Table 1 is linked to the information in Table 2. The other relationship is data flow between Table 2 and Table 4. In this case, it flows both ways. Here's how to illustrate that relationship:
Select the Connector tool and link the Table 2 and Table 4 boxes. Open the Stroke panel and select the left pointing arrow from the pop-down menu, as shown in Fig. 4.5. Set the stroke to 2 points.
Set a single connection between Table 1 and Table 3. Connect Tables 3 and 4 with a two-way data flow. When finished, your document should resemble that shown in Figure 4.6.
The lines connecting the field boxes are, for lack of a better analogy, connected to the boxes. For example, if you want to remove a line, select it and press the delete key. You cannot, however, move the lines. If you do, the data boxes to which they are connected will move with them. To see what we mean:
Select the Select tool.
Click on a line and drag it. The line and the box move. Undo the change by pressing Control-Z (PC) or Command-Z (Mac).
Moving a box has the same effect. Click on a box and move it to another location. Note how the line connected to it changes to reflect the move. Undo the change by pressing Control-Z (PC) or Command-Z (Mac).
Do not use the connect tool for database schemas because relationships have been within specific fields between tables and not tables themselves. If you are connecting fields, use simple strokes with arrowheads pointing to specified fields.
A workaround to use the Connector tool for a schema is making a box for each field and then a separate box for the table that contains the field boxes.
Now that we know how the data flows, we have to illustrate the logic using a flow chart.
To answer that question, you have to first ask another: What is logic? In extremely basic terms, it is the ordered sequence of steps required to get from point A to point B. Booking a tennis court at the community center looks simple, but everything in a web application requires a number of steps to achieve a certain task. For example, a user may be required to press a button to book the tennis courts. On the surface, this is a simple process, but the logic behind it includes checking if the court is available and, if it is, booking the court and sending a confirmation. The best way to show this logic is with a flow chart.
Think of a flow chart as being the road map for the logic. Building dynamic sites is a complicated process, and you simply can't keep every step in your head until you start building the site. This is especially true when working in a team-based environment; a flow chart shows everyone involved what they need to know, and it underscores the requirements of the task at hand.
As we pointed out earlier, booking a simple baseball diamond requires a four-step process that enables the user to choose the baseball diamond, choose the date, see if it is available, and make the reservation based on a membership number.
A flow chart, as shown in Figure 4.7, presents everyone with a visual representation of the process. It is also a relatively simple process and is flexible enough that the charts can be combined to illustrate the entire process.
Although the process of mapping out the logic may appear tedious and a huge imposition on your time, there are three solid advantages behind this step:
Planning the logic allows you to build the site on an extremely solid foundation.
You discover whether your concepts or functionality are workable. You can identify functionality needs and determine if all the requirements for the process to work are being met. At this stage, especially, it is much easier to add features than later on.
You actually save time. This stage of the process will identify potential problems before they occur. By solving these issues at the start of the process, the final application will be much more stable.
Although we can use many types of symbols in a flow chart, we will use the four basic symbols, shown in Figure 4.8, for our purposes. Copies of the Fireworks MX 2004 and Freehand MX files, named LogicSymbols.png and LogicSymbols.fh11, are located in the Chapter 4 Exercise folder of the book's web site.
The basic symbols are:
Diamond: Decision block. This block answers a logical "yes/no" question, such as, "Is there a Cookie present on the user's browser?" From here, you have two exit points?one for yes and one for no.
Rectangle: This shape indicates a procedure, which is a single step or instruction. A procedure can only have one entry point and one exit point.
Parallelogram: This shape indicates a series of steps condensed into one subroutine. Often, this symbol can be broken down into a series of logical steps that could be indicated on another page.
Ellipse: Terminal points in your logic. This is where you begin or end your logic sequence.
In Figure 4.7, we showed you a typical login sequence. This map is fairly typical of the work produced by developers. Unfortunately, even though the map looks impressive, there are some serious problems.
The first is that the steps are terribly confusing. They can make life difficult for the database designer and the coder because it is hard to tell which steps are programming steps and which are decision-making steps.
The second issue is the improper use of boxes. Using our shapes as a guide, the map is composed of procedures, which is not useful if your job is to build the database or do the coding.
Finally, it is hard to tell where we enter and exit our logic. This chart will impress the client, but it is too complex. There are many steps that can be consolidated. Remember, the best way of dealing with complexity is from a position of simplicity.
Figure 4.9 shows how we simplified the logic.
When the chart is simplified, the steps become clearer and more understandable. The logic is also quite concise and easy to follow. Most important of all, the use of decision diamonds and terminal points to mark where we enter and exit this piece of logic suddenly makes life easy for all concerned.