April 15, 2007

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.

18 comments:

Anonymous said...

Wow. Thnaks for actually explaining that stuff.
As civilains, we sometimes think, "Adobe is Huge. What do they mean there's not enough recources?" And while Adobe really should hire more people, at least your cross-app examples make sence.
Johnny Nack should have had you post this months ago for him (we weren't allowed a beta preview of Illustrator so all we have is PS for the CS3 example app).

Rene said...

Thanks for the post. I think very few people stop to realize how much work goes into creating Adobe Apps. Like any company/product, I'm sure there is plenty room for improvement.

But I have no doubt that Adobe apps are coded mostly by extremely passionate and talented engineers. You can't fake quality, and compared to other software products out there, there is just no comparison.

Gary Spedding, Ph.D. said...

I agree with the two comments here.
Being a non-designer myself (just a player/tinkerer for fun with Adobe products), I have said before that I am blown away every single day with what I learn of the capabilities of these programs. It is truly amazing considering that only 25 years ago I was learning about "state-of-the art" computers with punch cards and ticker tape!

So if I have any complaints whatsoever it would be for Adobe to slow down the release of new versions and give us all a chance to actually learn all that the existing ones offer. Let Adobe see what third party groups come up with (then incorporate the best ones) and give a couple years of comments from existing users to let them know how to make the next version the ultimate version. Aftall, right now, we might be thinking that the existing version IS THE penultimate one.

Also, instead of hiring many more new technical folks, pay for the third-party plug-in developers for their efforts and incorporate their work into new software instead of (presumably) reinventing the software wheels all over again!.

Unknown said...

jimhere - thanks man. Yeah, Nack and I come from similar backgrounds. He reads my blog almost as often as I read his... so I'm sure he'll appreciate it.

rene - I'm sure the folks who work at Adobe appreciate your comments. It's certainly true that they are all passionate about what they do, and they are all proud of their work.

gary - your point is well taken. I agree that it seems that technology moves much faster than we think it needs to. That's the business side where money and shareholders and stock analysts add yet another dimension to all of this. David Pogue has often spoke of this "problem".

As a final note, to really get an idea of just how much resources goes into an Adobe product, try viewing the names of all of the people involved. When you launch an Adobe app, the splash screen used to contain the names of all of the team members. Photoshop still does. But with Illustrator, we decided that the Illustrator team alone wasn't the only people responsible for the product. While the Illustrator-specific team has a team of about 70 or so individuals, there are hundreds of others who support and work on the product as well.

Once Illustrator is loaded, choose About Illustrator and watch the names scroll across the screen. On a Mac, you can press and hold the Option key to make the scrolling list move faster.

Anonymous said...

Mordy, in that thread where you wrote "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", I never did respond further, mostly because your answer was pretty good.

Rather than a "better technical reason", I would like to offer a non-technical analogy that may make it easier to understand.

Using a shared code library, like we now do for printing, font handling, previewing, and many other things, is sort of like a housing contractor getting their bricks and electrical components and plumbing fixtures from a supplier. They don't have to have a brick maker and a lighting fixture maker and a toilet maker all in their crew. The more components you can get from outside, the less you have to do yourself, so the job goes faster.

There are several instructive things to observe from this analogy:

1. Not everything is suitable for getting from the outside. It tends to work best for small components that can be pulled together in many different ways without losing too much flexibility in your design. As you go to larger and more complex components, you lose some architectural freedom. There are lots of jobs for which you still need a custom cabinet maker or artisan window maker instead of prefab cabinets or windows.

2. A palette, in itself, is just a place to display information and collect requests for changes to them. In the housing analogy, it isn't so much like a component acquired from a supplier, it is more like a form the contractor may give you you to fill out what kind of job you want done. Many contractors may use a standardized form, but filling out the form isn't a big part of what goes on to get the job done, so having a standardized form vs making up their own doesn't buy them much. And two clients filling out the same information on the form doesn't mean that it will be anywhere near possible for the contractor to go through the same steps in fulfilling the two requests.

To the extent that palettes can be shared components, it is typically at the piecemeal level. Shared palette component libraries allow individual applications to not have to do things like build their own code to support sliders, popup menus and other widgets. The UI changes in CS3 apps do use a lot of components from a new shared library. (I don't remember what the O in OWL stands for, but the WL is Widget Library.) But the individual applications still need to interpret what the values they pull out of the palettes MEAN.

3. It takes a LOT more work to retrofit an existing architecture to use standard components than it takes to build them in in the first place. In 2000 I bought a large house built in 1911. It took six months and about 90K just to bring the plumbing, wiring, heating and earthquake safety up to code, and there were no visible changes from it!

In software, often a comparable decision will be made to take the hit of retrofitting to a shared library in one release to enable easier upgrades and more powerful features in the next. But it is by no means a small job. Just as in upgrading an old house, you spend a whole lot of time and money on something that outside observers may not see any immediate benefit to at all.

This last point is the most relevant to the the immediate question of Separations Preview. Architecturally, Separations Preview actually IS a good candidate for using a shared engine. It is in many ways similar to "print to screen", and we now use a shared print engine. But in the same way that switching to a print architecture based on PDF took a VERY large effort spread across AI 9 and AI 10, without significantly changing the print output itself, it is a big job to retrofit all the "hooks" for separations preview into an existing program.

The palette itself just collects the options and makes a little box for the preview to be drawn into. The palette is the easy part. Getting all the individual objects to be capable of doing something like displaying only one of their color channels instead of compositing all of them requires adding additional smarts to every single object type, and additional options to every single function that passes display requests down the chain.

Trust us, if it was easy, it would have been done.

Unknown said...

Thanks for the additional explanation Teri! The construction analogy works very well here.

Anonymous said...

A fascinating article Mordy.

But were you aware that Google posted an Ad. for a pirate software site immediately above your article?!

>Free Adobe Illustrator CS
Want a free Adobe Illustrator CS? Offer Expires Today!
Download Illustrator CS3
Download anything you want - no time limits, no bandwidth limits, no content limits. Download anything you want anytime you want. We provide you access to the fastest and most reliable file-trading network online.>

Anonymous said...

Great write up, Mordy. I've struggled with explaining these same issues to Flash customers for years.

One other item worth mentioning has to do with those who say, "Why doesn't Adobe just hire more engineers?"

Besides the obvious answer of "operating expense" vs. "revenue" there's a more technical limitation that I've heard best articulated this way:

"Nine women can't make a baby in one month."

The reality is that adding more engineers doesn't necessarily give you more features.

Thanks,
Mike Downey | mdowney@adobe.com

Unknown said...

Mordy

Love it, great post.

Software is fun, but it ain't easy to write.



Nick Hodge, Professional Geek
Microsoft (and avid Adobe software user!)

Anonymous said...

As a former Apple engineer whose hatred of ProjectBuilder/XCode led to a complete lack of interest in developing for the platform for many years (and eventual firing), I must say that I am very genuinely impressed that anyone was able to port those gargantuan CodeWarrior projects over this quickly. That is truly a commendable achievement and I cringe at the thought of how much boring, tedious work was involved.

However, as an Adobe user of 15 years, I am not so impressed by the fact that we are all asked to shell out thousands of dollars every year or two for what basically amounts to bug fixes. I understand the logistics and politics involved in both running and working for a very large software vendor with tons of legacy code no one has even looked at in decades, but I also know I'm not the only one who feels that the company is growing more and more detached from its user base with every bloat-filled year. When you say that you don't have very many engineers on staff who are familiar with printing and pre-press issues it does not elicit sympathy so much as make me wonder what exactly your HR department is getting paid to do instead of actively recruiting such engineers. Yes, the web is there, and it's very important, and I'm sure somebody is really anxious to see some ROI on that whole Macromedia buyout, but seriously, this is Illustrator--it needs engineers who aren't familiar with print issues like a sushi restaurant needs a saucier. If finding them is really that difficult, then train the ones you can find. A week long internship at a local print shop would do wonders.

It's all very unfortunate how much work and money one has to pour into aging structures just to get them up to modern standards, but buying an antiquated house is a personal choice. What choice do professional Adobe users have since they've bought up all the competition? I know there's a ton of hard work involved in bringing new features to the world, but there's also a ton of six figure salaries being funded by our wallets that allow Adobe engineers the luxury of pouring 90K/yr into their little pet projects, and I think it would behoove the company as a whole to take a minute to remember who it is that keeps them in business. It isn't bloggers and it isn't the SEC.

I can make do with previewing separations in Acrobat myself, but Adobe seems to be in the business of manufacturing more excuses than quality software these days, and the fact that the online bug reporting form has been routing all input to a non-existent email address lately doesn't do much to console me nor does it encourage me to invest in every update.

Unknown said...

Ann -- thanks for the comments and for pointing out the issue about the Ad. I will have to look into that.

Mike -- great to see you here (I'm humbled). The baby analogy is wonderful as well.

Nick -- LTNS! Thanks for the compliment!

khiltd -- All valid points. My post wasn't meant to justify Adobe's behavior, rather to create some perspective by explaining some of what goes on. Obviously, the post would have been a LOT longer had I gone into more details.

In fact, I've been toying with the idea for quite some time (ever since I left Adobe) on writing a full book on the entire process (from start to finish) on how an App comes to life. For some reason I always thought such a book would only interest engineers, but maybe after seeing the response to this post, it might interest others as well...

Anonymous said...

khiltd,
Re: "When you say that you don't have very many engineers on staff who are familiar with printing and pre-press issues it does not elicit sympathy so much as make me wonder what exactly your HR department is getting paid to do instead of actively recruiting such engineers.

.. but seriously, this is Illustrator--it needs engineers who aren't familiar with print issues like a sushi restaurant needs a saucier. If finding them is really that difficult, then train the ones you can find. A week long internship at a local print shop would do wonders."


I didn't say "familiar with", I said "experienced in." And understanding the needs of the users is different than understanding the relevant code. Mordy has worked a lot more than a week in a print shop, and I doubt he could write software for it.

Not everyone has background experience in the same areas. Does every engineer at Apple have prior experience in every kind of program that Apple works on?

Adobe, as a company, has plenty of engineers who are experienced with printing and pre-press architectures. Not very many of them are on the Illustrator team per se, because most of the printing code is inside shared libraries.

The fraction of the Illustrator code base that is related to printing is, in fact, relatively small. It is more like a very large multi-ethnic restaurant. There is no need for every chef to have background as a sushi chef and a saucier and a wine steward and a pastry chef, even if several of each is needed in the kitchen.

It makes sense to allocate engineers where their skills are best utilized. I daresay Apple is more likely to assign their engineers with a background in optimizing compilers to the XCode team than to the iTunes team.

If it were determined that the best use of the engineers with background in printing software were to transfer some of them to the Illustrator team, it would be done. Adobe has very good procedures in place for moving engineers between teams, sometimes temporarily.

Regarding Mike Downey's quote that "Nine women can't make a baby in one month", from which he infers that adding more engineers doesn't necessarily give you more features, I think a more appropriate conclusion would be that adding more engineers doesn't shorten the release cycle. (It's more likely to lengthen it.) But a man with twenty wives does have more children. The question is, can he support them all?

For the most part, adding more engineers to the team would enable more features. But it would also require hiring more testers, more technical writers, more customer support personnel, more translators, etc., to deal with a larger feature load. And would those additional features bring in enough additional sales, over and above what you would have got without them, to justify all those additional expenses? It doesn't make fiduciary sense to spend beyond the point of diminishing returns.

I'm not involved in resource allocation, but I assume the upper level managers who decide the budgets have data to support the decisions they make.

If you asked the engineers, most of them would like to approximately double the size of the Illustrator team (not just engineers but across the board), and extend the product release cycle to three years. The marketing managers would probably prefer it too. And most users would. But if the company tried it, it would have a very negative effect on the stock price during the time when costs were growing, while income was dropping due to no new releases.

Re: "I think it would behoove the company as a whole to take a minute to remember who it is that keeps them in business. It isn't bloggers and it isn't the SEC."

I agree that it is extremely frustrating, both for users and engineers, how much we are constrained by the demands of the stock market for ever-growing earnings and clockwork release schedules. But that's the reality of the world we live in.

While the SEC does not keep companies in business (it is more tasked with keeping them honest), in a very real sense the stockholders do.
Any company that ignores the impact of decisions on the stock price tends to die, rather quickly, and then where are the users and employees left?

In the long run, meeting the needs of users does have a positive impact on the stock price, since it increases sales. But it can only do that so far. There's a point at which adding more features will make users happier, but not more likely to buy, since they would have already had enough to make the upgrade worthwhile and beat whatever the competition is offering.

(BTW, if "allow Adobe engineers the luxury pouring 90K/yr into their little pet projects" is meant to refer to my house, I don't spend nearly that on it "per year", and bringing one's home up to code so that it can be lived in safely is not usually referred to as a "little pet project." My little pet projects are my paper dolls and genealogy. :-) )

http://tpettit.best.vwh.net/

Josh Tynjala said...

khiltd said, "...and the fact that the online bug reporting form has been routing all input to a non-existent email address lately doesn't do much to console me nor does it encourage me to invest in every update."

I can assure you that the bug reporting form works just fine. I've communicated with Adobe QA folks on more than one occasion in the last few months after I've submitted a bug or feature request. However, it should be noted that you won't always receive a response. In general, they'll probably only contact you if they need clarification. I'm sure they get hundreds of reports or requests a day.

Anonymous said...

Just implement the features I want first. That should simplify matters.

Yes, it is all about me.

Anonymous said...

Ah, John, I love it when you lighten up these long analogy-filled discussions.

Remember this one: "So...if I go to plant a tree, find a black box while digging a hole and curse in french for the extra work in removing it, a police officer will give me a ticket unless I claim I really am planting a shrub in old english and offer to strip down to show my backwards compatibility so the officer can converse about it back at the station?

Good thing this was all cleared up."

mefull said...

Great post and very interesting comments.
I just discovered your blog - great job and thanks for all the behind the scenes stuff.
The real world of software development is not quite as idealistic as all of us end users might like to think.

As a long time Freehand user I guess it's time I got up to speed on Illustrator, I can read the writing on the wall. Although I have always owned a current copy of illustrator, I rarely used it unless I had to. I have never found it easy or intuitive to use. Rather clunky actually. Still some things it does very well and I sure don't want to go back to my t-square and rapidographs :-)

I understand that a whole lot of resources had to be diverted to port the code to the new OS's
Lets hope Apple is done making those kinds of changes for a while.

Still I wonder about the strategy of releasing the software as a suite. It seems to me to be a marketing driven decision that will slow down the innovation and feature development of each individual program. The need to release a new suite all at once appears to mean that the release cycle may be 2 or 3 years between versions? That’s a long time to wait for a feature that didn’t quite make the list.

My memory may be a little fuzzy, but I seem to remember a new release of Freehand and Illustrator about every 10 to 14 months. Each one trying to out do the other. I for one am sad to see the competition get swallowed up.

Anonymous said...

Mordy said, "In fact, I've been toying with the idea for quite some time (ever since I left Adobe) on writing a full book on the entire process (from start to finish) on how an App comes to life. For some reason I always thought such a book would only interest engineers, but maybe after seeing the response to this post, it might interest others as well..."

From an all-too vivid memory of being heavily involved in the development of a vector design program some years back (I'm no coder myself), you could simply paraphrase it to be:

"The story of sweat, blood and tears."

I, for one would buy the book. But I fear that my wife would soon say something about my nodding in a sagely manner, mutterings and laughter as the truth cuts too deep ;-)

Go for it!

Nick

Anonymous said...

"Remember this one:…"

Yes, that was a fun thread. : )