What should one consider when creating a dynamic web site? Macromedia helps us answer this question using one of their own products, Dreamweaver MX.
When you decide to make your site dynamic, you have a lot of things to think about, and thinking about them before you create your new site determines whether it is a success or failure. This article overview applies to web developers of all levels who are considering turning their websites dynamic.
Why Move to Dynamic Web Pages?
Since you update fewer pages in a dynamic site, you have fewer opportunities to introduce mistakes; every time you touch your files, you introduce the possibility of changing something unintentionally.
Retrieving content from a database with a SQL statement causes fewer problems than retrieving the data manually from a database. A dynamic site keeps content fresher. Updating static HTML pages across a site is not difficult, but it is a specific talent and it is time consuming. If you need to keep your site fresh with new news, however, it is easier to insert that content in a database than to change each page manually.
With a dynamic site, once a page is live, you can change its content easily. If you were updating a static page, however, an HTML professional would have to download the page to a local machine, edit it, and then re-post it. In a dynamic site, the document originator simply goes to a web page, selects the record with the error, and changes it. The next time any user accesses the page, the change is in effect. There is no need to coordinate teams or download and upload files. And best of all, it reduces the number of hands touching the page, which reduces the chance of unintentional changes or problems.
Of course, dynamic sites also create opportunities for e-commerce and e-business. The most obvious benefit of a dynamic site is that you can add e-commerce functionality to your site, such as a shopping cart, auctions, business-to-consumers and business-to-business resources such as threaded discussions, indices, or searches. Once your content is in a database, you can do anything you like with it, and your offerings can grow without having to rip up your whole site.
Once you decide you want to make your site dynamic, you have a lot of research to do. Here are some issues to consider when you decide to make your websites dynamic:
Planning for your needs ahead of time
Picking a database
Choosing an application server
Organizing workflow, processes and your team
Testing and production
Planning the architectural design of the website or application
Planning for your Needs Ahead of Time
Survey your customers and prospective customers. Know what your customer is doing on your site, not what they say they are doing. To find out what your users are doing, watch them. Be prepared to invite users to your facility or go to their location. Invite users that like your site and those who have complained about your site. Also, watch users of your competitor’s sites. Assign the users tasks—for instance, 10-15 simple tasks, such as finding a particular product, finding a place to mail a comment, finding a phone number of someone that will answer a question, finding a location, and searching for a name or article.
What do they like? What do they dislike? Why and how can you change that? What do they spend time on? Would a particular page be ideal for putting related products, advertisements, or special announcements? What pages do they go back to, over and over? What pages do they never visit? (An unvisited page might hold information they need to decide on a purchase. In this case, knowing this information can help you give higher exposure to that particular page or section of the site.)
Another way to find out what a users like is to ask them to take a survey. To increase the amount of submitted surveys for an accurate sample, give the survey responders a gift.
Evaluate the information you collect and think about implementing it in your development plan before making any other decision. Once you know what your customer does on your site and what they want to do on your site, you are ready to take the next step.
How much data do you want to publish? How many users will access the site and how many concurrent users will you have? This determines whether you need an e-commerce solution.
Now that you can estimate how robust your system needs to be and how busy it is going to be, you can start planning your service.
First, are you going to host the site yourself onsite or offsite at an ISP? If you plan to host it yourself, you must provide backups and monitor security. You must also buy hardware and software. You must have redundant systems in case one or some of your servers fail. You will need to have a high bandwidth connection to the Internet. These are big expenses and require staff to set up and manage. If you decide to host with an ISP, however, then you pay them to perform the tasks listed above. This costs more initially, but saves you costs in staff. With an ISP, you pay professionals, so you will not have to train staff how to install and maintain your systems.
Once you know where you would like to place the site, think about what database to use.
Picking a Database
If you are going to have a low volume site and you are developing the site and database yourself, Microsoft Access and FileMaker are the two most popular choices. Both databases are easy to use and both have a large amount of aftermarket books written about them. If you use Microsoft Access, you can use any of the dynamic server languages, such as ColdFusion, ASP, ASP.NET, JSP or PHP. If you use FileMaker, look at Lasso, from Blueworld; you can develop on either a Macintosh or a Windows machine.
If you have a higher volume site and can do more technical work—or if your ISP supports it, you might use MySQL, which is very popular and quite powerful.
In addition to selecting a database, you must learn structured query language(SQL) to select, update and delete information in the database. I recommend Teach Yourself SQL in 10 Minutes by Ben Forta and published by Sams Publishers. Luckily, using SQL is easy.
Finally, become familiar with creating and designing databases. This is a skill set that you will develop over time. However, it is important to realize that a well-researched database schema contributes to better application performance. Research your problem and apply that research in a solid data model. Research entity-relationship modeling; database normalization; and conceptual, logical, and physical database design to start with.
Choosing an Application Server
Once you have chosen the database, you can select a server language and application server platform, which is the component that serves the dynamic pages. I covered the selection of server languages in a previous column, so I will not do so again here other than to say Macromedia ColdFusion MX is an excellent choice that is easier to learn than the others. ASP is everywhere, and you will have no problem finding a host that supports it. ColdFusion MX, ASP.NET and JSP/Java 2 Enterprise Edition (J2EE) are ideal language options on the enterprise and mid-range enterprise level. PHP is the fastest growing server model.
If you decide to use JSP, you must also choose the application server. The Macromedia J2EE server, JRun 4, is a good choice, as is ColdFusion MX for J2EE (ColdFusion MX is now available on the J2EE platform) as well. There are also free servers like Tomcat for Apache, and high-end servers such as BEA WebLogic, Sun-Netscape iPlanet, Oracle OAI, Borland, Unify, SilverStream, and ATG. Again, select your application server based on your site's traffic volume and the needs of your business or client.
Now you are ready to create your site.
Organizing Workflow, Processes and your Team
When you create your site, first establish a workflow for your team. Keep it as simple as you can because teams are not likely to adhere to complex workflows. Once you create the workflow, be prepared to change it, but never violate it.
That is, if you find that there is a situation that your process does not cover, change the process, notify everyone that the process has been changed, and get their consensus. Do not simply solve the problem without updating the workflow. This prevents you from having to reinvent a process for fixing the same problem. Keep accountability for your development work. If there are problems, it is costly to fix problems that are not well documented.
To set up a workflow in your team, ensure that you set up regular intervals to check your work and confirm it with your customer. Taking the time to monitor and check in with your customer prevents problems. Fixing problems earlier costs a lot less than if you wait. Since workflow, processes and organization of the team is a big topic, I recommend that you study the project management section of the Macromedia site for an overview.
Testing and Production
Create your servers and sites locally and on a staging server. You should be able to test the site as you work. On the staging server, a QA professional who is not part of the day-to-day site creation should review your site. He or she is more likely to catch problems or to try to access invalid information or choices than the developers. Test the site on a number of operating system platforms and browsers.
Using a staging server is very important. As your team grows, they should not have direct access to the production server that is serving your site to the public. For instance, if someone on your team were to make a small mistake on an index page then upload it, it could knock your whole site out. If the web development team posts files to the staging server and then tests the page, you can catch problems before they go live. You may also want to look into file and code versioning software, such as Perforce to prevent developers from overwriting each other's work.
Once your workflow and servers are set up, prototype your site. Create it quickly on a machine, or mock it up on paper or index cards. Present the mock-up to as many users as you can and ask them to perform the same tasks you asked them to do in the beginning of this article, when you isolated the issues you were going to work on. If you discover flaws in the site structure, you can fix them before site production.
Once you finish your prototype, refine it to templates and create a data flow. Run one more set of tests in-house with the tasks requested previously.
Assuming it all works, you are now ready to publish your site from the staging server to the production server. And you're ready to begin planning your first revision.
Once your customers or your client's customers work with the site, they are going to find a number of things to change. Be prepared and budget time and money for the revision.
Planning the Architectural Design of the Website or Application
Once you have some initial coding under your belt, look into best practices and how to architect dynamic web sites. While this is a more advanced topic, it is worth mentioning here. A common problem developers have in the dynamic realm is creating what programmers call spaghetti code—code that is not well organized, hard to read, and susceptible to bugs. To avoid spaghetti code, learn about design patterns and application architecture. Luckily, the Macromedia DevNet has an architecture topic page that can help you learn about best coding practices.
Congratulations, you are now dynamic.
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.