When I first started building websites, back in the days of completely grey backgrounds, Mosaic and that upstart Netscape, I coded a site "by hand," that is, I used a simple text editor and wrote all the code myself. It wasn't hard. You put < p > at the end of every paragraph (I know, I know!) and animated GIFs were the height of kewl. As the web left kindergarten and moved on to junior high, coding a design meant using tables to contain chopped up bits of images and the tables could get pretty complex. It was easy to get lost in the code trying to figure out which cell you were in now if you'd spanned 3 rows and 2 columns ....
And then there was Dreamweaver, Macromedia's way to make web design easier.
For most web professionals this meant you could visually design a table - and then flip back into the code and clean up the mess that DW had made. Not perfect, but much faster than trying to code a complex table completely by hand. Basically, you'd design the site in Fireworks (think Photoshop but instead of editing photos, you edited shapes and buttons and such). When you had the design looking all purty, you began thinking, "Okay, I want text to go here, here and here. So, let's cut these images here and here and then code a table to make the images "glue" back together and put the text where I want it."
What made this work was the fact that you could flip from the visual look of a site (WYSIWYG editing) back into the code, make a change and then flip back to the visual to make sure it still looked right. You see, most designers are visual people. That's kind of why they're into design.
As the web graduated and headed off for college and then the big bad corporate world, it matured. Both those who coded and those who designed wanted the language of the web to be more semantic, to make more structural sense.
Back in the day, the code to make a word bold, was < b >. When you wanted to turn off bold, it was . Pretty simple and semantic, but it could be better. You really wanted a strong emphasis on that word or phrase and that's why you made it bold. So today, the code is < strong > instead. Italicized text's code is < em > for "emphasis." But looking at the code: < td colspan="5" > is not really very semantic. What does that mean, really? The web began using something called CSS to structure pages, a way of styling different elements in a semantic way.
The first time I ran across CSS, I was webmaster to four university sub-sites, plus my own webspaces. I discovered it in Dreamweaver's interface - I could suddenly style text! I could declare a style .times14 and then every time I wanted to use that typeface and size, I could just click a button and Dreamweaver would make it happen. Wonderful!
The truth of the matter was that I had grown far too reliant on Dreamweaver and I wasn't keeping up with my handwritten coding as much. This was the smallest portion of what CSS could do even then.
Today, many sites (particularly most blogs) take full advantage of CSS, although the "quirks" of how it displays from browser to browser still cause as many headaches as the "quirks" of how tables once displayed still making coding a site a challenge. Now, you can create a "div" to contain a section of the site. For example, a div might be called "content" and you put all the styling you want for your content into that div (and its specific components). In other words, maybe the main column of your blog is your content div. You (or the person who wrote your theme) coded that div to tell the browser, "Hey, we want this to be 400 pixels wide and to appear about 10 pixels to the right of the left sidebar. Also, the background of that content area should be this particular nifty image (that is contrasting enough that the text can still be read easily.) In addition, every paragraph should be in the font Arial (or, failing that, Helvetica or some other sans-serif font). Also, the title of a blog post should be about 18 pixels high and dark blue and italicized."
In other words, using CSS meant you could place sections of your site, set backgrounds and even code the look of the font just one time instead of for every paragraph.
When I first started really utilizing CSS, I learned it the same way I did HTML: I looked at websites who used it and figured out the code that way. I began coding my websites by hand again, partly because I enjoy knowing I can do that (I am, after all, a major geek), partly because coding for the web was suddenly semantic and easy again, and partly because Dreamweaver's support for CSS seriously sucked. The "design view" portion of the program just didn't display CSS very well.
Now, I've been using Dreamweaver since oh, version 2, I think. I loved it for years. It beat the socks off Microsloth's FrontPage and Adobe's GoLive left me cold at first.
Well, Adobe purchased Macromedia back in 2005 and I wondered if it would be GoLive or Dreamweaver that would "win" the merge. I was rooting for Dreamweaver ... and then I used GoLive. It actually rendered CSS in the design view! I had never managed to get Dreamweaver to do that (except for some textual stuff - but never the placement of a sidebar, content, sidebar kinda thing). I wasn't an instant convert as I had far too many sites being maintained in DW and I didn't want to migrate everything, but I was definitely thinking of starting new sites in GoLive instead.
Dreamweaver, it seemed to me, had grown old and stale and was no longer really conversant with what designers wanted. Its original big draw was the ability to visually design something ... and have it write the code ... and then have the ability to go in and "correct" or simplify that code. (And then go back into design view to verify that you had not, in fact, screwed something up with your simplified code.)
So when I began working somewhere that used GoLive instead of Dreamweaver, I was not really concerned about it.
Unfortunately, GoLive is no longer being produced - Adobe has thrown itself fully into Dreamweaver. Even more unfortunate, they've left the best things about GoLive behind instead of integrating them into Dreamweaver.
Just one quick example before I head out to work:
The place I work now owns about a bazillion websites. All of the designers work on all of the sites at some point or another. Hence, we have a Websites directory from which we work on Brand A site, The Music Site, Brand B site, Our Main site, etc ad nauseum. This makes sense to me. We use a versioning software to keep conflicts between designers to a minimum and, in fact, merges our changes (in other words, I might be working on page x in Brand A for a project ... and another designer may be working on a project which also means he has to edit page x). We do not include our images folder on our hard drive or in our versioning software. Those are stored on an images server, and it serves out those images to all of the sites.
GoLive understands that our images are out on another server. And when we flip to design view, it knows where to get those images and display them for us so we can make sure the code we just changed still displays everything correctly.
Dreamweaver doesn't get it. It cries. It cries piteously and repeatedly, "HEY! HEY! HEY! You put the images folder outside of the main folder! HEY!!!!11!"
In addition, GoLive understands that when we pick harddrive/documents/websites/OURCOMPANY/brandA/ as the root directory for the Brand A site, that it's the ROOT directory. In other words, when a page is coded to refer to an image or a stylesheet (that's what a CSS file is called), it knows that it should look on the website at the top directory for it. Likewise, when it's looking on my hard drive to show me how a page will look, it will use the root directory I set as the "top" directory - instead of using harddrive/ as the top directory. (Basically your computer's hard drive is the top directory for your computer. When you code a site, you often code it to refer to the top directory of the website - so any design program you use needs to be able to say, Oh, you mean the top directory of the website, not the top directory of your computer.)
Dreamweaver doesn't get it. It won't find your stylesheets if you coded them: /stylesheet.css. Instead, it looks for your stylesheet in the top directory of your computer.
This means that NONE of the styling in the sheet will work in Design View.
Which makes the visual editor pretty much useless.
And the Dreamweaver team seems to think this is actually a selling point - you can see your page uninhibited by all that pesky design.
And if you absolutely insist on viewing it with the stylesheet, well, you can manually add it. Manually. Add. To. Each. Page.
And, if you're unlucky enough to be working on a huge e-comm site wherein different pages use multiple stylesheets? Add each stylesheet manually. Separately. You can't even multi-select from the dialog box!
So now we seem a bit stuck at work. GoLive is old enough now that it is pretty common for it to crash. Dreamweaver totally screws up our workflow and doesn't understand much of what we need it to understand. Do we limp along with crashes for now and hope Dreamweaver gets it eventually? Do we bite the bullet and make the switch now? Do we completely change the way we code AND the way IT has all of our sites set up?
I don't know.
But I no longer think that Dreamweaver is the best WYSIWYG web program. In fact, I'm thinking right now, that it's more than a little over-rated.
Too bad our sites are too complex to just code by hand all the time.
Maybe now is a good time for us to simplify ... of course, that would mean a total redesign of every site ....
Hmmm... I'm still using an older version of Dreamweaver, but I can specify the root location for each "site" and it seems to work for me. Have they actually moved backward in more recent releases? Also, if this is case, can't you avoid the "every page" scenario by managing it through templates? PS: what version of DW are you all using?March 18, 2009 9:07 PM