BP Policies/Proceedures/Conventions

Please note that these policies are general guidelines that are sometimes broken when (and only when) there is a compelling reason for it.

File naming conventions

• Files are named using all lowercase characters. We don't use spaces or capital characters in file names.
• Spaces are not used in file names. Use of the underscore character is used in its place.

File management conventions

• Files are downloaded from the public server before they are worked on to avoid copying over previously conducted work.
• When uploading significant changes to a previously existing file, the old file is archived by renaming it with an underscore and the current date. For example, if we were updating web_file.shtml, before uploading the file, the old file on the server would be renamed web_file_011906.shtml, then the new file would be uploaded.
• Client files on the local BP network are backed up weekly on 3 different removable hard-drives. One drive is stored in the backup machine, it is swapped weekly to a local safe, and monthly to an off-site safe. Current anti-virus is installed on our local network and virus definitions are kept up to date automatically. The BP network operates behind a hardware firewall.
• Websites that are hosted on BP's web server are backed up on a weekly basis, downloaded to BP local network and backed up using the same process as was described above.
• Backup of Websites that are hosted on non-BP web servers is the responsibility of the host.
• Source documents used to develop websites are kept on BP's local network within the client's directory in a sub-directory called source_docs.
• CGIs are stored in whatever directory format makes the most sense for each client. CGIs are not required to be in a cgi-bin unless the web host requires it.
• When a new site is being built for a client with an existing site and the same host is going to be used, the new site is built in a new subdirectory of the existing site.

Website construction conventions

• All webpages are hand coded with a text editor
• All HTML tags are written in all capital characters
• All nested tags (like tables) are indented.
• Server side includes are used to build the template that all non-content code is placed in making for easier site updates down the road. Page files are named with the .shtml extension and the includes themselves are named with the .html extension.
• All webpages are built with special attention to load time. When possible pages are built to be 60k or smaller (including all images files and includes).
• The graphic design of websites is put together to allow the site to be built for:
  • As quick a download as possible.
  • Ease of changes to navigation in the future
  • Ease of visitor navigation.
  • A graphically balanced page regardless of viewer screen resolution. This usually means building the site using tables with some cells having their width set equal to 100%. That effectively allows for "expansion points" so the page will fill the entire screen horizontally regardless of resolution. This can take a lot of extra work to do right, but ultimately produces a far superior finished product and user experience.
• BP has developed its own perl script that is used for most online contact forms. Besides doing the obvious (e-mailing data to the client), it can e-mail custom messages to the sender, allow for required fields, give pre-filled-in prompts for missing/erroneous data, will write a time/date stamped record to a flat or MySQL database, and can assign quasi-random receipt numbers to each record.
• All work conducted of any volume is proofed by a separate staff person than the one whom conducted the work.
• All links off the client's website spawn a new windows (TARGET=new_window) so the user does not "lose" the client's website.
• All e-mail addresses in website content will be clickable with a mailto link unless we are specifically directed no to do so.
• Any time that pdfs are used on a website, the Acrobat logo should be included with a link to download Acrobat reader.
• Server-side-resizing of images will never be used unless we are specifically directed to do so. All images will be resized and optimized in Photoshop, not resized in the browser using the "height" and "width" attributes inside the "IMG" tag.

General policies

• Unencrypted passwords are not emailed.
• Meticulous records are kept of all work that is conducted on an hourly basis that details the project being worked on, and the time and date that the work was being conducted.
• Weekly updates are e-mailed to clients who have hired BP to conduct hourly work. This is usually sent out on Monday. If a Monday happens to fall just before or just after a regular billing cycle it is skipped that week. Hourly work is billed monthly on a net 15 basis
• Projects are assigned and managed using a web-based project mangement tool called WebCollab. Although I like WebCollab overall, I don't like how it shows task priorities. This is how I have it set up now (while reading this remember that projects and tasks are two different things in WebCollab): When you look at your home page the projects are grouped into one of five priority levels, the most urgent group at the top. Within each group the projects are listed alphabetically. It doesn't appear that there is any logic to how tasks are ordered within projects. Be that as it may, the due dates that I put down for each project are when I need a project completed. What that means to you is:
  1. The projects that are in the higher priority groups (toward the top) are more important than the lower ones. Do those first. I may change project priorities mid-stream. Don't stick with what you've been working on just because you were already working on it if a new job shows up with a higher priority.
  2. Of course, within a priority group or a project you don't work from top to bottom because the sorting is not by importance. Look at the due dates and work on the task that is coming up soonest.
  3. When a new task is assigned, look at the due date and let me know if you don't think it is realistic.
  I set up the due dates based on two things:
  • When I think is a reasonable amount of time to do the work.
  • When I've promised the client that something will be done.
  Obviously the first group is far less important than the second, but you don't know which is which when I assign work so unless you hear from me otherwise, you should assume that all due dates were promised to clients. Of course that means that it is VERY bad when we miss due dates.