Okay, we've had wysiwyg vs. hand coding discussions. But I'm not starting this thread for that reason. I'm looking at practical and philosophical approaches to building websites.

(So, to get this out of the way: Yes, it's true that it's good to know how to hand code; that some programs add a lot of extraneous or even gobbledy-gook code; that some can be configured not to create bad code; that it's best to know what the program is doing and how to tweak or fix the code if need be; that properly optimized code is better in search engines. Etc. Some people like hand-coding because of the control it affords; others prefer wysiwyg for various reasons. Okay.)

So. I came from wysiwyg and went to hand coding; I guess it's been a year or two and I'm very comfortable hand coding. I sometimes start with layouts in Photoshop/ImageReady (maybe) and then go to HomeSite to code the pages; I have a variety of approaches. I could use NotePad, but I hate the blocky text, and HomeSite has (among other things) color-coding, search-and-replace features, and I can save little snippets of code and insert them with a couple of keystrokes. I mean, I'm not here to prove anything; I just like the cleaner code and the control. Nice experience.

I got DreamWeaver3 a while back, but hated the incessant indenting of code; by the time you've got anything fairly complex, the incremental indenting does not make things clearer (plus you run the risk of getting whiplash from reading your own code -- LOL). Truthfully, I was only using DW to check my code if I somehow coded an error that I couldn't find. Eventually, I got to the point where there were no errors at all.

But now I am looking at the fact that, as time goes on and business increases, sometimes hand coding pages isn't the best use of a designer/marketer's time. I guess I've had a few too many navbar changes that took hours instead of minutes, and too many small edits that require looking through stacks of code. Most of my clients could care less what I use to build their sites (one mentioned he hoped I was "just pushing a button to change all this," a pretty enlightening statement).

And, while I heard it said years ago that only hand-coders were "real" designers, I believe that is a bunch of poppycock. Being able to hand code does not make you a designer -- anymore than it makes you a marketer. And I don't believe there is much cachet (distinction) (if there ever was) to sitting around hand coding in the middle of the night when a tool could have had you done and onto the next thing already.

And so I am looking once again at the viability of wysiwig. I dusted off the old DreamWeaver, and finally figured out how to configure it so that it didn't indent or do odd things (except one, and I can fix that). Interestingly, DW has a feature wherein you can designate a template and mark off editable sections; changing the template changes all pages made with that template throughout the site (at least, as I understand it). That means you can do your layout -- hand-coded, if you wish -- and lock it down in DW so that it doesn't change. And it has apparently the same feature that my old wysiwyg has ... change a filename from somewhere within the program and it updates links throughout the site -- so you no longer have to search/replace old "logo3ab1.gif" (LOL). This looks pretty interesting, and it is not even DreamWeaver4.

And, let's face it, it's just a lot more fun to look at your text as it will appear in a browser. Yes, I know -- maybe not quite as it will appear, but it's sure a lot closer than typing code. I'd rather see how it looks, and see the effect of text, pictures and ad copy as I go.

So, barring a potential, not eventual, move to SSI (yes, Jim, I hear you!), I'm thinking this is a faster and better way to go. It may end up enhancing creativity as well. It darned sure sounds like it will be faster. And more fun.

So, talk to me. How do you work, and what are your thoughts on this?

Then layout and design including consideration of search engine placement
and doorway pages. (WebPositionGold)

Coding is last.(Homesite)

Also, I use NoteTab Pro for my editor. I used the free version for a long time, and then simply decided that they deserved some money from me [and I am cheap!]. There are libriaries of code, and I use the HTML library most of the time. For example, to enter a hyperlink, I double click on that function on the left of the screen [document on right], and I am prompted for all of the options. I then hit OK, and the code is on my page. Excellent search and replace, and includes a directory search and replace--with or without confirm.

I am not affiliated with any of these programs--SSI CSS or NoteTab. I find that having easy ways to do things make them more likely to get done.

I guess I should mention that to go to SSI would be a simple editing function. Identify the repetitive code you would like to make an include out of, copy it, do a search and replace for all of your pages, replacing with your include statement. Past the copied text/code into a new file and name the file the same as you did the include. Repeat until your pages are skinnied down to code that is unique to that page.

I totally think that people who use WYSIWYG are going to be more design oriented than coders. It's a plain and simple fact. It goes back to the same concept as someone building a newspaper ad or a magazine ad... they will work with a physical representation of it and therefore moving the pieces of the ad around until it looks good.

I do believe however that coders are more technically apt to do a lot of the other stuff associated with html because they really know what's going on behind the scenes.

I've been back and forth so many times it's unbelievable... I have Dreamweaver, I have homesite. I usually lay my ground work with dreamweaver and cut it into editable regions as you said but i don't use the template feature of dreamweaver, i do it by hand.

It is becoming more common that people are using header and footer SSI calls or PHP Include calls to develope their site. That way if you need to change banner ads, etc. you can just go into that header and it will be updated on all the pages.

The problem with this is and all i know is that i can't get SSI to work in cgi or perl programs obviously because SSI is looking for an extension that will parse SSI. So if there is a section on my site in CGI like forums, etc. I would have to manually put my header and footer in the cgi file so now that makes 2 places i would have to edit.

But then i got even lazier and figured out how to read the contents of my header and footer files in a cgi file with some cgi commands and assign my header and footers to variables. So now i am back to being able to only edit 1 central location for the whole outer layout of my site around the content.

This is one way I am currently doing a lot of my sites now... until i find a better way that makes sense to me... i will be doing that

[This message has been edited by brobe (edited 04-03-2001).]

I use DreamWeaver as most of you may already know.
One of the reasons I started usind DW is the ease with which it lets u manipulate DIVs SPANs and LAYER tags. Then I tried making some tables.
I must admit that there is a certain prodction techneque associated with DW. It's probably best to find your own.
Using DW I find that its easyer/faster to build a table from scratch with x amount of rows and y amount of colums and then copy and paste the content in, then it is to manually go into the code and start adding TRs and TDs to make another table row.

Also think modular. DW allows you to have many windows open at once and for someone in production that is the coolest thing ever. Think this way: Instead of actually working on the huge HTML page inserting some tables within tables, build your finished product in a new window where there is less code jumping at you from other stuff. This way you can precisely control DW and not allow it to spew its garbage. Then when done, copy and paste the table visually or the code into the place where you need it on the other HTML page.
Also, bosses are constantly telling you to work on 4 or 5 projects at once well now u can easily manage it with an Alt Tab.

I use DW4 and if you guys are "stuck" with earlyer versions I suggest that you try 4. The difference is incredible. While its still that familiar DW, it has a split screen so you can both edit your code visually and manually. It doesn't garble the code as long as you keep checking in the HTML window.

I personally don't use SSI on my site instead what I do is this:

Lets say I rebuilt my nav bar. I take that code go into site map and choose find and replace I search for the old nav bar code and replace it with the new one site wide. Then I just ftp the files it changed and I'm in business. (I'm not saying this is better than SSI, I'm saying its another solution for a smaller site). This also works with text and graphics.

The template feature is good. I like it because you can set a design and just start new pages from that and be ready to add content.

But Diane, you really MUST start using SSI! Did you realize DW can insert them just like an image (insert menu) AND show you how it will look (prefrences, translation). You can even edit them by selecting the SSI and clicking the edit button. That way, if you have a simple change, you just edit the SSI and upload...no running DW to update pages, only one file to FTP. The SSI can be PART of your template, not instead of, so you get the best of both worlds.

No, I did not. That is most interesting. That just about handles all my concerns about using it.

That, and the fact that it codes a few things differently than I would wish.

And there is always the layout that can't be completely broken up into SSI-able chunks ... but at least some of it could be.

Thanks, baffled. I will get around to this when we get back from the IMS2001 Conference.

I'm curious, though: say you have your navbar SSI'ed ... but the navbar links change in subdirectories. Do you have to do a navbar for each of the subdirectories (e.g., for for differences in href/img links)? Or do you just use complete URLs? I guess I answered my question ... but if you use complete URLs for, say, image links, you wouldn't be able to see the images in DW because they'd be referenced to the server. ???

instead of file relative links:
../images/logo.gif

That way, it doesn't matter what directory its in, it always starts its reference from the root.

To use root relative in DW, there is a drop down in the image and URL select windows that says "relative to:". Change it to "site root" instead of "document". It remembers what you last selected, so you don't have to keep doing it.

I usually SSI: header (except if it changes, like a unique title graphic), footer, and menus. That doesn't include any content (i.e. news output from a script) or executables (i.e. counters).

Do note that SSI doesn't work in dynamic pages like CGI output. You will still have to hard code changes into the script/template, but that's usually just one or two files, so you still save lots of time.

As to the rest, it's one more thing to keep in mind while designing the layout. But what the heck.

DreamWeaver gets the job done. The template function ... I hand-coded a layout in HomeSite, then opened it in DW3 and designated it as a template. This makes the entire page uneditable. Once you do this, it "locks down" the code and that puppy will not change. Yesss.

Next, I selected the areas I wanted to be able to edit ... such as content and a title area within the uneditable topmost table (which I don't believe you could do in SSI if your topmost table was an SSI call) ... and marked them editable. It also by default leaves the title/metatags editable. Then, I simply made each new page from the template. Well, as may happen, I later decided I could use a few pixels' more margin ... opened the template itself and made the adjustments ... and DW prompted me to update all the files made with that template. It took seconds.

Hmmm, this begins to be true love. And I don't see that I need SSI. The only time I could see needing it is if you have thousands of page to upload. That could be an annoyance, but if you have to change a little more of your layout than, say, is covered by an SSI call ... you're back to search and replace. And, as I mentioned, you can make anything editable within a template. Example (not that you would do this): you could make part of your navbar editable and the rest uneditable.

Another nice feature is called "Library Items." Here, you designate specific bits of code as Library Items ... example: a phone number that gets plunked into the text here and there. Dreamweaver will not only display it properly, but you can edit the Library Item and it will update across the site. I found phone numbers in arial (the whole site is going sans-serif) but some were in bold/grey, others plain (making a bit of a problem with search/replace). So this Library Items function would not only make updating a snap, but would ensure uniformity across the site.

Being a bit fussy still about code, I also tweaked how DW3 treats it via a (very arcane) text file. Took a while to figure it out, but I cannot bear constant indenting ... I mean, after a few indentations, who can tell where you are in nested tables and lists? That's what comments are for

DW does insert comment tags showing editable/uneditable fields, but I guess if I were that flipped out about it, I could simply copy the site and delete them (search/replace). But at this point, I don't care.

I do wish it would stop opening up new windows for each file; I'd much prefer a tabbed files in one window.

Well, I'm sold. Truthfully, I have few (almost no) clients who care whether I hand code late into the night or use programs to work faster. Actually, the one I asked thought it a bizarre question, and another volunteered that he hoped I was just "pushing a button to make all these changes," so I stopped asking. They're more interested in the performance of the site with regards to customers buying, signing up or whatever ... as they should be. I'm just saying that my experience is that they could care less about any "real designers should hand-code" idea; there is no stigma whatsoever attached to wysiwyg as long as I can get the job done.

So, assuming I stay happy about DW, this will enable me to get the job done faster while spending more client dollars/my time on other aspects such as writing ad copy.

Of course, Alex claims that if I try DW4, I will forget about both HomeSite and DW3. Possibly, but I find HS such a stable, usable and comfortable program which I can fall back upon at any time -- and I still use it quite a bit.

While we are talking about working smarter, let me add a FTP tip. Have you ever shanged a half dozen files, then scrolled down to each one to FTP them one at a time? I finally realized that the time/date column in the FTP directory listings can be clicked, and the files are listed in order of last changes. Then highlight those last dozen files [they will be together at the top of the listings], and FTP them all together. Eliminates some steps. I am sure many of you do this already, but when I "found" this, it was a revelation for me.

Server Side Includes are a wonderful compromise between ease-of-use and server efficiency.

It’s a compromise in the sense that it works very well IF you can use a .shtml extension for your files. Unfortunately for me, I didn’t realize the strengths of SSI two and half years ago, so I designed my site using .html extensions – and throwing away two years of links and SE rankings by changing file names ain’t an option.

Yes, you can configure the server to parse .html files as well as the standard .shtml extension, and many people do exactly that – but you then give up the server efficiency. (And you can dramatically compound that loss if you use .htaccess to do it.) Imagine if every page on your site had to be sent through the php compiler, even if it didn’t have any php in it? Web servers (especially Apache) are very efficient at serving static pages because they don’t have to parse anything. They just grab and throw. Enabling SSI on all pages means you need to throw a LOT more hardware at the same job to get it done. For low-traffic sites, that’s often not a big factor because the hardware is sitting idle a lot any way. But, unless you plan on staying low-traffic, it doesn’t scale well at all. In my case, it would mean moving from a dedicated server to a cluster, which is a HUGE increase in costs.

I highly recommend SSI for new sites. And even if your new site consists of three pages and doesn’t use SSI today, I would still use an .shtml extension to leave that door open. But for existing sites that are locked into non-SSI naming conventions, like most of mine, it’s just not a viable economic option. The benefits of SSI are very real. But everyone in the computer world knows, by now, that benefits always have a cost.

I also wanted to clarify my stance on SSI. At work we use ASP SQL and all those other lovely things to run our site. With 5 people that do coding and others that go into files to change other things SSI is the way to go. The idea is "think modular" and also think "time is money". Using SSI in combination with SourceSafe seems to be a very efficiant fool proof way of getting the job done. Would you agree?

And another great post from RonC.

> Yes, you can configure the server to parse .html files as well as the standard .shtml extension, and many people do exactly that - but you then give up the server efficiency.

Ah, you are talking the XBitHack? Good info, verifying my recollection that it would slow the server down if you parse every page.

So, if it's just a matter of utilizing a convention (.shtml) at the start, that is easy enough for new sites.

And, interestingly, if I were desperate to go SSI in the future, I would just pop open my template and make the switch.

The current site I'm reworking, however, is my own; it has many links to it, making renaming pages to .shtml not an option. But for new sites, this is something to contemplate.

[This message has been edited by DianeV (edited 04-20-2001).]

AddType text/x-server-parsed-html .html

It makes .html a server parsed page just like .shtml.

I did do this, because I too started with .html extensions and didn't want to destroy all the hard work I did getting listings and links. While I understand the argument of not making the server parse pages for no reason, there are now VERY few pages on my site that don't have an SSI call of some kind or another. So its really no different than having every page named .shtml for me. If I was only using SSI on a few pages, I wouldn't have changed the .html extension. I now design sites with .shtml by determining when SSI will be useful beforehand. For a small site, they're may be little value in it. For a large site, its a lifesaver.

No Diane, SSI isn't the way to include content that changes from page to page (like title text). However, it is a great way to include constants. Perfect example: I recently had to remove one of my main content sections. If I didn't SSI my menu, it would have required changing, and FTPing, over 200 pages. Instead, I changed one include file, uploaded it, and bingo...every page was updated. Believe me, I was very happy it was this easy!

I don't know if you knew or not, but... Dreamweaver 4 has this cool button which lets you insert "Flash Text" it looks like the Text tool in Photoshop 5.5 and below.

Once you have written your text/make it a link, have it change color on mouse over whatever... The coolest thing is it saves the file and writes all the HTML you need to view the Flash.

How's that for a time saver? I was thinking of usefull applications for this tool and I think it would be a cool tool to use if you want to use some weird font on your site no one else has. Seeing as how one never has to leave DW4 to make the text and compress it as a gif or whatever. It also has a library of Flash buttons that are all custumizable.

[This message has been edited by xelA (edited 04-24-2001).]

Alex, I'm in the midst of a reorganization of my site, but after that I guess I go look at DW4.

And, actually, it's fine that HomeSite is separate ... sometimes I want to use it separately.