We are at the stage in the project where we no longer own the code. Ownership is now with QA is it goes through a series of test environments on its way into production. Our customer is QA and their accounting mechanism known as bugs. Anything that does not match the spec, or customer expectations will be ruthlessly, and rightly, entered as a bug. As a consequence the code repository exists for satisfying those demands.
Via gui.tavares on flickr We changed our view of quality for this project, incorporating the visual demands as an essential and integral part of the quality process. Previously we scheduled time at the end to do it all and due to the inevitable engineering pressures some of it squeezed out the wrong side of the project - ie was omitted.
The developers that were better at CSS produced high quality components, whereas those that were weak produced decent ones visually. CSS is not my strong point, unfortunately I am more the developer, but this was the reason for focusing on the visual side of things early on - otherwise developers just do code and algorithm and aesthetics are an after-thought.
From the customer's point of view though it is the first thing they see and the first impression they have of the product. Hence the focus on visuals and aesthetics early on in the quality process.
(reply)
