Learning HTML Coding and Website Building

Explains how I built TimsLaw.com

… From arranging web hosting and a domain name, to learning HTML coding, fits and starts, dead ends, finding essential tools, making mistakes.

This article exists to continue the web tradition of people putting out info about their experiences, so that others will have an easier path. Without similar pages by many others I could not have learned enough to develop this website. Thanks to all whose articles helped me. I hope you find this article useful as you develop your own site.

---

[UPDATE] — I’ve moved beyond HTML and entered the frightening world of PHP! My website is being recoded, by me, to fit into the PHP-based WordPress content management system. Many of the tips below refer to the old days of pure old HTML files.

[UPDATE2] — The following is really ancient history — In terms of “internet lifetimes”, we are going back a long time, since one lifetime is about 3 years, and my site started in 2002 — I learned good stuff with the PHP thingy, and built a well functioning site, but a site that became vulnerable to things like Apache updates at my webhost, which rendered some of my commands obsolete at times. — I am thinking of going back to a low tech site that is way less vulnerable to breakdown.

• On April 1, 2006 (an ominous date?) I decided to GO LIVE with the WordPress recoded version of TimsLaw.com. Prior to April 1, I had been recoding TimsLaw.com under a different domain name, MissouriJobLaw.com. If you had known of MissouriJobLaw.com, you could have visited the site during early development, and experienced the joy of constant crashes. Wouldn’t that have been a good time?
• The balance of this article remains somewhat valid as a historical journal of my travels through the process of learning HTML coding and website building. I started in 2002, with old-fashioned HTML hand-coding. And then by 2006 I was moving on to PHP-enabled, database-driven, websites. Whew! What a journey.

[More updates are spread around throughout this article]

---

Steps in the Process (and remember that this is pure history, several “internet generations” removed from today)

You’ll need someone to “host” your site, and a domain name.

I chose Pair Networks as my webhost. I had known of Pair Networks for years, because they host one of my favorite sites, Toms Hardware Guide, which is a giant site that requires a first class webhost capability. I looked into Pair’s hosting options (back in 2002) and found the perfect match for me to start out with: For about $7.00 a month (about $10 now), Pair offers a basic package that includes 100 meg of bandwidth per day, which is about 500 times more than I needed at the time to start out with. I’ve since upgraded the hosting plan somewhat to get more power. I’ve had no significant problems using Pair, and their emailed instructions were sufficient so that I could get set up without even having to speak to anyone. [UPDATE – Pair’s service is top notch and I have never considered changing, despite the sexy ads from Godaddy.com]

I bought my domain name, www.TimsLaw.com, from Verisign, but I did that before I arranged for hosting with Pair Networks. If I had it to do over again, I’d buy my domain name through Pair Networks, as well as my hosting. Go to Pair Networks and click the links to learn more about their domain name service and their webhosting packages.

Try not to pick a domain name that is too similar to an existing domain name. Here’s just one problem that could happen: The Yellow Pages got my domain name wrong in an ad, and called it “www.TimLaw.com” rather than “www.TimsLaw.com”. TimLaw existed already, and was a Canadian law site. I had to buy the domain name Timlaw.com from the current owner if I wanted any value out of the ad. It wasn’t cheap. I could probably have bought Timlaw.com cheaper on the front end, before my own site was up. TimLaw.com now redirects to TimsLaw.com.

How I initially learned to cope with HTML coding in 2002

I downloaded web-building tools to play with and experiment

Going into the coding of this website, I knew nothing about HTML. I downloaded demo versions of various editors and wysiwyg programs like Macromedia Dreamweaver and played with them. I downloaded some “templates” for Dreamweaver from Snakeye Web Templates. Between the Snakeye Templates and Dreamweaver, I was able to see a lot of raw HTML code and how it resulted in things happening on the pages. The Snakeye Template that got me started was (in 2002) Free Template 17. You do not need Dreamweaver in order to get good use out of a Snakeye Template. You can load a Snakeye Template into any HTML editor, or even Windows Notepad, (see below for links to editors) and you are on your way to designing your homepage.

With Dreamweaver, I was able to easily work on ideas for the TimsLaw front page. The Dreamweaver “layer” function is fantastic – you can drag and drop your layers while playing with the page layout. But then my trial period expired and I had to decide whether my relatively simple website was worth the big licensing fee for the Dreamweaver professional web development program. I decided it was not worth it, that I should be able to hand-code everything for this site.

I needed to write raw HTML myself and develop a website by hand. I needed to learn some HTML. I downloaded several free HTML editors and played with them. In the beginning I chose to work with 1st Page 2000 from EvrSoft (but I’ve since then moved on to Arachnophilia version 4, the non-Java version). [UPDATE – Arachnophilia remains my favorite editor for HTML and PHP files.][UPDATE2 – I now prefer the Notepad++ program combined with the Firefox Web Developer plugin.

Quick tip on learning HTML: Right now, yes right now, simply put your mouse over some part of this page and “Right-click “. Then select “View Source”. You will see that the “code” for this webpage is just plain old text. Scroll down through the code and you will eventually see this very paragraph. It ain’t rocket science. The secret to basic web-coding is knowledge of what a few codes mean, and lots of practice playing with the codes so you get them to do what you want. At the bottom of this page I link to the major sources of such knowledge and many tools to help you learn and practice.

If I had it to do over again, I would not play with Dreamweaver. Instead, I would just download a Snakeye Template and use Arachnophilia to begin editing the template. That’s what I recommend to others now. Read on, and see what a rocky road I created for myself.

You don’t need Dreamweaver (or Frontpage) unless you have a giant site or unless you want a lot of fancy bells and whistles. I wanted a technically simple website that I could code and maintain myself. That means I could do fine using a pure and simple HTML editor. If fact, you can use Windows Notepad as your HTML editor, because HTML is simply pure text. But there are features of the HTML editors like 1st Page and Archnophilia that make them more useful, such as color selection palettes and help files and macros.

After playing with Dreamweaver, I got a basic design, but it was VERY MESSY and I had to scrap it

When I ended my Dreamweaver trial, I had a mess: “layered” pages that were not accessible to the visually impaired or those with browser assistant programs or older versions of the popular browser programs. If I wanted my website to be usable to almost everyone, I had to recode.

Dreamweaver “layers” are sections of your page that you code and format differently, much as you would do with ordinary tables, or any other type of little box you might want to see on the screen. In Dreamweaver, you can drag and drop your layers (or stretch them, shrink them etc) anywhere on the page while playing with your layout. When the page is loaded by a web browser, the “layers” will be loaded in the order you designate through a “z-index” such as layer 1, layer 2, etc… The raw html code for the layers actually uses “Div” tags and absolute positioning using exact pixel offsets. You can precisely lay out a page and do a lot of impressive things with z-indexed layers.

But the various web browsers handle layers quite differently, and some browsers don’t handle them at all, and many users will see a chaotic mess rather than your well-planned beautiful web page. That’s what I found when I looked at my pages in some other web browsers. [UPDATE April 2006 – This critique remains valid. When I recoded TimsLaw.com into WordPress, I used old fashioned Tables for layout rather than z-indexed div-based layers]

I learned that I needed to convert my layers to ordinary Tables, if I wanted a site that would display acceptably in most browsers. I have links at the bottom of the page to some of the key resources I used in learning about HTML and Tables and Layers.

You could use Dreamweaver to make accessible pages (but I didn’t know how, and wasn’t thinking about accessibility issues when I started). You could also make Dreamweaver pages without using z-indexed layers, but layers are easy to use in Dreamweaver, and fun to play with when developing a site. The problem is that unless you are real PRO, you can’t manually tweak the extremely complex Dreamwever layer codes wihtout breaking everything – Dreamweaver will let the novice create a wadded up ball of string, which will work, but which you won’t be able to comprehend as a novice.

After playing with Layers, I had to get serious and learn about “Fluid Tables” or “Liquid Tables”.

After studying in Google, I learned of “Fluid Tables” (also called “Liquid Tables”), which are just regular tables that use percentages of screen width to specify their sizes, rather than exact pixel counts. The tables expand and contract according to the user’s screen resolution settings. At high resolution, my table data might appear on the smaller side, but the user can Increase the Font Size to Medium or Large and everything should look fine. At the more common lower resolutions, my pages still fill the screen and do not require scrolling. My fonts are almost always re-sizeable, which runs counter to the awful web trend of using exact pixel sizes for fonts (exact pixel sizes means that a lot of users cannot possibly increase the font to make the text readable).

There are many ways to write “tables”. You can position them with absolute sizes, or you can write them to expand and contract depending on the resolution of the user’s computer. I did not want to write tables that “required” any particular resolution in order to look ok. I wanted to write tables that would display acceptably no matter what resolution the user preferred.

If you use 1200 x 768 or higher screen resolution, then you know that a lot of websites are hard-coded with exact pixel counts optimized for 800 x 600 resolution, because when you see their sites you also see a lot of awkward white space on the side of the screen, and if you have a low resolution such as 640 x 480, you will often be scrolling to the right in order to see some websites, because the websites are not “fluid”. But when you go to my homepage at TimsLaw.com, my display SHOULD expand to fill all of your screen area. And my site SHOULD shrink to squeeze into your 640 x 480 window. That’s because my site is coded with fluid tables.

So I re-wrote my Dreamweaver layers into ordinary html tables

A Snakeye Template (linked above) is a great tool to get started with learning tables.

I wanted a three-column design with a banner across the top. I found a Snakeye Web Template that showed me something about how to code for such a design. I learned a lot from the Snakeye template, because it showed me the basics of tables. In the beginning, I could just begin typing things into the Snakeye template and I could begin filling up a table with info, like links to my articles. I was on my way.

I removed the DIV-based layers and then rebuilt the layers as ordinary tables. I ended up re-coding TimsLaw.com essentially from scratch in 1st Page 2000. 1st Page 2000 was fairly easy to use.

If I wanted a list, such as a links list, then I needed to learn some HTML listing commands, so I would search Google.com and read website help pages. As I became more comfortable with experimenting in HTML coding, my needs changed and became more complex. As my needs became more complex, in terms of what I wanted to do and what I wanted the site to look like, I spent more and more time searching Google and reading HTML tips pages, and experimenting in 1st Page 2000.

One thing led to another and I ended up learning about CSS stylesheets and using a lot of CSS on the site. This was a mixed blessing.

CSS means “cascading stylesheets”. Stylesheets are formatting commands such as fonts and colors and positioning and sizes and borders and widths and heights and background colors, etc… You can put the “style” commands in several places, and they execute (or “cascade”) in a particular order depending on where they are placed within your code. You can put the style commands into a separate file entirely, which is what I chose to do originally (and then abandoned for years due to the extra download time for the CSS file, and now I’m back to a separate CSS file.).

After I learned of CSS I got clever and put a whole lot of style routines into a large CSS file that would be called from my pages. The routines would be “called” from my HTML pages much as computer program subroutines would be called from within larger programs.

Eventually, I had a rudimentary three column design coded in ordinary “Fluid Tables” (using relative sizes such as percentages rather than absolute sizes such as pixels). My CSS stylesheet worked well (using MSIE 5.5 at home in 2002). I thought my site was ready for launching.

The shock of recognition: My re-write didn’t work well – In older browsers, my site was trashed completely. Older browsers choke on some CSS formatting commands. I recoded again, and learned of the “@import” trick to deny the CSS stylesheet to older web browsers.

But then one day I learned of major problems with older “Version 4″ browsers and my fairly simple CSS stylesheets. I actually looked at my pages on someone’s old PC – it was a complete nightmare. The tables were not the right size, or positioned properly, and the color scheme was chaotic and illegible. After research, I learned of the major discrepancies in how the various Version 4 browsers handle CSS style commands. Many CSS commands are not interpreted correctly in older web browsers, and the browsers choke and put gibberish on the screen, etc…

So I had to re-code again, to a lesser extent than the first time. I did two things. First, I learned how to prevent older versions of browsers from seeing my CSS stylesheet using the “@import trick” (see below for more on that). [UPDATE – I don’t prevent older browsers from seeing the stylesheet anymore. I stopped using the @import trick. See Redesign Notes for more info]. Second, I put safe but obsolete formatting attributes in my HTML table tags in an attempt to create an approximation of the site’s look even on older browsers that would not see my CSS stylesheet [UPDATE – I still use those safe, obsolete commands. You can see them if you View Source on my articles. Notice how the Table or TD tags have commands for colors and so forth right next to them. This is to enable a decent display even if something bad happens with the CSS stylesheet].

When you use safe, obsolete, formatting commands right alongside of the – table – commands, those commands are interpreted correctly by just about every browser. If the browser then sees CSS style formatting commands that it doesn’t know how to handle, the browsers almost always ignore the CSS styles and stick with the safe obsolete commands instead. If you fail to give the safe, obsolete commands, then the browsers have no “fallback” options; the page does not “degrade gracefully”, and the display might be gibberish.

Browsers that do know what to do with CSS commands ignore the obsolete table formatting commands and follow the CSS formatting commands instead. This approach has worked well. I have a link below to a page where I present some screenshots of how the site looked in older and newer browsers.

I’ll talk a bit about the @import trick. But there is a drawback to using multiple CSS files and the @import trick: Users have to download two CSS files along with the webpage, before anything will be displayed on their screen.

I (used to) use the @import CSS trick to try to deny the CSS stylesheet to “Version 4″ and older browsers. I learned of the @import trick here: w3development – hide css from browsers. The following browsers should fall victim to the @import trick, according to that site:

• Netscape 4.x
• Win IE 3
• Win IE 4
• Mac IE 4.01
• Mac IE 4.5
• Konqueror 2.1.2
• Win Amaya 5.1

The @import trick involves two stylesheets. The main stylesheet called from your page contains one line only –

Older browsers either ignore the @import command or don’t fully understand what to do when the stylesheet name is placed in quotes. So older browsers should not be able to see the real CSS stylesheet whose name is placed in quotes within an @import command.

NOTE: The @import trick is not necessary to prevent Netscape 4.7 users from seeing your CSS styles. I have learned of a different fix as follows: Netscape 4.7 is supposed to ignore any CSS style command that contains an invalid argument. Suggested use: .mystyle {xyz; font-size:small; } In theory, the invalid style command “xyz;” should cause Netscape 4.7 to refuse to parse any of the CSS instructions in the class. In theory, you can put anything there, even “netscapeignore;” and the entire style command should be ignored. No need to deny the entire CSS file to Netscape 4.7 users through the @import trick. But I don’t use that trick, just as I no longer even use the @import trick. See below for more on this subject.

I eventually let my second CSS file get big, way way too big. It reached 22K. The first CSS file (with the @import command) was only 1K. But each file to be downloaded requires a formal request from the user’s computer to my web server, and takes a few seconds in addition to the download time. With my front page reaching 35 K at one point, and a little scales gif file, and 2 CSS stylesheets, it was taking dialup visitors a long time to see my front page. A lot of people were not waiting the 20 seconds or so it might require.

One advantage to a separate CSS stylesheet file is this: When you want to change the colors or the fonts or the table borders, or just about any other style element, you just edit the CSS file and the entire site is automatically updated for every webpage. However, once your style commands become set in stone where you have stopped making changes, you can safely put the styles right into the HEAD of your HTML documents. Then you can use the SR98 utility (linked to below) to do a global Search and Replace if you need to update a particular style or add a new style command. [UPDATE: That’s how I did it for two years – But in 2004 I reverted to using a single simpler CSS file for all styles].

NOTE: See Redesign notes where I talk a little more about redesigns, and why.

Compare the CSS and non-CSS versions of my Front Page
(older browsers choke on some CSS commands)

My Front Page [used to be] absolutely trashed in Netscape 4 and MSIE 4 if I allowed those browsers to see my CSS stylesheet. They didn’t handle the style commands well. The only way to give those browsers access to my site [was] to deny them the CSS stylesheet using the @import trick described above.

Anyway, I try to code so that people can still see the basic info, even if they cannot use my stylesheet for some reason.

If you use the FireFox browser, you can strip the stylesheet out by clicking View, Page Style, NoStyle. You can also install the Web Developer plugin, which will let you easily DISABLE the CSS stylesheet for the page you are viewing. Then you can see the page using JUST the formatting commands that were placed into the TABLE or TD or P or DIV or LI tags, whatever]

As time has passed and the web has matured, I do not worry much about people being unable to handle my stylesheet. Here’s a bit of history: Back in the days when I actually denied Netscape 4.7 users access to my CSS file, I wrote an info page for Netscape 4.7 users that links to screenshots of how my front page looks in NS 4.7 and MSIE 5.5. That page is obsolete now, because I stopped using the @import trick, but I will keep it active for a while because some people find it informative.

More about 1st Page 2000

1st Page 2000 was the program for me when I was developing a website by hand and didn’tt want to pay big licensing fees. For daily editing of pages, after development was complete, Arachnophilia 4.0 was the program for me. I have links to both of those programs below. Arachnophilia 4.0 is better than 1st Page 2000 for daily editing because it doesn’t have the wordwrap bug (see below) and it loads faster and is somewhat more stable. But as you develop a site, you need the site management tools and better color palette provided by 1st Page 2000.

[UPDATE] In 2006, the people who brought you First Page 2000 released a new version, after all these years. From comments around the web, it appears the new version is no better than a Beta Release, perhaps not even as stable as a “release candidate” version, rather than a reasonably well tested stable release. Apparently, new features abound and the latest version of First Page WILL be a good program, but not until later releases clear up a lot of issues.

Be aware of three apparent 1st Page 2000 bugs:

• The word-wrap bug, of course. When you have two or more HTML files opened, the program forgets to wrap sentences to fit the screen size, and you have to click the icon for “word wrap” each time you flip back to one of the documents. (Arachnophilia does not have this problem)
• 1st Page 2000 apparently has a memory leak that becomes critical after several hours of editing. My system slowed down markedly, and other programs won’t even load after a while due to not enough memory, and I have to reboot to prevent a lockup./li>
• The final apparent bug is that 1st Page 2000 chokes on HTML files larger than about 25K to 30K and won’t “preview” changes in those large files.

About the “Preview” feature of HTML editors

“Preview” is a feature of just about every HTML editor or web development package. The program tries to act as if it were a web browser seeing your working page, showing you what browsers would see on the screen in real time as you make your edits. But in my experience with Dreamweaver, Ist Page, and other programs, the Preview feature did not work to my satisfaction (some styles do not show up in Preview mode, for example) and Preview mode seems to cause crashes.

So here is what I do now, when I edit an HTML page and want to preview it while I edit it: I click the filename in Windows Explorer. This loads the file into my web browser (FireFox since 2004). I then load the file into Arachnophilia as well. As I type this sentence using Arachnophilia, this very page is still loaded into my web browser which is minimized down on my toolbar. After I complete this paragraph, I will Save the changes in Arachnophilia. Then I will maximize my web browser and click “Refresh”. I will then see this page, with my changes, exactly as web users will see the page. My PC will not crash, and I will see every style intact. So there is no need to use any HTML editor’s “Preview” feature, in my opinion.

Testing your pages in multiple web browsers

I have a bunch of web browsers loaded onto my computer. Do a Google search and you will find many places to download the browsers. The main 3 that I test in are: FireFox, Netscape, and the worst of the bunch: Internet Explorer. [I use Firefox for all my web browsing now]. I also have other browsers, and I sometimes look at my pages in those as well, but I don’t write code to try to optimize the way other browsers see my pages, because those other browsers are very rarely used by anyone who visits me. The easy way to see pages in other browsers is to put a shortcut to the browsers in your “Send To” menu. Then just Right Click the filename and SendTo Netscape 4.7, for example.

How did I make the time to build this website?

Once I decided to commit myself to learning, it was easy to make the time. I just chose to forego spending leisure time on some other activities for awhile that took up my spare time outside of work. It took about 6 weeks of spare time to do two time-consuming initial things: learn some HTML coding and build maybe 10 or 15 basic articles to justify launching the site. Then I had further ongoing problems with the need to recode, and so I spent time in the early mornings learning and tweaking, and also writing new articles. For one example of a long project, I wanted to add a menu bar to each page. It took a long time to pull that off, since I was a novice.

Thereafter, the learning process is ongoing but tightly focused on solving very technical questions I might have. I write articles in the early mornings and late nights mostly, and post them periodically. I still tweak something on the site almost every day, whether it’s an edit to an old article or a coding change. I might do a major update or play with design changes on an entire weekend day if nothing else is going on.

The conversion to WordPress in 2006 was a big deal, and I avoided it for ages. When I finally got the courage to dig in, it went pretty much like the original coding had gone. It was a steep learning curve, and I had to focus hard. I also had to work every day, just like in 2002. Sleep went lacking a bit, because it’s important to stay focused when you get into a coding rhythym, as programmers will tell you. After a time you reach a coding goal, such as completing a module or feature, and then you can relax a bit. It took about 6 weeks to get TimsLaw.com sufficiently re-coded to permit the first Live Test.

Loading time issues – [UPDATED]

The time it takes to get a page loaded is a constant headache for webmasters. The more images you use, the longer it takes to put the page together for the visitor. The more CSS style files, the more time. And NOW with PHP and database-generated articles, the times are through the roof sometimes!

My new PHP version of TimsLaw.com crawls along compared to the fast loading times of the pure old HTML site. I’m working on a solution to this problem. The solution costs money of course – I have to buy time on a better webserver, with fewer co-tenants sucking up the resources of the computer and making my visitors wait their turn.

In the old days, when broadband was not prevalent, I was paranoid about loading times. Back in about November 2002, as my traffic increased (due to search engines finding my site), I became aware that a lot of people seemed to not be waiting for the site to load. I had overlooked the download-time required for each visitor to grab 4 files for each page (the page, then my scales GIF, then the @import file, then the CSS file). The CSS file was huge, at 22K. Total= 4 files and about 60 K for the front page, even more for other pages.

After I became sensitized to the problem with excessive download times, I had to begin working on solutions. I played a lot in the background, at home, with ideas. Finally, as 2002 ended, I was ready to do a major overhaul of the coding. I talk a lot about the coding changes in my ancient Redesign notes article. I greatly pared down the CSS styles I used, incorporated the CSS styles into each page and dropped the @import trick. I worked a lot to pare down my Front Page. I am still playing with ideas for redesigning the Front Page. I’m gruntled with the Front Page (as in not dis-gruntled), but I’m never satisfied.

AND THEN in 2005 I pulled the CSS styles right back out of each file and established a separate CSS file once again — go figure. See the Redesign article for more. The reason I again went to a separate CSS file (and still do), is that it’s just so dang EASY to change the appearance and style of the site. You edit ONE file, and presto, the entire site changes.

Let’s talk about SEARCH

For almost 4 years, until April 2006, I used the free Search Provider Atomz. Atomz provides an effective basic search capability, missing some bells and whistles, in exchange for putting their logo and some ads on the search results page. The search page and the results page are fully editable by you to fit into the style of your site.

It was hard to find Atomz when I went looking for a free search capability, because they don’t heavily pursue the free search market as others do, but I think Atomz WAS one of the best of the free search providers. Why do I say WAS? Well, at some point Atomz started to place ads on the Search Results page, as payback for the search service. For the first couple of years, there were no ads.

I don’t need Atomz now. My WordPress version of TimsLaw.com has a built-in basic search capability, which I improve upon dramatically with open source plugins from independent programmers.

Google offers the ability to put a search box on your site, to search your site. HOWEVER: Google is not searching your site. Google is only searching its own database of things from your site that it has previously indexed. New content and new modifications to old content might not be in the Google database for a long time, and hence will not be searchable by your visitors.

Timeline of the evolution of this website

Take a quick look at my Site info page, and scan down to the lower half of the page, and you will see the timeline of the major evolutionary steps in the development of this site, and some of my future plans for it.

ESSENTIAL RESOURCES
For Building and Managing a
technically simple
Do-it-yourself HTML website

• HTMLhelp.com for all the details about HTML tags and coding
• Validate your HTML code from HTMLHelp.com – Validation helps with debugging, even if your pages don’t “validate” to perfection. My pages validate to version HTML 4.0 Transitional at last check. But each time you edit you can introduce some errors, so periodically I re-validate.
• Validate HTML code from w3.org – These two validators I’ve linked to allow you to validate either your actual website pages or your PC-based pages before you have uploaded them.
• Learn about Cascading Style Sheets (CSS) from w3.org
• Validate your CSS stylesheet code from htmlhelp.com
• Validate your CSS code from w3.org – My CSS code does not validate. When I had valid CSS code, it trashed some browsers. Current non-validating CSS code seems to be ok.
• Check your links from a web-based interface at w3.org
• Offline link checker – Download the free Xenu link checker  Xenu will check your internal links off line. It will also go online if you wish and check your external links.
• Grab the free HTML editor 1st Page 2000 from EvrSoft
• Grab the free Arachnophilia 4.0 HTML editor – rivals 1st Page 2000 and is somewhat more stable

  I have not tried the “Java” version, Arachnophilia 5. I use 4.0, which is the old Windows version. Arachnophilia 4.0’s color selection palette is too limited and its site management tools are less robust than 1st Page 2000. Arachnophilia is great for editing HTML pages, but not great for designing and developing websites.

• Mozilla Firefox – world’s best web browser
• Get a free template for your website to get you started, from Snakeye Web Templates. The Snakeye Template that got me started was a conservative three-column model, Free template 17. You can also buy templates at Snakeye for a very reasonable price. Ignore all the stuff about Dreamweaver that Snakeye talks about, unless you want to use Dreamweaver, because the main part of each template is simply HTML code and can easily be edited in Arachnophilia to customize the template for your site.
• Get Search and Replace 98, a free utility to update all your pages in one swoop

  SR98 gives you a functionality on small websites roughly like using “templates” with Dreamweaver, in that you can update, in one pass, all pages that have identical blocks of code, such as for a menu, etc. You Search for the code block, and Replace with a new code block. The key is that the code block must be identical for the search and replace to work. But the more pages you have, the more likely it is that an extra space or line break or character appears in some code block, perhaps accidentally introduced by you during an edit of the main content of the page, and that file will then be skipped by SR98 in the next update of the affected code block (requiring a manual edit). Works well for small sites with pages that have common design elements.

• During the process of learning HTML (which is ongoing), whenever I get stuck I just go to Google.com and type in a description of the problem. I usually find my answer within a few minutes.

TimsLaw.com is now a PHP-based website using the WordPress open source content management system.