Creative Selection: Inside Apple's Design Process During the Golden Age of Steve Jobs

by Ken Kocienda

Once found, we tuned this proxy code to function the ...

how Steve prepared for these big-splash product announcements.

Three weeks or a month before the keynote itself, Steve would start rehearsing with portions of his slide deck in some venue at Apple,

Slowly, day by day, he would build the show by stepping through it as he wanted to p...

This was one of Steve’s great secrets of success as a presenter. He practiced. A lot. He went over and over the material until he had the p...

When Steve spoke to a slide, he went fully into his keynote persona. His tone of voice, his stance, his gestures, everything was exactly as if he were presenting to a packed house. For as long as everything proceeded to his satisfaction, he kept going.

Sometimes he did this three or four times, each time with an absolutely clear separation between attempts, like takes on a movie set. He never truly bungled a line—his presentation was already polished by this point—but he was committed to making every slide and every phrase better if he could.

Some may have thought that touting Safari performance was just marketing, a retrospective cherry-picking of one browser attribute that just happened to turn out well.

I knew better. I had been part of the team that had received the speed mandate months earlier, and I had participated in the actions he now described which ensured the speed of our browser.

Such connections of words to actions can be meaningful, and in our case they were, since the words led to the actions we used to make our product. This clear connection of words to act...

In any complex effort, communicating a well-articulated vision for what you’re trying to do is the starting point for figuring out how to do it.

And though coming up with such a vision is difficult, it’s unquestionably more difficult to complete the entire circuit, to come up with an idea, a plan to realize the idea, and then actualize the plan at a high standard, all without getting bogged down, changing direction entirely, or failing outright.

Perhaps the most unnerving and fear-inducing source of anxiety is that your ideas, words, and resulting vision might not be any good to start with and wouldn’t yield...

a significant part of attaining excellence in any field is closing the gap between the accidental and intentional, to achieve not just a something or even an everything

but a specific and well-chosen thing, to take words and turn them into a vision, and then use the vision to spur the actions that create the results.

our Mac email program couldn’t edit or reply to these web-based messages.

we could use WebKit, the core of our new browser code, to improve the email experience on the Mac. The technical challenge was that, as computer users, we browse the web. Other than filling out forms, as on ecommerce sites, we don’t edit web pages while we read them.

we were reaping the dividends of our investment in Safari and WebKit, since now we could decide for ourselves about the new web technology features we wanted in future Mac products.

Web page editing for email was just such a technology.

directly responsible individual

the person who has to do whatever is necessary to develop a piece of hardware or software, some technology, some critically needed thing—the DRI was the person with their butt on the line.

Since this email composer wasn’t a web browser, it couldn’t interpret web pages properly.

I had to swap out the simple email composer from Apple Mail, install WebKit in its place,

and make the change without anyone noticing.

Before starting on this project, I had never thought much about the insertion point

I was finding out that this familiar feature belied the underlying complexity of word processors and the subtle behaviors they exhibit.

My insertion point woes were the worst kind of bugs a coder can have, since the bad behavior didn’t always recur if I backed up and took the same steps again.

“heisenbugs.”

In HTML, it’s not always easy to tell the markup from the content.

Data and metadata are mixed.

I spent months trying to develop a way to disentangle content from markup, and as time passed, I became increasingly frustrated that I couldn’t solve the problem.

When it came time to discuss a solution, they told me that I should clean up my code.

It represented an important technical insight:

When software behavior is mysterious, get more organized.

My insertion point code needed to be as businesslike as a baker looking at a properly filled out order form to determine th...

I had succeeded in getting my colleagues invested in my insertion point behavior work, not just by asking for their help in a single meeting and saying thanks when it was finished but by demonstrating through my ongoing actions in code changes, demo reviews, and lunchtime chats that their advice had mattered to me.

Getting the insertion point to behave correctly wasn’t just my project anymore. It was now our project.

People matter more than programming.

This may sound trite, but many coders find it easier to get along with computers than colleagues, and there’s a tendency in Silicon Valley to view every question as having a technological answer.

not all Apple projects were created equal.

I knew immediately that “customer-facing” was Kurt’s euphemism for “important,” at least from his perspective in the marketing department.

This viewpoint counts for more than you might think. Apple is customer-focused. The company always sought to give people convincing reasons to buy its products.

If the marketing department wasn’t interested in telling ...

then the feature was something Apple felt it needed to do, not necessarily something that it wanted to ...

“Unsigning up” just wasn’t done.

Impressive as it was, the software Bas showed me wasn’t a firm base for long-term development, since there was no direct engineering path from a Director demo to a shippable product. We would need a software infrastructure built on a hardcore programming language like C++ or Objective-C,

For Purple, I had to adapt my editing code to a hardware platform that didn’t have a mouse and a physical keyboard, but experimenting with touchscreen text editing felt like blazing new trails, and I was happy to do it.

Even when demos went well, there was always a steady flow of feedback, suggestions for changes, impressions on how the software might behave differently.

Everyone spoke up. Demos were an open forum for exchanging ideas about how an interaction might look or function better.

When demos went poorly, as sometimes happened, there was the same stream of comments a...