Twenty Years in the Valley
Two trains leave from a station…
I’ve been designing software professionally for 25 years, since at least two years before Bill Clinton became the 42nd President of these United States of America — the first time.
I dropped out of college in 1990 to become one the first five founding members of a company making consumer level graphics products for the Macintosh: Specular International, the company behind Infini-D, Collage, Texturescape, Backburner, and Logomotion. Back in 1990, dropping out of college to join a software company was not cool, working on computers was not cool, and if you ever told anyone that what you did was Interface Design or User Experience Design, they gave you a look as if you were from Mars.
So my point of view on designing software will likely differ from a lot of people you know.
The simplistic version for me is this:
For the first half of my career, I’ve had to argue, debate, and cajole all the people I’ve worked with that I wasn’t just the guy who drew the pretty icons. For the last half of my career, I’ve had to remind everyone I’ve worked with that I actually like to draw the pretty icons!
I say this because whenever I talk, write, or speak about the subject of designing digital products, I invariably run into someone — often some expert who has been designing digital experiences since at least 2005— who thinks I speak in mutually exclusive terms when I talk about what designers need to do to have a career in digital design.
If you want to be any good at this job and make a career out of it, you’ll need to master a lot of skills. These include learning how to draw with pen and paper, create eye-catching production graphics in Photoshop or Sketch, understand color and type theory, create a taxonomy, empathize with and be a champion for customers, understand how to do field research, communicate design strategy with executives, dive deep into prototyping, learn how to code, and be a total snob when it comes to coffee. And of course, Mr. Expert, this list is not exhaustive. I’m trying my best to avoid scaring all the young folks who might want to get into this business by keeping the requirements for this inherently multidisciplinary job artificially limited.
I want to make sure that anyone reading this doesn’t assume that I think understanding customers is somehow a lesser aspect of the job. Of course customers matter! They pay your salary, so shun them at your own risk. However, it’s also true that you’ll run into problems that require little to no need to ask the user anything. The design solution you have to come up with will be purely technical in nature. It won’t matter if it’s right or wrong, good or bad, just or unjust. It’ll just be.
This story occurs about a couple of months into the work I was doing on Photoshop 4.0. I can’t recall the exact time frame, but it was in the early development part of the project, so likely late in 1995.
I had proposed a design for using transformation tools in Photoshop that mimicked page layout products like PageMaker or XPress to Mark Hamburg. At the time, Mark was the most senior engineer on the Photoshop team outside of Thomas Knoll. Mark is also one of the best mathematicians in the country. He understands math like Prince understands music — at an entirely different intellectual level than mere mortals like you or I. When you engage Mark about any interface that involved mathematics, and pixel manipulation algorithms are about as math heavy as it gets, you better know what you’re talking about.
It was a simple design, one that basically put the standard transform tools in the tool palette, with X & Y coordinates, width & height values, and skew & rotate values in a brand new Info Palette that sat just under the menubar. The idea was to allow the user to enter transform values to their hearts content to move, resize, rotate, and skew layers around as if they were simple objects. This is exactly what customers wanted to do with pixel layers in Photoshop. It’s the epitome of user centered design!
If I recall, Mark’s reaction to my design was simply, “That’s fucking stupid.”
(Author’s Note: I’d like to think that’s what Mark said, because if you’ve ever heard Mark speak, it’s exactly the kind of thing he might say to rile you up. It’s more likely he said something like “That won’t work.” But that sounds bland and utterly boring for a story like this.)
Mark is quite literally one of the smartest engineers I’ve ever worked with so when he said this to me, I was more than a little bit upset. I was crushed.
I asked, “Why?”
Mark replied, “Doing it this way would allow people to resample pixels multiple times too easily, degrading each pixel value over multiple transformations to create a muddled mess.”
Basically, my design proposal was similar to allowing someone to record an audio track to tape, then re-record from that tape, and then re-record from that second tape. In essence, I had proposed a design that made it too easy to suffer from generation loss. Each time the user entered a value and hit tab or enter on the keyboard, they would apply a transformation that changed the value of the pixels in that layer. An info palette would make it very easy to do this quickly and in succession with multiple entries, degrading the value of each pixel with each interaction.
The quality of pixel math is one of the secrets to Photoshop’s longevity as an application. My design proposal would have torpedoed that.
To his credit, Mark spent a good deal of time explaining to me why the design would result in something that likely wasn’t good for the product nor the customer. Once I understood, I asked him, “How do we solve it then? Transforms feel like something we should be able to do easier than how we’re doing it now.”
Mark paused. “I’m working from home tomorrow. Why don’t you come over and we’ll work through it.”
The next day, I drove over Highway 17 to work on the problem with Mark. Like many engineers at the time, he lived over the Santa Cruz mountains away from the Bay Area, working from home once or twice a week. Working from home for most engineers in this business isn’t a luxury, by they way. It’s more of a neccessity to be able to get anything done. When Mark was in the office, he was often interrupted by people like me bugging him with questions about some small detail that could be answered via email, or today with a Google search.
When I got to his house, we got to work. How do we allow users to perform transformations in one pass, with one pixel calculation? To be clear, we had to figure out how to make these tranforms work:
Move, Resize, Rotate, Skew, Distort and Perspective
So, here’s another thing you’ll need to learn how to do if you want to become a designer making digital products.
You’ll need to learn how to solve puzzles.
Mark tossed out the parameters. We have a mouse and keyboard. The mouse has one button we can rely on, and the keyboard has three modifier keys we can use — Command, Shift, and Option. We also have mouseDown and mouseUp events, where dragging can be distinct from a simple click.
We worked that problem for the entire day. And we solved it that same day.
The solution is something that lives in the product today: Free Transform. We came up with the Free Transform solution like you would solve any puzzle. We made a matrix of possibilities of how we could make all of the transformations work with the constraints. We talked through the various scenarios and the solution presented itself. Because of the nature of generation loss, the first part of the solution came easy. We had to make sure people were in a modal state. In doing so we’d have a better shot at keeping them from performing multiple transforms excessively.
The user would have to invoke Free Transform as a command, and then Photoshop would be in a new modal state whereby the mouse and keyboard behaved specifically, scoped to that modal state. The selected layer would get the traditional eight point bounding box familiar from other object oriented drawing programs.
We also decided to use the conventional keyboard shortcuts popular with Macintosh drawing products of the late 80s and early 90s when possible. For example, during a drag the Shift key would mean “constrain,” and the Option key would mean “mirror action” where applicable. The Command key was open to interpretation at the time.
As Gene Kranz would say, we worked the problem.
The solution to the puzzle became:
Move: Drag the mouse any direction after clicking inside the bounding box. Shift constrains dragging. Option clicking moved the transform origin point.
Resize: Drag any of the eight anchors points of the bounding box. Shift constrained rotation. Holding Option mirrored the operation.
Rotate: Click and drag anywhere outside of the bounding box. Without putting Photoshop into a modal state, this would be impossible to do. Shift drag constrained to 15 degree increments.
Distort: The Command key comes into play here. Click and drag with the Command key to distort the layer. Option mirrors.
Skew: While more common than Distort, we only were able to figure this out once we assigned Command to Distort. Simply put, Shift+Command constrains distortion from any side, creating a Skew.
Perspective: Combine Distort from a corner edge, with Option to mirror, and Shift to constraint and you get a perspective effect.
You enter Free Transform, perform multiple actions as you see fit, then hit the Enter key. The moment you do that, all of the transformations are collapsed into one pixel calculation, ensuring one level of generation loss no matter how many transforms you performed during it.
I’m not going to argue to the merits of this interface for users. Clearly, understanding the logic of Free Transform requires some form of RTFM, having someone teach you the shortcuts, using the menu commands, or otherwise stumbling upon the logic on your own. There are plenty of solutions to core features like object transformations over the years that are more clear, more obvious, or more learnable. A true heads up display style version of this interface could be implemented to make it both clear how Free Transform works, and easy to use repetitively in the product. As a sidenote, for all the praise young designers give new modern tools like Sketch, transformations are just as obtuse in that product as anything built in the 90s, in my opinion.
That’s not the point though. Improving the interface for Free Transform can be done in any number of meaningful ways. That not much has been done says more about Adobe’s priorities on Photoshop over the years than it does about a feature that is now 20 years old.
The point is that it still works on a computer using a mouse and keyboard.
Why?
Because Free Transform is a solution to a puzzle. A solution that follows logic embedded entirely in the context of it’s input model: the mouse and keyboard. Once the input model changes, the solution changes. This is clear to anyone trying to implement transformations in creative tools for touch devices. They require a different solution.
The main point of this story is simple. As part of your job as a designer on digital products, you’ll need to solve puzzles. If you don’t like puzzles, there’s a better than good chance you’re not going to enjoy this job.
Can Free Transform be done better? Absolutely.
Can it be done by purely asking your customers what they want? Absolutely not.
Can it be done by figuring out what they need to do, mixed in with the context of what technology allows, and how that technology can help them work?
You might be on to something.
