Студопедия — Проектирование пользовательского интерфейса
Студопедия Главная Случайная страница Обратная связь

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

Проектирование пользовательского интерфейса






 

Илларионов Вячеслав Семёнович

доцент, кандидат технических наук

 

 

Лицензия: серия НД №06090 от 21.10.2001 г.

Подписано в печать 20.09.2010

Формат 60x84 1/16. Бумага офсетная. Тираж 100 экз. Печ. л. 2, 5. Заказ №

 

Отпечатано с готового оригинал-макета в копировально-множительном

центре ГАОУ ВПО «МГОСГИ»

140411, г. Коломна, ул. Зеленая, 30. МГОСГИ.

 

 

ПРОЕКТИРОВАНИЕ

ИНФОРМАЦИОННЫХ СИСТЕМ

 

Методические указания

к лабораторному практикуму

 

 

Специальность 080801.65 – Прикладная информатика


СОДЕРЖАНИЕ

Лабораторная работа «Проектирование пользовательского

интерфейса»............................................................................................. 4

1. Цель работы.......................................................................................... 4

2. Программно-техническая платформа.............................................. 4

3. Теоретическая часть............................................................................ 4

4. Перечень заданий к лабораторной работе..................................... 16

5. Порядок выполнения лабораторной работы................................ 20

6. Содержание отчета по лабораторной работе............................... 23

Лабораторная работа «Разработка диаграмм потоков данных

с использованием CASE-технологии»............................................ 24

1. Цель работы........................................................................................ 24

2. Программно-техническая платформа............................................ 24

3. Теоретическая часть.......................................................................... 24

4. Перечень заданий к лабораторной работе..................................... 27

5. Порядок выполнения лабораторной работы................................ 29

6. Содержание отчета по лабораторной работе............................... 39

Список литературы.............................................................................. 40

Приложения........................................................................................... 41


ЛАБОРАТОРНАЯ РАБОТА

«Проектирование

пользовательского интерфейса»

Цель работы

Целью работы «Проектирование пользовательского интерфейса» является закрепление навыков в области разработки иерархического меню, проектирования экранных форм и отчетов при создании АРМ управленческого персонала. В ходе работы студенты приобретают практические навыки проектирования стандартного интерфейса Windows (многоуровневое меню, формы, отчеты) с помощью средств MS Access 2003.

Программно-техническая платформа

В качестве программного обеспечения используются приложения Microsoft Office 2003 Microsoft Access 2003 и Microsoft Word 2003.

Минимальные требования к технической платформе: персональный компьютер Pentium III и выше, 128 Мб оперативной памяти.

Теоретическая часть

Проектирование пользовательского интерфейса

Пользовательский интерфейс (User Interface – UI) включает в себя: меню, экранные формы и отчеты.

При проектировании пользовательского интерфейса любой программы должны выполняться следующие эвристические правила [3][1]:

· Видимость состояния системы (правило обратной связи). Программа (система) должна всегда информировать пользователя о состоянии своей работы. При рассмотрении этого правила необходимо учитывать несколько аспектов:

- информированность пользователя. Пользователь всегда должен иметь информацию о текущем статусе работы программы – например, сколько времени прошло от начала процесса копирования файлов. Кроме этого, пользователь обязательно должен видеть, к чему привело любое его действие: ввод данных, нажатие кнопки и т.п.;

- средства обеспечения обратной связи. Выбор конкретного средства обратной связи зависит от типа информации, которую нужно донести до пользователя, а также типа действия, которое вызывает потребность в обратной связи. Информация, при рассмотрении данного вопроса, делится на типы в зависимости от ее назначения и степени важности. Например, сообщения о критических ошибках, приводящих к невозможности продолжения работы, обычно выводятся в отдельном диалоговом окне. При этом работа приложения останавливается до тех пор, пока пользователь не закроет окно с информацией об ошибке (так называемое модальное окно), а сообщения о незначительных ошибках – в статусной строке окна приложения без остановки его работы. Что касается зависимости выбора средства обратной связи от типа действия, вызывающего его, то традиционно считается, что если пользователь сделал какое-то действие – например, запустил процесс кодирования файла и ожидает какого-то результата, то этот результат (или сообщение об ошибке) должен быть выведен в отдельном окне. Если же результат, о котором требуется сообщить пользователю, является текущей информацией о процессе, и не является прямым следствием действий пользователя, то можно ограничиться отображением соответствующего сообщения в строке состояния. Текстовые сообщения, выводящиеся в окне программы, для организации обратной связи могут быть дополнены другими средствами оповещения пользователя, например звуком;

- время оповещения. Промежуток времени от совершения пользователем действия до получения им информации о реакции на это действие (или о событии, вызванном этим действием) должен быть минимальным, поскольку наличие или отсутствие у пользователя информации о текущем состоянии системы определяет дальнейшие действия пользователя. Если пользователь не будет знать, что последняя операция была завершена неудачно, то последующие его действия могут выполняться с ошибками.

· Равенство между системой и реальным миром. Программа (система) должна «общаться» с пользователем на его языке. В данном случае подразумевается использование понятий, образов и концепций, которые знакомы пользователю по реальному миру и к которым он уже привык. Представление информации и объектов в программе должно быть организовано в естественном и логичном порядке.

· Свобода действий пользователя. Пользователь должен иметь контроль над системой и возможность изменить текущее состояние программы. Чаще всего это реализуется в виде кнопки Cancel (Отмена), расположенной в диалоговом окне и позволяющей прекратить выполнение текущей операции или закрыть это диалоговое окно. Аналогичный результат дает нажатие на клавиатуре клавиши < Escape>. Еще одним средством выхода из ошибочной ситуации являются функции Undo (Отменить) и Redo (Повторить). Если же по каким-либо причинам действие, на выполнение которого дал команду пользователь, нельзя будет отменить, то на экран должно быть выведено соответствующее предупреждение, а также просьба подтвердить выполнение команды.

· Последовательность и стандарты. Принцип последовательности означает использование одних и тех же средств для выражения схожих образов и выполнения действий, имеющих одинаковую природу. Примером применения принципа последовательности и стандартизации является интерфейс «в стиле Windows».

· Предупреждение ошибок. Интерфейс, предупреждающий возникновение ошибок, называется «услужливым». Программа как бы заботится о пользователе, будучи всегда готовой предложить ему помощь, дать подсказку. Кроме того, уменьшение вероятности возникновения ошибок пользователя при работе с программой достигается тщательной проработкой всех элементов интерфейса и его концепции в целом в соответствии с правилами проектирования интерфейсов.

· Понимание лучше, чем запоминание. При проектировании интерфейса все объекты, функции, действия должны быть видимыми и легко доступными пользователю. Данное правило отражает принцип прозрачного интерфейса – интерфейса, который понятен и не заставляет пользователя удерживать в памяти информацию из одной части программы, чтобы применить ее в другой. В любой момент ему должно быть ясно, что нужно делать в данный момент. В хорошем интерфейсе инструкции по использованию программы (системы) всегда видимы или легко доступны для вызова в любое время, когда это требуется. Это может быть реализовано как в виде продуманной организации элементов интерфейса, так и непосредственно в виде подсказок пользователю.

· Гибкость и эффективность использования. При проектировании интерфейса перед разработчиком часто встает такая проблема: требуется, чтобы интерфейс был одинаково удобен и для новичков, и для опытных пользователей. Для решения этой проблемы прибегают к следующему приему: функции, которые ускоряют работу, оформляют так, что они не видны начинающим, но легко доступны продвинутым пользователям. Примером реализации универсального интерфейса – это «горячие клавиши». Обозначения «горячих клавиш» пишутся рядом с соответствующими пунктами меню, поэтому они, с одной стороны, не мешают новичкам (они могут воспользоваться мышью для выбора пункта меню или щелчка по кнопке на панели инструментов), а, с другой стороны, легко доступны опытным пользователям. Другой пример реализации «интерфейса для каждого» – возможность выполнения сложных функций программы с помощью Мастера или вручную, посредством настройки опций в соответствующем диалоговом окне. Еще одной составляющей данного правила является необходимость предоставления пользователю возможности быстрого выполнения частых действий. Это может быть реализовано, например, с помощью команды для вызова последних открывавшихся файлов, и меню, в которых сначала показываются наиболее часто выполняющиеся команды.

· Эстетичный и минималистический дизайн. Каждый элемент интерфейса (кнопка или текстовая подпись) отвлекает часть внимания пользователя. Это может привести к тому, что видимость и, соответственно, легкость восприятия пользователем действительно нужных и полезных частей интерфейса будет сильно уменьшена за счет элементов, без которых в данном случае можно было бы обойтись.

· Распознавание и исправление ошибок. Это правило определяет проектирование сообщений об ошибках. Сообщение об ошибке должно состоять из двух частей:

- описание ошибки. Оно должно быть четким, ясным и понятным, давать пользователю всю необходимую информацию о причинах и месте возникновения ошибки;

- описание решения проблемы. Большинство разработчиков программ размещают описание решения проблемы в разделе справочной системы, посвященном соответствующей ошибке. Однако лучше всего включить эту информацию прямо в диалоговое окно сообщения об ошибке, так, как это сделано, например, в системе управления базами данных Microsoft Access. При описании пути решения проблемы нужно избегать составления слишком объемных текстов, т.к. пользователи будут просто пробегать их глазами, не вникая в смысл написанного, подобно тому, как человек, просматривающий газету, сначала останавливает взгляд на коротких заметках, пропуская большие материалы. Поэтому рекомендуется составлять описание действий по исправлению ошибки наподобие пошаговой инструкции, каждый шаг которой составляет 1–2 предложения.

· Справка и документация. Меню программы (системы) должно содержать пункт, с командами Справка (Help), О программе вызывающие соответственно справочную систему и информацию о программе.

Проектирование иерархического меню

Функциональная часть информационной системы (ИС) обычно имеет иерархическую структуру, то есть содержит комплексы задач, подкомплексы и, наконец, отдельные задачи. Выбор требуемой задачи в этом случае удобно осуществлять с помощью иерархического меню.

Например, на верхнем уровне иерархии могут находиться такие комплексы задач, как:

· поддержка (формирование, ведение базы данных);

· обработка (планирование, учет, анализ и т.д.);

· справки (отчеты, ответы на запросы).

В скобках указаны подкомплексы задач. Пользователю предоставляется возможность последовательно конкретизировать выбор интересующего подкомплекса задач и, наконец, отдельной задачи, которую он собирается решать.

Порядок проектирования меню следующий:

· проектирование содержания меню;

· проектирование формы меню;

· программное обеспечение меню.

Проектирование содержания меню требует изучения предметной области обоснования состава задач, образующих функциональную часть системы, и их иерархической взаимосвязи. Для этого необходимо выяснить должностные обязанности пользователя системы, которые зависят от назначения подразделения, в котором он работает. А место и роль подразделения, в свою очередь, зависит от характеристик предприятия в целом.

Выбор пункта меню может завершаться:

· появлением на экране меню следующего уровня;

· выполнением команды (например, возврат в системное меню);

· выполнением процедуры (например, процедуры ввода или вывода информации, функциональной обработки);

· появлением «заглушки» – сообщения о том, что данный пункт еще не реализован или же другого комментария.

Пример таблицы, отражающий выбор пункта меню для АРМ кладовщика склада материалов представлен ниже (см. таблицу 1).

В главном меню следует предусмотреть пункт «Выход», который позволяет вернуться к системному меню, что удобно при отладке системы.

 


 

Таблица 1.

Содержательное проектирование иерархического меню

Пункт главного меню Пункт подменю Экранная форма для ввода информации Выходная форма (отчет)
Помощь Приход Расход Отпуск на сторону Внутреннее перемещение Отпуск по лимитно-заборной карте Справки Наличие материала на складе   Движение материалов за период Выход – Приходный ордер Подменю Товарно-транспортная накладная Требование Лимитно-заборная карта Подменю Наличие материала на складе   Движение материалов за период – Текст инструкции Приходный ордер – Заглушка Требование Лимитно-заборная карта – Отчет о наличии материала на складе Отчет о движении материалов Системное меню

 


Иерархическое меню обычно содержит главное меню в виде горизонтально расположенной линейки. Выбор пункта этого меню приводит к появлению всплывающего меню. Выбор пункта всплывающего меню может вызвать появление каскадного меню. Все меню, начиная с третьего уровня, называются каскадными. Свое название они получили потому, что располагаются на экране уступами, частично перекрывая друг друга.

Существует ряд правил, которыми следует руководствоваться при проектировании меню. Эти правила соответствуют международным стандартам по проектированию пользовательского интерфейса. Один из этих стандартов – CUA (Common User Access).

Назовем следующие рекомендации:

1. Количество уровней в меню должно быть не более 2‑ 3.

2. Пользователь должен знать, в какой точке иерархического меню он находится, то есть следы предшествующих уровней должны оставаться.

3. Пункты меню не нумеруются.

4. Название пунктов горизонтального меню должно быть коротким.

5. Заглавной должна быть только первая буква названия пункта.

6. Пункт меню может быть выбран по первой (выделенной) букве его названия. Если первая буква названия пункта меню не является уникальной, то можно назначить любую выделенную букву.

7. Для выбора пункта всплывающего меню может быть предназначена «горячая клавиша» (hot key), поскольку путь к нему через главное меню может быть долгим.

8. Пункты, к которым часто обращаются, должны быть расположены в начале меню. Если присутствует пункт «Помощь», то он располагается в начале главного меню, а пункт «Выход» – в конце.

9. Логически взаимосвязанные пункты всплывающего меню объединяются в группы сплошной горизонтальной линией и могут получить свои подзаголовки.

10. При оформлении меню может быть выбрана своя световая схема (color scheme). Вертикальное (всплывающее) меню может быть выделено тенью.

 
 

Результат проектирования иерархического меню следует представить в графическом виде в форме дерева (рисунок 1):

1 – имя меню;

1.1; 1.2; …; 1.n – пункты меню 1-го уровня;

1.2.1; …; 1.n.i – пункты меню 2-го уровня.

Рис. 1. Представление иерархического меню

в графическом виде

Проектирование экранных форм.

Экранные формы в настоящее время образуют основу интерфейса в человеко-машинном диалоге.

Порядок проектирования экранной формы подразумевает следующие этапы:

· проектирование содержание экранной формы;

· проектирование ее формы представления (формы экрана);

· программное обеспечение экранной формы.

Содержание экранной формы зависит от ее назначения. По назначению можно выделить четыре класса экранных форм:

· для ввода информации в базу данных, т.е. для формирования и ведения базы данных; различают экранные формы для ввода справочной информации на этапе конфигурирования информационной системы (базовые формы) и экранные формы для ввода переменной информации;

· для ввода параметров обработки информации по задаче и идентификаторов запросов (условия выборки);

· для вывода результатов решения задачи и справочной информации;

· комбинированные экранные формы, предусматривающие многоцелевое назначение.

Проектирование сценария диалогового режима решения задачи состоит в разработке взаимосвязанной последовательности экранных форм и правил перехода между ними.

Содержание экранных форм должно отвечать принципу «дружественности»: обозначения реквизитов должны быть представлены на русском языке в соответствии с привычной для пользователя терминологией, процесс ввода информации должен сопровождаться подсказками и контролем.

Следует обратить особое внимание на контроль правильности вводимой информации, поскольку основная доля ошибок происходит по вине пользователя, а не машины.

Универсальным методом контроля является визуальный контроль. Контроль количественных реквизитов может состоять в проверке на соответствие области допустимых значений. Контроль реквизитов можно осуществлять путем проверки на соответствие разрешенным значениям (см. рисунок 2).

Повышение достоверности при вводе реквизитов-признаков может быть достигнуто за счет того, что они не вводятся с клавиатуры, а выбираются из предложенного на экране списка (см. рисунок 3).

Используются также методы контрольных сумм, верификации, формальный и логический контроль.

 


Рис. 2. Методы контроля реквизитов в СУБД Microsoft Access

 

 

 
 

 

 

Рис. 3. Использования выбора реквизита-признака

из списка в СУБД Microsoft Access

 

 


Результатом проектирования содержания экранной формы является ее реквизитный состав с указанием метода контроля (см. таблицу 2).

Таблица 2.

Реквизитный состав экранной формы

Наименование реквизита Имя поля в таблице Тип данных Размер поля Метод контроля Описание реквизита
           

 

Проектирование отчетов

Отчет представляет собой наилучшее средство для представления информации из базы данных в виде печатного документа. По сравнению с другими средствами вывода информации на печать отчеты обладают двумя принципиальными преимуществами:

· они предоставляют широкие возможности для группирования и вычисления промежуточных и общих итогов для больших наборов данных;

· отчеты могут быть использованы для получения красиво оформленных счетов, заказов, материалов для презентаций и других документов.

Результаты проектирования отчета представляются в виде таблицы 3.

Таблица 3.

Реквизитный состав формы отчета

Наименование реквизита Источник данных Имя поля в таблице Формула для вычисления
       






Дата добавления: 2014-11-10; просмотров: 2987. Нарушение авторских прав; Мы поможем в написании вашей работы!



Функция спроса населения на данный товар Функция спроса населения на данный товар: Qd=7-Р. Функция предложения: Qs= -5+2Р,где...

Аальтернативная стоимость. Кривая производственных возможностей В экономике Буридании есть 100 ед. труда с производительностью 4 м ткани или 2 кг мяса...

Вычисление основной дактилоскопической формулы Вычислением основной дактоформулы обычно занимается следователь. Для этого все десять пальцев разбиваются на пять пар...

Расчетные и графические задания Равновесный объем - это объем, определяемый равенством спроса и предложения...

Обзор компонентов Multisim Компоненты – это основа любой схемы, это все элементы, из которых она состоит...

Кран машиниста усл. № 394 – назначение и устройство Кран машиниста условный номер 394 предназначен для управления тормозами поезда...

Приложение Г: Особенности заполнение справки формы ву-45   После выполнения полного опробования тормозов, а так же после сокращенного, если предварительно на станции было произведено полное опробование тормозов состава от стационарной установки с автоматической регистрацией параметров или без...

Дизартрии у детей Выделение клинических форм дизартрии у детей является в большой степени условным, так как у них крайне редко бывают локальные поражения мозга, с которыми связаны четко определенные синдромы двигательных нарушений...

Педагогическая структура процесса социализации Характеризуя социализацию как педагогический процессе, следует рассмотреть ее основные компоненты: цель, содержание, средства, функции субъекта и объекта...

Типовые ситуационные задачи. Задача 1. Больной К., 38 лет, шахтер по профессии, во время планового медицинского осмотра предъявил жалобы на появление одышки при значительной физической   Задача 1. Больной К., 38 лет, шахтер по профессии, во время планового медицинского осмотра предъявил жалобы на появление одышки при значительной физической нагрузке. Из медицинской книжки установлено, что он страдает врожденным пороком сердца....

Studopedia.info - Студопедия - 2014-2024 год . (0.013 сек.) русская версия | украинская версия