3,1415926, или Пара слов о ПИ

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

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

Меню справа, меню слева…

Сразу предупрежу, что мы не будем касаться программ со шкурами-скинами, окнами неправильной формы и прочими наворотами экзотического вида и столь же экзотического предназначения, а поговорим о программах, базирующихся на привычных пользователю стандартах Windows. Это и есть одно из важнейших требований к ПИ: он должен быть привычен и знаком пользователю. Человек не обязан искать в программе меню и гадать, какой кнопкой она (программа) сворачивается! Примером нарушения этого правила служат столь любимые некоторыми разработчиками пункты меню в правой части окна (рис. 1). Далеко не каждый пользователь сможет найти такое меню быстро, если вообще найдет. Не менее спорным является использование элемента меню в качестве индикатора. Я сам лишь случайно обнаружил, что индикатор прокрутки текста в окне просмотра Windows Commander является также и элементом меню, причем элементом никак не продублированным (рис. 2).

Не менее привычными стоит также считать размеры элементов, подписи и картинки на кнопках Microsoft Office: сейчас редко найдешь человека, ни разу не работавшего с MS Word. Кстати, специально для особо ленивых: иконки для своего приложения вы можете не рисовать, а наковырять из MS Office с помощью экстрактора иконок авторства Анатолия Тенцера .

Понятие «привычности» включает в себя и соблюдение стандартов, принятых в Windows. Так, приложению желательно иметь меню, в котором отражена вся его функциональность, панели инструментов, расположенные в верхней или левой части окна ¹ и являющиеся настраиваемыми (если приложение богато функциями) и перемещаемыми. Меню должно содержать более или менее привычные функции, а его заголовки должны быть созвучны с объектами, с которыми работает программа. Так, для программы, работающей с документами, резонно первым сделать меню «Файл», последним пунктом которого будет «Выход». То же самое можно сказать и о сочетаниях клавиш. Не старайтесь придумать что-то новое для стандартных операций - пользователь вас просто не поймет.

Важным для понимания работы программы является и четкое соблюдение ее внутренней логики, отраженной в дизайне. Если вы используете в приложении несколько различных диалогов, постарайтесь сделать их единообразными, чтобы пользователь, разобравшись с одним из них, не испытывал затруднений с другим. Постарайтесь расположить кнопки «ОК», «Да», «Отмена» и т. п. в правой нижней части окна. Подписи к полям ввода должны быть слева или сверху от них. Желательно, чтобы различные элементы окна объединялись в группы, упорядоченные по высоте или ширине, что лучше воспринимается визуально.

В поисках пропавшей программы

Стоит сказать и об использовании System tray (области рядом с часами). Сворачивать приложение в трей сейчас довольно модно, а зачастую и удобно, но далеко не всегда привычно для пользователя. Представьте себе недоумение неопытного юзера, минимизировавшего программу, с которой он работал, когда оная программа исчезает в неизвестном направлении ²! В этом отношении очень грамотно построена минимизация переводчика «Сократ»: при запуске программы появляется так называемая splash-заставка, которая плавно сворачивается в tray, давая понять, где находится приложение, пребывая в неактивном состоянии. Несомненно, вопрос целесообразности сворачивания программы «к часикам» остается на усмотрение автора, но, по крайней мере, стоит включить в программу автоматическое определение уже запущенной копии, дабы не плодить одинаковых запущенных программ, а разворачивать выполняющееся приложение из трея. Кроме того, возможность минимизации в трей имеет смысл делать настраиваемой и отключаемой.

Часто встречается и такой недостаток интерфейса: многие программы легко справляются с небольшими наборами данных, но отчаянно «тормозят» при обработке больших объемов информации, при этом понять, работает программа или наглухо зависла, зачастую невозможно. Во избежание этого процессы, растянутые во времени (даже потенциально, например, при выполнении программы на медленной машине), должны иметь индикатор процесса ³ и кнопку завершения, иначе пользователь недолго будет терпеть вашу программу на своем рабочем столе.

Масштаб 1:10

Еще одна проблема - несоразмерность элементов управления при масштабировании окна программы. Бороться с этим (точнее, не допускать этого) довольно просто. В Delphi ⁴, например, у подавляющего большинства визуальных элементов есть свойство Align, которое может принимать следующие значения:

• alLeft и alRight - выровнять по левому или правому краю контейнера ⁵ соответственно;

• alBottom и alTop - выровнять по нижнему или верхнему краю контейнера соответственно;

• alClient - растянуть на весь контейнер.

Использование этих свойств в сочетании с компонентом TSplitter позволяет сделать вид окна «предсказуемым» при любом масштабировании.

«Больным» вопросом является любезно предоставляемая Windows возможность изменения системных шрифтов, используемых для отображения заголовков окон, меню, надписей на кнопках и т. д. на нестандартные (например, более крупные) - тут уже глючит даже сама система. Однако корректное решение этого вопроса целиком и полностью на совести программиста и зависит лишь от его терпеливости - придется не один десяток раз изменять шрифты и экранное разрешение и править программу в соответствии с результатами. Конечно, вовсе не обязательно, что после этого программа будет хорошо смотреться со всеми шрифтами на разных машинах, но по крайней мере под основные, наиболее часто используемые шрифты и под все экранные разрешения ее оптимизировать стоит.

Красота хуже воровства

Отдельная тема - украшательство программ. Я ничего не имею против красивой программы, даже наоборот, я обеими руками за! Но таких программ, к сожалению, не слишком много, и вот почему. «Красота не должна убивать функциональность!» - вот первое правило построения красивого интерфейса, которое очень часто не соблюдается. Красивый диалог с красивой надписью вовсе не всегда будет удобен. Если вы делаете что-то подобное (рис. 3), то постарайтесь не забыть, что надпись должна легко читаться, так как информация для диалогового окна куда важнее красоты. Вы можете изменять элементы управления, делая их более нарядными, но не забудьте сделать их и более удобными.

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

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

О многостраничных элементах (например, диалоговых окнах с закладками) нужно упомянуть особо: применять их рекомендуется очень осторожно. По странной прихоти Microsoft этот элемент выполнен таким образом, что если все закладки не умещаются в одну строчку, то они начинают выводиться в два или три ряда. Переключение между закладками зачастую сбивает пользователя с толку, и в результате выясняется, что на одной закладке он побывал три раза, а на другой ни одного. Поэтому старайтесь размещать закладки в один ряд. Это особенно сложно при разработке многоязычных приложений, так как в разных языках длина одних и тех же слов разная (на это стоит обратить внимание и при дизайне окон с большим количеством близко стоящих элементов). Если же разместить все закладки в один ряд не удается, возможно, стоит выбрать другую модель диалогового окна? Сравните окна настройки параметров того же MS Word (рис. 4) и Allaire HomeSite (рис. 5). Кстати, Microsoft использует вторую интерфейсную модель в своем новом средстве настройки и управления системой - Microsoft Management Console.

Я постарался описать основные трудности и ошибки, возникающие при проектировании ПИ. Cделать удобное приложение нетрудно, и для этого даже не надо затрачивать сверхусилий - наоборот, зачастую нужно вовремя сказать себе «Стоп» и перестать украшать собственную программу. И еще одно важное правило: разрабатывая программу, посмотрите, как устроены программы-лидеры в данной области, и постарайтесь перенять у них все основные особенности ПИ.

[i39830]