HWG-News Tips Late June 2000

Taking Over Another Author's Site

HWG-News features member-submitted "tips" in each issue, in the space between articles and announcements. These were the tips submitted for the 19 June 2000 newsletter, for the following category:

Taking Over Another Author's Site

In today's job market, new web developers will often be required to take over existing code... often when the original author(s) are long gone. What are some methods that can help ease the pain of having to take over existing code, cleaning it up and making it more maintainable?

This issue's winner!

1. MOST IMPORTANT: Back up the entire old site to floppy or Zip disk! You might miss something.
2. DON'T GET COCKY. Quite often a new author will flame a site design only to find they are not insulting the author but the customer... OOPS!
3. DESIGN THE NEW SITE AROUND THE OLD CONCEPT. Quite often the customer's original ideas are there, they are just too hard to find. Look for the core concept of the original site and rework it -- not only it will make your job easier, the customer will most likely say "now THAT'S what I was trying to say!"
4. CROSS BROWSER/PLATFORM COMPATIBILITY. Most of my redesigns are simply because the previous author refused to believe that YES, there are users for BOTH platforms and many browser visiting a site. Check all your work for cross-platform and cross-browser compatibility.
5. ECONOMICS: Finally, recode everything to make use of common files and CLEAN HOUSE. A neat and well-formed directory structure will help lend to a terse and effective site.

-- Submitted by Bill Snowman <bill@nytebyte.com>

Other Tips for Taking Over Another Author's Site

When you take over a website from another webmaster, make sure any code you write contains comments. Comment everything you keep from the old webmaster as well. Not only will it be easier for another person to follow what you wrote, it can help you remember what you were thinking when you wrote your own code six months ago.

-- Submitted by Ramon Campos <ramon_campos@hotmail.com>

If it is a contracted project, make sure you have a local copy of the site BEFORE you make your bid.  Make very sure there is no hidden programming you will have to deal with.  We have received a few projects because the last webmaster couldn't finish the job.  This is usually due to a problem with a code in the beginning of the process that corrupted the end product.  It is no fun to reverse engineer a site, especially when it is on your dime.  Make very sure you know exactly what your headed into before you put a price tag on it.

-- Submitted by Joel L Compton <joel@3riversweb.com>

I am kind of new to the world of web pages, but could you copy the visable text that is on each page to a web editor, like front page or something, and let it clean up the mess, Errr differences of opinion about how the page should have been written? And then move any graphics in as you progress.

-- Submitted by Pan Piper<pan_@hotmail.com>

Don't change page addresses just because you like your own page titles better. You will lose any links already established by search engines.

-- Submitted by Joe D Williams<joedw@webtv.net>

If the site is really awful, don't try to patch the existing framework. Strip out the usable text and any usable images and set them aside.  Create a "new site" (perhaps with CSS), then reintroduce the usable content and images.  It will be less painless in the long run, believe me.

-- Submitted by Jim Peden <jim@middlebury.net>

I have not normally submitted tips .. however I do have a couple of suggestions ..

I have had to take over several sites that were written by people who used Front Page and  Hot Metal .. It seems that every authoring tool has its own quirks and those who are writing sites have their own way of doing things .. If I plan to continue to keep up these sites - I re-write (edit) the site to be closer to the way I write pages (and charge the customer accordingly) - or - I bid to re create a new site - it seems to be more favorable to crate a new site and sometimes could be about the same cost as editing an old site ... as for the pain of cleaning up code (The biggest problem seems to be dirty JAVA) - not much eases the pain created by others.

-- Submitted by Dan <dmitzy@ucinet.com>

When taking over another author's code,   Make a copy of the site and put it in a separate folder.  Only make changes to the copy and verify it works before publishing it to the original. Study the code and try to determine what the previous author was doing before you make changes.  It helps to add border="1" to each table in order to see the layout more clearly.  Use the Comments tag for instructions to yourself or to explain a specific area of the code.  

-- Submitted by Joanna Wright <jowright@iglobal.net>

A subject dear to my heart, even if I'm the person editing my own code after many months (and I need a few moments to get re-oriented). My pet methods:

First , the basics...
[1] UPPER-CASE TAGS and lower-case attributes; few things are more annoying than wading through acres of code that all looks the same. Upper-case tags and lower-case attributes make it easier to separate one from the other.

[2] Progressive table indents accompanied by thorough commenting; this is crucial to keeping track of where you are in a series of nested tables. Cells and headers are always indented one tab stop further than their rows and tables.

[3] Block tags (H1, P, BLOCKQUOTE, UL, etc.) always start on a new line, at the same level of indent as their parent table cell. This also applies to line breaks. List elements are indented one step further than their parent.

[4] Paragraphs and lists are always closed.

[5] Table (WIDTH, ALIGN, BORDER, CELLPADDING) and font parameters (FACE, SIZE, COLOR) aren't left to chance; they are always spelled out even if the page features a style sheet.

[6] No extraneous spaces between lines of code (except when commenting, per above example); I like to have as tight an overview as possible over the sections. And no spaces between parameters and their attributes e.g. SRC="images/nav.gif" instead of SRC = "images/nav.gif"

[7] Attributes are *always* quoted. This prevents some older browsers from misinterpreting table width values expressed in precentages. It also helps differentiate parameters from attributes. The only drawback is that if you miss one quotation mark, the rest of the page is hosed.

[8] Parameters ought to be in the same order within tags e.g. TABLE WIDTH= ALIGN= BORDER= CELLPADDING= CELLSPACING= BGCOLOR= or FONT FACE= SIZE= COLOR= or IMG SRC= WIDTH= HEIGHT= BORDER= HSPACE= VSPACE= ALT=.

When a page is coded this way, I have a much easier time tracking down gremlins and weird behavior. It also ensures maximum cross-browser compatibility, IMNSHO. Unfortunately I have yet to encounter a WYSIWYG editor that delivers, which is why I stick to my trusty WebEdit v2.0 (now four years old) for digging into code (and making easy work of global Search and Replace!) and leave the fancy (Flash, JS) stuff to Dreamweaver.

-- Submitted by Stanislaw Chalicki <stan@webitinteractive.com>

Give the site a thorough once-over to figure out the general organization. Then while still keeping the same basic look, make gradual improvements to the site.  (i.e. Replacing yucky pixelated graphics with a sharp cleaned up version.)  That way the site isn't out of commission while you are working on improving it, and it's not too jarring to the users who are happy with the site the way it is.  A global search-and-replace feature in your web development software is very valuable.  That way a bit of pesky code that the original author used on every page in the site, can be searched and replaced with one action. You'll still yearn for to do the major overhaul -- but the site will be usable in the meantime.

-- Submitted by Diane Jackewicz <djackewicz@state.de.us>

Most of us take the attitude that we'd rather start from scratch than take over someone else's code, whether it be Perl or HTML. But, if you approach it methodically, you can separate the wheat from the chaff and develop a site that you can be proud of.

1.  DON'T assume that, necessarily, the previous webmaster didn't do as good of a job as you would have. Take time to learn what you can from their work.

2.  Then, of course, it is pretty much a given that you're going to want to change some things to fit your personal preferences. Dig in and understand as completely as you can what is going on before you start rearranging the furniture. You don't want to inadvertently cause problems by corrupting the existing code. DO insert comments liberally throughout.

3.  Build a FLOWCHART early on.

4.  Categorize and define, in your own language, the modules, subroutines, SSIs, javascripts, and style sheets in the existing site so you can modify or replace them with your own tried-and-true routines.

5.  Keep a POSITIVE attitude... negativity only increases the probability of failure, and your customer's opinion of you will not be enhanced by your whining.

-- Submitted by Chuck Lund <l@l.nu>

When taking over another author's site, plot a site map of the links to each page.  This will help you to get a feel for how the site flows for the user.

-- Submitted by Melinda Davis <MelMD2003@juno.com>

1. Become very familar with the structure and layout of the entire site by reading it through.

2. Make minor fixes immediately to see if a pattern of errors occurs (e.g. the old webmaster never nested tags consistently).

3. Automate whatever corrections you can, through programming or validation tools.

4. Avoid making major changes (e.g. new navigation structure) to the code at the same time as fixing the original site.

5. Document everything for the person who will be there after you.

-- Submitted by Michael Clark <mclark@homemail.com>

Be willing to burn the website to the ground and start all over again using site management techniques.  It's often faster than trying to repair a site with lots of problems.

If you do try to simply clean up an existing site without rebuilding, be sure to use all the "html cleaner" utilities you can find, such as Dreamweaver 's  "Word html cleaner" and BBEdit's "PageMill Cleaner". Run link checkers and Bobby too.

-- Submitted by Ellen Guttadauro <elguttadauro@ucdavis.edu>

If it's a corporate site, try to get your hands on the webmaster's computer.  You must capture the work already invested in collecting and processing content. Even if you plan to recode from scratch, you'll need those content files.

Avoid the extremes in the code takeover. Someone invested a lot of time in that site, but he/she did it his/her way, not yours. Study the site hands-on, offline, looking for includes, style sheets, logos, and other common elements. Aggressively comment points of interest and concern in that offline copy.

Better yet, take a job where the website is adequately staffed, and no great mysteries result if one code jockey hits the road ...

-- Submitted by Joel E. Tucker <jt@BootUp.com>

The first three contracts I secured were internet directory repair/reconstruction jobs; I have also often been hired to fix specific parts of sites for small business owners who would like to manage their own site, but their plans exceed their knowledge and experience. My advice is to contract specific tasks initially -- in writing --because it is so often the case that one new format will give the client new 'inspiration' and it becomes unclear when the work you've agreed to do is complete. Contract changes in the graphics separately from the code. Also, do not change a single tag until you've burned a copy of the existing site on a CD for them; it is a useful reference point in comparing the changes you've made to the original site.

-- Submitted by Marguerite Carr <marguerite@decaelo.com>