Archive for the ‘Development’ Category

Email Accessibility

Monday, July 16th, 2012

We all know that emails are notoriously difficult to build across the vast swath of email clients, and you might think that there’s nothing you could do about making them as accessible as possible.

But you’d be wrong.

Let’s take this example from the most profitable company in the world: Apple.

An email footer from Apple, demonstrating their lack of understanding in accessibility.

When design hinders accessibility

Straight away we can visually see a number of accessibility issues.

  1. Colour contrasting. You can almost see why Apple have designed their ‘small print’ this way. They don’t feel that it’s important to the message contained in the email, so they’ve made it as invisible as they can, but this is wrong. Not all visually impaired users are blind. Most of them won’t even use a screen reader such as Jaws to have a site read to them; this is the last possible option for most people trying to retain their independence. Unfortunately Apple have chosen grey on grey – a VERY difficult colour combination for anyone to read, let alone those who have trouble distinguishing multiple shades of one colour for fine details.
  2. Size. Now, we all know this is ‘small print’, but why does small print exist on the web? The old ideas of limited print space and “Let’s make this as small as we can so nobody reads it” are long since past. The web contains as much space as you want, and the public are more appreciative of legal and privacy information than ever before. This size will only impede those who want to read it, and unfortunately that again will affect your visually impaired readers.
  3. Links. Apple have made the classic mistake with their links, a mistake which is so old it’s actually quite shocking that they have done this. ‘Click here’. Why? What does it mean? You might be forgiven for thinking that the surrounding text might explain why you want to ‘Click Here’, but what about your users using a screen reader? Many feature a mode to simply read out links so that a user can quickly navigate your site. To a screen reader, using the image above, this would sound as follows: “www.apple.com/uk/studentoffer”, “Click here”, “Click here”, “Click here”, “Click here”, “Click here”, “All Rights Reserved”, “Privacy Policy”, “My Apple ID”, “Click here”.

You probably aren’t in charge of an email department quite as large as Apple’s, but if you avoid these obvious mistakes then you can be sure that yours will be better.

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?

Apache unexplained resets

Tuesday, April 19th, 2011

Sometimes you’ll be coding away and discover something peculiar. One such example is when attempting to run a regular expression on a very long string (1000+ bytes) on a default WAMP installation. Apache randomly ‘resets’ the connection. This is because you’ve caused it to crash. There’s no explanation and even the Windows event log doesn’t reveal any useful information.

The reason of course, is because you’ve overflowed the stack, Apache has run out of memory and crashed.

The fix is simple; just add this to your Apache config:

<IfModule mpm_winnt_module>
ThreadStackSize 8388608
</IfModule>

Problem solved.

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!

iPhone app Development Collaboration

Tuesday, June 30th, 2009

Last Saturday was an interesting day. Mid afternoon my good friend Ben Dodson came over. He wanted some help (or some basic prodding in the right direction) to help make an app for his new iPhone 3GS. The app he wanted to make? A metal detector of course!

One of the things the new iPhone 3GS has is an internal geographic compass. This is achieved with a device known as a magnetometer – something which can give you a 3-dimensional X, Y, Z co-ordinate to the magnetic north pole. The great (and sometimes frustrating thing) about these devices is, that they’re influenced by nearby metallic object, albeit, not by much. Still, this ‘negative’ effect is one we wanted to exploit, and turn into the first visual metal detector app for the new iPhone.

My ‘study’ is actually the largest bedroom in my house, consisting of a high end, 3 monitored PC, a sofa in-front of this, surround sound and a projector, which can display a 4th, 100″ screen from my PC (which I use for TV and DVD’s) or my Wii. Ben sat on the sofa with his Macbook, poking around with the iPhone developer SDK whilst I sat at my desk, seeing what physics were involved in making the app work. After some quick testing we discovered that this would be a fairly easy thing to achieve.

During tests I noticed that metals which tend to be more influenced by magnets were also the items most easily detected – Iron was found easily, but Aluminium barely registered. One of the other things I discovered was the influence of magnets on the 3GS – the stronger the magnetic flux, the higher the influence on the 3D geometrics. After this discovery, and our current lack of icon for the project I had an epiphany and said “Flux. This thing measures Magnetic flux too. How about a flux capacitor?”. Anyone who loves Back to the Future will know what that is! This remains my most significant contribution to the project.

Ben began to code the scale and graphics, whilst I created a mask to produce the curved effect, and generated 20 distinct square wave sounds, one for every 5 points of difference in our calculation of metalness / flux. Soon after finishing this whilst Ben was still coding, I began to work on the website. Ben had an idea in his mind of what the site could look like, which I largely kept to. You have to love the little South Park style versions of us (can you tell who is who?) It was decided that, due to IE6′s lack of position:fixed we’d instead have a little conditional message for IE6 users, informing them of some better browser choices.

After we’d finished producing the app and start of the site, we went to record the video in my dining room, with my Panasonic Lumix (The resolution on that thing isn’t too bad for a video). The final cut of this video features me swearing (sorry about that) and the sound of the doorbell, as a nice man delivers our Indian curry. Mmm.

Dinner over, Ben cut and uploaded our video and submitted our app, whilst I polished off the website. We also discovered at this point that it was gone midnight and Ben had missed the last train (bless). I very generously let him stay in my spare room.

Morning came, some more tweaking, and a special twitter feed for our new collaborative code site and that’s that.

So, go now and witness the fruits of our labour, achieved in one Saturday evening: philandben.com