Tom Mollerus' Weblog

So asks David Pogue of the New York Times, who describes the benefits of Web 2.0 as offering "a direct, more trusted line of communications than anything that came before it."

Around my office we have discussions about just what "Web 2.0" means. I usually interpret it in a more technical, feature-oriented fashion, saying that it applies to sites that have near-real-time interactivity with a web site, using AJAX to make themselves appear to work more like a desktop application than a page-request-based website. My boss thinks of Web 2.0 as meaning that a site has a user community and user-contributed content. There probably isn't just one meaning to the term, anyway. But Pogue gets the point-- it's no use talking about what Web 2.0 means. You just want to concentrate on what benefits it has to your company:

"When a company embraces the possibilities of Web 2.0, though, ... it [will] gain trust, goodwill and positive attention. You'll put a human face on your company. And you'll learn stuff about your customers that you wouldn't have discovered any other way."

Completely true. And here are other ways that your web site reflects the character of your company:

• The design: does this company have enough money to afford a good designer?
  
  
• The copywriting and layout: is the company smart and detail-oriented?
  
  
• The server uptime: is this company reliable?
  
  
• Graceful degradation: does the company think about its customers and their needs?
  
  
• Snazzy, cool AJAX features: does the company willing to explore new ideas?
  
  
• Splash page: is this company so into its branding and so clueless about what users really want to know that it throws a useless splash page in their way?
  
  

A colleague just brought the coolest feature to my attention: on the NY Times' website, you can bring up search results on any term they use in an article merely by double-clicking on the words in the article itself. You don't have to go typing in a search box, or pull up a contextual menu with a right-click.

After my recent post on enabling resizable textareas with the textarea-resizer script, a reader noted that the script shouldn't be run in Safari 3 since that browser adds its own resizer widget in the lower-right-hand corner of all textareas. So, with confirmation from the script's author Jonathan Leighton that the textarea-resizer script is redistributable and modifiable under the GPL, I've posted a tweak to the script so that it won't run on Safari 3. I've also included my own stylesheet and handle graphic for the grab bar.

I came across FancyZoom the other day, which calls itself "Smooth Javascript Image Zooming For Your Web Pages". It's a lot like lightbox, but with a "zoom" effect and no shading over of the original page.

In a few applications, I've noticed a relatively new feature (at least, new to me): a "handle", or bar, at the bottom of a textarea that allows you to resize it by clicking-and-dragging. I think this is a great addition to the usability of any site where a user might type in just a little or a lot into a textarea.

There are a number of JavaScript toolkits which can give you this capability, but not everyone wants to add the loadtime of a full toolkit to their site. So I'll point out one script that can give you this capability: Jonathan Leighton's Textarea Resizer.

Hareni Venkatramanan of Adobe commented on my previous posting about an issue with how ColdFusion 7 and 8 display labels for small values in pie charts, saying that there was a solution posted for this issue in the 7.0.1 Updater. Indeed there is-- but the solution isn't applied automatically via the updater. Instead, you have to edit the XML files that define your chart styles. Read on to see what the new chart looks like and to find out how to edit the XML file.

When you click on the "Member login" link on the Text Link Ads site or respond to a comment through the admin section of a Movable Type installation, you'll be presented with a new form in a slightly different manner than you're probably used to: instead of being sent to a new page, or seeing a popup window, the current page darkens, or "greys out", and a form appears immediately overlying it. It's a really neat way to keep the user in the current page context, and it neatly gets around the growing tendency for users to suppress popup windows.

They both do it with Lightbox Gone Wild, which is an adaptation of Lokesh Dhakar's Lightbox project. It's a very easy technique to pull off... link to three script files and one stylesheet in your main page; create a second page containing the code for your form; and then put a link to the second page in the main page with a class of "lbOn". Complete instructions can be found on the Lightbox Gone Wild page.

I know that cfwindow offers some of the same functionality, but it seems to me that cfwindow can't achieve the same level of flexibility as Lightbox.js can. For instance, I think cfwindow is somewhat more limited in how much of it you can style, and is also limited in whether forms in the dialog area can target the whole page.

I'm finally ready to share ClickHeat for ColdFusion with the rest of the community. It's a port of Labsmedia's original ClickHeat project, which is written in PHP. ClickHeat shows you where users are clicking on your pages: which links, which graphics, which nav items.

ClickHeat has two main parts: a JavaScript which tracks click coordinates and sends them via AJAX to a .cfm page which saves the information to a log file; and an application which reads the log file and converts it to a click map or heat map. A heat map creates a fuzzy, color-coded map telling you where the greatest amount of click activity occurs on your page (cooler blues indicate less activity, while brighter yellows and reds indicate more activity).

You can check out ClickHeat in my projects section. Please let me know what you think or if you run into any problems using the code.

In a few of the apps I've written there's been the need to show users a preview of a newsletter email or stock alert email. Before AJAX was widely known and available, you used to have to provide some action that would submit a form and refresh the page in the browser, perhaps interrupting the flow of the user's experience in the process. But today I noticed that the email service provider iContact has a great way of handling one-off preview emails without making you leave the page you're on.

While thinking about which features to include in one of my applications, I decided it would be valuable to customers (and a good mental exercise for me) to provide the cabability for the app to support different languages, and to support the ability for the user to add new languages of their own.

I will admit that while I did look around a bit for articles on how to achieve this, I didn't look very hard, because the solution seemed readily apparent...

In my recent post titled "Preventing multiple page requests after double-clicks", I suggest a way to use JavaScript to prevent multiple requests resulting from double-clicks on submit buttons or links. In the comments of my posting, Sam Farmer mentions the technique of putting "...the submit button in a span or div and after submission change the span or div contents to say 'Processing' or something like that." His is a great idea, and one that I've used myself in other sites. I responded that I'd blog about my technique for changing the appearance of a submit button to show that it's been clicked, so here goes!

A friend asked me for advice today on a problem he had been experiencing with his ColdFusion application. On around one out of every 500 requests, there would be an error saying that a certain session variable was undefined. He wondered if the problem was that he was deleting the session variable at the bottom of the page, but I assured him that it couldn't be the source of the error earlier in the page. But the answer I suggested was... double-clicks.

I think that double-clicks on a link or submit button could cause the same page to be requested and run twice at almost exactly the same time. The first request would run but never reach the browser; the second would run and then be sent back to the browser. If the timing was right, the first request would destroy the session variables right in the middle of the page processing of the second, throwing an error in the process. So what can be done about it?

Using the Symantec Store checkout process today to renew NAV for some of the office computers, I found myself baffled by one of their input requirements. Under the phone number field on the credit card entry screen, appears the phrase "Please enter numbers only." I only noticed this after typing in the phone number with a dash after the first three digits and seeing my entry get truncated because the field was at its character limit:

Why on earth can't Symantec, a company who purports to be able to defeat malware attacks and eradicate viruses from your computer, manage to parse a simple dash out of a phone number? This is a prime example of putting work where it doesn't belong-- on the shoulders of the customer. Any web site, whether they are trying to sell products or services or are just trying to get registration and participation, should make it as easy as possible for people to use the site. Parsing dashes from phone numbers and spaces from credit card numbers is so easy, there's absolutely no excuse to make the customer do it for you.

My previous post addressed how to use a client-side script to validate a To:, Cc:, or Bcc: field that may have more than one email address. Since not all people have JavaScript enabled, it's always a good idea to validate on the server as well-- and with multiple emails, you can't just use the function IsValid('email', [field value]) to validate. So, I converted my JavaScript function to ColdFusion code.

I was taught a simple lesson in the power of database indexes today. Here's how it happened: for a while, one of the sites I'm responsible for seemed to become slower and slower over time, even to the point of timing out during a database query. I always figured that it was because the web server was over 5 years old and needed a re-install or something like that. So, I switched to a new server and migrated the database to the new machine, which has more RAM and an has a more modern version of MySQL.

But guess what occurred on the new server when I started testing on it? The site and its database were as slow as ever. At that point I could no longer blame the problem on the machine, so that left... me. I had to figure that code optimization and/or database optimization were the only issues that could be at fault. So, I fired up a browser and looked at the MySQL docs. I knew enough to start investigating indexes to get things working a little faster, so one of the first lines I saw was this:

Use of indexes on the relevant columns is the best way to improve the performance of SELECT operations.

I'm definitely no database administrator, but my suggestion would be to create a two-column index for each join that you perform in your application. One column would contain the primary key of the table that you're indexing, and the other column would be the foreign key in that same table.

For instance, to create an index on a table of users that you join to a table of accounts via a foreign key in the users table, you'd write a MySQL index like so:

CREATE INDEX users_accounts ON users (userID, accountID)

Do this for each of your joins and your database should be nice and speedy for a good, long while.

As a follow-up from my earlier posting on tabbed dialog boxes using ColdFusion 8's new cflayout and cflayoutarea tags, I'll explain how you can also use those same tags to create dialog boxes with expandable/collapsible trees or icon lists in the left-hand pane and forms in the right-hand pane. These kinds of interfaces will be readily recognizable by users since they're almost exactly the same as you'd find in a desktop application.

With ColdFusion 8's new cflayout and cflayoutarea tags, you can now create tabbed dialog boxes like you'd find in any desktop application, complete with Save, Cancel, and Apply buttons. Users will instantly be familar with the interface.

If you're lucky enough to be performing a major site upgrade by switching to a new server, then your migration path is pretty simple: develop on the new server, test until the new application is stable, and then switch over to the new IP address. But if you don't have the luxury of a new server, you're probably going to have some downtime on the site while you upgrade to new code. So what code do you show your users in the meantime?

Since there could always be application-level problems during an upgrade (perhaps you're altering database tables, changing session defaults, or site-wide layouts), you probably want to stick with a static HTML page to show your message. So what I do is create a redirect in the application code, practically in the first few lines, which sends all users to a static HTML page. That page tells the user that the site us undergoing planned maintenance and will be back up shortly. The page also contains a 10-minute refresh back to the application. If you are still upgrading or testing and have the application redirect in place, users will be returned to the static page for another 10 minutes; if you're done upgrading and testing and have removed the application redirect, users will see your new, upgraded application.

Click on the image below if you want to download the full-sized version.

Have you ever gotten into a discussion (or perhaps even an argument) with a colleague or client over the effectiveness of one particular feature of your web application? Goodness knows I have. The good news is that if you can both agree that the end goal is to serve your site's users, then there's a solution: A/B split testing.

There's an art, in my opinion, to validating the information that a user submits in a web form. There are many ways to do it, but few forms do so in a way that is clear for the user and gives them fast feedback, before they submit.

The first thing you should do is use form field labels, descriptive text, and colors to give the user instructions and feedback before they even enter any information. The second is to give them instant feedback via JavaScript when they click on the form's submit button-- before they upload any data. Finally, if the user's entries pass your JavaScript validation and are sent up to the server, you should perform full validation there and, if needed, send their form back to them with clear instructions on how to correct any errors they made. I'll explain each of these steps in detail.

I've been at An Event Apart Boston for the last two days, and I'm excited to say that it was a pretty good conference. To mention just a few of the topics of interest: Eric Meyers' two talks on CSS highlighted some brilliant uses of the latest CSS specifications that Internet Explorer finally supports (as of IE7); Jeffrey Zeldman dispensed some of his worldly advice on how to pick good clients and do good work with them; and Dan Cedarholm explained how the use of microformats will provide people and software with readable content with only one set of code.