Archive for December, 2008

Intrepid mini-note comments

Monday, December 22nd, 2008

I have now been using Ubuntu 8.10 (Intrepid Ibex) on my HP 2133 mini-note for about 6 weeks, so here is the progress report.

Overall everything seems to work reliably and the machine has done stirling service. I have even done some photo editing in GIMP and am in need of 16bit TIFF support (hint hint).

The best improvement in 8.10 over 8.04 is more reliable WPA. I no longer have any problems with the WPA Supplicant getting lost on resume from hibernation. In fact, the whole wireless thing is much better and connection to my home network is very quick. As an aside I plugged a friend’s Sony Ericsson K610i in to USB so as to charge it and Gnome Network Monitor immediately reported a new mobile internet device. It doesn’t work with my P1i though – I have to use Gnome PPP manually as described previously.

Hibernation and suspend both work reliably – there is some complaining about CPU clock assertions but it ain’t broken anything yet.

I have gone back to XFCE. I like XFCE, it is simple and light(ish) but does all the business. I was tempted by the ancient charms of blackbox (I think I was in a retro mood – I used it extensively several years ago) but succumbed to the ease of use of XFCE! I can report a marked improvement in general application performance, especially application start up, using XFCE rather than Gnome.

The marked drop off in battery life I remarked on after first upgrading to 8.10 seems to have been a glitch. I am back to 90-100 minutes of use (including wlan) from a full charge on a three cell battery.

I still have to use a cable to get mobile internet (3g) via the Sony Ericsson P1i. This is actually not a major drawback given the amount of juice pulled from both batteries when using bluetooth. Using bluetooth the battery guage on the P1i falls quicker than my old 4.1l Cortina’s fuel guage on a fast blast along the Hume.

The only part still displaying any problems are the Via chrome drivers. The Beta version of 02 December runs fine in 2D mode but compiz cannot be enabled. This is not really an issue for me as I have stated before, but it is worth knowing. Openchrome doesn’t work.

So all in all, a good upgrade and a much better experience than Vista (which was painful) or XP (which is generally horrible anyway) on the little beast.

How to build a form – Part 2

Sunday, December 21st, 2008

Part two – labelling, messaging and moving those evil legends

At the end of part one we had a form which tasted a lot like 1994. It has controls with labels all inside fieldsets but looks pants. There are a few simple steps in tidying up.

Legends

Legends are notoriously difficult to style. So I don’t even try. I wrap each legend in a span and style the span. It really works. This is particulary important for legends which are eventually going to be the visual equivalents of labels. These are legends for mult control groups such as a set of radio buttons.

Label text and required markers.

If a field must be completed we should tell our users. This is often done using an asterisk. Why? I have an interesting alternative to the ubiquitous and meaningless asterisk. I use the word “required”. Weird I know, but hey, it works and is WYWIWYG (what you write is what you get). To get these required markers to work, and allow separate styles for the label, required marker and error messages, I wrap the label text in a span and the required marker in another span. I also use the label as the required marker for scripting the validation.

This is overkill but is based on a trick I picked up from The Man in Blue. We eventually have something that looks a bit like this:
<fieldset>
<legend><span>About you</span></legend>
<div>
<label for='firstnameField' class='required'>
<span class='labelText'>First name:
<span class='requiredmarker'>(required)</span>
</span>
<input type='text' name='firstname' id='firstnameField' value=''>
</label>
</div>
</fieldset>

So far all this has done is make a mess of the markup without improving the form. Bare with me – we will get there.

Design classes

We need to add a few classes to labels and controls to hang our CSS from. If every browser supported attribute selectors we could omit some of these, but we live in a less than perfect world.

I like to set all text controls to a common width. However, there are some times when this is inappropriate (date of birth fields for example). So we need a class to apply to inputs which will have this common width. We will be making labels display as blocks, so we will also need a class to put radio and checkbox labels back to inline.

So now I have a whole pile of excess markup but a form which is usable, accessible and very flexibly stylable. The CSS then becomes a lot of fun, but that is for another instalment

Example – for a more complete example see Amnesty’s membership form

<fieldset>
<legend><span>About you</span></legend>
<div class="controlSet">
<label for='firstnameField' class='required'>
<span class='labelText'>First name:
<span class='requiredmarker'>(required)</span>
</span>
<input type='text' name='firstname' id='firstnameField' class='input' value=''>
</label>
</div>
<fieldset>
<legend><span class="labelText required">Required grouping</span></legend>
<div class="controlSet">
<input type='checkbox' name='subscribe' id='subscribeField1' value='1'> <label for='subscribeField'>Label 1</label>
<input type='checkbox' name='subscribe' id='subscribeField2' value='1'> <label for='subscribeField'>Label 2</label>
<input type='checkbox' name='subscribe' id='subscribeField3' value='1'> <label for='subscribeField'>Label 3</label>
</div>
</fieldset>
</fieldset>

Forms – a standards based how-to, part 1

Sunday, December 21st, 2008

I had a phone conversation with Russ recently. He was surprised by a form on the Amnesty site. So I thought it might be worth an explanation.

Just so you know though, I am fundamentally a minimalist. I don’t like excessive design and excess mark up makes me quiver. I also think the mark up in these forms is a bit excessive.

Part one is about the markup of a form. I will base this on a rather complex example, that of Amnesty’s membership form. This is because this form has all my common building blocks in one form.

Basic controls

First of all, create your form and controls without any extraneous mark up. Text controls get wrapped in their labels, though I don’t do this with radios or checkboxen. I also place label text before the control except for radios and checkboxen where they go after the input.

Example 1: two fields with labels

<label for='nameField'>Label <input type='text' name='name' id='nameField' value=''></label>
<input type='checkbox' name='subscribe' id='subscribeField' value='1'> <label for='subscribeField'>Subscribe to our newsletter</label>

This is going to give you a form which is pretty much unusable as well as extremely ugly. The next step then is to break each control set (control and label) into separate lines. You could do this with CSS. However, this will result in a mangled mess for browsers withh CSS turned off. So here is my first bit of extraneous mark up. I wrap each control set in a div.

<div>
<label for='nameField'>Label <input type='text' name='name' id='nameField' value=''></label>
</div>
<div>
<input type='checkbox' name='subscribe' id='subscribeField' value='1'> <label for='subscribeField'>Subscribe to our newsletter</label>
</div>

The result of this is a long list of controls with no regularity of positioning of controls – still a bit of a mess but at least now a vaguely usable mess.

Joy of Sets

Each functional grouping in a form goes in a field set. There has to be a good reason to not use field sets, and forms which have more than one functional division really need them. What do I mean by functional division? A set of controls which map to a specific function or data set such as an addres set or credit card details. Grouped radio buttons or checkboxen also go in fieldsets. This breaks the form up into digestible chunks, provides a means for labelling parts of the form, and, with sets of radios/checkboxen, provides for a means of labelling the group as well as the individual items using the legend.

The fieldset should have a legend. I could rant for hours about legends. I really could. The legend is a cue to the purpose of that part of your form.

So we break the form up into sensible units and wrap each unit in a fieldset. I also use nested fieldsets where necessary. There are some issues with nested fieldsets and certain screen readers but they are more accessible than any other mechanism for labelling grouped radios.

What you have now is a more complex mess than before. Great if you can’t see but pretty horrible if you can.  This is the final form, functionality wise, however, so it is where part one ends.