skb875 of PixelForLife Video Tuts recently suggested on Twitter that I write an article about how to organize website files and folders. I suspect he asked not because he doesn’t know how to organize a site (after all the basics are pretty simple – arrange things so you can find them later) but because – like most of us – he just doesn’t always take the time to do it.

The logical first step in building a website is to create a flow chart of navigation through the site. This is critical not only because navigation is one of the most important features of your site but also because it will help you organize the site’s content and create a logical file/folder structure that will make your site easy to manage as the number of pages begins to grow.

Consider the example of a simple portfolio site for a designer that contains:

• A home page
• Biography
• Awards section
• Print Design Portfolio
• Web Design Portfolio
• 3D Design Portfolio
• Contact information and form

Of course this list will probably grow as content for the site is developed (and certainly as the designer’s career prospers) but this is a good start. The navigation flow chart for the site appears in figure 1.

Figure 1: Flow chart of navigation for a designer’s portfolio site.

The flow chart offers a logical navigation scheme for the site that can easily be translated into an unordered list and styled into a menu using CSS as shown in figure 2.

Figure 2: The navigation menu as an unordered list and a CSS menu.

The flowchart can also be used as an outline for the file/directory structure of the site.  The concept is simple. Each layer of the navigation represents a folder and each navigation item with a submenu becomes a folder as shown in figure 3.

Figure 3: The site’s file/folder structure.

Establishing this structure at the beginning of the site design/development process will prove helpful as the site evolves and grows. It’s a relatively simple process to determine where a new page fits in the existing structure, how it should be linked into the navigation and where the file should be saved. Of course, if our designer branches out into Fine Art, we may find ourselves adding a new folder in the portfolio folder or possibly even in the root folder.

So far, so good, but the current site structure leaves out some important files that can contribute to website clutter: image, JavaScript, CSS and other support files. In other words, all the files that Dreamweaver labels “dependent files” when you upload a page.

The simple answer is to add “images” and “support” folders to your root folder as in figure 4.

Figure 4: The site’s file/folder structure with images and support folders added.

Dreamweaver Tip: You can set the location of your images folder in the Local info category when you define/set up your site in Dreamweaver. Then, if you insert an image from outside your site, Dreamweaver will offer to save it to your images folder.

You can also set the location where Dreamweaver saves your Spry-related files in the Spry category of the Site Defintion/Setup dialog. The default is a SpryAssets folder that will be created the first time you add a Spry feature to a page. But you can change that (to say the support folder) if you prefer.

For sites containing lots of images (as our portfolio site undoubtedly will) the images folder can quickly become overwhelming. For those sites I recommend multiple images folders. Figure 5 offers a couple of possible solutions.

Figure 5: The site with supplemental images folders added.

• An images folder inside the portfolio folder to be used only for portfolio images. The design graphics and other images from the site would still be saved in the images folder in the root folder.
• If further structure is needed or preferred, an images folder for each section of the portfolio (shown as semitransparent folders in figure 5) an be created.

You might also want to consider some other organizational scheme such as adding images to folders named according to the month or year they are added to the site. Whatever your system, the goal is to create a file/folder that is as easy to navigate as your website.

Dreamweaver Tip: Dreamweaver reserves the folder name “Templates” for (obviously enough) templates. So Dreamweaver users should avoid naming a folder Templates and avoid saving any other files in the Templates folder.

That takes care of the site structure but one important issue remains. I strongly recommend you avoid saving files that are not a part of your site within your root folder. The most common culprits here are Photoshop and text files. You should save these files in a resources folder outside your root folder. I generally just add “-resources” to the site name when creating my resources folder. So, for example, for DWcourse.com, my root folder is DWcourse and my resources folder DWcourse-resources.

Final Tip: Once you’ve uploaded your site you automatically have a backup of your root folder (one copy on your local computer and one on the server). Since you won’t be uploading your resources folder, you’ll want to make sure you create a backup of those files somewhere else.

That’s the scheme I use (when I take the time to do it right). If you have your own system or have comments or suggestions about mine, I’d love to hear them. And if you have a Dreamweaver related topic you’d like me to cover in a future post, you can drop me a comment here or on Twitter:

Update: Adding another bugs, this one involving the Spry Assets folder.

1. It appears that Mac users with hard drives with a name that includes a space may be subject to an error (Spry Assets folder is not in the local site folder – even though it is) when they try to set up their sites. The “solution” appears to be to rename their hard drive which of course can mess up a lot of other things (including other site definitions). Here’s a discussion on the Adobe forum: http://forums.adobe.com/message/3053791#3053791

1. Double+clicking a style in the CSS Styles palette (sometimes) causes the style names to disappear. Double clicking again in the same spot opens the style editor (Mac). I haven’t yet been able to duplicate issue #1 on a PC (and I’m afraid, if it’s Mac-only, I’ll have to wait a very long time for Adobe to deal with it).

2. If you create a page from a template that has an editable region behind a non-editable div with the CSS overflow property set to auto or hidden, there is no way to select the text of the editable region. Pages from the same template work fine in CS4 and (here’s the kicker) in CS5 the page begins working correctly if you detach it from the template, select the text and then undo to reapply the template??? (Mac and PC)

UPDATE 8/9/2010: Thanks to Frances de Wall for the work-around for this issue (see discussion in the comments below). You need to attach a Design Time Style Sheet to the template with this CSS rule:

* {
   overflow: visible !important;
}


You can find more information on this issue on the Adobe forum.

Let me know if you discover other issues.

Hi, my name is Jim and I’m a CSS’oholic.

I remember my first floated div. It was heaven. Soon I escalated to CSS rollovers buttons and list-based menus. I was on top of the world!

And then, the downward spiral began. Before I realized what was happening, I found myself watching the sun come up over the lonely back alleys off the information superhighway as I hunted for one more CSS fix that would finally get my pixels aligned.

And then a friend took me to a CSS Anonymous meeting. I was skeptical at first but, thanks, to CA I’m on the road to recovery. Sure, I still face the occasional dawn with a mouse in one hand and an empty can of Red Bull in the other. I know I’ll always be a CSS’oholic but with the help of the 12 Step CSS Anonymous program at least I’m getting more sleep.

12 Steps to Conquering CSS’aholism

When faced with an impossible deadline and uncooperative CSS.

1. Just say “NO!”  Why waste time making your page look perfect in Explorer 6? If the user cared what your pages look like, he wouldn’t be using IE6.  
2. Back up: Now. And now! And NOW! When you stretch the limits of your CSS knowledge, the code will probably break before you do. When that happens a backup means you’ve only wasted time not trashed your site.
3. Search: OK, I know Google is probably the first place you turn when faced with a CSS issue but do you use it effectively? Here are few suggestions:
   • Construct your query carefully: You’ll get better results and the very process of refining your query may lead to the solution.
   • Focus on newer results: Web design has come along way in a very short time. By limiting your results to the last year you can eliminate a lot of once good advice that’s gone bad.
   • Bookmark sites that come up regularly: There’s a reason you keep stumbling across sites like W3.org and W3schools.com.
4. Exploit forums: Online forums are full of CSS enablers. I try to be active in forums where the people are knowledgeable and help and usually, when I need help, it’s offered.
5. Tweet: It seems crazy to think you can get the answer to a complex question in the 140 characters Twitter allows but:
   • Distilling your issue into a question of 140 characters helps you focus on the real problem.
   • You don’t need THE answer; you just need the idea that leads to it.
     Of course, if you’re not active on Twitter, when you desperately need help probably isn’t the time to get started.
6. Take a time out: What works for kids, works for adults. A brief break can help you approach the problem from a fresh perspective.
7. Compare your code to code that works: If you’re customizing standard code (like Dreamweaver’s built-in Spry) invest in software such as BBedit (Mac) or TextWrangler (PC) that allows you to compare your copy of a document to a virgin, working copy. Then you’ll only need to worry about the code you know has changed.
8. Get the big picture: Does your issue occur on one page or many?
   • If your pages share a fixed structure and only one page is broken, the problem is probably in the unique content of that page.
   • If the problem occurs throughout your site or in a particular section of your site then focus on the elements that are common to those pages.
9. Narrow your focus:
   • Where’s the break? If everything after X is whacky, the problem probably occurs at or before X.
   • Which browser(s): Does the problem occur in one browser (think Internet Explorer) or multiple browsers? Since each browser has its own quirks, pinpointing the problem browser can help you locate a solution.
   • Validate: I’ve got nothing against a bit of invalid HTML or CSS if things still work but a validator can quickly locate unclosed tags, syntax issues and other potential problems.
10. Start over: It’s tough to abandon several hours of work and start over or revert to a backup but, if you’ve spent several hours trying to solve a problem and haven’t, then you’ve probably spent those hours making it worse. The second time through the process you’ll know the issue (if not the solution) and, by working methodically and checking for the problem after each step, you’ll be able to pinpoint the problem if it happens again.
11. Break something else: Sometimes it’s simpler just to accept that you can’t fix every issue and adapt your design accordingly. For instance, if you can’t get rid of a pesky border on the left, try adding one on the right.
12. Write it down: When you learn a new bit of code, develop a new technique or discover a new resource, write it down. That way, the next time you fall off the CSS wagon at least at least the answer will be close at hand.

Last year I wrote that it is still possible (although not recommended) to use the deprecated <font> tag in Dreamweaver CS4. I recently got an email in response to that post asking how to remove the font tag from existing, older documents using CS4.

The writer noted that it was relatively easy in CS3 “all you have to do is highlight the block of text you want to edit and select “default” in the font selector box and “none” in font size and instantly the code is removed.”

The good news is it’s also very easy in CS4. All you need to do is right+click the offending <font> (or other) tag in the Status Bar at the bottom of the Document Window and select Remove Tag from the pop-up menu.

Viola, no <font> tag.

If you think of your domain name as your web site’s address, then the server provided by your hosting company is the “home” the address points to. It’s where your completed site will reside so that it is accessible to anyone with an Internet connection and a browser.

Reliable hosting is critical to your website’s success. Without it the world will never see the results of all your hard work. Fortunately, hosting is very affordable. Depending upon your needs you can expect to pay from $5 to $25 per month.

Over the years I’ve used more hosting companies than I care to remember and I’ve learned two lessons the hard way:

• Cheapest isn’t always (or even very often) the best.
• Live customer support (via online chat or phone) is critical. If there is a problem with your server, you don’t want to wait around for an email from customer support, you want help Right Now!

Based upon my experience and recommendations from other web developers, I currently recommend Hostgator for reasonably priced, reliable hosting.

1 Select your hosting plan

Go to Hostgator.com.

You’ll notice HostGator offers several types of hosting. All of them offer 99.9% uptime guarantees and 24/7 live support. We’re interested in basic Hosting which starts at $4.95 a month. So click on the Learn More… link in the Hosting box.

Now we’ll compare Linux Web Hosting plans. Unless your website is technically demanding (unlikely, since this is an introductory tutorial) the Hatchling plan should be more than adequate. If you’ll be adding additional websites with their own domains later, move up to the Baby plan.

Once you’ve determined which plan is right for you, click the orange Order Now button in the corresponding column.

While it’s easy to think of choosing a domain name and acquiring a web host as the last steps of building your site, they should really be among your first. That way, you’ll be able to completely define your site (Chapter 2) at the beginning of the development process and you’ll be able to upload and test your pages as you develop them (rather than discovering problems at the end of the process).

In this chapter, I’ll discuss the process of registering a domain name, which is basically the address where your website will live online (such as DWcourse.com). In my next post, Purchasing and Configuring Web Hosting (HostGator), I’ll cover the process of choosing a company to host your website and configuring your domain servers.

Domain Names

In the beginning of the Internet era, domain names were available through only one company (Network Solutions) and were relatively expensive to register ($70 for two years). These days, you can register domains with a variety of companies and, depending on the company, expect to pay about $10 to $15 per year.

Based upon my personal experience and the advice of several web professionals, I recommend registering your domains through GoDaddy. They’re a reliable registrar, and are currently offering .com domains for less than $10 per year.

So, let’s get started…

Adapted from my Dominate Dreamweaver online training course.

Back in the day, the Hebrews had a habit of getting themselves into trouble in spite of their favored status with God. So he decided to try to make it easy on them by reducing the rules to Ten Commandments.

In search of similar guidance from a lesser deity (Adobe), I ventured to the top of our local equivalent of Mount Sinai where I received these Ten Commandments for Editing Dreamweaver’s Spry Menubars on a stone iPad.

1. Thou shalt not edit the style sheet without reading the comments.
2. Thou shalt not edit the styles haphazardly.
3. Verily, rules for some selectors are defined in two locations.
4. Thou shalt not edit the position or display properties within the menubar styles.
5. Thou shalt not use the height property within menubar styles.
6. Thou shalt not apply padding, borders or margins to menubar list items <li>.
7. Thou shalt not set widths for links <a> within menubars.
8. Thou shalt not edit the browser hacks.
9. Thou shalt not edit the menubar JavaScript file.
10. Verily I say unto you, a new style shall appear to define the appearance of submenus.

Click a commandment above to view the related commentary.

I. Thou shalt not edit the style sheet without reading the comments.

Some very clever person at Adobe (God bless them) hath taken the time to insert extensive comments into the code of the menubar CSS file. Open the CSS file and read those comments and you shall be enlightened (and save a lot of wasted effort).

II. Thou shalt not edit the styles haphazardly.

Adobe hath joined the various styles rules together to function in harmony. Editing them without a clear plan and understanding of their purpose is guaranteed to create more problems than solutions.

A good plan is to edit styles according to the structure of the HTML page (and for that matter the order the styles appear in the css file).

1. Overall list (ul.MenuBarVertical or ul.MenuBarHorizontal)
2. Top-level list items (ul.MenuBarVertical li or ul.MenuBarHorizontal li)
3. Overall sub-menus (ul.MenuBarVertical ul or ul.MenuBarHorizontal ul – notice the second ul)
4. Sub-menu list items (ul.MenuBarVertical ul li or ul.MenuBarHorizontal ul li)
5. Links (styles related to the <a> tag including hover, focus, etc. states)

III. Verily, rules for some selectors are defined in two locations.

Adobe hath divided the LAYOUT INFORMATION from the DESIGN INFORMATION (not a bad idea) so rules using the same style selectors may appear in both locations. You can edit them in either place but make sure the properties you set in the layout section aren’t overwritten in the design section.

IV. Thou shalt not edit the position or display properties within the menubar styles.

Those who have not yet eaten the fruit from the tree of CSS knowledge are often tempted to edit the position and display properties within the menubar styles. While some sins go unpunished, this one rarely does. It WILL break your menu. And, while we’re on the subject, don’t go adding position or display properties to the style rules that don’t have them either.

V. Thou shalt not use the height property within menubar styles.

It’s very tempting to try to “force” your menubar to conform to your design by defining a CSS height property for one or more of the menu elements and you might get away with it. But the odds are that, under some conditions, one of your menu items will wrap to a second line and the height properties you so meticulously set will be ignored or your links partially obscured.

To be delivered from this evil, the best practice is to allow the height of your menu and menu items to be determined by a combination of the text-size and padding of your menu link <a> style.

VI. Thou shalt not apply padding, borders or margins to menubar list items <li>.

Set the width of your menubar “buttons” using the list item <li> rules. Since, as it is written, padding, borders and margin add to the width of HTML elements, applying those properties to list items will likely break your design.

Apply padding and borders to your buttons using the link <a> rules.

VII. Thou shalt not set widths for links within menubars.

In the commentary for Commandment VI we learned the width of our buttons should be set using the list item style rules. Any attempt to set a width for the links will likely conflict with those settings. But be not afraid, because the display: block property in the link style rule guarantees the link will completely fill its parent li tag.

VIII. Thou shalt not edit the browser hacks.

What CSS hacks Adobe hath joined together, let no man set asunder.

IX. Thou shalt not edit the menubar JavaScript file.

Yeah though you walk through the valley of Javascript, you shall fear no evil (if you just leave it alone).

X. Verily I say unto you, a new style shall appear and it shall define the appearance of submenus.

And God said, “let the styling for the sub-menus be separated from the styling of the main menu.” And it was, with the addition of a new style rule, so.

By creating a new style rule (ul.MenuBarVertical ul li or ul.MenuBarHorizontal ul li for submenu list items and ul.MenuBarVertical ul a or ul.MenuBarHorizontal ul a for submenu links – notice the second ul in the selectors) you can define CSS properties that apply only to submenus (or more precisely to unordered lists that are themselves within an unordered list). And, by the way, you only have to define the properties that you want to be different from the main menu. The rest of the properties will be inherited.

Now, go forth and sin no more.

The official CS5 announcement will be April 12 sign up at http://cs5launch.adobe.com/?sdid=FDSEN to view the announcement live.

Registration Opening Soon

Registration for the Dominate Dreamweaver will reopen the week of July 12.

Please contact me if you have any questions.

Well, we’ll soon find out what Adobe has in store for us. The official Creative Suite CS5 announcement is scheduled for April 12: http://cs5launch.adobe.com/?sdid=FDSEN

I’m compiling my list of most wanted features for the upcoming CS5 version of Dreamweaver. What would you most like to see in Dreamweaver CS5: bug fixes, user interface enhancements, new features, support for additional web standards? Or maybe there’s something that you’d like to see removed. Whichever it is, just add your wants to the comments and please try to be as specific as possible.