Archive for the ‘Comment’ Category

Ubuntu 9.10 & HP 2133

Saturday, November 21st, 2009

A belated remark about an upgrade to Karmic Koala. Like science it works. Not a hitch. And it looks fabulous. And it is way fast (for anything that runs on that rubbish processor).

Tags: , , , ,
Posted in Comment | No Comments »

More on the 2133 mini note & Ubuntu

Wednesday, August 19th, 2009

Last weekend I had a brain spasm and installed Windows 7 on the 2133. It worked but is kinda slow, even with all the pretties turned off – the C7 just isn’t up to it. Better than the original Vista it came with though!

However, as per the title this is a few more observations on Ubuntu on the Mini Note. After toying with Windows 7 RC for a few days, and even trying to do some real work with it, I re-installed Jaunty last night. Just a full clean install of the standard downloadable DVD image with one exception – I use ext4 (though I know it works fine with the regular ext3 file system). Every thing worked fine.

I then applied my mods to xorg.conf to use openchrome. Again everything is fine.

I am not a hardware expert. I do not rebuild drivers or kernels any more. I use Ubuntu after all these years because I am now too old, too lazy and far too busy to fiddle around with recompiling stuff. All I can say is that on an Australian HP Mini-Note 2133 with the AMD C7-M 1.6GHz processor, 2Gb RAM, 120G hdd and the model with bluetooth, 802.11a/b/g wireless and 10/100/1000 Mbps ethernet everything (including vga out at 1280×768, internal microphone & mic socket) appears to work fine out of the box except openchrome which needs a TINY fix to xorg.conf.

I have used Vista, XP, Winbdows 7 and Ubuntu 8.04, 8.10 and 9.04 on the 2133 (and have considered trying to Hackintosh it but as noted above, no longer have the time) and Ubuntu 9.04 Jaunty Jackalope is the smoothest, most workingest and quickest of them.

“It just works!”

But your mileage may vary.

Tags: , , ,
Posted in Comment, Gear | No Comments »

Ten ways to annoy a waiter

Tuesday, August 4th, 2009

No one will spit in your food. Well, that is not entirely true but outside of a pub ‘bistro’ practically no one will spit in your food. So you can get over that one. Waiters are generally nice people who like you. We choose to deal with people all night when we would rather be in the pub, shagging and/or staring at the ceiling; and people are often painful. The things that really get up our noses (apart from chefs) are arrogant idiots. Australia is internationally renowned for the aggressive attitude of its inhabitants, and it always seems that lower intelligence breeds compensatory arrogance. Don’t try these at your local:

  1. Fill your water glass to the top immediately before leaving. I really don’t know why people do this but it is far more common than you would think. It makes the glass unstackable and causes an extra clearance trip. Really annoying!
  2. Order the spiciest thing on the menu and ask for it with no chilli. Obviously this will only work in restaurants which serve spicy food: Thai, Mexican, Indian etc. If you don’t like chilli don’t order it. If you are unsure, ask the  waiter it is what s/he is there for!
  3. Eat all of your meal then complain about it. If something is wrong tell them whilst you still have the evidence and it will be fixed! Otherwise shut up and leave.
  4. Try to help with clear up. Do this by piling up mismatched plates and cutlery, especially leaning towers caused by uncleared plates. Really, get out of the way but don’t try to help unless you can clear a table of eight in one go.
  5. Order only one course but sit around chatting all night. Do this whilst demanding constant refreshes of tap water for bonus points. Remember, the reason there are so few decent places to eat in the country is because you and your 7 mates go out on a Friday or Saturday night, must eat at 7pm, order 5 dishes between 8 of you, take your own booze (because restaurant markups are excessive), then sit around taking up space until 10:30.
  6. Annoy other diners, especially by being excessively foul mouthed or by allowing your spoilt brat offspring to run wild. Actually, just taking your brat offspring is enough. If you have small children they should be in bed at 8pm, not throwing food all over some poor bugger’s dining room.
  7. Leave a tip of $2 or less, or less than 5% of the total bill if you rack up over $100. Unless the service really sucks it is better to not tip at all or leave a decent tip. What is a decent tip? If the service is good 10% of the bill, if not nothing – there is no problem with not tipping in Australia.
  8. Order in a language in which you are not fluent. Bad Italian, French, Thai or Mandarin (especially in a Cantonese restaurant) is just annoying OK.
  9. Split the bill, amongst seven, demand large quantities of small change, then complain that you have been ripped off when you can’t add up.
  10. Book for 8 people or more but make sure that at least 3 fewer actually turn up. Bonus points for Friday or Saturday nights at around 7-7:30. Don’t book for a group so large that you will have to pay a deposit – 8-10 is optimal.

Tags:
Posted in Comment, Top Ten | No Comments »

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>

Tags: , , , , , ,
Posted in Comment | No Comments »

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.

Tags: , , , ,
Posted in Comment | No Comments »

Anatomy of html

Thursday, October 23rd, 2008

A mark of any group is their shared language; and a mark of any group involved in a craft is the technical precision of their language. Brick layers, dentists, lithographers and chefs all know what each other mean when they refer to a particular item. Web professionals are no different. Most of the people working on and with the web, however, are not web professionals; even some who should be are not. For those of you who are, what I am about to describe is blindingly obvious. So you can stop reading now.

A few years ago I embarked on a mission to educate the team in my day job. I got them all to refer to all the bits that make up HTML and CSS by the correct names, This was done partly so they could explain to me what they want, partly because I am a neurotic labeller, but mostly because they wanted to be professionals in their field and so needed to use the language correctly. Things, and teams, change and just this week, for the first time in over two years, I heard someone who would consider himself a web professional use the term alt tags.

There are no alt tags

Never were.

Anyone involved in web production who refers to image elements’ alternate text attribute as alt tags is a moron.

The basic unit of HTML is an element. A tag is part of an element. An element Starts with an opening tag. This is the angle-bracket stuff, and ends with a closing tag. The element is everything between the opening tag and the closing tag including the tags themselves. Self closing elements don’t have a closing tag and the element is equivalent to the tag.

Note I stated that an element is everything from the < of the opening tag to the > of the closing tag – inclusive. Therefore an element can (and often does) contain other elements. The DTD describe the allowed content for each element. For the purposes of the rest of this rant I will describe elements which require a closing tag as per the HTML 4 DTD. The accompanying image outlines all this in much clearer fashion so I apologise to anyone who cannot view it. Those of you who choose not to view it can just deal.

A representation of the parts of an HTML element

A representation of the parts of an HTML element

The opening tag may contain attributes. An attribute consists of name/value pairs represented as the name, equals sign and value, white space is ignored. In HTML 4 some attributes may be entered as singletons; that is as a name only with the value implied, I don’t consider this good practice but there is no reason not to do it. Attribute values ought to be quoted. This is required in XHTML. In HTML quotes are optional for single word values; this is really bad practice and you ought to quote all attribute values. An image’s alternate text is an attribute. Some attributes are required by certain doctypes, the alternate text attribute of an imgage element being one such required attribute.

There are some restrictions on attribute values but these are often specific to certain attributes. For example the id attribute’s value should not start with a numeric. Some parsers seem to expect some attributes in a particular order. The W3C HTML validator seems to chuck a wobbly if an image element’s opening tag has something other than a source attribute as the first attribute. This is not strictly required.

A (non-self-closing) HTML element usually contains child nodes. These may be other elements or text nodes (which is just text and is usually referred to as text except by weird DOM-nerds). White space only text nodes usually exist within a DOM tree but can be ignored for most cases except when traversing the tree.

Some elements are restricted in what they can contain as child nodes. An unordered list element, for example, may only contain list item elements as its child nodes and (in HTML 4.01) a fieldset element must contain a legend element. There are some general rules of thumb to make this a little clearer (these rules omit the possible existance of whitespace text nodes withing the DOM tree):

  • inline elements must not contain block elements;
  • block elements except the paragraph element (<p></p>) may contain other block elements;
  • ordered and unordered list elements must contain list item elements as their immediate descendents;
  • definition list elements must contain definition term and definition data elements as their immediate descendents;
  • select elements must contain option elements or option group elements as their immediate descendents and option group elements may only contain option elements;
  • uou cannot nest forms (which stuffs up many ASP applications) or textareas;
  • use your common sense!

Tags: , ,
Posted in Comment | No Comments »

Pointless protests?

Wednesday, July 30th, 2008

Today in Amnesty International Australia’s online day of protest against internet repression in China. A wonderfully long name for a silly little gag. Whoop de doo!

Except this is important.

Given that people are imprisoned, tortured or murdered for political activity on an almost daily basis in China is the freedom to do what I am currently doing all that important? Well, how do we know when other (more important?) rights are expunged, violated, swept away etc? Do we rely on Xinhua to tell us?

I was in a cab recently. The taxi driver was interested in what I do for a living and was instantly skeptical about ‘rights’ (mix rights with charity and I am immediately labelled a rabid lefty by most people I meet). My point was simple: how often do you complain about the Government? Daily? Weekly? Never – all politicians are wonderful altruistic models of humanity who do a brilliant job?

The point is, if you don’t like what pollies do you can complain. At worst maybe occasionally you will find yourself being ridiculed on today tonight. You won’t (in Australia) usually find yourself in prison or getting a bullet to the back of the head (we are discussing politicians here – police officers are a different matter).

So express yourself and make all the noise you can. Because you can. Which is a right worth fighting whining for!

Tags: , , ,
Posted in Comment | No Comments »

Content counts

Sunday, June 24th, 2007

When was the last time you put out a product brochure or press release without thinking about what it said?

When you create a prospectus or sales brochure you get the copy written by a professional – either in-house or a contracted copywriter. Do you put that amount of care into the copy on your web site? If so, well done you can ignore the rest.

Your web site may be the first contact a potential business partner or customer has with you. It should get far more readers than your paper material. So you should put at least as much resource into getting the copy right.

Web copy is different from print copy. It works differently. People interact with it differently. It needs to behave in many ways unique to this medium; not many brochures get syndicated and refactored for delivery on other brochures in real time without you knowing it do they?

Your copy must stand alone. It carries your message. It sells your property, fills your leases and shifts your units. If it doesn’t do the job sitting typed on a side of A4 it won’t do it on your web site – no matter how cool your designer thinks s/he is.

Make sure the copy for your site does what you need it to do, wherever you get it. Only then think about enhancing the message with design. Once that is done you have the core of a web site, so start improving conversion through experimentation and structure. Once all of that is done you can think about web toys. By then you may not want them.

Posted in Comment | No Comments »

WYSIWYG – ha!

Tuesday, June 12th, 2007

online editor
an early editor built for edsys

It is a little known fact that I wrote one of the earliest JavaScript WYSIWYG editors for IE4. It sucked. But it was better than anything else available at the time. It even did tables and forms (wow, I hear you ironise, but this is going back 6 or 7 years).

The little embedded WYSIWYG editor tries to make the transition from nasty word processors to nasty web pages easy for people. They fail pretty much without exception. Part of the problem is that browser implementation sucks; part is that website and CMS developers suck (yep, that’s me); and part is that content producers are lazy hacks.

The main issue though is that online what you see is never what you get. And nor should it be. Even if all browsers rendered HTML and CSS according to a properly written and unambiguous specification we would still have variation in appearance. Screen resolution, default fonts, viewport size, other types of user agents, user style sheets, the list is endless.

What can we do? Well first of all, live with it. Variation is not just inevitable it is a good thing. Make content clear and free of formatting so it can be refactored and rendered by all sorts of user agents. Get CSS to do its job. Use something like Markdown or Textile instead of a WYSIWYG editor and live with the limitations.

What can content producers do? Write well using language for emphasis, source appropriate media and structure your content for maximum impact. This makes the silly formatting tricks which are the province of the WYSIWYG editor unnecessary. Plan your content and introduce some consistency; this helps usability as well as making the publishing process easier. Finally, learn just a little bit of whatever flavour of (X)HTML your site uses. The content producers at AIA use a small subset of XHTML 1.0 and hand code almost everything. They are writers not web developers. They know enough to get the job done, rather than enough to be dangerous.

Posted in Comment | No Comments »