I'm generally a sucker for memoirs of interesting environments, and this is one of the best ones I've read. In this book, Ken Kocienda, an Apple software engineer, shares his insider view on creating Safari and the iPhone keyboard. You get both the "vibes" and the principles of Apple's unique design culture. It's both a page-turner (for a nerd) and a book with tangible lessons. ## Why you only have one keyboard, not two, for the iPad The book opens with the experience of Kocienda demoing the new iPad's keyboard to Steve Jobs. The original design had two modes. The team decided that giving both options to the user would be good, and created a nice zoom animation to toggle between those options: * Keyboard A: Smaller, less functionality, and less disruptive to reading * Keyboard B: Bigger, more functionality, takes up a big chunk of screen Only when Steve saw it, his response was: "Which one of these are we doing? We're only doing one of these right", and everyone was like: "yeah definitely" (!). From this interaction, you can learn a few things about Apple's culture: - The Demo drives the design process. - Simplicity and decisiveness are key principles. ## Demos and Taste driving Creative Evolution The demo process is the source of the book's name. This anecdote was not a one-off, but a regular ritual Steve and leadership sat down, tried the product themselves, and gave feedback. As I read it, there's a sense of sanctity in the process. > 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. The book continues referring to demos and ✨**taste**✨, and shows concretely how the combination of the two has advanced Apple's products over the years, and embodies the intersection between science and liberal arts. ## Simplicity & Decisiveness: no feature is the best feature By nixing one of the keyboards, Apple prioritized ✨**simplicity**✨. Having both keyboards raises many "future questions." How will the swapping work? What about internationalization? And what happens on different screen sizes? >Steve figured that the best way to answer difficult questions like these was to avoid the need to ask them. This mirrors the Elon's "delete" principle, but also has a user ✨**empathy**✨ aspect to it: > 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. Kocienda seems to have over time adapted a [[Via Negativa]] approach to great UX design: > Over time, I came to the conclusion that designing an excellent user experience was as much about preventing negative experiences as facilitating positive ones. It couldn’t be an even trade-off either. Great products make people happy almost all the time and do the opposite rarely, if at all This principle permeated from Steve down. Nobody corrected him that the designers in fact intended to make two versions available: > because doing so would mean speaking up in favor of adding back complexity. Hardly a winning hand. Scott, Henri, Greg, and Bas wouldn’t have earned their place in Diplomacy unless they had a well-tuned sense of when it was best to say nothing. Bas never expressed any disappointment over his zoom animation getting deleted either. Seeing good work wind up on the cutting room floor was part of the job **✨ Decisiveness ✨**. Steve didn't ask the team to come back in a week with a suggestion of which keyboards they're keeping. He wanted an answer now: > Steve Jobs made me pick the better keyboard layout for the iPad on the spot while he waited rather than just offering the two different designs Bas and I developed ## Safari: making it work fast, fast When Apple set out to do Safari, they had a very clear directive: create the fastest browsing experience in the world. And they had about 18 months to pull it off. Spoiler alert, they [did it]([https://www.apple.com/newsroom/2003/01/07Apple-Unveils-Safari/](https://www.apple.com/newsroom/2003/01/07Apple-Unveils-Safari/)) > “Safari is the fastest browser on the Mac, and we predict that many will feel it is the best browser ever created,” said Steve Jobs, Apple’s CEO. “We are bringing innovation back into this category with the first all new browser created in many years.” The first step was a huge tedium of getting a first version of _something_ working. The browser working at the time on the Mac was Mozilla, but it was too bloated to become fast enough. Instead, after six weeks of chasing a dead end there, the team tried a different approach and took Konqueror (a Linux browser) and ported it to Mac. While this is simple, it's not easy - they had to tediously chase every single API call and adjust it to run on Mac. Their reward was to finally get Safari to run and seeing a black page. Kocienda lovingly dubs this as "the Black Slab Encounter": Kocienda calls the principles here **✨ craft ✨** (actually caring about speed) and **✨ diligence ✨** (doing the grunt work): > Craft, which means applying skill to achieve high-quality results and always striving to do better, as when the Safari team made the web browser faster and faster by running the Page Load Test, trying to understand what this test program told us about our software, and using these findings to optimizing our code > > Diligence, which means doing the necessary grunt work and never resorting to shortcuts or half measures, as when we persisted through the tedium of fixing cross-references to get Safari to build in the lead-up to the Black Slab Encounter Once they got it working, they had to make it faster and faster while adding features. It was not easy. They introduced a "Page Load Test" (PLT) which would essentially test how long does it take for the browser to load a big page. Under any circumstances, the PLT was not to go up. They held this line completely: > There were plenty of instances when we were about to integrate a new feature, only to find that there truly was no way to add the code without a negative impact on speed [...] 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. [...] None of this optimization was easy, and it wasn’t always fun, but Don always held the line. And in the year following the Black Slab Encounter, we succeeded in making our code faster and faster. Kocienda calls this principle ✨ **inspiration** ✨. For anyone who has been in a large organization, how the whole organization [[Begin from the end|began from the end]], and the entire process of software development was subservient to the singular goal of making it fast, is impressive: > Steve told us he wanted it to be fast. Don gave us his rule to realize this goal, never make the browser slower, as well as the Page Load Test, the means to accomplish it. Our browser team incorporated the PLT into our daily workflow, and we used the test results to measure and monitor our progress. Around a year later, when we were ready to release Safari, Steve could stand up on stage and, in a straightforward manner, tell the world what we had done. Our speedy browser lay at the end of a long chain linking inspiration to proposal to plan to process to product ## iPhone Keyboard This is the most exciting part of the book. You get a look behind the scenes of the biggest tech change of the century. From tasty tidbits around how he was introduced into Project Purple "we're building a new phone", to how they leveraged the few "Wallabee" prototypes they had, the backstory is fascinating. Kocienda zeroes in on one aspect: the keyboard. If you think about it, the keyboard was the single most important piece. Blackberry surrendered 50% of the screen space and ultimately lost to iPhone, exactly because they believed that a mechanical keyboard was essential. In the early days of development, the Apple team too believed the virtual keyboard was too poor. They thought it might even ruin the product. The team held a Keyboard Derby, which Kocienda won. They kept working, focusing more on the autocorrect features. Autocorrect is key. Without it, there’s no iPhone keyboard or any virtual keyboard of this size. When you're tapping on a key in a virtual keyboard, you think about it as a skeuomorphism to a mechanical keyboard. Under the wraps, something entirely different is happening: it's more of a probabilistic tap. That tap is adjusted too. The spot where your fingers actually touch is a few millimeters higher than you think - thankfully the software knows to adjust for it. ![[Creative.png]] ## Heuristics Kocienda discusses heuristics and explains that the best way to find them is through many tweaks and demos. By letting people interact with the product, we can discover what works. > 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, and might be 0.35 seconds for the app animation, or 30 pixels for the swipe gesture, or 4x for photo zooming, but the number was never the point. 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. ## Last ingredient: committed, small teams Inspiration, Taste, Craft, Decisiveness, Diligence, Collaboration and Empathy. Those are the seven principles that Kocienda shows. The last ingredient is the small and committed teams. It's really hard to fathom in a world where [DocuSign has 8000 employees]([https://www.teamblind.com/post/How-on-Earth-does-Docusign-have-7000-employees-1cmwOZcL](https://www.teamblind.com/post/How-on-Earth-does-Docusign-have-7000-employees-1cmwOZcL)), but: > The teams for the projects I’ve described in this book were small indeed. **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**. Although these two numbers measure different things, they get us in the right ballpark. These weren’t software teams of hundreds or thousands. There was a pragmatic management philosophy at play here, which started from Steve on down. Our leaders wanted high-quality results, and they set the constraint that they wanted to interact directly with the people doing the work, creating the demos, and so on. That placed limits on numbers.  #published 2025-02-09