Fundamentos del Aprendizaje de la Cuarta Dimensión

Una de las características más distintivas de la plataforma 4D es su compatibilidad con los Menús personalizados. No solo puede crear sus propias barras de menú, sino que también puede configurar 4D para que se inicie directamente en el modo Menús personalizados, lo que le brinda un control completo sobre la experiencia del usuario desde el momento en que se abre la aplicación. Esta es una desviación significativa de muchas herramientas de desarrollo rápido de aplicaciones, donde la barra de menús está fijada en gran medida por el framework y usted está limitado a habilitar o deshabilitar los comandos integrados.

Con los Menús personalizados de 4D, se le permite modificar el Menú Archivo y añadir sus propios menús y elementos de menú entre los menús Editar y Ayuda. Los menús Editar y Ayuda son fijos: no puede modificarlos. Todo lo demás es suyo para diseñar.

Puntos clave

• Los Menús personalizados de 4D le permiten reemplazar la barra de menú predeterminada por una diseñada por usted, y puede configurar la aplicación para que se abra en el modo Menús personalizados para un control total.
• Puede modificar el Menú Archivo e insertar sus propios menús y elementos entre los menús Editar y Ayuda, pero los menús Editar y Ayuda en sí son fijos.
• Puede crear múltiples barras de menú diferentes y asignar cada una a una situación distinta, pero el uso excesivo de esto es una ruta rápida para confundir a sus usuarios.
• Comparar su barra de menú planificada con lo que usan los programas establecidos es una forma práctica de verificar la coherencia de su diseño antes de comprometerse con él.
• El diseño de menús es tanto una decisión de experiencia de usuario como técnica; la consistencia y la previsibilidad importan más que la originalidad.

Por qué son importantes los Menús personalizados en 4D

En una aplicación de escritorio tradicional, la barra de menú es el mapa principal de lo que puede hacer el programa. Los usuarios la escanean para descubrir funciones y confían en que sea estable. Cuando entrega una aplicación 4D a un equipo de negocios, la barra de menú suele ser lo primero con lo que interactúan, antes de tocar cualquier formulario, lista o registro.

Eso hace que la barra de menús sea una superficie de diseño, no una idea de último momento. 4D lo reconoce al permitir que los desarrolladores asuman la propiedad total de ella. Vale la pena detallar las consecuencias prácticas:

• Usted controla la capacidad de descubrimiento. Si una función es importante, puede colocarla en el menú donde los usuarios la encontrarán, en lugar de esperar que se topen con un botón.
• Usted controla el vocabulario. Las etiquetas de menú integradas usan términos genéricos. Sus etiquetas personalizadas pueden usar el lenguaje que realmente hablan sus usuarios: “Publicar factura” en lugar de “Ejecutar”.
• Usted controla la experiencia de inicio. Al abrir en el modo Menús personalizados, evita que los usuarios deambulen por los menús predeterminados de 4D que exponen aspectos internos que nunca deberían tocar.
• Usted controla el alcance. Puede ocultar categorías enteras de funcionalidad para un grupo de usuarios determinado simplemente no incluyéndolas en la barra de menú de ese grupo.

La contrapartida es la responsabilidad. Una vez que toma el control de la barra de menú, usted es responsable de su consistencia, su integridad y su mantenimiento a medida que la aplicación crece.

Lo que puede y no puede cambiar

Comprender los límites desde el principio ahorra mucha frustración. Las reglas son sencillas:

Relacionado: Airtable — Una interfaz simple de hoja de cálculo ubicada sobre una base de datos relacional real, con automatizaciones, vistas e interfaces para compartir..

• Menú Archivo: modificable. Puede remodelarlo para que coincida con las operaciones relacionadas con archivos de su aplicación.
• Menú Editar: fijo. No puede modificarlo. Esto es deliberado: el menú Editar contiene el comportamiento estándar del portapapeles y de edición que los usuarios esperan que funcione de manera idéntica en todas las aplicaciones.
• Menú Ayuda: fijo. También no modificable, por la misma razón: el acceso a la ayuda debe ser predecible.
• Entre Editar y Ayuda: su territorio. Aquí es donde residen sus propios menús y elementos de menú.

La lógica de diseño detrás de fijar Editar y Ayuda es sólida y vale la pena internalizarla como principio: los comportamientos estándar deben seguir siendo estándar. Los usuarios desarrollan memoria muscular en torno a cortar, copiar, pegar, deshacer y el acceso a la ayuda. Si cada aplicación redefiniera estos, la plataforma se sentiría caótica. 4D protege esa base y le da libertad en todo lo demás.

Un modelo mental útil: piense en la barra de menú como si tuviera una zona reservada (Editar y Ayuda) y una zona de autoría (todo lo demás). Su trabajo es hacer que la zona de autoría se sienta tan inevitable y bien organizada como la zona reservada.

Diseño de su barra de menú: orientación práctica

Antes de comenzar a hacer clic en el editor de menús, decida qué es lo que su aplicación realmente necesita exponer. Una barra de menú es una jerarquía, y es fácil equivocarse con las jerarquías.

Si estás de compras: Zoho Creator — Un creador de aplicaciones de bajo código que se conecta a la suite más amplia de Zoho y ofrece precios por usuario en lugar de por aplicación..

Comience desde las tareas del usuario, no desde la estructura de su código

Un error común es reflejar la estructura interna de la base de datos: un menú por tabla, un elemento por método. Los usuarios no piensan en tablas y métodos. Piensan en tareas: “introducir un nuevo pedido”, “buscar un cliente”, “ejecutar el informe mensual”. Construya el menú en torno a esas tareas.

Agrupe por frecuencia y por riesgo

Coloque los comandos más utilizados donde sean más fáciles de alcanzar. Coloque los comandos destructivos o irreversibles (eliminar, purgar, archivar) lejos de los rutinarios, y considere requerir una confirmación. La ubicación de los menús es una forma de prevención de errores.

Mantenga la profundidad baja

Dos niveles de anidamiento (menú $\rightarrow$ elemento) son cómodos para la mayoría de los usuarios. Tres niveles (menú $\rightarrow$ submenú $\rightarrow$ elemento) son tolerables cuando el submenú es genuinamente una categoría. Más allá de eso, los usuarios pierden la noción de dónde están. Si descubre que necesita cuatro niveles, es probable que la función pertenezca a un formulario o a un cuadro de diálogo en su lugar.

Use separadores y un orden consistente

Los separadores agrupan visualmente los elementos relacionados. Dentro de un grupo, ordene los elementos por frecuencia esperada o por una secuencia lógica (por ejemplo, el orden en que se realiza un flujo de trabajo). Mantenga ese orden estable en todas las versiones: reordenar los menús entre versiones es una fuente sutil pero real de frustración para el usuario.

Escriba las etiquetas como verbos o sustantivos claros

“Imprimir factura” es más claro que “Factura imprimir”. “Informes” como título de menú está bien; “Informe” como elemento es ambiguo. Siga las convenciones que sus usuarios ya ven en el otro software que usan a diario.

Múltiples barras de menú: poder y peligro

4D le permite crear múltiples barras de menú diferentes y asignar cada una a una situación distinta. Esto es realmente poderoso. Los usos legítimos típicos incluyen:

Relacionado: Knack — Un creador de bases de datos sin código dirigido a portales, directorios y herramientas internas, con precios fijos en lugar de tarifas por usuario..

• Menús basados en roles. Un empleado de entrada de datos ve un menú simplificado; un supervisor ve los comandos de aprobación e informes.
• Menús basados en el contexto. Un menú que se muestra mientras un registro está abierto puede diferir del que se muestra en una pantalla de búsqueda.
• Menús basados en el modo. Un modo de “configuración” o “administración” puede exponer los comandos de configuración que la operación ordinaria oculta.

Vale la pena repetir y enfatizar la orientación original: recomiendo precaución aquí, ya que puede ser muy fácil confundir al usuario. Múltiples barras de menú multiplican el número de estados que un usuario debe rastrear. Si un comando se mueve o desaparece según el contexto, los usuarios pueden concluir que la función ha desaparecido en lugar de haber sido reubicada.

Una regla práctica:

Situación	Enfoque recomendado
Los diferentes roles de usuario necesitan diferentes capacidades	Barras de menú separadas: claras y justificadas
Mismo usuario, pantallas diferentes	Preferir una barra de menú estable; deshabilitar en lugar de eliminar elementos
Tareas administrativas de uso poco frecuente	Una barra de menú de administración dedicada, restringida por inicio de sesión
Diferencias contextuales menores	Mantener una barra de menú; cambiar el estado del elemento, no el diseño

El principio: cambie la disponibilidad, no la ubicación, siempre que pueda. Un elemento atenuado (en gris) aún le indica al usuario que la función existe. Un elemento desaparecido no le dice nada.

Nuestra elección: Claris FileMaker Pro — La plataforma de base de datos relacional de larga duración para equipos que necesitan aplicaciones personalizadas en escritorio, web y dispositivos móviles desde un solo archivo..

Comparación con programas establecidos

Para ayudar a ver qué utilizan otros programas para las barras de menú, puede ser útil hacer una comparación directa. Este es uno de los hábitos más prácticos que un desarrollador de 4D puede adoptar. La Figura 5 del material original muestra una comparación solo de las barras de menú: una comparativa lado a lado de cómo las diferentes aplicaciones organizan sus menús de nivel superior.

El valor de este ejercicio es que las convenciones de los menús se heredan en gran medida, no se inventan. Décadas de software de escritorio han convergido en un consenso aproximado sobre qué pertenece a cada lugar. Estudiar ese consenso —en procesadores de texto, hojas de cálculo, clientes de bases de datos y paquetes de contabilidad— le brinda una línea de base que puede seguir o de la cual puede apartarse deliberadamente.

Cuando compare las barras de menú, busque:

• Recuento de nivel superior. La mayoría de las aplicaciones maduras se decantan por un número pequeño de menús de nivel superior. Una barra con una docena de entradas se siente saturada.
• Convenciones de nomenclatura. Observe cuán consistentemente se usan “Archivo”, “Editar”, “Ver”, “Herramientas” y “Ayuda”, y dónde insertan las aplicaciones sus propios menús de dominio.
• Ubicación de menús específicos del dominio. ¿Dónde coloca una aplicación vertical sus comandos específicos de la industria? Por lo general, después de los menús estándar y antes de Ayuda; exactamente la zona que 4D deja abierta para usted.
• Densidad de elementos. ¿Cuántos elementos hay debajo de cada menú y cómo están separados?

Para obtener más información sobre las convenciones en sí, el artículo de Wikipedia sobre la barra de menú y el menú Archivo son referencias útiles para comprender de dónde provienen estos patrones y por qué persisten.

Un ejemplo práctico: Barra de menú para una pequeña aplicación de seguimiento de pedidos

Supongamos que está creando una aplicación modesta de seguimiento de pedidos para una pequeña empresa. Una barra de menú personalizada sensata podría verse así:

• Archivo — Nuevo pedido, Abrir pedido, Imprimir, Vista previa de impresión, Salir
• Editar — (fijo; se deja tal cual)
• Pedidos — Introducir pedido, Buscar pedido, Contabilizar pedido, Anular pedido
• Clientes — Nuevo cliente, Buscar cliente, Historial del cliente
• Informes — Resumen diario, Resumen mensual, Informe de pedidos pendientes
• Ayuda — (fijo; se deja tal cual)

Observe varias decisiones deliberadas. Los menús de dominio (Pedidos, Clientes, Informes) se encuentran entre Editar y Ayuda, exactamente donde 4D lo permite. Los comandos destructivos (Anular pedido) se agrupan al final de su menú, separados de la entrada rutinaria. El menú Informes es una lista plana en lugar de una jerarquía anidada, porque solo hay tres informes. Si la lista de informes creciera a quince, se justificaría un submenú por categoría.

Ahora considere la variación de roles. Un empleado de almacén podría tener la misma barra menos el menú Informes. Un gerente tiene la barra completa. Ese es un uso legítimo de múltiples barras de menú. Pero si la barra del empleado también reordenara los elementos de Pedidos de manera diferente a la del gerente, estaría creando confusión sin ningún beneficio.

Errores comunes a evitar

• Exponer los menús predeterminados de 4D por accidente. Si no configura la aplicación para que se abra en modo Menús personalizados, los usuarios pueden acceder a menús integrados que exponen la funcionalidad del modo de diseño. Bloquee esto desde el principio.
• Duplicar comandos en varios menús. Si “Imprimir” aparece tanto en Archivo como en Informes, los usuarios se preguntarán si son diferentes. Elija una ubicación única por comando.
• Usar elementos de menú como la única ruta hacia una función. Los menús sirven para la descubribilidad; las acciones utilizadas con frecuencia también deben ser accesibles desde formularios y barras de herramientas.
• Olvidar los atajos de teclado. Los elementos de menú sin atajos fuerzan el uso del mouse. Asigne atajos convencionales donde existan.
• No revisar nunca el diseño. Las barras de menú acumulan elementos obsoletos. Revise la suya en cada versión y elimine lo que ya no se utilice.

Cómo encaja esto en el camino de aprendizaje general de 4D

Los menús personalizados se sitúan junto a otras habilidades fundamentales de 4D cubiertas en esta serie: comprender definiciones y terminología, comparar los menús de 4D con los de FileMaker Pro, dar forma específicamente al menú Archivo y crear una pantalla de bienvenida personalizada. Juntos, estos forman la capa de presentación de una aplicación 4D: las partes que un usuario ve antes de tocar siquiera su modelo de datos.

El hilo conductor es el control. 4D le brinda un grado inusual de control sobre la interfaz externa de su aplicación. Los menús personalizados son una de las expresiones más claras de esa filosofía, y dominarlos pronto dará sus frutos a medida que su aplicación crezca en alcance y audiencia.

Preguntas frecuentes

¿Puedo modificar los menús Edición y Ayuda en 4D?

No. Los menús Edición y Ayuda son fijos y no se pueden modificar. Esto es intencional, porque estos menús contienen comportamientos estándar (operaciones del portapapeles, deshacer y acceso a la ayuda) que los usuarios esperan que se mantengan consistentes en todas las aplicaciones. Su personalización ocurre en el menú Archivo y en el espacio entre Edición y Ayuda.

¿Dónde aparecen mis menús personalizados y elementos de menú?

Sus propios menús y elementos de menú se insertan entre los menús Edición y Ayuda. Esta es la zona de autoría que 4D reserva para los desarrolladores. El menú Archivo también es modificable, mientras que Edición y Ayuda no lo son.

¿Debo crear varias barras de menú para mi aplicación?

Solo cuando la diferencia esté genuinamente justificada, más comúnmente para distintos roles de usuario o un modo administrativo. Múltiples barras de menú multiplican los estados que un usuario debe rastrear, y es muy fácil confundir a las personas. En caso de duda, mantenga una sola barra de menú y cambie la disponibilidad de los elementos en lugar del diseño.

¿Qué hace realmente “abrir en modo Menús personalizados”?

Le indica a 4D que inicie su aplicación utilizando su barra de menú personalizada en lugar de los menús predeterminados de 4D. Esto le brinda control total sobre la interfaz externa del programa y evita que los usuarios accedan a menús integrados que exponen aspectos internos que no deberían ver.

¿Cómo sé si el diseño de mi barra de menú es bueno?

Compárelo directamente con programas establecidos. Las convenciones de menú se heredan en gran medida en lugar de inventarse, por lo que estudiar cómo los procesadores de texto, las hojas de cálculo y los clientes de bases de datos organizan sus menús de nivel superior le brindará una base confiable. Observe la cantidad de menús de nivel superior, la nomenclatura, la ubicación de los menús específicos del dominio y la densidad de los elementos.

¿Es un problema si un elemento del menú desaparece en algunos contextos?

Puede serlo. Un elemento atenuado (en gris) todavía le indica al usuario que la función existe; un elemento que desaparece no le dice nada y puede llevarlo a pensar que la función fue eliminada. Prefiera cambiar la disponibilidad antes que cambiar la ubicación siempre que sea posible.