Main

April 16, 2008

Best practices for speeding up your site

Best Practices for Speeding Up Your Web Site — part of an excellent series of articles on the Yahoo Developer Network.

They mainly focus on the front end, as that is where you’ll get most bang for your buck. They make frequent reference to YSlow, a Firebug extension that looks extremely useful.

The presentation here is also strongly recommended, as it makes succinct arguments for all the techniques. (View on Slideshare to see it full-screen.)

Some things were familiar to me (and most are already standard practice for my colleagues), many weren’t (e.g. avoid @import for CSS), and some I know of but haven’t been convinced of before (e.g. CSS sprites). I was quite intrigued by this example of CSS sprites in use on Google. (When using CSS sprites, remember to consider their accessibility to screen readers, and don’t use if you want them to print.)

March 03, 2008

Reflections of a Windows-Mac switcher

10 months ago, starting a new job and needing a new laptop, I had a choice of platforms. Since I work in user experience design, knowing multiple operating systems is valuable in keeping my frame of reference as broad as possible. I haven't used Macs after 1999. I certainly preferred Win2000 and WinXP over Mac OS 7-9, but have become frustrated with Windows with increasing regularity. So I opted for a Mac (Powerbook 2.33 GHz Core 2 Duo with 2GB RAM).

Since then, I've kept a list of the pros and cons of OS X (Tiger) compared with WinXP. Naturally, there were many annoyances in the beginning, but I didn't want to blog about it until I've become settled on the new platform. I've not strictly switched either, since my home computer still runs WinXP, and I simply couldn't use OS X without also having WinXP on Parallels.

Short version: Took me about 3 months before I preferred working on the Mac, and am now likely to stick to the platform for work. Read on for my list of OS X annoyances, and likes.

Continue reading "Reflections of a Windows-Mac switcher" »

In praise of invisible text

As a website accessibility feature, invisible text has long been accepted as one of the most helpful things you can do. This is text that is invisible on screen, but read out in screen readers, using CSS like the off-left technique. So far, as in those articles, we’ve primarily used it to add skiplinks and invisible headings.

Yesterday, while peeking under the hood of the new BBC homepage (very impressive HTML/CSS), I noticed another very handy use of invisible text: replacing the oft-overused title attribute. Under the Radio section, a link that looks like “Listen Live” will actually be coded as <a href="/radio/aod/radio1.shtml" class="radiopop">Listen<span class="hide"> To Radio 1</span> Live</a>. For a sighted user, the visual context makes the extra text superfluous, but for screen readers users, it’s indispensable.

This is akin to “Read more” links, for which we’d usually add the associated page title in a title attribute (still a popular recommendation). But you can’t actually count on all screen reader users hearing the title attribute. (The fault of assistive technologies, but nonetheless…)

November 09, 2007

OS X dialog box overload

I started using a Mac 6 months ago. In some respects, it lives up to the hype for “just working” — networking in particular is a pleasure compared with WinXP. But in lots of other respects, it’s just as bad as any operating system I’ve ever used. Witness the following maze of similar-but-different dialog boxes I’ve had to wade through in my (unsuccessful) attempts to connect to the internet via my Nokia 6300:

July 03, 2007

Ebuyer / Bank of Scotland adopts Verified by Visa

The scourge of Verified by Visa continues. A 2-page step is tacked on at the end of a normal checkout process: see screenshots 1, 2. (You may find this useful if you’re forced to implement it yourself in future.) Yes, it sits inside an iframe in the page. Two things (security code and expiry date) you’ve already provided earlier in the process and are forced to provide again.

If you click “How will it be used” next to the email address, it opens a popup window with an explanation.

On the next step, if you click Help, it opens Help in the previous popup window (in the background, so you may well not notice anything had happened), which has no scrollbars, fixed-width layout wider than the window, and cannot be resized, so the only way to view all text is to select-drag.

The Help page actually mentions accessibility, but merely provides useless lip service. What good does it do to link to the WCAG, or to screen readers? And how much can you trust it if it claims “Support for No Java Script”, while the popup window wouldn’t have opened without JavaScript? Or even, god help us, when in-page anchor links look like this: <a href="javascript:moveToInerLink('#DDA');"> (sic).

After purchase completion, you receive a lengthy “Welcome to Bank of Scotland Secure” email message urging you to personalise it with a new login name and “personal message”. Any novice online shoppers who’ve made it this far is likely to throw their hands up in confusion.

This is supposedly all for our security, but already, phishing scams mimicking Verified by Visa abound. How long before phishers start mimicking the Verified by Visa Iframes? Using an Iframe you can’t even see the domain name, the https or little padlock. The pages in the Iframe are served from https://www.securesuite.co.uk/hbos/, itself not exactly a reassuring household name (note that the scam above is served from http://usa.consumers.datasecurities.net)

Visa’s response is this complacent, self-serving attitude: “The interesting thing about these Verified by Visa phishing attacks is that they further the argument to sign up for Verified by Visa, which is designed to thwart fraudulent payment transactions,” And if that doesn’t give you the horrors, “Visa is looking into a system under which a card issuer could require a cardholder to register for the program before completing an online checkout process” (my emphasis).