Paradigmas no layout/design da barra de menus

Question

Fazendo alguma reestruturação na barra de menus My Applications. Ao olhar para outras aplicações, parece haver duas maneiras diferentes de estrutura.

A "velha escola" mais comum, o verbo/comando seguido pelo assunto. Ou seja, o que você quer fazer e em que você quer fazer isso. Igual a:

• Arquivo
  • Novo
    • Foo
    • Bar
  • Abrir
    • Foo
    • Bar
  • Desistir

Ou aquele que novos aplicativos às vezes tentam, provavelmente desde que a Microsoft introduziu seu fita estrutura. Ou seja, com o que você quer trabalhar e com que operação você deseja executar sobre isso. Igual a:

• Arquivo
  • Desistir
• Foo
  • Novo
  • Abrir
• Bar
  • Novo
  • Abrir

Esses dois paradigmas estão estabelecidos? Eles têm um nome? Me ajudaria a me referir a eles e suas diferenças.

Answer 1

Sim, os menus no nível superior podem ser organizados pela classe de objeto em que agem (por exemplo, foos ou barras) ou o tipo de ação que eles realizam (por exemplo, ações de arquivamento). Como regra geral, a barra de menus ou fita na parte superior da janela deve ser organizada por tipo de ação para fornecer ao usuário uma maneira alternativa de encontrar um comando para os menus de contexto (clique com o botão direito do mouse) que são necessariamente organizados por classe de objeto.

Dito isto, muitas hierarquias de cardápio, incluindo a “Old School”, se beneficiariam de serem “achatadas” - de ser mais amplo em cada nível e menos profundo. Hierarquias profundas significam menus em cascata, que são lentos e desajeitados de usar. Poucas opções no nível superior significam rótulos vagos gerais que fornecem muito pouco perfume de informações (o que faz Arquivo realmente significa de qualquer forma?).

Existem várias maneiras de consertar isso enquanto ainda organiza a barra de menus por tipo de ação. Primeiro, há o simples achatamento do menu de arquivos da velha escola, como o Firefox faz:

• Arquivo
  • Novo foo
  • Novo bar
  • Abrir foo
  • Open bar
  • Desistir

O problema é que o menu de arquivos tradicional foi destinado a aplicativos "documentar" que operam em apenas uma classe de objeto principal. Por exemplo, os processadores de texto operam em artigos, os programas de planilhas operam em planilhas, os editores de imagens trabalham em imagens e assim por diante. O arquivo se torna pesado quando existem várias classes principais. Duas classes não são um problema, mas três ou mais são.

Em alguns casos, é melhor adotar a abordagem "suíte" e fazer parecer que você tem um programa separado para cada classe de objeto. Retire a seleção da classe de objetos da sua barra de menus e coloque -a no menu Iniciar, onde você instalou atalhos correspondentes a cada classe de objeto que abre uma janela primária para essa classe. Cada uma dessas “aplicações” tem apenas uma atuação nova e aberta apenas em sua classe:

• Arquivo
  • Novo
  • Abrir
  • Desistir

Em certo sentido, você tornou mais amplo o menu acima de sua barra de menus na hierarquia. Isso é totalmente consistente com outros aplicativos de desktop. É uma opção atraente se os usuários tenderem a trabalhar com apenas uma classe para uma sessão. Viagens frequentes ao menu Iniciar envelhecem.

Se você precisar manter tudo na barra de menus, poderá espalhar o menu de arquivo ao longo da barra de menus.

• Arquivo
  • Salvar
  • Imprimir
  • Desistir
• Novo
  • Foo
  • Bar
• Abrir
  • Foo
  • Bar

Muitos aplicativos com várias classes principais são aplicativos de banco de dados em que cada janela mostra vários objetos (registros do banco de dados). O que o usuário está "abrindo" não é um único arquivo, mas um resultado da consulta. Normalmente, o usuário quase nunca usou para uma janela em branco. Mesmo para entrada de dados, geralmente é útil e raramente prejudicial mostrar os resultados de uma consulta padrão para fornecer algum contexto (por exemplo, registros inseridos da última vez). Se o usuário quiser adicionar um novo registro aos já mostrados, é uma ação em edição, não o arquivo. Para que possamos eliminar novos.

• Programa
  • Foos
  • Barras
  • Desistir
• Arquivo
  • Consulta
  • Perto

Sugiro que você pegue uma sugestão do Mac OSX e tenha um menu de programa para sair (no OSX, o nome do aplicativo é a legenda do menu). O menu do programa possui itens de menu rotulado por sua classe de objeto, mas são ações - eles abrem o Foo e o Bar Windows, respectivamente. Você preenche essas janelas com um resultado de consulta padrão (que poderia estar vazio) ou mostre automaticamente a caixa de diálogo de consulta para o usuário selecionar uma. O item de menu de consulta em Arquivo aparece essa caixa de diálogo para permitir que o usuário altere a consulta para a janela a qualquer momento. Essa caixa de diálogo pode incluir uma opção vazia para casos de borda em que os usuários precisam de uma janela vazia.

Answer 2

Eu acho que é mais preferência pessoal. O que você acha que iria melhor? Se você não está implementando a GUI da fita em seu aplicativo, não há necessidade de copiar a estrutura deles.

Pessoalmente, eu iria com a primeira opção - "Old School", acho mais direta e a abordagem mais pragmática em relação ao problema.