Wiki

Замечания по созданию интерфейса Qt-приложений

Andi Peredri Материалом для данной статьи послужили многочисленные рекомендации дизайнеров, публикации экспертов в области пользовательского графического интерфейса и личный опыт автора. Разработчики Qt уделяют очень много внимания повышению удобства и улучшению внешнего вида GUI-элементов библиотеки. Однако в большей степени удобство интерфейса приложения обеспечивается его разработчиками, поэтому в этой статье рассказывается об основах дизайна вообще и принципах построения GUI в частности. Проблема создания приложений с качественным интерфейсом является особенно актуальной при разработке свободного программного обеспечения, так как разработчикам приходится заниматься дизайном самостоятельно. Предлагаемая здесь информация может быть также полезна разработчикам, использующим альтернативные GUI-инструментарии, например, GTK.
  1. Интерфейс программы должен быть простым, логичным и понятным. Используйте стандартные средства для построения GUI, не удивляйте пользователя.
  2. В сообщениях об ошибках указывайте пользователю возможные пути их решения. Используйте QErrorMessage, чтобы у пользователя была возможность отключить повторяющиеся сообщения:     QErrorMessage::qtHandler()->message("Message...");
  3. Реализуйте функции Undo и Redo. Помните, что пользователи, как и программы, не застрахованы от ошибок. В случаях, когда выполнение операции Undo невозможно, например, при закрытии главного окна программы с не сохраненным документом, требуйте от пользователя подтверждения его намерений с помощью QMessageBox::warning().
  4. Ориентируйте ваши приложения на пользователей различных категорий. Не забывайте добавлять к элементам графического интерфейса всплывающие подсказки, наиболее востребованные новичками. Для более опытных пользователей предоставьте "горячие клавиши".
  5. Показывайте экранную заставку (логотип) во время загрузки программы. Этот прием психологически уменьшает время ожидания загрузки, так как пользователь получает визуальную информацию.
  6. Постарайтесь избегать однозначных ответов Yes и No в диалогах QMessageBox. Замените их названиями предполагаемых действий, например, в диалоге, подтверждающем удаление файла, используйте кнопки Delete и Cancel. В этом случае пользователю не нужно будет тратить время на уточнение формулировки поставленного вопроса, и это ускорит его работу.
  7. Убедитесь, что ваше приложение выглядит одинаково хорошо при использовании различных стилей, цветовых схем и шрифтов. Не переопределяйте в приложении используемые по умолчанию шрифт и стиль. Для настройки этих параметров предназначена утилита qtconfig.
  8. Всегда указывайте название открытого документа в заголовке главного окна программы. Это позволит пользователю быстро находить нужное окно приложения в панели задач.
  9. При создании меню придерживайтесь следующих правил:
    • избегайте глубоких уровней вложенности;
    • используйте стандартные акселераторы для элементов меню;
    • если в определенный момент времени выполнение какой-либо команды невозможно, заблокируйте соответствующий пункт меню;
    • в качестве элементов меню используйте объекты QAction, чтобы в случае необходимости любая команда могла быть продублирована на панели инструментов.
    • добавьте в меню File список недавно открытых документов. Список желательно располагать не в отдельном подменю File -> Open Recent, а непосредственно перед командами Close и Exit:

      Menu

  10. При создании панелей инструментов QToolBar:
    • всегда располагайте их горизонтально в верхней области главного окна приложения (положение по умолчанию). Человеческий глаз производит визуальный поиск по горизонтали быстрее, чем по вертикали.
    • Предоставьте пользователю возможность гибко настраивать панель инструментов: определять состав и порядок элементов.
  11. При создании диалоговых окон учитывайте следующее:
    • диалоговые окна должны свободно помещаться на дисплеях SVGA (800x600);
    • не перегружайте диалоги пояснительной информацией, используйте для этого справку QWhatsThis;
    • снабдите диалоговые окна кнопками Apply, чтобы пользователь мог предварительно убедиться в правильности выполненных настроек;
    • кнопка отмены действия Cancel всегда должна находиться в правом нижнем углу диалога.
  12. После вызова диалога сохранения файла проверьте, ввел ли пользователь расширение имени файла или он справедливо ожидает этих действий от вашей программы? Вот соответствующий пример кода:
        QString filename = QFileDialog::getSaveFileName(0, "Txt Files (*.txt)", this);
        if( filename.isNull() ) return;
        if( !filename.endsWith(".txt") ) filename.append(".txt");
        ...
  13. При использовании вкладок QTabBar ограничьтесь их разумным количеством, чтобы они были полностью видны в окне, и пользователю не приходилось прибегать к их прокрутке. В противном случае, замените их на QListView или QToolBox:

    QTabBar

  14. Не делайте элементы графического интерфейса фиксированного размера. Всегда используйте менеджеры компоновки QVBoxLayout и QHBoxLayout. Это гарантирует приложению хороший внешний вид независимо от локальных настроек и используемых шрифтов.
  15. Активно используйте строку состояния QStatusBar главного окна приложения. Для обеспечения вывода разнотипной информации (текст, пиктограммы, индикаторы) сделайте ее многосекционной, добавив необходимые элементы с помощью statusBar()->addWidget(). Следите за актуальностью выводимой информации и избегайте бесполезных сообщений типа "Ready".
  16. При закрытии приложения обязательно сохраняйте выполненные пользователем настройки с помощью QSettings, в том числе:
    • расположение и размеры главного окна приложения;
    • расположение элементов QToolBar и QToolBox.
  17. Не используйте для построения своих программ интерфейс MDI (Multiple Document Interface). Предоставьте право управления окнами оконному менеджеру. В любом случае, он справится с этим лучше. Всегда используйте SDI (Single Document Interface) интерфейс, открывая каждый документ в новом окне. К тому же SDI-интерфейс проще в реализации и использовании.
  18. При создании собственных пиктограмм учтите следующее:
    • пиктограммы должны быть выполнены в одном стиле;
    • используйте стандартную символику для пиктограмм;
    • тени должны образовываться светом, падающим с верхнего левого угла;
    • красный цвет в пиктограммах используйте только для действий, связанных с удалением данных или прерыванием какого-либо процесса;
  19. Не используйте средства динамической загрузки диалогов из UI-файлов. Несмотря на то, что это позволяет отделить логику программы от ее интерфейса, эта возможность на практике чаще всего оказывается невостребованной. Пользователь не является специалистом по дизайну GUI, поэтому не ожидайте, что он сделает эту работу лучше вас. Правильно спланированный интерфейс не должен нуждаться в последующей доработке. Сами разработчики Qt при сборке своих приложений всегда включают UI-файлы (формы) в конечное приложение и не используют механизм динамической загрузки диалогов (libqui). Косвенной выгодой от такого подхода является более быстрая загрузка программ. Qt Designer использует libqui лишь для загрузки UI-файлов разрабатываемых приложений.
  20. Если документация вашего приложения представлена в формате HTML и не нуждается в поиске по ключевым словам, то в качестве справочной системы используйте браузер, установленный у пользователя, а не поставляемый вместе с Qt Qt Assistant (QAssistantClient). Такое решение предоставляет несколько преимуществ:
    • для просмотра документации может использоваться предпочитаемый браузер (обязательно предоставьте пользователю возможность его выбора!);
    • закладки на страницы документации будут храниться централизовано вместе с другими пользовательскими закладками; более удобные средства навигации;
    • возможность использования в документации более сложной HTML-разметки.
    Заметьте, это не мешает Qt Assistant оставаться лучшим средством обзора документации по Qt.
На этапе тестирования и ввода в эксплуатацию тесно общайтесь с пользователями вашей программы. Даже если у вас огромный опыт разработки GUI-приложений, у каждой программы могут быть свои особенности реализации интерфейса, которые заранее сложно предусмотреть.