Planning a Dynamic Site with Macromedia Studio MX 2004
This will inevitably happen to you.
You are sitting at your desk, and the phone rings. When you answer it, the individual, from the Oakbridge Recreation Center, will start a conversation that goes something like this:
"Do you build web sites?"
Your answer is, "Of course," and then you talk about the work you have done for other clients.
"Here's what we need," says the voice on the phone. "We need to rethink our site and are looking at adding a couple of features that cement our relationship with the community. They would include an interactive tour of the facility based on interest. We would also like to streamline our current facility booking procedures and enable people to book sports facilities or meeting rooms online. Finally, we do a lot of community work and want to create something on the site that enables people to meet online...or something like that. Do you do that sort of thing?"
This is typically the start of the process, and a positive answer will result in a client meeting. The project's success or failure is dependent upon what you do next.
In the good old days of the Wild, Wild Web, up to about 1998, the answer was a resounding, "Yes." In those days, the developer met with the client, got a rough idea of what was needed, and gave the client a rough idea of what he or she was going to do. The client, not having a clue what the developer's proposal entailed, inevitably bought in because it sure sounded "cool." At that point, the developer bought the necessary software and spent the next month learning how to do what he or she had just promised the client.
With the rise of dynamic sites and the introduction of the work group and some pretty sophisticated software, the technical and creative demands placed upon web developers have increased. This means the day of the "One-Guy-Does-It-All" shop is a thing of the past. In today's production environment, speed and accuracy are critical. This means projects can only be completed by a team of specialists working with a carefully crafted production and project plan.
The old business adage, "Plan your work and work your plan," is more appropriate than ever. More often than not, that means the production cycle doesn't start with pixels lighting up on a screen. It starts with a sheet of paper.
Want vs. Need
When talking to the client, a key skill to have is the ability to distinguish between a "want" and a "need." All too often, clients and developers get caught up in the technology and the software when they start discussing the project. A huge number of Flash MX 2004 sites out there could have been done more easily in Dreamweaver MX 2004. Why Flash? The client, discovering how cool it is to have a Flash site, decides they want one.
The problem here is technology is constantly changing and can't be fixed in place. A great example is the MX Studio. In April of 2002, we were all using individual Macromedia products. Six months later, they were completely reinvented as the MX Studio of integrated products that also included a developer edition of ColdFusion MX. Director developers planning a number of projects around the Multi-user server discovered, with the release of Director MX in late 2002, that the Flash Communication server replaced the Multi-user server. A valid question, therefore, is, "How long will the online meeting facility be available through the site, and will it be able to adapt to changing technologies?"
In the case of our community center, they want an online meeting room. This room will be used by members of the clubs or other associations based in the community center to get together online to discuss plans, events, and so on. It should have a shelf-life of at least two to three years, which means the enabling technologiesColdFusion and Flashwill most likely change, but the upgrades and changes are easy to effect. Then again, there is an even more fundamental question that should be asked.
The question is, do they need such a facility? Ask that question of both yourselves and the client, and the production process takes on an entirely new dimension.
Defining Exactly What Is Needed
The last thing a web developer needs is the client changing his or her mind mid-project. This situation usually results from the clients' discovery that the project is moving in a direction they never expected. Even worse is the client discovering they have a technologically-advanced site their market either can't or doesn't use.
In the case of the Oakbridge Community Center asking for an online meeting room, it is interesting, but do they need it?
In this situation, it is incumbent upon the developer to break out a pad of paper, meet with the client, and start doing some very careful fact-finding. The questions that could be asked are:
Have your clients expressed a need for this?
What sort of market do you serve?
Do you have any idea about what kind of connection they have to the Internet? Broadband or dial-up?
Are they technologically sophisticated enough to use video cameras connected to their computers?
Does your ISP have the necessary software to accommodate dynamic data transfer?
The key here is discovering whether a full-bore interactive area with streaming video, audio, and chat is needed, or whether the client would be better served with an instant messaging feature.
Never forget, your client is rarely as technologically adept as you are. Thus, your role is twofold: web developer and educator. You will be building the site but also translating the technology to the client and presenting it in terms he or she understands. If the client needs instant messaging, recommend it. Although instant messaging isn't as "cool" as a Chat Room built in Flash, you will have saved your client a serious amount of money that would have been spent on unnecessary technology.
Developing the Project Scope
When you understand what is needed, there is an understandable urge to start up the computer and get to work. This would be a huge mistake. The only software you will need at this point is word processing software. It is used to produce a document that lays out the parameters of the project, including items such as a budget, deadlines, a creative brief, and a technical specification. This is called the project scope. It should be regarded as a deliverable for the client to sign and date.
By producing this document and having the client sign and date it, you and the client reach an agreement regarding exactly what is to be produced, by when, and at what cost. In this manner, you avoid scope creep.
To avoid this potential messiness, create the aforementioned written document and include the fact that changes, additions, or deletions through such things as cancellation penalty clauses in contracts will incur extra charges. Some agencies go as far as setting a limit for these charges, at which time they will actually stop work and renegotiate a new agreement with the client.
Identifying the Technologies
There are a number of technologies that can be utilized in the building of a dynamic site. This book's topic suggests you already own Studio MX 2004. This means you have a serious number of very powerful tools available to you. From Dreamweaver MX 2004 to ColdFusion MX, your production needs are met. Still, the decision regarding which technology to use to meet the needs of the client requires some serious consideration and trade-offs.
The way we chose MySQL as the database for this book is a good example of the considerations and trade-offs you will have to make.
When we first considered producing this book, we assumed we would be using Microsoft Access as our database of choice. We had used it in our previous bookBuilding Web Sites with Macromedia Studio MXand we just assumed we would stay with it. The reasons were valid:
Microsoft Access is easy to use.
It is widely available because it is bundled in the Microsoft Office Suite.
ColdFusion can quickly "plug into" it.
The times have changed between our first book and this one. When we started looking at the marketour beloved readerswe came to the conclusion that Microsoft Access was not a suitable choice. For example:
Microsoft Access is only available on the PC. Even then, not everyone owns it. The likelihood of someone purchasing it just for the sake of following the exercises within this book is rather slim.
ColdFusion MX is widely available on many platforms. Mac OS X, as well as various J2EE platforms, can work with ColdFusion MX.
ISPs accommodate MySQL. Our site's host, NI Solutions in Toronto, offers MySQL in addition to the package of technologies available to us and, by association, to you. However, Access was not mentioned as part of their packages offered alongside ColdFusion.
When you ask those questions, the number of technology options tends to narrow to one choice. That choice is MySQL. Here's why:
It is freely available under the GNU General Public Licensing. This simply means that it is free for regular users as long they don't need to incorporate it in a commercial application. Go to http://www.mysql.com/downloads/index.html and download and install MySQL Public release 4.0 for your operating system. Mac OS X users can also download a complete installer from http://www.aaronfaby.com/, which also contains a System Preferences panel to control the MySQL daemon.
Various GUI (Graphic User Interface) MySQL management tools are available. There are a number of them out there, but for the purposes of this book, we have decided to go with YourSQL by Magister Ludi (http://www.mludi.net/YourSQL/) for Mac OS X. PC users can use http://www.mysql.com/downloads/mysqlcc.html. If all else fails, you can use the widely popular phpMyAdmin, available at http://phpmyadmin.sourceforge.net available on almost all platforms. Just remember that you would need to download and install PHP for this.
Connecting to MySQL through ColdFusion MX is done using a JDBC connection. ColdFusion 5 supports ODBC and thus connection strings. Macromedia dropped ODBC in the jump to Cold Fusion 6. That means the only way to connect ColdFusion MX to a database is through a datasource name.
Dreamweaver MX 2004 Server Behaviors write SQL queries that are understood by all SQL-compliant databases. Thus, anything we do with MySQL here can most likely be used on Microsoft Access.