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.
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.
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.
Is Spry compatible with the AIR framework?
Can the framework play well with others, such as Aptana?
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.
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.