More on this book
Community
Kindle Notes & Highlights
by
Ken Kocienda
Read between
December 26, 2019 - January 3, 2020
The letter pop-ups on the keyboard created a dialogue between the device and the typist,
Next I tried a more holistic scoring approach based on entire words. Rather than evaluating each touch as an individual event worthy of its own score, I grouped all the taps together.
the algorithmic task became finding the keyboarding constellation that looked most similar to the one a superhuman typist would type. The dictionary word corresponding to that ideal constellation would be the word the user meant to type . . . in theory.
The closest match was the one that required the fewest nudges.
This is what my nudges were, a counting up of the geometrical skew required to move a tap a typist made until it matched a dot in a dictionary pattern.
By joining up the pattern skew with the usage frequency values, 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.
This was the final autocorrection algorithm.
I spent many additional months tuning and optimizing the nudge calculations to improve the typing experience.
We needed scores of these finely tuned allowances and affordances throughout our software to make our touchscreen operating system intuitive and easy to use.
once we entered a convergence period, we started dealing with a persistent product development pressure generated by two opposing forces.
One was the constant ticking away of time as we moved closer to an unmovable ship date; the other was the variable and ever-changing number of bug reports representing software problems that needed to be fixed.
We learned to understand convergence behaviors, like the upward spikes in the line after big demos, which weren’t as worrisome as they seemed—many demo bugs would be quick and easy to fix—and the stubborn flat lines over many days, which could indicate real trouble, since the number of incoming bugs was matching our fix rate, and that meant convergence might be stalled.
Convergence isn’t magic. It’s a workaday high-tech development practice.
Bug squashing might help to make a decent product, but it’s not the secret for making a great one.
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.
At Apple, we never would have dreamed of doing that, and we never staged any A/B tests for any of the software on the iPhone.
We always made quick choices about small details, but we were always willing to reconsider previous decisions.
We took more time with bigger questions, but never too much.
We were always mindful of making ste...
This highlight has been truncated due to consecutive passage length restrictions.
The next demo was never far away, and often it was quite close.
Working in software meant we could move fast. We could make changes whenever we wanted, and we did.
We created new demos that were concretely and specifically targeted to be better than the previous one. We constructed Hollywood backlots around these demos to provide context and to help us suspend our disbelief about the often nonexistent system surrounding the feature or app that was the focus of our attention.
We gave each other feedback, both as initial impressions and after living on the software to test the viability of the ideas and quality of the associated implementations. We gathered up action items for the next ...
This highlight has been truncated due to consecutive passage length restrictions.
I’ve given a name to this continuing progression of demo -> feedback -> next d...
This highlight has been truncated due to consecutive passage length restrictions.
We were always so focused on the next demo, the next review session, the next time we were scheduled to show progress to Steve. Our iterative working method was like the air—something all around us all the time, something we were always aware of on some level, something it didn’t make sense to question.
There are innumerable ways creative selection can become bogged down, since this working method must be applied consistently over a period of time to yield results. Consequently, our success was as much about what we didn’t do as what we did.
Mostly we avoided falling into any of the typical product development traps common in Silicon Valley and that, I expect, occur often in other kinds of creative organizations and businesses.
We didn’t have an imbalance between influence and involvement,
where a senior leader might try to mimic the commanding role of Steve Jobs without the corresponding level of personal engagement.
Detached high-level managers making all the key decisions is such a ...
This highlight has been truncated due to consecutive passage length restrictions.
We didn’t establish large, cutting-edge software research departments sequestered from, and with a tenuous connection to, the designers and engineers responsible for creating and shipping the real products.
These kinds of anti-patterns can prevent creative selection from functioning correctly, since they block the steady accumulation of positive change while developing a product. They’re not the only ways the process can break down.
I would say that our clarity of purpose kept us on track,
Since our focus on making great products never wavered—if for no other reason than that’s what Steve demanded—perhaps
perhaps concentrating keenly on what to do helped us to block out what not to do.
Whatever the explanation for how we got started, as we had success with creative selection, ...
This highlight has been truncated due to consecutive passage length restrictions.
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.
I had been treating Purple as a prototype rather than a product, and I was usually paying attention to the parts that didn’t work quite right yet—developing features, fixing bugs, pushing for the next improvement, aiming toward the next demo.
It’s difficult to maintain a wider perspective in the midst of making; you have to make sure each individual demo feedback and response cycle eventually adds 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...
This highlight has been truncated due to consecutive passage length restrictions.
We used this notion to guide our efforts as we developed and lived on our gadgets, so that they turned out to be more than an agglomeration of the latest CPUs, ...
This highlight has been truncated due to consecutive passage length restrictions.
Unlike the unspoken idea of creative selection, we did talk about “working at the inte...
This highlight has been truncated due to consecutive passage length restrictions.
Not only was the intersection freely discussed inside the company,
but oddly for Apple, the discussion didn’t stop at the edge of the Cupertino campus.
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.
Steve used it to explain why the original Macintosh in 1984 had proportionally spaced fonts instead of the monospace teletype-like characters typical on computers of the day.