The ColdFusion community has been paying attention to IT journalism lately, for better or worse, and for good reason. Our environment is especially in a state of flux; many of us may had been concerned about the future of ColdFusion given Adobe’s acquisition of Macromedia, but those fears were allayed, especially now with Adobe making it so clear that they have invested respectable time and resources into improving ColdFusion with CF8. But the results of the acquisition are only just beginning to emerge. And as Adobe’s strategy becomes clearer, it is very evident that they are putting arguably more resources into other technology like Flash and Flex.

What ultimately prompted my thoughts was the article Web 2.0 Needs Adobe by Tom Yager. His discussion is very flattering for Adobe, although ColdFusion isn’t mentioned anywhere. Neither is it mentioned in Cringley’s equally flattering article An AIR of Invisibility. There’s a reason for this. They’re focusing on the user interface of apps, which is really what defines the perception of how responsive and powerful an app can be. Fretting about ColdFusion getting the back seat is like fretting that your favorite athlete wasn’t nominated for an Oscar; it wasn’t really up for consideration.

So, user interface. Now that’s something to fret about. Many of us don’t like to think about the UI, and that has to change! User interface has always been important when users form their impression of an app, and that high priority is applying more heavily to web apps as they begin to vie for user acceptance with their heavier desktop brethren.

Most ColdFusion developers are using HTML for their user interface. An industry migration will hopefully migrate that median toward AJAX-enhanced HTML or Flex interfaces for web apps, and of course AIR for desktop apps. ColdFusion won’t be going anywhere, as our internet connectivity is always going to need a server-side component.

So how are we to react to these articles’ evaluations of AJAX and Flex? In a way, they are depicting JavaScript (and thus AJAX) as a dinosaur with wings. It is powerful, it got a shot in the arm with the popularity of AJAX, and it can do amazing things. But it’s still a “dinosaur”. It is old technology trying to keep up. Enter Flash and Flex. The new kids on the block. They’re more modern–but they’ve had time to mature–and they just out-perform AJAX in what they can accomplish. Now tack on thoughts about how much AJAX functionality Adobe has put into CF8. What’s the point if AJAX is inferior to Flex? What does it all mean?

It’s a big internet out there. Various scenarios call for various solutions! Whereas it is a good idea for us as ColdFusion application developers to learn Flex and start using it when UI needs call for it, the ultimate point is that we start improving our UIs from plain HTML. Start putting more effort into the user interface. We’ve had it easy in the past when simpler, less sophisticated interfaces were accepted on the web, and that time is coming to an end as the web pushes forward as a viable application platform.

Is it urgent that we start learning Flex? I feel that AJAX and Flex will be sharing the web application space for a long time. Yes, Flex and Flash might be Adobe’s ticket for bringing web apps to the next level, but their commitment to AJAX is very clear. That is evident in the AJAX support in CF8 and AIR. Learn Flex if you can. If it’s just too much for you to handle right now, AJAX is a fine step–more palatable and familiar for HTML developers–that will let you focus on the more important point: Improving your app’s user interface.

I recently used the basic principles in Validation Hints For Your Form by askthecssguy.com for a password management application. I didn't notice any problems on my speedy development machine, but when I pushed the app to some beta testers, I noticed some slower-than-expected performance in IE. As it turns out, the problem was due to the JavaScript that would update an element's class, triggered by the onkeyup event of an input field. It was slow enough to even be disruptive to the experience.

Here is an example of a function that could duplicate the slowdown in IE. It could be attached to the onkeyup event of the username field. It will provide immediate feedback by altering the class name of the field's container when criteria are met (in this case, the value being greater than 7 characters in length). Your CSS and HTML can then determine exactly what that feedback will look like.

As it turns out, the slowdown in IE is due to a general slowdown that IE experiences anytime the class name of the element is changed. It may be unnoticeable if it happens once, but when it happens on every key press, it is noticeable. The slowdown only occurs, however, when the class name is changed, not when the value is referenced. So the easy solution is to compare the existing value to the value you want to set, and only assign the class name if it is different.

You might change the function above to look something like this.

This will theoretically improve performance in all browsers, although it is relatively moot in Firefox, as it doesn't experience the same level of slowdown. But for IE, this tweak in your code will make a noticeable speed improvement.

If my hands are on the keyboard, a new tab is just a Ctrl-T away.

When my hand is on the mouse, a middle-click on a link will open that link in a new tab. Great, very convenient. What about opening a new tab to enter a new URL? I just learned that double-clicking on the blank space in the tab area will open a new blank tab! How convenient is that?

Before, I would right-click on the tab area and click "New Tab". This double-click is much more convenient when your hands aren't already on the keyboard.

In a continuation of the first few steps to improve and expand my website, I have selected, implemented, and partially tweaked a new design that will meet my needs in the future as well as satisfy my desire for the coolness factor.
What was the main motivation for the new site design? Microsoft IE 7. Thanks Microsoft, your new browser completely choked on my old WordPress theme. It's for the better, though, because it moved me to action, and this new design is awesome!

I came this close to dropping WordPress and going with BlogCFC. Not so much out of a dislike for WordPress, but due to discomfort with PHP and WordPress templates in general, compared to thorough knowledge of ColdFusion. Alas, I stuck with WordPress for a few reasons: (a) It forces me to tinker a bit with PHP. It's a good thing. (b) WordPress has a billion themes, and I'm picky at how my site looks. (c) BlogCFC just feels a bit too plain sometimes. This is not an insult to Ray's fine work.

So here I am, with a fine theme called "Scary Little" by The Scary Little Monkey. It features some fun JavaScript effects, a great stylish look, and let's not miss the AJAX-driven search, which is great fun!

I've tweaked it a bit to include my tags (aka categories) in the menu navigation and to make pages (not blog entries, but the CMS pages) fill the whole site width, with no side menu.

Future tweaks I hope to get to: (a) A new header graphic that is flash-driven to incorporate just a tad of stylish animation, perhaps even an occasional image change; (b) Tabs at the top of the header, for moving between the different major website sections (I'll expound in a moment); (c) Either a better editor or tweak the default editor.

The site will be expanding. It is not going to be just a blog. Some ideas I have for expansion (probably about in order of seriousness): (a) A front-end site for my freelance development work; (b) A Trac-driven projects page, to be used with my freelance work; (c) Finally set up my "Land of Nazin" story blog! (d) An Apple Computer history wiki site. Yes, I know there are some out there, but I want to make one that is really nice. After all, I'd enjoy the process of making it since I enjoy reading about it.

Stay tuned!