Без особой необходимости не делайте окна приложения с изменяемыми пользователем размерами. При изменении размеров, если не применены специальные приемы, нарушается компоновка окна и пользователь ничего не выигрывает от своих операций с окном. Окно имеет смысл делать с изменяемыми размерами, только если это позволяет пользователю изменять полезную площадь каких-то расположенных в нем компонентов отображения и редактирования информации: текстов, изображений, списков и т.п.
Цвет является мощным средством воздействия на психику человека. Именно поэтому обращаться с ним надо очень осторожно. Неудачное цветовое решение может приводить к быстрому утомлению пользователя, работающего с вашим приложением, к рассеиванию его внимания, к частым ошибкам. Слишком яркий или неподходящий цвет может отвлекать внимание пользователя или вводить его в заблуждение, создавать трудности в работе. А удачно подобранная гамма цветов, осмысленные цветовые акценты снижают утомляемость, сосредоточивают внимание пользователя на выполняемых в данный момент операциях, повышают эффективность работы. С помощью цвета вы можете на что-то намекнуть или привлечь внимание к определенным областям экрана. Цвет может также связываться с различными состояниями объектов.
Надо стремиться использовать ограниченный набор цветов и уделять внимание их правильному сочетанию. Расположение ярких цветов, таких, как красный, на зеленом или черном фоне затрудняет возможность сфокусироваться на них. Не рекомендуется использовать дополнительные цвета. Обычно наиболее приемлемым цветом для фона будет нейтральный цвет, например, светло-серый (используется в большинстве продуктов Microsoft). Помните также, что яркие цвета кажутся выступающими из плоскости экрана, в то время как темные как бы отступают вглубь.
Цвет не должен использоваться в качестве основного средства передачи информации. Можно использовать различные панели, формы, штриховку и другие методики выделения областей экрана. Microsoft даже рекомендует разрабатывать приложение сначала в черно-белом варианте, а уже потом добавлять к нему цвет.
Нельзя также забывать, что восприятие цвета очень индивидуально. А по оценке Microsoft девять процентов взрослого населения вообще страдают нарушениями цветовосприятия. Поэтому не стоит навязывать пользователю свое видение цвета, даже если оно безукоризненно. Надо предоставить пользователю возможность самостоятельной настройки на наиболее приемлемую для него гамму. К тому же не стоит забывать, что может быть кто-то захочет использовать вашу программу на машине с монохромным монитором.
Статические цвета вы выбираете сами и они будут оставаться неизменными при работе приложения на любом компьютере. Это не очень хорошо, поскольку пользователь не сможет адаптировать вид вашего приложения к своим потребностям. При выборе желательной ему цветовой схемы пользователь может руководствоваться самыми разными соображениями: начиняя с практических (например, он может хотеть установить черный фон, чтобы экономить энергию батареи), и кончая эстетическими (он может предпочитать, например, шкалу оттенков серого, потому что не различает цвета). Все это он не может делать, если вы задали в приложении статические цвета. Но уж если по каким-то соображениям вам надо их задать, старайтесь использовать базовый набор из 16 цветов. Если вы попытаетесь использовать 256 (или, что еще хуже, 16 миллионов) цветов, это может замедлить работу вашего приложения, или оно будет выглядеть плохо на машине пользователя с 16 цветами. К тому же подумайте (а, как правило, это надо проверить и экспериментально), как будет выглядеть ваше приложение на монохромном дисплее.
Исходя из изложенных соображений, везде, где это имеет смысл, следует использовать для своего приложения палитру системных цветов. Это те цвета, которые устанавливает пользователь при настройке Windows. Когда вы создаете новую форму или размещаете на ней компоненты, Delphi автоматически присваивает им цвета в соответствии со схемой цветов, установленной в Windows. Конечно, вы будете менять эти установки по умолчанию. Но если при этом вы используете соответствующие константы системных цветов, то, когда пользователь изменит цветовую схему оформления экрана Windows, ваше приложение также будет соответственно меняться, и не будет выпадать из общего стиля других приложений.
Не злоупотребляйте в приложении яркими цветами. Пестрое приложение — обычно признак дилетантизма разработчика, утомляет пользователя, рассеивает его внимание. Как правило, используйте системные цвета, которые пользователь может перестраивать по своему усмотрению. Из статических цветов обычно имеет смысл использовать только clBlack — черный, clWhite — белый и clRed — красный цвет предупреждения об опасности.
Использование шрифтов по умолчанию: System или MS Sans Serif, чаще всего позволяет избежать неприятностей. Впрочем, увы, не всегда. Если вы используете для надписей русские тексты, то при запуске приложения на компьютере с нерусифицированным Windows иногда возможны неприятности. Для подобных случаев все-таки полезно приложить файлы использованных шрифтов к вашей программе.
Другой выход из положения — ввести в приложение команду выбора шрифта пользователем. Это позволит ему выбрать подходящий шрифт из имеющихся в его системе. Проведенную пользователем установку можно запоминать в файле .INI, в реестре или в файле конфигурации и читать автоматически информацию из этого файла при каждом запуске приложения (см. разделы 7.3 и 7.4).
Практически любое приложение должно иметь меню, поскольку именно меню дает наиболее удобный доступ к функциям программы. Существует несколько различных типов меню: главное меню с выпадающими списками разделов, каскадные меню, в которых разделу первичного меню ставится в соответствие список подразделов, и всплывающие или контекстные меню, появляющиеся, если пользователь щелкает правой кнопкой мыши на каком-то компоненте.
Основное требование к меню — их стандартизация. Это требование относится ко многим аспектам меню: месту размещения заголовков меню и их разделов, форме самих заголовков, клавишам быстрого доступа, организации каскадных меню. Цель стандартизации — облегчить пользователю работу с приложением. Надо, чтобы пользователю не приходилось думать, в каком меню и как ему надо открыть или сохранить файл, как ему получить справку, как работать с буфером обмена Clipboard и т.д. Для осуществления всех этих операций у пользователя, поработавшего хотя бы с несколькими приложениями Windows, вырабатывается стойкий автоматизм действий и недопустимо этот автоматизм ломать.
Начнем рассмотрение требований с размещения заголовков меню. Конечно, состав меню зависит от конкретного приложения. Но размещение общепринятых разделов должно быть стандартизированным. Все пользователи уже привыкли, что меню Файл размещается слева в полосе главного меню, раздел справки — справа, перед ним в приложениях MDI размещается меню Окно и т.д. Главное меню должно также снабжаться инструментальной панелью (см. рис. 1.5), быстрые кнопки которой дублируют наиболее часто используемые команды меню. На этих кнопках надо использовать, по возможности, привычные картинки.
По возможности стандартным должно быть и расположение разделов в выпадающих меню.
Группы функционально связанных разделов отделяются в выпадающих меню разделителями.
Названия разделов меню должны быть привычными пользователю. Если вы не знаете, как назвать какой-то раздел, не изобретайте свое имя, а попытайтесь найти аналогичный раздел в какой-нибудь русифицированной программе Microsoft для Windows. Названия должны быть краткими и понятными. Не используйте фраз, да и вообще больше двух слов, поскольку это перегружает экран и замедляет выбор пользователя. Названия разделов должны начинаться с заглавной буквы.
Названия разделов меню, связанных с вызовом диалоговых окон, должны заканчиваться многоточием, показывающим пользователю, что при выборе этого раздела ему предстоит установить в диалоге еще какие-то параметры.
Разделы, к которым относятся каскадные меню должны заканчиваться стрелкой, указывающей на наличие дочернего меню данного раздела.
В каждом названии раздела должен быть выделен подчеркиванием символ, соответствующий клавише быстрого доступа к разделу (клавиша Alt плюс подчеркнутый символ). Хотя вряд ли такими клавишами часто пользуются, но традиция указания таких клавиш незыблема. В реальной работе, вероятно, они используются только в случае, когда отказала мышь.
Многим разделам могут быть поставлены в соответствие «горячие» клавиши, позволяющие обратиться к команде данного раздела, даже не заходя в меню. Комбинации таких «горячих» клавиш должны быть традиционными. Например, команды вырезания, копирования и вставки фрагментов текста практически всегда имеют «горячие» клавиши Ctrl-X, Ctrl-C и Ctrl-V соответственно. Заданные сочетания клавиш отображаются в заголовках соответствующих разделов.
Каждое окно, которое вы вводите в свое приложение, должно быть тщательно продумано и скомпоновано. Удачная компоновка может стимулировать эффективную работу пользователя, а неудачная — рассеивать внимание, отвлекать, заставлять тратить лишнее время на поиск нужной кнопки или индикатора.
Управляющие элементы и функционально связанные с ними компоненты экрана должны быть зрительно объединены в группы, заголовки которых коротко и четко поясняют их назначение. Такое объединение позволяют осуществлять различные панели. Можно рекомендовать, как правило, размещать компоненты не непосредственно на форме, а на панелях. Но и внутри панелей надо продумывать размещение компонентов как с точки зрения эстетики, так и с точки зрения визуального отражения взаимоотношений элементов. Например, если имеется кнопка, которая разворачивает окно списка, то эти два компонента должны быть визуально связаны между собой: размещены на одной панели и в непосредственной близости друг от друга. Если же ваш экран представляет собой случайные скопления кнопок, то именно так он и будет восприниматься. И в следующий раз пользователь не захочет пользоваться вашей программой.