Недавно вышла книга “Creative Selection: Inside Apple’s Design Process During the Golden Age of Steve Jobs” от Ken Kocienda Это чувак, который играл ключевую роль в создании Safari и софта оригинального iPhone (делал клавиатуру).

В книге он описывает процесс создания и полировки этих двух продуктов. Там нет какой-то Правильной Методологии Эппла или же невероятных мыслей, которые откроют Главный Секрет Создания Продуктов. Зато там есть интересные истории и моменты того, как Эппл делает свои штуки.

Что мне запомнилось.

1. Когда делали Сафари, было указание от Джобса сделать его самым быстрым браузером на Маке. Поэтому команда сделала тест, который измерял скорость загрузки разных страниц в Сафари и показывала некий счет. Было принято простое правило, что никакие изменения в коде не должны увеличивать этот score. Оставлять таким же или уменьшать. В результате Safari получился быстрым, быстрее всех своих аналогов. Простые четкие правила рулят!

2. Маленькие команды: все новые продукты разрабатываются маленькими командами, где у каждого большая ответственность. Каждый человек в команде отвечает полностью за какое-то направление. При этом каждый разработчик в такой команде немного дизайнер, продакт-менеджер и тестер. Например автор отвечал полностью за клавиатуру iPhone. Одной из его задач было сделать звук тапа на кнопки. Он записал стук карандаша по столу, обработал и сделал два варианта. Стив Джобс выбрал один из них и этот звук был в Айфоне лет пять. (чувак — программист!)

3. Демки результатов для Эппла очень важны. Культура построена на пирамиде демок. Сначала разработчик работает над проектом. Раз в какое-то время он показывает демку своему руководителю (в книге — Скотт Форсталл), который дает свой фидбэк и замечания. Когда демка уже достаточно отполирована, ее показывают уже руководителю руководителя (Стив Джобс). В процессе этих демок отсматривается работа, делаются выборы из нескольких вариантов, находятся проблемы. Иногда работа выкидывается. Переделки ожидаемы и нормальны.

4. Когда делали софт для iPhone (iOS) было непонятно, какой размер должны иметь кнопки и иконки. С одной стороны экран небольшой и хочется, чтобы поместилось больше информации. С другой — если сделать мелко, будут промахиваться.
Поэтому чуваки запили программу — практически первую игру — которая показывала прямоугольники разных размеров и в разных местах экрана. Пользователь должен был тапнуть на прямоугольник и после этого показывался следующий. Несколько дней все увлеченно играли, а программа собирала статистику. И оказалось, что если прямоугольник размером 57px, то в него попадают практически в 100% случаев. Поэтому в первом айфоне иконки именно размера 57px.

5. За простыми штуками скрывается сложная и напряженная работа. То, что кажется очевидным из-за знания “задним числом”, на самом деле не очевидно, когда ты это придумываешь.

В книге приводится подробный рассказ, как придумывали клавиатуру iPhone. Это был непростой путь cо странными начальными прототипами и решениями. Был момент, когда неспособность придумать надежную(то есть чтобы можно было быстро набирать без ошибок) софтверную клавиатуру была признана угрозой для выпуска iPhone и ВСЮ команду разработку бросили на придумывание решения.

И Ken Kocienda как раз нашел решение, которое через множество итераций, описанных в книге, привело к тому, что мы видим сейчас. Главная его идея была в том, что надо прощать промахи по кнопках и использовать словари и эвристики, чтобы понять, что хотел ввести пользователь. Именно поэтому зона тапа на кнопках БОЛЬШЕ чем сама кнопка. Телефон автоматически догадывается, куда мы хотели нажать, а на самом деле мы часто промахиваемся. (Так что переделки и мучительные итерации — это нормально.)