October 23, 2021

Book Notes

Creative Selection by Ken Kocienda | Book Notes

1 – The Demo

  • As commonplace as virtual keyboards have become, in those days, the norm for smartphones was the BlackBerry, with its built-in hardware keyboard, its plastic chiclet keys, and its tactile thumb-typing. In contrast, the iPhone keyboard would offer tiny virtual keys that gave no feedback you could feel with your fingers.
  • Nobody at Apple wanted a repeat of the Newton, the handheld personal digital assistant the company marketed in the 1990s. Unreliable handwriting recognition gave the Newton a public relations black eye that never faded; the product never sold well, in large part due to its lackluster text entry; and the Newton never became the mass-market indispensable item it was intended to be.
  • Purple, the project code name for the in-development iPhone,
  • I never demoed my keyboard to Steve while our Purple smartphone was in development—someone higher up in the organization had always done it for me. The success of the iPhone keyboard had, apparently, enhanced my standing. My managers didn’t come right out and say so, but their invitation to meet with Steve, coming as it did only after I had proven myself by delivering iPhone autocorrection, showed me what it took to get direct access to the company’s famous CEO.
  • Whenever Steve reviewed a demo, he would say, often with highly detailed specificity, what he wanted to happen next. “Add more space between these two elements,” or “Replace the green in this graphic with blue,” or “None of this is working. Show me more options next time.”
  • Diplomacy was about thirty feet long and fifteen wide, drab and windowless. A couch in the middle of the room faced the door, roughly dividing the space into two squares. A pair of eight-foot-long tables were pushed against the walls in the half of the room closer to the door.
  • Diplomacy was a study in indifference. It was an important room, often used for CEO demos, but it was never the center of attention itself.
  • Scott’s position was not nearly as precarious. His relationship with Steve was solid, and their partnership extended back to their time at NeXT, the computer company Steve founded after being fired from Apple in 1985. Ever since Apple acquired NeXT in 1996, Steve and Scott had collaborated closely on software.
  • Steve valued Scott’s ability to imagine how new technologies might be integrated into our software products. Scott excelled at making these connections. If a programmer told Scott about an in-the-works software change to the touchscreen system that would make it possible to reliably differentiate between quick swiping gestures and slower panning gestures, Scott could visualize a user feature like swiping on an item in a list, say an email message, to delete
  • Greg Christie, one of his other senior managers, the day-to-day leader of the Human Interface team, the software designers responsible for the look and feel of iOS and the Mac, as well as the concepts behind how these systems functioned.
  • as the HI team leader, Greg brought breadth and depth to the design of our apps and user interfaces.
  • Bas Ording, a designer on the HI team. Bas possessed genius-level skills in illustration, animation, and demo creation, and his deftness contributed much to the intuitive feel of iOS devices.
  • Bas created inertial scrolling, the system of finger swiping that speeds up as you scroll repeatedly, glides to a rest when you stop touching the screen, and pleasantly bounces at the end of the list.
  • few years earlier, Bas and I had collaborated on the design for the iPhone keyboard, and we’d struggled mightily with the constraints of the phone’s small screen size.
  • In our final design, we made punctuation and numbers available under a separate layout accessible by tapping a .?123 key.
  • We worried there would be howls and complaints about the inconvenience of this arrangement, but it turned out to be one of those things that people adapted to readily and accepted without much fuss.
  • I thought that people would like typing periods and commas without having to tap the .?123 key.
  • As I glanced back and forth repeatedly between my prototype iPad screen and the hardware keyboard connected to my Mac, I had an idea. I picked up the iPad, turned it to landscape, and held it up over the Mac keyboard. I noticed that the long side of the iPad screen was about the same width as the top row of letters on the Mac keyboard. It occurred to me that I could take the ten letters from this top keyboard row, QWERTYUIOP, and fit them across the width of the iPad screen. There wouldn’t be room for number keys above the top row of letters, but that might be all right, since it would result in a design like the iPhone in terms of key layout, but on the larger iPad display, the keys would be almost as big as those on a Mac laptop. This was in contrast to Bas’s approach, which was to scale down the full Mac keyboard layout to the size of the iPad display.
  • Now I had two interesting ideas. My concept would offer bigger keys that would be easier to tap, but users would have to hunt around for numbers and punctuation. Bas’s design with more keys would make numbers and punctuation easier to find, but each key would be smaller so they all fit on the display. I decided to make a demo so I could try out both.
  • I had been responsible for the day-to-day maintenance of the keyboard code until just a few weeks earlier, when I got promoted, so I still knew the software like the back of my hand. I could write the code for two new keyboards in a couple days. I’d add one for the Bas layout with more keys and one for my layout with bigger keys. Building the demo in this way conferred a huge benefit. Unlike the Director demo Bas had shown me, which was just pictures and animations, my demo would be a fully functioning keyboard that would work in any iOS app.
  • When you tapped the zoom button on our iPad demo, the keyboard you were looking at (say, mine) transitioned to the other one (his),
  • When you tapped on the zoom button, it made you feel like one keyboard was becoming the other.
  • Some people might like a layout with more keys, since they had an intuitive feel for where all the letters, numbers, and punctuation keys were located. Others might like the layout with bigger keys, since they had a tactile sense for where the keys were located under their fingers. It was the best of both worlds. The zoom key made it easy and pleasant to try both of these two new keyboards and switch between them—there was no need to dig through some preference setting elsewhere in the system—and Bas’s animation made the feature seem special.
  • “Well, I’ve been using these demos for the past few days, and I’ve started to like the keyboard layout with the bigger keys. I think I could learn to touch type on it, and I think other people could too. Autocorrection has been a big help.”
  • Then he announced the demo verdict. “OK. We’ll go with the bigger keys.”
  • Demos served as the primary means to turn ideas into software.
  • In our case, Steve saw something he liked, but he found the demo unnecessarily complicated, so he unpacked it. This deconstruction wasn’t typical, but it was completely in character.
  • This push for simplicity had a purpose. Even though he was a high-tech CEO, Steve could put himself in the shoes of customers, people who cared nothing for the ins and outs of the software industry. He never wanted Apple software to overload people, especially when they might already be stretched by the bustle of their everyday lives.
  • He believed that stripping away nonessential features made products easier for people to learn from the start and easier to use over time.
  • Steve used demo reviews to judge for himself whether features met this basic usability standard.
  • When he gave me the specific feedback to remove one of the two keyboards from my iPad demo, it had a cascade effect toward greater simplicity. It meant we could also take out the Bas zoom animation. We could also take away the zoom button. We could also take away possible confusion about which keyboard to show in different situations.
  • For example, should the software remember that you used the bigger-keys keyboard in the Notes app and the more-keys keyboard in Mail, and should these keyboard choices be restored in some situations but not in others? These questions became moot, and that’s good, because they don’t necessarily have easy answers.
  • Steve figured that the best way to answer difficult questions like these was to avoid the need to ask them.

2 – The Crystal Ball

  • Demos were fundamental to our work at Apple. We used them to highlight the potential, explore the concepts, show the progress, prompt the discussion, and drive the decisions for making our products.
  • This “crystal ball” demo was set in the technology landscape of the early 2000s,
  • It was also a time when many Silicon Valley software companies started experimenting with free software and plans for turning a profit by developing software they wouldn’t charge their customers to use.
  • This seemingly paradoxical corporate strategy had its roots with Richard Stallman, a renowned programmer and technology activist, a man who believed all software should be free.
  • Stallman founded the GNU Project in 1983 to advocate for free software,1 and he wrote the General Public License (GPL) to advance his agenda.
  • If you wrote software based on code covered by the GPL, you were required to publish your software under the GPL as well.
  • His GPL drives the development of the Linux operating system, and Linux is the core software running on Android smartphones, in the data centers for Google, Amazon, Twitter, and Facebook, and on the majority of network servers of all kinds.
  • Netscape didn’t survive as a stand-alone company, it did ship the open source version of its browser code, christened with a new name: Mozilla.
  • Scott Forstall, then the director of Platform Experience at Apple. In the days before iPods and iPhones, this was the department responsible for the Mac’s user interface, system apps like Finder and Mail, as well as the software frameworks that third-party developers used to make their own Mac programs.
  • Didn’t Mac OS X have a web browser? Yes, it did. Microsoft Internet Explorer.
  • A deal between Apple and Microsoft had brought Internet Explorer to the Mac four years earlier. Steve Jobs announced this arrangement in August 1997, on the same day he invited Bill Gates to appear by video feed during his keynote at the Macworld Expo held in Boston.
  • On that day, Gates pledged Microsoft’s support for Apple, committed to ship Office for Mac for five years, invested $150 million in Apple, and agreed to furnish Internet Explorer to Apple as the default web browser on the Mac.
  • On the day Don and I joined Apple, this browser replacement initiative became our job. It involved two interlocking goals. First, make a web browser app. Second, create a web technology toolkit that would make it easy for Apple’s third-party software developers to incorporate web features into their software, from downloading text and images to displaying entire web pages.
  • Brooks offers this observation: “When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned.”
  • Hollywood backlots, the semipermanent outdoor locations movie studios maintain on their properties, the sidewalks, alleyways, and main streets that filmmakers employ as settings for their stories. Especially in decades past, before expensive location shoots and computer-aided special effects became common, backlots were essential.
  • software demos need to be convincing enough to explore an idea, to communicate a step toward making a product, even though the demo is not the product itself.
  • demos should be specifically choreographed, so it’s clear what must be included and what can be left out. Those things that aren’t the main focus of a demo, but are required to create the proper setting, must be realized at the correct level of detail so they contribute to the whole rather than detract from the vision.
  • He spent no time at all on irrelevant details, like keyboard shortcuts or a beautifully designed app icon.
  • He chose this combination of important/passable/ignorable features carefully to maximize impact, minimize distractions, and fit the work schedule he’d set for himself.
  • When I make a demo, I think about the intended audience, and I make a specific decision about what features to include.
  • In the case of a preferences screen, a minor user interface element for an app still in early development, I might take a screenshot from the preferences of another app rather than implement a fully working user interface.
  • creating the illusion of an actual product is essential during the development process to maintain the vision of what we’re actually trying to achieve, and so my colleagues can begin responding and giving feedback as if the demo was the product.

3 – The Black Slab

  • Adapting the code written for one operating system so that it works on another is common enough that programmers have a word to describe the task: porting.
  • In the iPhone era, Apple took to publishing software updates for no charge, but back then, the company sold its Mac operating system in the United States for $129 per computer.
  • I typed in a URL: http://www.yahoo.com. The FIXME report filled up with line after line as it always did, but the browser didn’t crash. A few seconds passed, and then the browser did something. It drew me a picture.
  • The Black Slab. The first real “web page” our Apple browser ever loaded from the internet.
  • There were only two Eureka! moments in my career at Apple, and this was one of them.
  • an electric current through the wirelike result. As Steven Johnson says in his book, Where Good Ideas Come From, “Folklore calls Edison the inventor of the lightbulb, but in truth the lightbulb came into being through a complex network of interaction between Edison and his rivals . . . Edison built on the designs of at least a half dozen other inventors who went before him, including Joseph Swan and William Sawyer.”4
  • Ideas are nothing without the hard work to make them real.
  • Hard work is hard. Inspiration does not pay off without diligence.

4 – One Simple Rule

  • Steve wanted our browser to be fast, really fast at loading web pages from the internet, much faster than Microsoft Internet Explorer, the default browser on the Mac, the product we aimed to replace.
  • Steve thought speed was the long-term key to better browsing, so making a high-performance browser became our top priority, our definition for greatness.
  • By the late spring of 2002, our web browser was still only capable of crawling. We couldn’t use it for our daily browsing—or anything close.
  • Don was the one who figured out how we would make our code quick. One day, a month or two after the Black Slab Encounter, he called me into his office and asked me to create a test program to measure browser speed.
  • He envisioned an automated tool that would launch our browser app and command it to load a suite of web pages, one after the other, in rapid succession. Over the next couple days, I wrote the code to do just that. I named it the Page Load Test, but we soon took to calling the PLT.
  • On our browser team, as in most serious software development efforts, we followed an editorial process to make changes to our source code. Whenever I finished editing some code, I would write a detailed summary of what my edits did, what feature it implemented or what bug it fixed, and how well I thought my code change accomplished these goals. Then I would find a teammate to review the work with me.
  • The code review process often led to round after round of reviewer feedback, improvements, and requests for re-review. Once everything passed muster in the peer review, and only then, was I allowed to commit my change to our repository, the central server that stored all the revisions to all our source code.
  • Don held that if we heeded the PLT without fail and rejected any code changes that made our code slower, only two things could happen. Either the browser would stay the same speed . . . or it would get faster.
  • Optimization is the process where programmers try to make code execute faster.
  • The PLT helped us to understand what our programming instructions were doing along the essential axis of speed and showed us precisely when and where we were introducing slowness to our source code.
  • It’s common for programming teams to make their code work correctly first and then turn to speeding it up only once most of the bugs are fixed.
  • Front-loading feature work and back-loading performance optimizations are typical.
  • Yet, when features take longer to complete than expected and the delivery schedule can’t be shifted, management might have no choice but to drop performance work entirely.
  • When we deemed such features too important to skip but couldn’t figure out how to add them without causing such slowdowns, we instituted a trading scheme, where we found speedups in unrelated parts of our existing source code to “pay for” the performance cost of the new features.
  • As we got close to the release date for our project, Apple’s marketing department set out to pick an official name for our browser.
  • Within a month before the worldwide announcement of our app, planned for Macworld Expo SF in early 2003, we were still calling it either WebBrowser or Alexander, the latter a code name evoking the great Macedonian king, a famous “Konqueror.”
  • Steve Jobs had some name ideas, and when I first heard them, I cringed. Early on, Steve liked “Thunder,” but he soon got over that in favor of “Freedom.”
  • It was Scott who ultimately came up with the name that stuck: Safari. It conveyed the same world-traveler feel as other well-known browsers—Navigator, Explorer, Konqueror—but it wasn’t a slavish knock-off. It was fresh. Don liked it too and, more important, so did Steve.
  • Don’s seat-of-the-pants plan was that if Steve ran into some glitch during the Safari demo rehearsal, he would be there to say “Yes sir, Steve, we’ll get everything fixed up right away,” and then he and I would figure out what was wrong, as The Man, a supremely restless audience, watched and waited.
  • In later years, I would learn more about 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, often in Town Hall, the auditorium on the Infinite Loop campus. Slowly, day by day, he would build the show by stepping through it as he wanted to present it at the keynote.
  • 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 presentation honed, and he knew it cold.
  • Steve ran through his entire presentation, from start to finish, twice each on the Saturday and Sunday preceding the keynote itself, which was planned for Tuesday, January 7, 2003.
  • In this pre-iPod/iPhone/iPad era, Apple, Inc. was still Apple Computer, a PC company trying to drum up customers to raise its single-digit market share.
  • Part of the strategy to increase sales had been the opening, two years earlier, of the first Apple Stores, retail locations that aimed to provide better customer service and an improved buying experience for Macs.
  • Steve also announced that Safari not only loaded web pages faster than Internet Explorer . . . it loaded web pages three times faster.
  • Steve felt the need to say why Apple had made its own browser, and his explanation led with speed.
  • 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.
  • a significant part of attaining excellence in any field is closing the gap between the accidental and intentional,

5 – The Hardest Problem

  • We initially released Safari as a beta, and within a day or two, we discovered a nasty bug that could delete data from people’s computers.
  • As promised, Scott called me in to his office a few weeks later. He began by describing how email was evolving—it was expanding beyond its origins as a text-only medium.
  • Browser-based email services like Hotmail were fast becoming more popular, and Mac users were getting more and more email with web pages as the body of the message.
  • Scott said that more and more of these “rich” messages were coming through using web technology as the means to style the text and lay out the images.
  • He suggested we could use WebKit, the core of our new browser code, to improve the email experience on the Mac.
  • he wanted me to enhance and adapt our browser code so people could treat the entirety of an emailed web page like it was a word processing document, editing the text and pictures in all the usual ways: typing new text, selecting passages with the mouse, deleting with the keyboard, cutting, copying, pasting, and so on.
  • This conversation illustrates an important aspect of how Apple software development worked: Leaders like Scott offered project opportunities to programmers like me.
  • Steve and Scott wanted this new feature. If Apple was going to deliver it, someone had to “sign up” for the work and get it done.
  • I first encountered the term “signing up” in Tracy Kidder’s Soul of a New Machine, a Pulitzer Prize–winning book on the quest to develop a new minicomputer at Data General Corporation in the late 1970s.
  • Kidder used the term to describe the moment one of the company’s young and harried engineers took on the personal responsibility for delivering a project.
  • The closest term we had in the Apple lexicon was more management speak: directly responsible individual (we pronounced it as D-R-I in conversation), 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.
  • That’s how I became responsible for adding web page editing to WebKit, a technology I knew next to nothing about.
  • 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. Programmers have a name for such defects. We evoke the uncertainty principle from quantum mechanics and the man, Werner Heisenberg, who developed it. My insertion point glitches were “heisenbugs.” And fixing insertion point heisenbugs was the hardest programming problem I ever tried to solve.
  • People matter more than programming. This may sound trite, but many coders find it easier to get along with computers than colleagues,

6 – The Keyboard Derby

  • Williams asked Steve where he “fit in the American family of thinkers and inventors.” At first, Steve attempted to brush off the question, but when Williams pressed him, Steve said: “I think if you do something and it turns out pretty good, then you should go do something else wonderful, not dwell on it for too long. Just figure out what’s next.”1
  • At the time, there was an opening for manager of Sync Services, the team responsible for data synchronization between Macs and Apple’s cloud services, which were then called .Mac.* I asked for the job. Scott agreed.
  • I liked the people on my new team, and sync was technically challenging, but very soon, I was miserable in my new job.
  • Why? Mostly because I was unprepared for the change in my daily routine. I went from writing software every day to worrying about my team. My schedule was always full of meetings. I had to navigate cross-functional relationships with other teams related to sync, and that involved much more politicking than I was expecting or was used to.
  • I hadn’t realized how much I relied on writing code to feel productive and happy.
  • A couple days after that, Henri called me into his office. He closed the door. We sat down. He asked me to sign a piece of paper. It was a nondisclosure agreement, an NDA,
  • I was already under a blanket NDA from the day I started at Apple, but I guessed what might happen if I signed the new one in front of me. I didn’t hesitate.
  • Then Henri told me. “Yeah, we’re making a cell phone. Its code name is Purple.”
  • We were also just one badge-access door away from the Human Interface (HI) team. They were the designers who would imbue Purple software with a spirit, from concepts and principles to animations and icons.
  • All of us, including Henri and the HI team led by Greg Christie, reported to Scott, who, as always, had an inside line to Steve Jobs.
  • We planned to build our phone software around a technology we called multitouch, a hardware and software system that could sense and respond to taps and slides on a transparent touchscreen that could also display colorful content underneath your fingers.
  • During my visit to the HI studio to get my first look at multitouch, Bas Ording took me through an interactive demo he had made, as always, in Adobe Director.
  • On his desk, he had a device we called a Wallaby, and this phone-sized experimental device was how Bas developed and tested his touchscreen demo.
  • Scott won the tussle by assigning Henri and a couple of software engineers to develop a platform that borrowed as much from the Mac as possible but replaced AppKit with a brand-new multitouch-aware user interface system called UIKit.
  • Demos were an open forum for exchanging ideas about how an interaction might look or function better.
  • This was the one essential demo expectation: progress.
  • Around September 2005, there was an especially difficult demo for the onscreen software keyboard.
  • Try as he might, Scott repeatedly failed to thumb-type anything intelligible. The onscreen keyboard produced not just wrong words but babble. Scott kept trying, deleting backward and then typing again.
  • Our Purple phone wouldn’t have a hardware keyboard. There were no prototypes in the Industrial Design studio that included anything like a BlackBerry-style keyboard. The Purple concept was built around a large touchscreen and a minimum number of fixed buttons. Apple had bet everything on a software keyboard.
  • He proposed using keys much bigger than your fingertip, with three or four large keys per row rather than the dozen or more found on a shrunk-down standard computer keyboard.
  • This was easy enough to do, but obviously, such a keyboard couldn’t include enough keys for every letter to have its own.
  • So we started ganging up multiple letters on each key as they did on flip phone keypads and developing various means to choose the correct letter: sliding, double taps, long presses, and others.
  • Richard made prototypes to explore this idea. I responded with my own, which I called the Blob keyboard.
  • Coupled with the redistribution of letters into unfamiliar layouts—almost all of our prototype keyboards did away with the standard QWERTY arrangement—none of them was easy to use.
  • After a couple more weeks went by, I looked at the five complete keyboard prototypes I’d made since the hallway meeting, and I decided that none of them was any good.
  • I scrapped them, but I wasn’t starting over from square one. I’d taken away a few lessons: 1. Big keys were easier to tap. Richard was right. 2. Rearranging the letters on the keyboard was a bad idea. Sticking with the common QWERTY arrangement made it easier for people to find the right letters without having to hunt around. 3. Keys should be tap only. Having to choose different finger gestures on a key-by-key basis was too hard.
  • Here was my concept: a big-key QWERTY keyboard that displayed multiple letters per key but that offloaded the decision of picking the letters to the computer. No more swipes or slides. Typing a three-letter word would always take three taps, a five-letter word would always take five taps, and so on.
  • Then the keyboard would figure out you meant “light,” since that was the most sensible word with that combination of keys and letters.
  • Purple team conference room, which was called Between. Across the hall, there were two other rooms: A Rock and A Hard Place.
  • Scott gave a half nod, turned his attention to the Wallaby, and as I watched over his shoulder, I saw him thumb-tap the five keys to type his name: as zxc op rt rt. He typed quickly, and when he looked up, he saw his name spelled correctly.
  • Henri said that Scott wanted me to be the DRI for keyboards.
  • Exactly how we collaborated mattered, and for us on the Purple project, it reduced to a basic idea: We showed demos to each other.
  • concrete and specific examples make the difference between a discussion that is difficult, perhaps impossible, to have and one that feels like child’s play.
  • Demos made us react, and the reactions were essential. Direct feedback on one demo provided the impetus to transform it into the next. Demos were the catalyst for creative decisions,
  • sooner we started making creative decisions—whether we should have big keys with easy-to-tap targets or small keys coupled with software assistance—the more time there was to refine and improve those decisions, to backtrack if needed, to forge ahead if possible.
  • Making a succession of demos was the core of the process of
  • If brainstorms run longer than an hour or so, or if there are more than a handful of people in attendance, or if they’re a common occurrence, they can devolve into a form of sneaky procrastination.
  • Whiteboard discussions feel like work, but often they’re not, since it’s too difficult to talk productively about ideas in the abstract.
  • when any of us had a new concept for a keyboard, we made a demo to communicate what we were thinking. Literally, we had to demonstrate our idea. We couldn’t get away with telling. We were required to show.

7 – QWERTY

  • all the responsibility for developing the keyboard, which had been shared collectively among the Purple software team for a few weeks, landed squarely in my lap.
  • All along, I worried that my keyboard had product-killing potential.
  • Indeed, there was a well-known precedent in Apple’s own history. Apple once made a product that was torpedoed by its poor text entry technology—the Newton, the handheld personal digital assistant the company created in the 1990s.
  • The Newton was groundbreaking in concept and form factor, but it was sunk by its problematic handwriting recognition.
  • I told him about our decisions to make big keys that were easy to target and couple them with suggestions from a dictionary. Phil wasn’t satisfied, and he said so. Then that was it. I was surprised we were done so fast. The demo was over in about two minutes.
  • While I had been working hard on it, for Phil it was brand new, and he was indifferent to it. He expected the software to win him over, and apparently, it didn’t.
  • his reaction was just like a prospective customer evaluating a product from scratch.
  • The derby-winning keyboard with some modifications to make it more full-featured. The shift and delete keys made way for a return key and a key to display numbers and punctuation.
  • A couple days later, Scott and I repeated the demo performance for Tony Fadell, the executive in charge of the iPod division.
  • Then he tried my software, but he couldn’t have typed more than a word or two. The demo with him was even shorter
  • Two demos with less-than-positive responses.
  • This scheme worked well for common words, and every new word I added to the dictionary made it work even better. Typing people’s names was another matter.
  • My keyboard had no trouble with finding paths for ordinary English words, but the software couldn’t find a path through a succession of keys for a name like Teemu, since his name wasn’t in the dictionary.
  • Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positive ones.
  • Great products make people happy almost all the time and do the opposite rarely, if at all.
  • As my teammates on the Purple project used my keyboard in their daily routine in the months following the demo derby, they found they were getting confused in the midst of the tapping through words letter by letter.
  • My teammates reported how they would start to type a word but then lose track of their progress somewhere in the middle.
  • After a little study, I figured out what was going on. The derby winner suggested only those words with the exact number of letters you’d typed. My dictionary lookup software didn’t predict longer words.
  • Here’s an example. I start typing the word “aluminum” but then get distracted momentarily—perhaps a colleague invites me to get a cup of coffee. Let’s say I typed five letters before my attention was diverted. When I want to refocus and continue typing, I have to ask myself “Where am I? What letter comes next?” I look up to the suggestion bar, the narrow rectangle situated directly above the keyboard that displayed candidates from the dictionary, hoping for some assistance.
  • with this latest difficulty, the issues with the derby-winning keyboard were piling up: We couldn’t type uncommon personal names like “Teemu.” We couldn’t type uncommon words like “Arrr!” We were getting lost while typing—the “Where am I?” problem.
  • There’s a common high-tech term for a daily regimen of using and evaluating your own product while you’re trying to develop it: dogfooding.
  • “Aww . . . come on, Ken! Can’t you just put one letter on every key?”
  • In my new, Greg-inspired layout, each letter appeared by itself on a key but was given a new set of neighbors as far as the autocorrection code was concerned.
  • For example, the letter F was no longer locked in a DF set. For the person typing, there was a clearly defined F key, but the autocorrection code saw F as part of a custom group, FDGRTC, with F in the center and all its neighbors to the left and right, above and below.
  • changing over to single-letter keys definitively solved the “Where am I?” problem. Since I always displayed the specific sequence of keys you actually tapped, you could always look up and find your place.
  • When I switched away from this automatic-word-choosing on the Greg-inspired, single-letter QWERTY keyboard, tapping space now entered the exact characters you typed, the ones you saw pop up as you tapped. Dictionary suggestions continued to be visible in the suggestion bar, and I placed the best dictionary suggestion in the left position. Your exact typing appeared in the right position. However, getting dictionary assistance required tapping the word bubble in the suggestion bar rather than tapping space. You needed to pause at the end of typing a word, look up at the letters you had actually typed, tap space if you had typed accurately, or tap a bubble to change to a software suggestion.
  • I wrote some code, and in about a half hour, I had a new demo of the QWERTY keyboard, one that automatically picked the best dictionary word suggestion when you tapped space.
  • Touchscreen keyboard autocorrection was born in that moment,
  • The Black Slab Encounter was one of only two Eureka! moments I ever had at Apple. This was the other one.
  • Taste is developing a refined sense of judgment and finding the balance that produces a pleasing and integrated whole.
  • Most people make the mistake of thinking design is what it [a product] looks like. People think it’s this veneer—that the designers are handed this box and told, “Make it look good!” That’s not what we think design is. It’s not just what it looks like and feels like. Design is how it works.

8 – Convergence

  • Convergence was the term we used to describe the final phase of making an Apple product, after the features had been locked down and the programming and design teams spent the last three or four months fixing bugs and polishing details.
  • usage frequency value. This was a measure of the popularity of a word in normal text.
  • The software had to know which words were more popular than others—for example, that it’s more likely for people to type “good” than “goof.” Hence, “good” had a higher usage frequency value than “goof.”
  • We found we had to add a complete collection of hate speech to the dictionary and explicitly mark those words to prevent the software from ever offering them as autocorrections—imagine trying to type “nugget” but narrowly mistyping the first vowel or the last consonant.
  • I started by imagining a picture of my single-letter QWERTY keyboard, and I made a guess about the way I might miss a key I was aiming for.
  • I supposed that if I wanted to tap the G key but missed it to the left and tapped the F key instead, I probably meant G or F more often than I meant H. In other words, if I missed the exact key I was aiming for, the one I intended to tap was most likely the next closest key, not some other key farther away. I built the direction of these misses into my algorithm.
  • During the keyboard derby, we learned that the visual of the key appearing under your finger when you tapped was the keyboard’s way of telling you what it saw. It was exactly the kind of feedback that can connect people and software.
  • The stream of pop-ups let a person know the keyboard was following along, that it was listening.
  • Touches to type the word “blog” form a key-tap constellation, a pattern of touches superimposed on top of the letters on the keyboard.
  • gave a name to this operation of comparing patterns and summing nudges: the pattern skew algorithm.
  • the autocorrection algorithm became this: Arrange typed keys in a set of tumblers with their neighboring keys. Spin the tumblers to check every letter combination. Note the dictionary words found by spinning the tumblers. Calculate the pattern skew for every found word. Multiply the usage frequency value for each found word with the reciprocal of its pattern skew. From all the found words, suggest the one with the greatest multiplied total of usage frequency and pattern skew.1 This was the final autocorrection algorithm.
  • Time passed, and by the autumn of 2006, our Purple software started to converge. We were getting closer to a software system Apple could ship in a product.
  • On the tenth of January 2007, the day after the big product introduction, I edited the autocorrection dictionary to add a new word: iPhone.
  • We used a program called Radar to monitor our bugs, and this flexible, internally developed bug tracker was like our convergence Swiss Army knife.
  • Don Melton often told a story about convergence at Netscape.
  • Netscape’s engineering leaders knew that no sophisticated piece of software was ever truly devoid of defects.
  • Instead, they shot for zarro boogs, an intentional mispronunciation of “zero bugs.” It was a humorous recognition that they were calling their project “finished” on the ship date,
  • If convergence was the primary focus of the Purple team in the last few months before the iPhone was announced, does convergence methodology explain why the iPhone turned out so well?
  • Bug squashing might help to make a decent product, but it’s not the secret for making a great one.
  • Douglas Bowman, a designer with a résumé that includes stints at Twitter and Wired. He also started at Google in 2006, becoming one of its early visual design leaders.* Here’s how he justified his departure from the web search firm almost three years later: Without a person at (or near) the helm who thoroughly understands the principles and elements of Design, a company eventually runs out of reasons for design decisions . . . Without conviction, doubt creeps in. Instincts fail . . . When a company is filled with engineers, it turns to engineering to solve problems. Reduce each decision to a simple logic problem. Remove all subjectivity and just look at the data. Data in your favor? Ok, launch it. Data shows negative effects? Back to the drawing board. And that data eventually becomes a crutch for every decision . . . Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better.3
  • In this kind of test, commonly referred to in the high-tech industry as an A/B test, the choices are already laid out.
  • In this Google pick-a-blue experiment, the result was always going to be one of those forty-one options.
  • the opportunity cost of running all the trials meant there was less time available for everyone on the development team to dream up a design that people might like two, or three, or ten times more.
  • A/B tests might be useful in finding a color that will get people to click a link more often, but it can’t produce a product that feels like a pleasing and integrated whole.
  • Google factored out taste from its design process.
  • As a whole, a succession of demos, feedback, and follow-up demos created a progression of variation and selection that shaped our products over time.
  • I’ve given a name to this continuing progression of demo feedback next demo: creative selection.
  • We always started small, with some inspiration. We made demos. We mixed in feedback. We listened to guidance from smart colleagues. We blended in variations. We honed our vision. We followed the initial demo with another and then another.
  • We improved our demos in incremental steps. We evolved our work by slowly converging on better versions of the vision. Round after round of creative selection moved us step by step from the spark of an idea to a finished product.

9 – The Intersection

  • up to something more. “The Intersection,” the title of this chapter, was an idea that helped us. It speaks to the way Apple valued expertise in both technology and liberal arts.
  • Steve Jobs told everyone what he thought about this topic himself, on stage, during the keynote presentation to announce the original iPad: The reason that Apple is able to create products like the iPad is because we’ve always tried to be at the intersection of technology and liberal arts, to be able to get the best of both, to make extremely advanced products from a technology point of view, but also have them be intuitive, easy to use, fun to use, so that they really fit the users. The users don’t have to come to them, they come to the user.

The First-Ever iPhone Game Was Serious Fun

  • we started asking each other the same “big” question: How large should we make objects on the screen so they’re easy to tap?
  • Tap targets needed to be small enough so that a single screen displayed enough content to be useful but large enough that you could confidently tap what you wanted.
  • SpringBoard, the program that displayed the home screen icons.
  • their differing user experiences provided us with proof early on in our development process that one of the most important user interactions for the iPhone rested on this question: What’s the best size for a home screen icon?
  • Scott Herz, one of my Purple teammates, soon gave us the answer. He wrote an app and circulated it around the Purple team.
  • The app launched showing a very large Start button. After tapping that button, the screen would go blank for a moment, then a box would appear somewhere on the display. The goal was to tap the box. After you tapped, whether you succeeded or failed, and after another momentary blank, another box would appear somewhere else. Only this next box would be a different size, maybe larger, maybe smaller. Tap the box. Tap the box. Tap the box.
  • Behind the scenes, the software tracked the sizes of the boxes and their location.
  • The results of Scott’s game showed that if we placed a box on the screen that was fifty-seven pixels square, then we could put it at any location—high, low, left, or right. If we did that, then everybody could tap the box comfortably, with near 100 percent accuracy.
  • The tap targets for home screen icons on the original iPhone were fifty-seven pixels square.

Smooth

  • One of the key concepts of the iPhone user interface is direct manipulation. This idea refers to giving software objects some of the same attributes and behaviors as physical objects, enabling people to interact with digital bits as if they were real-world items.
  • Here’s an example. Picture yourself sitting in an office. You have two objects on your desk, a piece of paper and a manila file folder. If you want to put the paper into the folder, you reach out with your hand, pick up the paper, and move it into the folder, perhaps tipping the folder open a little as you do so to make the filing go more smoothly.
  • Back in the 1980s, Apple had helped to change this with the Macintosh. The graphical user interface of the Mac, with its mouse and icons, offered a more direct experience.
  • Interacting with an object meant moving the mouse to the object you wanted. Picking it up was done with a click and hold on the mouse button, a gesture that evoked grasping the object with your hand. Dropping the object into a folder meant moving the object on top of an icon of a folder and releasing the mouse button.
  • All these conventions made computing friendlier, and they helped to introduce the concept of direct manipulation: You could see icons on the screen that represented the objects available to interact with, and you could point at them with the mouse.
  • Apple didn’t invent direct manipulation—a computer scientist named Ben Shneiderman did in 1982
  • Imran Chaudhri was one of these early multitouch proponents, and he helped to supply the design inspiration that transformed this new technology into a product.

Lightening the Load

  • mental load. It’s a fact that our working memory has hard limits, and there has been decades of study to understand the bounds of our cognitive capabilities, extending back to the psychology paper titled The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information, published by George A. Miller of Harvard University in 1956.
  • He found we can hold only around seven items in our working memories at once.
  • Trying to handle more than sevenish things in our minds simultaneously requires us to start making chunks or, as Miller puts it, to create “groups of items that go together.”
  • However, if we can’t free up slots in our mind by making chunks when a lot of information is coming at us, we become overloaded, and once our working memory is filled, we begin to make more errors and less accurate judgments. Our ability to function falls off fast.
  • To make products more approachable, designers must lighten the load on people trying to use the things they make. Even small simplifications make a difference.
  • in November, about six weeks before Steve Jobs stepped on stage to announce the iPhone to everyone, Scott Forstall told me to ditch the suggestion bar, the horizontal area immediately above the keyboard that displayed three or four tappable words the autocorrection system thought you might be trying to type.
  • Scott considered the number of places a person might look while typing—around the blinking insertion point was one place, and focusing attention on fingers or thumbs to tap the keyboard itself was a second place. Having the suggestion bar created a third place to look—one too many.
  • For the release of the original iPhone, we removed the suggestion bar from above the keyboard. After that, autocorrections only appeared right under the word with the insertion point in it.
  • our user tests showed that removing the suggestion bar actually led to a small but statistically significant increase in typing speed.
  • Warp: You might think that when you tap the iPhone screen, the tip of your finger touches the screen, but that isn’t so. Given the curved shape of our fingertips, the point of impact is actually lower, and it’s this spot on your finger that contacts the touchscreen first. The software modifies the geometry of your actual touch points, shifting or warping them upward to account for this difference, giving you a sense that your touch targeting is right on.
  • The distance between the perception and actual lines may not seem like a lot, but if the software didn’t warp touches, it would feel like the touchscreen isn’t accurate.
  • Charged Buttons: The actual geometry for the back button in the top navigation bar is too small to tap comfortably, so the button is charged, which means the active area the software recognizes for tapping is larger than the visual area for the button.
  • Child’s Play: The original slide-to-unlock feature helped to prevent you from unintentionally activating features when the phone was in your pocket or bag, and the slider-and-channel user interface to unlock was sufficiently intuitive that when Imran handed an iPhone to his daughter for the first time—she was about three years old—she looked at the screen for a moment and, with no prompting other than what the software showed her, she slid the control and unlocked the phone. No problem.
  • Can’t Miss: Tapping within the keyboard rectangle always resulted in a key activation. Since the keys do not touch each other, either visually or at the software level, it was possible to tap within the bounds of the keyboard but not hit a key. However, I decided that if a typist tapped on the keyboard, the goal was to type, so I always gave a result. In the case of a miss, I activated the geometrically closest key to the tap.
  • the physical home button had a comforting secondary role as an always-present escape hatch for people who got lost or confused in an app,
  • We used the word “heuristics” to describe aspects of software development that tip toward the liberal arts.
  • Its counterpart, “algorithms,” was its alter ego on the technical side.
  • Algorithms produce quantifiable results, where progress is defined by measurements moving in a predetermined direction,
  • Heuristics also have a measurement or value associated with them—the duration for an animation or the red-green-blue values for an onscreen color, but there isn’t a similar “arrow of improvement” that always points the same way.
  • Unlike evaluating algorithms, heuristics are harder to nail down. For instance, how quickly should a scrolling list glide to a stop after you’ve flicked it?
  • How long should it take for an app icon to animate up from its place on the home screen to fill the entire display? How far should you have to drag your finger on the screen for it to be possible to interpret the touch as a swipe gesture? How much should a two-finger pinch gesture allow you to zoom in on an image in the Photos app? The answers to all of these questions were numbers,
  • The values themselves weren’t provably better in any engineering sense. Rather, the numbers represented sensible defaults, or pleasing effects, or a way to give people what they meant rather than what they did.
  • It takes effort to find what these things are, which is appropriate, since the etymological root of “heuristic” is eureka, which (of course) comes from the Greek and means “to find.”
  • Google used an A/B test to make a color choice. It used a single predetermined value criterion and defined it like so: The best shade of blue is the one that people clicked most often in the test. This is an algorithm.
  • Other times we chained algorithms and heuristics together. The output from a heuristic often became the input to an algorithm whose output, in turn, became the input to the next heuristic. For example, swiping to the left to see the next image in the Photos app started with using your finger movement to make a judgment call for whether the swipe should go to the next photo or stay on the current one (a heuristic), which fed into animation code to move the photo display to a specific geometric position to center the next photo (an algorithm) starting from a certain speed, given how fast you swiped (another algorithm), and eased the photo to a gentle stop using a carefully designed animation timing (a heuristic).
  • Why do some products, like the iPhone, turn out as well as they do? I’m now ready to offer my complete answer. It comes in three parts.
  • The first part is the demo-making creative selection process.
  • When we got an idea, we cobbled together a first cut on the algorithms and heuristics we would need to illustrate it. Then we pulled together the supporting resources—code, graphics, animations, sounds, icons, and more—to produce a demo.
  • After we showed the demo and shared some feedback with each other, we made decisions about changes that might be an improvement.
  • the concrete and specific modifications we chose to make led to the action items that justified making the next demo. Repeat, then repeat again.
  • The second part of my answer goes back to the introduction, where I first mentioned the seven essential elements of the Apple development approach.
  • This brings me to the third part of my answer. After creative selection and the seven essential elements, we needed one more intersection to make great work: a combination of people and commitment.
  • In my experience, this manner of culture formation works best when the groups and teams remain small, when the interpersonal interactions are habitual and rich rather than occasional and fleeting.
  • Ten people edited code on the Safari project before we made the initial beta announcement of the software, and twenty-five people are listed as inventors on the ’949 Patent for the iPhone.
  • So, here’s my take on the Apple Way, our recipe for making software for products like Safari, WebKit, iPhone, and iPad, my explanation for how we made great products: A small group of people built a work culture based on applying the seven essential elements through an ongoing process of creative selection.
  • Expanded out, it reads like this: A small group of passionate, talented, imaginative, ingenious, ever-curious people built a work culture based on applying their inspiration and collaboration with diligence, craft, decisiveness, taste, and empathy and, through a lengthy progression of demo-feedback sessions, repeatedly tuned and optimized heuristics and algorithms, persisted through doubts and setbacks, selected the most promising bits of progress at every step, all with the goal of creating the best products possible.

10 – At This Point

  • that first iPhone had some glaring software gaps that seem remarkable now, and among them was a lack of cut, copy, and paste.
  • In a few weeks, I had a demo featuring early versions of three iPad multitasking gestures: 1. A side-to-side swipe to move between your most recently used apps without going back to the home screen 2. A swipe up to show a bar of icons of your most recently used apps 3. A scrunch to go back to the home screen from the current app

Share your thoughts via Twitter DM. Let's have a chat.