приходили только с течением времени, после долгого рассмотрения. Эвристические правила работают так. Они субъективны.

Мы используем алгоритмы и эвристические правила так, будто они являются двумя полушариями нашего коллективного разума, занимающегося разработкой продуктов. Реализация каждого связана с пересечением мастерства и вкуса, и мы всегда боролись за то, чтобы соблюсти правильный баланс. Чтобы сделать великолепный продукт высокого технического уровня, алгоритмы и эвристические правила должны сочетаться. Быстрая загрузка веб-страниц, правильное движение точки ввода, эффективный код, живая анимация, интуитивно понятные жесты и продуманное поведение — все это неотъемлемые составляющие такого продукта, как iPhone. Нашей целью была удобная техника и приспособленные к компьютеру гуманитарные науки — комбинация тех и других.

Как бы то ни было, очень важно правильно понять, что лучше использовать в конкретной ситуации: алгоритм или эвристическое правило. Именно поэтому эксперимент Google с сорока одним оттенком голубого кажется мне таким чужеродным, ведь я привык к подходу Apple. Google использовал А/В-тестирование, чтобы выбрать цвет. Он применяет один-единственный, заранее определенный критерий оценки и формулирует его так: лучший оттенок голубого — это тот, который люди чаще всего выбирают во время теста. Это алгоритм.

В Apple мы никогда не рассматривали понятие правильного цвета с точки зрения алгоритма. Мы использовали демоверсии, чтобы выбрать цвет и время анимации, и мы полагались на свой вкус. Когда мы искали правильное «движение пальца согласно правилу», как говорится в отрывке, который я взял из «Патента-949», мы принимали субъективное решение. Мы разрабатывали эвристические правила.

В то же время мы не делали все подряд на основе эмоций и поверхностных суждений. Создание оптимизированных алгоритмов было значительной частью разработки программного обеспечения для iPhone так же, как это было когда-то для Safari. Но важно было сохранять связь и движение между алгоритмами и эвристическими правилами — делать правильный выбор, чему отдать предпочтение: техническим или гуманитарным наукам. Это бывало непросто.

Например, иногда мы использовали эвристические правила, чтобы регулировать алгоритмы. В программе автоисправления клавиатуры алгоритм отклонения от схемы мог всегда найти наиболее близкое совпадение со словарным словом для любой последовательности букв. Представьте себе, что кто-то набрал oooorr, возможно, чтобы добавить некий нажим к слову or (или), делая выбор между двумя прекрасными вариантами (например, «на десерт мы могли бы съесть по три шарика мороженого с фруктами и орехами иииииили шоколадный слоеный торт»). Как бы то ни было, слова ooooorr нет в словаре, и оно не слишком напоминает слово, которое близко к нему в геометрическом смысле, используемом алгоритмом клавиатуры. Таким словом будет polite (вежливый). Проблема в том, что мы не считаем, что oooorr настолько похоже на polite, чтобы сократить дистанцию между ними. Они не выглядят, как слова, которые сочетаются. Мы не примем переход oooorr → polite так же, как принимаем автоисправление rhe → the или firdt → first. Цель автоисправления — это давать вам то слово, которое вы имели в виду, учитывая то, что вы делали, а не в обязательном порядке искать набранный вами текст по словарю, используя какие-либо заумные расчеты. Разрабатывая код клавиатуры, я обнаружил, что иногда лучше оставить набранные буквы в покое, опираясь на предположение о том, что автор текста действительно имел в виду то, что напечатал. После определенного момента из-за неожиданных автоисправлений программное обеспечение больше путает, чем помогает. Где же этот момент? Я смог его определить только опрашивая людей и затем, опираясь на их отзывы, сделать эвристическое правило точки отсечения, регулирующее, какое вмешательство я могу позволить алгоритму отклонения от схемы и когда ему лучше не вмешиваться. В этом случае, как показал опыт, oooorr лучше оставить в покое.

Бывали случаи, когда мы соединяли алгоритмы и эвристические правила вместе. Выход эвристического правила часто оказывался входом для алгоритма, а результат работы алгоритма, в свою очередь, часто становился вводом данных для следующего эвристического правила. Например, свайп влево, чтобы увидеть следующую фотографию в приложении «Фото», начинается движением вашего пальца, указывающего, следует ли перейти к следующей фотографии или остаться на текущей (эвристическое правило). Далее применяется код анимации, чтобы передвинуть экран с фото в определенную геометрическую позицию, дабы в центре появилось другое изображение (алгоритм). Все это происходит с определенной скоростью, которая зависит от быстроты вашего свайпа (еще один алгоритм). Затем следует мягкая остановка фотографии, для чего используется тщательно разработанный отсчет времени анимации (эвристическое правило).

Вот что такое работа на перекрестке наук. Эти примеры должны объяснить, почему мы всегда делали так много демоверсий. Пример с движением фотографий особенно хорошо объясняет, почему вы не можете «быть инженером» своего продукта на одном этапе, а затем переключиться на «наглядность и восприятие» на другом. Часто было трудно решить, где должен кончаться алгоритм и начинаться эвристическое правило. Обычно для того, чтобы оценить все относящиеся к делу варианты, требовалось много прогонов дизайнерами и программистами. Лучшим способом было принимать небольшие, тщательно взвешенные решения, уменьшая всю сложность такого количества многокомпонентных и налагающихся друг на друга факторов. Это было словно пытаться сложить пазл, когда не совсем представляешь, какой должна получиться картинка в конце, а куски постоянно меняют форму. Никакие А/В-тесты не были возможны. Так как программное обеспечение изменялось от поколения к поколению, мы редко могли увидеть все последствия нашего выбора в одной конкретной демоверсии. Мы чувствовали, что должны какое-то время пожить с этим софтом, чтобы знать наверняка, чтобы понять, как ПО подходит к нашей повседневности, чтобы увидеть, как то, что мы сделали, работает по сравнению с первоначальной версией. Нашей целью было срежиссировать последовательность алгоритмов и эвристических правил, чтобы создать великолепный продукт, который вызывал бы улыбки на лицах людей и хорошо работал без суеты. В конце концов, дизайн — это то, как он работает.

Это медленный путь. Как сказал Стив во время презентации iPhone, ему пришлось ждать этого события два с половиной года.

* * *

В случае такого продукта, как iPhone, случается много пересечений, и некоторые из них имеют совершенно особенный характер.

На презентации устройства на Macworld, когда Стив впервые продемонстрировал iPhone, моя клавиатура пересеклась с миром.

Когда Стив в своей презентации добрался до того места, где должен был первый раз показать клавиатуру публике вне Apple, мои гордость и надежда сменились страхом и ужасом. Затем в своем рассказе для зрителей Стив назвал мою клавиатуру «феноменальной» и легко набрал текстовое сообщение.

Фух! Честно говоря, Стив поставил лишний перевод строки в конце текста, который ставить не намеревался, но это не так уж важно. Ничего ужасного не случилось,