Recently in Web Standards Category

This one's been a lot of fun. Seriously.

Back at MAX 2008 we got to show off a project in it's early stages, code-named Meer Meer. It raised quite a bit of attention at the time, and was - as simply as I can put it - an earnest attempt on our parts to solve a problem that we'd been hearing about for quite some time from our professional web designers and developers - the challenge of cross-browser (and OS) design for the open web.

Web pros faced with supporting the wide variety of browsers and OSen their clients demanded were resorting to either physical or virtual test labs, or services that worked in a rather serial fashion - you'd type in a URL which would go into a queue with everyone else, and eventually return you a screenshot in a minute. Or five. Or far longer. No one wants to get blindsided with browser compatibility bugs at the critical endgame of a project, but the logistics of cross-browser testing often make it difficult to do early and often. We decided to address the problem with two principles - simplicity and speed.

Adobe BrowserLab is our simple, speedy solution.

BrowserLab runs in any Flash 10-enabled browser. That's it. No bulky downloads, no local installations (unless you want to enable direct Dreamweaver CS4 integration, which I strongly recommend), just you and an initial set of browsers on Windows and Mac to test your layouts against. The BrowserLab interface is simple, and uncluttered - one view to manage sets of browsers to both match project requirements and kick off 'batches' of screenshots easily, and one view to view, compare and examine your browser screenshots. You switch view modes with the 1, 2 and 3 key, and cycle through loaded browser screenshots with the up and down arrow. You can zoom into screenshots while overlaying two browsers together at your opacity of choice. A large part of BrowserLab's sweetness is its utter simplicity.

And if you're using Dreamweaver CS4, it's even sweeter. The biggest problem with existing 'screenshot' services is that you can't easily preview interactive content - rollovers, Ajax/JS widgets, dynamic data, basically anything that's loaded or 'triggered' in your page by user interaction. You're pretty much stuck with the default, loaded page that your URL produces. Dreamweaver CS4's new Live View - and it's ability to freeze JavaScript interactivity in place - lets you essentially 'drive' a page you're working on into a particular design "state", freeze it - and send that 'snapshot' directly to BrowserLab for review. The BrowserLab Dreamweaver panel gives you status of requests in the BrowserLab service so you aren't wasting time waiting, but concentrating on design - not collecting and compiling screenshots from test machines/virtual machines, or tapping your toes waiting for your turn in a screenshot queue. It's high time we were able to spend less time managing the logistical headaches of cross-browser proofing, and more time concentrating on design. Or code. Or whatever. :)

(next section updated occasionally as status changes, FYI)

As you read this, Adobe BrowserLab is live. However, we've already reached our initial beta capacity for the first round - we've let in roughly 3500 people or so this week on a first-come, first-served basis - as the first of several phases of rolling out the service. Experience is the key, so we're ramping up user capacity over time - if you didn't get in this week our apologies- we'll be extending to a wider, invitation-based program in early July to let everyone help us kick the wheels and polish the chrome for our first release. You can get all the info over in the BrowserLab section of Adobe Labs, and of course make sure to bookmark BrowserLab itself at browserlab.adobe.com.

On behalf of the entire BrowserLab team, enjoy!

Full disclosure- "Designing in a Developer's World" is my session this year at MAX. It was born out of many, many discussions I've had over the last 2 years in which it's become increasingly clear that the line between designer and developer is blurring when it comes to modern web-based projects.

As opposed to a decade ago where static web pages and request/response interaction with server-side components were your only choice, these days your average web designer creates designs that are dynamic and stateful - user interface elements open, closed, expanded, and resized, forms that validate themselves without taking a trip to the server first, etc - it's certainly not 1997 anymore. As the technical demands on web designers increase, the complexity of our projects have increased exponentially. This session will really get to the heart of the quandary- efficiently creating stateful, web-based designs while maintaining a modicum of creativity throughout an increasingly technical process. For examples and context, I'm planning to explore several types of 'stateful design' workflows that today's web designers are regularly a part of- from interactive form-based applications, to rich interface implementation, to content syndication and reuse.

There will be slides and example code available after the session, of course- I'll be sure to post them on my blog in case you miss it. However, if this sounds up your alley, please add my "Designing in a Developer's World" session to your MAX schedule, and make sure to come armed with your best questions- my favorite part about these presentations is, quite frankly, the open Q&A that always ensues afterwards.

Look forward to seeing you in November!

It can be tough to stay on top of web standards and best practices when you're churning away on projects- and god knows reading the W3C specs can be overwhelming. Recently Opera has taken a big step forward in releasing the Opera Web Standards Curriculum- a series of Creative Commons-licensed articles stepping through the breath of standards-based web development in an incredibly straightforward manner. Although they've planned around 50 such articles, the first 23 are now online for your educational pleasure.

Big shout-out and tip of the hat to Opera's standards viking Chris Mills, who wrangled all of the editorial duties, coordinated with the Yahoo! developer network, and launched all of this curriculum right as he also welcomed his daughter Elva into the world - two major undertakings of extreme significance if you ask me. This type of open educational material has been long overdue, and the open way in which it's being distributed will go a long way towards helping further the cause of web standards in both the professional market as well as the educational world - where curriculum can take an even slower path to adopt new and emerging standards.

Kudos to all involved- and BTW Chris, next time drinks are on me. :)

I'll be presenting on web design best practices/standards (along with a sneak peek of the next version of Dreamweaver) today @1:15pm at the WebVisions conference in Portland, should you be attending. Swing by, get an early look at what we've been working on back in the Dreamlabs, along with a lot of thoughts as to WHY we've been doing what we've doing with Dreamweaver. Aside from my own plug, the WebVisions track/session schedule looks great, with a speaker list that reads like a virtual who's-who of web luminaries. Given I'm up against folks like Bryan Veloso, Dan Rubin, Roger Black and Aaron Gustafson during my session hour, I'm both excited at the quality and density of content at WebVisions this year- and simultaneously bummed at what I'll miss even in the hour I'm onstage.

Currently I'm in Dave McFarland's "JavaScript for Designers" session, which is starting off quite nicely (great slides, too), but will probably be lurking in the lounge area between sessions catching up on email and feeds. Tap me on the shoulder if you're here and say hey!

Although it's long been rumored, today the news was officially delivered- GoLive will no longer be sold as of today (April 28th, 2008), and the focus will shift to Dreamweaver long-term for Adobe's professional web design & development customers. This is news that I'm reasonably certain most GoLive users saw coming as far back as the CS3 launch- when Dreamweaver replaced GoLive in the Creative Suite packages - but it's good to finally have an official word on the matter. GoLive (versions 5, 6, CS2 and 9) customers can take advantage of a $199 cross-grade special (same price as a Dreamweaver upgrade, basically) to pick up Dreamweaver CS3, which means there'll be a lot of GoLive customers considering Dreamweaver now.

There's been a lot of speculation on if and when this would happen - and if so, why - so I wanted to at least give a little perspective on this from my vantage point - as a long-time Dreamweaver team member - on two of the main concerns I've heard around Dreamweaver taking the helm of our web design products.

Lack of Competition

Ever since the Macromedia acquisition, I've heard the pretty regular concern that Adobe's competitors were systematically being eliminated, leaving the competitive landscape around our products bleak and quite frankly - non-competitive. Honestly, I couldn't see that more differently - competitors are all around if you care to look for them- from lightweight web design/development apps like Coda, CSSEdit and others, to full-blown IDEs like Visual Studio and Eclipse. For design-centric web developers, apps like Freeway and the reasonably-newer Expression Web are viable options. GoLive was a worthy competitor, but lately we've even more competing tools to consider as we build out Dreamweaver's roadmap, not less. That can only be a good thing for the competitive web design landscape - and Dreamweaver's future within it - in my opinion.

Coders vs Designers

Web design has increasingly become a more technical discipline over the years, and Dreamweaver's secret to success was always to follow what the pro web designers were doing on a project and workflow basis, and enable that within our tools. We occasionally hear criticism that Dreamweaver isn't 'WYSIWYG enough', or needs to support more drag-and-drop features and get away from the code. But that's not what the pro web design market has been telling us - web design is not like print design, or even Flash design. When was the last time you needed to hack your InDesign files to print correctly on that one, finicky printer? Web browsers are OUR printers, and they sure as heck don't always play as nicely with one another- let alone render the same way even on the best of days. Visual tools can get you 90% of the way there with the current browser landscape- but that remaining 10% of your headache is almost always code-based- a browser hack inserted into the stylesheet or perhaps some judicious markup-juggling to get that layout working correctly. And when this bites you, you absolutely, positively, have to have access to your code. Plain and simple. Sure, a lot of print designers have become accustomed to GoLive's more visual model, but at the end of the day Dreamweaver has to serve it's primary market - professional web designers and developers - and the market spoke quite loudly on that subject years ago. We're just following their lead, honestly.

But I'm sure there's lots of good ideas to consider now too, do you have favorite GoLive features that you'd like the DW team to consider going forward? If so, please use our bug/wish list form here to send them in for consideration (always the most direct path to getting a request into the teams here, FYI):

http://www.adobe.com/go/wish

So What's Next?

This will undoubtedly be a period of transition as there's a lot of GoLive users who are now considering Dreamweaver, and we'd like to make sure that your transition's a smooth one. I strongly recommend checking out the resources we've made available at the following URL:

http://www.adobe.com/products/dreamweaver/switch

These include:

• The GoLive to Dreamweaver migration extension - helping you convert the structure of your legacy sites to a format that can be imported and managed by Dreamweaver.
• GoLive to Dreamweaver Site Migration guide - written by GoLive experts Adam Pratt and Lynn Grillo.
• Training Video from Lynda.com - giving tips and tricks for getting up to speed quickly with Dreamweaver, including the migration process

Indeed, there's a lot of areas of difference between GoLive and Dreamweaver, but hopefully these bits of info will help you make the most sense of them quickly.

For the Dreamweaver team, we've already seen many of the GoLive engineers join our ranks, who are all contributing quite a bit to the next release of Dreamweaver already. It's been a pretty smooth transition internally, and is resulting in one amazing team. However, I realize that this news may be much more upsetting to you, but sincerely hope that the the transition is as painless as possible. Let us know how we can help?

I've been pretty hectic between travel and SxSW the last couple weeks, but a few cool items of note may have slipped past. Catching up now...

• Kuler just got an update today, with a feature I've been drooling over since I heard about it a few weeks back- color extraction! You can now upload an image, and have Kuler extract the dominant color theme from it. Simply awesome feature- saves me from my old "Posterize > sample colors to a swatch" workflow in Photoshop. Make sure and give the Kuler team your feedback, too.
• The Web Standards Project (WaSP) announced at SxSW last week that the Dreamweaver Task Force is being renamed and expanded to the Adobe Task Force, covering a wider range of our products. Don't fear, though- our historical cooperation with WaSP from the Dreamweaver team is alive and kicking as always, and will continue into the foreseeable future. I love those guys for keeping us honest over the years!
• Chris Charlton has been working overtime again and sneaked a peek at his upcoming DW extension for Drupal developers - the Dreamweaver Themer's Kit extension for Drupal. I swear that guy never sleeps, if you've been following his developer site xtnd.us you know exactly what I'm talking about. You can also check the Adobe Technologies group he manages out over at groups.drupal.org. Get some rest, Chris- we need you for the 4th quarter, man!

Anyway, since I didn't feel like posting yet another dissection of what went wrong in Sarah Lacy's interview of Facebook's Mark Zuckerburg last week (although I missed the beginning of the interview, I was drawn to the trainwreck ending like a moth to a flame), or general 'wish you were here' posts from SXSW, so I hope these tidbits are a little lighter on the fluff. If you want the blow-by-blow from last week in Austin, you can rewind my Twitter stream, after all.

Web developer Steve Stringer contacted me last week, and was interested in a point-counterpoint discussion on the merits of unobtrusive JavaScript (or lack thereof), and both myself and author Dave McFarland (Dreamweaver MX - The Missing Manual) took him up on it. You can read the results at Steve's StringFoo blog here - and by all means please jump into the comments if you have strong opinions one way or the other. (I'll refrain from further commentary here, as I pretty much summed my opinions up in the article, and would prefer to channel followup conversation to the article itself, too.)

Thanks for the opportunity, Steve!

First - and probably most surprising - the Internet Explorer 8 team just announced the reversal of the year. Instead of IE8 rendering in IE7 compatibility mode by default (and requiring a meta tag/header to 'turn on' IE8 compliance), the IE team just announced that IE8 will interpret web content in the most forward-looking, standards-compliant way that it can. The community has been very vocal about this, so it's great to see the IE team not just listen, but respond directly to the negative feedback. To be clear, there was definitely a split in the standards community on the subject, but at the end of the day I can't help but feel that having IE render more closely to standards by default is the right thing to do.

Secondly, the Web Standards Project (aka WaSP) just announced that the Acid3 browser test is now available, providing yet another benchmark for compliance for the browser vendors as a whole to refer to. IE8, for the record, recently passed the Acid2 test, but Drew hints that 'work is already underway based on the Acid3 previews', which is heartening to hear as well. Let's hope all the browser vendors take Acid3 to heart, as a world with far less cross-browser rendering headaches is a world I'd really like to live in.

Headed to SXSW '08 this year? I know I am, and I generally try to hit any/all WaSP-related events open to the public as I'm a bit obsessed with standards, personally speaking. Fortunately this year there's more than just the annual meeting, the Web Standards Project are also hosting a barbecue event right across from the main event hall.

Because there's so much going on in the world wide web today (IE8, HTML5), this year we're doing an additional event: the Bike Hugger Beer & BBQ. It's open to all SXSW interactive attendees, with free beer, free food and free (?) WaSP members present to discuss the state of the browser landscape.

This will be similar to the WaSP Cafés which, by the by, have been held in Tokyo, France and Spain over the last year, with 2008's first WaSP Café (held in Paris) having a grand total of 70 people attending!

The core topic for the WaSP discussion will be the IE8 versioning proposal, which clearly has been a hot topic since the very moment it was announced on A List Apart. All the WaSPs that will be at SXSW will be present, so we hope to see you there as well!

More details on the event can be found on the WaSP site, of course.

Only downer for me is that I won't be flying in until Saturday afternoon due to another speaking gig back in the Bay Area, but I'll be trying to go straight here from the airport. Hope to see you there!

After a week of highly polarized reactions to the recent Opera complaint against Microsoft, you've got to give some long overdue props to Microsoft's Internet Explorer team for pushing forward and finally announcing that internal builds of IE 8 have finally passed the Acid2 test, even if just internally for now. You can read the news from Dean Hachamovitch here, and Molly Holzschlag's report from the trenches here. Here's hoping IE8 gets out into the wild quickly.