2008-11-06 11 views
5

Al desarrollar una aplicación basada en formularios de Windows, ¿hay algún estándar que deba seguirse al diseñar el sistema de menú principal de su formulario?¿Hay algún estándar a seguir para determinar dónde colocar los elementos del menú?

La mayoría de las aplicaciones de Windows con sistemas de menú tendrán su archivo estándar | Editar | Ver | Herramientas | Menús de ayuda ¿Cómo se determina la ubicación de cualquier elemento adicional del menú de nivel superior?

Además, ¿cómo determina la ubicación de los elementos del submenú? Por ejemplo, ¿qué reglas o principios seguiría para determinar si un artículo debe colocarse en Editar, Herramientas o tal vez en su propio menú de nivel superior no estándar?

Busco dos cosas aquí:

  1. recursos publicados (web o impresión) que detallan este (especialmente si es de Microsoft), u otro material de UX o profesionales de la interfaz de usuario.
  2. Sus opiniones propias.

Basado en una respuesta de Gamecat mencionando la cinta de opciones, voy a expandir esto a la cinta de opciones también. ¿Cómo se determina en qué botones aparecen las pestañas? Buscando lo mismo que arriba.

pregunta relacionada: https://stackoverflow.com/questions/126797/is-there-a-style-guide-for-guis-somewhere

Respuesta

7

Las pautas de experiencia de usuario de Microsoft Vista se encuentran en: http://msdn.microsoft.com/en-us/library/aa511258.aspx

contenido específico a los menús, incluyendo menús estándar, se encuentra en: http://msdn.microsoft.com/en-us/library/aa511502.aspx

Esto incluye orden estándar de menús y elementos de menú, sus nombres y sus aceleradores.

Algunas pautas generales:

de archivos es para los comandos que afectan a todo el contenido que el usuario está trabajando en (generalmente un archivo) o toda la aplicación (por ejemplo, la salida). También es un buen lugar para que los usuarios seleccionen el formulario en el que desean trabajar.

Editar es para seleccionar fragmentos de contenido (por ejemplo, Buscar, Seleccionar todo) y actuar sobre tales elementos (Copiar, Eliminar). No lo use como un menú general de "cambiar algo" (por ejemplo, para "editar" preferencias o una macro).

Ver cambia el aspecto o la presentación del contenido sin cambiar el contenido subyacente (por ejemplo, lo que los usuarios ingresaron en sus formularios). Considere no incluyendo en los elementos del menú Ver para controlar la presencia de barras de herramientas (las barras de herramientas no están contenidas). Eso realmente debería ser con Opciones/Preferencias.

Aunque aparece como un estándar, evitaría el menú Herramientas.El nombre no tiene significado y los contenidos son muy a menudo basura al azar. Tenga en cuenta los nombres y la organización utilizados por la cinta de opciones de Office (por ejemplo, donde las opciones son inferiores al equivalente de archivo). Ver http://blogs.msdn.com/jensenh/archive/2006/01/31/520061.aspx.

En general, coloque los elementos del menú específicos de la aplicación debajo de los elementos del menú estándar en un menú estándar para que la memoria muscular del usuario no se vea afectada por los elementos del menú estándar. Sin embargo, si un elemento de menú específico de la aplicación es una variación de un elemento de menú estándar, colóquelo inmediatamente debajo del elemento de menú estándar (por ejemplo, Buscar siguiente debajo Buscar o Pegar especial debajo de Pegar)

No tenga miedo crea tus propios menús para artículos que no encajan en los de arriba. Las barras de menú a menudo tienen una amplitud insuficiente, creando un olor a información débil, especialmente para los elementos de menú no estándar. Ocho a 10 menús es perfectamente aceptable. Un menú con solo tres elementos de menú es perfectamente aceptable; uno con dos elementos de menú no está fuera de discusión.

La cascada o los submenús son difíciles de usar. Agrupe los elementos del menú por separadores en su lugar. Un menú puede tener ~ 15 elementos antes de que sea necesario considerar los menús en cascada. Si tiene tantos elementos de menú, primero considere separar algunos como un menú separado, en lugar de un menú en cascada en un menú.

Coloque sus menús específicos de la aplicación después de Ver pero antes de Ventana o Ayuda en la barra de menú. Recomiendo encarecidamente la búsqueda de usuarios (por ejemplo, clasificación de tarjetas) para organizar y nombrar menús no estándar.

Mire de cerca la cinta, y verá que su organización es prácticamente la misma que las barras de menú, con equivalentes para Archivo (el menú del logotipo), Editar (la pestaña "Inicio", que incluye formato) y Vista , por lo que desde el punto de vista de la organización, no importa si está usando una cinta de opciones o una barra de menú.

La barra de menús sigue siendo la mejor opción para la mayoría de las aplicaciones. La cinta de opciones no significa menos clics que una combinación tradicional barra de menú/barra de herramientas. No salte a la cinta simplemente porque MS lo está presionando. Tengo detalles en http://www.zuschlogin.com/?p=36.

+0

¡Excelente publicación! ¡Gracias! –

0

No es un estándar, pero se puede usar los productos de oficina como una guía.

Por cierto, los menús son del pasado, ahora todo es Ribbon. Y al principio era escéptico sobre la cinta, pero ahora creo que es una muy buena idea. (Minimizar los clics del mouse siempre es una buena idea).

Niza enlace: http://blogs.msdn.com/jeffdav/archive/2004/12/07/278012.aspx

+0

Sí, lo sé ... Me encanta la cinta, pero por desgracia, algunos de nosotros tenemos que mantener aplicaciones escritas hace años que no pueden soportar una interfaz de tipo Ribbon, pero aún así nos gustaría asegurarnos de que estamos siguiendo un estándar cuando se trata de menús. –

0

Algunas cosas a tener en cuenta.

Ambos métodos estandarizados fueron desarrollados e implementados en software de escritorio antes de la web. Esto significa que ninguno de estos dos modelos fue diseñado teniendo en cuenta el contexto web. Hay una gran diferencia entre el entorno de escritorio tradicional y un entorno basado en web: el botón "Atrás" del navegador.

o "Cancelar" también es una forma de "retroceder" y "Aceptar" es una forma de avanzar "hacia adelante". Esta metáfora de "Adelante/Atrás" subyace en la mayoría de las formas de las funciones "Cancelar" y "Aceptar".

Aquí están algunas otras extensiones de esta metáfora:

  • Nos utilizar la visualización para comunicar ideas complejas. Las interfaces gráficas de usuario son una forma de visualización. Tenemos una sólida historia de estándares de visualización en occidente (y más específicamente en la cultura estadounidense)

o Tiempo: en nuestras visualizaciones estándar "Viejo" se representa generalmente a la izquierda, "Nuevo" se representa a la derecha (la mayoría de las representaciones gráficas del tiempo usan esta metáfora de izquierda a derecha)

o Proceso: utilizamos la metáfora de izquierda a derecha cuando visualizamos los pasos progresivos: "Primero" está a la izquierda, "Segundo" se muestra normalmente en el derecho.

o escritura y lectura: en la escritura y la lectura que “continuamos” desplazan “hacia adelante” de izquierda a derecha (a menos que estemos en Asia, por supuesto)

o en el cine: la película es otra forma de visualización . En la película, un estándar en movimiento es: si una persona "va a algún lado", se mueve desde el lado izquierdo de la pantalla hacia la derecha. Si va "atrás", viaja de derecha a izquierda

o El modelo Cancelar/Aceptar puede ayudar a mejorar la toma consciente de decisiones: Este modelo asume que desea leer las opciones antes de tomar una decisión sobre la acción que desea para tomar (recomendable en interacciones importantes que requieren la atención completa del usuario y tienen más de un par de acciones disponibles para ellas). El modelo Cancelar/Aceptar presenta primero las acciones "alternativas" (a la izquierda) ... para que pueda leerlas antes Decidir que "OK" es la acción que realmente quieres tomar. El modelo Aceptar/Cancelar puede hacer que el usuario tenga la costumbre de hacer clic en la primera opción que encuentre. Al mismo tiempo, los usuarios que están entrenados para usar el modelo Cancelar/Aceptar pueden ir directamente al botón "Aceptar" siempre que estén bastante seguros de que esa es la elección que desean hacer.

o Adaptación del sistema operativo: Firefox de Mozilla coincide con el sistema operativo que se utiliza al mostrar el orden de los botones Aceptar y Cancelar. En otras palabras, la pantalla de los botones se adapta para adaptarse a lo que su sistema operativo le ha entrenado para usar.

Se trata de un interesante estudio que aborda esta cuestión muy específica de lo que pide este botón debe estar en: http://measuringuserexperience.com/SubmitCancel/index.htm

  • DM
+0

Un buen artículo, sin embargo, no estoy seguro de ver la relevancia de este hilo sobre los sistemas de menú, aparte de que ambos están relacionados con el diseño de la interfaz de usuario. No voy a rechazarlo solo porque contiene un buen contenido, aunque no me parezca relevante. –

0

Sí ... La agrupación lógica de menús ayudar a sus usuarios recuerda cosas fácilmente Yo tampoco prefiero tener un menú de "Herramientas" y arrojar todo lo que no pertenece a ningún otro lugar aquí ... Debe haber un "Menú de aplicación" como Mac o como el botón de Office (IU de espacio exterior en 2010) donde puede tener esas "herramientas" o preferencias.

Respecto botón de pedido, trate de seguir las convenciones de la plataforma ... http://blog.mugunthkumar.com/tech/elements-of-usability-design-okcancel-vs-cancelok-is-it-just-a-matter-of-taste/

Cuestiones relacionadas