Руководящие принципы проектирования интерфейсаПервый принцип – контроль на стороне пользователя Основной смысл этого принципа заключается в том, что пользователь инициирует действия, и если в результате этого контроль переходит к программе, то пользователь получает необходимую обратную связь (в виде курсора в форме песочных часов, либо индикатора ожидания или аналогичным способом). Рис. 7.6 демонстрирует типичный поток управления в человеко – машинном взаимодействии. Событие, инициированное пользователем (выбор пункта меню, щелчок мышью, перемещение указателя мыши по экрану и т.д.), может привести к открытию окна GUI-интерфейса или вызову программы – как правило, программы на языках типа 4GL или SQL в рамках приложения информационной системы. Программа временно перехватывает контроль у пользователя.
Рис. 7.6. Поток управления GUI – программы
Процесс выполнения программы имеет возможность вернуть управление назад тому же или другому окну. В другом случае он может вызвать другой модуль на языках типа 4GL или SQL или вызвать внешнюю процедуру. В некоторых случаях программа может кое-что делать для пользователя. Это возможно, к примеру, если программе требуется выполнить вычисления, которые обычно связаны с явным пользовательским событием, или если программа перемещает указатель на другое поле экрана, а для события перемещения с исходного поля предусмотрен обработчик события выхода, связанный с ним. Второй принцип – согласованность Согласованность, несомненно, является вторым основным принципом разработки качественного интерфейса. Фактически согласованность означает соблюдение стандартов и следование некоторым общепринятым правилам работы с GUI-интерфейсом. Согласованность может рассматриваться, по меньшей мере, в двух аспектах. - Соответствие стандартам поставщика GUI-интерфейса. - Соответствие стандартам в области именования, программирования и другим, разработанным внутри организации стандартам, которые связаны с GUI-интерфейсом. Оба аспекта одинаково важны, и второй (на который оказывают влияние разработчики) не должен противоречить первому. Если приложение разрабатывается для Windows, то следует обеспечить «впечатление и ощущение», свойственные работе в системе Windows. Для системы Macintosh замена знаменитого «яблочного» меню вложенным меню (типа «кенгуру»), вообще не удачная идея. Разработчик GUI-интерфейса не должен слишком увлекаться творчеством и предлагать необычные новшества. Это может плохо сказаться на уверенности и умении пользователей. Пользователям следует представлять знакомую среду, поведение которой предсказуемо. Не следует также недооценивать соответствие внутренним стандартам в области именования, программирования, аббревиатур и т.п. Сюда относятся именование и программирование меню, командных кнопок, полей экранов, а также стандартов по расположению объектов на экране и последовательному использованию элементов GUI-интерфейса в рамках всех приложений, разрабатываемых собственными силами.
Третий принцип – индивидуализация и настройка Индивидуализация и настройка – два взаимосвязанных принципа разработки GUI-интерфейса. Индивидуализация GUI- интерфейса – это просто его настройка под персональные нужды, в то время как настройка – так, как мы понимаем ее здесь – административная задача приспособления ПО к требованиям различных групп пользователей. Примером индивидуализации является изменение пользователем порядка и размеров колонки в программе просмотра строк (так называемые сетки - grid) с последующим сохранением этих изменений как его личных предпочтений. При обращении к этой же программе в будущем данные предпочтения учитываются. Примером настройки является различие в функционировании программы по отношению к опытным пользователям и пользователям-новичкам. Например, пользователю-новичку программа может предложить явную помощь и дополнительные предупреждающие сообщения, указывающие на потенциальную опасность некоторых событий, инициированных пользователем. Во многих случаях различия между индивидуализацией и настройкой весьма размыты и малозаметны. Изменение пунктов меню, создание новых меню и т.п. попадают в обе категории. Если они предназначены для индивидуального использования – это индивидуализация. Если они осуществляются системным администратором в интересах всего коллектива пользователей – это настройка. Четвертый принцип – терпимость к ошибкам Хорошо спроектированный интерфейс должен позволять пользователям экспериментировать и совершать ошибки, проявляя терпимость к ошибкам. Подобная терпимость стимулирует исследовательскую активность пользователя, поскольку позволяет ему выполнять ошибочные последовательности действий с возможностью в любой момент совершить при необходимости «откат» в начало. Терпимость к ошибкам подразумевает многоуровневую систему отмены операций. Об этом принципе легко говорить, однако, он трудно поддается реализации. Реализация терпимости к ошибкам в интерфейсе отличается особой сложностью для многопользовательских приложений баз данных. Пользователь, который снял (и потратил) деньги с банковского счета, не имеет возможности отменить эту операцию! Единственное, что он в состоянии сделать – исправить ошибку (если, конечно, это было ошибкой), положив деньги назад на счет, осуществив для этого другую операцию. Должен или не должен терпимый к ошибкам интерфейс предупреждать пользователя о последствиях снятия денег со счета – вопрос спорный (и относится он к принципу индивидуализации интерфейса). Пятый принцип – обратная связь Принцип обратной связи дополняет первый принцип – контроль должен находиться на стороне пользователя. Контролировать ситуацию – значит знать, что происходит, когда контроль временно передается программе. Разработчик должен встроить в систему визуальные или аудио подсказки для каждого события, инициируемого пользователем. В большинстве случаев указатель в форме песочных часов или индикатор ожидания представляет достаточный уровень обратной связи, чтобы понять, что программа что-то делает. Для тех компонент приложения, которые иногда могут стать источником проблем с производительностью, может потребоваться более ясная обратная связь (например, в виде отображения поясняющего сообщения). В любом случае, разработчик никогда не должен предполагать, что приложение выполняется настолько быстро, что обратная связь не потребуется. Любые отклонения в рабочей нагрузке приложения докажут, что разработчик, к сожалению, ошибался.
Шестой принцип – эстетичность и удобство Эстетичность интерфейса влияет на зрительное восприятие системы. Удобство касается легкости, простоты, эффективности, надежности и продуктивности в использовании интерфейса. Безусловно, оба принципа касаются удовлетворенности пользователя. Именно в этом вопросе разработчик GUI- интерфейса нуждается в помощи художника-графика и эксперта по социальной психологии. Существует много разнообразных «золотых правил», касающихся создания эстетичного и удобного интерфейса. При этом, следует учитывать такие вопросы, как фиксация и движение человеческого глаза, использование цветов, чувство уравновешенности и симметрии, выравнивание и отступ между элементами, чувство пропорции, группирование связанных элементов и т.д.
31. Моделирование вариантов использования. Основной и альтернативные потоки событий. Привести пример моделирования варианта использования «Покупка бензина на автозаправочной станции». Подготовить диаграмму вариантов использования. Обычно клиент платит за бензин наличными. Кроме отношения <include> добавить отношение расширения <extend>, с помощью которого описывается дополнительное поведение, возникающее, когда клиент платит кредитной картой снаружи или внутри АЗС. Возможны дополнительные услуги АЗС, в виде мойки машины, посещения кафетерия, приобретения авто товаров, продуктов питания и авто принадлежностей и т.п.
Сценарий: Этапы основного потока событий: 4. Вариант использования начинается с регистрации пользователя. 5. Система запоминает пользователя и предоставляет доступ к обеспечению. 3. Клиент выбирает перечень услуг из всех предоставленных. А0 4. Если выбрана заправка пользователю дается чек на заправку. А1 4.1. Если выбрана мойка пользователю дается чек на мойку. А1.1. 4.2. Если выбрана покупка пользователю дается покупка и чек на покупку. А1.2. 5. Пользователь выбирает категорию оплаты. 6 Пользователь подтверждает цену. 10. Система запрашивает тип кредитной карточки, ее номер, имя владельца и дату завершения срока действия. 11. Пользователь вводит тип кредитной карточки, ее номер, имя владельца и дату завершения срока действия. 12 Система подтверждает продажу по кредитной карточке. А3. А4.Е1. 13. Система генерирует и показывает пользователю код подтверждения. 14. Пользователь подтверждает получение кода. 15. Вариант использования завершается. Альтернативные потоки событий А0:Клиент выбрал и оплатил услуги через терминал. А1: Нет бензина. В этом случае: 4. Система выводит сообщение, что нет бензина. 5. Пользователь подтверждает просмотр сообщения. 6. Поток возвращается на этап 2 основного потока событий. А1.1: Закончилась вода и/или моющие средства. В этом случае: 7. Система выводит сообщение, что мойка недоступна. 8. Пользователь подтверждает просмотр сообщения. 9. Поток возвращается на этап 2 основного потока событий. А1.2: Нет необходимого товара. В этом случае: 1. Система выводит сообщение, что мойка недоступна. 2. Пользователь подтверждает просмотр сообщения. 3. Поток возвращается на этап 2 основного потока событий. А2: Счет пользователя не обнаружен. В этом случае: 3. Система выводит сообщение о том, что счет пользователя не обнаружен. 4. Поток возвращается на этап 10 основного потока событий. А3: Недостаточно денег на счете. В этом случае: 3. Система выводит сообщение о том, что остаток на кредитной карточке не позволяет завершить транзакцию. 4. Поток возвращается на этап 10 основного потока событий.
|
