How Illustrator gets its features

First, a disclaimer -- this post is a long one. I think it's important to read though, as it offers an insight into how large programs such as Illustrator get their new features. This post is actually more of a compilation of comments from a thread on Adobe's User to User forum.

It all started in late March right about the time that Illustrator CS3 was announced, when someone queried whether or not Illustrator CS3 featured a new Separation Preview palette (which both Acrobat and InDesign have). The request for a separation preview palette in Illustrator has been around for quite some time, and there are several plugins that offer the functionality as well.

Teri Pettit, a developer on the Illustrator team, kindly provided an explanation, mentioning a variety of reasons, including how each team at Adobe is assigned a certain amount of resources.

It was a great explanation from Teri on some of the challenges faced by the Adobe Illustrator team, especially considering how wide a variety of Illustrator users there are in the world.

A response to Teri's explanation presented a valid point -- concerning the apparent limited resources statement...

I understand that Adobe has limited resources. However, Illustrator is the oldest of Adobe's products and has one of the highest user bases of all the products, with maybe Photoshop being the only product that has more users. I'm glad that certain "features" were added to CS3, but limited resources should be no reason not to fix all of the broken features that are currently residing in Illustrator. Also, I'm sure n-channel image support is important, but there is also no excuse for Acrobat, InDesign and Photoshop all getting a Seps Preview before Illustrator when it's the oldest product. Besides maybe Multiple Pages, Seps Preview is probably the second most desired feature, at least among packaging prepress departments.

As a past product manager of Illustrator, I'm quite aware of the process of how features are added to products, and I actually responded to this question, with the following:

First, DeviceN (or NChannel) is a color space. Where the RGB model consists of 3 specific color channels (Red, Green, Blue), and where CMYK consists of 4 specific color channels (Cyan, Magenta, Yellow, Black), the DeviceN color space allows for any number of color channels greater than 1. Hexachrome is a good example of what you might use DeviceN for. Hexachrome was developed because there are many colors that fall outside the gamut of what CMYK can support. Therefore, by taking CMYK and adding two additional colors (Orange and Green), you can achieve MANY more colors. DeviceN, which allows for multiple color channels, can be used to store the 6 color channels required for Hexachrome. But DeviceN can also be used for individual spot channel files, 5 color files, 3 color files, etc.

It sounds like you're in the packaging prepress field, where multiple spot colors are heavily relied upon. This support in Illustrator will enable more workflows in that area.

Secondly, on the topic of limited resources and features, there really is a lot more that you have to take into consideration. I think that Teri provided some great information on trying to provide features for everyone, but there are so many things that you have to think about when planning features, your head can explode. I know, because I was once the product manager for Illustrator.

It's a business.

You have x amount of dollars to spend and x amount of time to develop a new version. Your goal is release a version that will be successful (meaning that it will sell well). So you write up a list of features that groups of users will want. Right away, Illustrator is unique in that category. Illustrator users fall into many categories -- including traditional print, web, video, and mobile areas. Single out traditional print and immediately you realize just how complex that one segment alone is. For example, a package designer may care very much about spot colors, trapping, and the like, while a fine artist or illustrator could care less about those things and value things like brushes and finer point control. With the exception of Photoshop, I don't think any other product at Adobe has this wide a range of markets to address. And to give you just an inkling of how big this challenge is, it's the driving force behind Adobe's decision to create an Extended version of Photoshop. It can certainly be argued that the same should be done for Illustrator.

So you get your feature list all put together, and you find out how much effort each feature takes to implement. For example, some features that seem simple may require a lot of architecture or development under the hood. Even more so, an engineer can build something "quick and dirty" and get it done faster, but an engineer can also take more time to build something that will be scalable or easier to manage over many years. In fact, there are many features found in Illustrator where some level of work was started in one version, but users didn't even see the functionality until a version or two later. Some features that you might like to add could also require that certain groundwork be laid before you can add your feature on top of it.

Then you add in all of the outside forces. Like Apple's move to Intel. That isn't something Adobe planned, but was required to do. Same with Vista support. There are many outside forces, which often fall out of the control of a product team. If you're a product manager, you suddenly realize that a feature you wanted to add has to be dropped in order to address those outside forces.

At some point, you look at a feature and put a dollar amount on it. And you're forced to decide, is the expense of building this feature worth its investment at this time? I wasn't involved in the release of CS3 at all, so the scenario I'm about to play out didn't happen (at least, not to my knowledge). BUT, had I been the PM, and these issues were brought before me, I would have taken the following course of action:

Team: Mordy, we see you've listed that you want us to build separation preview and also add deviceN support -- both equally important to the prepress market. But the Mac Intel and Windows Vista work is turning out to be more than we've anticipated. We need to drop one or the other -- what do you want us to do?

Mordy: Hmmm... we really do want both of those features. But in reality, there ARE currently plugins available for Illustrator that will do separation preview. And users can also use InDesign or Acrobat as well. Not elegant maybe, but doable. But DeviceN will enable prepress users to do things that simply could not do before at all, and can't do even with a plugin. Ok, let's drop separation preview from CS3 and go with DeviceN. Oh, but one more thing...

Team: Yes?

Mordy: When doing the DeviceN work, is there anything we can do internally that will enable us to implement separation preview more efficiently in a future version?

Team: We can definitely look into that and implement what we can.

While this is one example, I think you get the big picture. No one said you have to agree with any of Adobe's decisions, but I can certainly say that there is ALOT of discussion that goes on during development, and it's all well thought out and debated. Often.

After my response, another question was posted with regards to the issue of dot releases...

I do have one question though (well a series). I have posted about it in other forums. Developers used to release point upgrades (Photoshop 5.5 anyone? Quark 3.3) etc. What reasons do you see that this is no longer the case? I understand that free .5 upgrades to an app "don't make money", but is there any internal technical reasons why this couldn't be done? For our topic here, if someone worked on the seperation preview and got it done in 3 months, could it be added to a, let's say Illustrator 13.1 upgrade? If some other lingering 'bug' issues could be fixed plus a small requested feature added, does mgt allow it to be released? Or do they want to keep all significant features held until a new pay-for version can be released, even if the next version is more than a year away, just to build up a huge "new things" list?

These were good and valid questions, to which I offered the following response:

There are two issues at hand here when it comes to dot releases.

First, there are the lawyers and accountants. I don't profess to understand how money works or how things get accounted for, but I do know that there are certain rules in place. Some of those rules are set by the government or outside agencies (like the SEC for example), and some of those rules are set by the companies themselves.

Adobe is not allowed to ship what could be defined as a "new feature" for a paid-for product for free. There is something called revenue recognition and the way that monies are accounted for. Meaning that if Adobe would ship CS3 and make money on it in April, and then release an update which added a new feature like sep preview later that year in September for example, that feature had already been paid for in April, and so Adobe -- even though they are distributing the update for free -- would be backcharged towards the revenue they accepted in April. Basically, Adobe would be charged for fraud because they had charged you for a product you paid for in April, but Adobe didn't deliver it until September. So Adobe basically took your money but didn't give you anything in return. They "recognized" revenue or reported to their shareholders that they made money without having made the sale yet. It would be like Adobe is telling their shareholders that they sold lots of copies of software, without having actually sold anything. Again, it's a legal accounting thing. There is an allowance for "bug fixes" so Adobe is allowed to fix broken features that already exist. They just can't add new ones.

But even if we left the legal issues aside for a moment, there's a good reason why you don't see dot releases as often from Adobe these days. With the advent of the suite, we as users appreciate much of what Adobe has been able to do -- which is to make the products more consistent. Be it the user interface, the print engine, the PDF libraries, color management, etc -- there are just so many pieces that have to fit together.

I like to describe a computer program as large as Illustrator (approximately 5 million lines of code) as one huge game of Jenga. If you fix a bug in one place, you never really know what effect that might have somewhere else. And some features rely heavily on other features, so a small change in one place can have an adverse effect in many other places. Engineers, when asked to fix a bug, will usually provide a marketing person a risk involved in doing the fix. For example, I may ask Teri to fix a bug and she'll tell me, based on where that bug exists in the code, that it's a "safe" fix. Meaning little chance of something else going wrong. But there are also plenty of times where even a small fix could have a very high risk factor. And a product manager is forced to decide if it's worth fixing that bug if the result could mean a far more serious consequence.

Take all of that, and go one step further. Between all of the Adobe Creative Suite applications (remember to add all of the new Macromedia apps too now), there are over 80 million lines of code. To make things more efficient and more consistent, Adobe shares many code libraries across the suite. Meaning that Illustrator and InDesign for example, share the same print engine. Now what if I fixed a bug because there was something wrong in Illustrator, and that ended up breaking something in InDesign? Can you even imagine how complex that is when you start realizing there are so many other Adobe apps that can have the same issue?

In reality, what it all comes down to is testing. For the most part, an engineer can put together a feature or a bug fix rather easily. But then you have to test ALL of the areas that may have been affected, to make sure you didn't break anything else in the process of fixing the bug. Not only do you have to test AI, you have to test any other app that also shares that code. So what might take one day to fix, may take weeks or more to test.

Now imagine each product would be making dot releases. And each product would be testing against other products, which themselves would be testing their own fixes. The end result would be that you've dedicated your entire team to doing a small dot release, and by the time you'd start working on the next version, you'd be years late. If I remember, I once calculated that the dot release for Illustrator 9 (which was necessary) ended up costing the AI team 6 months of the Illustrator 10 schedule.

In any regard, you really have to understand what a miracle it is that Adobe is able to ship a working version of Illustrator -- let alone 3 entire suites of products that all work.

A final question was then asked, with regards to features implemented across applications:

Honing in on your info about master code libraries, I've asked before why couldn't Illustrator just "pick-up" the Separations Preview palette from InDesign? If both programs are "sharing" print engines, could they not "share" a simple palette as well? When I've posted this point before, some people in this group just gnarled back "those two programs can't share code, they're completely different, grrr!". I know that each program has it's own specific tags and what not, but you pretty much just said that they do share chunks of code.

And my response was as follows:

Teri could give you a far better technical reason for why you can't simply pick up a palette from one app and bring it into another, but I will offer the following two points:

- The underlying architecture for each app can be very different. The way a feature is implemented in one app isn't necessarily the way it is implemented in another. A palette (or any feature for that matter) is simply a feature on its own -- an island if you will. You must hook that up to the app's core functionality. Case in point. Illustrator has an OpenType palette. It's cool. InDesign doesn't have one. Why can't InDesign just pick up AI's palette? Well, if you think that the OpenType palette in AI is hooked up to AI's text engine, then you have to completely rewire it to work with ID's text engine. Thinking about the sep preview palette in ID -- that's hooked up to InDesign's way of displaying art - and maybe it isn't the same as it is in AI? I don't know -- I'm just making the point that there's a lot of depth and things going on that you don't see at first glance.

- While it's all good to have shared code libraries, the overall effect is that they inhibit innovation. If you've ever tried to make a decision by committee, you know what I mean. If AI, ID, PS, Acrobat, and Flash all shared code -- then each team would have to approve any new functionality. So if the AI team decided to add something that their user base has been requesting for many years, Flash could say, our users don't care much for that -- and we'd prefer another fix that's more important to us. The result would be that over several versions, there would be great consistency, but no innovation and little improvement. Overall, we hope for a happy medium where the teams can retain their individuality, continue to innovate, and also be able to share consistency across the suite.

Hopefully this information gives you some kind of an idea of what it's like to build an application. The concepts and ideas mentioned in this thread also apply to applications like Photoshop, InDesign, Flash, etc. I'm not saying that everyone has to have the same view and agree with Adobe's logic in every case. But some people seem to think that Adobe arbitrarily adds features and doesn't ask customers what they want -- and nothing could be further from the truth. Adobe does a tremendous amount of research for each version of each application, and spends a TON of time working on each version. No one claims perfection, and there's always room for more improvement, there's no question about that. But the people at Adobe do take their jobs seriously, and I think they do their jobs quite well.