Dreamweaver Web Sites 101

This is a basic tutorial to help some get started using Dreamweaver (they have their own tutorial, you know). At the moment there are only simple screen captures of the Preferences, and Site>Edit dialogues.

• Preferences - overall preferences for the program. Some are personal, or local preferences, and can be changed to whatever you're comfortable with, but some affect how the site is dealt with, and should conform to whatever the collaborators or webmaster have decided on.
• Site>Edit - site-specific preferences, including local mirror folder, FTP settings, collaboration settings, file encoding preferences.

Philosophy

My personal opinions about all this stuff gleaned from years of experience doing it, supporting others doing it, and pulling their bacon out of the fire.

• simplicity - don't add anything to the site, or a single page, script, button, or form that you don't absolutely have to. This means no CSS when HTML will do, no Javascript for frills, no server-side scripting for client-side work (form validation, menus, rollovers), no full size pallettes in graphics with less colours, no graphics when text will do (Ok, there's a neat rollover effect you can do with CSS that might contravene the sensibilities of some hard and fast minimalists, but what the hey, it saves bandwidth), and generally no extra bandwidth usage just 'cause. And especially don't fall in love with your 'art.' HTML is a funky thing. You're better to learn to get along with it, than to try and beat it into submission with layers, and div tags.
  Special Note: Some tools - I won't mention any names - in an effort to simplify the Web author's life, get very complicated under the covers. This will almost always come back to bite you.
• movie quotes to live by:
  • My daddy always said, "When you want to
    hammer a nail, don't do anything fancy. Just get a
    hammer and pound the son of a bitch."
    ...Todd's commanding officer in Soldier
• craftsmanship - my Dad's a cabinet maker, so...
  • Know your tools.
  • Everything in it's place.
  • The right tool for the job.
  • Don't guild the lilly (there, look that one up on the Web). It means stop when you're done. Don't fiddle more than you have to. Leonardo Da Vinci had trouble with this one. Some say this is the mark of a true artist - knowing when to stop.
  • Keep it clean as you go.
  • Put your tools away at the end of the day. For Dreamweaver collaboration that means check it in.
• usability - this is easy. Consider the user, and never reinvent the wheel. There's a reason all the big Web sites look the same. Upside to this is that most of the things you want to do have already been done. Just find a site you like, and copy what you like.
• the tough stuff - learn to read some HTML. You need to know what a tag is, what an attribute of a tag is, and some of the more common links. Just find the 'view source' item in your browser's menus, and look at this page's HTML source code.

Glossary?

• collaborators - those parties working jointly, or separately on the Web site. Managing this, using design notes, and file check in/check out, is one of Dreamweaver's strengths.
• file check in/check out - Dreamweaver's terms for a major feature used to facilitate collaboration. If this feature is turned on for a specific site, you are not allowed to download a file without checking it out first, and you're not allowed to upload a file without checking it in first. This assumes you're using Dreamweaver to work on the site. Of course you can override, or circumvent this feature - another of Dreamweaver's strength's, in my opinion. This feature also prevents you checking out a file, if someone already has. This lets collaborators bang away at the site without worrying about their work stepping on someone else's, or vice versa.
• design notes - Dreamweaver lets you associate a note with a Web object, and even force it to be displayed when the object is opened in Dreamweaver. This means you can maintain a todo list for the object, and make the other collaborators read it. Very cool, very handy, especially for works in progress.
• mirror - a duplicate version of something. Above I refer to the local mirror. This is the directory containing the local copy of the posted Web site.
• webmaster - the person responsible for managing the stuff on the server. This may, or may not, be the same person responsible for posting content, artwork, designing the look and feel, and/or programming server-side, and client-side, dynamic content. This is the person others should contact if there's a problem with the site, and he/she should receive email from a mailto link on each page.
• web designer - the person responsible for the look and feel of the site. Also responsible for the navigation model. i.e. usability
• web developer - the person writing dynamic content for the Web site. Frequently the person writing local, dynamic content is not the same person writing server-side dynamic content.
• usability - the study/practice of, in the Web site world, user interface, navigation model, graphic impact, etc, integration, and how it affects user interaction with the site. i.e. In the case of benevolent Web sites, can the user find what he wants with a minimum of effort? In the case of less benevolent Web sites, is the user being directed as the owner of the site intends - usually based on a profitability motive.
• server-side - stuff that resides on the server, and works on the server. This usually refers to scripts written in languages such as Perl (.pl, .cgi), PHP (.php, .php3, .php4, .cgi), Visual Basic (.vb, .asp) that run on the server, and can interact with the server. That is, these scripts do their work on the server, and then deliver a Web page to the user based on the results of the program's execution. A typical, legitimate use of this is to request information from a database residing on the server, and delivering the results in the form of a good looking Web page.
• client-side - stuff that resides on, or is delivered to, the user's computer before execution. This includes Javascript, style sheets, ActiveX, .NET, Java. This stuff is downloaded by the user's browser, and then executed on the user's computer by the browser, possibly with help from the operating system. A typical, legitimate use of this is to validate user input on a form before it's sent to the server. This reduces server load, and speeds up the process whereby the user is notified of the need for correction.
• HTML (HyperText Markup Language) - a text markup language that Web browsers understand, and use to format Web pages for their users.
• tag - HTML markup component. These are the magic parts of HTML that tell the browser what to do with the item on the page.
  • Typically a tag is a two-part entity. That is, there's a starting and an ending tag, and the pair applies to what's in between.
  • Some tags don't require their ending part. They know they're finished their work when there's another starting tag of the same type.
  • Some Web objects are made up of several different types of tags because they're not simple objects.
  • A tag is typcally a pair of angle brackets, <>, enclosing terse code for the type of tag in question. An ending tag is usually identical to the starting tag, but without attributes, and the first character after the angle bracket is a front slash, /. ex. <b>This is a bold tag, and all text after it will be bold until we close it thus.</b>
  • attributes - extra information between the angle brackets of the opening tag that modify the way the tag works. ex. <font color=red>This is a font tag, and all the text after it will be red until we close it. There are other attributes possible with the font tag.</font> Notice that we only had to use the word 'font' to close the tag.
  • quotes - this is a particularly thorny topic. For now, let's just understand that sometimes the attributes require specific kinds of quotation marks (single, or double) around them, sometimes they're optional, and sometimes you specifically don't use them. You'd better figure out which is which if you're going to entertain the idea of using any kind of dynamic HTML, because those same double, and single quotes mean different, special things to the source code of the dynamic content. If you have to put quotation marks inside other quotation marks, life gets pretty funky.
• DHTML (Dynamic HTML) - HTML that's not static... DUH! This is actually a complex issue made more so by our good friends at Microsoft. They're constantly usurping perfectly good terminology for their own. proprietary, and narrow, uses. Any HTML that has some kind of content in it to make it react to user's input can be considered dynamic. This can be done server-side, or client-side. As far as I'm concerned, it doesn't matter as long as it's done right.

I'm sure I'm not done, but I am quitting... for now ;-)

These slide shows were made with IrfanView in about 10 minutes - for both of them.