Carl just sent around a link at work — evidently I made one of the ‘past participants’ quotes for @media 2006.

note to self… re-read comments before sending. Can a conference be ‘affirming’?

(from http://www.vivabit.com/atmedia2007/europe/ - the quotes rotate)

One of our Human Factors Engineers just asked us to compile a list of “what makes good code”. He had a few initial suggestions, and they were added to for the following list. Although I think we are aware of certain principles, how do we create a checklist of what is “good” versus “poor”.

1. The code is valid
2. Inline comments are used consistently and effectively
3. Alignment and structure of the code display allows for easy scanning and reading
4. The code is accessible
5. Tables are not used for layout
6. CSS is used appropriately via an imported style sheet, a linked style sheet, or styles in the header (in that order).
7. The code is as slim and compact as possible
8. The code uses semantic markup
9. Inline styling and scripting is kept to a minimum
10. Graceful degradation is kept in mind

Today we are having a meeting with the visual designers to set out ‘theme names’. I am working on developing a library of UIBuilding Blocks, and will be using these themes to categorize the display. So far I’m looking at using xml, xsl and css, and have already had some fun in trying to tweak the xsl to get the different designs we have already established.

I definitely see merits in this, but it will take some time to get it right! Once it is in place, however, I definitely foresee many benefits!