Check out this resource at dancingengineer.com.

jQTouch is a jQuery plugin with native animations, automatic navigation, and themes for mobile WebKit browsers like iPhone, G1, and Pre.

You can preview right on your iPhone or watch a demo.

(thx, Scott)

jQuery focuses on expressiveness, quick and easy coding, and the DOM while MooTools focuses on extension, inheritance, legibility, reuse, and maintainability. If you put those two things on opposite sides of a scale, the jQuery side translates into something with which it’s easy to get started and see quick results but (in my experience) can turn into code that’s harder to reuse and maintain (but really that’s up to you; it’s not jQuery’s problem, per se), while the MooTools side takes longer to learn and requires you to write more code upfront before you see results, but afterwards is more reusable and more maintainable.

For me, I decided on jQuery a while back and we’ve opted to do the same at Wall St. We’ll see if jQuery stands up to the maintainability test over time, but for now, I contend, the library is giving way to faster and better development.

Here at Wall St., we host some of the largest financial websites on the Internet. From The New York Times to E*TRADE and Barclays to Charles Schwab, our data centers serve content to millions and millions of users per week. It’s imperative our websites provide accurate market data, look good, are easy to use, and are fast. With so much information to relay, we’re pushing a lot of data (including scripts, CSS, images, etc.) through the pipe. So Nicole’s presentation was perfect fodder for our design and development teams.

A few highlights from her talk, with some links for your consumption follow.

• Nine best practices for designing and building faster websites:
  1. Create a component library of smart objects.
  2. Use consistent semantic styles.
  3. Design modules to be transparent on the inside.
  4. Optimize images and sprites.
  5. Avoid non-standard browser fonts.
  6. Use columns rather than rows.
  7. Choose your bling carefully.
  8. Be flexible.
  9. Learn to love grids.
• Watch her presentation on the YDN.
• PNG8 is the clear winner for images on any website. They’re smaller in file size than GIFs (I didn’t believe it until I saw it), and they support transparency in IE5.5 and IE6. No CSS filter hacks needed. If you’ve got a copy of Fireworks, you’re in business because Photoshop doesn’t help create PNG8′s transparency. If you don’t have Fireworks and are comfy with the command line, see this guide to making alpha transparency in PNG8.
• Embrace Smush.it — a web service and Firefox plugin created by Nicole and former co-worker Stoyan Stefanov. The tool allows web developers to upload images of any kind while Smush.it runs through a long list of compression algorithms stripping meta data and needless information from them before spitting them back to you in a Zip file. It all happens in seconds and a few tests we ran here — 15 images reduced in size by 320kb (99.18% compression rate) — yielded impressive results. Evidently, Smush.it is in the process of being adopted by Yahoo! which has immediately interrupted the service (but hopefully not permanently).
• Consider Object Oriented CSS, or OO CSS. Much of OO CSS is in the 9 best practices mentioned above. But it’s not what you think. It’s not object oriented in the traditional programming sense of the term. It’s object — as in a virtual thing: a module, a header, a sidebar bucket, etc. I had a hard time with this one in the beginning. Most of OO CSS is pure common sense — at least it is here at Wall St. Sit down, evaluate your designs before you start building, and determine a baseline for common elements across the site. Then piece together your CSS efficiently. Three really useful tips for page layout:
  1. Don’t use height-specific modules. Let the content determine the height. This is genius and must be recognized by designers. Vertical grids, not horizontal.
  2. If you have two or three modules with rounded corners that are different but look similar, just pick one and move on. “Users aren’t that sophisticated,” she said.
  3. Use grids to determine layout, and let the content fill 100% of the available space. This way two columns becomes three columns or becomes 6 columns and the content continues to just fit.
• Set aside a few minutes to watch her presentation on OO CSS. It’s not earth-shattering stuff, but she does make some interesting points that convinced us to approach web dev from a slightly different angle.

Thanks Nicole. Safe travels in India.

His claim that crappy code is inevitable is based on the notion that crappy code is cheaper than clean code, and that therefore businesses will demand the crap every time. But it has generally not been business that has demanded crappy code. Rather it has been developers who mistakenly thought that the business’ need for speed meant that they had to produce crappy code. Once we, as professional developers, realize that the only way to go fast is to create clean and well designed code, then we will see the business’ need for speed as a demand for high quality code.

I’m in the business of web-based software and website development where clean code is paramount but deadlines always seem to win. There just aren’t enough hours in the day and days in the month to get through all the requirements. The process usually works like this: business development sells the job, design chews through the schedule, development is a rush, and quality assurance is an after thought. And, as Bob and Ed clearly point out, this is certainly not the best way to develop software or websites.

(Thx, Tim)

Until some future version of HTML gives us new native controls to use in a browser, at Google, we’ve been playing and experimenting with controls we call “custom buttons” in our apps (among other custom controls).

(via)

I say what he says:

“One way to judge the scope of an app is to think about how much time you’re intended to spend using it. There’s plenty of room for apps you use here and there for a few minutes at a time, or which you launch just once or twice a week. There’s hardly any room at all, though, for apps you work in for hours at a time, every day.

By this measure, Coda, the new app from Panic, is an epic.”

Kudos, John.

First, let me say if you haven’t read that article, do so now. If you have already, continue. Remember we started with a simple but obtrusive “halt!”? The code looks like this:

var needToConfirm = true;
window.onbeforeunload = confirmExit;

function confirmExit() {
if (needToConfirm)
return "Are you sure you want to leave?";
}

We modified the above to handle many more fields, and to compare arrays using a combination of functions afforded to us by Prototype, 4Guys, and others. You should view/download the full script to see what I’m talking about. All this excitement is of course about how this script can now process (check, compare, validate) all the fields on any form. When I discovered this I slapped myself on my forehead like those new TV commercials for V8. Doh! It’s easy:

On line 4, replace this:

var f = $$('div#myform input');

with this:

var f = $$('form#id input','form#id select');

Replace “#id” with your form’s Id. Using Prototype’s utility function, this creates an array of all the form fields and hands it off to our script… ultimately stopping a user if they made a change to any values, and letting them go if they have had a view-only session.

Editor’s note: The previous version of this script was downloaded a ton of times. I’m assuming folks are using it, and I’m positive there are ways to improve it. Comment away!

For now, note my RSS 2 feed has changed location:

http://markhealey.org/feed/rss2/

Despite it’s numerous (and not-yet-fully-tested!) successes, there’s one fatal flaw with this new application I’ve built: the primary users are coming directly from a Microsoft Office Access ’97 form-driven database. (I know what you might be thinking. This gets good. Read on.) Their current Office system works well, but it’s been patched, band-aided, and added onto countless times since the early part of this decade. In fact, when it loads, the Access ’97 “dashboard” has 20 or 30 differently-colored bricks which when clicked take users on a magical ride through literally hundreds of custom queries, and thousands of records in one single gigantic table. Each of the company’s employees is fluent in the myriad codes and mystical shorthand that make up each row and column of data. It’s something to behold, let me tell you.

Over the past months, through endless revisions of specification documents, writing line after line of semantic code, and creating ingenious ways to handle complex scenarios, one of the simplest issues arose. It is a direct result of my client’s full-time use of and dependence on Access ’97, and it’s fun save-as-you-move-from-field-to-field feature. Users never have to click a “save” button, and can fly around updating customer data in a dash. Not so with the new web application. Here’s how we fix the problem.

Preventing Users from Leaving Without Saving Their Data

There are two views in the new software where numerous text fields, checkboxes and select boxes grace the page. During some initial testing, we found that users were changing data and immediately bouncing along to another view without saving their changes – an action they were quite comfortable performing in the past. It became clear I had to write some code that stopped users from leaving the page unless they saved their changes.

I immediately turned to the DOM’s onbeforeunload event. We’re already using a short and sweet function on the multi-step customer application form which is somewhat obtrusive; a user cannot go anywhere, close the browser, or even refresh the page without being hit with a JavaScript confirmation box asking them if they’re sure they want to go. The code looks like this:

var needToConfirm = true;
window.onbeforeunload = confirmExit;

function confirmExit() {
if (needToConfirm)
	return "Are you sure you want to leave?";
}

This wonderfully-crafted little snippet comes from 4GuysFromRolla. Although nice, I needed something “smarter” that only prompted a user if and only if they made a change on the page. Scott Mitchell, the 4Guys author, continued in his article with an example of how to achieve this by creating two JavaScript arrays and then looping through them comparing the values. Great inspiration, Scott. I couldn’t use this script because I have two dozen fields on one view (it actually looks pretty good) instead of his six and typing out each field ID would take too much time. So I used his example, and wrote this relatively short set of functions:

	//markhealey.org
	//Inspiration from Scott Mitchell: http://www.4guysfromrolla.com/webtech/100604-1.shtml

	var f = $$('div#myform input');
	var needToConfirm = true;

	//Get all form field values
	var formDBVals = '';
	for(var i=0; i
		formDBVals += "'" + escape(f[i].value) + "', ";
	}
	formDBVals += "''";
	//New arrary to hold DB vals, before changes
	var the_values = new Array(formDBVals);

	//http://www.breakingpar.com/bkp/home.nsf/Doc%21OpenNavigator&87256B280015193F87256BFB0077DFFD
	function areArraysEqual(array1, array2) {
	   var temp = new Array();
	   if ( (!array1[0]) || (!array2[0]) ) { // If either is not an array
		  return false;
	   }
	   if (array1.length != array2.length) {
		  return false;
	   }
	   // Put all the elements from array1 into a "tagged" array
	   for (var i=0; i
		  key = (typeof array1[i]) + "~" + array1[i];
	   // Use "typeof" so a number 1 isn't equal to a string "1".
		  if (temp[key]) { temp[key]++; } else { temp[key] = 1; }
	   // temp[key] = # of occurrences of the value (so an element could appear multiple times)
	   }
	   // Go through array2 - if same tag missing in "tagged" array, not equal
	   for (var i=0; i
		  key = (typeof array2[i]) + "~" + array2[i];
		  if (temp[key]) {
			 if (temp[key] == 0) { return false; } else { temp[key]--; }
		  // Subtract to keep track of # of appearances in array2
		  } else { // Key didn't appear in array1, arrays are not equal.
			 return false;
		  }
	   }
	   // If we get to this point, then every generated key in array1 showed up the exact same
	   // number of times in array2, so the arrays are equal.
	   return true;
	}

	function confirmExitAccountInfo() {

		var formChangedVals = '';
		for(var i=0; i
			formChangedVals += "'" + escape(f[i].value) + "', ";
		}
		formChangedVals += "''";

		var the_changed_values = new Array(formChangedVals);

		if(needToConfirm) {
			if(!areArraysEqual(the_values,the_changed_values) ) {
				return "It appears you changed some info. Did you mean to leave without saving it?";
			}
		}
	}

	window.onbeforeunload = confirmExitAccountInfo;

Let’s examine this script. We first need to set the variable “needToConfirm” to true, so as soon as the page loads, we assume the user is going to get the save-before-you-leave prompt (unless they click “save”). Then using the Prototype function $$(), we load the values of every field in my form into an array called formDBVals by using a simple for loop. Since most of the fields on the view are pre-loaded with information from our database, we easily have access to this data. But you could fill your array with null values. We ultimately want to capture any changes the user makes, and prompt them to save them before leaving the page.

To track changes the user makes, we’re not actually doing anything fancy… just re-looping through the form fields, and comparing the original array (formDBVals) to the values in a second array (formChangedVals) when the form is saved. Using a snazzy script I found at BreakingPar, we quickly compare the two arrays. If they’re different, that is, if the user changed anything, we fire the save-before-you-leave prompt. If the two arrays are the same, then the user hasn’t changed any values… and of course, they’re allowed to leave. We also have to add “needToConfirm=false;” to the submit button’s onclick.

What started with obtrusive prompts which get really annoying – especially if nothing’s been changed – has now evolved into a smart script that’s completely reusable in any form. Remember, you need to include the Prototype.js for this to work.

Use it in your app, just please give 4Guys and me some credit. Download the JavaScript. And check out the live demo at 4GuysFromRolla.

Update: Sorry friends, I forgot to mention: This script does not detect checkbox or select box activity; only text fields. If you have that working, let me know and I’ll append this script for everyone.

SitePoint contributor Kevin Yank authored a post titled, “Microsoft Breaks HTML Email Rendering in Outlook 2007.” I didn’t even get past the opening paragraph before I started having heart palpitations. You may recall an article I penned last November on the topic of formatting XHTML emails for today’s myriad mail clients.

If support for web standards in browsers is improving slowly, then support in email clients is moving at a glacial pace.

Microsoft has officially decided to drop the IE-based rendering support from Office Outlook 2007 in favor of… you guessed it, Word. Great Scott!

I wouldn’t categorize myself as a Microsoft hater, but this decision ranks up there on the Top 10 Most Moronic Moves Ever Made While Trying to Win Over Web Developers list. For the first time in years, Microsoft releases an update to their highly used web browsing client which is significantly more supporting of web standards than previous versions. Yet, Redmond opted to use Word’s far superior web page rendering engine in Outlook. I am, of course, being as sarcastic as I’ve ever been.

The news, as bad as it is, is not the end of HTML emails in Outlook. We’ll have to redesign them to be thinner, with less emphasis on appearance and more on getting back to plain-and-simple content.

Unless Microsoft does the old switchero, with the impending release of the consumer version of the Office 2007 System, expect to redesign your HTML email templates in favor a much less instead of what IE7 offers — much more.

Enter stage left: Douglas Bowman’s Sliding Doors of CSS courtesy of ALA.

I added two tabs to my new view, repositioned them on the right side — which took some fancy footwork because this awesome technique only demonstrated the tabs as left-justified — and started the browser testing. With some minor edits to the CSS, my new tabs worked perfectly in almost uniform fashion, except in IE7. The browser correctly interpreted both of these declarations, including the Holly Hack (a.k.a. the Be Nice to Opera rule), previously undetected by IE.

#tabbednav ul { margin: 0; }
html>body #tabbednav ul { margin-bottom: -10px; }

A post on Zeldman.com helped me figure this one out, and allowed me to specify rules using a modified Holly Hack. This declaration targets Opera and Mozilla browsers, but all versions of IE don’t see it, including IE7:

html>/**/body #tabbednav ul { margin-bottom: -10px; }

Thanks to Zeldman and donovan.

Update @ nearly 4PM:
After further testing, Safari picks up my modified Holly Hack and improperly renders my tabs. I guess I’m going back to the drawing board.

Update @ just a bit before 4PM:
Ok, final update. I promise. In the end, I was able to make some modifications to one other rule and didn’t end up needing the negative margin. If anyone knows more about this “/**/” hack, ping me, I’m curious now.

If you have ever tried to send an (X)HTML email from your web apps, you and I both have a lot more to ask for.

I’m currently writing an application for a client of mine that’s rich in user interaction. In part, users can create accounts, verify email addresses, forget passwords, and more of the standard account-related functions. Needless to say, without any unnecessary overkill, we will be sending a good amount of emails to my client’s user base. I could have easily opted to send text-only messages, but the requirement included displaying a logo, bolding text, and other graphical presentations otherwise not available in text-only. So, without much hesitation, I charged ahead. Whip up some clean (and strict) XHTML, use loads of my already-fine-tuned CSS rules, pump in some content and we’re off!

Wrong. And this was just the beginning.

I use my Gmail account for testing — it’s convenient because all the messages get lumped into one conversation for easy review, not to mention the huge disk space and (my favorite) delete button closely within reach. But for all of Gmail’s successes, it sure wreaked havoc on my nicely-formatted XHTML messages. Evidently, Gmail strips every shred of code out of your email, and rebuilds it in its entirety before spitting it back into it’s wonderfully successful conversation view. Those unique div, span and other IDs? Gone. The short and sweet CSS rules? Gone, and definitely not working. Hell, even my one-line footer wrapped in a small tag didn’t render properly. I now know why I can’t read my itinerary confirmations from the airlines in Gmail.

To make sure I wasn’t out of my mind, I changed my testing email address to an account I manage with Outlook on Windows and Mail on the Mac. Naturally, the message came through looking as perfect as I could have ever imagined. I repeated this process with Mozilla’s Thunderbird and then webmail at Yahoo!, Hotmail, and AOL — all succeeded, but in different ways. Microsoft’s widely-used Outlook client performed the best (same goes for Outlook Web Access), followed closely by OS X’s Mail. Neither re-wrote my code. Yahoo! did better than Hotmail, but Hotmail’s new interface liked the HTML and CSS hybrid a little more than the old but it still wasn’t perfect.

I am fighting an in-browser application war! Here we have browser-based applications developed by the world’s largest software manufacturers performing the same basic functions displaying standard XHTML and CSS content from the same source — and it just doesn’t work. Grrr. In the end, it’s Gmail that is causing the biggest headaches.

Yesterday, I finished restructuring the code following tips I read about on this highly-useful Interweb (I love that old Verizon DSL commercial). Here are a few that helped me get going again:

• Don’t put anything in the head of your email template.
• Forget the love you have for your fine-tuned CSS document; there’s no hope of using it (as an externally linked file). You’ll have to drop all your classes and ids replacing them with hideous inline styles. If your email’s recipients use Gmail, you’ll need to do this one.
• If all else fails, especially with AOL, use a table to position your goodies. I can’t believe I typed that, but when it comes to this and saving time, it works.
• Have patience. I nearly tossed my lappie out the window on more than one occasion.

As of yesterday, my client’s customers are ready to receive fancy-schmancy emails. No matter which mail client, web-based or desktop, Mac or Windows, they’ll all see the same content — as it was intended by this designer. Now that it’s done and I’m filling out my time sheet, I find myself having a hard time justifying the large chunks of time spent formatting arbitrary (yet critical) emails when there’s plenty of other work that needs doing. It seems funny to me but after all these messages, like them or not, are part of your app and, more importantly, your client’s outward-facing marketing.

Poor XSL
One of the reasons I’m discontent with the three biggies — Safari, IE7, and Firefox 2 — is their apparent blatant disregard for a designer’s freedom to exercise his or her right to a custom XSL—styled XML feed. I don’t normally spend too much time writing XSL documents, but for one client’s particular requirement, they wanted a custom XML feed page. The client’s user base, we anticipated, was not RSS-savvy and we’d hoped to ease them into the process for consuming news, regular updates, and more. So, enter a fairly simple XSL style sheet and the über—friendly appearance of styled XML. Not so in the latest versions of these browsers.

It’s possible that I haven’t yet found the setting in the browser preferences or the line of code that fixes it, but the aforementioned Big Three are overriding my XSL! (Opera handles the XML as intended.) They favor their own display of RSS feeds and bully mine out of the way. (See theirs. See mine.)

I’m not even going to try to explain why the software makers decided on this, so if you know of a fix, let me know.

As time ticks later here on the east coast and my original content engine is in the garage for the night, I wanted to quickly tout a new forum package delivered as my early Christmas present from the folks over at WordPress. Called bbPress, they say it’s “simple, fast, elegant” — and from the less-than-3-minutes it took me to install it and give it a quick test drive, the software is certainly all that.

I’ve got a client that could use something just like this as their phpBB install is bloated and plagued with SPAM. I’m not going to hold out for bbPress’ coming-soon template system — I think I’ll dive right in and get customizing.