Arranged Delirium

Students in web design are creating (possibly) a new web site for the ITL department. But one thing that is always important to me is making sure that everyone know how to publish email links without just putting them out there for spam-bots to harvest. There are all sorts of complicated ways to prevent this; but there are also some very simple ways that can limit the nefarious spam industry. Here are the simple ones in order of complexity:

1) You simply use the [amp#64;] character instead of the @ sign in your code. This is quite easy; but there are numerous email harvesting spiders that can reconstruct this, so the amount of protection is very minimal.

2) You could also use characters or even type the address differently to obfuscate the address: name (at) washjeff _dot_ edu. This works a bit better, but depending on the formulae, most of these have been cracked; and from a user-interface perspective it can create effort on the part of the sender. This is a less than ideal solution if you actually want people to contact you. Plus, its pretty easy to de-munge.

3) In your code you could replace the actual text with hex values for the characters. This provides a bit more protection that the steps above, but there are still bots that can crack it. That being said, unless you are attracting spammers, it’s probably enough protection. Most certainly, it’s better than nothing! You can find tools online that will generate this for you. This is probably the course of action that you want to take if you are avoiding javascript.

4) You can use javascript to obfuscate the email address. As long as users have javascript enabled, they will see a clickable email address, but the bots will encounter javascript. It’s only a matter of time until this process becomes less effective; but thus far it still works well for me and the organizations I’ve done development for. I use the online tool Enkoder to generate the javascript for me. Supper-easy.

Of course there are better ways to do this - you could create a form, use captchas (annoying), or use a php script to protect email addresses. But truthfully, the javascript method works well enough unless you are being targeted and it is much better than just posting the email address out there where anyone can see it. Publicly broadcasting email addresses is a sure indicator of novice development - you don’t want to do it.

Adobe appears to have thrown in the towel recently regarding flash development - at least for mobile devices. Reuters has an good article on the topic here. This clears most of the remaining barrier for the broad-based acceptance of HTML 5 as the development platform of choice for web development and web-based mobile apps.

This really shouldn’t be too surprising. Adobe has updated Dreamweaver in version 5.5 to be a viable mobile app development platform, and it’s bought out other text editors that might have fulfilled a significant competitive role. This does however make the forthcoming Adobe Edge product more appealing as well. In combination with the PhoneGap API libraries that you can access through Dreamweaver, this tool could enable app creators to include a significant amount of interactivity.

Students in ITL 275: Web Design and Development are developing a new site for the ITL department here at W&J. Part of the process includes determining the audience and identifying who you are trying to serve. This seems like a good point to remind everyone of NetMarketShare which hosts monthly breakdowns of web content access by device and platform:

Some interesting notes - IE still makes up over 50% of desktop browsers. This isn’t as horrible as it once was, since both IE8 and IE9 are acceptable browsers; but 13% of users are still employing IE6 and IE7, meaning that there’s a whole lot of content that they can’t get to unless the developers are conscientious enough to query for the browser version and push out a different stylesheet.

Another resource for students is the Web Style Guide (2nd). Ignore the third edition - it goes too far afield for the work we’ll do this term.

I’m always telling my students not to plan on Flash as the sole tool for web animations, and I think they are always hesitant to believe me. But as I move toward implementing HTML 5 in my web development courses, I don’t see any reason not to abandon Flash altogether for the types of things we do. (And, I would argue that most folks developing Flash content do not use its full set of capabilities.) Anyway, I’ve been looking at Hype as a potential tool for creating simple web animations that will work on all devices. Check it out!

One great thing about web development over the past couple of years, is that we’ve finally seen a breakdown of the IE hegemony! IE is still over 60%, but at least most folks are running version 8. (Really? Why are you still using IE?) But its made testing and developing web sites a bit more of a chore. Add in the recent explosion of varying mobile devices, and suddenly you’ve got a couple dozen viable operating systems and browsers to support. (Or, at least to think about supporting.)

As a professor at a small college, its become beyond my abilities to support and maintain multiple testing kits - even with dual or tri-booting machines, it’s too time consuming. So, I’ve decided to outsource. There are two compelling services that I know of off the top of my head: Litmus and CrossBrowserTesting. I decided to test both, and both are quality services. I think that if you were running email marketing campaigns, Litmus might have an edge for you. For general web development, I found both services adequate. In the end, I decided to go with CrossBrowserTesting, primarily because: 1) it was cheaper, 2) did everything I needed, and 3) had a more robust free trial period which made for a better evaluation.

Best of all - this is going to speed up certain elements of my grading in my web development courses…

Other Notes: Most everything works on the Mac OS with each browser. Linux/Unix boxes running Firefox are all good; some of the ancillary browsers are problematic, but do a good enough job of rendering most valid CSS and constitute such a small market percentage it’s not worth addressing. Windows machines are much more problematic; but if you are running a recent version life is better. IE versions before 8 remain the biggest problem. The question now is: do I add browser detection and route folks to a different style sheet, or just forget about it? IE 6 & 7 make up about 24% of the general web viewing population, and about 8% of the folks that access my content.