Архитектура встраиваемых систем. Работа с таймерами МК. Отчет по лабораторной работе. Алан Купер Психбольница в руках пациентов
 Скачать 7.24 Mb.
|
|
Глава 11. Проектирование для людей В предшествующих главах я описал персонажи и подчеркнул превосходство целей над задачами. Только если у нас есть персонажи и мы представляем себе их цели, мы можем начать изучение задач без боязни, что они помешают процессу проектирования. Свой инструмент для рассмотрения задач мы называем «сценариями». Сценарий - это сжатое описание способов применения программного продукта персонажем для достижения цели. Эта глава посвящена сценариям, а также ряду других полезных инструментов проектирования. Она содержит и примеры работы этих инструментов, в частности сценариев в реальных проектах. Сценарии По мере детализации проектирования эффективность сценариев повышается. Наши персонажи проходят через эти сценарии, словно актеры, читающие роли, что позволяет проверять корректность проектирования и выдвинутые предположения. Неудивительно, что наш сценарный процесс часто сравнивают с игрой по Станиславскому - актер должен вжиться в роль, знать то, что знает персонаж, чувствовать то, что чувствует персонаж. Мы стараемся думать так, как думает он. Мы забываем о собственном образовании, способностях, подготовке, инструментах и думаем, что обладаем лишь данными и биографией персонажа. Поскольку мы проектировщики, а не актеры, без контекста и конкретных деталей может быть нелегко, поэтому сценарии оказываются большим подспорьем. Зная, к примеру, что Бетси пытается создать сайт для страховой компании, нам проще ставить себя на ее место. И это не так странно, как может показаться. Ведь программисты ставят себя на место своих компьютеров. Программисты привычно описывают действия компьютера от первого лица, они говорят: «Я обращаюсь к базе данных, а затем сохраняю записи в буфере». Человек говорит «я», но всю работу на самом деле выполняет компьютер. В роли компьютера человеку проще симпатизировать 228 потребностям машины в процессе написания кода. Сценарии создаются на основе информации, собранной в ходе первой фазы - исследования. Обычно в ходе интервью и непосредственного наблюдения за пользователями удается много узнать об их задачах. Цели стабильны и неизменны, задачи же неустойчивы, подвержены изменениям и часто оказываются ненужными в компьютеризованных системах. В процессе разработки сценариев мы стараемся находить и вычеркивать задачи, существование которых обусловлено лишь исторической необходимостью. Эффективность сценария определяется в большей степени его охватом, чем глубиной. Иначе говоря, важнее, чтобы сценарий описывал процесс от начала до конца, чем чтобы он описывал каждый шаг в исчерпывающих подробностях. Важно развивать лишь те сценарии, которые позволяют продвигаться вперед в процессе проектирования и не плутать в дебрях исключительных ситуаций. Мы разрабатываем лишь два вида сценариев, хотя сценариев каждого вида может быть и несколько. Это сценарии повседневные и сценарии обязательные. Повседневные сценарии Повседневные сценарии - самые полезные и важные. Они описывают основные действия, которые пользователь выполняет чаще всего. Так, для системы сопровождения программных ошибок типичные повседневные сценарии - поиск записей о дефектах и заполнение форм о свежевыявленных дефектах. Любой сотрудник технической поддержки выполняет эти две задачи ежедневно и по многу раз. В общем случае для большинства пользователей репертуар повседневных сценариев оказывается весьма ограниченным. Чаще это один или два сценария. И редко их бывает больше трех. Повседневные сценарии нуждаются в самой надежной поддержке качественным взаимодействием. Новые пользователи должны быстро овладевать такими сценариями, а значит, требуется качественная поддержка быстрого обучения. То есть инструкции по применению должны быть написаны у программы «на лбу». Однако частота повторений вскоре приводит к ненужности инструкций, поэтому у пользователей быстро появляется потребность в ускоренных методах работы, таких как клавиатурные сокращения. Кроме того, по мере при обретения опыта пользователи начинают ощущать потребность в 229 подгонке повседневных взаимодействий под индивидуальный стиль работы и личные предпочтения. Обязательные сценарии Обязательные сценарии описывают все действия, выполняемые и нечасто, но неукоснительно. Очистка баз данных и создание исключительных запросов могут оказаться именно в этой категории сценариев. Обязательное взаимодействие также требует поддержки механизма обучения. Однако пользователь никогда не перейдет на более высокий уровень прохождения таких сценариев. Редкое применение означает, что любой пользователь согласится с механизмами, предложенными программой, поэтому индивидуализация не потребуется. Это освобождает разработчиков от необходимости обеспечивать тот же уровень доводки которого требует повседневный сценарий. Примерно так же роскошный интерьер салона нового Ягуара и отличается от грубого металла его подкапотного пространства. В большинстве продуктов репертуар обязательных сценариев достаточно ограниченный, но количество последних обычно превышает количество сценариев повседневных. Сценарии исключительных ситуаций Разумеется, существует третий вид сценариев - сценарии для исключительных ситуаций. Программисты, естественно, обращают особое внимание именно на них, но в процессе проектирования продукта эти сценарии можно игнорировать. Это не означает, что соответствующей функциональности нет места в программе, но означает, что взаимодействие для таких сценариев можно проектировать грубо и упрятывать в глубины интерфейса. Работоспособность кода может зависеть от того, обрабатываются ли исключительные ситуации, а успех продукта зависит от способности справляться со случаями, описанными в сценариях повседневных и обязательных. Если пользователь решает некую задачу часто, то взаимодействие в данном месте программы должно быть продумано до мелочей. Точно так же, если задача выполняется редко, но в любом случае, то взаимодействия для этой задачи, пусть и преследующее иные цели, должно быть спроектировано качественно. Задачи, не являющиеся обязательными или повседневными, просто не требуют тщательного проектирования. Времени и денег всегда не хватает, поэтому такие задачи - хорошая возможность 230 сэкономить ресурсы и потратить их на то, что приносит больше пользы. Мы должны создать все сценарии, но тщательно проектировать интерфейс следует лишь для сценариев важных или применяемых постоянно. * * * Персонажи, цели и сценарии - тяжелая артиллерия проектировщика. Прежде чем перейти к примеру применения сценариев, поговорим о некоторых других полезных понятиях проектирования: адаптирующемся интерфейсе, вечных середняках, словаре, мозговом штурме и нестандартном мышлении. Адаптирующийся интерфейс Взаимодействие всегда можно упростить - достаточно удалить функции и сделать продукт менее функциональным. В большинстве случаев такая тактика неприемлема. Более сложные задачи проектирования требуют простоты применения продукта без принесения в жертву функциональности и мощи. Это сложно, но выполнимо. Здесь требуется лишь техника, которую яназываю адаптирующимся интерфейсом. Программа должна предоставлять массу функций, но в конкретный момент времени конкретному пользователю для конкретной задачи нужны далеко не все функции. Для каждого сценария персонажу требуется лишь небольшое подмножество органов управления и данных, хотя этот набор может меняться с течением времени и при изменении решаемой задачи. Интерфейс станет на порядок проще, если органы управления и данные, необходимые для повседневных сценариев, будут бросаться в глаза, тогда как все прочие элементы интерфейса отойдут на второй план, за пределы поля зрения. Интерфейсы большинства крупных программ очень похожи на меню в китайских ресторанах, где каждая страница испещрена сотнями пунктов. Возможно, для ужина именно это и нужно, но в продуктах высоких технологий только мешает. В Мiсrоsоft Word, к примеру, стандартная панель инструментов содержит пиктограммы для загрузки документа, закрытия и печати текущего документа. Перечисленные задачи выполняются с разумной частотой, и присутствие пиктограмм оправданно. Однако здесь же, рядом, располагаются пиктограммы, генерирующие схему документа и внедряющие в документ электронные таблицы. Мiсrоsоft поместила эти пиктограммы в Основном рабочем пространстве, чтобы мы смогли оценить мощь Word. 231 К несчастью, большинство пользователей к этим функциям так никогда и не обращаются, а если и обращаются, то вряд ли часто. Этим функциям Просто не место на панели инструментов, потому что панель инструментов - это идиома интерфейса, обеспечивающая доступ к самым востребованным функциям. Вечные середняки Обычно самые мощные инструменты позволяют нам понять, представить личности наших пользователей, вжиться в них. Одну умозрительную модель мы применяем постоянно - она называется «вечные середняки». Большинство пользователей - не новички и не эксперты, они просто вечные середняки. Помните Рупака, Шэннон, Декстера и Роберто из главы 9 где речь шла об уровне подготовленности? Квалификации этих людей совершенно различны, но все четверо являются вечными середняками. Опыт людей, работающих с интерактивными системами, как и многие другие характеристики, тяготеет к классическому «колоколу» нормального статистического распределения. Если построить график зависимости количества пользователей любого электронного продукта от уровня их профессионализма, то получится немного новичков в начале шкалы, немного профессионалов ближе к ее концу и преобладание пользователей среднего уровня по центру. Но статистика не дает полной картины. Это моментальная фотография, в которой нет динамики, и, хотя большинство - вечные середняки - остаются обычно в своей категории длительное время, люди на концах кривой - новички и эксперты - постоянно меняются. Сложность сохраненная высокого уровня профессионализма означает, что специалисты быстро появляются и быстро исчезают. Новички, в левой части кривой, сменяются еще быстрее. Какое-то минимальное время любой пользователь продукта проводит в статусе новичка, но никто надолго в этом статусе не задерживается. Просто потому, что никто 232 не любит быть новичком, ни у кого нет такой цели. Людям не нравится собственная некомпетентность, а новички некомпетентны по определению. И напротив, обучение и совершенствование - естественный, увлекательный, приносящий удовольствие процесс, поэтому новички очень быстро превращаются в середняков. К примеру, учиться играть в теннис увлекательно, но первые несколько часов или дней неудачные попытки отбить мяч приводят в отчаяние. Овладев базовым навыком, вы уже не тратите все время на беготню за пропущенными мячами, а действительно продвигаетесь вперед. Состояние новобранца попросту никого не привлекает, и каждый человек быстро выходит из него, попадая в некое подобие средней лиги. Если через несколько дней вы по-прежнему бессистемно гоняетесь за теннисными мячами, то забросите теннис и займетесь рыбной ловлей или станете филателистом. Новички на левом конце кривой либо мигрируют в центральную область, где обитают середняки, либо попросту исчезают с графика и находят другой вид деятельности, где способны превратиться в середняков. Однако популяция центральной части графика очень стабильна. Достигая адекватного уровня, люди, как правило, остаются в этой области навсегда. Особенно это верно для продуктов, обладающих высоким когнитивным сопротивлением: пользователи не получают удовольствия от их изучения. Поэтому они изучают необходимый минимум, после чего учеба прекращается. Лишь хомо логикус получает удовольствие от изучения сложных систем. Теперь сопоставим «колокол» кривой статистического распределения с тем, как разрабатывается программное обеспечение. Все программисты относятся к разряду экспертов, поскольку им приходится исследовать все, даже самые странные варианты и маловероятные ситуации, чтобы создать код для их обработки. Естественная склонность к проектированию на основе собственных предпочтений означает, что они создают код по модели реализации, назначая всем функциям равный вес во взаимодействии. Если построить график пригодности типичного продукта, созданного по модели реализации, то наивысшая его точка будет расположена в правой части шкалы, где обитают эксперты. О пользователях среднего уровня никто особенно не заботится. 233 В пределах компании руководство, отделы продаж и маркетинга постоянно расхваливают продукт клиентам, журналистам, партнерам, инвесторам, то есть людям, с продуктом не знакомым. Эти профессионалы вынуждены постоянно контактировать с начинающими, поэтому их видение пользовательской аудитории искажено и определяется именно этой проблемной группой. Все эти влиятельные участники процесса естественным образом лоббируют упрощение интерфейса на благо новичков. Они желают внедрить в продукт дополнительные средства обучения, облегчающие начинающим жизнь. Теперь наивысшая точка графика пригодности продукта к взаимодействию оказывается в левой части шкалы, где обитают новички. Наложив два графика, мы увидим, что сильнейшее влияние на проектирование взаимодействия оказывают антиподы, а самое главное, что ни те ни другие не достигают цели. Программисты требуют взаимодействия, уместного только для специалистов, тогда как маркетологи требуют взаимодействия, уместного только для новичков, тогда как самую большую, самую стабильную и самую важную группу пользователей - вечных середняков - просто игнорируют. 234 Такой разрыв между образом пользователей, сложившимся у разработчиков, и действительной природой пользователей создает дополнительное когнитивное сопротивление. Вы легко увидите это в большинстве внутренних корпоративных приложений и в большинстве массовых продуктов, основанных на программном обеспечении. Чтобы успешно применять эти продукты, необходимо быть программистом, но в то же время эти продукты изобилуют артефактами вроде мастеров и оперативной справки для начинающих. Эти возможности и есть дополнительно приделанные средства обучения. Мастеры и справка, как правило, выручают пользователей в определенных ситуациях, не обучая тому, как в будущее мне попадать в неприятные ситуации. Специалисты мастерами и справкой никогда не пользуются, а новички стремятся побыстрее избавиться от этих оскорбительных напоминаний о невежестве. Однако вечные середняки навсегда остаются в компании этих артефактов. * * * Вооруженные инструментами целеориентированного проектирования, такими как персонажи, цели, сценарии, вечные середняки, адаптирующийся интерфейс и другими, мы можем уверенно штурмовать проблемы проектирования, представленные нашими клиентами. Мы знаем, что даже самые неподатливые задачи в конечном итоге сдаются под натиском нашего процесса. Представь себе! Каждый инженер представляет свой продукт в собственных терминах, но из-за необходимости программировать редко видит продукт в контексте Конкретного пользователя (по крайней мере, конкретизация не достигает Уровня, который я нахожу полезным). Мозговые штурмы позволяют нам избавиться от всех ограничений и ожиданий и начать проектирование с чистого листа, уделяя большое внимание персонажам и их целям. Мы часто проделываем упражнение на творческое мышление. Это упражнение называется «представь себе!» и заключается в прохождении сценария с 235 «волшебным компьютером», не имеющим никаких ограничений. Это упражнение подчеркивает контраст между задачами и целями. Задачи обычно меняются вместе с технологией, тогда как цели остаются неизменными. Воображая волшебную технологию, мы принудительно изменяем все задачи, обнажая истинные цели. Несмотря на кажущееся притворство, процесс этот является весьма конкретным умственным упражнением. Иногда проектировщиков осеняет верным ответом, но не реже им приходится долго дискутировать и изучать проблему, прежде чем получить этот ответ. Словарь В процессе проектирования и особенно в ходе мозговых штурмов я отдельно подчеркиваю необходимость создания и применения подробного и точного словаря. Я считаю, что технический нюанс проектирования интерактивных продуктов настолько важен, что единственное неправильно истолкованное слово может стать причиной краха целого проекта. Мне приходилось наблюдать, как разные участники команды клиента применяют распространенные слова вроде «кнопка» или «диалог» для обозначения качественно различных вещей. Мне вспоминается встреча с заказчиком, на которой десять высокооплачиваемых специалистов в течение двух часов ожесточенно спорили из-за разногласия, возникшего лишь потому, что различные участники пользовались различными определениями одних и тех же понятий. Если нет слов для выражения идеи, то ее практически невозможно передать. И определенно невозможно такую идею проанализировать и разложить на составляющие до достаточного уровня технических деталей, чтобы реализовать ее на языке C# или Java. Если слова не точны, программисты рефлективно ищут спасения в самом точном из доступных методов выражения: исходном коде. И хотя не существует ничего более точного, чем код, также не существует и ничего более крепкого и неподвластного изменениям. Поэтому часто путаница в терминологии заставляет про грамм истов преждевременно начинать создание кода, и этот код становится проектированием де- факто, независимо от того, насколько такое проектирование уместно или корректно. Если терминов недостаточно или они определены нечетко, люди начинают мыслить консервативно. Без хорошего набора точных терминов новые идеи невозможно защищать на должном уровне, и в результате идеи отметаются раньше времени. 236 Наши термины не имеют ничего общего с теми, которые будут напечатаны на упаковке продукта. Наш словарь предназначен для внутреннего употребления, поэтому нас не заботит красота слов с точки зрения маркетолога. Слова должны быть всего лишь точны. Позже отдел маркетинга придумает слова, подходящие для завлечения покупателей. Продукт ScanBank компании Logitech изначально назывался «верстаком», это слово идеально подходило для нашего процесса проектирования и никогда не предназначалось для широкой публики. В одном проекте наши проектировщики зашли в тупик. После долгих споров стало очевидно, что существуют расхождения в трактовке терминов. Наша дискуссия была неэффективна, потому что не было общего словаря. Я настоял на том, чтобы разбить проект на отдельные фрагменты, с которыми мы все согласимся, и дать фрагментам совершенно новые названия, не относящиеся к делу. Без особой причины я выбрал названия горных массивов Аляски. Четыре основных фрагмента продукта мы назвали «гора Святого Ильи», «Брукс», «Аляска» и «Рангелл». Мы хорошо посмеялись над неуместностью новых терминов, но после этого практически сразу достигли согласия и быстро стали продвигаться вперед. Языковой прорыв Прежде всего, хороший словарь делает общение более эффективным. Однако создание терминологии иногда имеет и другой очень важный эффект. Время от времени нам приходится работать с командами, в которых определенные термины уже стали частью культуры. Хороший пример - фраза Мiсrоsоft «Embrace the Internet». Подобные фразы и слова могут иметь почти религиозное значение и произноситься с оттенками благоговейного трепета. Такое благоговение приводит к неспособности разобрать значение слова и повторно изучить его в свете новых императивов проектирования. Означает ли фраза, что следует идти навстречу браузерам, или же HTML, или же только протоколам ТСР/IР? Эти священные слова - забор вокруг храма. Растоптав священные верования клиента, мы не продвинемся в процесс е проектирования. Поэтому мы разбиваем процессы, задачи, программы на четко определенные обособленные фрагменты и назначаем им новые имена, не имеющие унаследованного смысла. Эти новые имена, обычно еще и шутливые, и такое легкомыслие позволят «пробить» серьезные мины участников. 237 Реальность смеется последней Типичный процесс разработки продукта начинается с перечисления ограничений и условий. Катехизис того, что «мы не можем сделать», повторяется достаточно часто и убедительно, чтобы стать доктриной независимо от того, насколько этот катехизис соответствует истине. Проектировщики взаимодействия должны со здоровым скептицизмом относиться к предположениям о невозможности чего-либо. Раз за разом мы находим способы обходить предполагаемые ограничения только потому, что отказываемся воспринимать их всерьез. Разумеется, встречаются и настоящие ограничения, которые обойти действительно невозможно, однако в попытках это сделать приобретается ценный опыт. Даже если мы не можем изящно обойти ограничение, наше путешествие по тупиковому маршруту может пролить свет на какую-то не замеченную ранее возможность. Этот процесс основан на работе Эдварда де Боно, посвященной нестандартному мышлению 1 Программисты - короли практичности. Прагматизм практически лишает их терпимости к фантазиям. Но эта сила может стать и слабостью, поскольку случается, что практичный подход не позволяет решить задачу. Изобретая, инженеры находят решение путем последовательного изучения практичных, возможных шагов. Как следствие, их решения всегда оказываются производными старых решении, а этого часто недостаточно. Мы же просто предполагаем, что возможно все, и проектируем, Исходя из этого убеждения. Обходя предполагаемые ограничения, мы видим цели и персонажи более отчетливо и находим решения, до которых невозможно добраться традиционными путями. 1 Edward de Bono «Lateral Thinking, Creativity Step by Step» (Нестандартное мышление: Творчество шаг за шагом), 1970, Harper & Row, Publishers, New York. 238 Инженеры испытывают тревогу, отступая от твердых рациональных основ, а потому предпочитают мириться с предполагаемыми ограничениями. Они знают, что мы в конечном итоге встретимся с этими ограничениями, а потому считают себя обязанными защищать их. Они называют это «ролью адвоката дьявола». Все это очень хорошо, но в чем окружающая действительность не нуждается, так это в том, чтобы ей помогали создавать трудности. Реальности не нужны адвокаты, поскольку от нее возможно отречься. Реальный мир всегда смеется последним. Зная, что реальность всегда найдет подходящий ответ, мы понимаем, что невозможное никогда не станет реальным, и здесь не спасают ни воображение, ни проектирование. Лишь человек, не заинтересованный кровно в успехе предприятия, может спроектировать что-то, что «невозможно» создать. Более того, мы часто обнаруживаем, что ограничения иллюзорны и надуманы. И это нельзя понять, не обойдя их. Пример: Logitech Scanman Наш инструмент «представь себе!» оказался особенно полезным в одном крупном проекте. Подразделение корпорации Logitech, занятое производством сканеров, пригласило нас для участия в проектировании программного обеспечения для совершенно нового поколения настольных сканеров, ориентированных на рынки домашнего и малого офисов. В новом сканере Logitech под кодовым названием «Peacock» были применены технологии сканирования нового поколения, а само устройство подключалось к компьютеру через новый порт USB. Этот недорогой продукт, по форме и размерам напоминающий свернутую газету, удобен и не занимает много места ,на столе. В прорезь сканера можно вставить любую страницу, после чего небольшой двигатель протягивает страницу через сканер, при этом происходит считывание изображения. 239 Компания Logitech уже давно сосредоточила усилия на выпуске небольших дополнительных аппаратных компонентов, особую ценность которым придает сопровождающее программное обеспечение. Звучит определенно неплохо, с точки зрения инженеров Logitech. Однако с точки зрения пользователя подход не очень приятный. Потому что не ориентирован на конечные цели. Logitech предполагала, что многочисленные программные возможности. Увеличивают ценность аппаратного устройства. В конце концов считалось, что добавление возможностей в программу гораздо дешевле добавления возможностей в аппаратную часть. Такая логика рассматривает уравнение стоимость-выгода с точки зрения производителя, а не пользователя. Предшественник продукта Peacock ломился от возможностей, и у каждого участника команды, будь то маркетолог, руководитель, программист или менеджер продукта, были свои любимые возможности, за которые он активно боролся на совещаниях. Но если когда-либо существовал продукт, нуждающийся в вивисекции, то это был именно Peacock. Мы редко считаем необходимым вырезать из продукта функции, чтобы сгладить неровности взаимодействия. Однако в случае Peacock широко распространенная идея о том, что многочисленные возможности увеличивают ценность продукта, явно была ошибочной. Наши персонажи и сценарии отчетливо показали, что интерфейс продукта перегружен ненужными, не востребованными и не находящими применение возможностями. Как обычно, мы начали процесс с создания набора персонажей. Расскажу о том, как мы сконструировали этот набор. Магазинная цена сканера была около $150. Для массового продукта это был достаточно мощный сканер с высоким разрешением и цветопередачей, однако до уровня профессиональных планшетных сканеров, стоивших обычно от $800 до $1000, он не дотягивал 1 . Всем было ясно, ЧТО основной рынок сбыта продукта формируют пользователи в домашних и малых офисах, известных под собирательным называнием SOHO (small office, home office). 1 Как обычно, время и пикирующие цены на продукты из кремния значительно изменили поле битвы сканеров, но в 1997 году ситуация была именно такая. 240 Малкольм, боец фронта Всемирной паутины Для представления сегмента пользователей SОНО мы создали персонаж Малкольма, бойца фронта Всемирной паутины. Этот молодой человек открыл на дому небольшую фирму по созданию сайтов. Он не разбирается глубоко в технических вопросах и не является дизайнером, однако знаком с компьютерами и знает, что оптимизированные изображения гораздо быстрее скачиваются из Интернета, чем здоровые, полноцветные. Сканер Peacock позволяет ему легко получить изображения среднего разрешения для сайтов, не неся излишних расходов и не вдаваясь в детали процесса. Чед Марчетти, мальчик Сканер Peacock был привлекателен и для владельцев домашних компьютеров, которые сканировали картинки и документы для личных, а не деловых целей. Для представления домашних пользователей мы изобрели персонаж Чеда Марчетти, десятилетнего мальчика, оформляющего при помощи сканера свои домашние задания. DPI Магнум Мы знали, что профессиональным дизайнерам нужны тысячедолларовые планшетные сканеры, а потому снизили свое внимание к этому сегменту рынка. Но мы знали также, что этот сегмент нельзя просто игнорировать, ведь и из искры может разгореться пламя. У начинающего дизайнера, еще не имеющего постоянной работы, нет свободных денег, поэтому Peacock сгодится на первый год или два, пока он не сможет позволить себе сканер профессионального уровня, однако только в том случае, если Peacock поможет добиться достаточной производительности. Искрой стал персонаж по имени DPI Магнум. (Вариация на тему старого телешоу Тома Селлека «Magnum, Р.I. 1 » и аббревиатуры слов dots-per-inch, распространенной меры разрешения оцифрованного изображения.) Магнум представляет, возможно, не самый крупный сегмент пользователей, но человек он, несомненно, влиятельный. Все его друзья, владельцы домашних компьютеров, просят его совета, когда речь заходит о программном и аппаратном обеспечении для работы с графикой. Через год он сможет позволить себе планшетный сканер, но до тех пор обойдется аппаратом Peacock. Малкольм и Чед не особенно разбираются в обработке изображений. Малкольм слишком сосредоточен на другом - ему нужно создавать сайты и зарабатывать деньги. У 1 Частный детектив Магнум. – Примеч. перев. 241 Чеда тоже иные интересы - не потерять изображения в глубинах файловой системы. Ни тот ни другой не видят серьезных причин ковыряться в пикселах. Обоим требуется сканировать изображения, обрезать их, а затем внедрять в документы. Конечным результатом являются именно эти документы, а никак не изображения. Мы обнаружили, что три важных цели Малкольма и Чеда совпадают: Они не желают разбираться в сканерах, разрешениях, настройках. Они желают быстро и легко находить на своем компьютере уже отсканированные изображения. Они желают легко и быстро внедрять отсканированные изображения в другие документы при помощи других программ. DPI Магнум гуляет сам по себе: он хорошо знает, что такое разрешение и чувствует себя, как рыба в воде, манипулируя различными настройками. Таким образом, можно предположить, что включение подобной функциональности в продукт пойдет Магнуму на пользу. Однако Магнум уже приобрел Adobe Photoshop. Эта мощная, сложная, дорогая программа обработки изображении - его основной инструмент, и он отлично им владеет 1 . Для решения всех своих задач (не имеет значения, насколько мелких) он применяет Photoshop. Любая попытка продублировать функциональность и мощь Photoshop в рамках Peacock обречена. Как и Пи Герман 2 , вышедший на ринг против Джорджа Формана, Peacock не продержался бы и раунда против чемпиона. Нет смысла вкладывать усилия в то, что не найдет применения и станет позорным клеймом. Однако же в двух случаях из трех цели Магнума идентичны целям Чеда и Малкольма: он желает легко находить свои изображения и легко переносить эти изображения в другую программу (Photoshop). Лишь во время сканирования Магнуму может понадобиться указать физическое разрешение в точках на дюйм. В старых, более медленных сканерах понижение разрешения позволяло экономить время при сканировании, что Магнум и делал. Новый Peacock гораздо быстрее и дает максимальное разрешение, равное вполне приличным 200 dpi. При полноцветном сканировании процесс занимает около 20 секунд для формата А4. Потратив десять секунд на изменение режима, Магнум сэкономит лишь пять секунд 1 Как бы мне хотелось перепроектировать взаимодействие в этой мощной сложной программе! Примечание: по меньшей мере шесть человек, читавших рукопись, подчеркнули эту сноску и добавили комментарии вроде: «И мне тоже!» и «Пожалуйста, сделай это!» 2 Pee Wee Herman – псевдоним американского комика Пола Ройбенса. – Примеч. ред. 242 при сканировании, но получит при этом более низкое качество, так что овчинка выделки не стоит. При достаточно высокой скорости сканирования придет ли в голову кому- нибудь - даже Магнуму - уменьшать разрешение? Такое проникновение в суть вещей позволило нам понять, что цели всех троих не противоречат друг другу, так что мы можем осчастливить пользователей и при этом избавиться от большинства ненужных возможностей продукта. Игра «Представь себе!» В ходе мозговых штурмов мы сыграли в игру «Представь себе!». Мы обнаружили, что Чед вполне доволен возможностью помещать изображения в компьютер, вообще не пользуясь сканером. Это упражнение показало, что ни Чеду, ни Малкольму, ни Магнуму не хочется разбираться с аппаратной частью процесса. С этого ракурса было легко увидеть, что Чеда интересовало только отсканированное изображение, причем после того, как оно уже попало в компьютер. Его не волнует, если изображение сканируется при помощи черной магии, однако интересует возможность потом найти это изображение, обрезать его и открыть в других программах. Большинство продуктов конкурентов, в том числе и продукт, предшествовавший Peacock, просто сбрасывали изображения в файловую систему, оставляя пользователя наедине с традиционной иерархией, позволяющей хранить и находить отсканированные изображения. Но этой файловой системой в действительности очень сложно пользоваться, она практически бесполезна. Файловая система требует, чтобы Чед назначил имя отсканированному изображению, затем выбрал место в иерархии файловой системы, где изображение следует сохранить. А если Чеду понадобится найти изображение, ему придется вспомнить имя изображения и место, где это изображение хранится. Так уж получилось, что Чед не очень силен в запоминании подобных фактов. А компьютер, обладая жестким диском, идеально подходит для запоминания подобных фактов, но не делает этого. Он заставляет Чеда помнить и место хранения, и имя файла. В нашем варианте программное обеспечение сканера не заставляет Чеда назначать изображениям имена и место сохранения. Программа все делает сама. Когда Чеду понадобится найти изображение, он сможет воспользоваться любым из его свойств, таких как дата сканирования, размер, содержание, отметка об экспорте в другую 243 программу. Не позволяя Чеду и Магнуму возиться с различными аппаратными настройками сканера, мы сосредоточили усилия на трех более важных моментах: • Исключили из интерфейса все идиомы управления сканером. • Сделали невозможной потерю отсканированных изображений в дебрях файловой системы. • Предельно облегчили перенос отсканированных изображений в документы других программ. Мы рассмотрели все доступные функции работы с изображениями и решили, что лишь три из них абсолютно необходимы. Остальные можно исключить или позднее выполнить в других, более подходящих приложениях, таких как Photoshop. Вот эти три функции: • Обрезка, отсечение изображения по краям. • Изменение размера изображения. • Изменение ориентации, поворот изображения. Набор функций получился очень маленький, но в него вошли только необходимые и часто используемые возможности, поэтому мы решили обеспечить всем функциям высочайшее качество и простоту применения. На коде удалось сэкономить в целом столько, что команда разработчиков получила необходимое время на достижение поставленных целей. Высококлассная обрезка Все компьютерные инструменты обрезки, с которыми мне приходилось 244 сталкиваться, работают одинаково неправильным образом. Пользователь щелкает мышью и растягивает прямоугольный контур. Щелчок происходит в левом верхнем углу области отсечения, а точка, где заканчивается движение, становится правым нижним углом области. Все, что находится вне области, удаляется, а фрагмент внутри области становится новым изображением. Метод быстрый, простой, легкий в реализации, доступный для понимания. Тяжеловесная графическая программа Photoshop тоже использует этот способ. Тем не менее, способ имеет серьезные недостатки. Прежде всего, он дает низкую точность - область следует выделять одним четким движением. При этом весьма вероятно, что, определив три стороны области, пользователь не сможет определить верно, четвертую, не затрагивая одну или несколько корректно размеченных сторон. Кроме того, необратимость операции означает, что программа может сохранить два различных варианта обрезки одного изображения. Наш вариант инструмента решил обе проблемы простыми для освоения и понимания способами. На каждой из четырех сторон отсканированного изображения присутствует постоянно видимый якорь линии обрезки. Якорь является наглядным инструментом непосредственного манипулирования. Теперь Чеду достаточно щелкнуть по якорю и потащить за него, чтобы получить мгновенный и соответствующий действию наглядный отклик, оценить последствия своих действий. По мере перемещения якоря часть изображения, оставленная «за бортом», меняет свой цвет на призрачно-серый. 245 Становится очевидно, что происходит обрезка изображения, но также ясно, что обрезка еще не произошла необратимо. Чед может так же легко перетащить якорь на прежнее место и таким образом восстановить фрагмент изображения. Перемещая один якорь, Чед сразу понимает, что четыре стороны области обрезки независимы, что перемещение одной стороны не затрагивает три другие. Он может корректировать и изменять область обрезки, пока не получит нужный результат. Совсем другое ощущение оставляют традиционные инструменты обрезки, где процесс модален, необратим, должен выполняться одним идеальным движением. Очень немногие пользователи компьютеров обладают нужно и ловкостью рук, позволяющей выполнить хорошо такое движение. И Чед определенно не входит в их число. Более того, обрезка должна быть наглядной и, как правило, итеративной. Даже художникам требуется несколько попыток, чтобы добиться нужного результата. Старые инструменты просто не поддерживали такой подход. А тот, что мы создали для Logitech, делал это замечательно. Даже окончательный выбор Чеда не делал обрезку необратимой. Текущие настройки области обрезки считались просто свойством изображения, а изображение всегда хранилось в полном объеме (отдельный пункт меню позволял сделать обрезку необратимой, если требовалась экономия дискового пространства). Так что Чед мог отсканировать фотографию своей семьи, усечь изображение, исключив всех, кроме кого- то одного, например матери, а результат использовать в домашней работе и потом месяца через три, вернуться к той же фотографии и изменить область об: резки, включив в результат только отца, и его фотографию поместить затем в письмо. Любая другая программа сканирования заставила бы Чеда повторно сканировать изображение. Высококлассное изменение размеров Изменение размера изображения в большинстве графических программ означает ввод размеров в диалоговом окне. Диалог допускает высокую точность значений и позволяет растягивать изображение, меняя пропорции, однако точность требуется редко, а непропорциональное масштабирование редко когда оказывается желанным. Предлагая то, что не требуется, диалог не предлагает того, что необходимо: возможности понять, насколько большим или маленьким будет новое изображение. Инструмент масштабирования должен быть наглядным. Наше решение: небольшой красный уголок, располагающийся в правом нижнем 246 углу отсканированного изображения. При наведении курсора уголок едва заметно меняется в размерах, увеличивается на пару пикселов. Это я и называю «активным откликом», он показывает Малкольму, что объект поддается прямому манипулированию. Если Малкольм щелкнет мышью и потащит за красный уголок, изображение (в реальном времени) станет больше или меньше, в зависимости от направления движения уголка. Изображение всегда сохраняет правильную пропорцию. Непропорциональное масштабирование - это уже работа Магнума, который для таких целей применяет Photoshop. Информативности инструменту масштабирования добавляют размерные линии, произрастающие из сторон изображения. Значения на линиях также изменяются в реальном времени, позволяя Малкольму при масштабировании мгновенно получать численную информацию о точных размерах изображения. Пункт меню позволяет Малкольму назначить и размерные единицы - пикселы, метрическую систему или имперскую. Высококлассный поворот изображения Графические программы обычно позволяют вращать отсканированное изображение. Вот три базовых применения этой функции: • Вращение фрагментов изображений с целью изменения композиции. • Придание нужной ориентации изображению, которое сканировалось с небольшим 247 отклонением от вертикальной ориентации. • Придание нужной ориентации перевернутому или перекошенному изображению. В большинстве программ для сканеров, к которым относится и предшественник Peacock, реализован инструмент вращения, посредством которого пользователь может решать все три задачи. Мы посмотрели на всю эту мощь и сложность с точки зрения Чеда, Малкольма и Магнума, после чего решили избрать совершенно иной подход. Первую задачу мы сразу вычеркнули из списка. Такая функция могла бы пригодиться только художнику, а художников среди наших пользователей не нашлось. Ближе всех Магнум, а он обратился бы к мощной функции поворота пакета Photoshop. А вторая - выравнивание - не может получаться хорошо из-за ограничений технологии. Практически все растрирующие устройства, такие как видеоэкраны, сканеры, принтеры, визуализируют прямые линии, отклоненные от горизонтали или вертикали на один - два градуса, в виде жутких зазубренных линий. Такую линию не распрямить никакой компьютерной обработкой, а стандартная функция поворота в таком Случае создает головокружительные оптические иллюзии. Лекарство хуже болезни. Хуже того, программный код, выполняющий поворот изображения на пару градусов, отличается большой сложностью и изощренностью. В большинстве других сканирующих продуктов эта абсурдно бесполезная функция с гордостью выпячивается - прекрасная иллюстрация того, что По Бронсон назвал слепотой, улучшающей зрение разработчиков программного обеспечения. Если изображение отсканировано с одно -двухградусным отклонением, то быстрее, лучше и проще скорректировать его расположение и отсканировать повторно. Сканирующее устройство не просто поддерживает такое решение своими точными механизмами и высокой скоростью, но и с самого начала практически исключает возможность ошибки. Третий вариант - изменение ориентации. Можно случайно отсканировать изображение вверх ногами или «уронив» его набок. Программным способом можно легко и быстро повернуть изображение на 90, 180 или 270 градусов, сориентировав его правильно. Поэтому мы спроектировали инструмент «переориентации» вместо инструмента «вращения» и снова приложили все усилия для создания лучшего варианта. В правом верхнем углу отсканированного изображения присутствует синий кружок, сходный с 248 красным уголком инструмента масштабирования. Если расположить курсор над кружком, кружок слегка увеличивается в размерах, снова намекая на активность. Если Малкольм щелкнет мышью и потащит за кружок, изображение опоясывает ярко-зеленый контур. Этот контур называется «прицелом» и подсказывает, как повернется изображение, когда Малкольм отпустит кнопку мыши. Как только кружок заходит за очередной угол изображения, зеленый прицел поворачивается в следующее из возможных положений: на угол 90, 180, 270 градусов. Малкольм заранее знает, какое влияние на изображение окажет его действие. Он отчетливо понимает, что поворот возможен лишь на фиксированные углы, а свободное вращение или коррекция результата невозможны. Все наши персонажи мгновенно понимают, как работать с инструментом. Первоклассные результаты По просьбе клиента мы провели пользовательское тестирование продукта и обнаружили удивительную вещь. Мы ожидали, что всем участникам тестирования очень понравится наш интерфейс, что они смогут понять его и легко им воспользоваться. Удивило то, что все как один участники высказались в том смысле, что Peacock – «самый мощный». С точки зрения количества функций это было далеко от истины. С точки же зрения доступности имеющихся возможностей продукт стал мощнее. 249 Когда продукт Peacock вышел наконец на рынок, персонал отдела техподдержки Logitech забеспокоился, потому что звонков с вопросами о том, как пользоваться продуктом, поступило намного меньше, чем обычно для новых продуктов. Преодоление разрыва между устройствами и программами С точки зрения проектировщика взаимодействия деление между аппаратным и программным обеспечением не имеет значения - потому что оно не имеет значения для пользователя. Пользователя не интересует, какая из составляющих в производстве дороже. Таким образом, проектировщики взаимодействия способны разрешать проблемы, возникающие при создании гибридных продуктов. В мире инженерной разработки живут разработчики аппаратной части, создающие платы электронных схем и микропроцессоры, а также разработчики программной части, создающие программный код. Хотя плоды их трудов продаются в совместных, гибридных продуктах, эти два лагеря, как правило, не сотрудничают. Иногда они даже не общаются, а просто перебрасываются готовыми модулями «через забор». По историческим причинам разработчики аппаратной части доминируют в большинстве компаний, производящих гибридные продукты. Однако по мере распространения аппаратного обеспечения эти устройства и разработчики этих устройств теряют свои позиции. И наоборот, все большую ценность для пользователей таких продуктов начинают представлять уникальные свойства программного обеспечения. Все это при водит к установлению тревожного перемирия в большинстве компаний, производящих гибридные продукты. Хорошим примером такой компании является Hewlett-Packard, здесь доминируют разработчики устройств. Принтеры, производимые компанией, - продукты сказочные, с образцовой технологией, однако после двадцати лет развития ни один из моих принтеров, произведенных НР, не способен полностью интегрироваться с компьютером. Они не сообщают компьютеру, сколько бумаги осталось в лотках, или сколько порошка осталось в картриджах, или сколько заданий находится в очереди печати. Подобное бездумное пренебрежение человеческой потребностью в информации - улика, с головой выдающая компании, где доминируют разработчики устройств. По иронии судьбы компании, выпускающие аппаратные устройства, имеют большой опыт привлечения посторонних промышленных дизайнеров для создания 250 продуктов более полезных и желанных для потребителей. Разработчики же программ склонны создавать продукты самостоятельно. В любой компании, создающей гибридные продукты, отсутствие проектировщиков, посредничающих в интересах обеих сторон, приводит к созданию продуктов, не удовлетворяющих пользователей. Примеры главы 1 «Загадки века информации» показывают это со всей ясностью. Гибридных продуктов становится все больше, и потребность в целеориентированном проектировании растет, потому что в смысле способов реализации оно агностично. Продукт PalmPilot компании 3Соm - хороший пример гибридного продукта, в котором проектирование позволило гладко сшить программную и аппаратную части. Достаточно коснуться экрана, чтобы машина проснулась точно в том состоянии, в каком была выключена. Мгновенная реакция устройства на действия пользователя четко показывает, что при проектировании аппаратной части были учтены потребности программной части. А вот контр пример: моя фотокамера Nikon CoolPix 900, при каждом включении которой на загрузку, при отсутствии жесткого диска, уходит семь длинных секунд. Когда устройство настолько медлительно, становится ясно, что шоу режиссировали разработчики аппаратной части. Разумеется, в реальном мире проектирования продуктов большинство программных компаний не заходит на территорию аппаратного обеспечения. Аппаратные проектировщики поддерживают такую линию поведения даже в случаях, когда специальное устройство приобрело бы значительные преимущества в результате сотрудничества. Однако если бюджет проекта позволяет, проектировщики могут без колебаний давать рекомендации относительно аппаратной части. Система P@ssport IFE, описанная в главе 9 «Проектирование для удовольствия», работала на выделенных компьютерах, и поставщик решения имел абсолютную власть над всеми устройствами и программами. Мои проектировщики дали некоторые рекомендации. Продукт Elemental Drumbeat, описанный в главе 10 «Проектирование ради результата» должен был работать на любом нормальном настольном компьютере Wintel. В данном случае мои проектировщики о рекомендациях даже и не думали. В нескольких случаях, в частности при работе над продуктом Logitech Peacock, моим проектировщикам предоставилась счастливая возможность повысить ценность 251 аппаратного обеспечения. У каждой компании была возможность ступить на путь гибридных решений, соглашаясь со всеми потенциальными опасностями и возможностями. Меньше значит больше Помешанные на технике, влюбленные в контроль программисты обожают фаршировать продукты всевозможными финтифлюшками и лишними функциями, но такое стремление противоречит фундаментальному тезису о качественном проектировании. Меньше, значит больше. Если проектировщик взаимодействия выполнил работу очень хорошо, то пользователь вряд ли догадается о его участии. Хороший интерфейс, как обслуживание в первоклассном ресторане, не привлекает внимания. Если проектировщику взаимодействия удалось сделать что-то особенно удачное, пользователи этого даже не заметят. «Классные» интерфейсы провозглашены целью проектирования в индустрии создания программных продуктов, и теперь артефакты взаимодействия, очевидно, отнявшие у какого-то несчастного программиста много времени и усилий, по- настоящему утомляют. Жаль, что его усилия не пошли на создание чего-то эффективного. Многие дизайнеры считают, что качественный дизайн - это классный дизайн. Часто так оно и бывает, однако независимо от того, насколько интерфейс классный, чем его .меньше, тем лучше 1 . Идея заключается в том, что чем меньше видит пользователь постороннего, тем лучше свою работу выполнил проектировщик. Представьте, что при просмотре фильма вам видны софиты на границах кадра, а в конце сцены вы слышите, как режиссер кричит: «Снято!» Представьте, насколько назойливы будут такие эффекты, как они разрушат очарование фильма. Гениальный программист и дизайнер Кай Краузе (Kai Krause) прославился своими уникальными интерфейсами. Кай создал некоторые из самых мощных и интересных программ для работы с графикой. Его продукты всегда имели захватывающе красивые интерфейсы, в то же время весьма загадочные, 'похожие на игры. Кай не только программист, но и дизайнер, и его продукты отражают стремление дизайнера делать вещи малопонятными, как в современном искусстве - чтобы произвести впечатление. 1 В своей книге «About Face» я описываю около 50 мощных аксиом проектирования. А это одна из них. 252 Такой подход эффективен потому, что пользователи его продуктов - такие же дизайнеры и увлеченные люди. За рамки этого мира продукты Кая пробиваются с трудом. * * * В программировании всегда существует бесконечное количество способов решить любую поставленную задачу. Опытные программисты знают, что в поиске вариантов, оптимальных решений рано или поздно наталкиваешься на метод, позволяющий выбросить сотни и даже тысячи строк кода. Это происходит, когда программист совершает качественный скачок. Если он может выбросить много кода, программа становится Лучше. Меньше кода - значит, меньше и сложность, меньше дефектов, меньше возможностей для некорректного взаимодействия, кроме того, упрощается сопровождение. Проектировщики взаимодействия разделяют такой подход. Исследуя варианты, они находят точки, где можно уничтожать целые экраны или избавляться от крупных и сложных диалогов. Проектировщик знает, что каждый элемент интерфейса отягощает пользователя. Каждая кнопка и пиктограмма - это еще одна вещь, о которой пользователь должен узнать, с которой должен справиться, чтобы получить искомое. Делать больше при помощи меньшего всегда лучше. Если проектировщик на верном пути, он урезает интерфейс продукта. Он вовсе не проектирует экран за экраном, наполняя их кнопками и штучками. Однажды нас посетил менеджер продукта из одной крупной компании, чтобы проконсультироваться по поводу перепроектирования продукта. В интерфейсе будет примерно десяток диалоговых окон, сказал он. Мы описали ему наш процесс, а затем дали оценку работы. Если мне не изменяет память, цифра составила $60000. «Возмутительно! - воскликнул тогда менеджер. - Это же $5000 за экран!» У меня не хватило духу сказать ему, что мы, вероятно, сократим количество диалогов до одного или двух, и тогда цена, если ее исчислять таким методом, станет гораздо выше. Он просто не понял, о чем речь. Платить за проектирование, исчисляя стоимость в экранах, все равно, что платить официанту за количество подходов к столику. Лучший официант меньше бегает, а лучший проектировщик всегда создает менее развесистые интерфейсы. Иногда стезя проектировщика взаимодействия становится просто невыносимой! Если, выполняя свою работу, вы делаете что-то фундаментально, абсолютно, неоспоримо верное, все тут же восклицают: «Ну разумеется! Здесь же просто нет других вариантов!» 253 Такова реальность, даже если клиент много месяцев и даже лет совершенно не имел понятия, как решить свою проблему. Такова реальность, даже если наше решение приносит компании миллионы долларов. Большинство действительно новаторских прорывов сложны в разработке и вполне очевидны задним числом. Невероятно сложно увидеть прорыв в проектировании. Можно получить подготовку, пройти обучение, потратить многие часы на изучение задачи, но не найти ответа. Затем приходит человек со стороны, указывает на ключевую концепцию, и тут же вся головоломка складывается в полноценное изображение с естественной очевидностью, присущей колесу. Если вы закричите о своем решении во весь голос, другие ответят: «Ну разумеется, колесо круглое! Какое еще оно может быть?» Так что похвастать хорошей работой по проектированию очень и очень сложно. Ученый-компьютерщик Алан Карп говорит: «Практически все мои патентные заявки были отвергнуты как "очевидные"». Когда я говорю меньше интерфейса, то не имею в виду меньше функциональности, хотя и такое случается. Я имею в виду, что пользователя не следует заставлять взаимодействовать с программой дольше, чем абсолютно необходимо для решения тои или иной задачи. * * * В этой главе и двух предшествующих я представил краткий рассказ о самых полезных наших инструментах проектирования. Они верой и Правдой служили для проектирования продуктов и служб - от промышленного управления до корпоративного планирования и массовых продуктов. В следующей главе я расскажу о некоторых других существующих инструментах, способствующих созданию более качественно спроектированных продуктов. Часть V. Возвращаемся на место водителя |