Any developer who has worked on a job for a corporate client of any reasonable size, has probably had to wade through some documentation as it pertains to the final presentation of their project. Companies want to make sure that whatever you do for them matches everything else, it’s vital to their livelihood that their image doesn’t get diluted by designers and developers trying to push the envelope.

Although it can be frustrating and annoying, it also gives a designer/developer the freedom to avoid getting mired in the details of the interface (even though many of us love designing interfaces). Taking a page from the corporate world (no pun intended), establishing a set of rules can make a developer’s life easier.

These rules should be created for two important reasons. First, working with other designers and developers becomes easier if they are all working from the same playbook. Second, by providing the rule book to the client before work begins, the client can feel better about the decisions of the developer (they will know that the process has been well thought out, and that there is a reason for the decisions of the developer).

Starting Out

Any developer that has been asked by their client to explain why he/she did something in particular already knows a number of the rules that should be established. I broke my own rule book into six main sections:

• Overview
• Design
• Accessibility
• Usability
• Browser Compatibility
• Coding Practices

Coding Practices is by far the largest section. It includes six sub-sections (General, HTML, CSS, JavaScript, Database, and PHP).

Building on a bad thing

Every time that I run into a conflict with a client or another developer that isn’t covered in my manual, I/we decide on a solution, and it goes into the manual for future reference.

Evolve the rules

Every so often (3-6 months) I read through my rule book to make sure I agree with everything in the rule book. For instance, one of my rules is minimum screen size. In my last read-through, after a little investigation, I decided that 1024×768 is the new minimum size that I would begin working within.

Samples

Here are a few rules from my book:

• All code/layout for publicly accessible pages should be built so that Internet Explorer 6.0, Firefox 1.0, and Safari 1.5 all act similarly.
• CSS styling should only be implemented using linked files.
  • Inline styles should not be used
  • Style definitions in the head of the document should be avoided.
• Forms should always be validated on the server side.
  • JavaScript form validation is a nice extra, but data from the client should never be trusted to be valid.

This entry was posted on Wednesday, December 20th, 2006 at 3:04 pm and is filed under Technique. You can follow any responses to this entry through the RSS 2.0 feed.