Ooer

Remember the last time you were successful at a job interview. Nerves, butterflies, cold sweat? Or were you more confident than that? Perhaps you knew you could do the job well and you were ideally suited for the gig. Hell, you were! You got the job! You definitely weren’t late, you were dressed smartly, you were sociable and approachable, you answered all the questions you were asked correctly, maybe you even asked a few questions yourself. You were a winner. Congrats!

Exactly the same principle applies to your company’s website. When a visitor loads up that first page they’re interviewing your business to see if you make the grade.

Is it late? If your website users have to wait they’re going to get annoyed. Your website has to load fast. A few years ago that meant keeping pages under 50KB for all those people stuck on dial up internet connections. Today it’s not so bad. Most people have broadband. But you still need to work to retain user’s if you’re serving rich content – it won’t do to have the user sit staring at a progress bar for the first 15 seconds they’re on the page if there’s nothing else to read.

ACTION: Scripting is your friend here. Load a small static HTML page, then load the rich media when that’s done. (Don’t forget users who don’t have scripting enabled of course!)

Smartly dressed? Your website is bound to look great. There are stacks of talented designers around who can make great looking websites these days. But, just like at that job interview, your pristine look can be ruined by a few tiny mistakes:

• Proofread. Proofread everything. Get someone else to proofread your copy too. Do not rely on a spelling checker. Despite what some progressive English teachers might argue, people do notice spelling and grammar problems, and they are put off if they’re there.
• Optimise graphics. If your developers use the wrong format for images they’ll end up looking a bit ragged. Photographic content should be a JPEG, graphics and illustrations should be GIF or PNG.
• Do your colours give the right message? Colours mean things to us. Red means danger, green is peaceful, white is pure, and so on. You wouldn’t sell as many flowers online if your website was a dull brown than if it was a lively and bright.
• Check your website in different browsers. If your website works in Firefox and Internet Explorer that’s a good start. But what about Safari? Chrome? Opera? What does it look like on a Mac? On Linux? There are differences (mostly in things like forms). Your developers should be checking in as many target browsers as possible.
• Check your accessibility and usability. If your website employs small text, and website users can’t resize it (if it’s fixed height or an image), you could be giving up the opportunity to convert as much as 12% of your traffic into sales. Likewise if your content features colours that are indistinguishable to users with colour blindness you might be throwing away 5% of your traffic (moreso if your target audience is predominantly male; women don’t suffer colour blindness as much as men).

ACTION: Make a list of things to test, and check them regularly (after each major site update).

Answering questions correctly? This is not really a point for your developers at all. You know your business best. You know what sort of questions your customers ask when they’re buying your product. You need to communicate that knowledge to the person on yoursite though. The individual pages for your products should feature everything necessary, and they should be searchable. You should consider including a “knowledge base” (a database of questions and answers) too. They’re a good, usable way of finding information, and you can easily add questions to it as your customers contact you to ask things that aren’t covered. Ultimately, if your website is answering the questions that a customer has, they’re more likely too purchase. That’s the key.

ACTION: Build a database of questions and answers that your customers are likely to ask, and feature product or service specific questions on each of the relevant pages. Make all the content searchable. Make sure you keep it up-to-date and fresh too. As a bonus, all that content will work to drive traffic to your website from search engines, so make the knowledge base pages link directly to the products they’re about.

Being a client is easy, right? You write down your website idea, you talk it through with your chosen web development company, you sign a big cheque, and a few months later out pops a website that fulfils all your needs and sits on a web server printing you piles and piles of lovely money. Brilliant! Only it’s not really ever like that. I wish it was.

Investing in a website for your company is a complicated process. In this series of “Dear client” blog posts I’m planning to outline a handful of things that you, as a client, should ask of your web development company before commissioning them to build something for you, during the development process, and after the website is completed. On the whole they’ll be common sense advice based on questions that I’ve been asked, or wish I’d been asked, during my career to date.

Before you begin.

Do I need a website?

This is the very first question that you should be asking of yourself before you even talk to anyone in the web industry. It’s obvious. It’s fundamental. It could save you a big pile of money if the answer is “no”.

There’s a notion among new business owners that when you start your company you need to do several things – register with Companies House, get a business bank account, get some business cards, and get a website. Without those things in place you’re not running a proper business. The thing is though, the internet is not a quick fix or a business panacea. It can’t magically deliver you more customers. A website is only effective if your market (the people you’re selling to) use the internet to look for the sort of service you’re offering. If they don’t then you’ll be spending hundreds or thousands of pounds on a site that won’t deliver any results. That’s a waste of time and money.

I do need a website. What next?

On the whole your business will benefit from some sort of online presence. If you’re not selling directly over the internet then a website can, at the very least, be a great way to support the rest of your marketing material. When a potential customer reads about your company in an article or an advert, if they’re interested enough to want to know more, then a website can give them the opportunity to find out what your business is about.

Ok, so you’ve decided that a website will help you achieve your business’s goals. What next?

You’ll need to choose a web development company. You need one who can you trust, who you can afford, and who are capable of delivering what you want. What do you look for?

Look at their own company website. If they don’t have a website run away. If they do, do you like it? Does it work properly in your web browser? Does it tell you about what they offer?

BEWARE: It’s a sad fact that there are some unscrupulous companies out there that plagiarise content and whole websites from more capable companies. Try copying a sentence from the company’s site into Google to see if it finds other companies with identical copy. To search for exact phrases you’ll need to quote the phrase; eg search for “To search for exact phrases you’ll need to quote the phrase” (with the speech marks).

Look at their portfolio. If they don’t have a portfolio you don’t need to run away just yet; they might be very new. If they do have a portfolio check out some of their work. Does it match the sort of thing you’re looking for? Does it work? Contact some of their clients and ask if they’re happy.

BEWARE: Again, there are some unscrupulous companies out there. Some claim to have written websites that they didn’t. Check to see if there’s text stating “Website by <name>” anywhere. It’s usually in the footer of the index page, or on the About Us page, or in a meta tag (”View Source..”, then see if there’s a tag that looks like <META name=”Author” content=”Chris Neale”>.

Talk to them. If you like their website and they’ve got some portfolio examples that look like they could create a website that meets your needs, email them or call them. Arrange a meeting to go and talk face to face. Ask them questions about how they create websites. You should be on the look out for words like “accessibility”, “usability”, and “testing”. If they dwell on technical aspects like which scripting technology they use or how scalable the website will be you should consider not using them. As a client the technical aspects of the website are not your concern – you just need to know that the website will work.

BEWARE: Don’t volunteer too much information about the website. You’ll need to tell the company you’re talking to the basics about what you want, but beyond that you should wait for them to ask. They don’t know how you work, and if they’re not interested in finding out by asking lots and lots of questions they’re not likely to build a website that seamlessly integrates into your business. You need a developer who can properly analyse the software need and who isn’t afraid to ask about things that they don’t fully understand.

So, that’s how you get from the point of considering whether or not you need a website to finding a web development company to build it for you. But what should they build? Check back soon for the next part of “Dear Client” and find out.

POSTSCRIPT: Something you might want to consider, and it’s slightly unusual these days, is employing a freelance web project manager. These people know how to make websites and how to analyse business processes, effectively crossing the gap between programmer and business analyst. They can act as an intermediary between you and the web development company – defining what the website requires at the beginning and making sure the website meets those needs at the end. They know how to check a site has been properly developed. Unfortunately though, they’re a rare breed. It’s a very new sort of job. You might have difficulty finding someone who can take on your project.

I hate putting websites live. I’m totally paranoid about things going awry; I don’t trust my development server. I barely trust my staging server. I trust my production server though, which is why I only really sign things off when they’re working correctly on there.

Most the big sites I’ve been responsible for over the past few years have been snuck out of the door under cover of darkness, launched at 6 A.M. on a Saturday without fanfare or media coverage until the following Monday when the code has settled and I’ve spent a good few hours hammering away at it looking for things that don’t work. I don’t think there’s been a launch yet where I’ve not found anything wrong.

And so, with that in mind, I imagine the team behind the new Quick.TV website know how I feel. After what must have been a fraught morning, and a couple of minor hitches, the new site is up and running. And, it must be said, it looks great. The design is spot on. The product looks really exciting too (if you ignore the usability issues that interactive video throws up). I wish the guys the very best of luck.

It’s great to see a bleeding edge bit on internet tech being developed up here in the North East.

As the old Hitchcockian cliché goes “Expect the unexpected!”.

As far as your website is concerned though, the user really, really doesn’t. Confusing, unusual and bizarre experiences on internet sites are a huge turn-off. These range from things like hidden navigation, or forms that don’t work in the usual manner, or disabling browser features (the right mouse button for example), to, as the case of a website I discovered this morning illustrates, a simple redirect.

The website in question is http://www.jimaging.co.uk/

When it first loads you can see a page of accessible, usable HTML and images loading up. Some of the images are a little large for the web, but it’s architectural imaging so big is probably better. The problem arises when the document is completed – the site is then redirected to a Flash version with apparently much less content. This is confusing. Like the majority of internet users I start to read a webpage when the text and layout HTML are downloaded – the fact the images and multimedia assets are still downloading doesn’t stop me. To be halfway through a paragraph when the page vanishes to be replaced with a Flash version is baffling. What’s worse is that  the image assets have to be downloaded into the Flash version again, costing me more time waiting and costing the website owner double the bandwidth. That’s crazy.

There are two possible solutions for this problem. The first, and the one I would advise to use, would be to scrap the Flash version of the site completely. In a portfolio people are interested in the final product – the pictures – and any barrier to viewing them is a bad thing. The Flash version of the website adds very little beyond some animated effects. Flash should be used to enhance a page by making it more usable. Animation and tweened fading isn’t much of an enhancement.

The other option would be to detect whether the user has Flash available before any of the HTML and images are loaded, and redirect to the Flash version before anything is displayed if they do. This would mean only one version is displayed, saving users’ confusion at the page reloading while they’re reading, and saving bandwidth costs because the assets for the HTML version wouldn’t often be accessed.

When it was first made available “FutureSplash Animator” was heralded as a game-changing technology that would revolutionise the internet. It took web design out of the hands of the techie geeks and gave designers a tool that would, eventually, give them the power to put their multimedia design work online exactly how they wanted. There were far fewer limitations to what could be done compared to HTML.

Sadly, or not, depending on your point of view, the technology had a few flaws. It required a browser plugin. It wasn’t searchable. It was slow if you pushed it hard. Web designers were put off. Fast forward 10 years to today. Flash is a phenomenal tool that affords a designer, and a developer, a playground to do anything. You name it, a designer can implement it. If you want a whizzy 3D interface with effect galore you can have it. Fantastic!

Unfortunately this means clients occasionally get a bit carried away and forget that they need to commission things people can actually use. Flash is a powerful tool that can be used to add to a website. The basic underlying website still needs to be usable.

Today I found a perfect example of this problem: three.com

The Flash version of the website uses an ‘unfocused’ menu system that blurs the text of links until your mouse hovers over them. This system makes the menu unusable – you can’t read the options available or scan the menu to find what you want. You’re left to “sweep” (running your mouse over each option to find the one you want).

Three.com Flash Menu

There’s no good reason for this. The client, or the designer, has used the effect for the sake of adding it, and has put up a barrier to entry for the user. That is an example of an appalling lack of usability knowledge. Strangely, and very fortunately, the same menu system is not utilised on the non-scripted alternative site displayed to users who don’t have Flash or have scripting disabled:

Three.com No Flash

The menu could have a fancy effect using CSS to switch images but it’s been left static. Consequently the menu is usable. It’s a shame the links don’t look like links but we can’t have everything.

What we can take away from this lesson is simple: Flash is great, but you mustn’t forget your basic usability principles when you use it.

In a recent Alertbox posting Jakob Neilsen talked about password masking (link), and how it reduces how usable a form is, and how it actually degrades security. All in all it was a pretty reasonable argument; I agree with his point. However, that said, I’m not sure I’d want to deviate so far from the norm of masked passwords to display them in plain text, and regardless of how small a risk it might be ‘shoulder surfing‘ is still an issue.

So what would be a good compromise?

Having thought about it for a little while I feel the best approach to the problem of providing a usable password input is still to default to masked passwords, but to present the user with the option of displaying the plain text if they’re in an environment that affords them enough security. Fortunately this is achievable with a trivial amount of code added an HTML form if we employ jQuery.

The Show password demo form

Using jQuery’s before() method to insert some HTML code before an element, and then the remove() method to delete the original element, we can replace a form a element with another:

$('#user_password').before('<input id="user_password" type="'+type+'" value="'+value+'">').remove();

The ‘type’ variable needs to be the opposing type of “text” or “password” depending on what the current type of #user_password is, and ‘value’ need to be the value of the form element. You can see a working demo here: Show password demo. It has been tested in Firefox and IE, but should work in most browsers thanks to jQuery.

The form itself needs a short explanation of how the user should interact with it. This is simply a line of text telling them what the checkbox does and warning them not to use it unless their computer is secure.