Создание профессионального интерфейса

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

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

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

Стандартные элементы интерфейса

Постарайтесь не использовать в своей программе нестандартные элементы интерфейса - например, командные кнопки не только с текстом, но и с рисунком, или комбинированные списки со сложной рамкой, которые в изобилии можно найти в oilline-коллекциях VCL и ActiveX-компонентов. Хотя бы потому, что именно так поступают профессиональные разработчики интерфейсов. "Чем стандартнее компоненты, тем лучше и профессиональнее вид" - не раз приходилось слышать от опытных авторов. Посудите сами: вы когда-нибудь видели в программе от Microsoft, Corel или Adobe элемент управления, сделанный начинающим программистом, выложенный в Интернете и сопровожденный припиской в файле readme.txt: "Это мой первый опыт в создании компонента, поэтому не пинайте слишком сильно!"

Замечание

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

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

Небольшая палитра инструментов

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

Одинаковое расстояние между элементами управления

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

TabOrder. "Правильный" порядок

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

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

Выбор шрифтов

Здесь все просто - автор не должен выбирать никаких шрифтов. Оставьте их такими, какими они определены по умолчанию, а лучше - укажите в свойстве Шрифт (Font) соответствующие глобальные переменные Windows: WindowText, MenuText и т. д. В этом случае смена пользователем стандартных шрифтов Windows по своему вкусу с помощью Панели управления отразится и на внешнем виде вашей программы. Таким образом, пользователь, запустив ваш продукт, окажется в знакомом ему окружении.

Еще один вопрос - предпочтительное начертание шрифтов. Современные системы программирования допускают указание для свойства Шрифт, помимо обычного (normal) начертания еще и полужирное (bold), курсивное (italic) и подчеркнутое (underlined), а также их сочетания. Многие авторы, обрадовавшись предоставленным возможностям, охотно ими пользуются, применяя различные комбинации шрифтовых начертании. На самом же деле в интерфейсах Windows-программ принято использовать всего два начертания: нормальное и полужирное (последнее - для выделения какой-либо важной информации, заголовков и т. п.). Применение курсива или подчеркивания, которое, к тому же, пользователь ошибочно может принять за гиперссылку - это дурной тон.

Масштабирование шрифтов

Нужно учитывать, что на разных компьютерах установлены различные по масштабу шрифты: одни пользователи предпочитают крупный шрифт, другие - более мелкий. Из-за этого текстовые подписи (на кнопках, панелях и т. п.), которые автор поместил в своей программе, при запуске продукта пользователями могут увеличиваться в размерах. Многие элементы управления автоматически подстраивают свои размеры согласно содержимому, но некоторые, например Строка состояния (StatusBar), таким свойством не обладают, и текст в этом случае может обрезаться.

Выбор цветов

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

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

Альтернативное управление

Ваша программа должна одинаково хорошо управляться как с помощью мыши, так и клавиатуры. Не должно быть функций, которые можно выполнить только мышью (за исключением традиционно "мышиных" операций - например, рисования в графических редакторах). Наиболее популярные функции следует снабдить "горячими клавишами" для их быстрого вызова. При выборе комбинаций клавиш не забывайте о привычках и навыках пользователей: остановитесь на тех комбинациях, которые обычно используются в программах такого рода. Например, если вы разрабатываете файловый менеджер в стиле Проводника Windows, то лучше создавать комбинации, традиционные для Windows-программ (табл. 1); если же вы ориентируетесь на Norton Commander, то, например, для функции обновления списка файлов присвоите "горячую клавишу" <Ctrl>+<R>, а не <F5> Windows. Но, наверное, в такой ситуации идеальный, но, естественно, не самый легкий вариант - предусмотреть для функций программы две "схемы" горячих клавиш, чтобы удовлетворить потребности приверженцев обоих стилей работы с файлами.

Операция

Таблица 5.1. Стандартные комбинации клавиш в Windows Комбинация клавиш

Новое (окно, письмо, файл и т. п.)            < Ctrl>+<N>

Открыть                                                 <Ctrl>+<O>

Сохранить                                              <Ctrl>+<S>

Печать                                                   <Ctrl >+<Р>

Отменить                                                <Ctrl>+<Z>

Повторить                                               <Ctrl>+<Y>

Вырезать                                 <Ctrl >+<X>, <Shift>+<Del>

Копировать                                              <Ctrl >+<C>, <Ctrl>+<lns>

Вставить (из буфера обмена)                     <Ctrl>+<V>, <Shift>+<lns>

Вставить (новый объект)                            < lns>

Удалить                                                   <Del>

Выделить все                                  <Ctrl>+<A>

Найти                                                     <Ctrl>+<F>

Найти далее                                     <F3>

Заменить                                                <Ctrl>+<H>

Обновить                                               <F5>

Справка                                                <F1>

Кирпичики интерфейса

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

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

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

·        от последовательности правил, по которым функционирует элемент управления.

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

Заголовок окна (формы)

Хотя в палитрах доступных программисту компонентов современных систем создания приложений отсутствует такой элемент управления, как заголовок окна, он определяется свойством Заголовок (Caption) объекта Форма (Form), ему нужно уделять не меньшее внимание, чем кнопкам, спискам и тому подобным элементам.

Заголовок главного окна программы традиционно используется для вывода информации о двух вещах: названии программы и названии документа, с которым в данный момент работает пользователь (если, конечно, в программе вообще предусмотрена обработка каких-либо документов). Так вот, вопрос в том, в каком порядке должна помещаться в окне программы такая информация?

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

В новых версиях программных продуктов постепенно происходит отказ от традиционной схемы построения заголовков окоп. Например, Microsoft уже перевела на новый формат заголовка окна свои продукты - от простого "Блокнота" из состава Windows до программ пакета Office 2000.

Командные кнопки

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

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

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

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

Лично мне приходилось не раз сталкиваться с описанной выше проблемой. Однажды я даже не смог зарегистрировать законно приобретенную копию shareware-программы; кнопка Зарегистрировать все время оставалась отключенной, несмотря на ввод в текстовое окно регистрационного кода. И информацию о том, что именно я делаю неправильно, я смог получить, только написав письмо автору программы... Поэтому при проектировании интерфейса собственной программы, Actual Startup, я решил не поддаваться соблазну сделать диалоговые окна слишком "умными". Кнопка ОК в окне создания нового "сервиса" становится доступной даже при вводе неправильных данных, зато после ее нажатия появляется окно с сообщением об ошибке и информацией о том, как ее исправить.

Текстовые подписи

Казалось бы, какие "подводные камни" могут быть при использовании одного из самых простых элементов управления - Label? Во-первых, не забудьте о масштабировании шрифтов: чтобы текстовая подпись автоматически подстраивала свои размеры согласно содержащемуся в ней тексту, проверьте, что свойство AutoSize имеет значение True. Во-вторых, также присвойте значение True свойству Transparent (если ваша среда разработки поддерживает его) - это приведет к тому, что фон подписи станет прозрачным, и гарантированно убережет вас от возникновения проблемы.

Вот такой он непростой, элемент Label: "обрезанный" текст и фон, не соответствующий фону основной формы, могут сильно испортить отношение пользователя ко всей программе.

Меню

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

В самых первых программах, предназначенных для работы на персональных компьютерах, меню представляло собой список операций, и для выбора какой-либо из них требовалось нажать на клавиатуре клавишу с цифрой, обозначающей порядковый номер соответствующей команды в меню. В программных продуктах для IBM PC середины 80-х годов, большинство из которых работало в текстовом режиме экрана (тот же Norton Commander), меню уже имело сложную структуру: команды были разбиты на группы, названия которых выводились в строке вверху экрана; по ниспадающим спискам команд можно было перемещаться нажатием клавиш со стрелками, а выбор делать при помощи клавиши <Enter>. Во многих программах к управлению подключилась мышь.

С расцветом Windows и ростом популярности графического интерфейса меню заняло основное место среди средств управления компьютерными программами. Законодатель мод в области интерфейсов Windows-приложений - корпорация Microsoft - постоянно улучшала внешний вид и эргономику меню. В Windows 95 в меню были добавлены графические пиктограммы и возможность перемещения курсора мышью, а не только клавиатурой, как в Windows 3.1; в Windows 2000 появились "умные" меню, в которых первыми показывались наиболее часто вызываемые пользователем команды.

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

Вопрос "Что помещать в меню?" я рассмотрю чуть позже, а пока хотел бы обратить внимание на обязательность присутствия меню в главном окне программы. Это, если угодно, такое же правило хорошего тона, как и любое из эвристик Якоба Нильсена, о которых рассказывалось выше. Отказываясь от включения меню в проект своей программы, автор игнорирует опыт и навыки пользователей, заставляет их отказываться от стиля работы, к которому они привыкли. Особенно меня забавляет, когда авторы не делают в программе меню, но создают кнопочную панель инструментов: последняя появилась в интерфейсе программ для персональных компьютеров относительно недавно и, конечно, не может быть полноценной заменой меню. Хотя бы потому, что меню - это не просто список команд, это еще и многофункциональная "шпаргалка" по работе с программой, "шпаргалка", которая всегда под рукой (как известно, читать справочные файлы пользователи не очень любят). Достаточно провести мышью по строке меню вверху экрана, и можно выяснить набор функций программы, комбинации "горячих клавиш" и даже - объяснение назначения кнопок на панели инструментов.

Замечание

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

Теперь - о том, что же можно помещать в меню. Некоторые авторы считают, что для простых программ меню вовсе не нужно, т. к. не стоит делать меню ради двух-трех пунктов. Но даже программа, которая ничего не делает, достойна меню как минимум из двух пунктов: Файл, где находится команда Выход и Справка, включающий подпункт О программе (ведь потенциальные пользователи должны знать, куда отправлять свои денежки, правда?).

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

И, конечно же, не стоит забывать о контекстных меню - меню, появляющихся при щелчке правой кнопкой мыши на каком-либо объекте и содержащими команды для работы с этим объектом. Разработка таких меню - дело, хотя технически очень простое, но при этом довольно кропотливое. Тем не менее, затраты времени и сил обязательно окупятся. Операционная система Windows 95 и ее последующие версии приучили пользователей к мысли, что при щелчке правой кнопкой мыши появляется контекстное меню. Щелчок правой кнопкой мыши стал уже настолько естественным действием, что программа, не "понимающая" его, напоминает человека, который не слышит, что ему говорят. Контекстное меню - одна из самых сильных привычек пользователей и навык, который имеют даже малоопытные новички. Нужно обязательно учитывать это при разработке интерфейсов собственных программ.

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

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

Списки

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

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

Флажки и переключатели

Флажки (CheckBoxes) и переключатели (Option Buttons) используются для одной цели: для выбора из группы предложенных вариантов. Разница между ними, как вам, наверное, известно, состоит в том, что флажки используются для выбора одновременно нескольких вариантов из группы, а переключатели позволяют сделать выбор в пользу только одного варианта.

К сожалению, даже некоторые довольно авторитетные специалисты не придают большого значения этому различию между флажками и переключателями. В очередном номере Visual Basic Programmer's Journal 101 Tech Tips for VB Developers, вышедшем в августе 1999 года, был опубликован небольшой кусок кода, который модифицировал функциональность группы флажков, позволяя им работать, как переключатели: с их помощью можно было выбрать только один вариант из предложенных. "Такое изменение может быть полезно, если вы хотите использовать флажки вместо переключателей", - говорилось в публикации. Редактор сайта iarchitect.com с иронией предложил заменить вторую часть этой фразы на следующее: "...если вы хотите запутать ваших пользователей". Ведь само появление на экране группы флажков сразу говорит пользователю о том, что сейчас ему можно будет сделать выбор нескольких вариантов, а не одного-единственного. Поэтому ни в коем случае не применяйте флажки для организации выбора одного варианта из группы.

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

Кнопочные панели инструментов (Toolbars) - излюбленный компонент многих разработчиков. С ним окно программы сразу приобретает более привлекательный, солидный и профессиональный вид. Любовь программистов к панелям инструментов настолько велика, что они, как я уже рассказывал чуть выше, даже отказываются в пользу них от святая святых пользовательского интерфейса - меню! Конечно, популярность компонента приводит к тому, что многие начинающие разработчики при включении панелей инструментов в свой проект сталкиваются с некоторыми "подводными камнями".

Панель инструментов - довольно сложный и, так сказать, капризный компонент. Для его поддержки в Windows включена специальная библиотека - comctl32.dll. За историю развития операционных систем семейства Windows 9.x эта библиотека пережила несколько обновлений, что привело к тому, что в программах, созданных на более поздних версиях системы, с "новыми" версиями comctl32.dll, панель инструментов не может работать, если программа запущена под одной из предыдущих версий Windows. Опытные разработчики обязательно включают в справочные файлы своих программ информацию об этой проблеме. Они выкладывают на своих Web-сайтах новую версию comctl32,dll, чтобы пользователи не самых последних версий Windows могли нормально работать с программой. А вот если программист забывает об этом, то вскоре ему начинают приходить письма от пользователей с сообщениями о странной ошибке, в результате которой на кнопках панелей инструментов не видны пиктограммы.

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

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

А вот например, если вы решите позаимствовать для своей программы пиктограммы популярного менеджера закачек ReGet (http://www.reget.com), то вряд ли это окажется незамеченным. Эти пиктограммы были созданы специально для ReGet в одной из самых крупных студий дизайна в России - Студии Артемия Лебедева (http://www.design.ro), и разработчик ReGet - компания ReGet Software, конечно же, заинтересована в том, чтобы никто, кроме нее, не пользовался этими уникальными пиктограммами.

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

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

А вот разработчики Adobe Photoshop были более последовательны: в нижнем правом углу каждой "сложной" кнопки в качестве индикации помещено изображение стрелки.

Тип границы кнопок на панелях инструментов - тоже не такой простой вопрос, как кажется. Традиционно кнопки на инструментальных панелях точно так же, как и обычные командные кнопки, имели объемную границу вокруг них. Сложившийся порядок нарушил выход версии 3.0 браузера Microsoft Internet Explorer, Кнопки на панели инструментов этой программы имели "плоский" вид: граница появлялась на них лишь после того, как пользователь наводил на кнопку курсор мыши. Оригинальную, хотя и не бесспорную идею охотно подхватили все разработчики, и сегодня практически все программы имеют "плоскую" панель инструментов. Лично я разделяю мнение, что "плоская" панель инструментов выглядит очень необычно и интересно, однако есть пользователи, которым больше по душе традиционное оформление панели инструментов, когда кнопки выглядят именно так, как должны выглядеть кнопки. И те разработчики программ, которые стараются не упускать из виду даже самые незначительные мелочи, предусматривают в своих продуктах возможность смены пользователем вида панели "обычный"/"плоский", тем более что технически реализовать такую функцию в программе очень просто - нужно менять значение всего одного свойства.

Вкладки

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

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

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

Если посмотреть, как эта проблема решается в известных shareware-программах, то можно заметить, что их авторы стремятся уменьшить число вкладок в диалоговых окнах за счет разделения всех вкладок в новые группы, где число вкладок относительно невелико. Например, в главном меню популярного почтового клиента The Bat! (http://www.ritlabs.com) есть отдельный пункт - Свойства, а в нем - несколько подпунктов, вызывающих соответствующие диалоговые окна: Редактор писем. Быстрые шаблоны. Подключение и администрирование и т. п. В некоторых из них вообще отсутствуют вкладки, а некоторые обошлись всего лишь двумя-тремя вкладками. В не менее популярном текстовом редакторе UltraEdit аналогичным образом разнесены окна настройки самого редактора и вспомогательных утилит. В уже много раз упоминавшейся программе Chameleon Clock, в окне Свойства создано три группы опций: Настройки, Действия и Виды (переключение между ними происходит при помощи панели в стиле Microsoft Outlook), в которых находятся по четыре- пять вкладок (а в опции Виды их вообще нет).

Всплывающие подсказки

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

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

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

Осторожно: скины!

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

Человек всегда стремится как-то выделиться, придать себе и своим вещам индивидуальность. Многие люди стараются так украсить собственный дом, автомобиль, рабочее место, чтобы они отличались от других. То же самое наблюдается с компьютерами: пользователи устанавливают в качестве "обоев" Рабочего стола Windows понравившиеся картинки, перенастраивают цветовую и звуковую схемы. Введение возможности изменить вид программы по своему вкусу - закономерное развитие компьютерных интерфейсов, еще один шаг к удовлетворению желания пользователей настраивать все "под себя" и индивидуализировать себя и свое окружение.

Хрестоматийный пример программы, использующей скины, - это мульти-медимный плейер WinAmp (http://www.winamp.com). Именно после ее выхода слово "скины" стало очень модным. Огромной популярностью стали пользоваться программы, как и WinAmp, позволявшие менять "кожу", online-коллекции скинов (например, сайт http://www.skinz.org). Слово "скины" буквально завораживало пользователей, и они торопились скачать и опробовать любой программный продукт, в описании которого оно встречалось. Естественно, сам WinAmp тоже не остался без внимания, заполучив огромную аудиторию пользователей со всего мира, и его часто приводят как пример удачного маркетингового хода.

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

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

Некоторые программисты не обращают на эти доводы никакого внимания:

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

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

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

·        к WinAmp уже нарисовано огромное количество скинов - более сорока трех тысяч (!) на август 2001 года;

·        некоторые программы независимых разработчиков уже поддерживают скины WinAmp.

Таким образом, сделав свой продукт совместимым со "шкурам" WinAmp, вы одним выстрелом убиваете не двух, а трех зайцев, получая:

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

·        огромную потенциальную аудиторию, значительная часть которой вполне может из потенциальной стать реальной: многие пользователи захотят заполучить, например, калькулятор или записную книжку, которые выглядят так же, как и их любимый WinAmp;

·        возможность эффективно рекламировать свою программу: наличие в описании программы слов "поддержка скинов WinAmp" дает неплохой отклик со стороны пользователей на поисковых системах и в online-архивах программного обеспечения.

Если вы захотите встроить в свою программу поддержку скинов, то сначала хорошенько подумайте: а действительно ли "шкуры" так необходимы вашему продукту?

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

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

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