The first site completed—completed just in time for their Halloween party—was for the Lower Red Lion, a pub and guest house in St Albans.

It has 400 years of history behind it, with some visible timber and brickwork, and featured in the ITV series Foyle’s War.

My aim was to make the site as useful as possible to people thinking of visiting St Albans, and to showcase all the pub’s attractions.

I am now working extensively with typographic grids, creating pages which balance vertically as well as horizontally. This site was my first complete site to use such a grid. It was also my first HTML 5 site.

The site which I designed and developed for the theatre group Footlights Calpe is also an HTML 5 site. A bit simpler than the Lower Red Lion site, it still allowed me a few theatrical effects.

For a few more details about the two sites, you can glance through the Website notes and Design notes which accompany each display on my portfolio page.

It’s such a cliché. And yet, still true. If you want it good and fast, you have to pay. Over the odds.

Most of my clients have limited budgets. They get me cheap, and I produce at least halfway decent Web sites. Check for yourself.

I lift my glass to all my fellow professional Web designers who charge little, produce great Web sites—and whose clients keep wanting to see the Web site up tomorrow…

So I have attacked the dreadful custom of asking for ‘First names’ and ‘Last names.’ And I have put in a protest against the illogical American system of numeric dating. In this post, I tread on even thinner ice: is it ‘sex’ or ‘gender’?

In modern English and American Web forms, this not only reflects a misunderstanding of the original radical purpose behind the use of ‘gender’, it also stifles that very purpose. From being a mind-changer, it has become a system-enforcer.

In many (maybe most?) of the languages of the world, gender is a critical feature. Articles, possessive pronouns, adjectives, and so on, all have to agree with the gender of the noun. If you are speaking Spanish, you have to know that a tie (una corbata) is feminine, and a dress (un vestido) is masculine.

This gender is quite arbitrary, as my examples suggest. So radical thinkers in the early days of structuralism extended this to masculinity and femininity generally. There were no given masculine qualities or feminine qualities. It was all arbitrary.

A liberation, which led to much ‘gender-bending.’ A liberation for all of us, men as well as women. And then one day some English speakers got hold of this idea, and not understanding its origins in the grammar of other languages, decided that using ‘gender’ instead of ‘sex’ would show everyone that sexes are also arbitrary.

You might applaud the thinking behind it. However, its net effect has been to freeze what had been fluid. You can now ask people for their gender on a Web form. So it’s fixed.

You have to be an English speaker, and not very good with languages, to think that there can be a ‘male gender’ or a ‘female gender.’ So a great radical liberation has been lost. We are all back in our (check) boxes.

People who design forms for airline flight bookings aren’t likely to be reading this post. But lots of us design forms for local car hire companies, or local property agents, so that bookings can be made online. And both of these are common on the Costa Blanca.

The first point is really obvious. Don’t expect people to enter dates by hand. Give the website visitor a popup calendar for each date field. In particular, I recommend the jQuery UI date picker. You can style it exactly the way you want, and, in its recent versions, it has all the options any Web designer could ask for.

And now a free goodie. Lots of us want to set a second date picker to start at the date already set by a first date picker. I spent months Googling for a simple way to do this before I came across a solution. And this is my simpler version. (In programming, as in maths, the simpler solutions are the more difficult to work out. And the more useful to other people.)

$( document ).ready( function() {
	$( "#start" ).datepicker({ dateFormat: 'yy-mm-dd', firstDay: 1 });
	$( "#end" ).datepicker({
		dateFormat: 'yy-mm-dd',
		firstDay: 1,	// Monday, for Spanish calendar
		beforeShow: function()	{
			dt = $( "#start" ).datepicker( 'getDate' );
			return { minDate: dt };
				// JSON - dt could be 'null' (which is OK)
		}
	});
});

This relies on your knowing some jQuery, of course. But you’ll need that to use the date picker. Date field 1 has an ID of start; date field 2 an ID of end. You won’t need ‘firstDay’ at all if your week begins on Sunday. Check the date picker documentation for the other option fields.

That could be it. But I have one axe to grind. If you have to ask for dates using separate days and months, do not use the provincial American order of month-day-year, especially if you’re asking for numbers.

I sometimes wonder if the effect of their date system on their infant minds is why some Americans have such odd ways of thinking. Year→month→day (as in the MySQL format above) makes sense, going from greater to lesser; so does day→month→year, going the other way. But month→day→year? Month→day→year? It just leaps about the place, without any logic to it. 11/09/2001 is a date to make all of us feel a sense of human solidarity with Americans. It’s the eleventh day of September, 2001. The problem is that Americans write it 09/11/2001, which can only logically refer to the ninth day of November. I suppose it’s a sign of our solidarity that almost all English speakers now refer to the date as “nine-eleven.” But we mustn’t let our solidarity influence us when asking for dates in Web forms.

I filled in a Web form like this just this morning. And how did it ask for my name? (Wait for it.) First name and Last name. This is so common it’s appalling. The clear assumption (and this is proved by automated replies, which always start ‘Dear [First name],’—or even ‘Howdy, [First name],’) is that the Web visitor’s first name is their personal name, and that their family name or surname is their last name.

This is to be as bizarrely provincial as you can get. OK, in the USA and in the UK, this is common. But the majority of human beings on this planet put their family name first. I’ll say that again, in case there are any provincial Americans reading this post: the majority of human beings on this planet put their family name first and their personal name last.

At this moment a Chinese woman tennis player is going great guns in Melbourne. Her name sometimes appear as Li Na, and sometimes as Na Li. Commentators still seem to find it difficult to get their head round the name, to work out which is her personal name. I also remember hearing Americans, during the Iraq war, referring to “President Hussein.” This is like saying “President George.” Saddam was the dictator’s family name, so he put it first. Hussein was his personal name, so he put it second.

The consequence for Web form designers? It is vital that we abandon the awful First name/Last name or First name/Surname practice. Web form designers must ask instead for Family name and Personal name. That way our Web forms will be understood (and can be translated) across the planet.

I am not here concerned with the more complex colour effects you can get by creating a background image with the effects you want—gradients, radial bursts, stripes, and so on. I just want to make a small point about the use of colour names.

I have 2 recommendations to make, and I make them to the most talented and experienced of my fellow Web designers, because they don’t always follow them.

1. Use the colour names of the 16 originally defined colours: red, green, blue, etc.. It doesn’t take long to learn them. Especially, use black and white. There is absolutely no excuse for writing
   background-color: #000;
color: #fff.
2. Add a comment to any colours that you can only identify using hex (or RGB) values. After
   color: #cf2200,
   add the comment
   /* a red, from garden flower */,
   or at least
   /* a red */

Anyone who has been a programmer as well as a designer knows the value of comments. In particular, they make it easy for other people to identify your colours and your reasons for choosing them, while reading your code. And they make it easier for you, when you come back to the code a few months later.

I should mention here that modern browsers know a huge array of colour names, but I am not suggesting we need to use them, except when by chance a name identifies a shade/hue that we have already chosen. It’s better to get into the habit of adding comments.

Actually, while we’re on the topic of CSS colours, I feel like passing on a practice of my own which is not so generally useful as to count as a recommendation, but which I find really useful as a designer. And here I mean designer, not coder.

I put all my colour rules—for backgrounds and borders as well as text and links— in a separate section at the end of my style sheets. This is a bit of an irritation when coding, since I have to create the other rules for a given element in another section of the style sheet. But it really pays dividends when I want to make small changes to site-wide colour schemes. The relevant values are all together, and can be changed together—sometimes in a single rule.

Why not see if it works for you?

Unfortunately, I can’t show you either—unless you are an AFPO Calpe member, in which case you can head over to the site and log in! I suppose that means a few more people will see those pages than see my lovely designs for the Jalón Villa Rentals management interface, which only the owner and I ever see. (Actually, I could add the index page to my page designs—so you can see if it’s as lovely as I claim. I’ll put that on my to-do list.)

What anyone can see are the public pages. They are quite text-heavy, so I compensated by setting text in plenty of whitespace—actually buff—and creating what I hope is an imposing header.

This header is in part based on the AFPO magazine cover: it was from there that I got the blue and the yellow, and the overlapping titles. At the end is an image of the Peñon, with a cloud halo. I love the photo, which featured on the previous AFPO site, and still appears on their stationery. I’m not so sure about the heavy gilt lettering—but the President told me he didn’t have a copy of the photo without the lettering, and I’ve now got quite used to it.

Because of the big header, I gave the Web site a left-column menu.

I explain the background to this commission, and the thinking behind particular design decisions, in my notes on my website portfolio page. And you can of course visit the AFPO Web site itself!

And it does make a good story, with lots of false starts and lessons learned—as well as obstacles overcome. And there is stuff here to interest anyone who has contemplated moving or reconstructing a Web site. What is more, if anyone is in the same predicament, looking at a Web site based on a proprietary CMS, I have a lot to pass on.

But now I am in another predicament. I am too busy to go into the detail. To give you an idea: I have been building a new Web site for a local organisation which already has a Web site. We agreed a date in mid-March for the switch. But the organisation’s old Web site has vanished from the Web! They are now asking me if they can switch this week.

So: here is a summary of what I did to reconstruct the proprietary CMS site.

1. I created a MySQL database, together with 4 tables
2. I populated the tables partly with data that the previous designer kindly handed on to me, in the form of an Excel spreadsheet, but mostly with data that I copied and pasted from the site.
3. I created the main ‘site’ pages as static pages, simply copying the HTML that the previous dynamic system generated.
4. I created the ‘browsing pages’ with a set of HTML templates and PHP scripts.
5. I downloaded, one by one, by hand, around 800 images, including property images and icons, and put them in appropriate directories.
6. I created a PHP script that displayed any of the 70 or so properties, taking descriptions and prices from the database, and images from directories.
7. I created a wealth of interactive features: a search facility, a registration form, popup enquiry and print forms, a ‘lightshow’ image gallery, an availability calendar (for each property), and various booking forms.

At last a Web site was there, which looked very like the old one. At this point I turned to creating a new client interface, so that my client had a new personalised CMS.

As you may guess, this turned out taking as long as reconstructing the Web site visible to the public. But I was able to give my client a much more friendly and intuitive interface, with many more facilities than she had had before. (Oh, and as part of the process, I had to recreate the database tables, to make her job easier…)

I would point you to the result, but the public part of the site is only my reconstruction of the original designs, and still contains the mangled CSS and HTML generated by the old CMS.

And nobody but me and my client can see my lovely new client interface. Sad.

There is a general summary of the position on an Australian Web site. This is (part of) what they say about CMS sites:

“Content Management Systems – a mixed blessing
An alternative to a personal web designer is a CMS or Content Management System. The main benefit of a CMS is the ability to update your site yourself – within certain parameters – over the internet, and rolling all your costs into one monthly payment. But you need to go into a CMS contract with your eyes open.
1. CMS do not provide distinctive sites. They are, almost by definition, formulaic. Look at some and see what you think.
2. You don’t own your CMS site in the same way that you own a site designed by a web designer. With CMS you own the content but you cannot walk away from your CMS contract with your site intact – your site can only operate on the CMS operator’s platform.
3. With a CMS website you are locked in – you cannot change to a hosting company that provides more competitive rates or better features without losing your website.”

Point 3 in effect repeats what the English company say about their own sites.

So what was I to do when I was asked to ‘move’ exactly such a Web site, by a potential client to whom I had been recommended—by people I would prefer not to let down?

Of course I said ‘yes’. I committed myself to recreating the site, i.e., constructing a completely new site that would look just like the client’s current site, with a completely new database, a new set of scripts (PHP rather than the current ASP), all the existing images (several hundred of them) and a client interface that let her do everything she had done with the old CMS.

How did I get on in this foolhardy enterprise? Answer in Part 2.

I have a couple of Web sites in this position right now. One is for two karaoke presenters: brookies karaoke. The other is for a friend who wants to sell her unique spacious villa in Calpe. I am doing plenty of work behind the scenes, which the website owners can check out, but neither of the full Web sites are ready yet to go public.

Obviously, you can’t go anywhere further on the site from the home page of a one-page Web site—but at least you can find contact details. What is more, from a website designer’s/owner’s point of view, the minimal Web site is available to be noticed. (And, to my astonishment, Web search engines often find one-page Web sites quite fast.)