Logged In

Inside the Dreamweaver MX 2004 Updater

When the Developer Center team asked me to write the Logged In article for our new release of Dreamweaver MX 2004, I realized I couldn't do it alone. This performance update has truly been a team effort. For that reason, I invited the team to share their thoughts along with me in this article.

First things first: If you're a Dreamweaver MX 2004 user, there's a new updater (version 7.0.1). You can download it now.

While we were thrilled with the new features released in Dreamweaver MX 2004 this past fall, we were not as pleased with the performance and stability we heard about from customers. Unfortunately, the new features and functionality we added also introduced thousands more lines of code to an already robust product. With over three million lines of code in Dreamweaver MX 2004, the new features increased the application’s complexity, resulting in unexpected performance and stability issues.

Over the past few months, we as a team have focused only on quality improvements for Dreamweaver; this updater provides substantial and dramatic improvements to stability and performance. We've invested deeply across the board in some areas you will notice right away, and in some that you will never notice. We're particularly proud of these "invisible" improvements—the features you should never need to notice. If they are fast and do what you expect, then we've done our job and done it well.

The entire Dreamweaver team is proud to release this updater, and they wanted to share some of the things they’ve learned working on this project. Below are some insights from behind the scenes of the 7.0.1 release of Dreamweaver MX 2004.

Jen Taylor
Product Manager, Dreamweaver

Dominic Sagolla and David Zuckerman: Performance and Stability

"Does it feel faster?" This is the question that we've been asking ourselves each day for the past five months as we worked on an updater. When we shipped Dreamweaver MX 2004, it was clear that our customers were experiencing slowness and stability problems, especially on the Macintosh. Customers told us that they had problems in common areas such as typing in tables, editing CSS, and even performing small functions such as switching between documents or applications.

The two of us systematically categorized these issues into problem areas and created a customer survey to try to validate these categories. We posted this survey to popular forums and review sites to get as much data as possible. Armed with hundreds of customer survey responses for both Mac and PC, we led a performance task force to identify some possible solutions to these issues. While working closely with our best engineers, we created a web application (in Dreamweaver) to track performance on a daily basis. The purpose of this application was to distinguish between the automated performance numbers that developers generate and the actual "feel" of working with Dreamweaver.

We handpicked QA engineers to give a subjective analysis of each new build. We obsessed over each negative opinion or comment from customers to make sure that everyone got heard. We bugged management incessantly to make changes that normally wouldn't go into an updater release.

Once we felt that the application showed marked performance and stability improvements, we invited the most vocal of our survey respondents to participate in a new beta group. This was a different beta experience than others we’ve had for Dreamweaver. We found ourselves e-mailing or calling individuals more often. We gathered a huge storehouse of customer files to find the best examples of problem areas. We didn't want to ship the product until all of our beta users felt that it was ready to go.

Our team has listened to everyone and made our beta users much happier than they were last September. Our users tell us that the new Dreamweaver MX 2004 7.0.1 is as fast as or faster than Dreamweaver MX. They also say that their important issues have been addressed. They're getting great work done using Dreamweaver and discovering the power of new features such as relevant CSS and browser validation.

We've spent extra time trying to make this release the best that it can be for all of our customers. Everyone on the Dreamweaver team is excited to see this release go out the door, and we look forward to hearing from you once you try it!

Dominic Sagolla and David Zuckerman
QA Engineers, Dreamweaver

Jack Herrington: Fixing Issues and Bugs

"What we need is three months to just fix bugs." That's what Terry Stone, QA engineer for Dreamweaver, told me, and I agreed with him. And that's what we did—four months of bug fixing. We dedicated that time to fixing all of the weak points, performance problems, broken windows, bad workflow, and problematic user interface in a product that had been racing to add new features from its first release.

What were the problems? The major problem with the performance in MX 2004 was Unicode. Unicode enables a software product or a website to render text correctly across multiple platforms, languages, and countries without re-engineering. Dreamweaver is used worldwide, so it is critical that we support the global standard for text entry and rendering within the product so that our users can easily create content that works everywhere. For the Dreamweaver MX 2004 release, we converted the entire code base to use all Unicode strings and, while the code was simpler, it was also slower. To tackle that, we equipped Dom, Dave, and the engineers with stopwatches, and we judged the MX 2004 performance against MX. We wanted to be as fast or faster. We have achieved that goal of "same or faster" in the 7.0.1 release; in some areas, 7.0.1 is much faster.

With this release, we've addressed more bugs than we've ever addressed in any previous Dreamweaver release, including both full shipping versions and free dot releases. We concentrated on major areas such as CSS, sites, user interface, performance, tables, and the return of the timeline feature. That is not to say that we didn't fix stuff all over; we did. There wasn't a single area of the application without at least a couple of fixes, and the majority had many more than that.

When I first joined the team, what struck me was that we had a dedication to pushing the limits by implementing new features, but this sometimes cost us in stability and performance. As a quality hound, it has been a pleasure just concentrating on the bugs for once to make a super-stable release that still has great features.

It is rare for a company to spend the time required to go through its bug archives, talk with customers to identify the bugs, and spend the time to make the fixes. Now that we have, we can build on this solid base to create the next generation of Dreamweaver, which will go beyond what any of us imagined it could ever do when we started out seven years ago.

Jack Herrington
Principal Software Engineer, Dreamweaver

Jay London: Timelines and the Upgrade Policy

"And about those timelines, Jay..." It was our community manager, calling me again with a question about the removal of the timelines feature in Dreamweaver MX 2004. After the first three questions came in, we knew we'd made a mistake. We removed the timelines in an effort to respond to overwhelming customer requests to simplify the product. Survey research indicated that timelines were rarely used, so we thought we would be in the clear removing them. However, customer response to the removal of this feature has taught us both that the survey data was wrong and that our process for assessing the removal of features needed some improvement. So, at the top of my list when we sat down to discuss the scope of the dot release was how we could resurface the timelines functionality. For those of you who knew and loved the timelines functionality in our prior releases, I'm happy to report that it is back. For those of you who would like to work with DHTML but are not familiar with the feature—check it out.

We learned a valuable lesson about our process of removing features. Streamlining the product is an important goal and one we will continue to strive for. However, we also need to make sure we continue to support the technologies you use in your work. We will do this by supporting our existing functionality or by introducing new features that allow our users to work with the same technologies in new, more efficient ways.

I highlight the timelines here, but what the reintroduction of the feature really represents is our focus on listening to the customer for this Dreamweaver MX 2004 Updater release. Listening is something we've always done well as a company, and we really did a lot of it for this release. We spent tons of time talking with Macromedia Technical Support and Customer Service about calls they had logged. We scoured our public bug list. We dug deeper into online forums—all in attempt to listen more closely and more clearly to how our users were working with Dreamweaver MX 2004. Through the research, we learned that instead of focusing on one or two specific areas of the product, we needed to focus on the product as a whole and evaluate fixes in virtually all parts of the product.

Building this updater has been an exciting time for us as a team. With this release we feel we've made significant changes across the board that will improve how you work in Dreamweaver MX 2004. Please, download the trial or update your existing product and then let us know how we did. If you find a bug or think of a feature you would like us to add for the next release, please let us know by completing the Feature Request/Bug Form.

Finally, in addition to ensuring that you can continue to work with all the same technologies from release to release, we've also worked with the legal team to adjust the upgrade policy so that as you upgrade from one version to the next, you can continue to use your prior version. And finally, don't forget to download the new dot release of Dreamweaver MX 2004.

Jay London
Engineering Manager, Dreamweaver

About the author