Planning the presentation of your web site is one of the most important things you must do when attempting to create a high-quality site. Proper site planning will save you more time than you can imagine.
From determining your target audience, to sitting down and creating a sketch of how you want your site to look, extensive presentation planning directly correlates to successful web site development.
The question isn't just about what you want to do today, but also what you want to do a month from now maybe even a year from now. Defining what you want out of your site before you even start building it will keep your mind focused and your head clear of distractions. You have probably seen some poorly defined web sites. Many "personal" web sites (as well as many professional ones) tend to present a chaotic and cluttered message. Often these jumbled sites result from lack of proper planning.
The first thing you must decide is what you want your site to accomplish. Whether it's to provide the most up-to-date national news or to provide the latest and greatest in the world of computer video cards, your site needs purpose before structure.
When establishing your site goal(s), define them specifically, but don't inhibit your site's potential by chaining it to goals that focus on minutiae. Saying that your site will be "the biggest and best site about electronics" is not very specific. On the other hand, saying your site will "provide detailed instruction on the planting and care of the picea pungens (blue spruce tree)" might be a bit too specific. You must achieve a balance. An example of a balanced (and therefore better) site goal is to "provide updated news, weather, sports, dining, and other happenings of Salt Lake City, Utah." This goal targets a specific group (residents of Utah specifically, Salt Lake City), but it still retains a broad enough scope to leave room for future possibilities (an example might be adding a tourism section later for potential visitors to the city to review places to go, sites to see, and hotels available with rates charged) in your initial design.
You might want a multitiered goal as well. Instead of attempting to realize a whole vision in one scheme, you might decide to divide it into smaller projects, each adding incrementally to the previous ones. You must consider all these factors during the planning process.
Closely related to your site goals is your target audience. These two things are even interchangeable at times. Sometimes you might identify a specific lifestyle or otherwise-defined group of people you want to attract and then figure out what you need to create for them. In every case, you must determine whom you want to visit your site and who will be visiting your site. A distinct difference exists between the two. Often you will anticipate a particular audience but end up with a completely different one. It would be extremely difficult, perhaps quixotic, to attempt to create a site for every man, woman, and child. Opinions, priorities, and lifestyles vary with characteristics such as gender, race, nationality, wealth, age, occupation, and so forth.
An understanding about who is most likely to visit your site will help you choose how to promote the site as well as decide on the type of advertising (if any) you want. Identification of your target audience also will enable you to create meta tags, which effectively drive traffic to your site. (For more information on meta tags, refer to Chapter 7, "Utilizing Head Content.") Another consideration is the flexibility of your target audience goals. It's all about demographics; choosing the right groups of people to target will maximize your effectiveness and success. This must be flexible as demographics change and so should your target audience goals. A few modifications to your goals, for instance, might double your number of visitors.
Another important factor to consider after you have determined who will come to your site is how they will get there. Whether you're creating a site for a company intranet or a financial advice site, knowing how your visitors will access your site is very important. For instance, many companies use a uniform operating system and browser. In such cases, you might decide to include browser-specific features. Maybe you're creating a web site that offers retirement real estate in Florida. Your target audience might be of the 55 to 70 age group, and you're estimating that most are not up to date on the newest hardware and software. If so, compatibility with older browser versions and slower hardware might be paramount.
Along the same lines, you might opt for a multiversion site. Although this might involve more work, it offers a few distinct advantages. Users with slower systems won't have to watch choppy Flash intros, whereas visitors with screaming systems and DSL connections can enjoy every last ounce of them. An increasing number of wireless web browsers are becoming available as well. Whether they're PDAs or cellular phones, these stripped-down versions of web browsers will certainly gain momentum in the near future. Remember to consider all the things when defining your target audience.
After determining the purpose of your site and the target audience, you should begin to develop possible structuring schemes for the site. At the top of the list should be considerations such as the overall design and layout, as well as the navigation you will provide that enables users to easily go from one area to the next. The following sections discuss these topics in detail.
During the design and layout phase, your creative juices have to flow. You can save a lot of time in the long run by creating a very basic idea or sketch of how you want the site to look and feel. Likewise, a detailed plan now will save you a lot of time and grief later. Such a plan enables you to logically decide on content placement or where the navigation items will best be utilized. During this time, you also can view the site in your mind as a single object, not a collection of various pages. If you create the look and feel before you start adding content, you will most likely maintain consistency throughout your site. If visitors are easily confused by how your site looks, chances are good that they won't hang around long enough to see whether it has valuable content.
The navigational method you choose to implement will be one of the most scrutinized aspects of your site. Whether vocally or subconsciously, each user will rate and remember how easy it was to go from page to page. If the interface that you provide is intuitive, simple, and well organized, you can bet that visitors will stick around a while longer, because they can actually navigate and find what it is they are there for. The alternative is that they get frustrated with obscure navigation systems, leave your site, and generally don't return.
When choosing a navigation structure for your site, remember your own casual web browsing experiences. Your own experiences will help make you aware of many important design issues. You have undoubtedly become frustrated sometimes by poorly formatted content or a hard-to-understand navigation bar. Likewise, you have most likely run across some sites that just amaze you with their simplicity and intuitiveness. In the future, make a mental (or physical) note of such sites for reference and try to determine what made them so easy to navigate. After all, what good is your content if your visitors cannot find it?
Have you ever noticed that you can navigate some sites without actually considering every navigational element? Sites that accomplish this capture the largest audience. Try to make your navigation items as descriptive and inclusive as possible. If users have to figure out your navigation scheme, then it might be too complex or muddled.
When designing a site, you should consider a few other things. The importance of these issues varies from site to site, but to some degree all will definitely be factors in how a site functions and appears.
The two most potentially restricting aspects of creating a web site are money and time. Money will strongly influence the type of technology used, as well as the detail and originality put into the site, and it will possibly dictate how the initial content will be presented to the end user.
Certain technologies such as Flash animations, PHP or other database-driven applications, and custom-written Perl or CGI scripts tend to cost your client more than basic HTML. The use of these features will add to the overhead of your client's site cost. Designers charge not just for the time used to pump out content, but also for the time it takes to create a unique and catchy design for the site. Basic designs or template-based sites obviously cost less than custom-designed ones.
Time is another important consideration and often a constraint as well to assess. If a company asks you to complete a site in two weeks, the length of time allowed for site design will be significantly less than if the same company could wait two months. You might opt for a prebuilt, template-based site for a temporary solution and then create an original site as a second phase. Then again, what if the budget doesn't allow for that type of double-site creation? You will find that the time frame for completion and available finances generally conflict. It's your responsibility to find the happy medium between time and budget constraints.
Project Seven Development (www.projectseven.com) creates extremely effective and professional templates for Dreamweaver. They call them design packs. These include all source HTML, images (PNG, JPG, and GIF), CSS files, as well as detailed instructions in HTML format that are required to create small or large sites. Many times, they also include custom Extensions for Dreamweaver, made specifically to bring that design pack to life. These are especially useful for those who have limited design capability or for clients who want to save on the costs of their site.
After all this planning, you are probably itching to start cranking out page after page of your upcoming masterpiece. That's fine; but where are you going to put these files? You have already figured out how the site should be structured visually; now it's time to think about how you should physically create the directories and files that you'll need.
When you create a site with Dreamweaver, you start by creating a local version of the site on your hard drive. In fact, this is how you should always start a site. First define the local root folder within Dreamweaver, and then create the site itself. Dreamweaver is not designed to maintain local sites that aren't on your local machine or mapped network drive, so you must have a local copy. This is called a local site, and it should have the exact same file and directory hierarchy as the public or remote site. Keeping them the same will make it easier for you and others to understand. In fact, doing this will prevent major problems with future site maintenance. It also will enable you to utilize some of Dreamweaver's site-management features, such as tracking links and the Synchronize command. This, of course, has been said tongue in cheek. There is not always a requirement to have the local and remote site exactly the same, and there are situations when you shouldn't have them the same. For instance, if you are a lone developer, do not upload your _notes, Templates, or Library folders (doing so could allow people to steal your source files if they find them), but if you are collaborating with someone in another city, then you might have to upload these referenced source files so that the job can be completed. It can be said that the cgi-bin folder does not need to reside on your local machine, but it is better to have duplication that can be used as a backup than not have it at all and have to start from scratch when your server or local hard drive dies.
Maintaining a copy of the live site locally not only makes it easier to work with in Dreamweaver, but also provides a level of data redundancy. If the live site should become corrupt or experience data loss for some reason, you can always just upload the local site again.
You also can store your local copy on a floppy disk (if there's enough space), a Zip disk, or some other form of rewritable storage medium besides your hard drive. The only possible problem with using removable media is its tendency to become corrupted. If you insist on using this method of local site storage, it's strongly recommended that you back up your data on another medium as well.
Identify the rough number and type of files that you will use in each logical section of the site. You can then begin to determine how they should be organized and separated into subdirectories for easy navigation from the back end. You want to create logical sections, which means that you want to group files together that logically belong in the same directories. Usually this will be very intuitive and shouldn't take much time.
As an example, the National Basketball Association's web site (www.nba.com) divides each team's pages into its own directory. This makes perfect sense. If you need to change information for the Indiana Pacers, you know that every file specifically relating to the team is in the pacers subdirectory. See Figure 21.1.
While you think through this process, keep in mind that browsers keep a copy of every graphic they download. This is called the browser cache, and if you plan ahead, you can utilize this feature to help your pages load faster. By using the same background image source or reusing the navigation bar images as much as possible, the browser will have to download them only once. On additional page views in the same session (sometimes future sessions as well), the browser will load the cached files instead of downloading them again from your server. This typically means faster load times and less bandwidth usage on both the server and the client side, both of which are very good things.
After you have categorized the logical grouping of your files, you should think about how to further define differences. If your site is large enough, you might want to keep all your images and media files in a place separate from your HTML documents. You also might further divide your media content, such as your SWF or PDF files. Whether you need to do this depends greatly on the size of the site in question. However, doing this will enable you to quickly navigate to the correct file when creating links in your HTML. If you need to edit or replace an image, you'll know its exact location and can avoid wading through a mess of file types.
This is the basic reason computers use a hierarchy of directories to organize data. You "can group a broad subject into a directory and then make additional groupings more specific. These specific directories are children of the main directory and are called sub-directories. Figure 21.2 shows a potential site directory structure.
Write down possible directory combinations for your project. You might think that this point seems trivial to the success of your site, but I guarantee that you will save an incredible amount of time by following this simple procedure. After you have managed your site for a while, understanding directories and hierarchies will become much more natural and intuitive. As a result, you'll greatly reduce the time needed for this portion of site development.
Before turning to how to set up your site information in Dreamweaver, it's important to emphasize one more point. If you have all the images and other media type content of your site finished before you begin writing the actual HTML, you will find that the document creation process (the process of putting your design and layout into HTML format) will flow much more smoothly. Likewise, creating a basic "shell" or blank document to act as a placeholder for the final version is advantageous. This enables you to establish any internal links at any time, without having to create a new document. When you're working as a team of designers, this might be difficult; but it is highly recommended that, when possible, you create all your images and pages before starting the HTML production.
Business Name: DreamweaverFAQ.com
What made you decide to start web developing?
I wasn't expecting to become a web developer. It just sort of turned out that way. I was a new mom, and needed to find a way to stay at home with my baby while still earning an income. Shortly before getting pregnant, I'd started a small business selling invitations for special occasions. I was persuaded by family to take that business online. Clueless, I sought out to build my first web site.
The first few times I used Dreamweaver in September 2001, I was completely lost. With nobody to help me, I searched online. I soon found the Macromedia Dreamweaver Newsgroup and my learning process began. I read every post, even though nothing made any sense at the time. I knew I might need it later. I bought a few books and started learning new things. Then about two months later, I attended a conference in Monterey, California. I learned so much in those two days, and I met some great people. Without the support of the newsgroup community, I'd probably have given up.
I built my first web site and was hooked! I knew web development was the way to go. What I didn't realize was how hooked I would get on Dreamweaver itself. Now, I find I spend most of my working hours maintaining DreamweaverFAQ.com, writing tutorials and help files for commercial extensions, and anything else Dreamweaver related that I can.
What is your claim to fame?
I'm not famous! People probably know me best from my involvement in the Macromedia Dreamweaver newsgroup community as a Team Macromedia volunteer. From that involvement, I saw a need for a web site that covered basic and frequently asked questions on the newsgroup. I bought the DreamweaverFAQ.com domain in January 2001, with no intention of using it for at least a year, as I still very much considered myself a "newbie." (Remember, I'd only been working with Dreamweaver seriously since I returned from the conference in November.)
In late March 2001, I started posting to the newsgroup a daily list of questions, answers, and cool resources that I developed with the help of Kindler Chase. As time progressed, we saw a need to put up a web site to host an online version of the list. Kindler gave me some server space at his domain, and we hosted it there temporarily. Unfortunately, Kindler was unable to pursue the site with me as he was already committed to his love of professional cycling. Throughout May and June, I worked on planning, gathering content for, and developing the permanent site: DreamweaverFAQ.com.
Daniel Short, whom I'd met at Monterey, and I began to talk more and more, offered me free server space for the new domain. His helpfulness didn't end there; he got involved and spent countless hours helping me prepare. He built all the ASP functionality into the site including the Style Changer, Font Changer, Snippets Exchange, and all the while had enough patience to teach me along the way. I can't thank Dan enough for all he's done for me; he's like a brother to me.
On June 27, 2001 DreamweaverFAQ.com (a.k.a. DWfaq.com) was launched with three main sections: FAQs, Tutorials, and Resources. The site began with contributions of tutorials from a dozen members of the newsgroup community, each with their very own style (color scheme). Since then, many more tutorial authors [have been added], and the site itself has expanded tremendously.
Over the last year, DWfaq has become practically a full-time job for me, and I wouldn't have it any other way! So, I suppose you could call it my "claim to fame," but I couldn't have gotten there without all the help and generosity I've received over the last year.
I am confident that my involvement with DWfaq and the support of those who have helped me has led me to my most recent accomplishments as the lead technical editor for Dreamweaver MX Bible (Wiley Publishing), contributing author to Dreamweaver MX Magic (New Riders), and contributing author to ColdFusion MX Web Application Construction Kit (Macromedia Press).
What are your thoughts on site planning? Did you plan your site or develop it on-the-fly?
When I built DreamweaverFAQ, I spent a lot of time deciding on the structure of the site. I knew I wanted to break it down into categories and subcategories that would make complete sense to the user. I started off with a pencil and a paper and did a flow chart. I had the home page and the top level, of course. Tutorials, FAQs, Resources, and Help were my second levels. I then broke my second levels down into more specific topics. It's a very simple site structure that makes a lot of sense for users and is great when adding "breadcrumb trail" navigation.
For the most part, I always plan a site in the same way that I described. Sometimes, there is an element of "developing on-the-fly," but the core structure is always established first.
One of the most important things for me when developing a site is keeping naming conventions and folder structure intuitive and organized. If ever the site gets to be what I feel is sloppy, I take advantage of Dreamweaver's Site panel and move files and folders from there so that all links to moved files are corrected automatically for me. It saves a ton of time being organized when you're managing larger sites. I've been known to say many times, that I get annoyed browsing for files because it wastes so much time. An organized Site panel makes things just so much faster and easier.
Did you allow for expansion, or was that an afterthought?
The structure of DreamweaverFAQ is so simple that there is always room for expansion, although there are some limitations to the design. When I developed the design, I knew that there was room for a couple more categories on the navigation bar. What I didn't expect was that we'd eventually run out of room. I didn't foresee that there could be so many main categories! I planned for it to some degree, but as design limitations crept upon me, I had to re-arrange things and adapt for those limitations.
The great thing about it is, with such a solid and organized structure in place, I can easily change the layout of the site (when the time comes) without disrupting any of the functionality. Header and footer information are stored in Server-Side Includes, thus allowing me to completely change the look of the site or navigation elements by updating only two files on the server.
Would you recommend people spend time planning prior to development?
Absolutely! It will eventually come to a point where you will develop your own way of organizing a site and using the same naming conventions. For example, I always have a 1x1 transparent GIF file in my images folder named shim.gif in every site. I always name my main CSS file master.css.
The more you plan and organize before you begin, the better off you'll be down the road. Of course, you can plan as you go along, but there can be a danger in that if you don't plan ahead you can run into issues that will slow production. Knowing what you need to get the job done before you begin is very important. If you like to plan as you go along, at least have a good idea of the bigger picture while doing so, [to] be able to move along smoothly.
The final thing you really should consider when beginning a project is how people will be able to access the site when it's done. Deciding on the best web host is never an easy thing. The following system is a solid foundation to help determine which host best fulfils your needs and budget:
Determine the site's requirements. (Is the site going to be built using a server-side language? Do you need database services? How many email addresses will the client require? How much space and bandwidth do you think the site will require? Will the site require immediate e-commerce or not, or possibly in the future?)
Find several web hosts that meet these requirements.
Weed out the companies that don't give extensive information in their plan details. Depending on the number of hosts at this point, you also might throw away those that just don't "feel right."
Visit various newsgroups and online forums. Ask people about any negative or positive experiences with the hosts in your list. Bad experiences help you know which hosts to eliminate. By the same token, asking (and receiving) positive responses might help you rank those that remain.
After narrowing the list to a few companies, try to determine which might best accommodate future needs.
The following sections discuss in detail some of the more important aspects of picking the best web host.
Although this might seem obvious, many people sign up with a web host, only to find out the host doesn't support everything they need. From a developer's viewpoint, sometimes some "extra" settings on the server side seem default. Remember this isn't always the case. If your site requires anything beyond basic services, be sure the host supports such requirements. Some common site requirements include the following:
Server-side scripting languages such as PHP, ASP, ColdFusion, JSP, and so on.
Database support including Oracle, MySQL, MS Access, MS SQL Server 2000, mSQL, and so on.
Most e-commerce packages.
Email Although some clients opt to run their own email services, many will not.
SSI (server-side includes).
Server space and bandwidth allotted.
You might think some of the features in this list should be considered "basic" and included by default. Many times they are; however, some hosts will undoubtedly neglect to offer at least a few of these services.
Sometimes I don't know everything a site is going to need until I start working on it. In such cases, I find it effective to write down each requirement as I work on that part of the site. That way I'm sure to get everything I need.
After you have determined what your site needs to function properly, you can begin the relentless search for a host. Several available resources can help you with this. Search engines will return hundreds or thousands of individual companies. You also can find web sites dedicated to listing many hosting companies. One such web site is TopHosts.com (www.tophosts.com). They list companies located all over, including the United States, Canada, and the United Kingdom.
Sites such as TopHosts.com are good resources primarily because they provide similar information about several providers in a compact space. This enables you to easily compare pricing and features.
After you have compiled a list of companies that meet your needs, you might want to see which ones provide additional services, such as the following:
Phone support (preferably 24 hours)
Excellent email support
Database access (MySQL, PostgreSQL, SQL Server 2000, mSQL, and so on)
Domain redirects (pointing additional domains to subdirectories on the same account)
Comprehensive online FAQs
Easy site/user management
Online and/or automatic billing
Bandwidth speed and capacity
Reliability and uptime
Web-based email access
Remember that a good web host for your site probably doesn't need all of these features; most would go unused. That said, always ask for proof of a provider's uptime history. If it's relatively shaky, drop that host from consideration immediately!
A common mistake is underestimating the growth of a site. This especially holds true when databases are used to store various site and user information. Make sure the potential web hosts provide for future expandability at a reasonable cost. It is a pain in the neck to change providers after you have everything up and running. Consider the following elements and how much of each your site might require in the future:
Monthly transfer in gigabytes (GB)
Disk storage in megabytes (MB)
Number and size of any databases
Future email needs
Although this list is not exhaustive, considering these items will definitely reduce the chance that your site outgrows the web host.
By now, you have all the knowledge necessary to make an informed decision abut where your site should be hosted. As a final cautionary measure, Table 21.1 shows some possible pitfalls (and solutions) you might run across in your search. Good luck!
Noticeably low prices
The provider might be significantly overselling its bandwidth or have limited/ cheap access to the Internet.
Check with the provider to confirm its average bandwidth utilization. Also be sure to find out what type of access the provider has outside of its network.
Vague features listing
This might point toward a provider who is actually just a "reseller" for a larger host. It also might show that its services are geared toward "basic" account types.
Email or call the provider to clarify any confusion. Also consider just dropping that host from consideration.
Lack of phone numbers
This could indicate a "halfhearted" hosting attempt, especially by a reseller. The host might just want to make a quick buck.
Look for phone numbers. Email the service department and see how quickly you get a response. Sometimes hosts might rely more heavily on email-based support to track issues. If the reply time is within a few hours, the host is probably okay.
Windows 2000 or UNIX/Linux (but not both)
This host might be extremely new or inexperienced in anything except the platform it provides.
On the same note, the host might intentionally specialize on one operating system for a purpose. This should not be an issue in most cases; if it is, however, drop the host.
A final word on web hosting: If (or when) you decide to change hosts, be sure to maintain the old account for four to seven days after changing the service to the new host. Some DNS servers require significant time to update. Having a four to seven day overlap will ensure uninterrupted access for everyone.
This chapter focused on three main areas of site development: presentation, organization (both on the user and server side), and finding a proper web host.
By now you should be aware of issues such as who your target (and real) audience is and the need to plan for various viewing methods. You also learned in this chapter about general attributes that make site navigation effective. This chapter also discussed the importance of organizing your files on the server in a logical manner. You learned in this chapter about site requirements to keep in mind while searching for a company to host your new web site. And you now know how to compare hosts and how to avoid common mistakes.
The following list summarizes the topics covered in the remaining chapters in this section:
Chapter 22, "Local Site Management." This chapter discusses how to define and use your local site. File and link management are discussed as well. This chapter also discusses the Assets panel.
Chapter 23, "Site Publishing and Maintenance." This chapter discusses the inner workings of remote site setup, and how to work with the remote site. You also learn how to keep your local and remote site synchronized through Dreamweaver.
Chapter 24, "Workplace Collaboration." This chapter discusses some of the challenges of working as a team (and also poses possible solutions). The Check In/Out system, as well as other server-based version control systems, is covered. You also learn how to create reports in Dreamweaver that increase productivity and efficiency.
Chapter 25, "Templates and Libraries." This chapter discusses how to create and manage somewhat dynamic content using Dreamweaver Templates and Library items. Server-side includes are discussed as well.