Working practices
Here’s a rough guide to some of my practices in the web development process:
Requirements and quotes
Some projects are more suited to an hourly or daily rate; some are more suited to a fixed quote. In general, the clearer the requirements are specified, the more able I am to give a fixed quote.
Some projects will be complex enough to require a separate specification stage (usually referred to as “scoping”), which I will bill for, although I usually only work on this scale in partnership with companies who provide full project management services.
It’s important for clients to understand the necessity of spending some time pinning down requirements at the start. It establishes clearer boundaries for the work being undertaken, and prevents expensive misunderstandings further down the line!
On smaller projects, my usual practice is to give a fixed quote, but also to agree on an hourly rate. I keep track of my hours, and if it looks like the project might start overshooting the quote, we discuss. If the scope of the project has quietly grown since my quote, we’ll discuss how much extra work this’ll involve. If the overshoot is generally down to me, I’ll usually take the hit.
Either way, I rely on honest, friendly communication with clients, and it usually serves us both very well.
Coding
I’m happy to work with your own requirements for validation, accessibility and semantics in my XHTML/CSS work (if you have any!). But unless otherwise specified, there are my “baselines” for web page design and development:
- I will usually try to work to the XHTML 1.0 Strict markup standard, though sometimes XHTML 1.0 Transitional is useful when minor compromises are necessitated by a design.
- I always try to use CSS positioning and floats in my layouts, in order to keep the main content at the start of the underlying markup. This improves accessibility for when pages are accessed without CSS, as well as improves search engine rankings.
- I usually use a particular hack to selectively serve CSS to recent browsers. This means: all Mozilla-based browsers (like Firefox), Internet Explorer 5.5+, Opera and Safari. This represents a vast proportion of the current browser market, and catering only to these browsers significantly simplifies development. I’m happy to cater for older browsers (for instance, by serving simpler CSS to them), but this will entail extra costs above my usual development costs.
- My usual development practices always bring my code to WCAG 1.0 Conformance Level A, usually to Level AA. Level AAA is often acheived, but specifically achieving this usually involves careful work with content development as well as code development (which I am happy to advise on).
