Сообщений 21 
Оценка 515 
Оценить 
| Сообщений 21 Оценка 515 Оценить
|
Модное слово дисклеймер (disclaimer) в переводе с английского означает «отказ» или «отречение». Не могу в точности сказать, какова практика его применения у тех наций, которые изобрели этот термин, но в российской практике он применяется, когда автор дисклеймера хочет подчеркнуть, что отказывается от ответственности, которую должен был бы понести, не напиши его. В данном случае об ответственности, надеюсь, речь не идет, а вот расставить точки над i не помешало бы.
Этот материал родился следующим образом. Я по жизни большой любитель красоты и, хотя и не считаю, что именно она спасет мир, но всегда стремился к тому, что на советском языке называлось «товарным видом». Занимаясь программированием, я, закономерно, много времени посвятил изучению графического интерфейса пользователя. (Консольный интерфейс к моменту моего прихода в программирование уже вымер, хотя до сих пор кое-где отдельные граждане пользуются потомками древнего ящера нортонкоммандера). Посмотрев на то, как мои коллеги писали многочисленные окна своих приложений, в том числе диалоговые, я не утерпел и написал для них реферат по книге Official Guidelines for User Interface Developers and Designers, которая входит в состав MSDN. С одной стороны мне было лениво подготовить точный перевод, с другой – у меня было свое видение того, на чем стоит поставить акцент, а что можно опустить, с третьей – кое-где попадаются вкрапления из других материалов MSDN. Этот реферат и лег в основу статьи. Насколько позволили установить мои изыскания, ничьих прав я при этом не нарушил. Впрочем, если ошибаюсь – что ж, готов нести всю полноту ответственности. Далее, вы сами можете видеть, что это не мои взгляды и предпочтения. Это официальные рекомендации от Microsoft, и как с таковыми, имеет смысл с ними ознакомиться. Наконец, лучше всего будет, если вы прочтете оригинал. Он того стоит.
Оказалось, что наши англоязычные коллеги понимают слово «дизайн» расширенно (а не только в применении к расстановке визуальных элементов управления). Согласно главе «Дизайн, ориентированный на данные», и ее продолжению, «Метафора объектов», ключевое понятие для пользователя современных приложений – документы.
Во времена DOS винчестеры пользователей представляли собой яркий пример того, что сейчас называется программно-ориентированным подходом. Как правило, каждая вновь установленная программа создавала отдельный каталог для сохранения своих файлов, причем чаще всего – внутри каталога, в который она была установлена. Скажем, программа для редактирования графики в формате *.bmp, установленная в каталог GraphEdit, запросто могла создать внутри него подкаталог BMP, в который по умолчанию сохранялись файлы. Недостатки такой схемы очевидны, что и привело к появлению документно-ориентированного подхода при работе с файлами. Перечислим основные из этих недостатков:
Microsoft рекомендует использовать папку "Мои документы" для сохранения файлов по умолчанию. Этот каталог является базовым, внутри него пользователи могут создавать свои собственные каталоги проектов. Для файлов, которые четко выделяются в группы, приложение может создать подкаталог самостоятельно. Хорошей иллюстрацией является подкаталог "My Pictures". Следует помнить, что в локализованных версиях операционной системы имя папки "Мои документы" может отличаться, поэтому не следует нигде в коде задавать его явно. Для его получения следует пользоваться функцией SHGetFolderPath.
Ни в коем случае не следует для хранения файлов приложения создавать каталог в корне жесткого диска. Вместо этого приложение должно быть размещено в единственном подкаталоге папки Program Files. При этом необходимо выполнять следующее правило: все файлы, помещенные в подкаталог Program Files должны иметь атрибут read-only. В этом каталоге можно хранить файлы *.exe, *.dll, файлы справки, а также файлы с примерами, clip-art'ы и т.п. Если несколько приложений использует разделяемый код в *.dll и *.ocx файлах, для их хранения предназначен каталог Program Files\Common Files.
Приложению может понадобиться сохранять какую-нибудь информацию для того, чтобы при следующем запуске ею воспользоваться. (Эти данные при первом запуске отсутствуют). К подобным данным можно причислить настройки пользовательского интерфейса. Предпочтительно сохранять пользовательские настройки в реестре. Но также есть информация, которую предпочтительно сохранять во внешних файлах: логи, скрытые базы данных или файлы индексации (а также пользовательские словари, файловый кэш и адресная книга). Чтобы проверить, относится ли файл к данной категории, можно воспользоваться следующим критерием: файл обновляется приложением время от времени либо файл не должен быть скопирован при копировании приложения с компьютера на компьютер. Такие файлы должны быть размещены в папке Application Data. Если такие файлы могут занимать много места, то они должны быть зарегистрированы при помощи интерфейса IEmptyVolumeCache.
Когда пользователь видит файлы, которые он не создавал, и которые имеют непонятные имена, он может удалить их. Не стоит думать, что так поступают только неквалифицированные пользователи. В любом случае, желательно обезопасить файлы от возможного удаления их пользователем. Для этого файлам следует давать понятные имена. Необходимо избегать сокращений (если только они не являются общепринятыми). Ни в коем случае нельзя пользоваться транслитерацией, то есть давать файлам русские имена, записанные латиницей. Это может осложнить локализацию, а также вызвать у пользователя недоверие к качеству продукта (согласно сложившемуся стереотипу, подобная нотация файловых имен – признак непрофессионализма разработчиков). Windows позволяет давать файлам длинные имена, что очень хорошо в смысле удобочитаемости. Не стоит экономить на числе символов в файловых именах.
Когда только возможно, пользуйтесь существующими типами файлов. Если вы создаете новый тип файлов, должна быть возможность однозначно идентифицировать этот тип файлов с вашим приложением. Для этого:
Если этот тип файлов является уникальным для вашего приложения, ассоциируйте приложение с этим типом файлов, чтобы пользователь, открыв этот файл, мог автоматически запустить ваше приложение. Если приложение обрабатывает распространенные типы файлов, перед тем, как ассоциировать эти типы с вашим приложением, необходимо сделать запрос пользователю и предусмотреть возможность отката к прежним ассоциациям.
Кнопки делятся на командные, check-boxes (далее «чекбоксы») и radio-buttons (пусть будут «радиокнопки». Лучше термина не нашел). Командные кнопки должны иметь размеры 50x14 DLU (диалоговых единиц).
| ПРИМЕЧАНИЕ DLU (диалоговых единиц) – это единица размера (по горизонтали или вертикали) в диалоговом окне. Горизонтальная DLU – это средняя ширина шрифта диалогового окна, деленная на 4. Вертикальная - средняя высота шрифта диалогового окна, деленная на 8. |
Если текст не помещается на кнопку, следует увеличить ее размеры, что, однако, не рекомендуется. Кнопки не должны содержать какой-либо графики. Также не рекомендуется пользоваться нестандартными кнопками с собственным кодом отрисовки. Шрифт кнопки должен совпадать со шрифтом диалоговых элементов (рекомендуется гарнитура Tahoma, кегль 8). Если при нажатии на кнопку открывается новый диалог, она должна иметь в конце имени символ многоточия (…). Если кнопка расширяет текущий диалог (изменяет размеры), она должна иметь в конце пару символов «>>». Имя кнопки должно точно отражать суть действия, за которое она отвечает. Имена «Да» и «Нет» следует применять только при конкретно заданном вопросе во всплывающих сообщениях. В диалогах имена должны быть, соответственно, «ОК» и «Отмена».
Рисунок 1.
Радиокнопки должны находиться в количестве от 2 до 7 для одного выбора. В противном случае следует применять список или выпадающий список (combo-box). Как и иные объединённые по смыслу элементы диалога, радиокнопки должны быть помещены в group-box. Требуется обязательное использование стандартных элементов Windows (как радиокнопок, так и рамки). Поддерживайте выбор из группы радиокнопок с помощью клавиатуры: при нажатии стрелок должен меняться фокус и выбираться новая кнопка, при нажатии TAB должен переходить только фокус, а выбирать в активные неактивную радиокнопку следует нажатием пробела.
Чекбоксы должны использоваться для принятия пользователем одного из двух возможных решений. Чекбоксы могут находиться в трёх состояниях. Следует иметь в виду, что когда чекбокс относится к группе элементов, следует предусматривать возможность смешанного (mixed) состояния. Предел на количество для чекбоксов такой же (до 7), если же требуется большее число чекбоксов, следует пользоваться элементом управления список со встроенными чекбоксами:
Рисунок 2. Окно Customize программы MS Word 2003.
Имена для чекбоксов и радиокнопок выбираются так, чтобы каждое слово имени начиналось с маленькой буквы (кроме первого), в отличие от имён для кнопок, в которых каждое слово может начинаться с большой буквы. Как видим, ко встроенным чекбоксам это не относится.
Если диалог содержит дополнительные инструкции, добавлять их следует над основным маркером:
Рисунок 3.
Дополнительная информация, которая полезна, но не является необходимой, должна быть краткой.
Список с одиночным выделением служит для выбора одного значения из нескольких. Необходимо, чтобы в списке было представлено не менее 3 и не больше 8 значений (в рамках окна). Список с одиночным выделением удобен для замены большого числа радиокнопок. Всегда следует включать вертикальную прокрутку для такого списка. Если все элементы помещаются в рамку окна списка, полоса прокрутки должна быть скрыта. Для окна списка должна быть реализована поддержка клавиш Home, End, PgUp, PgDn и клавиш-стрелок. Если необходимо сэкономить место в окне, список можно организовать как выпадающий. Установите ширину списка больше, чем средняя ширина элемента. Выпадающая часть списка должна показывать за раз от 3 и, желательно, до 8 элементов. Для списков не рекомендуется использовать собственный код отрисовки выделения.
Поля ввода текста должны быть снабжены текстовыми маркерами, заканчивающимися символом двоеточия. Маркеры следует располагать над полем ввода (выравнивая текст и поле по левому краю) или слева от поля. Если в окне несколько полей ввода текста, их следует расположить один над другим, а маркеры разместить сверху:
Рисунок 4.
Если поле предназначено для ввода чисел, при нажатии на клавиши с символами, недопустимыми в числе (буквы, !, @, #, $ и т.д.) должен раздаваться звук предупреждения, а символ не должен вводиться. Если поле ввода числа имеет ограничение по диапазону, в поле следует помещать стандартный элемент управления up-down control:
Рисунок 5.
Стандартный элемент не требует какого-либо вмешательства со стороны программиста, его достаточно разместить поверх поля ввода, поэтому следует избегать элементов аналогичного назначения с собственной отрисовкой. Если поле ввода является частью диалога, содержащего кнопки «ОК» или «Применить», и при редактировании нет необходимости интерактивно отслеживать изменение значения поля, проверку на вхождение в диапазон следует производить при нажатии на эти кнопки. Если значение недопустимо, диалог не закрывается, а появляется сообщение, что поле ввода содержит недопустимую информацию со ссылкой на диапазон. Если поле ввода предназначено для ввода имени файла или папки, сразу за полем ввода должна быть расположена кнопка с многоточием для быстрого поиска объекта:
Рисунок 6.
Имя диалога должно ассоциироваться с командой, которой был вызван данный диалог. Каждое слово имени должно начинаться с заглавной буквы в английском варианте и с маленькой (кроме первого) – в русском. Имя диалога не должно содержать символа многоточия. Исключение – когда размер диалога модифицируется и окно уже, нежели необходимо для вывода заголовка.
Если окно содержит кнопку «ОК», она должна быть выделена по умолчанию. Кнопка «ОК» всегда должна находиться слева, за ней – кнопка «Отмена», затем – если есть – кнопка «Применить». В стандартных локализациях порядок чтения идет слева направо и сверху вниз. Поэтому более важные опции должны располагаться как можно ближе к левому верхнему углу диалога. Нестандартную ориентацию элементов управления допустимо использовать, только если на это имеются веские причины. Например, кнопки «Север», «Юг», «Запад», «Восток» можно расположить «крестиком». По возможности для распространённых действий (загрузка/сохранение и т.п.) следует пользоваться стандартными диалогами операционной системы.
| ПРИМЕЧАНИЕ Важное примечание: если вы разрабатываете Win32-приложения, всегда пользуйтесь стандартными элементами Windows, исключения должны быть крайне редки и хорошо аргументированы. Пример правильного исключения – использование классов и компонентов «MS Office look-n-feel», а также компонента Color picker. К сожалению, он недокументирован, хотя и используется в Windows. |
Панель задач – панель, на которой приложения размещают свои кнопки. Есть простое правило использования панели задач: если у приложения имеется главное окно, в панели задач должно быть размещено именно оно. Ни одно дочернее окно на панели задач представлено быть не должно. Исключение: если у программы есть незакрывающееся окно, то есть при нажатии на кнопку закрытия оно не выгружается, а продолжает работать в фоновом режиме, оно должно быть размещено в system tray. Окно управления печатью документов реализовано именно так.
Панель быстрого запуска не должна изменяться программами. Эту панель разработали специально для настройки исключительно пользователем.
Приложение не должно использовать сообщения, чтобы известить пользователя об изменениях в работе программы, если приложение неактивно. Например, прежде чем вывести сообщение о том, что расчёт или конвертация закончены, программа должна проанализировать свою активность, и если оно неактивно, воспользоваться функцией мигания кнопки на панели задач. За реализацию отвечают функции FlashWindow и GetCaretBlinkTime. При этом можно пользоваться Baloon Tips.
Следует по возможности избегать сообщений об ошибках, которые произошли в результате действий пользователя. Например, совершенно не допустимы сообщения типа: «Программа не может удалить/скопировать/изменить элемент, потому, что ничего не выделено». Если операция недопустима, то соответствующие кнопки должны быть недоступны пользователю. Тем более, недопустимо, когда кнопка доступна, сообщение пользователю не посылается, а действие просто не выполняется. В програмистском обиходе такая практика шутливо называется «защита от дурака», хотя я бы политкорректно назвал ее «защита от необдуманных действий».
В сообщениях следует использовать стандартные значки операционной системы. Ниже представлена таблица, показывающая, в каких случаях какой значок следует применять:
| Значок | Ситуация |
|---|---|
|
Информировать
Предоставить пользователю информацию о результатах команды. Окно такого сообщения не должно содержать иных кнопок, кроме «ОК». |
|
Предупредить
Сообщить пользователю о ситуации, в которой он должен принять решение перед продолжением. Окна таких сообщений могут содержать кнопки «Да», «Нет», «Отмена», например: «Сохранить изменения в файл text.txt?» |
|
Критично!
Сообщить пользователю о серьезной проблеме, которая должна быть решена, прежде чем работа будет продолжена. |
|
Устаревший значок В Windows эта иконка оставлена только для совместимости с ранними версиями. Не используйте её. |
При подготовке текстов сообщений пользуйтесь следующими правилами:
Позвольте подвести некоторые итоги. Во-первых, не стоит воспринимать эти рекомендации как догму. Даже сама Microsoft относится к ним довольно творчески, что видно на примере пакета MS Office. Во-вторых, насколько я могу судить, главная идея состоит в том, чтобы интерфейс приложения не был заметен – примерно, как стекло в окне. Его можно очень круто затонировать, но ведь главное, что от требуется от оконного стекла – не заслонять пейзаж (при всей функциональности типа термоизоляции). И, наконец, в-третьих – внешний вид приложения должен настраиваться из операционной системы – с помощью стилей. Кому-то, как говорится, нравится поп, кому-то – попадья. Если пользователь захочет, чтобы его кнопки выглядели как застывшие кусочки стекла – он поставит себе стиль Aqua. Требования исключить собственный код отрисовки элементов – это именно об этом.
Счастливого программирования!
Оба приложения являются цитатой из книги Official Guidelines for User Interface Developers and Designers.
| Окно | Размеры (в диалоговых единицах – DLU) |
|---|---|
| Диалоговые окна и страницы свойств | 252х218, 227х215, 212х188 |
| Кнопки | 50х14 |
| Чекбоксы | Высота - 10 |
| Комбобоксы | Высота - 10 |
| Радиокнопки | Высота - 10 |
| ПРИМЕЧАНИЕ Эти рекомендации вызвали у нас противоречивые чувства. С одной стороны, они, конечно, очень нужны – так как до сих пор существует множество программистов, демонстрирующих чудеса самостийного интерфейсостроения. С другой стороны, они несколько устарели – дело в том, что в Microsoft рекомендации по GUI писали еще времен Windows 95. Следует отметить, что сама Microsoft не всегда и не везде следует собственным рекомендациям. Например, хранение пользовательских настроек в реестре уже уходит в прошлое, и это в ряде случаев значительно облегчает жизнь. Так, в Visual Studio Whidbey (готовящейся к выходу в 2004 году) они хранятся в виде XML-файлов, что значительно облегчает их правку и перенос с компьютера на компьютер. Думаю, многие могут вспомнить проблемы с экспортом настроек Visual Studio и переносом их на другую машину. При разработке, например, RSDN@Home, было выбрано сохранение настроек в XML – что куда удобнее реестра и при развертывании приложения, и при изменении настроек. Интерфейс приложения может быть сделан по рекомендациям Microsoft, Sun, Adobe или любой другой фирмы – но главное, он должен иметь стиль. Это понятие вообще не упоминается в микрософтовских рекомендациях – совершенно непонятно, почему. Уродцы, в изобилии плодящиеся усилиями множества энтузиастов – отличный пример отсутствия именно стиля, а не пренебрежения рекомендациями. В то же время в интерфейсах многих продуктов рекомендации Microsoft просто проигнорированы, но остаются удобными в использовании и весьма элегантными с точки зрения внешнего облика. Например, Lightwave3D от NewTek или WinAmp совершенно непохожи на Windows-программы – но их интерфейс вполне логичен и понятен (конечно, пользователю, знакомому с областью применения программы – однако и PhotoShop некоторые находят непонятным). Многие приложения (хотя бы Norton Utilities) выполнены в собственном стиле, и я не осмелюсь сказать – чей, их или микрософтовский, стиль лучше. Дело в том, что невозможно полностью следовать рекомендациям – поскольку не бывает правил без исключений. Но нельзя быть и немножечко беременной – если вы решили пренебречь рекомендациями, то придется идти до конца. Особенно хорошо неправильность частичного пренебрежения рекомендациями видна на примере приложений для Windows 9х, запускаемых под ХР. |
| Сообщений 21 Оценка 515 Оценить
|
