Paradigmas en la disposición/diseño de la barra de menús

Question

Haciendo una reestructuración en la barra de menú de mis aplicaciones.Al observar otras aplicaciones, parece haber dos formas diferentes de estructura.

O la forma más común de la "vieja escuela", el verbo/comando seguido del sujeto.Es decir.¿Qué quieres hacer y en qué quieres hacerlo?Al igual que:

• Archivo
  • Nuevo
    • foo
    • Bar
  • Abierto
    • foo
    • Bar
  • Abandonar

O el que a veces prueban las nuevas aplicaciones, probablemente desde que Microsoft presentó su cinta estructura.Es decir.con qué quiere trabajar y qué operación desea ejecutar al respecto.Al igual que:

• Archivo
  • Abandonar
• foo
  • Nuevo
  • Abierto
• Bar
  • Nuevo
  • Abierto

¿Están establecidos estos dos paradigmas?¿Tienen nombre?Me ayudaría a referirme a ellos y sus diferencias.

Answer 1

Sí, los menús del nivel superior pueden organizarse por la clase de objeto sobre el que actúan (p. ej., Foos o Bars), o el tipo de acción que realizan (p. ej., acciones de archivo).Como regla general, la barra de menú o cinta en la parte superior de la ventana debe estar organizada por tipo de acción para brindar al usuario una forma alternativa de encontrar un comando a los menús contextuales (clic derecho) que necesariamente están organizados por clase de objeto.

Dicho esto, muchas jerarquías de menú, incluida la de la “vieja escuela”, se beneficiarían de ser “aplanadas”, es decir, más amplias en cada nivel y menos profundas.Las jerarquías profundas significan menús en cascada, que son lentos y difíciles de usar.Pocas opciones en el nivel superior significan etiquetas generales vagas que brindan muy poca información sobre el aroma (¿qué significa? Archivo realmente malo ¿de todos modos?).

Hay varias formas de solucionar este problema sin dejar de organizar la barra de menú por tipo de acción.Primero, está el simple aplanamiento del menú Archivo de la vieja escuela, muy parecido a lo que hace Firefox:

• Archivo
  • nuevo foo
  • Nueva barra
  • Foo abierto
  • Barra libre
  • Abandonar

El problema es que el menú Archivo tradicional estaba destinado a aplicaciones de “documentos” que operan sólo en una clase de objeto principal.Por ejemplo, los procesadores de texto funcionan con documentos, los programas de hojas de cálculo funcionan con hojas de trabajo, los editores de imágenes funcionan con imágenes, etc.El archivo se vuelve difícil de manejar cuando hay varias clases principales.Dos clases no son un problema, pero tres o más sí lo son.

En algunos casos, es mejor adoptar el enfoque de "conjunto" y hacer que parezca que tiene un programa separado para cada clase de objeto.Saque la selección de clase de objeto de su barra de menú y colóquela en el menú Inicio, donde ha instalado accesos directos correspondientes a cada clase de objeto que abren una ventana principal para esa clase.Cada una de estas “aplicaciones” solo tiene Nuevas y Abiertas que actúan solo en su clase:

• Archivo
  • Nuevo
  • Abierto
  • Abandonar

En cierto sentido, has ampliado el menú. arriba su barra de menú en la jerarquía.Esto es totalmente coherente con otras aplicaciones de escritorio.Es una opción atractiva si los usuarios tienden a trabajar con una sola clase por sesión.Los viajes frecuentes al menú Inicio se vuelven obsoletos.

Si necesita mantener todo en su barra de menú, puede distribuir el menú Archivo a lo largo de la barra de menú.

• Archivo
  • Ahorrar
  • Imprimir
  • Abandonar
• Nuevo
  • foo
  • Bar
• Abierto
  • foo
  • Bar

Muchas aplicaciones con múltiples clases principales son aplicaciones de bases de datos donde cada ventana muestra múltiples objetos (registros de bases de datos).Lo que el usuario está “abriendo” no es un único archivo sino un resultado de la consulta.Normalmente, el usuario casi nunca utiliza una ventana en blanco.Incluso para la entrada de datos, suele ser útil y rara vez perjudicial mostrar los resultados de una consulta predeterminada para proporcionar algo de contexto (por ejemplo, los registros ingresados ​​la última vez).Si el usuario desea agregar un nuevo registro a los que ya se muestran, es una acción en Editar, no en Archivo.Entonces podemos eliminar New.

• Programa
  • foos
  • Barras
  • Abandonar
• Archivo
  • Consulta
  • Cerca

Le sugiero que siga el ejemplo de Mac OSX y tenga un menú Programa para Salir (en OSX, el nombre de la aplicación es el título del menú).El menú Programa tiene elementos de menú etiquetados por su clase de objeto, pero son acciones: abren las ventanas Foo y Bar respectivamente.Puede llenar estas ventanas con un resultado de consulta predeterminado (que podría estar vacío) o mostrar automáticamente el cuadro de diálogo de consulta para que el usuario seleccione uno.El elemento del menú Consulta en Archivo abre este cuadro de diálogo para permitir al usuario cambiar la consulta de la ventana en cualquier momento.Este cuadro de diálogo puede incluir una opción Vaciar para casos extremos donde los usuarios necesitan una ventana vacía.

Answer 2

Creo que es más preferencia personal. ¿Qué opinas iría mejor? Si no está implementando la interfaz gráfica de usuario de la cinta en su aplicación entonces no hay necesidad de copiar su estructura.

En lo personal me gustaría ir con la primera opción -. "Vieja escuela", me resulta más sencillo y el enfoque más pragmático hacia el problema