Archive for the ‘CSS’ Category

The importance of email

Sunday, May 15th, 2011

All good online marketers know that email is an excellent source of potential revenue. Most of those also know there’s a fine balance between being informative and being a spammer; users are all too happy to click that unsubscribe link, the worst thing possible for an email based marketing campaign. So, apart from sending uninteresting or just too many emails, what other reasons would somebody who had signed-up to your marketing gleefully unsubscribe?

One of the answers may well be with how your emails are constructed. Making marketing email is often much trickier than building a webpage; there are so many mail clients out there that you really are against it to make your email look similar across the board. If you know what you’re doing this can be achieved relatively well, however; it would seem that a large quantity of companies simply don’t know what they’re doing, or at least, their developers don’t.

Let’s take our first example: Adobe. Adobe is a multi-billion dollar company that distributes popular media software such as Photoshop, and even webpage creation software called Dreamweaver. Would you therefore conclude that its array of competent professionals were experts at meticulously crafting emails that looked perfect everywhere? If you would, you’d be wrong. Take a look at these images:

Instantly we can see a problem. With images disabled the email is just a random collection of links, some of which are just ‘click here’ or ‘learn more’ (which is also a large accessibility issue – the last thing you want to hear as a disabled user when you ask your screen reader to read out the list of links is: ‘click here’, ‘click here’, ‘click here’, etc). With images enabled the email doesn’t get much better, it’s still completely unreadable. This email was rendered in Outlook 2003, still a popular email client for businesses across the world. A definite candidate for unsubscribing, if you can find the link.

Adobe isn’t alone in being a large client who doesn’t test their email properly, here we also have problems from TomTom and Nintendo in Outlook 2007:

Clearly there needs to be more quality control at large corporations when it comes to their online marketing.

There’s another way to confuse your user-base: using the text version of the email for the wrong thing. Traditionally when you send an HTML email you also send a text version so that people who either have HTML disabled on their email client or users whose client simply doesn’t support HTML see the same content but without the images. Unfortunately some email creators are all to happy to ignore text-only email viewers and direct people straight to an HTML page on the web to view their newsletter instead. Now, you may be thinking that that would be an acceptable solution, but; you’d be wrong.

Take a look at our next example add tell me what you see?

Now the problem is all too evident: some email clients such as Mail on iPhone and iPad, and the desktop alert in Outlook will use the textual version of the email to give a handy preview. Obviously as we can see from this example, it fails horribly when you use it the wrong way.

There is something worse though; sending out the wrong email. And not just the wrong email, but the text only version of the email to people who actually have HTML clients. And you’ve used your text-only version incorrectly, to tell people that they need an HTML compatible mail client to view the email. And then supply a link, a single link. Which is in fact, an unsubscribe link. This is without a doubt, the ultimate fail:

How many clients did they lose that day?

Internet Explorer 9

Thursday, June 24th, 2010

Every web developer knows that Internet Explorer (IE) 6 is a pain. It has a lot of bugs, and a lot of newer code just doesn’t work. The problem is, we can’t stop coding for it – IE6 still has over 10% of the browser market share. Now, it was neglected for five whole years. Then version 7 came along. IE7 fixed a few of IE6′s bugs, but from a developers point of view wasn’t anything special. A couple of years later IE8 was released – which much improved rendering all round.

Now, IE8 is a good rendering browser, it’s not too bad at all. It doesn’t however support any of the ‘new’ features of the web. Experimental things such as HTML5 and CSS3 simply don’t work. Is that such a bad thing? Well, yes. Because every other major browser (Chrome, Safari, Firefox) supports a good chunk of them and there’s a lot of things that we as developers want to use, but can’t.

Take my website for example – if you’re here in any version of IE you’ll see a very plain and very square design. Any other browser and you’ll likely see rounded corners, text shadow and box shadow – three small parts of CSS3 that really improve the visual appearance of a simple layout like this one.

Now, suddenly, Microsoft have realised they’re in a browser war once more – fall behind too much and people will walk away. Why is that troubling for Microsoft? Well, if you can convince people to use a new browser how much harder is it to convince them to use a new operating system the next time they buy? With increasing proportions of the smart-phone markets both Apple and Google are making people more aware of their products – and training them in their ability to use them. Google launches its own OS soon, how many PC users will be swayed to a computer with Google OS or for the richer of you, OSX?

Back on topic – IE9, slated for release in 2011. Another IE – great I think, as a developer. Another browser to support, bug fix and nannify.

But

I did something silly the other day. I downloaded the IE9 platform preview (version 3) and stood back in awe. Not only does it perform well in the Acid 3 test (83/100 compared to 20/100 for IE8) which although doesn’t beat Chrome’s and Safari’s 100/100 perfect score – is a vast improvement, but it also does something magical (in the words of Steve Jobs). Take a look at the screen shots below. On the left we have Chrome, on the right we have the IE9 preview.

IE9 Asteroid DemoIE9 Fish Demo

That’s right. Google Chrome was by far the fastest JavaScript running Browser for PC and on a par with Safari. Not anymore. The new IE9 sports a new feature – background compiling of JavaScript. This fancy feature punches Chrome in the mouth and sprints away fast. A staggering 22 times faster in the fish test and immeasurably (but at least 60 times) faster in the asteroid test leaves you blown away.

This is a feature I’m definitely looking forward to!

One thing I will note though, Chrome still loaded and rendered pages faster than this IE9 preview.

CamelCase, Hyphens – Under_scores

Monday, February 22nd, 2010

It’s a question many people ask. It’s a question many people want an answer to. But if you try to find an answer to the question “What should I use in my programming?” then you’re bound to find conflicting answers from various corners of the software sphere.

It turns out, that there isn’t any one right answer. Usually, you should do what works for you. More often than not, when you join an agency, you’ll be asked to conform to the current pattern set by the existing team, which itself will likely have been introduced by the first developer in a much younger agency many moons ago.

So, I can’t tell you what to do. But I can tell you what I do and why, and maybe it’ll help you? Who knows. So, here goes…

PHP

You name it, I’ve seen it. People use everything in PHP. Underscores, camel-case, underscores, uppercase, hy… no. Not hyphens. I’ve never seen hyphens.

Why?

Because – Hyphens aren’t allowed in variable names. And, assuming you’re a php developer you should know why. $variable-name is interpreted by PHP as $variable minus name. And what’s in a name? Well, without a $, PHP will assume it’s a pre-defined constant. So, first off, don’t use hyphens.

So, what do I use? I used camelCase. For everything. When it comes to high-level languages, most people use camel-case or underscores. I don’t think there’s anything wrong with underscores – I just happen to find it faster to hold shift and press a key, rather than hold shift to make an underscore, then type the next letter. So my variables look $likeThis. Constants though, should always be capitalised – this is actually pretty standard across most industries. That’s because, in languages that don’t use prefixes, it makes it much clearer. $variable and CONSTANT. Easy to see isn’t it?

Training languages, such as BASIC encourage you to capitalise keywords: INPUT, PRINT, DIM etc. But these days, we have colour-coded editors and it’s very standard to make everything lower-case except constants. Get it?

MySQL

Ah. Well, that’s just blown myself out of the water. When you type a MySQL statement, you DO type the keywords in capitals. That’s because it makes it VERY CLEAR to see which statements are DOOERS and which are ACTORS. SELECT name FROM users WHERE password = ‘hackme’.

By the way – never store plain text passwords. Ever. If you’re ever unlucky enough to be my subordinate and I catch you doing it I WILL FIRE YOU. Storing plain text passwords are bad for many, many reasons.

  1. People generally use one password for everything, regardless of how you educate them. If this password ever gets revealed to the world from your site, you’ve just screwed them over in multiple ways and they will sue you for every penny you, your family and your whole ancestry has ever earned.
  2. Regardless of how secure your website is, you can never be sure that your developers have remembered to secure every entry point. One hole, and a hacker can dump your whole database, and as bad as that is for your company, it’s worse for your customers. And then worse for you, when they all sue you.
  3. My website is safe, I’ve secured all the entry points. Or have I? What about the server itself? All the hundreds of processes and protocols it runs? Can I guarantee the work of the developers of all of those too? No. Never assume you’re safe for a second. Always keep your (to use a terrible cliché) ‘eye on the ball’.
  4. Ok, So I’m a GOD and everything is so secure I’ll never be hacked. But, it turns out, one of my employees is dodgy, and sold the unencrypted password database to someone for £1,000. They convinced them, it was just a list of passwords and emails for our site which is just a newsletter signup – what could they even do with that info? Easy money! Except they just successfully logged into a range of websites across 100,000 customers and ‘hacked’ several million pounds of wealth for themselves. Well done.

So remember: Watch your code, watch your servers, watch your employees. And if the site is hosted by another company – their employees might not be all on the level too. More security is better. The only difference you’ll have to make by keeping only encrypted passwords is to change your forgotten password system – send people a link with a unique hash ID to change their password, rather than re-sending them their password, which you can’t. Simple. But I digress…

JavaScript

Much like PHP, I like to use camelCase for JavaScript. Simple eh?

HTML and CSS

Oh, where to start. This is often the area I take most issue with other developers. As it turns out, a lot of HTML developers use hyphens in their class and id names. But I don’t – I use underscores.

Why?

Well, remember, hyphens aren’t valid variable names. And I like to pretend that classes and ids are variables. Especially when you have to manipulate these things with JavaScript – hyphens just seem to fail a little. I often relate using it to starting a class or id name with a number. I’ve seen it done by several people. What’s the harm in using or starting a class name with a number? It’s easy to use JavaScript to do cool things like that! Except – you just failed. Numbers aren’t valid variable names. var 6 = 9 just wouldn’t make sense to anyone. If I said to you: ’6!’. Would you think: ‘He means 6′ or ‘He means the contents of 6, which is 9′? But ids and classes aren’t variables, so why can’t I use numbers at the beginning of them? Well, to me it seems obvious – the people who developed it wanted to be consistent. So, stay consistent. Don’t use numbers at the beginning. And, I can’t stop you using hyphens, but I’ll respect you more if you use underscores.

Oh, and regardless of what you use, I won’t respect you at all if your sites don’t validate. There’s no excuse AT ALL to produce a website which doesn’t validate. Who cares? you ask. I care. And you’ll care when you do something dodgy that messes up in the next version of IE and you have 100 clients within their guarantee demanding a free fix!

Oh, and don’t go around using camel-case in your ids and classes. Because I said so. Generally, you’ll find all good sources of web tutorials will tell you to use lower-case for everything. It’s not good to mix case in HTML / CSS, because of the way some browsers can treat things (and why cause more preventable problems for yourself than you have to?) I know a lot of ASP developers do it. But, just don’t. The web elite web community is quite anal, and they won’t like you for it. And will tell you how ASP is a derivative of Visual Basic which is a derivative of BASIC which is a BABY language. And, I’ll join them in mocking you.

I think that’s everything. Did I miss something? Did I annoy you? Leave a comment!