Feb 17, 2009
The History of Creative Suite Installers
Note: Our current plan is to post a new entry here every week and then follow up that post many times per day in the comments section. This week’s post is the last of the “Introductory” posts. Next week’s topic is scheduled to be why native OS installers (MSI/PKG) don’t satisfy our needs. I’m really looking forward to next week’s discussion.
The Creative Suite has struggled for a long time with its installers. There have been complaints about installation failures or inability to deploy in an enterprise environment since CS1. In CS3 Adobe moved to its own installer technology. In a future post we’ll go through the details of why we use our own installer technology, including why MSI/PKG formats are unacceptable. For this post, I’d like to talk a little bit about what happened to the installers over the last four Creative Suite releases and the opportunities currently available to us.
CS1 was really a collection of traditional Adobe applications each with its own unique install requirements. The applications grew over literally decades into the mature Adobe applications we sell today. As such, the install requirements were diverse and sometimes not totally rational. The shared technologies in CS1 were minimal. The primary shared technology that made the aggregate applications into a “suite” was the Version Cue feature set. Given the diverse install requirements and limited shared components, CS1 continued to have each application create its own unique installer and aggregated these into a single suite installer.
CS2 was quite similar to CS1 in that the number of applications didn’t dramatically change. The install requirements of the applications were relatively constant compared to CS1. The number of shared components grew only slightly, with the introduction of the Bridge application. Even this limited set of shared components and only-slightly changing product line stretched the abilities of the platform install technologies. Creating the CS2 installers was a very costly and time consuming process. Something needed to change.
With CS3 and the inclusion of former Macromedia applications, it was very clear that the platform install technologies would not satisfy the business requirements for Creative Suite installers. So Adobe created its own install technology. For CS3, the installer was all new code. It was introduced to provide the kind of package management and flexibility needed by Adobe’s increasingly diverse install requirements. The move to our own installers was extremely challenging both for Adobe and Adobe’s customers. We’re really not in the business of creating installers and would prefer not to do so; but, given the need to rapidly integrate the former Macromedia applications with all their different installer requirements, the now significantly larger set of shared components and the experience of creating CS2 installers, it was clear that we could no longer use the platform technologies.
As I said, the move to our own installers was extremely painful for Adobe and Adobe’s customers. One could easily argue that it was a step backward. Certainly for our enterprise customers it set up really difficult road blocks to deploying the Creative Suite. So when we started work for CS4 we put lots of focus on the install technology to try to “get it right”, at least for the retail customers. The personnel also changed so that the technology was now managed by the same group responsible for the Creative Suite itself (me) – essentially, we wanted the technology team and its management to have skin in the game.
Our goal for CS4 was to make the installers work for the retail customer. It was a difficult choice because we knew the enterprise customers would continue to run across the same road blocks as with CS3. Throughout the CS3 cycle we gathered input from customer care about what problems our retail users were having and tried to ensure the CS4 installers addressed those problems. We focused on solidifying the install technology so that it worked as it was supposed to work. We operated within the limitations of the existing technology to provide a UI as stable as we could.
Lots of hard work later, we shipped CS4 and did see dramatic improvements in the installer for retail customers. Customer care calls about failed installs dropped significantly. There’s no doubt that problems still exist. The enterprise customers are still left in the lurch. The UI still has lots of room for improvement. But for retail customers, it was definitely a step in the right direction.
Now we have some opportunities ahead of us. The personnel changes that happened for CS4 allowed us to train the engineers on the technology and the problems our customers faced for installation. So the engineers can now make architectural changes to the install technology that can eliminate some of the road blocks for enterprise customers. We also have the opportunity to migrate the UI technology away from DHTML (used for CS3 and CS4) into an embedded Flash interpreter. This will allow us to have much more flexibility and stability in the UI; which will, in turn, allow us to use a better experience design. We continue to receive feedback from our customers about the problems they face when installing and will continue to tackle the most egregious problems that surface, thereby making the installers yet more stable and drive down customer care calls even further. I’m sure it still won’t be perfect; but, it had better be much better than CS3 and CS4!
We’d like to make further progress on the aforementioned architectural changes before going into the details on this blog. I’d hate to advertise a change and then have to renege on that promise a month or two later. As we do make progress we’ll advertise the changes being made so that you’re all well aware of what to expect in the next version before it ships. There may also be an opportunity to provide some changes for CS4 prior to shipping the next version, at least for changes that don’t involve massive rework or break United States accounting rules.
So that’s where we are today. We continue to gather information from World Wide Customer Care (tech support), strategic partners and users such as readers of this blog. With this information we can look at what is failing and see how we might be able to fix it. Some of those fixes can come as an update or workaround in CS4. Some of those fixes will have to come in future versions of the Creative Suite.
The comments from the first post were very encouraging. You all seem to approach this with a spirit of cooperation and are educating us on exactly what is causing you problems. As we come up with solutions and verify that those solutions are actually feasible we’ll try to let you know our plans. That way you’ll know what to expect in the future and can hopefully confirm that our plans really will satisfy most of your needs – or correct us where we run astray.
Sr. Engineering Manger