Главная » Delphi » Совет 5 — об интерфейсе

0

То, что мы говорили об интерфейсах ранее, можно конкретизировать так: программа не должна заставлять вас делать что-то лишнее. Меню программы, а также все операции должны быть простыми и понятными и по возможности осуществляться стандартным способом. Надо четко представлять, что именно вы хотите сделать, и идти к цели наиболее коротким и по возможности стандартным путем. Сама Microsoft злостно нарушила это требование еще много лет назад, когда по совершенно необъяснимой причине вдруг задействовала клавишу <Alt> для входа в меню (кстати, в главе 7 вы узнаете, как написать утилиту, которая эту функцию отключает). Хочу предостеречь читателей от подобных извращений— системные клавиши (в первую очередь клавиши- модификаторы <Alt>, <Ctrl> и <Shift>, но также и такие, как <Esc>, <Del>, <End> и пр.) предназначены для выполнения совершенно определенных действий и не должны использоваться в вашей программе ни для чего другого. В противном случае вы обязательно создадите большие трудности пользователям. Единственное исключение— нестандартное использование правых (дополнительных) клавиш <Alt>, <Ctrl> и <Shift>, изредка— второго <Enter>, которое стало уже традиционным но той причине, что для осуществления основных функций они оказались просто лишними. Допустимо также задействовать для какой-то оригинальной операции практически неиспользуемую системную клавишу <ScrollLock>, если вас не раздражает лампочка, а вообще горячие клавиши должны быть только из набора специально для этой цели предназначенных функциональных клавиш <K.v> или буквенно- цифровых в сочетании с клавишами-модификаторами (достаточный набор их имеется прямо в меню соответствующего компонента Delphi и обычно ничего специально придумывать не надо). Не следует также вслед за разработчиками некоторых графических редакторов и CAD использовать в качестве горячих клавиш "голые" буквенные или цифровые клавиши — просто по той причине, что их легко случайно задеть и что-то при этом испортить. Излишне говорить, что любая достаточно солидная программа обязана дублировать все пункты меню горячими клавишами.

Заметки на полях

В качестве типичного примера, как делать не надо, можно привести программы для записи на CD, например, WinOnCD или Nero. Когда мне случилось столкнуться с этими программами первый раз, я был просто ошарашен. Ладно, к тому, что просто записать файл не получится, а надо обязательно создавать некий "project", я был готоа. Но WinOnCD (речь идет о версии 6), помимо идиотских вопросов про какие-то "мультисессии". встретила меня четырьмя смежными окнами, снабженными в общей сложности 19 пунктами меню (многие из которых имеют иногда с десяток подпунктов). Плюс еще семь кнопок без подписей, но и этого разработчикам показалось мало, и на экране наблюдается еще 8 (восемь) закладок. "Боже мой, — растерянно думает пользователь в моем лице— а я-то хотел всего лишь файл на диск записать…". Не думаю, что сильно ошибусь, если предположу, что программисты фирмы Roxio (или те, что продали все это Roxio) решили, что они сделают интерфейс "интуитивно понятным", если продублируют одну и ту же функцию во всех местах, где только осталось свободное место. Какая уж тут психология, эргономика и прочие премудрости…

Поползновения "настоящих программистов" сделать как можно сложнее наблюдаются, например, в таких популярных и необходимых программах, как WinZip, и, к еще большему сожалению, сделанному по ее образцу WinRar — программах, в основе которых лежат чудесные алгоритмы, но с точки зрения удобства интерфейса они заслуживают огромный жирный кол. WinZip (в аер- сии 6.3) имеет в сумме 47 пунктов меню и сверх того панель из восьми кнопок, и к тому же представлена в двух почти ничем не различающихся вариантах ("классический" и еще какой-то. не помню). Легко сообразить, что для программ типа WinZip и WinRar в их основной функциональности меню не требуется вообще (как оно не требуется для окна папки в Проводнике)— все спокойно можно реализовать через правую кнопку мыши. Если разработчик хотел добавить что-то еще, он был просто обязан спрятать это с глаз долой — для функций типа создания самораспаковывающихся архивов лично я бы просто сделал отдельную программу (кстати, сама по себе она реализована в WinRar просто отлично, и мы непременно этим воспользуемся, см. главу 17).

Заметки на полях

В WinRar есть одна концептуальная ошибке, которая может показаться мелкой, но мы остановимся на ней подробнее, т. к. она очень показательна. В диалоге распаковки файлоа в строке с указанием пути указано одно, а в рядом расположенном окне с деревом папок — совершенно другое. Учитывая, что строка пути сделана на осноае компонента Edit с неубранным выделением (к компоненту Edit с его синим выделением мы не раз вернемся), и по умолчанию там путь высаечивается абсолютно нечитаемым белым по синему фону шрифтом 8 кегля, господин Рошал простит меня за то, что я принципиально не пользовался графическим RAR пет шесть— только по крайней необходимости. (WinZip я вообще никогда не пользовался — в Disco Commander входит свой Zip, обращение с которым на много порядков быстрее.) И только потом я обнаружил, что эта программа, оказывается, запоминает последнюю папку и наверху еще есть кнопочка "Показать"! Если это не есть типичное "умножение сущностей без необходимости", то что тогда? Подумайте, сколько в принципе щелчков надо сделать для того, чтобы просто извпечь файл из архива?

Еще один отрицательный пример — демонстрация сокращенного пути к файлу вместо полного. Так, известный антивирус Касперского при сканировании диска может продемонстрировать путь к проверяемому файлу в гаком, например, виде: C:\…\svhost.exe. Скажите, на кого рассчитана такая запись и зачем это демонстрировать вообще? Допустимо лишь сокращать путь до папок, местоположение которых очевидно: запись "..\Borland\Dclphi7\Projects" или ".AProgram FiIes\Adobe\Photoshop" в большинстве случаев не создаст неудобств. Такая запись, наоборот, может быть полезна, т. к. начальные папки ("Borland" и "Program Files" в данном примере) могут быть расположены в самых разных местах, и мы в этой книге, например, таким образом подчеркиваем, что нам это безразлично.

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

Источник: Ревнч Ю. В.  Нестандартные приемы программирования на Delphi. — СПб.: БХВ-Петербург, 2005. — 560 е.: ил.

По теме:

  • Комментарии