At the MAX conference in Chicago, we caught up with Scott Fegette, technical product manager for Dreamweaver to discuss the ins and outs of the upcoming Spry release.

Builder AU: What’s new in Spry 1.6?

Fegette: A lot of changes and a few new features too. The focus this time for 1.6 was really about shoring up our story and raising our game in regards to standards and accessibility and best practises in general.

There was some early criticism from some of the standards organisations about the decision early on with Spry to go on with custom attributes for a lot of the model.

Although we’re technically following the letter of the standards, we had namespace for our custom attributes and we’re kind of doing things correctly, the movement of unobtrusive JavaScript is gaining a lot of steam in best practise circles right now and obviously putting custom attributes directly in your mark-up starts to litter your content model along with your behaviour layer and we wanted to start addressing things like that specifically.

So in 1.6 one of the new features is the element selector, similar to some other frameworks, prototype for example, you can have double dollar sign notation to actually select individual element selectors within your mark-up and attach Spry elements or anything else unobtrusively at runtime so you can move all your behaviour layer off into JavaScript.

A lot of other things, we now provide compressed and packed versions of the files. A good example is the SpryData.js went from 128k to around 41k, huge savings. There was a little bit of concern about the size of the files so that will help shore that up a bit.

Of course if you’re using compressed files you do have to deal with the decompression hit on the browser side but most people would prefer that trade off. The real story here is that you have your options, you can use the uncompressed files or you can use either a packed or a packed and compressed file also and we included all of these in the pack.

Let’s see, some other things in Spry 1.6, a lot of it has been documentation too, we realised that people downloaded Spry and were using it at face value but weren’t really diving deeply into what you could do with the framework so we spent a lot of time … getting a lot of documentation around best practises, ways that you could create really gracefully degrading pages using Spry, ways that you could use Spry unobtrusively [to] really separate content from behaviour.

So the documentation, I think, is kind of the unsung feature of 1.6, there’s just so much information there that helps you take Spry to the next level, regardless of how you got into it. If you downloaded it as a framework, if you’re using it in Dreamweaver, it’s just a lot of great information.

Dreamweaver was another point, we’re always had this interesting delta situation between Dreamweaver and Spry in that Spry was really a lambs project — it was launched a good year before Dreamweaver CS3 launched.

So when CS3 came out we actually had kind of a pre-release version of 1.6, 1.5 that we wanted to get out but we were torn, we weren’t really able to update Dreamweaver with it yet, we wanted to get more feedback so as soon as we pushed it out we got a lot of criticism on why couldn’t users update Dreamweaver directly.

That kind of exasperated the difference between our shipping product and our labs product of Spry. So with 1.6 we also have an updater that you can either download separately or as part of the framework package that’ll basically go through and update all your framework files and give you the option to update your local sites directly.

And we did spend a lot of time testing backwards compatibility too, so at least we’re hoping, knock wood, that you won’t have any compatibility problems just by updating to 1.6. Your existing sites won’t break but you’ll get all these additional features too which will really help you move to the next level.

What about users that are using a previous version of Dreamweaver, is there any option for them?

No, the Spry integration was really part of CS3 so that’s kind of the starting point for Spry support, on the flip side though I personally like to advocate diving in and looking under the hood.

Dreamweaver gives you a lot of good visual features, but it’s really easy to treat it as a black box, push a button — get a feature. I mean Spry is a lot deeper as a framework that what you’ll even see in Dreamweaver CS3.

So personally I’d like to say that everyone should have access to Spry regardless of whether you own Dreamweaver 4, MX or CS3. You’ll get some of the nice push button features and easy integration with the UI in Dreamweaver CS3 but it certainly shouldn’t preclude you from using it.

Does this version of Spry address the issue of standards compliance?

Yeah, custom attributes. And that honestly is a bit of a philosophical debate in the standards community. You mentioned that there’s the Spry namespace, so Spry:attribute is the syntax and you add these custom attributes to your tags so like a TD tag you can add a little bit of Spry data attributes to that to help integrate it easily into the mark-up.

The reason why we decided to do it originally was because we realised that a lot of people wanted to get into rich interfaces but weren’t necessarily hardcore JavaScript coders, we wanted to make it something that was easy to understand as the mark-up they were used to.

So we went in this direction and there actually is some precedent even amongst the standards right now for using things this way. The YRIA initiative for accessibility implements rolls and states for accessibility using a custom namespace in exactly the same way. Although I totally agree and we’ve done a lot to shore it up I would have to disagree a little but that we kind of broke the mould because there are some existing examples that went this way too. The problem is when you start talking about validation a lot of the online validators can’t extend to custom namespaces. But realistically that’s what the X in XHTML stands for, extensible.

So you know we’re just trying to use the mechanism and that being said it’s not like I disagree with the criticism, I think that it’s really important to be able to use Spry both ways and that’s why we did 1.6. We wanted to make sure that you had the option that you weren’t tied into using custom attributes and namespaces if that’s not what you wanted.

So now it’s really easy to create an unobtrusive Spry page that validates perfectly and you can bring in these namespace attributes at runtime and get the benefit of the Spry framework later.

There seems to be more documentation, specifically examples of good use policy …

Absolutely, I mean best practice [best practice], there’s one thing to talk about standards and the letter of the law, so to speak, but you know with any law people find creative ways around it and ultimately it’s the interpretation of these rules. The standards and how they can be applied to real world projects.

We’ve been paying a lot of close attention to best practises, there’s one I brought up earlier, unobtrusive JavaScript in general. Complete separation of your display of CSS, your data, XHTML and your behaviour in JavaScript is becoming a goal that a lot of people are striving towards in their projects and this is just one more way that we’re helping Spry fit within that model instead of the one that we carved out for it.

Is Spry compatible with the AIR framework?

Yeah, as a matter of fact it’s funny that you mentioned that, one of the AIR Developer Derby finalists was Spaz AIR which was created with a nice mix of I believe a little bit of JQuery, a little bit of Spry — it’s all HTML and JavaScript. It’s a really cool Twitter client. It’s ended up my Twitter client of choice lately, it’s a hot little app and it’s all in AIR.

Can the framework play well with others, such as Aptana?

A pretty hard core JavaScript developer pulled me aside yesterday and was like “you know I gotta tell you Spry is a little bit of your sleeper feature. I hadn’t really noticed it until now and I took a look at it and I’m really liking it.” We made Spry to be really open and accessible so it plays nicely with other development tools.

We just want to stay as agnostic with Spry as possible, honestly it’s a framework — it does have hooks into Dreamweaver but we’re looking at it as more Dreamweaver running with Spry as opposed to Spry being part of Dreamweaver.

Spry’s got its own development team, they’re working on their own schedules and we always sync up with the Dreamweaver team, they’re part of the larger team, it’s kind of like a start-up within a big company, it helps keep us nimble.

But there’s obviously a benefit in having it in Dreamweaver …

To me it’s all about rapid development in Dreamweaver. Keep in mind I may not even be the best use case for a typical Dreamweaver developer because I’m a pretty serious gear head. I love tweaking code but honestly when I start with Spry, and I think the same goes with a lot of Dreamweaver features too, I use Dreamweaver to get my code 90 percent of the way there, but then there’s always little tweaks that I want to do on the backend with Spry.

Let’s say I’ve definitely drunk the standards Kool-Aid myself over the last year. A few months of withering criticism will do that to many people, but it’s actually good advice that I’ve taken to heart.

I like to start with Spry, mock out my original page, get everything together. I’m not really thinking about how Dreamweaver’s working specifically with the attributes, whether they’re in the page, whether they’re external or not. At the time that I want to start refining, that’s when I usually do my moving. I’ll take CSS inline styles and move them externally, I’ll put event handlers out of my mark-up, move them into external JavaScript also and all that’s really easy to do with the code management tools in Dreamweaver.

Honestly that’s where I’m seeing a lot of people are using Spry. These people who are hard core developers using Dreamweaver with Spry, mostly. It’s just to get that quick mark-up. On the other hand it’s also pretty comprehensive, you can do a lot with the tools there. They don’t cover all the features in the framework, but they cover enough of them to really let designers be effective building rich interfaces. That’s kind of the goal of the framework anyway.

I think that we’re almost serving two masters here with Spry, there’s the folk who really want a robust framework, people who might even use a mix of frameworks. Spry, along with JQuery or people with use YUI widgets on the front-end, that’s totally cool, but then there’s designers who really just want to get a job done and done quickly so these are the benefits of the front-end feature of Dreamweaver for me.