Парадигмы в макете/дизайне строки меню

Question

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

Либо самый распространенный способ «старой школы», за глаголом/командой следует подлежащее.Т.е.что вы хотите сделать и на чем вы хотите это сделать.Вот так:

• Файл
  • Новый
    • Фу
    • Бар
  • Открыть
    • Фу
    • Бар
  • Покидать

Или тот, который иногда пробуют новые приложения, вероятно, с тех пор, как Microsoft представила свой лента состав.Т.е.с чем вы хотите работать и какую операцию вы хотите выполнить над этим.Вот так:

• Файл
  • Покидать
• Фу
  • Новый
  • Открыть
• Бар
  • Новый
  • Открыть

Устоялись ли эти две парадигмы?У них есть имя?Помогло бы мне указать на них и их различия.

Answer 1

Да, меню на верхнем уровне могут быть организованы по классу объекта, над которым они действуют (например, Foos или Bars), или по типу выполняемого действия (например, действия по хранению).Как правило, строка меню или лента в верхней части окна должна быть организована по типу действия, чтобы предоставить пользователю альтернативный способ поиска команды в контекстных меню (щелкаемых правой кнопкой мыши), которые обязательно организованы по класс объекта.

Тем не менее, многие иерархии меню, в том числе «старая школа», выиграют от «сглаживания» — от расширения на каждом уровне и менее глубокого.Глубокая иерархия означает каскадные меню, которые медленны и неудобны в использовании.Немногие варианты на верхнем уровне означают общие расплывчатые ярлыки, которые несут очень мало информации (что означает Файл действительно значит в любом случае?).

Есть несколько способов исправить это, сохраняя при этом организацию строки меню по типу действия.Во-первых, это простое выравнивание старого школьного меню «Файл», очень похожее на то, как это делает Firefox:

• Файл
  • Нью Фу
  • Новый Бар
  • Открыть Фу
  • Открытый бар
  • Покидать

Проблема в том, что традиционное меню «Файл» предназначалось для «документных» приложений, которые работают только с одним основным классом объектов.Например, текстовые процессоры работают с бумагами, программы для работы с электронными таблицами — с рабочими листами, редакторы изображений — с изображениями и так далее.Файл становится громоздким, если существует несколько основных классов.Два занятия – не проблема, но три и более – это проблема.

В некоторых случаях лучше всего использовать «пакетный» подход и создать впечатление, будто у вас есть отдельная программа для каждого класса объектов.Уберите выбор класса объекта из строки меню и поместите его в меню «Пуск», где вы установили ярлыки, соответствующие каждому классу объектов, которые открывают главное окно для этого класса.Каждое из этих «приложений» имеет New и Open, действующие только на его класс:

• Файл
  • Новый
  • Открыть
  • Покидать

В каком-то смысле вы расширили меню выше ваша строка меню в иерархии.Это полностью соответствует другим настольным приложениям.Это привлекательный вариант, если пользователи склонны работать только с одним классом в течение сеанса.Частые обращения к меню «Пуск» надоедают.

Если вам нужно сохранить все в строке меню, вы можете распределить меню «Файл» по строке меню.

• Файл
  • Сохранять
  • Распечатать
  • Покидать
• Новый
  • Фу
  • Бар
• Открыть
  • Фу
  • Бар

Многие приложения с несколькими основными классами представляют собой приложения баз данных, в каждом окне которых отображается несколько объектов (записей базы данных).Пользователь «открывает» не отдельный файл, а целый результат запроса.Обычно пользователю практически никогда не приходится использовать пустое окно.Даже при вводе данных часто полезно и редко вредно показывать результаты запроса по умолчанию, чтобы обеспечить некоторый контекст (например, записи, введенные в последний раз).Если пользователь хочет добавить новую запись к уже показанным, это действие выполняется в разделе «Редактировать», а не в разделе «Файл».Таким образом, мы можем устранить New.

• Программа
  • Фос
  • Бары
  • Покидать
• Файл
  • Запрос
  • Закрывать

Я предлагаю вам взять пример с Mac OSX и создать меню «Программа» для выхода (в OSX имя приложения — это заголовок меню).В меню «Программа» есть пункты, помеченные соответствующим классом объекта, но они являются действиями — они открывают окна Foo и Bar соответственно.Вы либо заполняете эти окна результатом запроса по умолчанию (который мог быть пустым) или автоматически отображать диалоговое окно запроса, чтобы пользователь мог его выбрать.Пункт меню «Запрос» в разделе «Файл» открывает это диалоговое окно, позволяющее пользователю изменить запрос к окну в любое время.Это диалоговое окно может включать параметр «Пусто» для крайних случаев, когда пользователям нужно пустое окно.

Answer 2

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

Лично я бы выбрал первый вариант — «старая школа», я считаю его более простым и прагматичным подходом к проблеме.