СОДЕРЖАНИЕ
ВВЕДЕНИЕ
1.Анализ предметной области
1.1Оценка и изучение предметной области
1.2Определение необходимой функциональности системы
1.2.1Анализ целей пользователей
1.2.2Анализ действий пользователей
1.3Создание пользовательских сценариев
2.Высокоуровневое проектирование
2.1Проектирование структуры экранов системы
2.2Проектирование навигационной системы
2.3Проектирование структуры справочной системы
3.Низкоуровневое проектирование
3.1Проектирование экранов клиентской части
3.2Проектирование экранов администраторской части
3.3Тестирование
3.4Экспертная оценка
4.Построение прототипа пользовательского интерфейса
4.1Этапы построения прототипа
4.1.1Бумажный
4.1.2Презентационный
4.1.3Псевдореальный
4.1.4Реальный
5.Тестирование и модификация прототипа
ЗАКЛЮЧЕНИЕ
СПИСОКИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ
ВВЕДЕНИЕ
Одной из важнейшихзадач, практически всегда стоявших перед человечеством, является сохранениеинформации во времени и пространстве. Со времён возникновения книгопечатиосновной формой хранения и распространения информации являются книги (печатныеиздания), а главными средствами хранения и доступа к информации сталибиблиотеки.
Сохранение ииспользование рукописных и печатных документов достаточно хорошо освоено. Здесьимеется богатый опыт, результаты исследовательской и практической работы многихпоколений специалистов. Но очевидно, что с постоянным увеличением объёмовинформации, работа с ней (такая как хранение, поиск, учёт и т.д.) становитсявсё сложнее. Развитие вычислительной техники позволило сохранять ираспространять информацию в электронной форме. Это играет революционную роль вистории человечества, сравнимую с изобретением книгопечати.
Электронная формапозволяет хранить информацию в более надёжном, компактном и удобном виде,увеличивается скорость и простота её распространения. Немаловажно и то, что вэлектронной форме, в отличие от печатной, информацией можно свободноманипулировать. В связи с этим, количество электронных публикаций с каждымгодом растёт.
Виртуальная библиотека- это информационная система, позволяющая надёжно сохранять и эффективноиспользовать разнообразные коллекции электронных документов, локализованных всамой системе, а также доступных ей через телекоммуникационные сети.
Существенное развитиеработы по электронным библиотекам получили на рубеже 90-х годов, когдапоявились адекватные средства вычислительной техники и информационныетехнологии, обеспечивающие надёжное сохранение, оперативную обработку иэффективное использование больших массивов разнородной информации, прежде всеготекстовой. Именно в это время в ряде стран стали подготавливаться проектыцифровых библиотек.
Основные задачивиртуальной библиотеки:
- интеграцияразнородных информационных ресурсов;
- регистрация(публикация) новых данных;
- хранениеи предоставление доступа к таким данным;
- координациядругих электронных коллекций по профилю данной библиотеки.
Под интеграциейинформационных ресурсов понимается их объединение с целью использования (спомощью удобных и унифицированных пользовательских интерфейсов) различнойинформации с сохранением её свойств, особенностей представления и пользовательскихвозможностей манипулирования с ней. При этом объединение ресурсов необязательно должно осуществляться физически, оно может быть виртуальным.Главное, чтобы оно обеспечивало пользователя возможностью воспринимать доступнуюинформацию как единое целое. Новые технологии, разрабатываемые в этой области,прежде всего и ориентированы на решение этой важнейшей задачи. В частности,цифровые библиотеки принесли с собой новый, более высокий уровеньсемантического описания.
Эффективная навигация вэлектронной библиотеке понимается как возможность пользователя находитьинтересующую его информацию с наибольшей полнотой и точностью при наименьшихзатратах усилий во всём доступном информационном пространстве. При такомподходе хорошо известные информационные поиски, используемые в информационныхсистемах и базах данных, являются частными случаями навигационных средств.
На сегодня, печатнаяинформация является основным источником формирования цифровых библиотек.
1.Анализ предметной области
Предметная область — это материальная система или система, характеризующая элементы материальногомира, информация о которой хранится и обрабатывается. Предметная областьрассматривается как некоторая совокупность реальных объектов и связей междуними. Каждый объект обладает определённым набором свойств (атрибутов).
1.1Оценка и изучение предметной области
Для того чтобыадекватно оценить ресурсы (время, деньги, количество экспертов), которые будетнеобходимо потратить на разработку (переработку) интерфейса, необходимо четкопредставлять себе объем информации, с которой следует ознакомиться.
Чтобы предлагатьадекватные интерфейсные решения заказчику, необходимо иметь четкоепредставление о предметной области системы. Предметная область изучается политературе. Наряду с этим, как правило, проводится серия интервью с экспертамидля выяснения основных аспектов и характеристик предметной области.
После получениянеобходимых знаний об интересуемой предметной области, следует экспертнаяоценка текущего интерфейса системы. Вместе с собственными «жалобами» заказчикана текущую версию системы, результаты этого этапа составляют основноесодержание работы над проектом (экспертная оценка часто обнаруживает проблемы,которые заказчику не видны, маскируясь под другие). Проблемы, выявленные наданном этапе, должны быть решены в новом интерфейсе, а удачные решенияжелательно сохранить, чтобы имеющимся пользователям не пришлось полностьюпереучиваться (и чтобы сократить затраты на переделку). Основное вниманиеуделяется не удачным решениям в существующем интерфейсе. Если на этом этапепроводилось юзабилити-тестирование текущей версии, отчет содержит краткиепротоколы и перечень выводов исследования.
1.2Определение необходимой функциональности системы
На первом этапенеобходимо определить функциональность будущей системы. Это исключительноважный этап, поскольку именно функциональность будет определять весь интерфейс.Очень важно сознавать, что практически невозможно убрать из уже продающейсясистемы какие-либо функции. Во-первых, программы до сих пор продаются пофункциям, т.е. чем больше список функций на коробке с программой, тем легче еёпродать, даже если большинство функций либо не работает, либо не нужнопользователям. Происходит это потому, что существенную часть тиража программы покупаютновые пользователи, которые ничего не знают про истинное положение вещей.Во-вторых, имеющиеся пользователи обычно с исключительной неохотойпереучиваются для использования новых функций взамен прежних (при этом еще иобижаются из-за того, что их инвестиции в обучение оказались выброшенными наветер). Это значит, что ненужная функция системы будет кочевать из версии вверсию, раздувая размеры программы, снижая надежность и быстродействие, и, чтодля нас более важно, портя интерфейс (при этом и длительность разработкивозрастает). Несколько лучшая ситуация с сайтами — никого пока не удивляет,когда сайт после изменения дизайна почти не напоминает прежний. Так чтооптимальным вариантом работы почти всегда является проектированиефункциональности сразу на несколько версий вперед.
Традиционно требованияк функциональности исходят от отдела продаж или от его аналога. Такиетребования имеют два источника, а именно жалобы имеющихся клиентов и системыконкурентов. К сожалению, оба эти источника сомнительны.
Всегда может оказаться,что желание клиента получить новую функцию, обусловлено не реальнойпотребностью в ней, а собственно концептуальными проблемами системы. Системы жеконкурентов страдают как от такого же непонимания проблемы, так и от множествадругих причин. Это значит, что прислушиваться к сторонним требованиям ксистеме, безусловно, следует, но рассматривать эти требования нужно не какдирективы, но как признаки общего неблагополучия. Некой фирмой было разработанотехническое задание к системе каталогизации изображений, рассчитанной надомашних пользователей, которая состояла из сведенного в таблицу списка всехфункциональных возможностей всех конкурентов. В результате система получилаогромное количество никому не нужных возможностей, что не только никак непомогло ей на рынке, но и безмерно удлинило срок её разработки.
Существует двапринципиально разных подхода к определению функциональности системы. При первомподходе система снабжается максимальным количеством функций, при этомрезультаты многих из них являются суммой результатов других функций. При другомподходе все составные функции (метафункции) из системы изымаются. Яркимпредставителем первого подхода является CorelPhotoPaint, не менее яркимпредставителем другого — AdobePhotoShop.
Оба подхода имеют какнедостатки, так и достоинства. Подход, при котором количество функцийограничено, позволяет упрощать интерфейс, но при этом требует от пользователяпонимать, как из многих низкоуровневых функций «собирать»более сложные. Подход,при котором помимо низкоуровневых функций есть высокоуровневые, позволяетпотенциально обеспечивать большую скорость работы (за счет отсутствия паузмежду низкоуровневыми функциями), но зато требует от пользователя знаний о том,где эти высокоуровневые функции найти и как с ними работать, при этом ониперегружают интерфейс.
Судя по всему, людямбольше нравится пользоваться низкоуровневыми функциями, поскольку это позволяетдобиваться более тонких и предсказуемых результатов. С другой стороны,доказательств этого не так уж много (сам факт того, что PhotoShop продаетсялучше, чем PhotoPaint, говорит не так уж о многом). Таким образом, выборподхода не слишком прост. С другой стороны, остается возможность компромисса:всегда можно включить в систему средства автоматизации, чтобы пользователиполучали возможность создавать (и распространять) свои метафункции, каковойподход как раз и применен в PhotoShop.
Так как всё-такиопределить нужную функциональность? Современная наука выдвинула два основныхспособа, а именно анализ целей и анализ действий пользователей. Эти способыфактически не конфликтуют друг с другом, более того, в процессе определенияфункциональности желательно использовать оба.
1.2.1Анализ целей пользователей
Идеей, лежащей в основеданного метода, является простое соображение, гласящее, что людям не нужныинструменты сами по себе, нужны лишь результаты их работы. Никому не нуженмолоток, если не нужно забивать гвозди. Никому не нужен текстовый процессор, нонужна возможность, с удобством, писать тексты. Никому не нужна программаобработки изображений — нужны уже обработанные изображения.
Разработчику необходимочетко осознавать, что пользователям не нужны инструменты сами по себе, нужнылишь результаты их работы. Никому не нужен текстовый процессор — нужнавозможность с удобством писать тексты. Никому не нужна программа обработкиизображений — нужны уже обработанные изображения. Это значит, что сами по себефункции никому не нужны и не важны. Людям нужно средство, позволяющее выполнятькакую-либо работу.
Ни в коем случае нельзядать обмануть себя ненужной конкретикой, т.е. описанием того, какова должнабыть будущая функциональность. Как правило, одного и того же результата можнодобиться несколькими разными способами, при этом важно не только реализоватькакой-либо способ, но и выбрать лучший.Результатом этого процесса долженявляться список целей.
Анализ целейпользователя виртуальной библиотеки: «Виртуальная библиотека должна иметьсписок доступных книг, из которых человек сможет выбирать интересующие его. Вней обязательно должна присутствовать поисковая система (для более удобнойнавигации). Помимо клиентской части приложения должен быть и некий редактор,позволяющий манипулировать информацией цифровой библиотеки».
После того, какистинные цели пользователей установлены (и доказано, что таких пользователейдостаточно много, чтобы оправдать создание системы), приходит время выбиратьконкретный способ реализации функции, для чего используется второй метод.
1.2.2Анализ действий пользователей
Достижение почти всехцелей требует от пользователей совершения определенных действий. Разумеется,эти действия могут различаться при разных способах достижения. В сколько-нибудьсложных интерактивных системах сами по себе выбранные стратегии действий влияютна требования к функциональности.
В компьютерных системахвзаимодействие сложнее, чем в реальности, при этом логический анализнеприемлем.Единственным выходом является банальное наблюдение за людьми,выполняющими свою задачу, пользуясь уже имеющимися инструментами, а именно системамиконкурентов (если они есть) и предметами реального мира (поскольку оченьнемного новых действий появилось только после появления компьютеров). Неплохимисточником материала для анализа часто служит даже не наблюдение за людьми, ноанализ результатов их работы — если оказывается, что результат работыпрактически не зависит от используемого инструмента, это значит, что нужнатолько та функциональность, которая оказала воздействие на результат (т.е.функции, которыми никто не воспользовался, не нужны).
Тут очень важноизбежать эгоцентризма. Очень трудно отказаться от мысли «если это нужно мне,это нужно и многим». Возможно, что и нужно. А возможно, что и нет. Единственнымже способом проверить, нужна функция или нет, является наблюдение запользователями и анализ их действий.
Как уже было сказано,обычно есть несколько разных способов реализации одной и той же функции. Анализдействий пользователей как раз и позволяет определить, какой именно способследует реализовывать. Поскольку на этом этапе мы узнаём, какая именнофункциональность нужна для каждого варианта, можно избрать верный путь поправилу «чем меньше действий требуется от пользователя, тем лучше» (благокомпьютер есть, прежде всего, великое средство автоматизации). Не стоитзабывать и про другое правило: чем меньше функций, тем легче их сделать.
1.3Создание пользовательских сценариев
Цель этого этапа — написать словесное описание взаимодействия пользователя с системой, неконкретизируя, как именно проходит взаимодействие, но уделяя возможно большеевнимание всем целям пользователей. Количество сценариев может бытьпроизвольным, главное, что они должны включать все типы задач, стоящих передсистемой, и быть сколько-нибудь реалистичными.
Сценарии будут полезныдля последующего тестирования, поскольку тестируется не выполнение абстрактныхзадач, а выполнение конкретных, входящих в эти сценарии, операции. Да и самфакт их написания обычно, хоть и не всегда, приводит к лучшему пониманиюустройства проектируемой системы, побуждая сразу же оптимизировать будущеевзаимодействие.
Сценарий взаимодействияпользователя с виртуальной библиотекой: «Пользователь открывает программу,выбирает книгу из каталога и начинает её чтение».
Сценарий взаимодействияадминистратора с программой: «Администратор открывает редактор, выбираетсуществующую книгу для редактирования или добавляет новую в список».
2.Высокоуровневое проектирование
2.1Проектирование структуры экранов системы
На этом этапе,основываясь на сценариях работы и ролях пользователей, формируется структураэкранов системы, т.е. определяется количество экранов, функциональность каждогоиз них, навигационные связи между ними, формируется структура меню и другихнавигационных элементов.
По сути, на этом этапевыделяются отдельные функциональные блоки. Под функциональными блоками будетподразумевать функцию или группу функций, связанных по назначению или областиприменения в случае программы и группу функций/фрагментов информационногонаполнения в случае сайта.
Программное обеспечение«Виртуальная библиотека» будет состоять из двух частей: клиентской (Таблица2.1) и администраторской (Таблица 2.2).
Таблица 2.1 — функциональныеблоки клиентской части приложения.
Основной экран
Навигация между различными наименованиями книг Поиск необходимой книги Сортировка доступных книг по категориям
Экран краткой информации о книге
Описание книги Получение полного содержания книги
Экран содержания книги
Текст книги
Таблица 2.2 — функциональныеблоки администраторской части приложения.
Основной экран
Навигация между различными наименованиями книг Поиск необходимой книги Сортировка доступных книг по категориям Добавление книги в список Редактирование книги из списка Удаление книги из списка
Экран добавления и редактирования книги
Заполнение и изменение информации о книге
Существует три основныхвида связи между блоками. Это «логическая связь», «связь по представлениюпользователей» и «процессуальная связь».
Логическая связь.Логическая связь определяет взаимодействие между фрагментами системы с точкизрения разработчика. Полученные связи очень существенно влияют на навигацию впределах системы (особенно, когда система многооконная). Поэтому чтобы неперегружать интерфейс, стоит избегать как слишком уж отдельных блоков (ихтрудно найти), так и блоков, связанных с большим количеством других.
На этом этапевыделяются объективные критерии оценки эргономичности интерфейса, такие какпоказатели эффективности, продуктивности, удовлетворенности пользователей (наболее ранних этапах выделить эти критерии невозможно).
Связь по представлениюпользователей. Пользователи имеют свое мнение о системе, и это мнение тожеявляется важным видом связи. В информационных системах, когда необходимогарантировать, что пользователь найдет всю нужную ему информацию, необходимоустанавливать связи между блоками, основываясь не только на точке зренияразработчика, но и на представлениях пользователей. Дело в том, что самыйраспространенный способ поиска, а именно поиск по классификации признаков,работает только в том случае, когда пользователи согласны с принципами этойклассификации. Большинство же понятий однозначно классифицировать нельзя из-заналичия слишком большого количества значимых признаков. Также проблема состоитв том, что реальный классификационный признак может отличаться от широкораспространенного.
Из этой ситуации естьвыход. Существует простой способ классификации — способ карточной сортировки.Все понятия, которые требуется классифицировать, пишутся на карточках израсчета «одно понятие — одна карточка». После чего группе пользователей изцелевой аудитории предлагается эти карточки рассортировать (при этом каждыйсубъект получает свой набор карточек). Получившиеся кучки из карточек нужноразобрать на составляющие и свести результаты от разных субъектов в один способклассификации.
Процессуальная связь.Процессуальная связь описывает не вполне логичное, но естественное дляимеющегося процесса взаимодействие. Установление качественной процессуальнойсвязи обычно довольно трудная задача, поскольку единственным источникоминформации является наблюдение за пользователем. В то же время установлениетакой связи дело исключительно полезное. Зачем, например, рисовать на экранесложную систему навигации, если точно известно, к какому блоку пользовательперейдет дальше? В этом смысле зачастую оправдано навязывать пользователюкакую-либо процессуальную связь, жертвуя удобством, зато выигрывая с скоростиобучения (поскольку пользователю приходится думать меньше). Жестко заданнаясвязь позволяет также уменьшить количество ошибок. Классическим примером жесткозаданной процессуальной связи является устройство мастеров, при которомпользователя заставляют нажимать кнопку «Далее».
2.2Проектирование навигационной системы
На основе разработаннойранее структуры экранов на этом этапе выбирается наиболее адекватнаянавигационная система и разрабатывается её детальный интерфейс.
Навигационная системапоказывает механизм распределения функций и задач между окнами программы.Навигационная система определяет, каким образом пользователи смогут перемещатьсякак между различными задачами, так и внутри отдельной задачи. Например, можноли будет оставить частично завершенную задачу и начать другую.
Как правило, на этомэтапе не создается отдельного отчета; разработанный интерфейс в дальнейшемописывается в отчете, посвященному низкоуровневому проектированию.
Навигация в программебудет осуществляться посредством мышки, путём нажатия на графические элементы — кнопки (для перехода между экранами).
2.3Проектирование структуры справочной системы
Разрабатываетсясправочная система (к настоящему этапу уже известна вся информация, необходимаядля выработки структуры справочной системы, не просто описывающей интерфейс, нои помогающей пользователю решать его задачи).
Множество систем, нипри каких обстоятельствах не могут быть используемы без подготовки, независимоот качества их интерфейса. Система автоматизации, например, может бытьэффективно использована только в том случае, когда пользователь этой системыпонимает суть автоматизируемых процессов. Для этого пользователя необходимоснабдить пониманием устройства системы. Это значит, что концепции и сутьсложной системы могут быть безболезненно вынесены из интерфейса в документацию,освобождая ресурсы дизайнера. С другой стороны, зачастую описание концепцийвлияет на их реализацию в системе, особенно в ситуациях, когда качествообучения работе с системой является важнейшей составляющей общего качества. Этонаблюдение вполне подтверждается опытом. Например, Джеф Раскин, Отец Макинтоша,изначально был начальником отдела документации. После того, как он обнаружил,что имеющуюся систему невозможно приемлемо описать, он создал новую,описывающуюся хорошо. Побочным свойством новой системы, компьютера Макинтош,было то, что его интерфейс был понятен и удобен в работе.
Документация являетсячастью интерфейса, причем в сложных системах это большая часть.
К сожалению, созданиесправочной системы воспринимается в нашей стране как сравнительнонеобязательный процесс, нужный исключительно для утяжеления коробки с готовымпродуктом. От этого документация почти всегда пишется после того, как системасоздана.
3.Низкоуровневое проектирование
На данном этаперазрабатываются интерфейсы конкретных экранов системы (состав, взаимноерасположение и поддерживающие текст интерфейсных элементов).
3.1Проектирование экранов клиентской части
Основной экран. Как ужебыло отмечено ранее, основной экран в приложении должен отображать списокдоступных книг, иметь функцию сортировки информации, а также предоставлятьпользователю функцию поиска (Рисунок 3.1).
Чтобы упорядочитьнаименования книг по автору, достаточно нажать на заголовок столбца «Автор» (Рисунок3.2). При этом вокруг элемента появится рамка. Всего доступно 3 группысортировки: по автору, по названию книги и по жанру.
Наибольшее пространствов главной форме принадлежит списку книг (Рисунок 3.3), справа от которогорасположена вертикальная полоса прокрутки, дающая возможность перемещаться поэтому списку. Активный элемент (при наведении мышки) подсвечивается зелёнымцветом.
Форма поиска (Рисунок3.4) позволяет искать пользователю интересующие его книги по списку.
Экран информации окниге. Данный экран предоставляет краткую информацию о книге, такую как:название, автор, издательство и небольшое описание (Рисунок 3.5).
Внизу формы расположенапара кнопок. Кнопка «Читать» откроет содержание книги, а кнопка «Каталог»вернёт пользователя к списку литературы.
Экран содержания книги.На этомэкране отображается содержание книги (Рисунок 3.6). Навигация по немуосуществляется с помощью полосы вертикальной прокрутки.
Для более удобнойнавигации, на этой форме присутствует поле поиска. Чтобы вернуться обратно ксписку литературы, следует нажать на кнопку «Каталог».
3.2Проектирование экранов администраторской части
Основной экран. Основнойэкран администраторской части несильно отличается от экрана клиентской. Помимоуже упомянутых ранее элементов, на нём появилось пара новых (Рисунок 3.7).
Около поля поисканаходится кнопка «Добавить», предназначенная для добавления новых книг всписок. Для изменения или удаления уже существующих записей в таблицесуществует 2 кнопки, расположенные левее от наименования — «Удалить» (иконка ввиде крестика) и «Изменить» (с иконкой в виде документа).
Экран изменения иредактирования. На этом экране осуществляется заполнение информации о книге,перед её добавлением в таблицу или при изменении уже существующей (Рисунок 3.8).
Кнопка«Сохранить» — заканчивает редактирование информации о книге. Кнопка «Назад» возвращаетпользователя к каталогу. «Изменить картинку» позволяет указать изображение длякниги, которое впоследствии будет отображаться в краткой информации о ней. Кнопка«Выбрать файл содержания» позволяет указать файл, в котором находится тексткниги
3.3Тестирование
На основе объективныхкритериев успеха интерфейса и сценариев действий пользователей разрабатываютсятестовые задания, которые выполняются пользователями с фиксацией всех значимыххарактеристик их деятельности. После этого выполняется подсчет соответствующихпоказателей и сравнение их с заданными. На основании полученных данныхинтерфейс либо дорабатывается, либо считается разработанным.
В процессепроектирования полезно зафиксировать все используемые в системе понятия. Дляэтого нужно просмотреть все созданные экраны и выписать из них все уникальныепонятия (например, текст с кнопок, названия элементов меню и окон, названиярежимов и т.д.). После этого к получившемуся списку нужно добавить определениявсех концепций системы (например, книга или изображение).
После этого необходимоэтот список улучшить. Для этого необходимо:
- уменьшитьдлину всех получившихся элементов;
- показатьэтот список любому потенциальному пользователю системы и спросить его, как онапонимает каждый элемент. Если текст какого-то элемента воспринимаетсянеправильно, его нужно заменить;
- уменьшитьдлину всех получившихся элементов;
- проверить,что одно и то же понятие не называется в разных местах по-разному;
- проверитьтекст на совпадение стиля с официальным для выбранной платформы (если выделаете программу, эталоном является текст из MS Windows);
- уменьшитьдлину всех получившихся элементов;
- убедится,что на всех командных кнопках стоят глаголы-инфинитивы (Отменить, Удалить,Отправить).
Последней задачей передпостроением прототипа является проверка внутренней логики системы. Дело в том,что всегда существует вероятность того, что вы что-то забыли или спланировалинеправильно. Как уже было сказано, исправить эти ошибки лучше всего допостроения прототипа (даже первой его версии). Конечно, многие структурныеошибки нельзя найти никакими методами, кроме длительного логического анализа. Сдругой стороны, практика показывает, что почти все найденные ошибки будутсущественными. Так что лишняя проверка не повредит.
Для финальной проверкисхемы пригодятся разработанные ранее />пользовательскиесценарии. Не глядя на схему, необходимо подробно описать, как все вымышленныепользователи будут взаимодействовать с системой, не пропуская ни одногоэлемента управления. После чего сверить полученный текст со схемой.
Тут возможно три вариантаразвития событий: либо вы обнаружите, что вы что-то забыли задокументировать всхеме, либо обнаружите, что свеженаписанный рассказ значительно лучше схемы,вероятнее же всего, что и то и другое произойдет одновременно. На четвертыйвариант, а именно на полное отсутствие проблем, рассчитывать, как правило, нестоит.
3.4Экспертная оценка
Весьма эффективнымсредством оценки получающегося интерфейса является его экспертная оценка. Частооказывается, что сравнительно дорогое тестирование показывает то, что было былегко видно постороннему, тем более вооруженному опытом и квалификацией,взгляду. Хотя экспертная оценка не может быть полноценной заменой тестирования,она обладает одним существенным преимуществом — для её проведения не требуетсяпрототип. Это значит, что эксперт может быть приглашен на ранних стадияхработы, когда польза от обнаружения ошибок максимальна.
Для проведенияэкспертной оценки нужно знать следующее:
- разныелюди обнаруживают разные ошибки. Это значит, что метод работает лучше, когдаколичество экспертов больше единицы;
- лучшепривлекать несколько экспертов не одновременно, но последовательно;
- чембольше информации о проектируемой системе будет предоставлено эксперту, темболее сложные проблемы он сможет выявить;
- нельзятребовать от эксперта работы по весу. В большинстве случаев результатом егоработы будут одна или две страницы текста (поскольку описание одной проблемытребует обычно всего двух или трех предложений). Если от эксперта будеттребоваться объемный результат работы, он включит в него много несущественныхподробностей;
4.Построение прототипа пользовательского интерфейса
Создание максимальноэффективного прототипа интерфейса является чрезвычайно важной задачей. Прототипдолжен хорошо выглядеть, чтобы понравиться заказчику и не вызвать вопросов усубъектов тестирования, он должен быть максимально дешев, максимально полон и,что немаловажно, должен с легкостью обновляться.
При создании прототипанаиболее частой ошибкой является чрезмерное наведение глянца и вообщестремление сделать прототип возможно более похожим на результирующую систему. Всамом таком подходе нет ничего плохого (всё равно определенные части прототипаприходится делать максимально совершенными), проблема в том, что в большинствеслучаев прототип после тестирования оказывается неправильным. Его приходитсяпеределывать, причем иногда полностью, при этом все вложенные в прототипресурсы (в основном время) оказываются выброшенными на ветер.
К счастью, требования кпрототипу изменяются со временем. Сначала наиболее актуальными его свойствамиявляются скорость создания и простота модификации. Эти свойства позволяютбыстро разработать и проверить несколько версий интерфейса, при этом ещё иисправить значительную часть ошибок. Только затем на первый план выходятфункциональность и эстетичность, простота же модификации становится уже не такважна, поскольку с каждой новой исправленной ошибкой снижается вероятностьтого, что прототип придется полностью переделывать при обнаружении новойошибки.
Поэтому всегдаправильно делать прототип настолько похожим на результирующую систему,насколько версия прототипа поздняя. Первый прототип стоит делать максимальнопримитивным. Только после того, как тестирование подтверждает его правильность,стоит делать более детализированный прототип.
4.1Этапы построения прототипа
Существуют четыреверсии прототипа: бумажная, презентационная, псевдореальная и реальная. Особыйинтерес представляют первые две. Третья и четвертая используются редко, т.к. несильно отличаются от готовой программы.
4.1.1Бумажный
Необходимо нарисоватьна бумаге все экраны и диалоговые окна (или распечатать соответствующие частисхемы). Нужно только убедиться, что все интерфейсные элементы выглядятединообразно и сколько-нибудь похоже на реальные (Рисунок 4.1).
Эта распечатка иявляется первым прототипом. На нём вполне можно тестировать восприятие системыпользователем и её основную логику.
Достоинствами бумагиявляются исключительная простота и скорость рисования (Рисунок 4.2). Пользаначального прототипирования на бумаге заключается, во-первых, в простоте искорости рисования, во-вторых, в исключительной простоте модификации порезультатам тестирования, а в-третьих, в относительной простоте привлеченияпредставителей целевой аудитории. Значительно легче завлечь субъекта кписьменному столу, нежели к компьютеру, на котором надо что-то запускать,ждать, пока запустится и так далее. Кроме того, бумага помогает не думать отом, как интерфейс выглядит, позволяя сосредоточиться на том, как интерфейсработает.
При рисовании прототипана бумажке очень важно не стараться нарисовать его так, чтобы он был красив,например, не нужно стараться рисовать линии прямыми. На понимание работыинтерфейса это не повлияет, зато здорово замедлит работу. Красоту же всё равнопридется выбрасывать, когда будет нарисована новая версию. Так что основнымкритерием живописности должна стать скорость работы.
Элементы интерфейса,которые нельзя нарисовать однозначно (например, раскрывающиеся списки, укоторых значения до поры скрыты) эффективнее всего рисовать неоднозначными,важную же информацию из них лучше всего словами писать на полях.
Разумеется, значениеслова «версия», весьма условно. В действительности после обнаружения каждойошибки схема и прототип исправляются, а тестирование продолжается уже на новомпрототипе. Так что на этом этапе прототип может пережить множество исправленийи, соответственно, много версий (Рисунок 4.3).
4.1.2Презентационный
После исчерпаниявозможностей бумажной версии прототипа стоит создать новую версию. Для этоготочно так же рисуется интерфейс, но уже не на бумаге, но в какой-либопрезентационной программе (Рисунок 4.4). С этой версией прототипа можнотестировать значительно более сложное взаимодействие человека с системой,нежели с бумажной. С другой стороны, исправление найденных ошибок значительноболее трудоемко.
Самым распространенныминструментом для создания прототипов второго типа является MS Visio. Некоторуюконкуренцию ему могут составить MS PowerPoint и MacromediaFreeHand (и вообщелюбой иллюстративный пакет, обладающий возможностью работать с несколькимистраницами).
При работе с Visioможно выбрать одну из двух возможностей: можно либо рисовать все экраны наодном листе, соединяя взаимосвязанные элементы управления и экраны линиями,либо рисовать каждый экран на отдельном листе, связывая экраны ссылками. Первыйвариант хорош для вас, поскольку позволяет оценить интерфейс в целом, второй –для заказчика и субъектов тестирования, поскольку его легче понять. Какправило, превратить второй вариант в первый оказывается гораздо легче. Еслирисовать в PowerPoint, каждой экран удобно создавать как отдельный слайд, арезультат нажатия кнопок имитировать переходами между слайдами.
Среди многочисленныхнаборов заготовок в Visio есть и набор с элементами интерфейса Windows, однакоэти заготовки выполнены довольно грубо, с огромным количеством лишних деталей.Пользоваться можно только заготовками для радиокнопок и чекбоксов (которыереализованы неплохо), а также заготовкой для полоски прокрутки. Поскольку созданиесобственных интерактивных заготовок непроблематично, рекомендуется создать свойнабор и пользоваться им.
Большим достоинствомVisio является возможность записывать результат в HTML-файл, что позволяет безпроблем тестировать интерфейс на территории субъектов тестирования. Раньше этомог только PowerPoint, чем, во многом, и объяснялась его популярность вкачестве инструмента для создания прототипов. Сейчас это умеет и Visio(сохранение в HTML начало нормально работать только в Visio 2001).
У многих разработчиков,особенно кто не понаслышке знаком с программированием есть соблазнвоспользоваться для создания прототипа средствами быстрой разработки приложений(Delphi, VisualBasic и т.д.). В этом случае прототип интерфейса воспринимаетсялишь как вспомогательная оболочка над программным кодом. Как следствиевозникают следующие недостатки:
- длятестирования прототипа на пользователях крайне желательно, чтобы он «немногоработал», то есть, например, нажатие на кнопку вызывало другое окно или чтобыиз выпадающего списка можно было выбрать значение. Так вот, в данном случаелюбое взаимодействие, как между отдельными элементами интерфейса, так и междуразличными формами реализуется только с помощью написания программного кода.Что совершенно незачем в данном контексте. Зачем усложнять то, что можносделать проще? Ведь основной критерий создания прототипа это скорость;
- чрезвычайносложно создать принципиально новый элемент интерфейса либо модифицировать ужеимеющийся. Подобные задачи очень часто встречаются на практике, так как для«хорошего» интерфейса стандартных элементов, как правило, не хватает. Затратына создание/модификацию собственного элемента управления в данных средах разработкинельзя назвать адекватными;
- каждыйэлемент управления здесь имеет несколько десятков различных свойств, тогда какдля прототипизирования требуются лишь касающиеся внешнего вида настройки — шрифт, цвет, текст, размер;
- естественныйнедостаток: нельзя разрабатывать веб-интерфейс.
Фактически длябольшинства систем этой версии прототипа оказывается достаточно.
4.1.3Псевдореальный
В тех случаях, когда винтерфейсе появляются нестандартные элементы или необходимо проверить реальнуюскорость взаимодействия пользователя с системой, создается еще одна версияпрототипа – реально выглядящая, но лишенная каких-либо алгоритмов и,соответственно, не показывающая реальных данных. Делать этот вариант можно какв средах разработки, благо в них есть визуальные инструменты созданияинтерфейсов, так и в редакторах изображений, что обычно быстрее. Фактически приэтом создаются фальшивые снимки экрана, на которых и производят тестирование(Рисунок3.1). Понятно, что существенно модифицировать эти экраны затруднительно, такчто лучше не увлекаться такой работой, не получив каких-либо гарантий ее правильности.
4.1.4Реальный
Иногда необходимотестировать взаимодействие пользователя не только с интерфейсом системы, но и собрабатываемыми системой данными. Например, работая с графической программой,пользователь не только нажимает на экранные кнопки, но также создает имодифицирует изображения мышью. Область же редактирования данных зачастуювообще не содержит каких-либо визуальных интерфейсных элементов, из чего вовсене следует, что интерфейса в ней нет, его, наоборот, много. Другой разговор,что счет в нем идет не на кнопки и переключатели, но на пиксели и миллисекунды.
Понятно, что созданиепрототипа в таких условиях не поможет, поскольку прототип вообще не будетотличаться от проектируемой системы. В таких условиях лучше всего написатьнужные участки кода до написания всего остального, и проводить тестирование ужена реальной системе.
5.Тестирование и модификация прототипа
Какими бы не былисовершенными логические соображения, приведшие к созданию интерфейса, всегдаостается вероятность того, что интерфейс получился плохой, либо, что болеевероятно, не такой хороший, каким бы он мог быть (Рисунок 5.1).
Необходимо иметькакие-либо подтверждения его работоспособности. К счастью, проверка качестваинтерфейса обычно непроблематична. Всё, что для этого нужно, это несколькопользователей средней квалификации, никогда не видевшие тестируемой системы,плюс прототип (разумеется, при наличии основательного бюджета можноразвернуться и пошире, например, купить прибор, фиксирующий направление взглядапользователя).
В литературе частовстречается мнение, что тестированием можно решить чуть ли не все проблемыинтерфейса. Утверждение это сомнительно. Тестированием, скорее, можноопределить слабые места интерфейса, но почти невозможно обнаружить сильные,поскольку они пользователями просто не замечаются, и совсем уж невозможноопределить новые способы улучшения. Происходит это из-за того, что субъектытестирования:
- необладают всей необходимой информацией о системе;
- ничегоне знают о проектировании интерфейсов;
- ихмотивация существенно отличается от необходимой — вместо того, чтобы стремитьсясделать хороший интерфейс, они стремятся оставить в этом интерфейсе свой след.
Вообще, слушатьпотребителей обычно неправильно. Разве мы спрашиваем канарейку, в какой клеткеона хочет жить? Сюжет проамериканский автопром, например, стал уже частьюистории бизнеса: все американские потребители в семидесятых годах дружноутверждали, что они хотят большие, мощные машины, при этом так же дружнопокупая маленькие и маломощные японские автомобили. Или другой пример — всоветское время измученные коммунизмом люди мечтали вовсе не об отпуске наТенерифе, о котором они ничего не знали, но о финском хромированном смесителе,который поставил себе сосед — хотя Тенериф, безусловно, в качестве мечтыинтереснее.
В то же время, даже неслушая пользователей, обязательно нужно принимать во внимание их потребности,способности и предпочтения. Например, нередко дизайнер интерфейса знает опредметной области меньше, нежели будущие пользователи. В таких условиях потеряконтакта с пользователями грозит крахом продукта, просто потому, что системаоказывается неспособна решать задачи, о которых дизайнер ничего не знал. Чаще,однако, случается так, что уровень «компьютерной грамотности» дизайнера оказываетсявыше уровня аудитории. В этом случае все получается ещё хуже: дизайнер выбираетрешения, которые обеспечивают эффективность работы, а потребителям нужнырешения, которые они могут понять, в результате они оказываются неспособнымивоспользоваться системой (это совершенно нормальная ситуация, особенно винтернете). Например, замечено, что опытные пользователи (к которым относятсядизайнеры) создают значительно менее работоспособные иерархии меню, нежелипользователи начинающие.
Разумеется, если переоценкаспособностей реальных пользователей и незнание предметной области совпадают,результат бывает ещё хуже.
ЗАКЛЮЧЕНИЕ
Виртуальные библиотекиявляются неотъемлемой частью настоящего и будущего. С каждым днём числоэлектронных публикаций растёт, постепенно вытесняя бумажные издания.
Электронная формапозволяет хранить информацию в более надёжном, компактном и удобном виде.Значительно увеличивается скорость поиска нужной информации, простота еёраспространения.
При разработкепрограммы, особое внимание стоит уделять её интерфейсу. Лаконичный, удобный, аглавное понятный пользовательский интерфейс делает обучение работе с ним легкими быстрым, снижает время и затраты на обучение, техническую поддержкупользователей. Он способен повысить производительность труда пользователей,снизить количество человеческих ошибок, а значит, уменьшить количество временина их исправление.