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 Экспертная оценка
Весьма эффективным средством оценки получающегося интерфейса является его экспертная оценка. Часто оказывается, что сравнительно дорогое тестирование показывает то, что было бы легко видно постороннему, тем более вооруженному опытом и квалификацией, взгляду. Хотя экспертная оценка не может быть полноценной заменой тестирования, она обладает одним существенным преимуществом - для её проведения не требуется прототип. Это значит, что эксперт может быть приглашен на ранних стадиях работы, когда польза от обнаружения ошибок максимальна.
Для проведения экспертной оценки нужно знать следующее:
- разные люди обнаруживают разные ошибки. Это значит, что метод работает лучше, когда количество экспертов больше единицы;
- лучше привлекать несколько экспертов не одновременно, но последовательно;
- чем больше информации о проектируемой системе будет предоставлено эксперту, тем более сложные проблемы он сможет выявить;
- нельзя требовать от эксперта работы по весу. В большинстве случаев результатом его работы будут одна или две страницы текста (поскольку описание одной проблемы требует обычно всего двух или трех предложений). Если от эксперта будет требоваться объемный результат работы, он включит в него много несущественных подробностей;