CFInternals

Adobe, Dreamweaver CS6, And The World's Most Brain Dead Installer

I like Adobe products. Really, I do. Except, of course, when it's Dreamweaver and it starts rewriting my code. But that's a different story.

By and large, I like using them.

But I absolutely hate upgrading and installing a new version. A large part of my ire is drawn by the fact that Adobe will cheerfully install megabytes upon megabytes of new applications, but not once will it offer to clean house and delete the previous version. And supporting files. And help files. And examples.

Heck, the other day I found a batch of CS3 files in my Mac's Application folder.

Of course, when a new Adobe program acts up and starts behaving badly (like rewriting my code), having an earlier version to fall back on is helpful.

But the thing that really gets me, the thing I really hate, is how often the installer fails to transfer my options and preferences from the existing program.

Which brings us to Dreamweaver CS6.

WHICH HAS TO HAVE THE WORLD'S MOST BRAIN DEAD INSTALLER. PERIOD.

Let me explain. Calmly.

You download the new AdobeApplicationManager, so it can download the Adobe Application Manager, so you can install Dreamweaver CS6. It does so, and then offers to launch it for you. I accept.

First thing I noticed was that it managed to pull my site list forward from CS5.5. Cool.

Well, part of the site list anyway. See, this is a ColdFusion site. I, for better or worse, am a ColdFusion developer. And many of the ColdFusion sites I develop for clients are accessed via RDS.

Understand now? I've upgraded from Dreamweaver MX to CS to CS2 to CS3 to CS4 to CS5 to CS5.5 (thanks Adobe), and now to CS6...

AND NOT ONCE HAS DREAMWEAVER MANAGED TO TRANSFER RDS SETTINGS.

I have dozens upon dozens of sites, and because of this stupidity I have to manually go through each and every one and reenter the RDS site path, and directory path, and username and password. 

Fortunately, Adobe didn't delete the earlier version... (sigh).

RDS is an Adobe protocol that enables an Adobe product like Dreamweaver to communicate with another Adobe product like ColdFusion. So why in the hell can it not transfer RDS settings from an earlier version?

I asked an Adobe manager this about thee versions ago, and was told with a straight face that it was because RDS was a "plug-in". Apparently, moving FTP or SFTP or WebDAV settings -- which aren't Adobe protocols -- isn't a problem, but moving settings for their own protocol is a problem.

Because it's a plug-in. Right.

Fine. 

But does it transfer my font preferences? No.

Does it transfer my code hilighting preferences? No.

Does it transfer my layout preferences? No.

Does it transfer my toolbar settings? No.

And no. And no. And no. Guess those were "plug-ins" too.

What's worse is that this is probably a day or two's worth of coding for an Adobe engineer. Call it 16 hours. But every single person who uses the product has to spend their own time reentering settings and reconfiguring preferences.

Thousands of man-hours lost.

Like I said earlier, for the most part, I like using Adobe products.

But upgrading? Adobe, man, you're killing me.

Contact Forms: Why Wanting Too Much Can Lead To Nothing At All

I just came across an article by MaoStudios regarding contact forms and web site usability.

In it they advocate using web-based contact forms as opposed to email links.

While I agree with the approach, and with their comments, there's one more thing I think you should consider before implementing such a thing on your own site.

Keep it short and sweet.

Too many times marketing, sales, or someone will start adding fields; requiring names, addresses, phone numbers, email address, products or versions owned, Os versions, subject, topic, category, age, DOB, and/or the user's pet's name.  And a capcha of course. All usually under the guise of "getting some information up front."

Resist. Because all that you're doing is throwing roadblocks up in front of your users. Be honest. How many times have you visited a site and wanted to ask a question or leave a quick note or suggestion about some site or product feature, only to be faced with the monster contact form from hell?

Faced with filling out a visually complex form with dozens of fields or leaving, you leave. 

Customer contact aborted.

Now, I actually know one or two companies that do this on purpose. They don't WANT to talk to customers, thinking that they have better things to do with their time, and that answering customer questions and email is an expensive waste of time.

But compare this to a place I do work for now that views each customer contact as a opportunity to learn what's happening, what's working, what's not, and what can be done to fix it. Oddly enough, that particular business is thriving, with a steadily expanding and extremely loyal customer base. And according to the numbers, about 40% of those contacts go on to buy more products, many on the spot.

Which would you rather be?

Put a subject dropdown there to make it easy to forward to the right person (feature, bug, request, problem, etc.). Put a text box there for the question. Add an OPTIONAL email address for a response, if needed. And a big button that says "SEND".

That's it. That's all you need.

Sometimes the business wonks will say "Okay, I see your point. Let's make the extra fields optional." Resist that as well, because even optional fields will make a filling out a simple contact form seem like a hassle. 

For an example, check out their contact form, and then you tell me. Would YOU take the time to drop them a line or ask a quick question? Would you take the time to parse the form and figure out that you only need to fill in five fields out of the 12 presented?

Or would you just jump to the next site in the Google search to see if they're easier to deal with?

Make contacting your company easy. Your customers will thank you for it, and if I ever visit your site, I'll do the same.

Dreamweaver CS5.5 Rewrites Code - AGAIN!!!

I CAN NOT ****ING BELIEVE IT.

I just upgraded from Dreamweaver CS5 to CS5.5, as I needed to cross-grade to the Design Suite in order to get InDesign.

Everything was going swimmingly, until I ran across the following. Take a look at the following code fragment:

<input type="text" name="getEmailAddress()" size="40" required="1" validate="email" message="Please enter your email address." />

Thing is, this is NOT HTML. This is part of an XML definition of a form, embedded within a CFC. Whenever CS5.5 gets its grubby little paws on it, however it changes it to this:

<input type="text" name="getEmailAddress()" size="40" required validate="email" message="Please enter your email address." />

Note the required="1" attribute is now simply required. Which blows up the XML parser big time.

This, just when I was getting around to writing a post about how, after THREE versions (CS3, CS4, CS5), Adobe finally got around to fixing the code rewriting bug I originally posted back in March, 2008.

I've tried changing doctypes, turned off rewriting in preferences, and done pretty much eveything I could think of, AND DREAMWEAVER STILL REWRITES MY CODE!

Look, Adobe, I'm a professional. I know what I'm doing, and when I put text to a file, I expect it to remain exactly as written. I do NOT need you "improving" my code.

Especially when "improving" my code BREAKS MY CODE.

Please provide a "hands off" option, and HONOR it.

I wonder how many years I'm going to have to wait to get THIS fixed...

UPDATE: It appears that Dreamweaver will perform these kinds of changes based on the presence of a doctype specification... But why is doing it in a CFC?????? Am I supposed to add doctype's to my CFC's now?

Dreamweaver CS3 Rewrites Code!

Yes, you read it correctly, Dreamweaver CS3 is rewriting my code. I'll go to save a file and upload it to my web site, only to get strange ColdFusion errors about unbalanced tags. I finally determined that if I close and reopen the file, I'll see the changes.

Fix the file, save, and re-upload, and the errors reappear. Needless to say, this is extremely frustrating, as you can never tell when deploying a set of changes to a site will work or not.

I've included a YouTube video after the break that shows the entire process.

Load-Balancing, High-Availability, and Sessions

Mike Brunt just posted the latest in a series of articles about high-availability web site architecture, with the conclusion that "the most effective Load Balancing in a Cluster is Round-Robin with Sticky-Sessions, if it is necessary to preserve state in a single user session."

The later portion of which would seem to be an interesting qualification.

After all, why would someone use memory-based sessions in an application meant to reside in a high-availability environment?

Answering Objections to Rich Internet Applications (Flash)

Anthony Franco has a nice article pointing out common objections to building Flash applications and the rebuttals one might use in answering them.

Some of which—unfortunately—I found to be unconvincing. For example, the ultimate answers to several of the issues (SEOs and accessibility) is simply to build two sites. Or "dual web experiences", as he calls them.

Somehow I don't see "use Flash and do twice the work" as a major selling point.

A Spaces Workflow in Leopard

The iSights blog has a nice article on using OS X Leopard's Spaces feature in an development environment. While the article focuses on Spaces, the same concepts could be used in any environment that supports multiple virtual desktops.

Fundamentally, the main tactic comes down to collocating spaces so that related applications are in related spaces. In his example, he puts Dreamweaver up in one space, with the assorted Safari and Firefox browser windows needed for testing directly beneath in the space below. This allows single control-key transitions between the development environment and the browser test environment.

It also allows one to maximize the layout of each, without having to worry about tiling or overlaying windows so that you can easily switch between them. To quote, this "lets me get the maximum use out of screen hogging applications like Dreamweaver, Photoshop, and Aperture."

Worth a read.

How to install ColdFusion 8 on Leopard (OSX)

The guys over at daemonite have written detailed instructions for those of you who absolutely have to have ColdFusion 8 running directly under OS X Leopard.

Unlike the instructions posted earlier by Mark Drew (which apparently have worked for some and not for others), this installation is not for the faint of heart.

The standard ColdFusion installer for OSX has no web connector for Apache 2.2, so you're going to have to compile your own using the XCode tools found on the OS X DVD.

ColdFusion / Leopard Compatibility Issues

Reports are coming in that ColdFusion 8 can't communicate with the latest version of Apache on Leopard. No fix or word from Adobe as to if or when a hotfix might be available.

Worse, it appears that ADC (Apple Developer Connection) developers who have been getting Leopard seeds prior to its release have known about the problem since August.

Multiple Layout Specifications in CS3

SitePoint just released an article discussing the multiple layout specifications that the W3C is recommending that web browser vendors implement.

My position? The W3C is nuts.

A new direction for ColdFusion?

Ryan Stewart comes back from MAX with an article discussing ColdFusion's future. In particular, he talks about how ColdFusion now falls under the Platform Business Unit, which puts it in the same organizational unit at Adobe as Flex, Flash Player and AIR.

One of the key results, he explains, is that now ColdFusion should have an "even closer integration with Adobe’s products." But is that really such a good thing? Ryan obviously seems to believe so, but I'm not so sure. Here's why.

Mobile Web Design

Cameron Moll has a great little ebook available on Mobile Web Design, a web standards approach for delivering content beyond the desktop.

This announcement comes right on the heels of Apple introducing the new iPod Touch, a video iPod styled on the iPhone touch-screen interface. Notable is the fact that it, like the iPhone, also has built-in WiFi and includes their mobile Safari browser.

In addition, Apple dropped the price of the 8GB iPhone to $399, so combined with the Touch and new phones coming from Nokia and LG the number of sophisticated mobile devices out there is only bound to increase. Is your site ready for them?

A free sample chapter is available, and to sweeten the deal Cameron is also giving away a free iPhone to a lucky buyer, but only if you order by September 14th. Mobile Web Design is a 104-page ebook and sells for $19. Recommended.

Model-Glue, Events... and Global Variables???

So there I was, sitting back and reading Doug Boude's recent post on The Model-Glue Event Lifecycle in Layman's Terms. Good article, I thought. Nice descriptions. Then one paragraph jumped out at me and I had a sudden realization: OMG, we've regressed back in time.

The good, the bad, and the different - iPhone edition

Aaron over on WebStandards.org is advocating that web sites NOT design specifically for the iPhone, but for all mobile devices. While cogent, I think his arguments are missing a critical element.

iPhone Development Resources

Apple has added some good iPhone development resources to their site, including a great guide to Optimizing Web Applications and Content for iPhone.