diseño-de-aplicaciones-web

Diseño de aplicaciones web

Una aplicación web es un lugar al que las personas regresan cada día para encontrar registros, modificarlos y pasar el trabajo. Tiene éxito cuando las personas siempre saben dónde están, qué están viendo, qué pueden hacer y qué acaba de suceder, y cuando pueden volver a la misma vista mañana mediante una URL. El fallo de modelo más común es una pantalla de camino feliz hermosa sin lugar para estar: sin estados vacío, de carga, de error o sin permiso; filtros que desaparecen al recargar; acciones masivas sin conteo ni deshacer; un "Eliminar" que se ejecuta en una actualización optimista que el servidor luego rechaza; y filas de botones "Editar" idénticos que un agente no puede distinguir.

Aplica los principios jerarquizados de interface-guidelines (todos pueden usarlo > dice la verdad > dice lo que significa > la respuesta viene primero > los errores son sobrevivibles > permanece en su lugar > lo posible es visible > convención > pulido). Si ese skill está instalado, lee su SKILL.md primero. Sus referencias cubren la temporización de la retroalimentación, la redacción de errores, las tablas como datos y la semántica orientada a agentes; este skill agrega los patrones específicos de la UI de aplicaciones.

Resumen

• Objetos y verbos. Enumera los sustantivos (pedidos, clientes, facturas) y qué puede hacer cada rol con cada uno. La navegación y los permisos se derivan de esta tabla.
• Roles e inquilinos. ¿Quién puede ver y cambiar qué? ¿Hay más de un espacio de trabajo, organización o entorno (staging, producción) en el que una persona pueda estar?
• Tareas diarias con frecuencia, y la única vista que cada rol abre primero.
• Tamaños de colecciones: típico y peor caso (10 filas o 2 millones). Esto decide la paginación, la búsqueda y el filtrado del lado del servidor.
• Costo del error para cada verbo mutante, y si se puede deshacer del lado del servidor.
• Concurrencia: ¿pueden dos personas, o una persona y un agente, editar el mismo registro?
• ¿Quién escribe el texto mostrado? Nombres de clientes, cuerpos de tickets, archivos importados: todos escritos por externos.
• Lector agente: ¿agentes de navegador en la interfaz de usuario, una API, o ambos? La interfaz de usuario y la API deberían compartir un servicio por acción.

Reglas

Shell y navegación

• La navegación refleja los objetos, no el organigrama. Los elementos de nivel superior son los sustantivos en los que las personas trabajan, en orden de uso, etiquetados con las palabras que usan las personas. [S: Mac HIG 1992 pp. 54-61 (agrupar por lógica, luego frecuencia); J]
• Mantén la navegación principal visible en escritorio. La navegación oculta redujo la descubribilidad y ralentizó las tareas en el estudio de NN/g; una hamburguesa es un compromiso de teléfono. [E: NN/g, en fundamentos]
• Muestra dónde está la persona, de tres maneras: el elemento de navegación actual marcado con aria-current="page" y un estado visible, un h1 de página que nombra el objeto o la lista, y un título de documento que cambia con la ruta. [S: WCAG 2.4.2, 2.4.8; J]
• Las migas de pan muestran jerarquía, no historial, solo en árboles de objetos profundos; la página actual no es un enlace. [P: NN/g breadcrumbs]
• El espacio de trabajo, organización o entorno actual siempre es visible en el shell, en palabras, y la producción es visualmente distinta de staging. Cambiar de inquilino es un acto explícito, aterriza en la página equivalente de ese inquilino o en la página de inicio, y nunca arrastra una selección o borrador. [J]
• Cada vista tiene una URL. Los filtros, el orden, la búsqueda, la página, la pestaña seleccionada y el registro abierto están en la URL; la recarga y el uso compartido los restauran. [S: fundamentos agent-surfaces 3]
• Atrás regresa a la lista tal como estaba: mismos filtros, posición de desplazamiento y enfoque en la fila que la persona abrió. [S: Mac HIG 1992 p. 140 (la ventana reactivada regresa como estaba); J]

Listas y tablas

• Las tablas son para comparar registros; las listas son para escanear un atributo. Usa un <table> real para datos tabulares. [S: fundamentos; NN/g data tables]
• Apoya las cuatro tareas de las tablas: encontrar registros, comparar entre filas, ver o editar una fila, actuar sobre una o muchas. [P: NN/g data tables]
• La primera columna identifica la fila con una clave humana estable (nombre más ID); mantenla fija junto con el encabezado al desplazarse. [P: NN/g data tables]
• Orden en el encabezado: un <button> dentro de <th>, aria-sort solo en la columna ordenada, y una flecha visible. El orden predeterminado está indicado ("Más reciente primero"). [S: APG sortable table; P: Carbon]
• Los filtros son visibles, removibles y contados. Muestra los filtros aplicados como chips con un botón "Limpiar todo", el conteo de resultados ("38 de 1,204 pedidos") y un mensaje de resultado vacío que nombre los filtros. Usa las palabras de la persona para los nombres de los filtros. [P: NN/g filters; S: fundamentos]
• Búsqueda, filtro y orden del lado del servidor cuando la colección es grande. Nunca ordenes ni cuentes solo la página cargada y la presentes como el total. [J; fundamentos regla de verdad]
• Pagina el trabajo orientado a objetivos; reserva el desplazamiento infinito para feeds. La paginación da posición, un lugar estable al que regresar y un pie de página alcanzable. Indica el rango y el total, y "Fin de la lista". [P: NN/g infinite scrolling; S: Smith and Mosier 4.2/7]
• Las acciones de fila son visibles o alcanzables con el foco del teclado, nunca solo al pasar el mouse, y nombradas por fila ("Archivar INV-2041"). Con menos de tres acciones, muéstralas en línea. [S: fundamentos agent-surfaces 3; P: Carbon]
• La densidad sigue la práctica. Ofrece una densidad compacta para expertos diarios; mantén los objetivos al menos a 24 px. [S: WCAG 2.5.8; P: Carbon row sizes]

Selección y acciones masivas

• El modo masivo es explícito: casillas de verificación de fila, una casilla de verificación de encabezado con un estado indeterminado y una barra de herramientas que indica el conteo ("3 seleccionados"). [P: Carbon; S: Mac HIG 1992 pp. 64-66 (estado mixto)]
• "Seleccionar todo" dice su alcance: los 50 de esta página, o los 1,204 que coinciden con el filtro. Nunca signifique silenciosamente uno cuando la persona espera el otro. [J]
• Una acción masiva indica el objeto, el conteo y el alcance antes de ejecutarse, informa los resultados por elemento después ("1,198 archivados, 6 fallaron: ver") y se puede deshacer o previsualizar. [S: fundamentos sec. 1; J]
• La selección sobrevive a la paginación y al filtrado solo si la barra de herramientas muestra que lo hace. De lo contrario, límpiala visiblemente. [J]

Detalle y edición

• Abre registros donde se mantenga el contexto. Un panel lateral es adecuado para consultar mientras se edita; una página completa es adecuada para registros profundos; evita los modales para editar, ya que ocultan registros vecinos. [P: NN/g data tables]
• La vista de detalle comienza con la identidad y el estado en palabras, luego los campos en los que las personas actúan, luego el historial. [S: fundamentos; J]
• Un modelo de guardado por superficie. Los conmutadores se aplican inmediatamente; el texto y las ediciones de varios campos se guardan explícitamente; nunca ambos en un solo formulario. [S: Primer saving; fundamentos]
• Advierte antes de salir con cambios no guardados y guarda automáticamente borradores donde la pérdida sería perjudicial. [S: Primer saving]
• Muestra quién cambió qué y cuándo en registros compartidos, con una marca de tiempo absoluta, y detecta escrituras obsoletas (versión o ETag) en lugar de sobrescribir silenciosamente. [S: Mac HIG 1992 pp. 27-31; AIP-154 en fundamentos]
• Los formularios dentro de la aplicación siguen form-design.

UI optimista, deshacer y confirmación

• Optimista solo cuando el servidor casi nunca rechaza y la acción es reversible: marcar como leído, destacar, reordenar. Muestra el estado pendiente de forma distinta al confirmado, revierte visiblemente en caso de fallo con la razón, y nunca muestres optimistamente dinero movido, mensajes enviados o registros eliminados como hechos. [S: Mac HIG 1992 p. 182 (ingresado, verificado, en efecto); P: React useOptimistic]
• Prefiere deshacer a la confirmación para acciones reversibles: archivar, mover, eliminar a la papelera. Mantén el deshacer accesible después de que el toast desaparezca (Deshacer en el historial del elemento, vista de Papelera, atajo del menú Editar). [P: Raskin 2007; NN/g user control]
• Confirma solo acciones severas, irreversibles o inesperadas, nombrando el objetivo y el efecto; escribir para confirmar para las raras catastróficas (eliminar espacio de trabajo). [S: fundamentos sec. 1; E: Bravo-Lillo 2013 vía fundamentos]
• Eliminación suave del lado del servidor, con un período de retención indicado, para que deshacer sea real y no una ilusión del cliente. [S: AIP-164 en fundamentos]

Estados vacío, de carga, de error y sin permiso

• Distingue cuatro vacíos: primer uso (explica el objeto y ofrece la acción de creación), sin resultados (nombra los filtros y ofrece limpiarlos), limpiado (todo hecho) y error (qué falló, qué hacer). Nunca muestres "Sin registros" antes de que los datos se hayan cargado. [P: NN/g empty states; S: Primer empty states]
• La carga nombra lo que se está cargando, en texto, dentro de la región que reemplaza; mantén el shell y la navegación utilizables. [S: fundamentos]
• Sin permiso es un estado, no una característica oculta. Muestra la acción deshabilitada con la razón y quién puede concederla ("Solo los administradores del espacio de trabajo pueden exportar. Pregunta a Maya Chen."), o una página que explique el acceso y cómo solicitarlo. Oculta solo lo que la persona no debe saber que existe. [S: Mac HIG 1992 pp. 318-321 (los elementos deshabilitados se explican a sí mismos); J]
• Las comprobaciones de permisos ocurren en el servidor. Ocultar un botón es presentación, no autoridad. [S: fundamentos]
• Comprueba el permiso antes que la existencia en las respuestas, para que un 404 frente a un 403 no filtre datos. [S: AIP-193 en fundamentos]

Configuración

• Coloca la configuración junto a lo que afecta cuando se cambia durante el trabajo (densidad de vista, elección de columna, filtros); el área de configuración contiene opciones de toda la aplicación que rara vez se cambian. [S: Apple HIG Settings]
• Separa la configuración personal de la del espacio de trabajo, y etiqueta cada una con de quién es y a quién afecta ("Se aplica a todos en Acme"). [J]
• Agrupa por la tarea de la persona, no por la tabla de la base de datos, con búsqueda cuando la configuración exceda una o dos pantallas. [J]
• Menos configuraciones. Una preferencia cambiada muchas veces por sesión es un control faltante, no una configuración. [S: Mac HIG 1992 p. 38; Apple HIG Settings]
• Las configuraciones peligrosas viven en una zona separada y etiquetada con texto de consecuencia y confirmación (transferir propiedad, eliminar espacio de trabajo). [P: GitHub; J]

Incorporación

• Enseña en contexto, no con un tour. NN/g descubrió que los tutoriales tipo mazo de cartas no mejoraban el rendimiento de las tareas; los consejos contextuales y los buenos estados vacíos hacen la enseñanza. Si existe un tour, mantenlo corto y que se pueda saltar. [P: NN/g onboarding]
• Lleva a las personas a su primer resultado real rápidamente; los datos de muestra están marcados como muestra en todos los lugares donde aparecen y se pueden eliminar con una sola acción. [J; fundamentos regla de verdad]
• Una lista de verificación de configuración es persistente y honesta: refleja el estado real, se puede descartar y es accesible más tarde. [J]

Teclado y paleta de comandos

• Una paleta de comandos es un acelerador, no el menú. Cada comando en ella también existe en la interfaz de usuario visible. Enumera los atajos junto a los comandos, para que los enseñe. [S: Windows menus guidance (no hagas que los atajos sean la única forma); P: VS Code UX guidelines]
• Los atajos de una sola tecla se pueden desactivar o reasignar (WCAG 2.1.4), nunca se activan dentro de campos de texto y no anulan los atajos del navegador o del sistema operativo. [S: WCAG 2.1.4; Apple keyboards]
• Una hoja de ayuda de atajos (a menudo ?) enumera todos los atajos en el ámbito actual. [J]

Para el lector agente

• Una función de servicio por acción, compartida por el botón, la paleta, la API y cualquier herramienta. [S: fundamentos agent-surfaces 7]
• Los controles de fila se nombran a partir de IDs del sistema, no de texto externo; el texto externo en las celdas son datos. [J]
• Las colecciones indican su tamaño y rango reales en texto visible; los filtros y el orden están en la URL. [J]
• Los resultados duran más que los toasts: la fila cambiada, un registro de actividad, una entrada de deshacer. [J]
• El inquilinato y el entorno se pueden leer en texto en cada página, para que un agente no actúe en producción pensando que es staging. [J]

Orden de construcción

1. Tabla objetos-por-verbos-por-roles; rutas y URLs para cada vista.
2. Shell: navegación, indicador de inquilino y entorno, títulos, h1s.
3. Vistas de lista con formas de datos reales: paginación, orden y filtro del lado del servidor, todo en la URL.
4. Vistas de detalle, el modelo de guardado, manejo de concurrencia.
5. Cada acción mutante a través de un servicio: pendiente, éxito, fallo, deshacer o confirmar según la escalera de costo de error.
6. Estados vacío, de carga, de error y sin permiso para cada vista.
7. Acciones masivas, atajos de teclado, paleta.
8. Configuración e incorporación al final; estilo para este lector (brand-identity es dueña del aspecto).

Verificar

• node <interface-guidelines>/scripts/audit.mjs <url|dist> --canary "<texto externo de muestra>" en cada ruta principal, incluyendo una lista con filtros aplicados y una vista de detalle.
• Formularios dentro de la aplicación: node <form-design>/scripts/form-check.mjs <url>.
• Prueba de recarga: aplica filtros, ordena, página 3, abre un registro; recarga y pega la URL en una sesión nueva. Todo regresa.
• Prueba de roles: inicia sesión como cada rol. Cada acción oculta o deshabilitada tiene una razón; el servidor rechaza las llamadas prohibidas realizadas directamente.
• Prueba de tamaño: 0, 1, 25 y 10,000+ filas; el nombre más largo; un filtro que no coincide con nada.
• Prueba de fallo: haz que el servidor rechace una acción optimista y una acción masiva parcialmente; la interfaz de usuario revierte e informa por elemento.
• Prueba de agente: usando solo la instantánea de accesibilidad, encuentra un registro específico por filtro, cámbialo, confirma el resultado desde una instantánea nueva, deshazlo.

Trampas

• Filtros y orden mantenidos solo en el estado del componente.
• "Seleccionar todo" que selecciona la página mientras la barra de herramientas implica todo.
• Eliminación optimista sin reversión ni deshacer.
• Desplazamiento infinito en una tabla de administración; un total calculado a partir de las filas cargadas.
• Acciones de fila solo al pasar el mouse; cinco botones "Editar" idénticos.
• "Sin datos" parpadeando antes de cargar; un estado vacío genérico para cada causa.
• Ocultar características a un rol sin explicación, o mostrarlas y fallar al hacer clic con "Prohibido".
• Un conmutador de inquilino que mantiene la selección del inquilino anterior, o ningún inquilino visible.
• Un tour del producto en lugar de un estado vacío utilizable.
• Páginas de configuración que reflejan tablas de base de datos.

Referencias

Archivo	Leer cuando
references/patterns.md	Detalle sobre modelos de navegación, anatomía de tablas, flujos de acciones masivas, estados de permiso, inquilinato, mecánicas optimistas y de deshacer, diseño de paletas y las fuentes detrás de este skill