This is a bit off topic for this blog, but this is one of the coolest things I’ve seen that’s real.

Remember Minority Report with its holographic computer interface? The technology is called multi-touch, and it’s been around in labs for a while now. In fact, you’ll see it in the new iPhone later this summer. The concept is simple: you use multiple touch points to interact with a digital “object” in real time. You grab, pinch, turn, spin, and otherwise manipulate objects as you would in the real world. Very cool, very intuitive stuff.

Microsoft has a working coffee table-sized prototype of what they’re calling the Surface Computing Platform, and it’s packed with gee-wiz coolness. (Interestingly, there wasn’t a hint of a Windows interface. I’m sure they’ll mess the UI up at some point with a start menu of some kind (they just can’t help themselves), but for the moment, watching this thing in action is nothing short of sublime.)

Check the video out at the Popular Mechanics site. [link]

Microsoft has launched a website for its Surface Computing initiative. [link]

Holy cats, this is useful. This cheat sheet distills the various mod_rewrite rules and syntax into easily digestible chunks. Many, many thanks to Dave Child of ILoveJackDaniels.com for putting this together.

mod_rewrite Cheat Sheet [link][eop]

Don’t you just love the insecure content warning you see all the time in Internet Explorer? Clearly, the engineers at Microsoft were looking out for our best interests when they decided to throw a warning each and every time an image or JavaScript file happened to be linked from the non-SSL side of your site.

If you’ve implemented Google Analytics, you may have run into this problem. By linking to the urchin.js file from an otherwise secure page, you can trigger the insecure content warning in IE. Yea!

The solution is quite simple. In your PHP head section, first look to see if the $_SERVER['HTTPS'] value is set and has a value of “on.” Then set a value that contains the path to the secure version of the urchin.js file as follows:

if(isset($_SERVER['HTTPS']) && ($_SERVER['HTTPS']==’on’))
{  $gaSrc = ‘https://ssl.google-analytics.com/urchin.js’;
} else {
  $gaSrc = ‘http://www.google-analytics.com/urchin.js’;
}

Bonus tip: by placing this in the head section, you can also set an absolute path to your images directory or any other dependent paths, helping further eliminate the possibility of triggering IE’s insecure content warning.

In the footer of any PHP page that links to Google Ananalytics, simply echo the $gaSrc variable set above as follows:

<script src=”<?php echo $gaSrc; ?>” type=”text/javascript”></script>

<script type=”text/javascript”>
_uacct = “[YOUR ACCOUNT NUM]“;
urchinTracker();</script>

Be sure to replace “[YOUR ACCOUNT NUM]” with your Google Analytics tracking number. That’s it!

At $99 retail, the Logitech MX Revolution is a daunting purchase. I mean, can a mouse really be worth that much money? In a word, yes.

Amazon is selling the MX Revolution for $73.24 as of this writing. [link]

The special sauce for this puppy is the magic scroll wheel that is more like a flywheel than a typical scroll wheel. Give the thing a spin and it just keeps on scrolling smoothly down the page gradually coming to a stop. The sensation is sublime, and it is one of those features you wonder how you ever lived without once you see it in action. For coders, this makes fast work out of jumping around a long page, especially if you’re upgrading from Apple’s standard (or Mighty) mouse.

Clicking the scroll wheel puts the wheel into a standard ratchet mode that is more like scroll mice I’ve used in the past. I personally don’t see a need to revert to this standard mode, but I suppose some may appreciate its presence.

In addition to the scroll wheel, there are a host of other mappable buttons that make quick work out of page navigation or, in my case, clipboard management. There’s an innovative thumb wheel that is mapped to the application switcher (Cmd+Tab or Alt+Tab) by default. I’ve switched mine to toggle between open windows within an app, which I find to be far more useful.

If there’s a knock on the mouse (besides its steep price tag), it’s the fact that the USB fob seems to loose sync occasionally upon wakeup from sleep. Unplugging the fob (mine is in my keyboard’s USB slot) and reattaching fixes the problem, but it’s still something that you shouldn’t have to do for a premium product like this.

As mice go, this one is by far the best I’ve used. If you’re a Mac user, this is a must-have upgrade over the standard mouse. If you’re a Windows user, you’re probably used to third party peripherals already. Even still, this mouse is well worth the money.

In September, 2006, Adobe acquired InterAKT, a small company that wrote extensions for Dreamweaver and Flex. Among these extensions was the Dreamweaver Developer Toolbox, an extensive set of class-driven wizards that added sorely needed features to Dreamweaver such as advanced form creation and query builders that all worked within the Dreamweaver framework.

A free 30-day trial of the Toolkit is available here.

At $299, Adobe is asking a lot for these tools. As a point of reference, Dreamweaver itself is $399 at full retail. Does the Toolbox deliver 3/4 of the functionality of its parent app? Not even close. Adobe has tried to address many of the deficiencies in Dreamweaver with this Toolbox, but I believe strongly that these features should be addressed as part of an already expensive app, not as a $299 add-on.

Setting my philosophical problems with Adobe’s pricing decision aside, I have spent the past two weeks playing with them and evaluating their applicability to my development environment. In short, it’s a no-go. My strong recommendation is to save your money.

This recommendation is based on several factors, some of which are specific to my development environment, and some of which I believe will be commonly experienced by all developers.

To understand where the Toolbox is fatally flawed, it is worth exploring what, exactly, the Toolbox does. The Toolbox is actually a set of Server Behaviors that extend the set of canned behaviors included in DW. For instance, the toolbox offers a handy way to create an advanced set of registration features, complete with confirmation emails, etc. These are all wizard driven and derive their functionality from a set of classes and function libraries that are included as a set of files automatically by DW.

Therein lies the fatal flaw. Like Dreamweaver, the Toolbox assumes that your local root folder specified in your Site settings is actually the public web root. Internal links to the libraries are relative and extensive and automated, meaning you can’t simply move the included files to your public web root without breaking all of the canned functionality.

To make matters worse, the wizard-driven interface was, in my experience, fatally buggy and inconsistent. More times than not, the Toolkit could not make a connection to my database giving me the infamous “Testing Database Connection” dialog. Apparently, the Toolkit caches some value somewhere deep within its Wizard’s bowels and won’t let go. I could find no rhyme or reason for this problem, but it persisted and happened in enough Wizards and situations that it made me believe that this was a global problem, not an isolated issue.

It’s a shame. There’s so much potential there. InterAKT valiantly tried to address Dreamweaver’s shortcomings with an extensive set of behaviors. Some were truly useful and I could see myself using them. But in the end, there is no way I am paying $299 Adobe for a buggy, semi-functional set of server behaviors. Being the eternal optimist, perhaps they’ll fix these problems and integrate the Toolkit directly into Dreamweaver next go-round. We’ll see.

Related stories:

• Review: Dreamweaver CS3: What a Disappointment
• An Open Letter to Adobe

Dear Adobe,

I beg of you, don’t let Dreamweaver go the way of GoLive. With each subsequent release leading up to its death, you added more and more design-centric features to GoLive until it basically became an exporter for InDesign. Yes, designers need tools too, but they have them already; they’re called web developers. And web developers need an advanced development environment in which to bring modern web sites to life. With your acquisition of Macromedia, you have a responsibility to the web development community to support and extend the only viable development tool left in the marketplace.

With your latest release of Dreamweaver CS3, I am seeing ominous signs that your bias towards web design rather than web development is unchanged. For starters, DW CS3 has hardly changed at all from its Studio8 predecessor. What few new features that were added pay little more than PR lip service to the so-called Web 2.0 movement with anemic support for AJAX, an non-existent support for framework based sites.

With CS3, you had an opportunity to provide a next-gen IDE that would support the creation of Web 3.0, not Web 1.5. So, I write this open letter at this early stage in the sincere hope that the feature set you choose for Dreamweaver CS4–or even a CS3 service pack–will realize this dream. With this in mind, I offer the following ten suggestions for sorely needed features and updates.

1. Framework Support
   Modern web sites are built upon frameworks like Ruby on Rails, Cake, or custom solutions. These frameworks utilize non-linear structures like MVC and templates. The IDE should be smart enough to see the page as PHP and Apache (or other language/server combos) do. This means following required and included pages, recognizing variables, functions and classes (see next), and, most importantly, rendering the pages accurately in design view (see next).
2. Accurate Page Rendering and Design View

   I gave up back in the MX days being able to use Design View to predict what my dynamic pages will look like in the various browsers. For all but the most simple of pages, elements break apart and are pushed all over the screen even on CSS validated pages. And if you have dynamic content, template-driven, or framework-based pages (see #1 above), the feature is useless. It’s time for a serious overhaul of this system. Design view needs to see the page as the web server sees it, including required files and libraries, and drawing the page accurately and using dummy content where applicable. In fact, why not integrate an emulated LAMP server right in the app?

3. More Flexible Server Behaviors
   While the built-in PHP, etc. functionality is great, working with it can be difficult, especially if you are using a custom framework. One small example, the GetSQLValueString() function is ubiquitous, and the first thing I do with every site is move this function to a core library. As part of better framework support (see #1 above), DW should recognize included files and spare me from having to delete volumes of redundant code every time I add a server behavior to a page. It should also recognize that my Connections file is included in my main settings file, or, better yet, let me specify the required connection file replacing the standard “../Connections/mysite.php” file with “../lib/settings.php” in a site preference.
4. Persistent Development Environment States
   For dynamic sites requiring log-ins, rendering a dynamic page in Design View can’t be accomplished. Yes, you can specify a GET variable on a per-page basis, but even your own canned log-in functionality isn’t GET-based, nor should it be for security reasons. Being able to log in once and set a cookie–or something equivalent to that–on a per-site basis would facilitate more robust and secure testing and page previews. Better still, provide the means to define a set of login states and dummy users on a persistent, site-wide basis. These would be selectable in Design View or preview mode.
5. Included Function and Class Recognition
   Every modern site relies upon a core set of libraries that contain custom classes and functions, not only for PHP, etc., but also for JavaScript. Dreamweaver needs to see these included files reliably and consistently and provide code coloring, tool-tips, and auto-complete capabilities just as it does for built-in or native language functions.
6. Integrated SVN and CVS Version Control Support
   It is inexcusable that Dreamweaver does not have built-in client support for Subversion and CVS. No self-respecting developer builds a site without version control, and integrating them directly into the IDE seems a logical feature.
7. Much Better Snippet Support
   Snippets are great, but the feature is unchanged since MX. The ability to assign snippets to hotkeys and buttons would be incredibly helpful. If you want to go even further, look at QuickSilver and TextExpander on the Mac for ultra-efficient ways to support Snippet use.
8. Visual Query Builder
   Like the Snippets feature, the MySQL query builder has remained unchanged since MX. A visual query builder that allows dragging & dropping of tables & fields and the creation of complex joins, order-bys, and group-bys is long overdue. Microsoft Access has had this feature literally since version 2.0 back in the early 90’s, and to this day, I fire up Access in Parallels to build complex queries. Building queries efficiently and reliably is a core task that is performed dozens of times every day when developing a site. Features aimed at better supporting this task are sorely needed in Dreamweaver.
9. Native Support for Ruby
   Add Ruby to your set of supported languages and integrated server behaviors.
10. Overhaul the Interface and Add Workflow Efficiencies
    As with Photoshop CS3’s interface overhaul, Dreamweaver could benefit from a serious overhaul of its interface that take into consideration widespread use of wide-screen and multiple-monitor development environments (for example, splitting the screen vertically instead of horizontally in Split view). In addition, tweak existing features to improve workflow efficiencies with improvements such as the ability to Sync open documents, cloak individual files, code collapsing integrated into the document save/undo structure, and improved searching (including file-level searches).

I believe I speak for many others in the web development community when I ask that you consider these features carefully and reverse the trend apparent in the release of CS3 towards designer-centric web development at the expense of those of us who actually bring the next generation of sites to life.

Regards,
Steve Stringer
Principal - Stringer Sites, LLC

Adobe Certified Expert (ACE)

Related stories:

• Review: Dreamweaver CS3: What a Disappointment
• Review: Dreamweaver Developer Toolkit: Good Idea, Poor Execution

Google Analytics is a free service that provides an amazing window into your site’s performance, and is a must-have tool for your clients’ sites. To get this level of analysis previously, you would have had to build your own custom solution or pay literally thousands of dollars for a hosted tracking service. GA now provides this analysis for free, and, in addition, ties closely into your AdSense campaigns. This is definitely worth checking out. [eop]

I had planned on writing a lengthy, in-depth review of CS3. Unfortunately, there’s not much to write about. I’m sincerely disappointed to report that Dreamweaver CS3 is virtually identical to its Studio8 predecessor. Shockingly so, in fact.

A visual query builder? Framework support? Native Ruby support? Improved FTP performance? I could list about 10 more sorely-needed updates, all of which remain unchanged in CS3. And by unchanged, I mean literally unchanged; same dialogs, same icons, same UI…even the same bugs (plus a few new whoppers). Dreamweaver appears to be the green-headed bastard stepchild of the CS3 family, and suffers from neglect and lack of development. I can say that my worst fears about the Adobe Macromedia merger have come true, and I was even on Adobe’s side when the merger happened!

DW CS3 boasts very moderate performance gains with the Universal binary update. These gains are most noticeable when closing the application, but are otherwise undetectable in day to day use (I’m running on a Quad Xeon Mac Pro). Given this, I’m wondering if Dreamweaver is, itself, emulating some underlying ancient codebase. Regardless, if you’re hoping for speed increases with DW CS3, you’ll be disappointed.

Adobe promotes the Spry framework as one of the major new features. The reality is that the included Spry widgets–all four of them–pale in comparison to those offered over at Script.aculo.us, and the Spry AJAX framework may be useful in limited applications, but by Adobe’s own admission in their documentation, the Spry AJAX framework is not intended to support commercial-grade applications, just bootstrap implementations or one-off widgets.

On the cross-application support front, being able to paste Photoshop docs directly into my pages may be nice in theory, but I seriously doubt it’s something I’ll ever have a need to use. Device Central is a true missed opportunity. DC is a stand-alone application that supposedly lets you preview your web content on a wide variety of emulated phones and mobile devices. The catch is that “web content” is limited to FlashLite content or static graphic files, not web pages. This makes me seriously question why this app exists except to push Flash for mobile devices.

Finally, Dreamweaver CS3 is surprisingly buggy given how little of it changed in the year-and-a-half since Studio 8 was released. So far, I’ve had serious problems syncing sites (see a separate post on this issue), and there are about half-a-dozen UI quirks (I’m putting it nicely) that I’ve encountered so far. The app appears to have taken a step back in many significant ways.

When Adobe purchased Macromedia, the general FUD flowing through The Tubes was that the Macromedia apps would wither on the vine or be killed outright. In particular, would they carry the mantle and keep Dreamweaver on the cutting edge of web development? “No, no,” Adobe assured us in its press releases, “we’d never do that.” Well, it would appear that these fears have come true. Dreamweaver has not been appreciably advanced and has clearly been neglected as other front-line apps like Photoshop and Illustrator got the lion’s share of resources, feature improvement, and testing. What a disappointment.

So here it is:

• Studio8 owners, save your money. For the most part, you’re not missing a thing.
• If you’re considering upgrading from CS2/Stuido8 to CS3, weigh your needs carefully. Photoshop is a worthy update on the Mac. Other CS3 apps, less so. Certainly don’t upgrade for Dreamweaver’s sake.
• If you’re new to the Creative Suite, then I’d recommend waiting until the first patch is out. Then visit your local bank for that home equity loan it will take to afford a full license to CS3.
• No matter who you are, don’t hope for much in the way of improvement and you won’t be sorely disappointed.

Related stories:

• An Open Letter to Adobe
• Review: Dreamweaver Developer Toolkit: Good Idea, Poor Execution