I got 5 test emails from different web developer friends today asking me if this christmas ecard in email format looks good in my email client. Most looked messed up in one way or another, and all had the images initially blocked and flagged up the loading as a security issue.

So here are some of my thoughts on HTML email:

• email is probably the most spammed way of technological communication
• most security issues and virus breakouts are caused by email or messaging software and users who do not know better than to click a link or run an attachment
• If I wanted to know that you read my emails, I’d embed a cgi script as an image
• the display size of email programs is totally unknown, and I don’t know anybody who opens emails fullscreen by default
• Multipart emails (embedded images and HTML) might be filtered out as spam or possible virus threats
• different email clients support CSS/HTML to different degrees, in addition to online email clients like gmail, yahoo or hotmail. It is a bit like trying to make everything perfect for about 20 different browsers.
• Multipart HTML email can get rather big

Now, do you want to spend a lot of time on something that is very likely not to work out and spook your clients or wish them happy christmas?

The solution for wishing them a happy christmas: Host your ecard on a server, send them a link. You’ll know that the email will arrive and not cause warning lights to go on and you draw visitors to your site to boot.

I looked over the wireframes of a new project today and discovered a weird one for the use case of entering a PIN number: The client defined a keypad like you would see on a cash machine, and requested that the user should enter the PIN thus – via the mouse.

The accessibility militia member in me started to frown upon this, considering that a password field is a lot easier to use and wondered if that is a marketing
gimmick.

However, upon reading further into the requirements, I realised that it is a security measure to prevent keylogging software to store the pins users enter in the application.

However, I don’t think that there is a truly accessible solution for that problem, as you will need JavaScript to change a field’s value when clicking other buttons – unless you want to reload on every button click.

I came up with a DOMscripting solution for the problem, check the test page for DOMpinpad here and wondered if there are more options to improve this.

Currently the pad

• only applies itself when DOM is supported and JavaScript is available
• renders the PIN field readonly and greyed out only when the pad can be used
• can be used with a keyboard and tabbing and with the mouse (is there a safety hazard in the tabbing ability? Wouldn’t that be trackable, too?)
• is self contained, as in plays well with other scripts
• is styleable via CSS

I tested it on MSIE 6,Firefox and Opera on PC and Safari on Mac, please report any problems you may encounter.

If this one is considered a worthy solution, I will wrap it up and release the code at a later stage.

Installing the .NET 2 framework to run CSS Vista corrupted my registry and the laptop went straight into BSOD when booting. Therefore I had to parallel install Windows (as the repair explanations on MSDN didn’t work) and got the chance to clean up the mess that accumulated over the last 3 years. It was a great feeling simply deleting folders to get rid of Software, much like a Mac…

Anyways, here is the Software I consider really necessary for me to work efficiently, maybe you can find some things you hadn’t used or known yet, and I am happy to get more tips in the comments. (more…)

Some of you may remember Bobby van der Sluis’ Unobtrusive Flash Objects – a clever way to add Flash to pages only when and if the browser supports it.

Paul Colton has now come up with a different idea of making JavaScript and Flash boogie, a JavaScript wrapper for Flash called AFLAX . What this script allows you to do is to script Flash animations with JavaScript – not the Flash IDE or ActionScript.

It does look sexy and pretty cool, but as some other comments at AJAXIAN already pointed out, it seems that we have a hard time to find a good use for this idea. I can imagine that in a closed environment, you can do some nice things with it – like interactive graphs. With Flash being able to talk to the backend and JavaScript doing the same via AJAX it does feel a bit like mixing technologies that don’t need mixing.

Well, I guess we should keep our eyes open what is happening to that.

I just came back from a quick vacation in Munich, and on the train I wrote a small introduction to pop-under ads for a friend. Personally I am not a friend of ads, pop-up or pop-under, but sometimes you need them.
The main problem I have seen so far is that bad implementations cover the content even when JavaScript is disabled, thus making it impossible for the user to get rid of them.

This article describes how to create user friendly pop-under ads with CSS and DOM and offers an example that only covers the main content and gets a “close” functionality when the browser allows it.

Hopefully you’ll find it helpful.