Архитектура встраиваемых систем. Работа с таймерами МК. Отчет по лабораторной работе. Алан Купер Психбольница в руках пациентов
 Скачать 7.24 Mb.
|
|
Реалистичный взгляд на уровень подготовленности Один из действительно положительных моментов, связанных с персонажами, заключается в том, что они придают дискуссиям об уровне подготовленности пользователей свежесть реализма. Вариации на тему подготовленности пользователей крайне широки, и персонажи позволяют отчетливо это осознать. Широко распространенная модель подготовленности пользователей приведена в главе 2 «Когнитивное сопротивление. Вершину пирам иды составляют «продвинутые пользователи, которые предположительно знают о компьютерах все, если речь не идет о программировании. Центральный фрагмент составляют «компьютерно образованные пользователи», имеющие базовое понимание принципов работы компьютера, но не представляющие себе всех замечательных возможностей. «Неподготовленные пользователи - это основание пирамиды; считается, что они до безобразия невежественны и неумны. Вот некоторые примеры персонажей, разрушающие ложные посылки, на которых строится пирамида. Рупак работает инженером по установке компьютерных сетей в Лос-Анджелесе. Он ежедневно целыми днями возится с компьютерами, он дока в том, как заставить их работать, однако он не понимает, как они работают. Его выживание на данном месте основано на запасе суеверий и практических знаний, способности к механическому заучиванию и бесконечному терпению. Шэннон работает бухгалтером в оздоровительном центре в Темпе, штат Аризона. Она совершенно не имеет представления о Всемирной паутине, электронной почте, сетях, файловой системе и практически всех остальных аспектах современных компьютеров, но потрясающе обращается с электронными таблицами Мiсrоsоft Excel. Она умеет моментально создавать новые финансовые таблицы с графиками и диаграммами. Декстер - вице-президент отдела развития голливудской компании Steinhammer Video Productions. У Декстера, перемещающегося между павильонами звукозаписи, карманы двубортного пиджака заполнены: там пейджер, два мобильных телефона, на ладонный компьютер и беспроводной модем. В области техники он гигант, способный 173 решить любую проблему. Коллеги постоянно звонят ему, просят найти потерянные файлы, но он действительно очень занят, чтобы терять время на подобное обучение. Майкл ждет ответа на третьей линии! Роберто - представитель по телемаркетингу J. Р. Stone, компании, продающей одежду по почтовым заказам. Он сидит в своем рабочем отсеке, где-то в пригороде Мэдисона, штат Висконсин, на нем гарнитура, а компьютер он использует для обработки поступающих по телефону заказов. Роберто совершенно не разбирается в компьютерах и высоких технологиях, но он уравновешенный добросовестный работник, обладающий замечательной способностью выполнять сложные процедуры. После нескольких дней тренировки он стал одним из самых производительных и эффективных представителей J. Р. Stone. Он говорит: «Мне нравится мой компьютер!» Что интересно, ни Рупак, ни Шэннон, ни Декстер, ни Роберто не вписываются в упомянутую пирамиду. Если оставить в стороне угнетающий характер стереотипов, предложенных пирамидой, она совершенно не отражает характер аудитории пользователей. Чрезмерно упрощенные рыночные модели никак не способствуют решению проблем проектирования. Персонажи закрывают споры о функциях Как ни удивительно, вторым крайне важным вкладом персонажей является их большая ценность в качестве инструмента общения. Набор персонажей становится системой, обладающей мощным свойством объяснять наши решения в области проектирования. Более того, это как прожектор высвечивающий для разработчиков, маркетологов, руководителей очевидную правильность наших решений по проектированию. Жизненно важно, чтобы каждый в команде проектировщиков не только познакомился с набором персонажей, но чтобы все персонажи стали подобны реальным людям, подобны самим участникам команды разработчики. Программистам свойствен математический подход и они естественным образом не склонны рассматривать отдельных пользователей, предпочитая обобщение. Это переходит и на их отношение к пользователям, которых они всегда представляют в общих, агрегатных или же усредненных категориях. Они предпочитают говорить «пользователь», а не «Джуди», «Крэндал», «Луис», «Эстелла», «Раджив» или «Фрэн». 174 До введения в обращение персонажей типичный диалог программиста и руководителя, занятых проектированием взаимодействий, выглядит примерно так: Программист: «Что если пользователь захочет вывести это на печать? Руководитель: «Не думаю, что печать в первой версии так уж необходима». Программист: «Кому-то может понадобиться печать». Руководитель: «Вероятно, да, но не могли бы мы отложить пока эту функцию? » Руководитель не может победить в этом споре, поскольку в его аргументах нет логики. Аргумент, независимо от его правдивости, выглядит лишь аморфным желанием руководителя сделать что-то иначе, тогда как логике программиста о «возможных событиях» сопротивляться нельзя! После разработки набора персонажей мы получаем систему, позволяющую точно выразить, кому и что нужно от программы. Однако программистов тяжело убедить, поэтому типичная беседа нашего клиента с программистом на ранних стадиях выглядит так: Программист: «Что если пользователь захочет вывести это на печать?» Проектировщик взаимодействия: «Розмари печать не нужна». Программист: «Кому-то может понадобиться печать». Проектировщик взаимодействия: «Но мы проектируем для Розмари, а не для кого- то». На данном этапе особых перемен нет. Программист по-прежнему применяет слово «пользователь» И по-прежнему живет в мире возможных событий. Однако ввод в действие персонажа Розмари - это уже не аморфное, несформированное желание. Напротив, речь идет о конкретном человеке, обладающем известным набором умений и целей. У нас, наконец, имеется убедительный аргумент. Но поскольку кодом владеют программисты, они могут делать и делают, что захотят, независимо от силы наших аргументов. Ключ к успеху в том, чтобы заставить программистов поверить в существование и реальность созданных персонажей. Каждый из наших проектировщиков решительно настаивает на выражении всех вопросов, связанных с проектированием, с помощью именованных персонажей. Мы никогда не возвращаемся к понятию «пользователь». Через какое-то время такая последовательность приносит плоды, программисты начинают привыкать к персонажам и называть их по именам. Когда программисты начинают называть их по именам по 175 собственной воле, это малозаметное, но переломное событие меняет природу сотрудничества между проектировщиками и разработчиками. Перелом наступает во всех наших успешных начинаниях, связанных с проектированием. И тогда происходит переключение на высокую передачу. Беседа звучит теперь иначе: Просветленный программист: «Розмари захочет это напечатать?» Довольный проектировщик взаимодействия: «Нет. А вот Джейкобу нужна печать квартальных отчетов». Просветленный программист: «Ну, если печать нужна так редко, сэкономим время и силы, не будем создавать собственный встроенный генератор отчетов, а лицензируем уже существующий». Довольный руководитель: «Эдак мы сэкономим на разработке две недели!» Я видел, как после такого перелома наши клиентские компании меняются коренным образом. Раньше они плутали в дебрях бесконечных споров о Возможностях и каждые две недели снова решали уже, казалось бы, решенные вопросы. После описанных перемен вопросы проектирования обсуждаются, разрешаются и остаются разрешенными навсегда. Некоторые наши клиенты заказали футболки с изображениями важных персонажей для каждого из разработчиков. Другие напечатали постеры с персонажами для помещений, где работают программисты. Эти усилия помогают сплотить программистов ради понимания потребителей продукта. Персонажи нужны проектировщикам и программистам Нам приходилось работать в компаниях, где программисты не могли себя заставить называть пользователей по именам и не верили в точных персонажей. Они постоянно скатывались обратно к «пользователям», отчего кошмарно страдали продукты. Я знаю программиста, который просто не понимает механизм действия персонажей. Под давлением аргументов с моей стороны и со стороны Моих коллег он признал, что персонажи важны. При этом он упускает из виду главную идею конкретизации, поэтому склонен слово «персонаж»употреблять в качестве синонима слова «пользователь». Он говорит: «Мы должны обеспечить потребности персонажей». Применяя термин, он тем не менее отвергает конкретику, главный действующий ингредиент, из-за чего подход 176 теряет всякую силу. Один клиент дал нам лишь несколько дней на составление рекомендаций. Мы создали персонаж по имени Эдгар, и большим количеством деталей этот персонаж обрасти не успел. Затем мы вступили в продолжительные дискуссии с клиентом по вопросам, выходящим за исходные рамки проекта. Мы быстро обнаружили, что Эдгар начал размножаться. Различные команды внутри этой компании воспринимали различных Эдгаров, то есть каждая самостоятельно наделяла его теми или иными качествами. Профессиональные маркетологи мгновенно принимают процесс разработки персонажей, поскольку он очень похож на то, что они делают на этапе определения рынка. Главное различие между персонажами маркетинга и персонажами проектирования в том, что первые создаются исходя из демографии и каналов сбыта, а последние - исключительно на основе пользователей. Это не одни и те же персонажи, хотя служат одной цели. Персонажи маркетинга проливают свет на процесс продажи, тогда как персонажи проектирования проливают свет на процесс разработки. Продумывая этапы проектирования, мы можем примерять их результаты к персонажам и видеть, насколько хорошо справляемся. Мы начинаем играть роли, действуем от имени и по поручению персонажей. И благодаря конкретным определениям это нетрудно. Примерив на персонаже продукт или задачу, вы сразу можете понять, удастся ли вам его удовлетворить. Персонаж пользователя, а не покупателя Одна из распространенных ошибок заключается в проектировании для человека, близкого к продукту, но непосредственным пользователем не являющегося. Многие продукты проектируются для журналиста, пишущего обзор продукта для потребительской прессы. В сфере информационных технологий руководитель, покупающий продукт, часто оказывается не тем, кому придется продукт применять. Проектирование для покупателя - распространенная ошибка в компьютерном бизнесе. Разумеется, потребности руководителя в ИТ тоже нельзя игнорировать, но в конечном итоге руководителю больше понравится, если продукт сделает довольным конечного пользователя. В конце концов, если конечный пользователь доволен и имеет возможность работать Продуктивно, это успех для руководителя в ИТ. Нередко наши 177 клиенты игнорируют данный совет и потворствуют этим клевретам технологии. Одарив реальных конечных пользователей продуктом, руководители тонут в потоке жалоб и обнаруживают, что пользователи не желают иметь дело с продуктом, очаровавшим руководителя. Руководитель обращается к создателю приложения и требует, чтобы взаимодействия стали более удобными для конечных пользователей. Подбор персонажей Каждый проект получает собственный набор персонажей в количестве от трех до двенадцати. Мы проектируем не для каждого из них, но все персонажи полезны для выражения пользовательской аудитории. Некоторые создаются лишь для того, чтобы было ясно, для кого мы не проектируем. Так, в одном из проектов речь шла о системе управления поддержкой клиентов. Мы дали определения трем персонажам, из которых двое были техническими специалистами, работающими в отделе поддержки. Лео Пирс, младший маркетолог продукта, работал на компьютере ежедневно и время от времени сам обращался в службу поддержки. Элисон Хардинг, специалист компании, перемещалась из кабинета в кабинет со своими инструментами в алюминиевом кейсе, разрешая проблемы сотрудников, подобных Лео. Тедван Верен, представитель службы поддержки, целыми днями разговаривал по телефону с людьми, подобными Лео, и сообщал Элисон, какой кабинет следует посетить и что починить. Наш клиент, компания Remedy Inc., как раз занимался пересмотром Флагманского продукта, Action RequestSystem (ARS), и желал сделать его «более простым в применении». Разработав эти три персонажа (и еще ряд других), мы смогли четко выразить действительные цели проекта. Тед на тот момент был основным потребителем ARS, но не он стал нашим главным персонажем. Мы могли бы сделать программу более простой для Теда, но это означало бы полный провал. Вместо этого мы решили дать Лео прямо и доступ к системе поддержки. До этого, нуждаясь в помощи Лео был вынужден звонить Теду, который уведомлял Элисон. Полный набор персонажей дал нам четкое представление об участниках этой игры. Мы получили возможность сообщить разработчикам - системы, что цель будет достигнута лишь в том случае, если Лео, далекий от техники маркетолог, сможет задействовать систему обработки запросов (Action Request System, ARS) со своего компьютера для вызова техпомощи, Не прибегая к вмешательству Теда. 178 Как только мы объяснили положение дел в терминах персонажей, участники команды сразу поняли, что необходимо снять акцент с Теда и сосредоточить внимание на Лео. Тед занимает место так называемого «отрицательного персонажа». Его существование помогает нам понять, для кого мы не проектируем. 179 * * * Обнаружив такой персонаж, цели которого уникальны, мы идентифицируем его. Совершенно не обязательно, чтобы персонажи имели непересекающиеся наборы целей, достаточно, чтобы стремления каждого персонажа четко отличались от набора остальных. Цели Рауля, собирающего она конвейере газонокосилки, отличаются от целей Сесили, контролирующей сборку. Сесили стремится улучшить производительность в целом, избежав при этом происшествий. Рауль желает выполнить разумный объем работы, не совершая ошибок. Практически е цели этих людей одинаковы, однако мотивы очевидно различаются. Рауль желает стабильности, Сесили желает получить повышение. Их цели достаточно сильно различаются, чтобы появилась необходимость создать два различных персонажа. Ключевые персонажи В каждом наборе персонажей сеть хотя бы один ключевой персонаж. Эта личность находится в фокусе процесса проектирования. Ключевой персонаж отличает потребность в удовлетворении, недостижимом при помощи интерфейсов, спроектированных для любого другого персонажа. Для ключевого персонажа всегда существует отдельный интерфейс. В примере с Remedy ARS ключевым персонажем был Лео Пирс. Нахождение одного ключевого персонажа или сразу нескольких - жизненно важный шаг в разработке набора персонажей. По моему опыту, каждый ключевой персонаж требует отдельного уникального интерфейса. Если у нас два ключевых персонажа, то придется в конечном итоге проектировать два интерфейса. Если у нас три ключевых персонажа, придется в конечном итоге проектировать три интерфейса. Если у нас четыре ключевых персонажа, это означает, это у нас возникли трудности. 180 Если мы обнаружили более трех ключевых персонажей, это означает, что набор проблем предметной области слишком велик, что мы пытаемся слишком много сделать в один прием. Мы создаем персонажи для сужения диапазона конечных пользователей. Отсюда следует, что если число персонажей слишком велико, значит, мы начинаем действовать против исходной цели создания персонажей. Подбор персонажей - не просто удобное словосочетание, а средство проектирования, как в физическом, так и логическом плане. После просеивания аудитории полезных персонажей оказывается обычно от трех до семи. Мы собираем на одном листе бумаги информацию о них - имена, изображения, описания должностей, цели и, нередко, обрывки сплетен. Этот документ в одну страницу становится неизменной составляющей нашего процесса. Мы распечатываем копии набора персонажей и раздаем их на каждом собрании, независимо от того, присутствует ли клиент. Каждый проектировщик на всех наших мозговых штурмах и собраниях, посвященных детальному проектированию, постоянно держит перед собой эту страницу. Если на собрании присутствуют представители клиента, мы печатаем дополнительные копии и для них. Каждый созданный для клиента документ содержит эту страницу. Наша цель состоит в том, чтобы сделать персонажи неизбежным ингредиентом. Они настолько важны, что мы навязываем их всем и каждому. Выполнить качественное проектирование и не выразить его в терминах персонажей - не очень мудрое решение. Слишком уж легко скатиться обратно к разговорам о «пользователе» и утратить с таким трудом приобретенный фокус на конкретных архетипах пользователей. Пример: Sony Trans Соm и P@ssport В 1997 году компания Sony Trans Соm предложила нам замечательную проблему из области проектирования. Sony Trans Соm - это отделение корпорации Sony, расположенное в Калифорнии и отвечающее за проектирование и производство развлекательных систем для гражданской авиации. Развлекательные системы подобного рода, позволяющие в полете смотреть фильмы, телепередачи, слушать музыку и играть в игры - большой и прибыльный бизнес. Компания Sony Trans Соm разработала новое поколение технологии, предоставляющее пассажирам новые возможности. Самой впечатляющей возможностью новой системы, получившей название P@ssport, стало 181 работоспособное видео по запросу (video-on-demand). Видео по запросу означает, что Патриция на месте 23А может начать смотреть фильм «Когда Гарри встретил Салли» через десять минут после взлета, тогда как Анна, на месте 16С, может начать смотреть тот же фильм на 45 минут позже, причем каждая из них будет иметь возможность приостановить воспроизведение или перемотать фильм, никак не мешая другой. Система P@ssport подняла планку развлекательных систем в гражданской авиации на высоту, невообразимую для существующих технических решений. В спинку каждого кресла встраивался экран и компьютер с процессором Pentium под управлением Windows 95. В носу самолета располагался мощный кластер компьютеров, хранящий огромные объемы оцифрованной информации. Компьютеры на местах соединялись с кластером оптическим кабелем, причем каждые несколько рядов кресел подключались через выделенные концентраторы, что делало систему исключительно быстрой и поразительно мощной. Sony проработала над системой много месяцев, прежде чем обратилась к нам за помощью в проектировании взаимодействия. Инженеры в своей работе над системой продвигались разумными темпами, а вот проектировщики зашли в тупик. В кресле самолета может оказаться кто угодно, поэтому проектировщики пытались учесть все возможные варианты, от абсолютного новичка в компьютерах до компьютерного спеца. Они понятия не имели, как угодить всем этим клиентам. Мы, кстати, тоже не имели понятия, но у нас были мощные методы проектирования, в частности персонажи, и мы были уверены, что сможем решить проблему. Традиционное решение Sony Trans Соm успела спроектировать и создать прототип системы P@ssport с традиционным интерфейсом. Интерфейс очень хорошо ложился на внутреннюю 182 структуру программы. То есть отображал реализацию. По существу, он состоял из глубокой иерархии экранов, через которые приходилось пробираться пользователю, принимая решение на каждом экране. Очевидные минусы такого подхода и заставили фирму обратиться ко мне. Каждый экран представлял дополнительный уровень иерархии, и требовалось пройти шесть экранов, чтобы выбрать фильм. Классический пример «необоснованного решения». На каждом шаге пользователь делает выбор, последствия которого неизвестны. На первом надо выбрать вид развлечения: музыка (Audio), фильмы (Video), игры (Games), покупки (Shop) и т. д. Если выбрать «Video», то все остальные варианты исчезают, а следующий экран требует выбрать категорию фильма. И так экран за экраном, пока на шестом уровне пользователю не удается, наконец, посмотреть ролик и согласиться или отказаться смотреть весь фильм. Отказавшись, он и должен вернуться на шесть экранов назад, к самому началу, и снова пройти шесть экранов, чтобы добраться до следующего фильма. Уф! Поскольку P@ssport функционирует на экране, встроенном в спинку кресла, экран всегда находится в пределах досягаемости пользователя, Сразу было ясно, что сенсорный экран будет отличным естественным решением, превосходящим пульт дистанционного управления, который надо держать в руках. Однако заказчик отверг эту идею. Было очевидно, что двенадцать щелчков на каждый вариант - это много, и среднему пользователю понадобится несколько десятков щелчков, чтобы, наконец, выбрать что-то подходящее. Кроме того, сидящий впереди будет в ярости из-за постоянных прикосновений к креслу сзади. Поэтому заказчик отказался от сенсорных экранов и вернулся к пульту управления, связанному с сиденьем коротким шнуром. 183 Классическая иллюстрация к словам По Бронсона о том, что инженеры продолжают чинить то, что не сломано, пока оно не сломается. Компания просто выплеснула ребенка с водой. Инженеры сожалели о таком решении, однако считали его неизбежным из-за того, что разработка продукта была ограничена во времени. Описанный шестиэкранный интерфейс - классический пример проектирования по модели реализации, точно отражающего внутреннее строение программного обеспечения. Каждый экран с выбором содержал очень мало контекстной или вспомогательной информации, поэтому пользователь не мог почувствовать себя уверенно, что и сделало навигацию неприемлемо сложной. Каждый раз, погружаясь уровнем ниже, пользователь терял из виду контекст. Выбор пункта «Video» лишал возможности выбрать (или даже видеть) другие пункты, такие как «Games». На каждом шаге программа совершенно никак не отражала общую картину, поэтому пользователю оставалось только теряться в догадках. И он выбирал «Video», не зная, какие фильмы можно посмотреть и сколько их. Он выбирал единственную категорию фильма, не понимая, что все эти категории означают. Что за фильм «Правдивая ложь» - приключенческий, романтический или это комедия? Добравшись, наконец, до названий 184 фильмов, пользователь утрачивает и эту информацию. Хм, «Стирательная резинка» - это же, вроде, какой-то художественный фильм про кроткого школьного учителя? Даже на стадии прототипа в интерфейсе уже была красивая трехмерная графика, высокохудожественные пиктограммы, а также метафорическая тема карты-глобуса - все атрибуты хорошего, но пустого интерфейса. Мы называем это «раскраской трупа». Персонажи Как всегда, наш процесс проектирования начался со стадии тщательного исследования, состоявшего в основном из бесед и проходившего в стенах Sony. Мы выслушали большинство людей, работавших над продуктом включая руководителя проекта, руководителя разработки, пару инженеров, руководителя отдела маркетинга, а также руководителя группы развлекательного наполнения системы. В результате мы получили хорошее представление о том, чего пытается достичь Sony Trans Com, выпуская этот продукт. Кроме того, мы увидели некоторую историческую перспективу развлекательных систем гражданской авиации с точки зрения бизнеса и технологии. Вооружившись этим знанием, мы принялись за исследования в полевых условиях и выслушали массу сотрудников авиалиний, в частности стюардесс и стюардов из нескольких компаний. В процессе интервьюирования наша команда проектировщиков постоянно изобретала новые персонажи. Выслушав стюардессу, мы каждый раз создавали персонаж и в результате получили около трех десятков. Чем больше мы слушали, тем больше узнавали, и в конечном итоге стали очевидны сходства персонажей. Обнаруживая, персонажи с общими целями, мы собирали из них один. Наступил момент, когда персонажей осталось всего десять: четыре пассажира и шесть сотрудников авиалиний. Как можно догадаться, сотрудники авиакомпании имели формальные описания должностей, их служебные обязанности легко было понять и принять во внимание при проектировании. Крепким орешком оказался персонаж пассажира. Каждый из четырех персонажей представлял своеобразный архетип, включающий обширный сегмент пользователей, но невозможно спроектировать интерфейс для четырех персонажей. Требуется найти общий знаменатель. Вот как выглядела четверка финалистов: Чак Бургермайстер, деловые поездки. Член клуба сто тысячников, летает практически еженедельно. Его богатый опыт полетов означает, что он вряд ли станет 185 мириться со сложными, отнимающими время интерфейсами, равно как с интерфейсами для полных чайников. Этан Скотт, девятилетний мальчик. Путешествует без сопровождения впервые. Этану интересны игры, игры, еще больше игр. Мари Дюбуа, говорит на двух языках, деловые поездки. Английский для нее второй язык. Ей понравились разделы покупок, а также развлекательных программ. Клевиc Мак-Клауд, старичок, под семьдесят, с причудами. Стареющий, но еще бойкий техасец, немного стесненный начинающимся артритом рук. Этот персонаж - единственный из четырех, который не имеет компьютера и не умеет компьютером пользоваться. Пассажиры Экипаж Odissey AIRLINES Клевис Мак-Клауд Возраст: 65, World Odyssey Class Брент Ковингтон Возраст: 37, старший стюард Мари Дюбуа Возраст: 31, Odyssey Club Class Аманда Кент Возраст: 28, стюардесса Чак Бургермайстер Возраст: 54, Odyssey Gold Class Жан-Поль Дюро Возраст: 33, переводчик-синхронист 186 Этан Скотт Возраст: 9, World Odyssey Class Молли Спрингер Возраст: 41, специалист по обновлению цифровой библиотеки Мел «Хоппи» Хоппер Возраст: 51, механик Джеймс Таттерсолл Возраст: 47, пилот Наш интерфейс должен удовлетворить Чака, Этана, Мари и Клевиса, не причиняя никому из них неудобств. Однако не было речи о том, чтобы сделать всех четверых безумно счастливыми. Этан знает, что игры, игры и снова игры - вещь особая, ради нее можно и несколько лишних кнопочек нажать; лишь бы был результат. Чак знает, что обширный опыт полетов позволяет ему экономить усилия на уже привычных вещах, однако, он готов немного напрячься и запомнить специальные команды. Клевис оказался общим делителем. У него не было компьютера, и он не стремился им обладать. Его девиз: «Старого пса новым штукам не выучишь» он не глуп и не ленив, а просто не любит высокие технологии. Мы знали, что, поместив на экране диалоговое окно с шапкой и кнопкой «Закрыть», мы моментально потеряем Клевиса. Отсюда следовала полная непригодность привычных компьютерных интерфейсов. Мы также понимали, что его артрит не позволит совершать сложные манипуляции. Система должна подчиниться неточным движениям его рук. Любое решение, ориентированное на Чака, Мари или Этана, было бы 187 неприемлемым для Клевиса, которого напугали бы и запутали сокращенные команды (Чaк) и выбор языка (Мари). Мельтешащие игрушки Этана будут Клевису только мешать при этом решение, способное осчастливить Клевиса, странноватого старого луддита, будет абсолютно приемлемо для всех остальных, если их особые потребности будут учтены в интерфейсе. Чак и Марш летают уже давно: и смогут сориентироваться в любой системе, если он не потребует длительного обучения. Мы понимали, что простая и наглядная система не подразумевает длительного привыкания, так что Чака и Мaри не обидим. С Этаном еще проще, о нем известно заранее, что он быстро и активно освоит систему и разберется со всем, что она предлагает. Он будет доволен, если сможет найти свои игрушки. На протяжении всего проекта главным ориентиром был Клевис. Его изображение стало вашим боевым штандартом. Идеальная для Клевиса система сделала бы счастливыми и всех остальных пассажиров, всех до единого. Он стал нашим ключевым персонажем, мы проектировали систему для него и только для него. Проектирование для Клевиса Клевис не имел опыта работы с компьютерами, как и терпения, позволяющего дождаться вознаграждения, пройдя через многочисленные испытания программы. Решение проблемы навигации для Клевиса было простое: он не может не будет заниматься «навигацией», поэтому экран может быть только один. Из нежелания Клевиса исследовать интерфейсвытекала необходимость создать продукт, не прячущий информацию. Мы экономим на вариантах выбора, но щедро делимся информацией. Мы превратили экран в горизонтальную прокручивающуюся ленту, на которой размещались постеры фильмов и обложки альбомов. Мы создали крупную цилиндрическую рукоятку и назвали ее «информационная рукоять». Эту кнопку Клевис мог вращать как верньер радиоприемника. Рукоятка была не нарисована на экране, а физически присутствовала под ним. При повороте происходила прокрутка ленты с постерами: поворот по часовой стрелке прокручивал ленту вправо, а против часовой - влево. 188 Клевис просматривает постеры точно так же, как витрины магазинов, идя по улице. Ему не нужно выбирать категорию фильма и даже задумываться о ней. Мы отказались от древовидной иерархии - никто не будет долбить по экрану, как дятел, поэтому мы вернули к жизни сенсорный экран. Заинтересовавшись фильмом, Клевис касается постера и мгновенно получает рекламный ролик, вместе с текстом, информацией об актерах и стоимости просмотра. Еще одно касание, и он сможет начать просмотр фильма или продолжить прогулку по «Фильм-стрит». Постеры на ленте расположены в одной плоскости, на единственном слое и распределены по группам. Мы часто заменяем такими группами иерархии в интерфейсах. Предметы на поверхности вашего рабочего стола, вероятно, расположены примерно так же, равно как книги на полках и вещи в ящиках. Все люди, включая Клевиса, Мари, Этана и Чака, очень быстро и легко осваиваются с таким размещением информации. При этом «категория» фильма из обязательного выбора превращается в полезное свойство. Клевис может присмотреться к постерам и понять, к какой категории принадлежит тот или иной фильм, прежде чем начинать просмотр. Такой подход решает и проблему принадлежности фильмов к категориям. К примеру, фильм «Правдивая ложь» одновременно фигурирует в жанрах боевика, фильма одного актера, приключенческого фильма, фильма с обилием спецэффектов, романтического фильма и комедии иерархический подход вынудил бы поместить фильм в одну из категорий, а в выбранном нами варианте атрибуты фильма можно занести во все категории. При прокрутке за постерами фильмов без всякой паузы следуют обложки музыкальных альбомов, а затем постеры игр. Библиотека невелика, и Клевис может быстро добраться до нужного места. Рукоять достаточно крупна не слишком 189 чувствительна, поэтому даже Клевису с его большими, загрубевшими, уже пораженными артритом руками нефтяника не трудно ее вращать. Панель навигации в нижней части экрана сообщает Клевису, что есть несколько обширных развлекательных категорий, а небольшой индикатор на той же панели перемещается, указывая его текущее положение на шкале выбора. Программисты Sony попали в ловушку трех чисел - нуля, единицы и бесконечности. На практике система P@ssport способна справиться примерно с тремя дюжинами фильмов. С точки зрения программиста число 36, будучи больше нуля и единицы, эквивалентно бесконечности, а представление бесконечного числа фильмов вызвало осложнения, что и стало причиной возникновения иерархии категорий. Но Клевису по душе прокрутка трех десятков вариантов. Даже если бы фильмов было несколько сотен, ему все равно была бы приятна эта прогулка - он вспоминал бы фильмы, которые уже видел, и предвкушал бы просмотр новых. Хорошую службу тут сослужили постеры, которые передают существенную информацию о каждом фильме: об актерах, о сюжете, о настрое фильма. Инженеры это понимали, но беспокоились, что присутствие постеров нагрузит поставщиков цифровых фильмов ненужной работой. Когда мы проговорились об идее некоторым из них, реакция поставщиков была прямо противоположной. Они восторгались при мысли, что можно протащить постеры в интерфейс. В конце концов, они потратили сотни тысяч долларов на создание постеров, передающих наиболее лаконичным способом максимум возможной информации о кинокартине, причем передача эта рассчитана на самую широкую аудиторию. Почему же не использовать результаты этих трудов в самолете? Они сочли это замечательной новой возможностью создать иллюстрации для продукта. 190 Мы спроектировали интерфейс для одного ключевого персонажа, но предприняли ряд усилий, чтобы удовлетворить нужды и вспомогательных персонажей. Чак Бургермайстер, завсегдатай авиалиний, захочет пользоваться сокращенными командами для быстрого доступа, и такие возможности в интерфейсе присутствуют, незаметные для Клевиса. Если Чаку необходимо переместиться в другую развлекательную категорию быстрее, чем позволяет рукоять, ему достаточно коснуться панели навигации. Программа мгновенно прокручивает ленту до указанной группы, уже без участия Чака. Клевису даже и знать не нужно об этой постоянно доступной возможности, однако ее очень легко обнаружить и изучить, поэтому более опытные путешественники, такие как Чак и Мари, смогут быстро освоиться, самостоятельно или понаблюдав за соседями. В отличие от изображений на экране, физические органы управления располагают к манипуляциям. Увидев впервые рукоять, Клевис может по ее форме и положению определить, как с ней обращаться. И хотя Клевис не может определить заранее результат вращения, достаточно лишь немного повернуть кнопку, и ее действие становится совершенно очевидным, поскольку экран реагирует прокруткой ленты с постерами. Еще вероятнее, что Клевис увидит, как другие пассажиры вращают рукоятки, а ленты с постерами прокручиваются соответственно. Прямая связь между рукоятью и экраном тривиальна, и вот уже Клевис научился работать с развлекательной системой. * * * Я описал лишь интерфейс, спроектированный нами для Клевиса Мак-Клауда, пассажира. Мы спроектировали еще два более емких интерфейса для двух оставшихся ключевых персонажей, Аманды Кент, стюардессы, и Мела Хоппера, механика. Цели этих людей отличаются от целей Клевиса. Позаботившись о безопасности пассажиров, Аманда должна сосредоточиться на обслуживании, чтобы каждый пассажир остался максимально доволен полетом. Интерфейс для нее должен содержать органы управления всеми операциями в полете. К примеру, если Чак (место 24С) захочет пересесть, потому что Клевис (место 24В) уснул и громко храпит, Аманда должна иметь возможность перенести счет Чака и до половины просмотренный фильм на пустое место 19D, куда он пересаживается. Основное требование для Хоппи - быстрая оценка состояния системы. Он определяет, какие есть неполадки, насколько они серьезны и что он может сделать, чтобы исправить ситуацию. 191 Аманда и Хоппи пользуются одним экраном, расположенным на посту стюардов, однако их интерфейсы очень сильно различаются, поскольку различаются их цели. * * * При желании проектировать программные продукты, делающие людей счастливыми, вы должны с некоторой степенью уверенности знать, кто эти люди. Вот почему нужны персонажи. Следующий шаг - спроектировать продукт как можно более мощный, а чтобы это сделать, необходимо знать все о целях пользователей. |