Рекомендации по написанию диалоговых окон

Диалоговые окна предназначены для ввода-вывода информации в форме, требующей обязательного внимания пользователя. Если обязательность обращения внимания пользователя не требуется, предпочтительным вариантом организации ввода-вывода является либо SDI - интерфейс, либо MDI - интерфейс.

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

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

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

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

Правило 3. Следствие второго правила. Не следует покорять пользователя бизнес-программы изысканной графикой и оригинальными надписями на кнопках вроде "лады", "согласен", "не надо", другими нестандартными высказываниями и особенно жаргонными терминами и выражениями.

Правило 4. Не следует делать предположений о текущем разрешении экрана пользовательского компьютера и текущей глубине цвета. Диалоговые окна следует выполнять такого размера, что его размер по умолчанию меньше чем 640x480. Исключение составляют программы, выполняемые по заказу, к которым могут быть применены стандарты предприятия, например минимальное разрешение на компьютерах будет 800x600. Контролы, критичные к глубине цвета, в случае их использования следует проверить лично на каждой глубине.

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

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

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

Правило 8. В системном меню диалогового окна обязательно должны присутствовать два пункта - Move, Close. В случае если диалоговое окно имеет изменяемые размеры, добавляется третий пункт Size. Проверка - вызвав диалоговое окно, нажать Alt + пробел. Остальные пункты не рекомендуются. Указание в кнопках на заголовке кнопки Help предпочтительнее согласовывать с режимом подключаемой online справки. Если ее нет, то эту кнопку рекомендуется убрать. Ее всегда можно добавить позднее.

Правило 9. Контролы на диалоговом окне бывают двух видов - ввод-вывод данных и подтверждение такого ввода. К вторым относят кнопки вроде OK и Cancel. Кнопки второго типа а также кнопки не связанные с редактированием данных в текущих контролах, например Network в окне выбора файла, предпочтительнее размещать в единообразном виде. Единообразность предпочтительна для всей программы и всех диалоговых окон, в нее входящих. Располагать контролы можно двумя способами. Первый - редактирующие контролы сверху, кнопки подтверждения - снизу в горизонтальный ряд. Второй - редактирующие контролы слева, кнопки подтверждения справа в вертикальный ряд. В ряду с кнопками подтверждения ввода не следует размещять редакторов. Лучше оставить это место пустым.

Правило 10. Более распространенным является второй стиль размещения контролов. Это общая статистика, и ее следует учитывать при проектировании диалогового окна. Если же выбирается вариант с нижним расположением управляющих внопок, то этот стиль должен жестко выдерживаться во всех диалоговых окнах, как, например, это сделано в Borland Resource Workshop.

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

Правило 12. Следствие правила 12. После размещения контролов следует им задать порядох их обхода по табуляции (TabOrder). Сначала в порядке обхода должны быть контролы редактирования, потом кнопка подтверждения, потом кнопка отмены редактирования, потом остальные.

Правило 13. Порядок табуляции должен действовать только на те контролы, которые видимы пользователю. Если табуляция уходит в контрол за пределами окна, это вызывает путаницу.

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

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

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

Правило 17. Если после подтверждения ввода программа начнет какие-то действия, связанные с преобразованием данных, которые пользователь не сможет позднее исправить, кнопке подтверждения следует дать надпись не просто OK, а в виде соответствующего глагола, например диалог печати при подтверждении ввода следом имеет печать на бумагу. Предпочтительное название кнопки - Print.

Правило 18. Размещение диалоговых окон на экране не должно быть неожиданностью для пользователя. Поэтому их следует размещать единообразным образом. Хорошим стилем является центрирование окна. Центрирование может быть выполнено по горизонтали, но со сдвигом по вертикали, например, диалог логина размещается по центру, но приглашение к логину смещено немного вверх (логин в Windows). Центрирование может выполняться относительно родительского окна, относительно экрана и относительно десктопа (в многомониторных системах). Предпочтительным вариантом является единый стиль программы. В большинстве случаев хорошим выбором в случае неопределенности является центрирование относительно экрана. В некоторых случаях размещение диалогового окна не по центру является более оправданным, например, диалоговое окно FindNext может перемещаться по экрану с целью не загораживать выделенный текст. Эта фича многими пользователями воспринимается как демонстрация уважения к их данным и способствует вырабатыванию доверия к программе.

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

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

Правило 21. Организация передачи данных должна предусматривать, что пользователь может нажать кнопку Escape на клавиатуре, кнопку Cancel на диалоге, либо крестик на заголовке окна. Все эти действия должны быть проверены на эквивалентность реакции в программном коде.

Правило 22. Контролы диалогового окна должны позволять переключение фокуса ввода с помощью только клавиатуры. Для этого выполняются акселераторы контролов. В кнопках и текстовых метках акселератор отмечается подчеркиванием одного из символов. Программист указывает акселератор символом & в надписи контрола. Например &Edit.

Правило 23. Следствие правила 22. В случае если составить акселератор затруднительно, например при обилии контролов, акселератор приписывается отдельно в круглых скобках, например Precedence(&W):

Правило 24. Следствие правила 22. Контролы, для которых нет возможности указать акселератор, должны иметь соответствующую им текстовую надпись с акселератором, свойство FocusControl которой должно указывать на этот контрол. Это для Delphi - подобных средств разработки. В случае использования WinAPI для реализации диалоговых окон и редактирования ресурса окна надпись будет переключать фокус в тот контрол, который следует за ней в описании ресурса.

Правило 25. Большинство типов данных не требуют изобретения нового способа редактирования. Не следует реализовывать хитроумный drag-n-drop в диалоговых окнах без явной на то необходимости и прочее в духе необычного интерфейса, иначе придется каждый раз писать, что в этом диалоге возможен drag-n-drop.

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

Правило 27. Следует помнить, что клипборд является наиболее полезным средством CASE (Computer Added Software Engineering). Большинство диалоговых окон программы может иметь одинаковые ширину, высоту, расположение кнопок подтверждения ввода и размеры отступов контролов от границ окна. В общем, в большинстве случаев дизайн может быть скопирован. Это придает программе стильность, а стильность интерфейса вырабатывает у пользователя доверие к программе. Во многих случаях существует возможность либо копировать интерфейс, либо использовать несколько подходящих визардов для генерации однотипных шаблонов.

Правило 28. В интерфейсе Windows преобладают два вида расположения диалоговых окон - портретом и ландшафтом. Полностью квадратных окон еще не встречалось ни разу. Расположение диалогового окна портретом в большинстве случаев ассоциируется с настройками чего-то (Properties), расположение ландшафтом ассоциируется с вводом новой информации. Эту статистику следует учитывать. Например, создание ярлыка выполняется ландшафтным диалоговым окном, но его последующее редактирование - портретным. Данная методика может быть спорной, но на такую статистику также следует обращать внимание. Это правило является, видимо, наиболее спорным и его использование существенно зависит от реализуемой программы. Если программа рассчитана на слабоподготовленного пользователя, то следование методике Microsoft может быть даже оправдано. В любом случае выполнение визардов в портретном расположении еще ни разу не встречалось.

Правило 29. Следствие правила 28. Некоторые объекты при их начальном создании могут быть редактированы в интерфейсе визарда, но последующее редактирование может быть выполнено в виде портретного диалога с закладками. Второй вариант позволяет в отличие от первого переключиться в произвольный контрол. Таким образом, следует учитывать, что существует достаточно большое количество программ, в которых редактирование объекта и редактирование вновь создаваемого объекта может быть выполнено в виде двух совершенно различных, в том числе по функциональности, диалоговых окон. Более того, если оба варианта выполняются в виде одного и того же окна, то у пользователя может возникнуть ощущение, что это не он создает данные, а программа сама втихаря что-то делает и вместо ввода новых данных программа предлагает редактирование уже созданных ей данных, хотя пользователь еще не подтвердил их создание. Это может породить недоверие к программе и неуверенность в том, что пользователь контролирует ситуацию со своими данными.

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

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