As I began debating whether to make the move, I got pretty sentimental about the last 15 years – so much so, that I almost chose not to go. Thanks to GoLive/Macromedia/Adobe, I’ve gotten to help build tools that literally have changed the (web) world. I’ve also had the good fortune to travel around the world more times than I can count and accumulated frequent flyer miles and hotel points that will take years to use up. And along the way, I also got to meet and work with some truly amazing people, including my incredible wife, Stephanie Rewis. I want to thank you all – my colleagues, friends, travel buddies, conference attendees, et. al. – for so many great memories. Chili crab in Singapore, tuk-tuk rides in Dehli, climbing the Sydney Harbor Bridge, dinner at Carnivores in Johannesburg, standing naked in a hotel hallway in Seoul (don’t ask), horizontal rain/ice in Helsinki in February(buuurrrr!), far too many beers at the Oktoberfest, sitting in the MacWorld green room with Steve Jobs, getting to fly with Paul McCartney – and so many, many more!

It’s been an amazing ride and I would be lying if I said that I won’t miss parts of it (expense reports excluded). I hope to still be asked to speak at conferences (hint, hint), and I will definitely be writing here and twittering there – it’ll just be less Dreamweaver and Adobe stuff, and more HTML5/CSS3/JS – and you’re all still invited to come hang out on Geeks4Sail. But, I’m also excitedly looking forward to the new challenges that come with change – and even better, I get to carpool to work with Stef (our offices are literally one mile apart)!

So, to my soon-to-be former colleagues at Adobe, I wish you all the best! Keep making great products! And to the rest of my readers, I’m not leaving you, so… um… carry on with what you were doing!

*Hat-tip to Leslie Jensen-Inman for the title of this post

As always, here’s the disclaimer – you’re going to be editing files in Dreamweaver’s Configuration folder, so proceed with caution, make a backup of the originals, etc.

The first thing that we need to do is to tell Dreamweaver that it’s okay to open a .scss or .less file – something that Dreamweaver by default doesn’t understand. You’ll first need to take a peak in your personal Dreamweaver configuration folder – on a Mac, that’s located in ~username/Library/Application Support/Adobe/Dreamweaver CS5.5/en_us/Configuration – and locate a file named “Extensions.txt”. If, for some reason, this file doesn’t exist, you can edit the master file located in Adobe Dreamweaver CS5.5/Configuration. Open the file and add SCSS (or SASS if you’re using the older syntax) and LESS to line 8, so that it reads: CSS,SCSS,LESS:Style Sheets. Save the file and restart Dreamweaver. You should now be able to click on a .scss or .less file in your Site panel and have it open in Dreamweaver.

Now, in order for Dreamweaver to understand that this, in fact, is a CSS file, you’ll need to edit MMDocumentTypes.xml located in the DocumentTypes folder in the Configuration folder. Open this file and scroll down to line 142. You’ll notice two properties on that line: winfileextension=”css” macfileextension=”css”. Add scss and less (comma seperated) to the appropriate property for your platform. Save the file and restart Dreamweaver. Open your .scss or .less file and you should see your familiar CSS code coloring and hinting!

If you’re serious about your Sass and/or Less, you should be using CodeKit, IMHO. CodeKit, in addition to other things, monitors your scss (or less) file for changes and then compiles it into CSS. I’m using CodeKit and Sass on every project – and loving it! To optimize my workflow, I actually link to the .scss file in my HTML (just remember to remove it before pushing the page live). That way, I can use Dreamweaver’s split view to edit the .scss file while looking at the page with Live View turned on. When I save the .scss file, CodeKit compiles the file into a CSS file that is also linked in my page. Sadly, Dreamweaver doesn’t know when the CSS file is changed, but simply hitting F5 (or the refresh button at the top of the document window) causes Dreamweaver’s Live View to refresh and I can see my changes.

When you’re ready to validate your page, simply click the W3C Validator button and choose whether you want the local page on your computer validated or a page on a server.

If you have any errors, they will appear in the W3C Validation panel. Simply double click each error to be taken directly to the culprit in Code View. You can also choose to save the report if you’re into that sort of thing.

But very often during development, the list of errors can be quite extensive – and even irrelevant. For example, I don’t bother to put alt text (or even an empty alt attribute) on placeholder images that aren’t actually going to be used in the final page. For that reason, Dreamweaver also allows you to suppress errors from a report. Right click on the desired error and choose Hide Error to add it to your list of suppressed errors.

Of course, you’ll want to make sure you’ve actually fixed those errors before going live. Therefore, Dreamweaver CS5.5 allows you to remove errors from the list of Hidden Errors by choosing Settings from the W3C Validator button and clicking the Manage button.

Actually, one of the best features of Dreamweaver, Live View, can be used in a way that you might not have thought of. We know that Live View allows us to see the page, rendered by the embedded Webkit engine, exactly as it would appear in Webkit-based browsers. But there is also an interesting text field that becomes active in Live View at the top of the document window – an address field – just like in a browser!

And yes, you can type any URL into the field. Dreamweaver, just like the browser, will load the page in Live View. If you are in Split View mode, you might notice that the actual HTML from the page you are viewing is not there because Dreamweaver is still showing the code of your original page.

But click the Live Code button, and Dreamweaver will display the generated source of the page you are looking at — complete with all the corresponding CSS and Javascript files appearing in the related files bar. It’s a great way to learn from what others are doing.

To get the most out of this feature, I have simply created a “tools page” with links to all of my favorite online tools. In order to interact with your local tools page, you will need to choose “Follow Link” or, even better, “Follow Links Continuously” from the Live View Options menu.

So now, when I start Dreamweaver, I immediately open this page, turn on Live View, enable the Follow Links Continuously option and then go about working on my projects. Any time that I need a gradient, transition or anything more complex that I don’t want to “think about” how to create, I switch to my “tools page” tab where all my online friends are ready to help. I can then easily copy their code into the stylesheet that I am working on.

Let me know what you think about this – or if you have an even better “Best Tip Ever”!

The Dreamweaver team has released instructions which you can find here: http://kb2.adobe.com/cps/904/cpsid_90408.html

Basically, you’ll need to replace the NativeAppCommon.js file located at [Dreamweaver Install Location]/Configuration/NativeAppFramework/. The entire process takes less than a minute to complete.

If you have already installed the Android Framework, you don’t “have” to do this, however you might want to go ahead and grab the updated file just in case you ever want to reinstall the framework with Dreamweaver’s Easy Install.

Before proceeding, you’ll obviously want to go grab the updated libraries themselves. For the core jQuery library, I suggest using the minified version. Because images are also part of jQuery Mobile, I recommend grabbing the zipped version of the framework. After you download and unzip the folder, you’ll find a full version of the css and js files. I recommend using the minified versions, so go ahead and delete the full versions of the files (ie, they don’t have “.min” in their names).

Arguably one of the most powerful features of Dreamweaver is its extensibility. In fact, the application itself is built around the very technologies that it itself writes, namely HTML, CSS and Javascript. All of these pieces are located in the Configuration folder that you can find where Dreamweaver is installed on your computer. For me, since I’m a Mac user, it’s at Applications>Adobe Dreamweaver CS5.5>Configuration. There are tons of other folders in the Configuration folder, but the one that holds the files that we are interested in is the Third Party Source Code folder.

Inside this folder, you’ll find the jquery-mobile folder. If you want to backup the folder, feel free. None of the sites that you have worked on previously are reliant on these files, as Dreamweaver makes a local copy in each site you create (if you are not using the CDN versions of the Mobile Starter Pages – which we will talk about later). Replace the two jquery-mobile files (css and js) with your newly downloaded files. Replace the entire images folder as well. Finally, replace the jquery-1.5.min.js file with your jquery-1.6.1.min.js file (or whatever you named it).

One last step and your update is complete. When you choose to create a new file from the New Document dialog, Dreamweaver makes a copy of the selected file from the Configuration folder and places it in your site file. The Mobile Starter layouts (New Document > Page from Sample > Mobile Starters) are located in Configuration > BuiltIn > Mobile Starters. There are 3 pages – two of which reference the files that you have now deleted, jQueryMobileLocalMultiPage.htm and jQueryMobilePhoneGapMultiPage.htm.

Open each of these files in Dreamweaver. You’ll see in the head of the document links to the two old jQuery Javascript files and the old CSS file. Simply update these links to point to your new files and save the document. Test that everything worked properly by closing the file, then creating a new page from the Sample that you just changed. Make sure to save the file into a site to make sure that Dreamweaver copies the proper files into the site.

Finally, if you want to change the CDN version, it points to the jquery repository online, simply update jQueryMobileMultiPage.htm to point to the location of the CDN versions of the files.

Happy mobile coding!

HTML5 / CSS3

For those that missed it, shortly after the release of Dreamweaver CS5, the team released an update on Adobe Labs which provided initial code-hinting support for HTML5 and CSS3. This was later baked into an update to the core product. With Dreamweaver CS5.5, the team has updated the code-hinting database to reflect the current state of the HTML5 elements, as well as updating the WebKit browser engine embedded into Dreamweaver’s Live View. This means that things like native HTML5 video can be “seen”, but also interacted with while you are designing your page.

For the CSS3 aficionados, you might remember that the HTML5/CSS3 update last year added support for vendor-specific prefixes. This meant that you could type a dash, and Dreamweaver would codehint “-moz-”, “-o-” and “-webkit”-”. Choosing one of the vendor-specific prefixes would then in turn display a list the list of CSS properties that that specific prefix could be used with. Dreamweaver CS5.5 not only continues this functionality, a fourth vendor-specific prefix has been added, “-ms-”, because now Internet Explorer 9 has adopted its own prefix.

Additionally, the CSS Panel has been updated with a couple of very nice enhancements. First, the dropdown list now includes all of the new CSS3 properties and any vendor-specific properties that you may have added to your rule show up in the assigned properties list for easy editing. Second, new fly-out dialogs have been added to allow you to quickly specify values for box shadow, text shadow and border radius. Finally, the color picker has been updated to support the RGBa and HSLa color spaces — and even translate between hexadecimal values and these new color spaces.

The Multiscreen Preview which was added with the HTML5 update, has also been improved and now eases the process of creating media queries and their attached stylesheet files. But taking the idea one step further, the Window Size manager (a long forgotten Dreamweaver feature) now includes the ability to change the Design View and Live View to reflect only the desired stylesheet. Yes, this means that you can continue to work, modifying HTML, CSS and Javascript, while looking at the way the page will actually look under various scenarios! If you are serious about targeting multiple screen sizes/dimensions with CSS, this feature will have you cheering!

jQuery Mobile

And if you are into targeting mobile devices, the jQuery Mobile framework helps ease the process of creating mobile-optimized pages that actually “feel” like a native application. As a proud sponsor of the jQuery Mobile project, the Dreamweaver team has been actively contributing back to the framework. And Dreamweaver is all the better for it, as Dreamweaver CS5.5 adds a jQuery Mobile widget section to the Insert Panel, allowing you to easily add UI widgets from the framework to your page — and getting started is just as easy with the new jQuery Mobile starter layout. Use the Window Size manager to set your Design/Live View to the size of a mobile phone and it’s as if you are almost working on the phone itself.

And speaking of jQuery in general, Dreamweaver CS5.5 builds upon the enhanced Javascript code-hinting introduced in the previous version by providing intelligent code-hinting for the full jQuery framework.

Phonegap

Having spent the last six or so months attending conferences featuring talks about native application development with HTML/CSS/JS, I can personally attest to the popularity of the Phonegap framework. This simple, yet powerful, framework is there to solve one simple problem, the actual packaging of your HTML, CSS and Javascript into a native application for iOS and Android devices. And Dreamweaver CS5.5 includes built-in access to the framework — meaning, once you have your application looking and functioning like you want, a simple command in Dreamweaver can pass the entire “site” off to the Phonegap framework, packaging it up for deployment, or, if you’re in the middle of development, you can interact with your application using the iOS or Android simulators included in the respective platforms’ SDK.

Read more, see more

I have to admit that I’ve been looking forward to finally being able to show this wickedly evolved version of Dreamweaver off in public! And, that’s what I will be doing quite a lot over the coming months. Together with my good friends and colleagues, Terry White, Jason Levine and Paul Trani, I will be on tour around the world throughout the rest of April, May and June. You can see dates in the right hand column of this blog — or, read more about the tour and get registered on our Creative Suite Evolution Tour page. If you can’t make it to one of our tour stops, I’ve also recorded a series of videos showing off all the shiny new features.

Of course, this release is not just about Dreamweaver — there’s new stuff for Flash developers, video and audio professionals, as well as some wickedly cool developments in the InDesign world. So, be sure to check out Terry’s blog to get up to speed on publishing from InDesign to tablets. Jason will be spreading all of the new video and audio love (any Audition fans out there on the Mac platform?), and Paul will be sharing all the new developments around Flash and how this version is raising the bar on multi-screen development for applications and games.

As always, be sure to visit Dreamweaver’s home on Adobe.com for a complete list of features, as well as pricing and upgrade information.

There are several approaches to provide this fallback, but the “recommended” way to do this is as follows. We begin with the <video> element, and then a list of <source> elements providing the multiple encodings. Of course, you have to remember to list the MP4 file first, because iDevices are so damned arrogant that they won’t look further if they don’t see their desired format first. Not that Firefox is much better — if you don’t provide an ogg-encoded video, Firefox won’t fall back to the Flash video. Which, of course means you must encode your video in two formats (at least for now, as we wait to see the impact/support for WebM). Finally, you need the <object> element for Flash which loads and plays the H.264 video in a SWF wrapper.

<video  height="270" width="340" controls>
<source src="assets/video/odysseyAdv.mp4" type="video/mp4" />
<source src="assets/video/odysseyAdv.ogg" type="video/ogg"/>
<object id="FlashID2" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="340" height="270">
  <param name="movie" value="assets/video/videoPlayer.swf"> <!-- other parameters intentionally omitted -->
</object>
</video>

This got me to thinking… there’s got to be an easier way to deliver video to everyone – especially given that I don’t (currently) have any way to encode ogg or webm video from within Creative Suite 5. Since we are already encoding video into H.264 for consumption in Flash, couldn’t we just stop there? With the penetration of Flash at over 96% on desktop computers, Flash is the predominent video delivery vehicle on the desktop web. On mobile, Flash is already available both in the browser, as well as via AIR, on Android devices and will soon be available on other smartphone platforms like RIM, Palm, Nokia – so delivering via Flash is viable. So it’s only the iDevices that seem to be a problem – but the solution is so simple it’s almost laughable that we haven’t thought of it before.

For years we have “sniffed” for the presence of the proper Flash Player version on the desktop, and provided the opportunity to do an express install to update to the most current version. And for visitors without the Flash player, we’ve even provided alternate content such as the Flash Player badge and verbiage to suggest that the visitor install Flash. Hello, solution!

Instead of burying the Flash version of the video in the <video> element as a fallback for Internet Explorer 8 and below, we can provide Flash as the first option, and fall back to the native <video> element for iDevices.

<object id="FlashID2" classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" width="340" height="270">
<param name="movie" value="assets/video/videoPlayer.swf"> <!-- other parameters intentionally omitted -->
<!-- The browser displays the following alternative content for users with Flash Player 6.0 and older. -->
<div>
<h4>You must be on an iDevice, because you are seeing native HTML5 video — everyone else sees the video in the Flash Player!</h4>
<video  height="270" width="340" controls>
<source src="assets/video/odysseyAdv.mp4" type="video/mp4" />
<source src="assets/video/odysseyAdv.ogg" type="video/ogg"/>
</video>
</div>
</object>

You can see that I’ve simply put the <video> element in the place provided for alternate content. And, if you want, you can still provide all three video formats (mp4, ogg, webm) in case someone on Firefox has a Flash blocker turned on, for example. But if you only want to encode once as H.264, this solution is so simple, you’re probably kicking yourself as hard as I was when I “discovered” it.

Don’t believe me? Here’s an example that shows the native video with Flash fallback and there’s also a link to the Flash with native video fallback. And if you have any problems with these examples, definitely let me know!

At a recent conference, I had the chance to ask a former Dreamweaver user why he’d begun using Coda instead. One of the reasons he cited was Coda’s snippets feature (called Clips in Coda). I couldn’t help but laugh – and point out that Dreamweaver not only has a snippets panel, it’s been in the program for over 10 years!

Used properly, the Snippets panel becomes one of Dreamweaver’s most productivity-enhancing features. Let’s take a closer look…

Depending upon your current workspace layout, the Snippets panel may or may not be visible. The easiest way to access it (without clicking through the various panel groups) is simply to use the Window>Snippets command. By default, Dreamweaver comes with 8 predefined folders of snippets, providing various pieces of functionality. But honestly, 7 of these are completely useless unless you are an absolute noob. The 1 folder that I actually have found a use for is the Javascript folder. There are actually some really useful snippets in there. For example, I had a recent project that needed a random image displayed. Of course, that meant that I needed a random number to be generated to pick the lucky image from my array. I could have done this with PHP, but wanted to offload the task for client-side processing. And, guess what? There’s a random number script right there in the folder.

I do most of my Javascripting these days with jQuery. And, anyone who uses jQuery will tell you how quickly they tire of writing “$(document).ready(function () {…});” Of course, before you even get that far, you’ve got to write the <script> block. After about the 4313th time of writing it myself, I “remembered” the Snippets panel. Simply write out the desired code once and then highlight it in the Code View. In the Snippets panel, select the desired folder (or create a new folder) to save the new snippet into, then click the new Snippet button at the bottom of the panel.

The code which you highlighted is copied into the dialog automatically. All you need to do is give the new Snippet a name, and decide how you want the snippet applied. You have two choices, you can either wrap code around a selected element (in this case, you would need to write or copy/paste some additional code into the Insert After field), or chose the Insert Block option to simply insert the block of code in the current cursor location.

Now, the next time you need it, you can simply double click the snippet in the Snippet Panel – or, even better, use a keyboard shortcut!

Simply choose the Keyboard Shortcuts command from the Dreamweaver menu on the Mac or the Help menu on Windows (I believe – sorry, I’m a Mac guy). You’ll need to duplicate the standard keyboard shortcut set. Once you’ve done this, you can choose Snippets from the Commands drop-down menu.

Select your newly created snippet, and then simply press the keys that you want to use as the keyboard shortcut. If you accidentally chose a key combination that is already assigned to a command, you’ll be warned and have the option to either choose a new combination, or wipe out the shortcut on the other command and assign it to your new snippet.

Now, all I have to do is use the keyboard shortcut to insert my script block which also contains my initial jQuery code. The biggest challenge now, is simply remembering all of your new shortcuts! I hope this helps you become a bit more productive…

I’ve been using this workspace so long now, that I tend to forget what the default DW workspace even looks like! The only issue that I’ve had is that I still find myself toggling the panels on/off using the F4 keyboard shortcut so that I can see more of the design.

Well, I just found out, that I can keep them toggled close – and still get to what I need quickly! (Head slap here) First, use F4 to toggle your panels off. Now, when you need them, simply move your mouse all the way to the edge of the screen that you’ve hidden the panels – and, viola, there they are! Click back in your page and they hide themselves again.