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.
Thanks,
–Eric Wilde
Sr. Engineering Manger
ewilde@adobe.com

30 Responses to The History of Creative Suite Installers

  1. Rosyna says:

    For the next CS cycle (CS5?) is there any way you can create “dummy” installers so people can complain about the UI early?
    By “dummy” I mean something that just installs the folders themselves (no files).
    It’d be nice if this “dummy” installer was also done on a disk image that mimics the real CS organization when you install from DVD (none of that setup.exe junk).
    I ask this because I know people will be loudest about the UI.

  2. Eric Wilde says:

    Rosyna writes:
    For the next CS cycle (CS5?) is there any way you can create “dummy” installers so people can complain about the UI early?
    I really do hope to get input on the UI prior to shipping anything. We can do that either through the prerelease program or by providing pointers to just UI here in this blog. I prefer the prerelease program. We try to keep the number of people in our prerelease program somewhat limited in order to not get overwhelmed with input; but, this type of UI feedback would be very valuable.
    For any readers of this blog that want to join the prerelease program for installation and licensing, please send me email directly. I cannot guarantee we’ll enlist all of you; but, we can try. Mail to: ewilde@adobe.com and mention:
    Who you are
    Why you want to be on our prerelease program (what you hope to contribute)
    What your role is in your business
    It’d be nice if this “dummy” installer was also done on a disk image that mimics the real CS organization when you install from DVD (none of that setup.exe junk).
    If its a prerelease build then the actual install would occur. That would be the least amount of work for us. For things like a “dummy” installer it might be easier to just publish screen shots for review.
    I ask this because I know people will be loudest about the UI.
    Wanna bet? :^)
    The loudest voices thus far have been the SysAdmins in the enterprise deployment space due to our nasty functional limitations there.

  3. Mark Barber says:

    Hi,
    I’m a sys admin for 730 Mac users, running about 75% CS2 25% CS3 with the business backing a plan to move to CS4 from April 2009. We’ve successfully used Casper and ARD as software deployment tools for earlier versions of CS and every other product on the Mac with little problem. Unfortunately as many of my fellow sys admins have pointed out this is not the case for CS4 and are now having to invest time with the Adobe Software Deployment Tool which isn’t guaranteed to work. With the size of environment I manage its key that I’m able to use the functionality within Casper e.g. – self-healing etc. Also some of my users require previous versions of CS to run with CS4 and unfortunately installing CS4 on top of previously versions creates sporadic errors. Added to the fact that we also need to change our font management system, in its early stages this is proving problematic even before we’ve got to a proper testing phase.

  4. Ben says:

    I note that Creative Suite is starting to use a lot more shared libraries which is both a blessing and a curse. For instance someone uninstalling CS3 may accidentally remove files used by CS4 applications. What is Adobe’s plan for mitigating these types of issues in the future? Also will the Creative Suites become more self contained?

  5. As one of those loud sys admins, I am wondering if with the advent of the Creative Suite Deployment Kit there would be a possibility of providing those in the enterprise deployment game with one or more payload-less PKG installers that call the appropriate AdobeUberInstaller to do their thing. This would be compatible with established PKG-based deployment methods yet not require the current (you guessed it) extremely painful repackaging rigamarole. I’d probably try and create something like this just to See What Happens but as a direct source for this stuff you guys may be able to provide a yay or nay on the concept.

  6. Brian Johns says:

    This may be a very esoteric issue, but can you address why the Adobe suite can’t install on a case-sensitive filesystem on a Mac? I realize this might not affect too many people but I was bit my it and ended up having to reinstall my entire OS just to install CS3.

  7. Eric Wilde says:

    Ben writes:
    I note that Creative Suite is starting to use a lot more shared libraries which is both a blessing and a curse. For instance someone uninstalling CS3 may accidentally remove files used by CS4 applications. What is Adobe’s plan for mitigating these types of issues in the future?

    Starting in CS3 we moved to our own installer technology partly because this complex package management wasn’t adequately supported by the native OS installers. We do indeed track multiple installs and only uninstall when all references to a shared component are removed – at least that’s the design. There were plenty of bugs in CS3. For CS4 I think we removed most of the kinks in this area, particularly for retail customers. Please note that this problem isn’t just a problem with multiple versions co-existing on the same system. It also happens when multiple products are uninstalled individually on the same system.
    Also will the Creative Suites become more self contained?
    I’m not sure I understand your question. Can you please explain?

  8. Eric Wilde says:

    Pepijn Bruienne writes:
    As one of those loud sys admins, I am wondering if with the advent of the Creative Suite Deployment Kit there would be a possibility of providing those in the enterprise deployment game with one or more payload-less PKG installers that call the appropriate AdobeUberInstaller to do their thing. This would be compatible with established PKG-based deployment methods yet not require the current (you guessed it) extremely painful repackaging rigamarole. I’d probably try and create something like this just to See What Happens but as a direct source for this stuff you guys may be able to provide a yay or nay on the concept.
    Great idea. We’ve also heard this suggestion from other enterprise deployment sys admins. I really want us to do something like this in the near future. There are some technical challenges; but, we think it may be possible. There are also some legal challenges which may block us (which is, I think, the biggest problem to doing something soon.) We are currently investigating if there’s something we can do before the next version of the Creative Suite. We’ll definitely post here as we find out more in the next month or two.
    I have heard of some customers using PkgGen to generate installers deployable through ARD.

  9. Eric Wilde says:

    Brian Johns writes:
    This may be a very esoteric issue, but can you address why the Adobe suite can’t install on a case-sensitive filesystem on a Mac? I realize this might not affect too many people but I was bit my it and ended up having to reinstall my entire OS just to install CS3.
    The short answer is that its not really an installer issue. Some applications themselves fail to execute on case sensitive files systems. Because of this failure on the applications, the installer blocks installing such applications on case sensitive file systems. I realize this is painful and can require lots of time to reinstall OSs. We do want this situation to change; but, we have to prioritize it along with all the other work that product teams are doing.
    Similarly with things like preference files being in all kinds of crazy formats and strewn across the hard drive. We’re pushing product teams to be consistent; but, its not going to be fixed quickly. There are other, more critical items that need to be fixed more quickly. For example, the enterprise deployment story or updaters are causing even greater problems and need to be fixed first.

  10. Jay Halderman says:

    Just a plain-old end user who was directed to this blog from a forum thread (http://www.adobeforums.com/webx?128@@.59b77ab9) by Tim Kurkoski on the AE team.
    I can’t begin to describe the painful experiences I have had upgrading CS2 to CS3 and subsequently CS3 to CS4. In both cases, the only solution was to run the cleanscript at level 4. However, once CS sucessfully installs, the updater installs fail and also break components of the suite in the process.
    Given that the only way to install is to wipe all traces of CS products off my system and then, once CS products are back on my system, the update installers fail, it seems logical to conclude that the installers can be pretty bad about dealing with existing installs of Adobe’s own products. This is particularly painful when one needs to migrate Version Cue data from one suite to the other, or needs to run elements of CS3 concurrently with CS4 (incidentally, required to use the Version Cue migrate plugin).
    Echoing an above sentiment about shared files, it seems the CS installers have an innate lack of awareness about how to handle files from other installs, and how to fail gracefully by rolling back changes. Coordination between the updaters is sorely needed instead of treating them as separate installs.

  11. Eric Wilde says:

    Jay Halderman writes:
    I can’t begin to describe the painful experiences I have had upgrading CS2 to CS3 and subsequently CS3 to CS4. In both cases, the only solution was to run the cleanscript at level 4. However, once CS sucessfully installs, the updater installs fail and also break components of the suite in the process.

    I’m sorry to hear about the pain you experienced. What you describe, for “plain old users” or retail customers, is now the exception rather than the norm. That doesn’t, however, mitigate your pain. I’ll contact you directly via email. If you’re willing, I’d like to get an engineer on the team in touch with you to figure out what went wrong.
    Given that the only way to install is to wipe all traces of CS products off my system and then, once CS products are back on my system, the update installers fail, it seems logical to conclude that the installers can be pretty bad about dealing with existing installs of Adobe’s own products. This is particularly painful when one needs to migrate Version Cue data from one suite to the other, or needs to run elements of CS3 concurrently with CS4 (incidentally, required to use the Version Cue migrate plugin).
    This should all be supported in CS4. That was the design intent and our testing showed that such coexistence does indeed generally work. Obviously something went wrong with our software when you tried to install it. As mentioned above, if you’re willing I’d like to get an engineer to help diagnose the problem so we can actually fix it.
    Expect an email soon.

  12. Eric Wilde says:

    Mark Barber writes:
    I’m a sys admin for 730 Mac users…
    Mark, I think there are two different issues inherent in your comments:
    - First, there’s how (and whether) to integrate the use of the Adobe CS4 Deployment Toolkit with ARD and other management systems such as Casper. We are actively writing improved documentation about this and also working with the third parties to establish and document best practices.
    - Second, there’s the question of whether CS4 installs break CS3 installs, especially when performed using packages built by 3rd-party management systems. We designed and tested the CS4 installers (and applications) to ensure that CS4 and CS3 can co-exist, but there are install techniques (such as snapshotting) and install sequences (such as installing CS3 over the top of CS4) which will break this compatibility. This is another area where we are actively trying to document safe practices, and also to clarify the issues with 3rd parties.
    Can you please contact me off-list? If you are willing, we would like to get your help working both of these issues.

  13. Thomas says:

    The most important part in this game right now is, that i feel that Adobe is starting really learning and cares about the user working with their products since “Dear Adobe”
    Personally, that’s the biggest step into the right direction.
    Why? Because i’m a frustrated Apple Pro Apps User and i’ve never had the feeling that Apple listened nor responded to their specific group of users that indeed nedd another treatment than their “consumer products”.
    All my faith now belongs to Adobe.
    Thanks for listening.

  14. Barry Hills says:

    Hi Thomas-
    RE: “The most important part in this game right now is, that i feel that Adobe is starting really learning and cares about the user working with their products since “Dear Adobe””
    I have the ‘Dear Adobe Top 100′ bookmarked and refer to it often.
    I run the Creative Suite and Shared Technology engineering organization and Eric’s group is a key part of that team.
    This blog and Eric’s open communications are intended to provide a more transparent avenue for discussion and getting more direct customer input on a subject there has been a lot of pain and frustration on.
    Feel free to contact me anytime if there are things you think Adobe can do better (or do well and should keep doing).
    This is an open invitation to all who read this. I welcome your input/feedback.
    Thanks,
    Barry
    bhills@adobe.com
    VP, Engineering and Program Mgmt
    Creative Suite Business Unit

  15. Kai Howells says:

    I would love Adobe to stop trying to reinvent the wheel, and use the right tool for the right job. Flash isn’t an installer.
    Whilst focussing on retail customers for the OOBE may reduce support calls, it’s the enterprise customers that are spending big $$$ on Adobe products, and they really need some love at this stage.
    We are a systems integration company, and support a large number of people in corporate environments. Part of this support is creating SOEs, which is very difficult to do with Adobe products.
    In this case, the right tool for the right job is using MSI packages for Windows and Installer Packages for Mac OS X. Yes, you need to package things up twice, but you’re offsetting this with not having to create and maintain your own installer software codebase.
    I have had one to two of my systems engineers spend a large amount of time over the past month to create Mac OS X installer packages for the Adobe suites, so we can integrate them into a package-based SOE deployment. This has been an incredibly time-consuming task and has turned up a huge number of issues we’ve had to deal with.
    Things like permissions on folders in system areas set to 777 (world writeable), or permissions set to things like 700, multiple installations of the same files (exactly the same, not just the same path and filename) and things like hidden installs of Opera (wtf!?!)
    We now have a set of installer packages for Mac OS X that install Creative Suite absolutely identically (file for file, bit for bit) to the Adobe installer. Why can’t Adobe do this? Plus, it follows the “Law of Least Surprise” people on Mac OS X expect to have software either installed as a drag-install, or through the Mac OS X Installer.

  16. Eric Wilde says:

    Kai writes:
    I would love Adobe to stop trying to reinvent the wheel, and use the right tool for the right job. Flash isn’t an installer.
    There seems to be miscommunication here. Flash isn’t an installer, you’re right. We don’t plan to use Flash to install anything. The UI would be implemented in terms of SWFs, which provides a lot more flexibility than DHTML and is a lot less costly than native OS UI.
    Whilst focussing on retail customers for the OOBE may reduce support calls, it’s the enterprise customers that are spending big $$$ on Adobe products, and they really need some love at this stage.
    Absolutely! Enterprise customers are currently one of the primary focuses for the next version of the installer technology.
    In this case, the right tool for the right job is using MSI packages for Windows and Installer Packages for Mac OS X. Yes, you need to package things up twice, but you’re offsetting this with not having to create and maintain your own installer software codebase.
    Next week’s post is intended to discuss MSI/PKG formats, their positive and negative aspects, and why they don’t satisfy our requirements for the Creative Suite. Believe me, if we didn’t have to user our own installer technology we wouldn’t. Its not fun and, as you note, its very costly to create and maintain our own.
    I have had one to two of my systems engineers spend a large amount of time over the past month to create Mac OS X installer packages for the Adobe suites, so we can integrate them into a package-based SOE deployment. This has been an incredibly time-consuming task and has turned up a huge number of issues we’ve had to deal with.

    You mentioned a few items (access privileges, Opera, multiple copies of a file) that you had to deal with. I’d love to continue the discussion and hear about the other problems you faced. We’re investigating what we can provide ourselves in this area for CS4 and anything we can learn from you would be helpful. Feel free to email me if you want to talk more about what you did and the problems you uncovered. We can also use this forum if you don’t mind sharing with the rest of the community.
    Also, did you make the your PKG installers customizable or does every seat have the same installation? That’s one of our big hurdles for PKG. Every customer, both enterprise and retail, wants something different. PKG just doesn’t provide a lot of that flexibility. There’s more around package management; but, we can get into that in the next post.
    Why can’t Adobe do this?
    Good question. As mentioned, we made a conscious decision for CS4 to focus on our retail customers with full knowledge that enterprise customers would continue to hate us. It was a difficult decision; but, I still believe it was the correct decision. We have to prioritize our work based on customer impact and revenue impact. For the next version we are trying to make a big dent in the enterprise customer workflow (though we still won’t address everything, for example preference files will still be a problem.)
    As stated above, we’re trying to see what we can do with CS4 now for enterprise customers prior to the next version shipping. There are some technical hurdles and some business hurdles. If we get to the point where we think we’ll actually be able to deliver something we’ll post about it here.

  17. Eric Wilde says:

    Jake writes:
    The updater keeps downloading and installing the same updates over and over again:
    Adobe Camera Raw 5.2 Update, Adobe Output Module Update, Flash lite 3.1 update for Adobe Device Central CS4 and Adobe Extention manager. I download, authorize (on Mac I enter my password) and it installs and says the update process is complete. But when I run the updater again, it still says I need to download these same files again!!! Will take response online. Thanks

    After touching base with customer care and looking through our bug database, it sounds like what might be happening is the update fails to correctly install but the error message apparently isn’t shown. If you want help isolate and resolve this problem then the best thing to do would be:
    (1) Download one of the updates directly from the web page. For example, the camera raw update is here:
    http://www.adobe.com/support/downloads/product.jsp?product=106&platform=Macintosh
    (2) Check the version/size info for the current camera raw framework.
    (3) Execute the update directly, without involving the Adobe Update Manager. If this has an error message then get back to me and I’ll get an engineer to work with you directly to figure out why the patch is failing.
    (4) If the update succeeds and AUM (Adobe Update Manager) is still asking you to install these updates then that is an AUM bug. In such a case I’ll get an engineer on that team to contact you and help isolate the problem so we can fix it.
    I could go on and on about updater behavior and bugs. The updater has also moved to my team just a couple of months ago and we’re avidly reading Dear Adobe and other forums about the problems people have with the updater. We have every intent to dramatically improve it in the coming months. This topic deserves its own post.
    Thanks for your help here. Much appreciated.

  18. Kai Howells says:

    Hi Eric,
    Thank you for providing this forum, and thank you for personally responding to issues raised here. This kind of direct communication with major application developers has been missing in the past and I feel that it is so much more valuable having a two-way dialogue rather than end-users filing bug-reports and hoping for the best.
    I will be very interested to read next week’s post discussing msi and pkg formats and how they fell short for you. I haven’t developed packages for Windows, so can’t comment on MSIs, but I have found that pkg installers, combined with pre and post install scripts to be incredibly flexible.
    I will gather more information from my engineers regarding the issues they faced in more detail when packaging up CS4 installs so we can deploy them with a NetBoot environment using Apple’s installer. What we do for SOE situations is have a NetBoot image that boots into a minimal finder environment and has a set of packages to deploy – everything from the base OS to third-party apps.
    I know there was a lot of logic that needed to be written so we could have one repository of packages yet have multiple options, selected in Apple’s installer, for the different flavours of CS4, as well as then further customising those installs. We needed to account for things like if you select one suite, the others are all disabled, and while a lot of the point products are identical from suite to suite, there’s the licensing information that needs to be accounted for – you can’t install, for instance, Design Premium and license it, if it’s been installed as the Master Collection, even if you only select the apps that make up Design Premium.
    In the end, we were able to have our pkg installers be quite customisable – there were the top-level choices of the actual suite to be installed, and then you can expand the disclosure triangle to select/deselect the point products in each suite. We haven’t gone as far as then being able to go into each point product and customise them individually, but I don’t think the Adobe installer allows you that granularity either (please correct me if I’m wrong!).
    This involved a significant amount of work – we’d have to have a clean system, install various suites and take a diff from before and after to work out what got installed and where, but in the end we were able to achieve an end result that was file for file and permission for permission identical to using the Adobe installer.
    I appreciate that on your part it would be a not insignificant amount of work maintaining two different installation architectures and if you needed features that were in one technology, but not the other (for instance, running a perl script as a post deployment script on Windows may be difficult, but trivial for Mac OS X) then this complicates issues further.
    Anyway, thanks again for the frank and candid approach to talking to your customers here. I’m eagerly awaiting to hear your team’s thoughts on the strengths and weaknesses of MSIs and PKGs.

  19. Mark Barber says:

    Can you please confirm the status with running CS, CS2, CS3, CS4 all on the same device ?

  20. Eric Wilde says:

    Mark Barber writes:
    Can you please confirm the status with running CS, CS2, CS3, CS4 all on the same device ?

    We only test back two releases. So CS4 coexistence was tested with CS3 and CS2. CS2, CS3 and CS4 should all be installable, licensable and executable on the same system.

  21. Kai Howells says:

    Here’s an interesting take on the whole installer affair. It’s written as quite a rant, but contains some very good points:
    http://www.bynkii.com/archives/2009/02/on_installers.html

  22. pListOFF says:

    Eric:
    Why do you (and others at Adobe) keep cowtowing to the acerbic Jon Welch?!?! Quit giving him any kind of credit. So he doesn’t like your installers, so what! He is no one yet you guys seem to be bullied by. Just do your job and do it well (I have no doubt that’s your intent) but ignore him.

  23. Jay Halderman says:

    I just wanted to let everyone know that thanks to a lot of persistant effort by Matt Laun, he and I were able to trace my update installer problems to the Adobe Installers handling of an a-typical Vista Junction Point permission (not unique or self-inflicted, but probably relatively low occurrence) Hopefully, this insight will help the installer developers handle or avoid this particular problem in future releases.

  24. RaymondRuiz says:

    I am having the worst expierience right now! I am currently trying install Adobe CS4 Dreamweaver and I keep getting a 1603 Fatal Error! Would anyone know why I am getting this error.
    I am running on a Vista Computer.

  25. ursule tolo says:

    installing

  26. Sandy Frazee says:

    Multiple CS suites on system running Tiger 10.4.11
    Running CS2, CS3 and CS4 on system for testing purposes. CS2 InDesign files show with CS3 InDesign icons, CS2 Illustrator files show with CS4 Illustrator icons. How do we correct so the version the file was created in is what appears on the icon? This is very confusing for our testers.
    thank you!

  27. Sara N.A. Suttle says:

    Eric,
    for a mainsteam product such as Adobe Design premium, I can’t believe that the engineer team is still basically trying solutions out and yet Adobe markets the product as “being tested.” I’ve had CS4 for the past three months and still been unable to install it on Win 7 system. I’m a user, not an IT; I shouldn’t be spending hours trying to figure out what a registry or a color profile is. It is already hard enough to learn to use the product and truly enjoy it, I don’t need extra work. I sincerely enjoy your product when it works, but I’m totally disappointed by the endless flaws that it still shows. The technical support is not enough; I simply move from one solution to another without really solving anything. What about an on site support? An office in main cities where I can take my hard drive and have somebody who’s really competent look into it. This would save the user time and frustration and make her a loyal and satisfied customer. Sometimes I find Adobe’s answers to users’ questions or dismay absolutely inappropriate: “Sorry folks we didn’t have this solution in place back then. We have it figured out now with CS5.” Where does this leave consumers who have not even installed the previous copy? The company really makes me feel like a faceless statistic in a report: since those who experience a problem and document it are a minority, then they don’t count. Please do something about it. We users are the reason why Adobe is in business to start with, don’t leave us stranded!!!

  28. Eric Wilde says:

    Sara,
    CS4 does generally install on Windows 7 and it is tested. I’m not sure what issues are causing these problems for you but would like to help resolve them for you. If you called tech support, can you send me a case # so that I can get any data already collected.
    I’ll send you email privately to gather more data.

  29. That is very inspirational stuff. Never known that feeling can be this diversified. Thanks for all the enthusiasm to extend such helpful information on this post.

  30. Roy Tobon says:

    It鈥檚 difficult to find experienced people on this topic, but you seem like you know what you鈥檙e talking about! Thanks

Leave a Reply

Your email address will not be published. Required fields are marked *


− 4 = five

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>