Practices and Policies

Contents

Design Considerations

Marketing and demographic issues. Screen resolution targets are sometimes related to marketing issues. In marketing to up-scale clients, for example, we might feel more free in targeting 1024 pixel-wide displays rather than the basic 800 pixels. Similarly, larger graphics take more time to download and appear on a page than smaller images. However, in a localized market in an urban area it might be useful to assume the people in your market have broadband access.

Browser compatibility. Certain effects work better in one web browser than another. As the majority of people are using Internet Explorer, our current inclination is to take advantage of "bells and whistles" visible only to Internet Explorer, but not if it means the website "breaks" when viewed through another browser such as Firefox.

See also the page on Web Design for other tradeoffs.

Incremental development

I like to develop sites incrementally at a published location (typically at your domain or at kinata.net) so that you can see and comment on current progress. The downside of this method is that some effects, formats, or content elements get implemented before others. For example, I might set up a basic menuing system so that you can navigate the website, but hold off on setting up flashy button-click effects until later.

Another method is to develop the site offline, and upload a close-to-final release candidate only when complete.

Tracking Tasks, Times, and Invoicing

I've put together an Excel tracking application that combines the functions of a task list manager, timesheet, and invoicing system. For any given task, I "punch in" at the beginning, and "punch out" at the end; task durations as reported are rounded to the nearest minute. This means that there is no minimum-charge increment, such as 15 minutes.

The tracking sheet for your project is published to a private location on the Web, so you can review current charges and get a picture of how the project is proceeding.

I don't typically charge for reading and writing email, unless requested to do a lengthy tutorial. I also don't charge for thinking about your site, which is often a significant amount of time!

I generally charge a reduced rate for programming something new but might want to use in the future, for two reasons. First, it takes much less time to do something the tenth time than the first, because you've reduced the task to a standard practice. Second, it doesn't seem correct to charge one client for R&D that will benefit others.

We're currently billing once at the start of the when most of the content is up on the site, and again when the website is very approximately 90% final. At some point after the content is all in and we're converging on the final formatting adjustments, I like to go "off the clock" and do the remaining tweaks at no charge. My reasoning is that educating clients about considerations and trade-offs in implementing web designs takes a lot of communication, and I don't want clients to feel pressured about getting what they want, and I don't want to nickle-and-dime people for minor changes.

Terms and conditions

This is a brief summary of some principles stated in more detail in our web design contract:

We charge for the time needed to create the website itself. We also charge for training on various topics related to developing a website, such as setting up new email accounts, or offering advice on digital photography, marketing, or improving your search engine rating.

You of course have copyright privileges on all text and graphic content provided by you.

You have a non-exclusive license to the HTML code, formatting, stylesheets, scripting, or other computer code used to implement the website. I retain the copyright for custom code developed for your website.

Payment is due 10 business days after invoicing.

After the website is complete and the final invoice is paid, you have a right to a copy of the website fileset.

Websites may be hosted at kinata.net until final hand-off and payment, at which time the site is moved to its final domain name. Ownership of domain names acquired on behalf of the client are also transferred at this time.

Procedures for submitting text, graphics, and requests for changes

Content

When providing new content, use descriptive and unique filenames; best practice is to append the date of the submission at the end of the filename. Examples:

new text.doc [worst]
Home Page text.doc [bad]
Home Page text version 2.doc [better]
Home Page text 2005-03-10.doc [best]

In the same spirit, please use descriptive filenames for images. Examples:

DSC1004823.jpg [worst]
painting01.jpg [bad]
Mona Lisa.jpg [better]
Mona Lisa 20050917.jpg [best]

In the case of emailing content for product items, it really helps when images are attached to the same email that provides the text. If this isn't feasible, submitted product information should cite the filenames for the images associated with that product.

Basically the idea here is the greater the clarity, the less time is spent sorting things out.

Text corrections

Be specific. Example:

On the Home page, change the sentence
"The finest in pre-Columbian artifacts."
to 
"The finest in pre-Columbian alien technology."