studio programacion para móviles libro edición desarrollo curso aplicaciones .net windows winforms user-interface

.net - para - programacion android pdf 2018



¿Hay algún estándar a seguir para determinar dónde colocar los elementos del menú? (7)

Al desarrollar la 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?

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 se 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?

Estoy buscando dos cosas aquí:

  1. Recursos publicados (web o impresos) que detallan esto (especialmente si es de Microsoft) u otro material de UX o UI profesionales.
  2. Tus propias opiniones

Basado en una respuesta de Gamecat mencionando Ribbon, 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

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

El contenido específico de los menús, incluidos los menús estándar, está en: http://msdn.microsoft.com/en-us/library/aa511502.aspx

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

Algunas pautas generales:

File es para comandos que afectan todo el contenido en el que el usuario está trabajando (generalmente un archivo) o la aplicación completa (por ejemplo, Exit). 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 (p. Ej., Buscar, Seleccionar todo) y actuar sobre dichos 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 incluir 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 están en el 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 del menú específico de la aplicación es una variación de un elemento del menú estándar, colóquelo inmediatamente debajo del elemento del menú estándar (por ejemplo, Buscar siguiente debajo Buscar o Pegar especial debajo de Pegar)

No tengas miedo de crear tus propios menús para los artículos que no encajan en los puntos anteriores. 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.

Cascade o 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 de opciones, y verá que su organización es más o menos lo mismo que las barras de menú, con equivalentes para Archivo (el menú del logotipo), Editar (la pestaña "Inicio", que incluye el formato) y Ver, así que desde Desde el punto de vista de la organización, no hay mucha diferencia si está usando una cinta de opciones o una barra de menú.

La barra de menú 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 .

No es un estándar, pero podría 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).

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

Algunas cosas para tener en mente.

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í hay algunas otras extensiones de esta metáfora:

  • Utilizamos 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 estadounidense)

o Tiempo: en nuestras visualizaciones estándar "Viejo" generalmente se representa 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 generalmente a la derecha.

o Escritura y lectura: en escritura y lectura, "continuamos" o avanzamos "de izquierda a derecha" (a menos que estemos en Asia, por supuesto)

o En la película: 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 ella va a "volver", viaja de derecha a izquierda

o El modelo Cancelar / Aceptar puede ayudar a mejorar la toma de decisiones consciente: este modelo asume que desea leer las opciones antes de tomar una decisión sobre qué acción desea realizar (aconsejable en las interacciones importantes que requieren la plena atención del usuario y tienen más que un par de acciones disponibles para ellos.) El modelo Cancelar / Aceptar presenta primero las acciones "alternativas" (a la izquierda) ... para que pueda leerlas antes de decidir que "OK" es la acción que realmente desea tomar. El modelo Aceptar / Cancelar puede hacer que el usuario tenga el hábito de hacer clic en la primera opción que encuentra. 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.

Esta es una encuesta interesante que aborda esta pregunta muy específica sobre en qué orden deberían estar estos botones: http://measuringuserexperience.com/SubmitCancel/index.htm

  • DM

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

Con respecto al orden de los botones, intente seguir las convenciones de la plataforma ... http://blog.mugunthkumar.com/tech/elements-of-usability-design-okcancel-vs-cancelok-is-it-just-a-matter-of- gusto/