December 28, 2005

Not my type

Ask most people what Illustrator is used for and a likely response will be "for making logos". While I have my own issues with that kind of reply (some people think AI is ONLY good for logos), I certainly do find myself creating logos all of the time. Like just a few minutes ago actually.

Having started my career as a typesetter, I'm pretty confident in my ability to spot typefaces and have committed most styles to memory. However, when setting a word of type and wanting to quickly see what that word looks like when set in a variety of different faces, I find myself creating tens of copies of my text and then going through the process of changing the typefaces for them all. A tedious process indeed.

Photoshop has this wonderful feature where if you set some type and then place your cursor in the Font field in the Tool Options bar, you can simply press the up and down arrows to switch typefaces. In this manner, I can simply tap tap tap tap with the arrow keys to preview my text in a variety of different font faces. It's wonderful. I wish I could do this in Illustrator.

Now I've found a new use for Photoshop -- finding a typeface for my logo -- then I copy and paste it into AI and finalize it :)


Newmango said...

You know it's a must-have feature when you find yourself trying to make something work in an application where it doesn't exist. Another Photoshop feature that I covet for Illustrator is the ability to access dynamic sliders for every value field by dragging on the word or symbol in front of the field.

Teri Pettit said...

Mordy, can you delete that last entry? I accidentally hit enter when I was reaching for the shift key.

As I was saying ....

On the other hand, there are some Illustrator features that I've been wanting for years and years in Photoshop, and never seem to get because they aren't splashy enough to get marketing focus. Like Scale and Rotate tools that would let you control the transformation by mousing down at any arbitrary point, instead of only at the edges of the selection bounding box.

I do a lot of stitching together of multiple images (since I put online a bunch of pages from large format books and magazines that are too big for my scanner bed), and often I want to rotate an entire 9 inch by 12 inch layer at 300 dpi by a very small amount when zoomed in to 800% or 1200% or more, to make tiny details like serifs of individual letterforms (or even flecks of dust!) coincide correctly. It works best to translate so that the details at one side of the image coincide, put the pin point in one of those details that is exactly right, move way over to the other edge of the picture, and rotate the whole layer so that the details at the other edge coincide. But at the true edges of the selection, either no details are visible because it is the page margins, or they are distorted by bending of the magazine spine, so you don't want to use them for reference. You want to use details that are about 2 inches in from the edge.

So I have to scroll to the edge where I can get the rotate control, rotate a tiny smidgen, scroll back to where my reference details are, see if it worked, and if not, scroll back to the edge again. And 2 inches at 300 dpi at 800% zoom is a lot of scrolling. With an Illustrator-style Rotate tool, I could just mouse down on any pixel I wanted to move, and drag it to the matching pixel on the other layer.

Mordy Golding said...

I agree Teri. In truth, such features abound. For example...

...I wish that Illustrator's Appearance palette had some of the nuances of Photoshop's Layer Styles (with eyes to turn effects off, etc.).

...I wish that Illustrator had InDesign's Package command.

...I wish that InDesign had the ability to define a key object when aligning objects (like Illustrator can).

...I wish that Illustrator had an "indent to here" feature like InDesign has.

:) Mordy

Phosphor said...

I know I'm not the only one, then, who has wondered why some of these most obvious feature disparities between applications in the Suite exist?

It's pretty easy to understand the main reasons why it is that not every feature is available in every application—application bloat, and the bean counter's desire to sell more than one application, to name two. But in those instances where it would make cross-application workflow more intuitive (such as having Photoshop's "arrow-keying through font lists to preview" available in Illustrator), I've yet to hear any reasonable explanation why the disparity exists.

I've never heard any good explanation about why there seems to be such a lack of communication between, for example—the Photoshop Team and the Illustrator Team.

Mordy and'd be terrific if you two might take the opportunity to use this venue to shed some light on this frustrating conundrum. Go ahead and go all geek and technical if you want to. We can handle it!

Cheers! (and thanks for cranking up your blog, Mordy!)


Mordy Golding said...

Teri would best be able to answer this from a technical standpoint (although stepping around the issue of discussing proprietary Adobe technology is no small feat), but I can certainly offer my own personal views from a marketing standpoint.

This is something that is actually discussed often at Adobe, and John Nack of the Photoshop team has some strong feelings about this as well, and I think that he's spoken about it on his blog as well.

Also, before I get to my explanation, I want to state that there is great communication between the product teams at adobe -- from both a marketing and an engineering standpoint. Especially so with the AI and PS teams, who are on the 11th and 10th floor of the same building. Engineers share ideas and concepts, but at the end of the day, each application focuses on what is best for its case.

Application teams are free to develop their own features because they are intimately aware of what their customers need. And products are always in a state of development. If the Photoshop team comes up with a cool idea, they might be able to implement it because they think it's important for their user base, but the InDesign team might think that such functionality makes sense to Photoshop users, but not ID users. Or AI users might like the feature, but feel that it's not as important as another feature that they are working on, and so it falls lower on the priority list and ends up getting cut.

By the way Phosphor, the two reasons you state -- bean counting and app bloat -- are rarely true if at all. App bloat is more of an excuse not to add a feature, but Adobe finds a way to add features all the time, so that isn't an issue. And as for bean counting, Adobe seems more focused on selling the Creative Suite rather than individual apps these days.

Teri Pettit said...

Mordy has it right. There is really no intentional trying to keep features out of one application to make people buy more Adobe apps. And Illustrator and Photoshop engineers communicate pretty well. Chris Cox from the Photoshop team talks with the Illustrator engineers almost daily. (And about algorithms, not just chit-chat.)

The biggest factor that causes feature disparity is just the incremental, evolutionary nature of application development.

Most of Adobe's major applications started a long time ago, from separate code bases. We've been gradually bringing them closer together, but there is a very long way to go. And coding new features isn't easy. There is a whole lot of work between a concept, and a working feature.

When adding a new feature, there are several ways this work could happen:

1. (Best case) The applications share some code library for doing common functions, and the new feature can be put within that common code.

2. (Second best, but uncommon) The feature has "loose connections" to the rest of the code, so it can be developed first within one, and then fairly easily ported into the other. Maybe easily enough to happen within the same release cycle.

3. (Worst for feature commonality, yet by far the most common situation when dealing with applications that have long histories and separate origins) Implementing the feature requires intricate connections with the host application that make porting it to another application non-trivial. Like rewiring a 100 year old wood Victorian for electricity involves different problems from rewiring a three hundred year old stone castle for electricity, even if the lighting looks similar when you're done. So the idea can either get "thought up" once, and coded independently in both applications targeted at the same release cycle, or it can get coded first in one application, and then recoded in another application at a later release cycle. For complex features, the latter is more common. It is unlikely both teams will have the resources to work on the feature in parallel, and there is some advantage in letting one group explore the ramifications first. Even with those two very different old buildings, it would still work better if electrical wiring hadn't been invented yet to figure out how to do it in one building first, than it would to try to go directly from concept to implementation in parallel on both buildings.

So, for example, by now all of Adobe's major applications are using the same code library for translating vectors and fonts to rasters. So any improvements in anti-aliasing algorithms, say, can get coded once, and automatically picked up by all the applications.

But each application still has its own dialog manager. So any new ideas in palette manipulation have to first get coded in one application, then duplicated into the others. Which makes palette features more disparate than printing features are.

The only way that "bean counting" comes into play (and it does to a certain extent) is that the need to ship regular upgrades, on schedule, or risk the ire of Wall Street, and the need to have identifiable new features that get you stars in the magazine reviews, means that there is limited opportunity for assigning engineers to non-flashy work like reworking the foundations to use more shared libraries. Which is not to say that it doesn't happen; it does. All of Adobe's major applications now use the same font management code (code named CoolType), which once was not the case. They all use the same PDF printing engine, which once was not the case. So they will probably some day all use the same palette management code, and share other facilities they don't yet. But it won't happen quickly.

There are always many many more features that each team would like to put into each release than they have the resources to do. Mordy can confirm that each release usually starts out with literally hundreds of candidate features, that get whittled down to about a tenth of that number before coding starts on them. Some of the line items that make the cut are usually cross-product feature parity items, but so are some of them that get cut. This is just natural, since they have to compete with performance enhancements and new product-specific features. When Adobe cuts a potential feature from the list, it doesn't mean they think it's a bad idea. Just that they can't do everything at once.

Phosphor said...

Thanks, Mordy and Teri, for shedding some light on the development process. Teri: The 3 pathways to new features is something I kind of knew instinctually, but it was nice to see you flesh them out the way you have.

Still, even knowing what the stumbling blocks may be, sometimes it's difficult for us end users to understand why certain features aren't implemented. I think most of us understand—if only superficially—where the bean counters find their motivations. Wall Street, bottom line for shareholders, bombastic new features, yada, yada, yada is all well and good, but as I'm sure you're quite well aware, there are some things —reasonable and utilitarian features and improvements— that have been requested for years. We're not talking time-machine stuff here, but items well considered by many dedicated, thoughtful, professional and realistic users.

For instance, it would be kind of nice to know why there isn't parity between Illustrator and Photoshop in the way arrow-key font update/preview works. This is one of those things that many of us would find immensely useful, on a daily basis. Surely, by now, the means to implement Photoshop's method for this into Illustrator is not a herculean task, when compared to some of the other process- or coding-intensive new features that have been added over the past couple versions. Granted, it doesn't have the flashy panache as something like the highly marketable LiveTrace feature, but I can almost hear the distant roar of cheers arising from the hordes of people who have been wishing for it for so long.

Going in the other direction—and touching on something I've been yammering about for years: Why are Photoshop's guidelines capabilities so evolutionarily retarded when compared to Illustrator's? Mr. Cox had finally responded to me a couple of months ago—in his inimitably terse fashion—by saying that upgrading the guidelines features in Photoshop is a lot more difficult than people realize. What he left out of his explanation—and what you have so helpfully explained, Teri—are some possible reasons why the improvements would be so difficult to implement. I can understand him not feeling like taking the time to trot out those details—spending time explaining why to masses of people who either don't care or who wouldn't understand the reasons. Your explanations at least had some palliative effect, and go a long way toward placating those of us who desire more than a "Because doing that would be difficult" -type of dismissal.

These are just two things off the top of my head, and I'll leave it at that. I'm sure the esteemed Mssrs. Talmage and Newman could add many more items to the list of utilitarian features that have been neglected for too long. I suppose my point is that it's these little things that regular users have to deal with every day that really make an application show its mettle in the trenches, and which demonstrate that the engineering teams are paying attention to what users are clamoring for. All the little things that get taken for granted. All the little changes that people would like to see in the next version. Sure, some of the things being requested might only be useful in rare instances, and I can understand why these would be excised when the feature winnowing process is taking place.

On the other hand, there are some improvements that could—and should— be made that no amount of "this is how the upgrade process works" revelations can explain away. As end-users, we really don't G.A.S. about Wall Street, or shareholders or coding difficulty. When it really comes down to it—and I'll say again that I really appreciate your time and that I understand them, but— the explanations about what must be taken into consideration don't matter to users. NOT ONE BIT. What we want is for the application to do some of those non-spectacular things we ask it to do. We don't need time machines (though I can think of many reasons why I'd be happy to pay the $169 upgrade price to have one!). We want some attention paid to some of the little things that will make our lives—and our attitudes about the company that makes the tools we love— a little rosier.

This isn't just a wholesale rant about how things could be better. Anybody could cook up a few noisy paragraphs like that regarding any product or service we might choose to focus upon. (Some of us even consider it a minor hobby! ;o) ) It should be pretty obvious by now that many of us—myself most certainly included—really enjoy the products. It's evident by how long we've been participating on the Forums, and it's evident that those of us who are at times a little loud only act that way because we really, truly want to see the tools we use become as good as they possibly could be—not just for ourselves, but for every other user who face the same challenges using them.

My best regards for your willingness to participate in the dialogue, and Cheers!

Teri Pettit said...


To specifically answer your question about arrow key navigation in the Font field, that functionality was in fact slated for CS2, as a "do if time permits" subtask of the Control Palette feature. There were several other tasks in that category, such as making the Align buttons work on direct-selected anchor points. Any improvements in the behavior of buttons or commands that already existed on other palettes, and were planned to be incorporated into the Control Palette, got put into that bucket. But before work could begin on that category of tasks, the basic required functionality of the Control Palette had to be brought up to shipping quality.

Now, the Control Palette is a lot more complex than it appears on the surface. It seems like one little palette that just does a lot of stuff that already existed elsewhere. No big deal, right? But its contents and layout are much more sensitive to the selection than any other palette ever has been. And it required interactions between subsystems that were not originally designed to interact. The palette as a whole, its layout and the way it responds to selection changes, are implemented by the Control Palette plugin. But the actual commands and buttons that live on it are implemented by a whole slew of different plugins. The Paint Style plugin manages the Fill and Stroke fields, the Live Trace plugin implements the Trace buttons, the Align Palette plugin implements the alignment buttons, the Transform Palette plugin implements the transformation fields, etc. Illustrator's plugin architecture originally allowed plugins to implement their own palettes, their own tools, or their own menu commands. Those were the only places plugins had "hooks" into the user interface. It did not allow one plugin to install controls on a palette whose overall layout and event management was handled by a different plugin. Adding the architecture to support that level of communication between plugins took more time and introduced more bugs than was originally expected. So the time near the end of the release cycle that the responsible engineer would ideally have spent implementing the "do if time" cleanup features was instead spent fixing the bugs in the interactions between program modules.

And frankly, that didn't really get done to shipping quality. Several rather noticeable bugs had to be deferred for lack of time, especially with text selections. I don't know if you're using CS2 yet (you're pretty well known for sticking with older versions), but even if you aren't, you may have seen the forum comments about how the some of the values displayed in the controls tend to lag one edit behind the actual settings of the selection. If we had two more weeks of coding time before shipping, they would have been spent fixing those synchronization bugs, not working on the "do if time" items. If we had another month of coding time, some of the planned cleanup items would have got done, but probably not more than half of them. If we had three more months of coding time, they might have all got in.

So, to address the anticipated response of, "Well, take that damn time, then!! The users would much rather have a fully polished release three, six or even ten months late, instead of a half-baked one that ships on the predicted schedule! Geesh!"

I don't know an engineer or tester or customer support tech who wouldn't agree whole heartedly with that sentiment. For one thing, many of us are heavy users of the products too, even outside our jobs. (I may be one of the first vector drawing app users in the world. I had sample art in the Griffin User Guide published in 1979. Google on "Griffin Xerox Maureen Stone".) So we experience the workflow frustrations too. And even those of us who don't use Illustrator outside of testing our own code still take pride in our work, and cringe to see something ship that we don't feel we're done with. We probably feel the same way you would if you were forced to deliver a half-finished design to a client.

But unfortunately, we live in a real world, and there are circumstances we can't change, no matter how much we might wish to. Users may not give a shit what Wall Street thinks, but a company that lets its stock fall doesn't just stagnate, it dies!! It gets bought up by some other company whose stock is doing better. And how does it help the end users if that happens?

In an ideal world, stock markets wouldn't be so extremely sensitive to short-term profit growth and to predictability, but that's the way they are. A publicly traded company has to have increasing profits every quarter, and even more critically, it has to be able to reliably predict those profits. You have to be able to tell the market analysts how much you expect to make each quarter of the upcoming year, and to do that, you have to know when you expect to ship each product, and how many copies you expect to sell. You can't delay shipment of a major product. When it gets close to the wire, you start making everyone work 80 hour weeks. You cut unfinished features, and if the deadline arrives and you still have bugs, you cut quality. Delaying shipment enough to significantly impact the revenue timing isn't even an option. We might wish it were, but it's as futile as wanting a genie to pop out of a lamp and magically fix all the bugs. It ain't gonna happen. Any company that tries it gets creamed.

The only thing that you have control over is just trying not to bite off more than you can chew in the first place. Which means whittling your 400 feature long wish list (it really is that long) down to 30 to 50 line items. Which means that it takes a lot more release cycles to get a significant fraction of the feature requests implemented than users would wish. They don't get forgotten, though. It took many releases before we had a WYSIWIG font menu, but it eventually happened.

(Sorry to dominate your blog this way, Mordy.)

Newmango said...

I understand why having more time to make things perfect may not be an option, but couldn't there be another option besides more time? Wouldn't bringing in a few more coders seem like a relatively small investment in the grand scheme of things?

Mordy Golding said...

As always, Teri is correct -- and to answer your question directly Gary, there's a lot more that happens behind the scenes.

Teri, I'm thrilled that you posted such a great and detailed reply, and you and I both know enough about how all of this works to make it difficult to talk about it -- not only from an NDA standpoint, but I'm sure also from a personal standpoint because when you work for a large company and decisions are rendered, they don't always mesh with your own personal views.

At first, I thought that I would blog about my own feelings on this, but in reality, this is something that might be better "hidden" within comments somewhere :)

There's ALOT more that happens, and above all, you simply HAVE to realize that in the end, this is a business. But more than that, Illustrator is a TREMENDOUSLY complex application. When I first joined Adobe, I can assure you that I had a master plan to change the world and make Illustrator into the best thing ever. Then I started learning how things really work, and that's when a whole new understanding dawned upon me.

Some of that understanding, I can share here. Hopefully, this will also give you at least some insight into the madness. After you read this, I'm sure you'll share my own feelings in that it's nothing short of a miracle that ANY version of Illustrator (or any software for that matter), is released.

You can do the math on your own, but Illustrator has what's called a product life cycle, which takes a specific amount of time (basically, the time between releases). This amount of time is split up into different milestones -- some of which you are probably familiar with, like alpha, beta, etc.

The actual amount of time that features are actually written in code (i.e, developed) is a smaller percentage of that life cycle than you might think. Even though you might have a specified number of months between releases, you can't use all of those months to develop features. In fact, before the features are actually written, they are carefully defined. Engineers (like Teri) write detailed feature specifications at which time you try to anticipate all possible ways that a feature will interact with the program. The engineers work closely with User Interface designers and Product Managers (like I used to be) in order to get a better idea for how the feature will look, and more importantly, what the feature is required to do. A product manager will likely draw up a list of features that are "must have" and a list that are "nice to have". For example, when we were working on the 3D feature, we specified that the feature must have the ability to work on text. An example of a "nice to have" feature was the ability to do artwork mapping, etc. Each of these "sub features" are carefully organized into lists and engineers state how much time it will take to develop each of these. Throughout the cycle, this list is constantly evaluated. Sometimes, a product manager might realize that a certain feature is taking up too much time and decides to cut it. Of course, a product manager never wants to cut any features at all. And people like myself were notorious for adding as many line items as possible, but the last thing you want to do is miss a product milestone, because the repercussions can be severe, as you'll hear about soon.

Once the features are defined, they are developed, or written into the code. And then the madness happens. They are tested. If I remember correctly, for every engineer on the Illustrator team, there are 2.5 "quality engineers" -- or people who's job it is to make sure the feature works as intended -- without breaking anything else in the program as well (remember that Illustrator is 20 years old and contains over 5 million lines of code -- thing of writing code for Illustrator as one huge game of Jenga). Testing, by far, is the single largest chunk of the product lifecycle.

I'll never forget the day one of Illustrator's senior engineering managers called me into his office. I had learned a very dangerous thing you see -- something called "feature creep". I had a way of persuading an engineer to add "just one more thing" to a feature. I'd start by getting my foot in the door by saying, "hey, this is broken, we need to fix it" and so an engineer would fix it -- and I'd see that it really only took an hour or so to fix it. And so I'd say "hey, that was easy -- you know people would LOVE if you could add one more thing..." The problem that I didn't realize was just how much of a risk I was adding to the project. What if that little thing broke something bigger? And because of that, I was forced to drop another feature that I really liked? But that's the small part of it. It goes way beyond that.

Illustrator's User Guide is published simultaneoulsy with the release (obviously). So in order for that to happen, it has to be written while the program is still being developed. Usually, the people who write these user guides get their info from the detailed feature specifications that are written early on -- but oh so much can change as the product develops and it becomes increasingly difficult to keep the user guide folks up to date with everything that's going on. Suddenly, it's no wonder that the product user guide isn't always that helpful -- they barely have enough time to get it out at all. In fact, one of the reasons why Adobe has been pushing to go with digitial user guides instead of printed ones (like with the Creative Suite), isn't to save money -- but more so that they have more time to work on it. There was once a version of GoLive that was actually held up because the user guide got to the printer too late.

Then I was introduced to localization. Illustrator is "published" in 13 different languages worldwide. Once the English version is done, the program is translated (called localized) and this also presents a problem. The later you "lock down" the English version, the later your other worldwide releases come out. And if you make what might seem like a small tiny change late in the cycle, that may mean a delay of weeks or even months for foreign language versions.

There's alot more that I'm not going to talk about here, but I think you can get the picture. In reality, a single cycle of Illustrator is made up of a certain amount of new features, a certain amount of bug fixes, and a whole lot of amount of testing.

So a valid question was asked -- why not just hire more people? What's a few extra salaries to a company like Adobe? I WISH it were that simple. Again, there are many many many things that come into play, but again, here are a few things to chew on. Teri and other Illustrator engineers are intimitely familiar with Illustrator's code -- I'd even go so far as saying they are familiar with the code that they work on -- but they may not have any idea about a different part of the code. Hiring someone to work on a feature means teaching that person about the nuances of the code and it may take longer to train someone new. Also, Adobe is a profitable company and a very well managed company (if you believe all of the Wall Street talk) for a reason. Having worked there, I can tell you it's true. They are very careful about how many people work in each department, and each team is allocated a certain amount, etc. At this point, you can blame the bean counters, because the Illustrator team is told what they can and can't have with regards to budget and resources (people).

Of course, every team asks for more resources for each release, and they have to "sell" their reasons for those needs. And even then, one it's decided, that's what you live with. And these kinds of things aren't changed mid-cycle. So if you realize you are behind in a release, there's more of a chance that you'll be asked to drop a feature in order to make your release date, than get an extra hand to help out.

As Teri mentioned, these reasons alone are what force you to think very carefully before a release about what new features will get added, and you'll want to keep that list at a risk level that you're comfortable with. Adobe has a tremendous amount of experience and the people who work there know what they are doing (for the most part anyway). They can usually tell well in advance if you've put too much on your plate -- and you'll thank them later for that experience.

Anyway, I've already said too much... but I hope it has shed some light into the mechanics of what goes on behind the scenes. Can Adobe do more? Sure it can! Can it do better? Of course! There's always room for improvement -- and our help as users, make a difference (more about that in a different blog)...

Newmango said...

Excellent post, Mordy. Of course I knew any answer could not be as simple as - "We'll just hire a few more engineers."

Here's another question to which you probalby don't know the answer, but perhaps you'd care to guess? With Adobe's acquisition of Macromedia, there must be a boatload of Postscript engineers who are pretty expert at doing the same types of things that Illustrator's engineers do. Now they work for Adobe. Or do they? Are Freehand engineers likely to be integrated into the Illustrator team?

Mordy Golding said...

You're right, in that I don't know the answer -- but I can certainly offer educated guesses.

First of all -- a "postscript" programmer has nothing to do with anything. Besides the fact that Illustrator now uses PDF as its native file format, Illustrator itself is written in C++ -- at least I think so -- Teri can confirm or deny.

Secondly, I was under the impression that "FreeHand" programmers are few and far in between -- when Flash became the big thing, and Macromedia set their sights on Flash technology, much of FreeHand was left to wallow. By the time the merger was complete, I'm not sure how many FreeHand specific engineers there are left (if any).

Finally, and this sort of circles back to my previous post -- all of Illustrator's code isn't necessarily done by Illustrator engineers. Adobe maintains shared libraries or components (like parts of PDF, the print engine, the text engine, etc.) which Adobe calls "core components"... there are teams that works on such features and Illustrator and InDesign pick them up. The transparency flattener is such an example. I say it circles back to my previous post because there are some features which are almost "out of Illustrator's hands" and decisions made on those features need buy-in from all of the other products -- a process that could take weeks.