Бильфельд Н.В., Затонский А.В. Основы разработки интерфейсов: Реализация в системе Borland Delphi

Подождите немного. Документ загружается.

•

Ширина списка, если уж нет возможности вместить все строки,

должна позволять различать элементы.

• Необходимо сортировать элементы (по популярности, типу или

алфавиту). За наиболее популярными элементами лучше вставить

разделитель, чтобы отделить от алфавитного списка.

• Пиктограммы обеспечивают существенное повышение

субъективной привлекательности интерфейса и считываются

быстрее «голого» текста.

• В раскрывающемся списке помимо самих элементов надо

предусмотреть метаэлементы «Все», «Ничего» и подобные, если они

нужны.

• Не стоит (даже в Интернет) использовать раскрывающийся список

как навигационное меню – любая моторная ошибка пользователя

может привести к запуску нежелательного в данной ситуации

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

• Высота списка – не менее 4-х строк (а лучше, не менее 8-и). Пустого

места в конце быть не должно.

Комбобокс

Гибрид списка с полем ввода: пользователь может выбрать

существующий элемент, либо ввести свой.

У раскрывающегося комбобокса есть проблемы. Во-первых, он

выглядят в точности как раскрывающийся список, визуально отличаясь от

них только наличием индикатора фокуса ввода (да и то, только тогда, когда

элемент выделен). Это значит, что полноценно пользоваться ими могут

только сравнительно продвинутые пользователи. В этом нет особой

проблемы, поскольку комбобоксом все равно можно пользоваться, как

обычным списком. Во-вторых, что гораздо хуже, раскрывающиеся

комбобоксы отсутствуют в Интернете. Поддержки их нет ни в браузерах, ни

в HTML.

Проблемы расширенных комбобоксов, совершенно иные. Их можно

реализовать в Интернете (через JavaScript). Они имеют уникальный вид,

отличающий их от остальных элементов управления. Зато их сравнительно

трудно (хотя и гораздо легче, чем в интернете) реализовать в оконном

интерфейсе. При этом расширенный комбобокс потребляет много места на

экране.

Поскольку комбобоксы являются гибридами списков и полей ввода, к

ним применимы те же требования, что и к их родителям.

Поля ввода

Поля ввода являются основой любого интерфейса. В результате,

требований к ним довольно много.

Размер по вертикали должен соответствовать размеру вводимого текста

(нарушением этого правила регулярно грешат форумы, заставляющие

пользователей вводить сообщения в поля ввода размером с ноготь).

2. Ширина поля не должна быть больше максимальной длины вводимой

строки: такие поля выглядят неряшливо и обманывают пользователя,

ожидающего продолжения ввода. Особенно это изумляет пользователя,

если объем вводимого текста ограничен, а поле значительно шире.

3. Поскольку восприятие подписей занимает определенное время, в часто

используемых экранах подписи должны быть сверху от поля (чтобы их

было легче не читать), а в редко используемых подписи должны быть

слева (чтобы всегда восприниматься и тем самым сокращать

количество ошибок).

4. Если очень жалко экранное пространство, подпись можно поместить

внутрь поля (и затереть потом вводимым текстом).

5. Крутилка экономит время на ввод (не надо переносить руку на

клавиатуру) и допускает ввод априори корректных данных, в

корректном формате, в корректных пределах.

6. Ползунок хорош, если:

• значений в ряду чисел много;

• нужно передать ранжируемость значений;

• необходимо дать возможность быстро выбрать значение из

большого их количества (в таких случаях ползунок

оказывается самым эффективным элементом, хотя и опасен

возможными человеческими ошибками).

• надо выбирать из ранжированных текстовых значений

(например, «завтрак», «обед», «ужин»).

Меню

Меню – метод взаимодействия пользователя с системой, при котором

пользователь выбирает из предложенных вариантов, а не предоставляет

системе свою команду. Соответственно, диалоговое окно с несколькими

кнопками (и без единого поля ввода) также является меню. Меню позволяет

снизить нагрузку на мозги пользователей, поскольку для выбора команды не

надо вспоминать, какая именно команда нужна и как именно её нужно

использовать – вся (или почти вся) нужная информация уже содержится на

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

пользователей, появляется возможность в значительной мере изъять из этого

диапазона ошибочные действия. Более того: меню показывает пользователям

объем действий, которые они могут совершить благодаря системе, и тем

самым обучают пользователей.

Можно привести две классификации меню:

По расположению:

•

статическое – постоянно присутствует на экране (панель

инструментов): обеспечивают высокую скорость работы, лучше

обучают пользователей, но занимают много места на экране;

• динамическое – пользователь должен вызвать меню, чтобы выбрать

какой-либо элемент (обычное контекстное меню).

2. По разворачиванию:

• разворачивающееся в пространстве (обычное меню): когда

пользователь выбирает элемент нижнего уровня, верхние элементы

остаются видимыми. Обеспечивает большую поддержку контекста

действий пользователей, но эта поддержка обходится в потерю

экранного пространства;

• разворачивающееся во времени: при использовании таких меню,

элементы верхнего уровня (то есть уже пройденные элементы) по тем

или иным причинам исчезают с экрана.

На эффективность меню наибольшее влияние оказывают устройство

отдельных элементов и их группировка. Несколько менее важны факторы,

такие как выделение элементов и стандартность меню.

Важно, чтобы название меню (или элемента) было наилучшим из

возможных, понятным, полно отражающим функциональность элемента.

Функциональность, не отраженная названием элемента, с большой степенью

вероятности не будет найдена значительной частью аудитории. Элементы,

запускающие действие, должны быть глаголами, как командные кнопки.

Наиболее значимое слово должно стоять первым.

Пиктограммы в меню помогают обучить пользователей, если

повторяют кнопки панели управления. Однако, они лучше работают, когда

ими оснащены только важные элементы меню.

Элемент-чекбокс (например, включение и выключение видимости

панели) лучше снабдить «галочкой», а не инвертировать текст

(«Показывать», «Не показывать») или менять начертание элемента. Вообще,

текст с отрицанием в элементах интерфейса плохо воспринимается.

Вид элемента должен подсказывать – произойдет действие или

раскроется подменю («Выбрать…»).

Группировка элементов должна помогать найти элемент. Правильная

группировка отвечает на вопросы:

1. Зачем группировать элементы?

• Меню сканируется быстрее (как и с пиктограммами).

• Разделители подчеркивают связь между элементами.

• Группировка облегчает кластеризацию элементов в

кратковременной памяти пользователя.

2. Как группировать элементы?

• Взаимоисключающие элементы надо помещать в отдельный

уровень иерархии.

•

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

программиста, досконально знающего свой продукт.

3. Как разделять группы между собой?

• Пустым элементом.

• В отдельных иерархических группах.

• Глубина меню увеличивает вероятность каскадных ошибок,

когда неверно выбранный пункт верхнего меню порождает

заведомо ошибочный выбор всех остальных. Главное меню

лучше ограничить 2-3 уровнями.

• В аннотации к элементу можно показать некоторые элементы

нижнего уровня (рис. 9).

Рис. 9. Первое аннотированное меню появилось на портале Yahoo

Контекстные меню не занимают постоянно место на экране и

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

начинающего пользователя. Нельзя делать контекстные меню единственным

способом вызова какой-либо функции.

Объем контекстного меню – не более 7-8 строк, иначе скорость работы

падает. К тому же, большое меню значительнее перекрывает объект, от

которого оно вызвано (в отличие от традиционного меню). Иерархичность в

контекстных меню теряет смысл, так как превращает их в обычные меню.

Порядок следования элементов в контекстном меню более важен, чем в

обычном, и вначале должны следовать наиболее релевантные строки.

Окна

Разработка интерфейса заключается в том, чтобы правильно помещать

правильные элементы управления в правильные окна или экраны, поэтому

окна требуют не меньше заботы, чем элементы управления.

Существуют следующие типы окон (рис. 10):

Рис. 10. Различные типы окон

• главные окна программы;

• окна документа;

• режимные (модальные) диалоговые окна – блокируют доступ к

остальным элементам системы, фактически, переводя интерфейс

в новый режим работы;

• безрежимные диалоговые окна;

•

палитры;

Главное окно

Окно документа

Режимное диалоговое окно

Безрежимное диалоговое окно

Панель инструментов

Палитра

•

окна браузера (поскольку используемая в интернете технология

существенно отличается от обычной, этот тип окон стоит

несколько особняком).

В настоящее время окна документов понемногу сменяются окнами

программ, диалоговые окна – палитрами, палитры – панелями инструментов,

так что в будущем, скорее всего, останутся только окна программ, панели

инструментов и режимные диалоговые окна.

Модальные окна раздражают пользователя: в случае, если такое окно

открыли по ошибке, его приходится закрывать, менять положение в

контексте и открывать окно снова. Безрежимные окна приходится делать

«плавающими» поверх остальных, чтобы пользователь не забывал о них (не

заслонял окнами документов). Палитра, по сути, является безрежимным

окном, из которого убрано все лишнее. Перемещая по экрану палитры,

пользователь индивидуализирует интерфейс, что создает иллюзию

управляемости и успокаивает пользователя. Однако если палитра закрывает

важные элементы, ее приходится двигать с места на место постоянно, даже

если она закрывает не весь элемент, а только малую его часть. Прикрепив

палитру к краю экрана, получили панель инструментов.

Заголовок окна имеет важное значение для выбора между открытыми

окнами средствами операционной системы: пользователь должен иметь

возможность опознать окно по началу текста заголовка.

Строка статуса может как отображать состояние системы (рис. 11), так

и быть эффективной панелью инструментов (рис. 12).

Рис. 11. В строке статуса – разные индикаторы, поле ввода (слева) и

подсказки

Рис. 12. Первые два блока строки статуса показывают положение

открытого фрагмента документа, за ними идут четыре переключателя

режимов, затем кнопка, нажатие на которую пролистывает документ до

ближайшей языковой ошибки (это ещё и индикатор системы проверки

правописания)

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

• позволяют пользователям быстро вызывать нужные функции

мышью;

• позволяют пользователям меньше задействовать память;

•

повышают визуальное богатство интерфейса;

•

ускоряют обучение работе с системой (по сравнению с

раскрывающимся меню) благодаря своей большей наглядности

Однако они занимают много места на экране, так что поместить в них

всё, что хочется, невозможно. Поэтому в них нужно помещать только

наиболее часто используемые команды, и их можно делать зависимыми от

контекста. В то же время, как и контекстное меню, панель управления не

следует делать единственным способом вызова какой-либо функции.

Рекомендуется самые главные кнопки делать в виде пиктограммы и

текста (в том числе, в них проще попасть мышью), а остальные в виде только

пиктограмм (для опытных пользователей) или только текста (для

неопытных).

Полосы прокрутки в настоящее время фактически вытеснены

колесиком мыши, и их применение в окнах оправдано редко, разве что

только вкупе с индикацией сравнительного объема прокрученного текста.

Структура окна

Существует ряд устоявшихся традиций расположения элементов в

окнах.

• Терминационные кнопки (т. е. командные кнопки, управляющие

окном, например «Ok» или «Закрыть») должны быть либо снизу

окна, либо в правой его части.

• Окно должно хорошо сканироваться взглядом, т. е. его основные

части должны быть сразу видны и заметны.

• Окно должно читаться как текст.

• Чаще всего используемые элементы должны быть расположены в

левой верхней части экрана, реже используемые – в правой

нижней части.

Увеличение площади окна за счет применения вкладок обладает

некоторыми особенностями.

• Вкладки (кроме первой) скрывают от пользователя

функциональность.

• Если вкладка раскрывающаяся («Дополнительно…»),

увеличивается количество кликов мыши до нужных элементов.

• Число вкладок ограничено шириной ярлыков (даже помещаемых

в несколько рядов или скрываемых) и способностью к

восприятию пользователя, и не должно быть более 5-7.

• Не следует стремиться сделать одинаковое количество элементов

во вкладках: здесь важнее их правильная смысловая группировка.

• Терминационные кнопки обязательно должны располагаться вне

области вкладок.

Перемещение по полям окна возможно как мышью или «горячими»

клавишами, так и кнопкой Tab. Последнее предпочтительно в

информационных системах, где оператор вносит много данных подряд,

всегда в одном и том же порядке следования полей ввода. Надо обеспечивать

логичный (в смысловом и визуальном плане) порядок перемещения между

полями, не сбивающий пользователя с толку.

Цвет и звук

Пожалуй, ни одна тема не вызывает у дизайнеров такого интереса и

воодушевления, как цвет. Однако при реализации интерфейсов

информационных систем цветовая насыщенность имеет особенности.

Во-первых, цветами невозможно передавать пользователям сколько-

нибудь сложную информацию. Как правило, схемы типа «этот объект

тёмный, значит…» не работают, поскольку требуют от пользователей

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

и анализировать взаимосвязи цветов. Так, строки в таблице, окрашенные в

разные цвета, подсознательно будут группироваться пользователями по

цветовому признаку. Обратите внимание, что работать это будет только при

очень ограниченном числе используемых цветов (максимальное число цветов

равно объему кратковременной памяти). Однако на практике, всё, что можно

передать цветом, умещается в одно предложение: для всех красный цвет

обозначает «нельзя» или «осторожно», для многих людей зеленый

обозначает «поехали» (от умения пользоваться светофором; интересно, что

желтый цвет не работает, хотя должен). Реально актуальна только первая

половина предложения, поскольку в нашем деле фраза «для многих людей»

часто значит «ни для кого».

Во-вторых, восприятие цвета индивидуально, при этом порой слишком

сильно, даже если не принимать во внимание дальтоников. С возрастом

зрение слабеет, при этом видимые цвета темнеют и выцветают. Это значит,

что нельзя использовать цвет как единственный индикатор чего-либо,

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

восприятия цветов происходит другое правило: позволяйте пользователю

самому выбрать цвета, поскольку цвет, нравящийся одному человеку,

возможно, будет вызывать омерзение у другого (желательно делать это

системными средствами).

Звук не является необходимым атрибутом интерфейса, пожалуй, за

одним исключением: система, завершив какую-либо длительную операцию,

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

блока, так как звуковая карта может отсутствовать, или колонки могут быть

выключены.

Основные методы разработки интерфейсов

Создание одного обработчика событий для группы

компонентов

Как было сказано ранее, используя обычные подходы

программирования, как правило, для каждого компонента, используемого в

разрабатываемом приложении, пишутся свои обработчики событий.

Рассмотрим написание одного обработчика для нескольких

компонентов (в частности для компонентов Edit). Основная цель –

информировать пользователя, в который из перечисленных компонентов

осуществляется ввод.

Чтобы написать один обработчик для группы компонентов достаточно

выделить необходимые компоненты (например, удерживая клавишу Shift) и

затем активизировать необходимое событие. Основной задачей данного

обработчика будет определение компонента, от которого произошло

событие. Это можно сделать, назначив свойству Tag перечисленных

компонентов конкретные значения, а в обработчике анализировать эти

значения, например, в операторе Case.

Пример №1

Создадим форму (рис. 13).

Рис. 13. Внешний вид формы примера № 1

Назначим свойству Tag компонентов Edit значения 1, 2 и 3

соответственно. Выделим все компоненты Edit и активизируем событие

OnChange

В обработчике данного события напишем следующий код:

procedure TForm1.Edit1Change(Sender: TObject);

Var S:String;

Рабочий вариант и исходный текст примера находятся в папке Events1 прилагаемого

диска.

begin

Case TEdit(Sender).Tag Of

1:S:='1';

2:S:='2';

3:S:='3';

End;

Label1.Caption:='Ввод в компонент Edit'+S;

end

После запуска программы и ввода текста в компоненты Edit в метке

Label будет выводиться информация о том, в какой компонент

осуществляется ввод.

Данный подход можно использовать во многих случаях, например при

обработке событий от кнопок обычного калькулятора.

Использование переменных, объявленных на классы

компонентов

Кроме стандартных типов переменных, таких как Integer, String, Array,

Boolean и т.д., которые осваиваются студентами еще на стадии изучения

языка Pascal в среде Delphi, имеется возможность объявлять переменные на

любой класс компонентов, например как:

Var

E1,E2:TEdit;

B: Array [1..20] Of TButton;

Такие объявления позволяют, с одной стороны сократить код за счет

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

будет показано дальше, создавать массивы из компонентов.

Пример №2

Необходимо запретить ввод в компоненты Edit любой информации,

кроме действительных чисел с сохранением возможности редактирования

(удаления, вставки и т.д.).

Реализуем данную задачу с использованием одного обработчика

событий, рассмотренного в предыдущем примере и описания переменных на

класс компонента TEdit.

Создадим форму (рис. 14).

Рабочий вариант и исходный текст в папке Variable.