Proof of Concept
Here’s a quick example of what I’m talking about. I’ve used Photoshop as the example application as it is the closest thing I use to an IDE, it is the program I have been using the longest (as of next birthday I will have been pushing pixels for more than half my life!) and it is far and away my favourite piece of software. Element names have been made purposefully verbose to ease readability .

Below is a snippet detailing how basic preferences could be stored:

<preferences>
	<preferencegroup>
		<name>General</name>
		<pref name="color picker" value="Adobe" />
		<pref name="interpolation" value="Bicubic Sharper" />
		<pref name="history" value="30" />
		<pref name="export clipboard" value="true" />
		<pref name="zoom resize" value="true" />
		<pref name="auto update" value="false" />
		<pref name="asian text" value="false" />
	</preferencegroup>
	<preferencegroup>
		<name>Display and Cursors</name>
		<pref name="color channels" value="true" />
		<pref name="diffusion dither" value="false" />
		<pref name="pixel doubling" value="false" />
		<pref name="painting cursor" value="brush size" />
		<pref name="other cursor" value="standard" />
	</preferencegroup>
</preferences>

Simple, yes? Now to use XML to really make a difference. The snippet below is an example of what I really wanted last Monday – the details of my desktop arrangement within photoshop.

<palettegroup>
	<height>710</height>
	<width>274</width>
	<x-pos>1292</x-pos>
	<y-pos>2</y-pos>
	<palette>Layers</palette>
	<palette>Channels</palette>
	<palette>Paths</palette>
</palettegroup>
<palettegroup>
	<height>132</height>
	<width>212</width>
	<x-pos>1571</x-pos>
	<y-pos>2</y-pos>
	<palette>Info</palette>
	<palette>Histogram</palette>
	<palette>Swatches</palette>
</palettegroup>
<palettegroup>
	<height>382</height>
	<width>212</width>
	<x-pos>1571</x-pos>
	<y-pos>136</y-pos>
	<palette>History</palette>
	<palette>Actions</palette>
</palettegroup>
<palettegroup>
	<height>218</height>
	<width>212</width>
	<x-pos>1571</x-pos>
	<y-pos>520</y-pos>
	<palette>Character</palette>
	<palette>Paragraph</palette>
</palettegroup>

This could easily be extended to include the paths to action files, patterns, brushes and other such goodies. Techniques like the above are the sort of lead the big guys should be taking from the linux/unix crowd. I’m not saying everything should be controlled via .conf files, but at least give advanced users advanced options.

Oh, in case Andrei stumbles upon this, perhaps you could mention the idea to the guys at work?

The following post may fall into the bleedin’ obvious category for many of you, but I think it needs to be reiterated. One mistake I often see is forms that are altered to meet the designer’s tastes rather than styled in an attempt to simplify the experience for the user. Tiny little search fields might look cool but they are a nightmare interact with.

Do it for the People

Forms are something that I use daily, so when it came to making my own I gave some serious thought as to exactly what I would want when filling it out. I believe balancing the point where the design hat comes off and the usability/accessibility hat goes on is what makes a web designer; as such I consider ease of use and reliable functionality paramount when dealing with forms.

Real World Examples

An example of finding the balance came up today on the webstandardsgroup list. Someone was seeking help with a bug in Mozilla / Firefox whereby the dropdown arrow for a floated <select> was disappearing depending on the width set in the CSS. As the designer, it’s your responsibility to make sure the changes you have made to default widgets don’t cause such bugs to be triggered; if they do then the design is what must be sacrificed — not the usability.

Using the :focus pseudo-class to indicate the currently active field is a good practice, but watch out that you’re not doing more harm than good. In my opinion, if background colour changes are going to be made to the active field then the active colour should be lighter than that of the normal state. The user is reading the text in that field, so why make it harder for them? One great looking site I came across yesterday suffers from this common mistake (Ed: not anymore…). If you take a look at the comment form or the contact form in a modern browser you’ll see you would have seen what I mean. Setting the background of the current field to a darker colour decreases the text contrast and also decreases a site’s People Friendly Factor.

So what’s your opinion? As always, comments are open and I’d like to hear some different takes on the matter.

The first change that should have happened long ago was serving up real XHTML (content=application/xhtml+xml). This site is now XHTML 1.1 in modern browsers, with old fashioned SGML tag-soup being fed to lesser equipped browsers. I’ve nervously decided to also serve all my posts and comments as XML, which means that one bad bit of code in a comment will bring on the Yellow Screen of Death for the whole post. That was never going to last long!

Not Everyone Uses a Mouse

Too often designers/developers set link styling for a:link, a:visited and a:hover, and think that is enough. That is not enough. Many users, myself included, like to ditch the mouse while reading a long article and navigate via the keyboard (*gasp*! What is this, 1986?!). Jumping from link to link using the tab key is fast and easy, but irresponsible design decisions can make the experience akin to driving blind. Try it out now.

No problems, because I have set visual changes on the :focus pseudo-class. That’s all well and good, until IE comes to the party. IE doesn’t support :focus, but in traditional IE style one of its bugs can be played against another. In this instance it is the :active pseudo-class that comes to the rescue. Microsoft decided to interpret :active as :focus, meaning that any changes set on :active will be applied when that link receives focus.

Automated Testing – Home Delivered Lies

As a standard practice, I run my sites through the Cynthia and Bobby automated accessibility tests. The results for Left Justified are quite good, with only a minor warning or two in the Priority 3 (WAI-AAA) section.
What a crock.
I know for a fact that I don’t even meet all the Priority 2 requirements.

3.4 Use relative rather than absolute units in markup language attribute values and style sheet property values. [Priority 2]

That alone is enough to disqualify Left Justified from anything higher than a WAI-A rating. Yet if I wanted to, I could stick up a big ugly “Bobby AAA” button and have it link to a positive test result – but I won’t, because being a responsible web designer/developer/person (I’m using the term web person from here on in) means that automated tests are just that — a test. It’s nowhere near an equivalent to human testing, let alone a replacement.

So now all of the T’s are crossed and i’s are dotted, where are the XHTML 1.1 and CSS buttons on the footer of every page? Not here, folks.

Validity isn’t an accomplishment, it’s a requirement.