Keeping up with the Joneses 
Aug 16th, 2007
Very Important Note: At the time I wrote this, I did so without consulting anyone at Adobe about it. I did so for a couple of reasons, but mostly because I didn’t want anyone to get in trouble in the event any of my legal eagle friends at Adobe felt I shouldn’t have posted it. However, I felt this article was an important piece of Adobe design history that was better served by being out there in the world than not, so I went ahead and posted it anyway without consultation.
Since then, I’ve spoken to a few folks and found out a little bit more of how the CS3 interface overhaul came to be. While I won’t go into details, it turns out that indeed my Joneses concept sketches were an inspiration and a starting point for the CS3 design and engineering team. They took the ideas in Joneses, researched them heavily with customers, iterated on the ideas extensively and prototyped many different approaches before arriving at what you see inside CS3. I should also note that Flash picked up the approach, a mistake I’ve corrected in the article. I want to make sure I acknowledge those that made happen what I could not. I know exactly how hard their task was to make it a reality and what they went through in doing so.
So, I’d like to give a great big round of applause to: Chris Smith, Michael Ninness, Frederick Aliaga, Michael Coleman, Wilson Chan, Marianne Berkovich, Ken Moore, Elizabeth Smith, Eric Berdahl, Jesper Bache, John Fritzpatrick, Tim Beauchamp and Bill Bachman, with whom I go way back.
You guys deserve immense credit for pulling off a massive overhaul of the Adobe interface. I salute you!
- - - - -
Interface designers are limited by the constraints of technology even more so than other design disciplines at this point in time. That is to say, what is possible to design in today’s software is not nearly as far advanced as what other designers achieve in other design disciplines. Architecture and print have had hundreds of years to evolve their core design principles and the technology used to produce their work. Automobile designers are now enjoying a level of technological progress in their field that enables them to achieve amazing feats at a lower cost that still yields great design these days. That kind of progress is still evolving for those of us working in the technology sector.
Given how often I feel limited by what I’m able to do in my line of work, it was refreshing for me to install Adobe Creative Suite 3 and see that the Adobe design team finally implemented the kind of interface approach I had been wanting to do for almost ten years now. While I’m not privy to the intimate details that went into CS3, having left Adobe back in 2004 to start Involution Studios, I can give you some insight into CS3’s approach from my point of view since the interface concept is based off some early concept work I did.
Back in 1999, once InDesign 1.0 finally shipped, the first batch of the Creative Suite was considered complete by my measuring stick. I had begun the process of creating the Adobe common interface back in 1995, when I first joined the company. It was five years of the most stressful work I have ever done as an interface designer, even to this day, tapping me of pretty much everything I had. After five years and with InDesign on the market, I finally saw my work in a complete state. I had at least accomplished the main goal I set out to do.
During the months previous to that moment, I had begun exploring what could be done next. After all, at that point in time, the common interface approach I had been implementing with my design team at Adobe was already five year old thinking. Ancient in software terms. Archaic by today’s standards. I was ready to begin the next stage of the evolution of the Adobe common interface.
I had found the work that Microsoft had done in Microsoft Office 97 to be intriguing at the time. As with most work done at Microsoft, I found they had good ideas at the surface level, but had missed a lot of the small details diving deeper that really turn the corner when it comes to designing software applications. In this case, their configurable toolbars were used mostly as a means for action shortcuts, which led them to cram as many buttons on their default toolbar configurations as they could in an effort to expose more of the actions their products could perform. Further, while they had access to tear off a palette from the toolbars, they missed an opportunity to make the palettes work more dynamically from the toolbar itself without having to tear them off. More on that in a bit.
I found the concept of configurable toolbars to be a compelling interface device. Being able to shuffle controls and buttons around to allow users to create their own workspace was something we had wanted to do for a while at Adobe. Considering the enormous diversity of the user types we had for our products, configurability was always seen as a means to keep as many people as happy with the interface as possible. And configurability was always at the heart of what Kevin Johnston created when he introduced tabbed palettes in the first place to Photoshop way back in the early 1990s.
Another goal at the time for me was to go back to address something Joe Holt, one of the original Illustrator engineers, use to complain about in the work I did on the common interface strategy. He always felt there was far too much line noise and three dimensional effects, muddying the display of the products. At the time I came up with the original common interface strategy — remember, that was 1995, and I had just gotten started at Adobe — I was following the visual trends from Apple and Microsoft and was basically following what everyone else was doing. Everything needed to look beveled and chiseled. But after having gone through the common interface design process up to that point and looking back on it, I knew Joe had been right.
So given the configurability of the Microsoft Office approach and a desire to reduce interface noise, I set about creating a few concept sketches for the next stage of the common interface. One that I wanted to convince the product teams at Adobe to adopt.
Thus, the Joneses was born. (That was my personal codename for the work.)
Figure 1. A general overview of the idea behind a configurable interface for Photoshop with less line noise.
Figure 2. Palette’s would be able to be accessed from any icon placed anywhere on any toolbar by the user. This would allow people to place icons wherever they chose in order to create a unique workspace.
Figure 3. Palettes would also be allowed to be combined to give people a means to collapse similar functions to be accessed by a single icon.
Figure 4. With this new interface structure in place, a user could even configure Photoshop to have a much different layout, accessing palettes only when they needed to.
Figure 5. A quick screenshot of Photoshop in Creative Suite 3 to use as a comparison.
The first thing you’ll note is how dated the screenshots look. It was always a thorn in my side that the interface for Photoshop back in the 1990s was always limited to pixelated 1980s design aesthetics given the Photoshop engine itself could do all this amazing pixel level compositing and painting operations. But that’s part of the constraint of being an interface designer. Technology at the systems level always lags behind technology at the application level for a variety of reasons that are not worth diving into in this article. Suffice it to say that the Photoshop team had no desire to recreate the core graphics engine to work for the operating system, so we were largely at the mercy of whatever Apple and Microsoft could do at the time.
Back in 1999, while sketching out this concept, palettes had no means to “stick” temporarily on screen while being used. They were either there or not. The kind of interaction needed to make Joneses viable had not been programmed to my knowledge. In order for that to happen, you had to have what I termed a semi-modal state; something that was modal and self-contained like a dialog box, but did not lock out the user from the rest of the interface or require an explicit click of an OK or CANCEL button to dismiss. With this approach, the user clicks an icon, the palette pops open and sticks, the user interacts with it while keeping the palette on the screen. As long as the user clicks and tabs inside the palette itself, the palette would remain on the screen. Only when the user clicks off the palette or hits the RETURN or ESC keys would the palette disappear.
When I pressed the Photoshop team back in 1999 to add this new type of interaction behavior, they balked. Part of the reason why is simple: most Adobe products have very heavy and intricate keyboard interactions. Learning how to use Photoshop is a lot like learning how to play the guitar. How people use their hands with the keyboard and mouse creates a certain feel, and they learn to use it in ways where their behavioral patterns become unique to their means of interacting with it. To introduce this new semi-modal state would require going into the code to rework all of application’s core interface pieces, something that was very risky. If not done properly, the whole approach could break one of the core foundations the product gained it’s reputation on.
In the end, I couldn’t convince enough people at the time to take the risk or invest in the kind of resources that would be needed for a Joneses type of interface overhaul for Photoshop, which I was hoping to use to push the rest of the Creative Suite as well. As such, I decided to leave Adobe back in 1999 with the core pieces of the common interface completed and implemented. I took some time trying my hand at Internet companies during the late stages of the dot.com boom, only to get convinced to come back to Adobe by Mark Hamburg to get Adobe Lightroom off the ground in 2002. (Who am I kidding? I didn’t need a whole heckuva of a lot of arm twisting. Getting a chance to work with an engineer as smart as Hamburg on any project is a no brainer.)
But I did enough pushing to convince the team to let one of Photoshop’s long time über-engineers, Seetha Narayanan, create the code to allow this new semi-modal interaction method to work. To try out the new behavior and see how it felt in real usage, the Photoshop team isolated the semi-modal concept into what became the Palette Well and the pop-up slider controls in version 6.0. While it appears the Creative Suite 3 approach uses an entirely different code base from what existed only in Photoshop to execute on the new interface approach, the end result appears to be what I was looking for back with the Joneses.
The concept of the Joneses and what you see in Creative Suite 3 is basically the same: create the ability for people to configure their interface in a way they prefer to work, while giving them quick access to other features at an iconic level if so desired. Although I have to say I’m disappointed that Creative Suite 3 falls short of letting me arrange icons for palette access horizontally as shown in my Joneses concept sketches, but that’s a minor nit. As far as I can tell, that’s the only thing missing functionally between what I was aiming for back then and what finally shipped this year.
What I most loved about the approach back then is something that I can now finally experience in CS3. The maximized screen state where the palettes exist on the screen and force the canvas to never go behind or cover up the palettes. Yet, the palette wells can be resized while adjusting the palettes themselves to one’s liking, forcing the canvas to never intrude on the palette screen real estate. I find this method of working alone to be worth the entire upgrade to CS3.
So, some things take time I guess. It’s just part of the life being an interface designer so early in the field’s technical evolution. But in the end, it warms my heart to see the concepts from the Joneses implemented in Creative Suite 3. I’m especially happy to be able to use it since I’m now on the other side of the wall.
Now I guess someone over at Adobe needs to get the Dreamweaver and Fireworks teams on the ball and do the same thing.
