Menús Contextuales y Selección

El menú contextual es una capa de eficiencia para usuarios avanzados, no el canal de descubrimiento principal. Las acciones críticas deben existir también en la UI visible; el right-click las duplica como atajo. Si una acción solo existe en el menú contextual, el 60–70% de usuarios móviles y touch-first nunca la encontrará. Más de 9 ítems sin separadores paraliza la decisión; agrupamiento semántico en bloques (lectura / edición / destrucción) reduce el tiempo de escaneo hasta un 40%.

La toolbar flotante de selección de texto debe aparecer 8–12px por encima del extremo superior de la selección, centrada horizontalmente sobre ella. Posicionarla debajo tapa el texto seleccionado y obliga al usuario a mover el cursor para leer lo que quiere formatear. En escritura colaborativa, toolbars que tapan la selección aumentan los errores de re-selección en un 34%. Si no hay espacio arriba, aplicar flip y mostrarla debajo con una flecha invertida.

Al seleccionar uno o más ítems de una lista o grid, debe aparecer una toolbar de acciones en masa que reemplaza o superpone el header. La selección sin feedback visual de "qué puedo hacer ahora" genera abandono. Mostrar el conteo exacto ("3 seleccionados") y acciones contextuales al tipo de ítem son los dos indicadores de calidad más importantes de esta interacción. Las mismas acciones genéricas para cualquier mezcla de tipos es el anti-patrón más frecuente.

El long-press (300–500ms) es el canal contextual en touch; debe ofrecer las mismas acciones del right-click desktop pero simplificadas al contexto táctil. Disparar haptic feedback al inicio del menú confirma al usuario que el gesto fue reconocido antes de que el menú aparezca visualmente. Sin haptic, un 23% de usuarios repite el gesto creyendo que no funcionó. El menú debe ser bottom sheet nativo con preview del contenido, nunca un menú flotante de desktop adaptado.

Mostrar el keyboard shortcut junto a cada acción en el menú contextual reduce el tiempo de aprendizaje de atajos un 40% comparado con documentación separada. El menú contextual es el lugar de descubrimiento natural: el usuario ya está haciendo la acción manualmente, y ver el shortcut en contexto crea el vínculo cognitivo. El acelerador (la tecla que activa la acción con el menú abierto) se marca subrayando esa letra en el label. En mobile, omitir la columna de shortcuts completamente.

Los submenús añaden capacidad de organización pero cada nivel adicional aumenta la carga cognitiva exponencialmente. Más allá de 2 niveles el usuario pierde el contexto de dónde está en la jerarquía. El delay de 300ms antes de abrir el submenú previene aperturas accidentales al atravesar el menú con el cursor (diagonal movement problem); sin delay, el 15% de los usuarios abre submenús no deseados. La técnica "safe triangle" mantiene el submenú abierto mientras el cursor se mueve en diagonal hacia él.

Las acciones que destruyen datos deben estar visualmente separadas del resto del menú, al final, en rojo, para que el usuario no las active por escaneo rápido o fat-finger. El color rojo reduce los clics accidentales en acciones destructivas un 27%. La confirmación inline (en el mismo menú, no modal) es más efectiva para acciones reversibles; para irreversibles, un popover anclado al ítem con botón rojo y botón neutro es el patrón correcto. Nunca usar modal completo para confirmaciones de menú contextual.

Un menú contextual sin accesibilidad excluye a usuarios de teclado, lectores de pantalla y personas con discapacidades motoras. El patrón WAI-ARIA Menú es el contrato técnico: role="menú" con role="menuitem" y navegación por flechas. Sin esto, el menú es invisible para VoiceOver y NVDA. Escape debe cerrar el menú y devolver el focus al elemento trigger; Enter y Space activan el ítem enfocado; las flechas navegan con wrap circular desde el último al primero.