Skip Navigation

Probably the Worst CAPTCHA Ever Made

This weekend we stayed in an "aparthotel" for the second time in as many months. Until we booked the first stay I'd never heard of them. They're city-based apartments for rent by the night, much like a hotel, with a reception etc. The difference is you get two bedrooms and a separate living room/kitchen. The kitchen has a cooker, microwave and dishwasher.

If you have to take a family of five away with you (we were at a wedding in Newcastle) then having separate rooms makes it bearable, whereas doing the same in a conventional hotel is nothing short of a nightmare. From now on I don't think I'll stay anywhere else with the kids. We got the double room apartment on Friday for £120, so not that much more than a basic room in a city centre hotel.

Anyway, I mention it for two reasons. First to hopefully enlighten you guys. I guess you all knew about them, but if not, they're worth looking in to next time you're away with family or friends. The other reason is that I just had to pass on an example of terrible UI design from the website of the one we stayed in on Friday night, Kensington House.

Looking for a map I looked at their contact page and saw this. See if you can see anything odd:

filter

It took me a while to work out that the weird "garbage" in the contact form was in fact a CAPTCHA. Can you see it? If you pull your head back and squint you can just about make out that it says 8+9=. The white box to the right of it must be an input field.

It sticks out like a saw thumb. No less so because the site itself and the place it represents is going for the "swanky" look. This is what happens when you let a geek design part of the UI. I can imagine he feels fairly smug at having written such a clever spam blocker, but what about the poor user?!

I've said before and I'll say again - in my opinion spam is not the user's problem and so they should not be the one made to pay. That's why all spam blocking measures on this site are back-end. Not making the user pay is all the more important if the contact form is on a company website. If you run a company surely you want to make it as easy as possible for potential customers to make contact. Why make them jump through hoops!?

The other reason for this post is because it's Monday morning after the break and I need to ease myself back in to office work nice and slow.

Comment Icon 7 Comments Read - Add | Mon 5 Jan 2009 | Open »

2008 - CodeStore's Year in Review

As is tradition this time of year, here's my yearly review of happenings on codestore.

New Content

First let's see how the amount of new content I posted stacks up against previous years.

  2008 2007 2006 2005
Blogs 115 119 148 180
Responses 1822 1598 2444 2933
Articles 0 2 8 4
Sandbox downloads 4 5 0 5

The amount of blogging and the amount of feedback is pretty much the same as 2007, which is reassuring. I'd be worried if the yearly decrease in activity continued. It's hard to keep it flowing what with work commitments and two kids under the age of two.

The obvious difference this year is that I haven't written an "article". I know most of you refer to anything on here as an article, but, to me, they're the full-length posts that don't appear as a part of the blog. What I've found is that a) I don't have time to write the full-length posts any more and b) I can get most of what I want to say across via the blog posts. This site has always evolved to my situation and I can see articles being used less and less.

Noteworthy Happenings / Content

Having just looked through all 115 blog entries from the year, here's what stands out for me:

Each year I always think what on earth am I going to write about in the next year. I often think I'll run out of tips/tricks at some point. Things always come up though, as this year has shown. As for next year, who knows what will come up!?

Chances are that 2009 will see me talk about XPages, as I need to get up to speed on that and I'm sure you're dying to know my impressions. For the immediate future though you should expect a lot of talk about RIAs and, in particular, Adobe Flex!

Visitors

Never mind content. How popular was the site over the last year. Well, according to Google Analytics, 309,247 Absolute Unique Visitors amounted to 1,134,843 Page Views. I can't compare this to the previous year as I didn't start recording until March 2007. More than a million page views sounds alright to me though. Anybody know how much advertising revenue I'm missing out on?

Onwards...

So, here's to another year of techy geekness and to your continued input. Just remember, this site wouldn't continue if you weren't reading.

Next year will see this site's 10th birthday! Never thought that would happen.

Comment Icon 8 Comments Read - Add | Wed 31 Dec 2008 | Open »

Merry Christmas To You All

It's Monday morning and I've come to sit in the office as normal. It doesn't feel normal though. What is it about the weeks that contain Christmas and New Year which make all the days in them feel like the weekend!?

Because of this weekend-factor I'm finding it hard to concentrate. It feels a bit like I'm the only one here. Am I? Hello!?

Sorry, I'm waffling. All I wanted to do is wish a Merry Christmas to all (of you that celebrate/have time off).

I'll probably be back here with something to say (codestore's year in review perhaps) before, but if not, I'll see you all in 2009...

Comment Icon 19 Comments Read - Add | Mon 22 Dec 2008 | Open »

CSS Files and Relative URLs

By coincidence, the day after I spoke about the confusion relative URLs can cause I was asked to help out on a project where relative URLs of a different kind were causing yet more confusion. This time it was URLs inside a CSS file.

Imagine your web page loads a CSS file like this:

<link rel="stylesheet" type="text/css" media="all" href="css/default.css" />

Note that the file is inside a "subfolder" of the database called "css". Inside this stylesheet we add a rule to place a background image in the header DIV like so:

div#header {
 background-image:url( images/header_background.gif );
}

Assuming the CSS file is located at /db.nsf/css/default.css you'd probably expect the image to load if it were located at /database.nsf/images/header_background.gif. But wait. It won't! Why? Because URLs inside CSS files are relative to the CSS file itself -- not the database and definitely not any BASE href in the web page, which has no effect on the relativeness of the URLs in the CSS files.

Come again!? Well, the stylesheet above lives inside a folder called "css". So, any URL it tries to load is relative to that folder. If you used a HTTP sniffer you'd see the browser try and load the background image from /db.nsf/css/images/header_background.gif.

The correct CSS is in fact:

div#header {
 background-image:url( ../images/header_background.gif );
}

The browser then knows to step back out of the CSS folder and then in to the images folder, both of which are at the same level in the database's faux-folder structure.

Similarly, if the stylesheet were two subfolders deep and in /db.nsf/css/screen/default.css then the rule would become:

div#header {
 background-image:url( ../../images/header_background.gif );
}

Again, this might seem like a noob thing, but it's another that can really trip people up until you learn how URLs inside CSS file behave.

Comment Icon 3 Comments Read - Add | Fri 19 Dec 2008 | Open »

Solving a Simple Problem with Relative URLs

It seems like I've explained a solution to what must be a common problem enough times over the past couple of months to warrant answering it here (much easier to point to a link than to explain it over and over).

The Problem

Imagine you place an image on a Form using Passthru HTML. Something like this:

<img src="logo.jpg">

The problem is that when you create a new document using the form the image appears, but when you open the saved document in read mode it doesn't. It doesn't have to be an image. It can be any resource you load by URL, such as a CSS or JavaScript file, in which case the consequence would be much more obvious.

The Cause

This behaviour is down to the fact that the resource is being referenced as a relative URL. When the document is first being created the actual URL would be something like:

http://server.com/apps/help.nsf/ticket?OpenForm

So the browser will try and fetch the image from

http://server.com/apps/help.nsf/logo.jpg

This is the correct location and so the image loads. When the document is saved and re-opened the actual URL becomes something like:

http://server.com/apps/help.nsf/tickets/788A7878ED562132322EA21312?OpenDocument

And, so, the browser then tries to load the image from the following URL:

http://server.com/apps/help.nsf/tickets/logo.jpg

When reading documents we are, in effect, one "directory" deeper in to the site's structure and so relative URLs become broken.

The Solution

The quickest solution is to make the reference to the image/resource absolute. Like so:

<img src="/apps/help.nsf/logo.jpg">

However, if you're loading lots of images and/or resources it can become a drain on resources to compute the database path each time. Instead I'd recommend using the technique I use in all databases I create -- BASE href

I know this must seem a bit nooby to most of you, but you'd be surprised how often I see it come up as a problem.

Comment Icon 11 Comments Read - Add | Wed 17 Dec 2008 | Open »

More blog entries are available in the archive »