Web Posts:

Amazon Link Localizer Greasemonkey Script

Monday, September 28th, 2009

This Greasemonkey script will convert links to international Amazon sites into links to your local Amazon site.
So if I link to a product on Amazon.co.uk, you will get a link to that same product on Amazon.com instead.

Greasemonkey is an add-on for Firefox that allows you to run user-generated scripts on the websites you visit. If you haven’t got it yet, download it now, as you’ll need it to install the below script.

Once you’ve installed Greasemonkey, simply click the below link to install the script.

As you’re visiting from US, you’re probably looking for the Amazon.com Script, right?

Download: Amazon.com Link Localiser (or see all options)

Amazon Affiliate Link Localizer Wordpress Plugin

Friday, September 25th, 2009

Download

Current Version: Amazon Affiliate Link Localizer 1.3
Last Updated: 27/11/2009

Description

This plugin not only automatically changes any Amazon link on your site to use your affiliate ID, but it also changes the link to point to the user’s local Amazon store.

So if your visitor is visiting from the UK they’ll get a link to Amazon.co.uk, if they’re visiting from the US they’ll get a link to the same product on Amazon.com.

All you have to do is provide all your affiliate IDs!

Non-Wordpress version

If you want to achieve the same result on a non-Wordpress site, you can simply install the pure JavaScript version.

See also: Greasemonkey Script

As an Amazon user, you may also be interested in my Amazon Link Localizer Greasemonkey Script which automatically converts links to international Amazon sites into links to your local Amazon site.

So if I link to a product on Amazon.co.uk, and you are a US visitor, you will get a link to that same product on Amazon.com instead.

Disclosure

If you do not insert your own affiliate IDs the script will use mine. Hopefully this will help fund my book addiction!

How to Speed Up Your Site and Get a YSlow Grade A

Wednesday, August 12th, 2009

When I first launched my homepage it earned a Grade F in Yahoo’s YSlow. This post explains how I decreased load time and achieved a Grade A.

If you’re not familiar with it, YSlow is a Firefox Add-On that integrates with the indispensible Firebug. It measures page performance and provides suggestions on how to make improvements.

The key to improving the speed of you page is to not only reduce the amount of data that is sent to the client, but also the number of requests made to the server. Each time your browser makes an HTTP request from the server, time is wasted setting up a connection and waiting for a response, introducing further delays.

Originally, my homepage and all its assets – images, JavaScript and CSS files – weighed in at 196kb with a total of 46 HTTP requests. It’s now down to 75kb with 16 requests and loads in half the time.

So here’s how you can improve your YSlow grade

Compress Images

Saved me 18kb
You probably already know you can reduce image filesizes by choosing the optimal file format and saving at the right quality level. What you might not know is that the resultant images can often been compressed further without any loss of quality.

Smush.it is a lossless compression tool (now built into YSlow itself), which in a single click checks your site for any bloated images, compresses them and then pops them all in a handy zip file for you to download.

You’ll find Smush.it under the Tools menu in YSlow.

Remove 404s

Saved me 4kb and 2 HTTP requests
Check Firebug’s Net tab for any red items, these are files which cannot be found. Here you’re wasting an HTTP request and downloading a 404 page you don’t need. I was surprised to see that I actually had a couple 404s from a Lytebox CSS file.

Remove unused CSS

Saved me 1kb
Firefox add-on Dust-Me Selectors checks your pages for any CSS selectors which are declared in your CSS but not used by your HTML. Providing these aren’t used in any other pages, these can be removed to save bytes.

Combine JavaScript and CSS files

Saved me 4 HTTP requests
If each of your pages use the same few JavaScript files, try combining them into a single file to remove unnecessary HTTP requests. You can do the same with your CSS files.

Minify JavaScript and CSS

Saved me 15kb
Hopefully you write your CSS and JavaScript to be easy to read and maintain, with plenty of comments, verbose variable names and appropriate use of whitespace. However none of this is of any interest to browsers, so these can all be stripped out by a JavaScript minifier, saving crucial bytes.

Use the JavaScript Compressorator to see how much you can save.
There are a few CSS minifiers around, but I’ve found Robson’s CSS Compressor to give the best results.

Be sure to keep the original uncompressed files for any further development. Name the minified file *.min.js or *.min.css and repoint your HTML files.

Gzip Components

Saved me 53kb
Gzipping your text-based assets (HTML, JavaScript and CSS) allows your webserver to transmit compressed versions of your files, often reducing the filesize by around 70%, and allow the users’ browser to seamlessly unzip it and process it as normal. This is probably the quickest and most effective way to improve your site’s performance.

How you turn on gzip compression depends on what webserver you’re running. If it’s Apache 2, as is most common, then the easiest method it to add the following to your .htaccess file:

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xhtml+xml
AddOutputFilterByType DEFLATE application/x-javascript application/javascript text/javascript text/css

If you’ve not got a .htacess file, simply add a text file called ‘.htaccess’ at the root level of your site containing the above text.

To confirm your files are being gzipped, use Firebug to inspect your headers and look for ‘content encoding: gzip‘.

Create CSS Sprites

Saved 14kb and 8 HTTP requests
Images on a website can often be the biggest abuser of HTTP requests. CSS sprites are a technique to reduce the number of requests necessary by combining multiple images into a single image and then using CSS’s background-position to position them.

To the user, everything looks the same, just a little bit faster.

This can also trim down the filesize a fair bit, especially if you combine images of the same format with similar colours. For instance the images accompanying the links in the sidebar to the right are from a 3kb CSS sprite, but individually the images totalled 11kb.

Use multiple Subdomains

The HTTP specification states that a browser can only download a maximum of 2 files from each domain at any one time. If all your files are on a single domain then your users will waste time queuing up downloads.

So once you’ve reduced your HTTP requests, try spreading them around. I’ve moved my JavaScript, CSS and image files onto separate subdomains allowing the user to make the most of their bandwidth.

Add Expires Header

YSlow suggests that you ‘Add Expires headers’, which basically is a note in the header telling the browser to cache the file until a specific date. It won’t then waste time looking to see if the file has changed until that date.

To implement a long expire header, add the following code to your .htaccess file:

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
        ExpiresActive On
        ExpiresDefault "access plus 1 year"
</FilesMatch>

This does however complicate maintenance. If you make a change to any of the affected files you’ll need to give it a new filename to prevent the cached version being used. I tend to put the last-modified date in the filename to avoid this.

Configure Entity Tags

Entity tags are used to check if the file in your cache is the same as the one on the server. Yahoo’s problem with them is that this doesn’t work if the site is server from a different server – as might happen on a load-balanced site.

So for most of us, this isn’t really a problem that needs solving. If you want to keep YSlow happy though, you just need to add the following to your .htaccess file:

FileETag none

Image Replacement

Saved 17kb and 12 HTTP requests
Due to limited font support across the web, people often use images to display custom fonts. Along with the accessibility issues this presents, this also has the effect of increasing your page’s footprint.

A more accessible and maintainable solution is to use an image replacement technique such as sIFR, FLIR or Cofun to replicate a font.

I prefer Cufon for a variety of reasons, not least because it’s a purely JavaScript technique meaning it can be nicely minified, combined and compressed. The Cufon script and the JavaScript-encoded font used on this site come to around 12k – far less than the images they replaced and didn’t cost any extra HTTP requests.

Prioritised Loading

Once you’ve completed all the above steps, you can still make your website appear to load quicker.

Placing CSS at the top of the page allows pages to be displayed progressively as it loads.
Place JavaScript at the bottom as it blocks the download of any other content.

Backend Optimisation

As well as improving the speed your content is transmitted, you can improve the speed it is generated. On anything but the most basic static HTML site, there will be some server-side programming and database access slowing down the delivery of your content. Be sure you don’t overlook any opportunities for optimisation here.

If you’re not a backend developer there are still opportunities for improvement, for example by installing a caching plug-in on Wordpress.

Conclusion

I completed all the above steps mainly as a learning exercise and because I can’t resist the allure of getting a top grade in anything! However, some of the above ’solutions’ aren’t necessarily appropriate for every site – it’s up to you to assess how great the potential performance gains are and if they worth the overhead in maintenance.

JavaScript Amazon Associate Link Localiser

Tuesday, July 14th, 2009

I’ve been a member of Amazon’s Associate program for a number of years and have posted affiliate links to books discussed on this very blog. The program means that by putting my affiliate ID into any links to Amazon products, I receive a small referral fee.

I’ve always linked to Amazon.co.uk as that’s my local Amazon store, but of course that’s not necessarily true for my visitors – or yours…

To solve this problem, I’ve written some JavaScript which will convert any Amazon product links on your page into affiliated links to your visitor’s local Amazon store. So US visitors will get a .com link, whilst UK visitors will get a .co.uk link to the same product.

Download

Setup

Edit amazon.js to insert your regional Associate IDs into the array at the top, for example:

var arrAffiliates = {
	'co.uk' : 'petewill-19',
	'com'	: 'petewill-20',
	'de'	: 'petewill05-21',
	'fr'	: 'petewill-21',
	'ca'	: 'petewill00-20',
	'jp'	: ''
}

If you do not have an ID for each country, you can just leave them blank, as above for .jp.

Upload and Embed

As well as linking to amazon.js you need to link to the Google JS API file (5 kb) or the script will not work. Insert the following code just before your </body> tag:

<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript" src="amazon.min.js"></script>

Upload your modified amazon.js file, and make sure the above link points to the right location.

Usage

That’s it. You’re done! You can now just link to any product on any Amazon site with a normal, unaffiliated link and your users will get one affiliated for their country.

Example

The script is running on this page, so hopefully this example should be affiliated specially for you!

Disclosure

If you do not insert your own affiliate IDs the script will use mine. Hopefully this will help fund my book addiction!

Designers – Leave the interface elements alone!

Wednesday, June 24th, 2009

Most desktop applications make heavy use of standardised GUI components such as drop-down menus, tabs, and buttons. Some applications, often web applications, try something different… and fail.

Flash scrollbars are a classic example

Here’s why you should stick to the standards:

  • Familiarity – people are used to, and expect these consistent elements in applications. They already know how they work and will be frustrated if yours don’t work in the same way.
  • Free research! – You’ll probably find that the original elements underwent much experimentation, analysis and research until an optimum was found. This is all yours for free with the standard element!

As such, it’s important not to bastardise these elements without understanding the thought process behind them. Let’s take a look at some examples…

Tabs

Windows Vista's standard tab interface shows correct tab usage.

Vista's standard tab interface shows correct tab usage.

Tabs are a great interface control – they provide a mechanism to make extra information easily available without overloading the user. When used correctly, as per the standard Windows (see right) and Mac controls they also create a great physical metaphor – new users can relate the interface to traditional paper tabs and know what to expect.

What often happens when people mess with tabs, is that they they break that metaphor. For tabs to work, they need to be a different colour when selected, and that colour should be the same as the page displayed below. Just as they would with paper tabs.

A poor web implementation of tabs.

A poor web implementation of tabs.

The image to the right shows an example where the designers have not thought about this metaphor and as a result have produced less usable tabs. They have lost the affordance of tabs – it’s no longer clear what is selected, nor what clicking the tabs will do.

Someone at IBM put a lot of thought into how tabs would work best – let’s not put it to waste by thinking we know better, not until you understand the though process behind the design.

See Steve Krug’s “Don’t Make Me Think” for more detail on the correct design of tab controls.

Scroll Bars

No honestly, that is a scrollbar!

No honestly, that is an actual scrollbar!

Time and time after again we see designers, often of Flash sites, try and reinvent the scroll bar. Not once have I seen anyone offer an improvement over the standard. As well as the risk that users won’t recognise or understand your scroll bar, they ignore what makes the standard element so good:

  • Recognisable scroll buttons with arrows pointing in direction of movement
  • The slider (or ‘thumb’) gets larger when you have less to scroll, providing a larger target when less accuracy is required
  • Clicking in the trough jumps the content up or down
  • Holding down the mouse makes it scroll faster
  • It works horizontally or vertically
  • Only appears when required
  • Works with mouse scroll wheels

I’ve seen all these rules broken simply because the designers wanted something looking different. It gets worse still when they try and make them behave differently, such as those that scroll on hover, instead of on click.

The example to the right, is possibly the worst scrollbar I’ve come across. So much so that you might struggle to spot it. The plus and minus sign along with the bullet points actually form a disjointed scrollbar. If you hover over plus or minus the content moves vertically within it’s box. If you click a bullet it scrolls to specific points. Clicking or hovering anywhere else does nothing. What makes it worse is that this is a small part of the page not a whole screen, so there’s not even the expectation that it might scroll!

Application Close Button

Photoshop CS4's non-standard close/resize buttons

Photoshop CS4's non-standard close/resize buttons

Here’s the problem that prompted me to write this post in the first place – Photoshop CS4’s close button.

You might be thinking there’s not much to go wrong with that little buttons in the top right of your screen, but therein lies the important factor – they need to be at the top right, the very top right!

The top right corner is one of the easiest places on the screen to reach – you can get there in an instant with just a blind fling of your mouse. Move the button just a coupe pixels in from that corner and you lose this – as Abode have done. Worse still, they’ve made the button smaller which makes it harder to use, as Fitts’ Law explains:

The time required to move to a target area is a function of the distance to and the size of the target.

The edges of your screen are effectively of an infinite depth – however far your arm moves the mouse, the cursor stays at the edge. Therefore they represent the biggest click targets and are prime real estate for common functions.

The positioning of the standard close button is no coincidence. As we’ve found, there’s science and research behind all successful interface design, despite the fact that it may not seem immediately obvious. As such, unless you’ve got a genuine reason not to, please leave the interface elements alone!

A Ticketmaster User Experience Rant!

Monday, March 16th, 2009

Did anyone else waste hours of their life failing to buy Michael Jackson tickets?

For those of you who didn’t, the experience went like this:

  1. Go to Ticketmaster website and click Michael Jackson promo
  2. View a list of 50 dates at the same venue and choose one
  3. Wait 5 minutes for a page to load then select number of tickets
  4. Wait 15-30 minutes for a page to load saying there are no tickets available
  5. Return to step 2 and select a different date
  6. Repeat until you hear on the radio that all tickets are gone
  7. Leave Ticketmaster website and hope you never have to come back again

Now why oh why, could I not have just said that I want Michael Jackson tickets – and I don’t care when for – and then have it find me a date with tickets available?

You’d have thought a company so universally detested for their extortionate fees might prioritise a decent user experience in order to claw back some goodwill, but apparently not…

The less you say, the more we listen

Wednesday, February 18th, 2009

eye tracking heatmap

The Problem

I’ll keep this brief because you’re probably not going to read it all anyway. In fact, that’s my point – web users don’t read, they scan.

The adjacent heatmap shows eye activity on a typical product page. This is fairly normal behaviour and displays what Nielson calls F Pattern reading, after the shape the eyes follow on the page.

The Solutions

So if they’re not going to read it all, make sure they read what you want them to – lose everything else.

  • Steve Krug’s advice in his book is “lose half your words, then lose half of what’s left”. I’d say that’s a good start. Just keep taking out words until every last one is vital
  • Front-load your text – Put the important stuff at the beginning, because people probably won’t get to the end. Screen-reader users especially will skip content if the start isn’t engaging
  • Formatting – Headers, bullet lists and bolding help direct the eye to the important places and are easier to read that large text blocks
  • Practice on twitter – the 140 character limit should help!

Why CAPTCHA Sucks and What to do About it

Monday, February 9th, 2009

CAPTCHA

CAPTCHA, as you probably know is used to check that a form was submitted by a human, not an evil-plotting computer. It generally takes the form of typing in some barely-legible characters shown in an image. And it sucks.

Why it sucks

Obviously they’re hard to read – that’s kinda the point – I get them ‘wrong’ regularly and I’ve got 20/20 vision. To me, they’re a pain in the arse – but to anyone suffering from visual impairments, they’re a total brick wall. Sure, some come with audio alternatives, but these have been found to be even less successful.

There are some seemingly more accessible alternatives cropping up, like ‘2 + 5 =’, spot the odd one out, or other basic logic problems, but are these really any better? OK we’re no longer alienating our visually impaired audience but what about those with learning difficulties or cognitive disabilities? Even if that is a small group being affected, it’s all of us that have to put up with it. Whatever happened to the first rule of usability: Don’t Make Me Think!

The simple fact is that these irritations drive people away from your site, and ultimately cost you money! I’ve abandoned registrations and purchases before because of impossible CAPTCHAs and I’m sure I’m not alone.

What to do about it

Well for starters let’s minimise where they’re used. Not every form needs one! Before you implement a CAPTCHA system think about whether it would really be a problem if it was a computer filling in the form – how much would it really matter if a bot signed up to your mailing list?

It’s important to think about why you don’t want bots to submit your form and if there are other ways to go about it. For example?

  • Trying to prevent DOS attacks? Then limit CAPTCHA to when the server is above a certain load level
  • Want to avoid comment spam? – Askimet or Spam Karma can filter out most of it for you!
  • Don’t want a screen-scraper pillaging your data? At least let them have the first few, most likely legal, requests without CAPTCHA then hit them with it if they keep on accessing data rapidly.

Not again!

One of the things that annoys me the most is when the same site makes me prove I’m still as human as I was a minute earlier! The worst cases being forms validated server side which return an error saying I missed a field or something and then insist I fill in the CAPTCHA again – I just did it! Why do I need to do it again?

Likewise, if I completed a CAPTCHA on registration, then why should I have to do one every time I post a comment? At least leave me alone until I do something bot-like!

And that’s the important thing to remember here – there are other bot-like characteristics apart from not being able to read text from an image. With this in mind perhaps we can avoid CAPTCHA altogether…

György Fekete has come up with a 5 Layer Spam Filter that uses some cunning techniques to identify bots without having to resort to CAPTCHA:

  • Do fields hidden off-screen still get filled in
  • Is the form filled in in seconds?
  • Do they not have JavaScript enabled?
  • Does Askimet mark it as spam

Now, I don’t think the first two points can be entirely relied upon because automated form-fillers, such as RoboForm or Google Toolbar’s Autofill feature, will still fill in hidden forms and mean a registration form can be completed in seconds. Screen-readers would also fall into the trap of reading these out and thus they would get filled in. As such, I wouldn’t suggest relying entirely on these criteria to identify spammers, but perhaps each point could be assigned a weighting, and a high enough score could trigger a CAPTCHA request. This way, most of your users will be treated to a nice, simple and accessible form, with CAPTCHA reserved for the odd few whose behaviour is flagged as suspicious.

So maybe there is a need for CAPTCHA at time, in those situations where you really do need to use CAPTCHA, at least bring something positive out of it and use reCAPTCHA which helps digitize books where OCR can’t. Then I might just let you off…

When the Internet was all fields…

Monday, January 26th, 2009

I’ve just finished reading Donald Norman’s The Design of Everyday Things, a fascinating study of user-centered design from 1988, and was particularly amused by the following prognosis of what was to become the web:

“So, what do you think of hypertext? Imagine trying to write something using it. The extra freedom also poses extra requirements. If hypertext really becomes available, especially in fancy versions now being talked about – where words, sounds, video, computer graphics, simulations and more are all available at the touch of the screen – well, it is hard to imagine anyone capable of preparing the material. It will take teams of people. I predict that there will be much experimentation, and much failure…

He wasn’t far off at all – there has been much experimentation, there has been much failure and there’s been a fair bit of fanciness. What’s really remarkable though, is where he wasn’t quote right – it doesn’t take a team of people (though a range of specialists will always be an advantage) – there are plenty of great web applications out there created by single developers.

Still, baring in mind this prediction was made about the time Bill Gates was supposedly telling us we wouldn’t need more than 640k of RAM – it’s not bad at all.