ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 11.01.2024
Просмотров: 771
Скачиваний: 35
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
223
Бетси по-прежнему желала создавать классные, мощные, динамические сайты, но самая важная цель для нее стала иной. То, что было целью гигиенической и воспринималось Бетси как данность, но вскоре исчезло, получило теперь фокус внимания. Главной целью Бетси снова стала независимость, освобождение от Эрни. Она хотела иметь возможность начать отношения с клиентом, спроектировать, создать мощный, красивый, динамический сайт, функционирующий на основе базы данных, и
при этом не ждать, когда Эрни, наконец, разгадает какую-нибудь техническую
головоломку.
Изначально мы намеревались сделать инструменты Бетси более мощными, при этом сохранив простоту применения. Оставаясь весьма привлекательным, такой продукт всего лишь давал Бетси отсрочку в общении с Эрни, не позволяя ей достичь самой важной цели. Чтобы добиться успеха с Бетси, мы должны были спроектировать Drumbeat, позволяющий вовремя и самостоятельно завершать все проекты.
Эрни тоже не был абсолютно счастлив, работая с Бетси. Все, что он делал, требовало одобрения Бетси, и она постоянно придиралась по поводу пиксела там, пиксела здесь - к тому, что, по его мнению, никакой роли не играло. Она требовала переделывать уже сделанное по пять-шесть раз, вносить ненужные, как он считал, изменения, прежде чем согласиться, что работа готова. Он хотел получить независимость от Бетси не меньше, чем она желала получить независимость от него.
Проектирование
На этом этапе мы смогли обосновать свою точку зрения. Вместо того чтобы давать
Бетси отсрочку в общении с Эрни, мы должны были возвести между ними непроницаемую стену и дать независимость обоим. Бетси по-прежнему будут нужны функции, которыми ранее ведал Эрни, и, в конце концов, Бетси для Эрн и была неплохим источником дохода, поэтому их коммерческие отношения необходимо сохранить, тогда как их деятельность необходимо четко разграничить.
Строить стену между ними было необходимо на основе стандарта - интерфейса, позволяющего создавать и использовать функциональные модули. Эрни следует дать интерфейс программиста, позволяющий работать кодом, а Бетси - интерфейс дизайнера сайтов. Общей и нейтральной территорией стала бы программа Drumbeat. Эрни сможет писать мощные, гибкие модули и публиковать их при помощи функционального
224 интерфейса Drumbeat. Бетси будет применять эти модули посредством интерфейса визуального программирования Drumbeat.
Теперь Бетси сможет создавать динамические сайты, работающие с базами данных, посредством опубликованных модулей, никогда не встречал автора этих модулей. Эрни сможет создавать, публиковать и продавать функциональный код, никогда больше не трогая цвет фона. Освободив эти два персонажа, мы помогли Бетси в области дизайна и производства, а Эрни - в области программирования.
Теперь Эрни выступает в роли автора инструментов, а не программиста, выполняющего заказы. Он создает подключаемые модули, которые могут становиться частью инструментария Бетси. У его модулей более широкая аудитория, поскольку он может продавать их многим другим Бетси, которые, в свою очередь, будут применять эти модули для многочисленных сайтов.
Случай интересен тем, что проектирование взаимодействия оказало значительное влияние как на внутреннюю структуру продукта, так и на позиционирование продукта на рынке. Это хороший пример, показывающий, как проектирование влияет на начинку, описывая всего лишь внешние проявления.
Откат
Разработчики Elemental поначалу решили, что наше решение не сработает, поскольку сразу представили себе ряд вырожденных случаев, когда Бетси все равно понадобятся особые таланты Эрни. «Нельзя совсем исключать Эрни из цикла, - заявили
225 они, - поскольку Бетси может понадобиться решить какую-то особую или сложную задачу».
Что ж, подумали мы, это справедливо, однако лишь в редких случаях. В большинстве же случаев она работает независимо, тогда как при текущем положении дел о независимости и мечтать не приходится. В этих редких вырожденных случаях она просто будет возвращаться в прежнюю ситуацию зависимости от Эрни. Это определенно не ухудшает состояние дел, а в большинстве случаев заметно улучшает.
Независимость важна для Бетси, и ради ее достижения она готова на соразмерные жертвы. Drumbeat позволяет ей создавать полноценные сайты без помощи Эрни, и это примиряет ее с небольшими компромиссами в дизайне, открывающими доступ к готовым программам Эрни
1
. Жертва невелика, поскольку запросы большинства клиентов укладываются в стандартные схемы. Если она получит контракт на создание корпоративно сети для универмагов Wal-Mart или системы оперативного резервирование для отелей Hilton, то определенно задействует человека, обладающего талантами разработчика, чтобы он помог справиться с этими монументальными задачами, но в большинстве случаев это не требуется.
Прочие моменты
Изначально в программе было множество плавающих панелей с разнообразными инструментами для рисования, и каждая заслоняла часть макета создаваемого сайта. В
Elemental все свыклись с идеей, что пользователям нравится гонять панельки по экрану в процессе работы. При каждой демонстрации продукта разработчики гордо хвастались этими панелями.
Участники нашей команды проектировщиков в один голос заявили, что панели назойливы, сложны и совершенно излишни. Разумеется, необходимо обеспечивать доступ к инструментам, но мы знали и более привлекательные способы. Однако каждый раз, когда мы отрицательно отзывались о панелях, программисты (и руководители разработки) тут же заявляли, что панели всем очень нужны.
Наблюдая, как реальные Бетси работают с продуктом, мы скоро поняли, почему плавающие панели были настолько популярны. Изначально программа была спроектирована так, что без панелей было не обойтись. Большинство инструментов
1
Создание сайтов – это программирование, и Бетси точно так же не способна сопротивляться очарованию повторного использования кода.
226 каждой панели редко находили применение, но при этом на каждой панели было по меньшей мере два очень полезных и востребованных инструмента. То есть Бетси нужны были все панели для решения самых простых задач. Из-за лишних инструментов каждая панель была чересчур велика, и все панели плавали поверх изображения сайта, находящегося в разработке, поэтому, работая над сайтом, Бетси постоянно приходилось перемещать панели. Альтернативный режим позволял зафиксировать панели вдоль одной из границ экрана, но это означало лишь, что Бетси придется постоянно прокручивать изображение сайта. Бетси попала в безвыходное взаимодействие. Она могла терять время на ненужную прокрутку или на перемещение панелей. Такие ненужные для пользователя действия мы называем «акцизами», и изначально программа была ими насыщена.
Мы понимали, что под рукой должны быть только инструменты, применяемые часто, и для решения проблемы все инструменты лучше поместить в одно место. Иначе
Бетси запутается.
Путем простой реорганизации и отсеивания нечасто востребуемых функций мы значительно уменьшили размеры панелей. После этого мы закрепили панели в определенных точках. Так панели стали практически незаметной составляющей интерфейса. Вот хороший пример, показывающий, как целеориентированное проектирование снижает объем кода, необходимого для создания интерфейса.
* * *
Как проектирование, так и продукт стали успешными. Ближе к завершению работ над версией, основанной на наших исследованиях, Elemental удалось получить значительное венчурное финансирование, не в последнюю очередь благодаря инновациям во взаимодействии. После выхода в свет Drumbeat получил многочисленные положительные отзывы в отраслевой прессе. Эта цитата из журнала «РС» вполне отражает ситуацию.
«Drumbeat - продукт уникальный и впечатляющий, его возможности автоматизации сложных веб-задач превосходят все другие присутствующие на рынке решения. Продукт позволяет непрограммистам решать задачи очень просто. Вы сможете создавать огромные профессиональные сайты и даже применять технологию Active Server Pages, не написав и строчки кода.»
Этот продукт стал успехом несмотря на то, что многие другие программы для
227 создания сайтов пробились на рынок раньше.
* * *
Как видите, взгляд на вещи через призму пользовательских целей может дать уникальную и обладающую невероятным потенциалом перспективу, открывающую новые возможности для творчества. Это и есть основа целеориентированного проектирования.
1 ... 13 14 15 16 17 18 19 20 21
Глава 11. Проектирование для людей
В предшествующих главах я описал персонажи и подчеркнул превосходство целей над задачами. Только если у нас есть персонажи и мы представляем себе их цели, мы можем начать изучение задач без боязни, что они помешают процессу проектирования.
Свой инструмент для рассмотрения задач мы называем «сценариями». Сценарий - это сжатое описание способов применения программного продукта персонажем для достижения цели. Эта глава посвящена сценариям, а также ряду других полезных инструментов проектирования. Она содержит и примеры работы этих инструментов, в частности сценариев в реальных проектах.
Сценарии
По мере детализации проектирования эффективность сценариев повышается. Наши персонажи проходят через эти сценарии, словно актеры, читающие роли, что позволяет проверять корректность проектирования и выдвинутые предположения. Неудивительно, что наш сценарный процесс часто сравнивают с игрой по Станиславскому - актер должен вжиться в роль, знать то, что знает персонаж, чувствовать то, что чувствует персонаж.
Мы стараемся думать так, как думает он. Мы забываем о собственном образовании, способностях, подготовке, инструментах и думаем, что обладаем лишь данными и биографией персонажа. Поскольку мы проектировщики, а не актеры, без контекста и конкретных деталей может быть нелегко, поэтому сценарии оказываются большим подспорьем. Зная, к примеру, что Бетси пытается создать сайт для страховой компании, нам проще ставить себя на ее место. И это не так странно, как может показаться. Ведь программисты ставят себя на место своих компьютеров. Программисты привычно описывают действия компьютера от первого лица, они говорят: «Я обращаюсь к базе данных, а затем сохраняю записи в буфере». Человек говорит «я», но всю работу на самом деле выполняет компьютер. В роли компьютера человеку проще симпатизировать
228 потребностям машины в процессе написания кода.
Сценарии создаются на основе информации, собранной в ходе первой фазы - исследования. Обычно в ходе интервью и непосредственного наблюдения за пользователями удается много узнать об их задачах. Цели стабильны и неизменны, задачи же неустойчивы, подвержены изменениям и часто оказываются ненужными в компьютеризованных системах. В процессе разработки сценариев мы стараемся находить и вычеркивать задачи, существование которых обусловлено лишь исторической необходимостью.
Эффективность сценария определяется в большей степени его охватом, чем глубиной. Иначе говоря, важнее, чтобы сценарий описывал процесс от начала до конца, чем чтобы он описывал каждый шаг в исчерпывающих подробностях.
Важно развивать лишь те сценарии, которые позволяют продвигаться вперед в процессе проектирования и не плутать в дебрях исключительных ситуаций. Мы разрабатываем лишь два вида сценариев, хотя сценариев каждого вида может быть и несколько. Это сценарии повседневные и сценарии обязательные.
Повседневные сценарии
Повседневные сценарии - самые полезные и важные. Они описывают основные действия, которые пользователь выполняет чаще всего. Так, для системы сопровождения программных ошибок типичные повседневные сценарии - поиск записей о дефектах и заполнение форм о свежевыявленных дефектах. Любой сотрудник технической поддержки выполняет эти две задачи ежедневно и по многу раз.
В общем случае для большинства пользователей репертуар повседневных сценариев оказывается весьма ограниченным. Чаще это один или два сценария. И редко их бывает больше трех.
Повседневные сценарии нуждаются в самой надежной поддержке качественным взаимодействием. Новые пользователи должны быстро овладевать такими сценариями, а значит, требуется качественная поддержка быстрого обучения. То есть инструкции по применению должны быть написаны у программы «на лбу». Однако частота повторений вскоре приводит к ненужности инструкций, поэтому у пользователей быстро появляется потребность в ускоренных методах работы, таких как клавиатурные сокращения. Кроме того, по мере при обретения опыта пользователи начинают ощущать потребность в
229 подгонке повседневных взаимодействий под индивидуальный стиль работы и личные предпочтения.
Обязательные сценарии
Обязательные сценарии описывают все действия, выполняемые и нечасто, но неукоснительно. Очистка баз данных и создание исключительных запросов могут оказаться именно в этой категории сценариев.
Обязательное взаимодействие также требует поддержки механизма обучения.
Однако пользователь никогда не перейдет на более высокий уровень прохождения таких сценариев. Редкое применение означает, что любой пользователь согласится с механизмами, предложенными программой, поэтому индивидуализация не потребуется.
Это освобождает разработчиков от необходимости обеспечивать тот же уровень доводки которого требует повседневный сценарий. Примерно так же роскошный интерьер салона нового Ягуара и отличается от грубого металла его подкапотного пространства.
В большинстве продуктов репертуар обязательных сценариев достаточно ограниченный, но количество последних обычно превышает количество сценариев повседневных.
Сценарии исключительных ситуаций
Разумеется, существует третий вид сценариев - сценарии для исключительных ситуаций. Программисты, естественно, обращают особое внимание именно на них, но в процессе проектирования продукта эти сценарии можно игнорировать. Это не означает, что соответствующей функциональности нет места в программе, но означает, что взаимодействие для таких сценариев можно проектировать грубо и упрятывать в глубины интерфейса. Работоспособность кода может зависеть от того, обрабатываются ли исключительные ситуации, а успех продукта зависит от способности справляться со случаями, описанными в сценариях повседневных и обязательных.
Если пользователь решает некую задачу часто, то взаимодействие в данном месте программы должно быть продумано до мелочей. Точно так же, если задача выполняется редко, но в любом случае, то взаимодействия для этой задачи, пусть и преследующее иные цели, должно быть спроектировано качественно. Задачи, не являющиеся обязательными или повседневными, просто не требуют тщательного проектирования.
Времени и денег всегда не хватает, поэтому такие задачи - хорошая возможность
230 сэкономить ресурсы и потратить их на то, что приносит больше пользы. Мы должны создать все сценарии, но тщательно проектировать интерфейс следует лишь для сценариев важных или применяемых постоянно.
* * *
Персонажи, цели и сценарии - тяжелая артиллерия проектировщика. Прежде чем перейти к примеру применения сценариев, поговорим о некоторых других полезных понятиях проектирования: адаптирующемся интерфейсе, вечных середняках, словаре, мозговом штурме и нестандартном мышлении.
Адаптирующийся интерфейс
Взаимодействие всегда можно упростить - достаточно удалить функции и сделать продукт менее функциональным. В большинстве случаев такая тактика неприемлема.
Более сложные задачи проектирования требуют простоты применения продукта без принесения в жертву функциональности и мощи. Это сложно, но выполнимо. Здесь требуется лишь техника, которую яназываю адаптирующимся интерфейсом.
Программа должна предоставлять массу функций, но в конкретный момент времени конкретному пользователю для конкретной задачи нужны далеко не все функции. Для каждого сценария персонажу требуется лишь небольшое подмножество органов управления и данных, хотя этот набор может меняться с течением времени и при изменении решаемой задачи. Интерфейс станет на порядок проще, если органы управления и данные, необходимые для повседневных сценариев, будут бросаться в глаза, тогда как все прочие элементы интерфейса отойдут на второй план, за пределы поля зрения.
Интерфейсы большинства крупных программ очень похожи на меню в китайских ресторанах, где каждая страница испещрена сотнями пунктов. Возможно, для ужина именно это и нужно, но в продуктах высоких технологий только мешает.
В Мiсrоsоft Word, к примеру, стандартная панель инструментов содержит пиктограммы для загрузки документа, закрытия и печати текущего документа.
Перечисленные задачи выполняются с разумной частотой, и присутствие пиктограмм оправданно. Однако здесь же, рядом, располагаются пиктограммы, генерирующие схему документа и внедряющие в документ электронные таблицы. Мiсrоsоft поместила эти пиктограммы в Основном рабочем пространстве, чтобы мы смогли оценить мощь Word.