Изучение премудростей дизайна пользовательских интерфейсов я начинал с прочтения отличной книги Джоэля Спольски «Руководство по UI дизайну для программистов». Поскольку там были высказаны очень здравые идеи, я стал постоянным читателем его блога JoelOnSoftware и позднее вступил в сообщество переводчиков.
А недавно Джоэль опубликовал там коротенькую заметку следующего содержания:
Не скрывайте и не выключайте пунктов меню.
Очень давно стало модным, даже рекомендуемым, выключать пункты меню, если они не могут быть использованы.
Не делайте этого. Пользователи видят выключенные пункты меню, по которым они хотят кликнуть, и остаются без каких-либо догадок о том, что они могут сделать для их включения.
Вместо этого, оставляйте пункт меню включенным. Если по каким-то причинам вы не можете завершить действие, выбранный пункт меню может отобразить пользователю сообщение, почему это не получилось.
Заметка вызвала неоднозначную реакцию на его форуме. Многие разработчики интерфейса посчитали это нецелесообразным, потому что такой подход помогает начинающим пользователям, но вызывает огромное раздражение опытных пользователей. Представьте себе ситуацию, когда вы, не выделив предварительно текст в редакторе Word, случайно нажимаете пункт меню «Правка—Копировать». И вместо того, чтобы проигнорировать действие, которое не может быть выполнено в данном контексте, на экран вываливается диалог с текстом вроде такого: «Команда Копировать недоступна, так как вы предварительно не выделили текст, который надо скопировать». Этот принцип напрямую противоречит главе 6 вышеназванной книги Джоэля, потому что опытные пользователи никогда не читают текстовых сообщений, а от появления блокирующих диалоговых окон могут иногда просто разбить монитор.
Форумчане придумали альтернативное решение: показывать пункты меню отключенными, но оставлять их доступными для нажатия, а при нажатии показывать всплывающую подсказку с пояснением причин отключения. Правда, никто не учел себестоимость реализации такого решения, потому что выключенные стандартными способами пункты меню во всех RAD-системах, которые я знаю, не генерируют событие нажатия. А потому придется «плыть против течения» и городить жуткий дополнительный код для реализации нестандартного затенения неактивных пунктов меню + отслеживания кликов по ним.
На мой взгляд, вместо этого стоит пораскинуть мозгами при проектировании интерфейса и применять подход, предложенный Джоэлем, только в тех случаях, когда предыдущий «жизненный опыт» пользователя не может помочь ему интуитивно определить причину отключении пунктов меню. В 99% случаев пользователи начинают использовать вашу программу только после знакомства с одним или несколькими десктопными приложениями, вроде MS Office. Поэтому базовые операции, которые можно/нельзя провести с различными объектами приложения, им, скорее всего, известны.
При пристальном рассмотрении своего текущего проекта я понял, что уже наполовину это реализовал. В редактор тестов можно вставлять формулы, которые являются OLE-объектами Microsoft Equation. Делается это путем выбора пункта меню «Вставка—Формула». Объект Microsoft Equation не входит в стандартную поставку Windows, а устанавливается на компьютер вместе с пакетом Microsoft Office. Потому вставка формулы невозможна при его отсутствии.
Там где формулу нельзя вставить в принципе (например, когда фокус ввода не находится в редакторах вопросов/ответов), было принято решение блокировать этот пункт меню. А в случае, если формулу вставить можно, но Microsoft Equation не установлен, соответствующий пункт меню не блокируется, и при его нажатии выводится сообщение, поясняющее отсутствие OLE-объекта на компьютере. Без этого неподготовленный пользователь вряд ли сможет проявить интуицию и догадаться, почему формулу вставить нельзя, без прочтения руководства по использованию.
