estándar-de-estructura-ui

Estándar de Estructura de UI

Las interfaces se vuelven difíciles de usar por la estructura, no por el tamaño. Una aplicación con 300 ajustes puede ser fácil de navegar y una con 30 puede ser un laberinto. Las causas son siempre las mismas pocas: el mismo control vive en varios lugares, los menús reflejan el código o el equipo, las acciones se mezclan con las preferencias, los iconos no están etiquetados, el alcance es invisible y nunca se elimina nada.

La solución es hacer lo que las principales plataformas ya hacen, de la misma manera en cada aplicación, para que las personas puedan usar lo que ya saben:

• Un diseño familiar. Una lista de categorías con búsqueda a la izquierda, la página abierta a la derecha, filas con la etiqueta a la izquierda y el control a la derecha.
• Un conjunto de nombres de categorías. Cuenta, Notificaciones, Privacidad y seguridad, Accesibilidad, Apariencia, Idioma y región, Datos y almacenamiento, luego los propios temas del producto. Siete preguntas archivan cualquier ajuste exactamente en uno.
• Menos controles. El mejor ajuste es el que nunca se envía porque un valor predeterminado mejor lo hizo innecesario.
• Un hogar para cada control que permanece. Cada ajuste, destino y comando es un registro en un registro, cada registro tiene exactamente un hogar, y la interfaz se dibuja a partir de los registros. Cuando nadie coloca un control a mano, la estructura no puede derivar.

Elige el trabajo

Encuentra la solicitud en esta tabla y lee solo esa sección, más los archivos que nombra.

La solicitud	Sección	También lee
"Añadir un ajuste / elemento de menú / botón"	Añadiendo un control	Nada más, normalmente
"Esta UI es un desastre", "revisa esto", "los usuarios no pueden encontrar cosas"	Auditando una interfaz existente	references/audit.md, references/rules.md
"Construir / diseñar / rediseñar una pantalla de configuración, barra lateral o barra de herramientas", o una lista de características para convertir en una	Construyendo una nueva superficie	references/categories.md, references/visual-design.md, references/record-schema.md
"Organizar nuestros ajustes", "qué categorías deberíamos tener"	Las categorías estándar	references/categories.md
"Configurar esto para nuestro proyecto"	Adoptando el registro	references/record-schema.md

Sea cual sea el trabajo, respeta el proyecto en el que estás. Si el código base ya tiene un registro de ajustes, una biblioteca de componentes o sus propias reglas sobre el marcado, extiéndelos; no introduzcas un sistema paralelo. El estándar describe la estructura, no la tecnología.

La carpeta evals/ contiene casos de prueba para esta habilidad. No es material de referencia; no la leas mientras realizas una tarea.

Añadiendo un control

Haz estas cinco preguntas en orden y detente en el primer sí. Dile al usuario esa decisión y la razón; no los guíes a través de preguntas que ya no aplican.

1. ¿Un mejor valor predeterminado lo haría innecesario? Si la necesidad puede ser satisfecha para todos cambiando el valor predeterminado, detectando la situación, o simplemente eliminando el comportamiento que a la gente no le gusta (una confirmación que nadie necesita, un aviso para algo que se autoguarda), haz eso. No hay ajuste.
2. ¿El sistema o un administrador ya lo decide? El tema, el tamaño del texto, el permiso de notificación y similares pertenecen a la capa inferior. Síguelo. Si el producto tiene una razón real para ofrecer su propia elección, la elección incluye "Usar ajuste del sistema" y ese es el valor predeterminado; nunca es un interruptor de encendido/apagado simple.
3. ¿Se hace una vez, no es una elección duradera? Entonces es una acción: un botón, mantenido aparte de los interruptores, en contexto o en un grupo etiquetado al pie de su página.
4. ¿Se cambia semanalmente o más a menudo? Entonces el control vive en contexto, junto a la característica que cambia, con un enlace a su página de inicio. La página de inicio aún lo lista.
5. ¿Menos de aproximadamente 1 de cada 20 personas lo cambiaría alguna vez? Entonces su nivel es avanzado. Una página con tres o más elementos avanzados los muestra en un pliegue Avanzado; con menos, es una fila ordinaria colocada al final.

De lo contrario, es una fila estándar en su página de tema.

Si la respuesta a la pregunta 1 o 2 fue sí, dilo claramente y propón ese cambio en lugar del ajuste. Cada ajuste tiene un costo en pruebas, en soporte y en la capacidad de todos los demás para encontrar cosas, por lo que el usuario debe escuchar primero la opción más barata. Puede que aún quieran el ajuste; esa es su decisión. Ofrécelo como alternativa en unas pocas líneas.

Eligiendo el hogar. Usa las siete preguntas bajo Las categorías estándar, mapeadas en las páginas que existen. Si el control no encaja en ninguna, eso es evidencia de un tema faltante: dilo y propón uno. No crees una página llamada General, Misc, Otro o Avanzado. Cuando la interfaz existente ya tiene tal página, coloca el nuevo control en la página específica mejor nombrada y menciona el cajón de sastre en una línea como algo que vale la pena arreglar más tarde. Una solicitud para añadir un control no es una solicitud para una auditoría.

Controles que hacen una pregunta. Una confirmación con "No preguntar de nuevo" es un control en contexto para un ajuste (pregunta 4): la casilla de verificación y la fila de ajustes son el mismo registro, por lo que la elección se puede encontrar y revertir más tarde. Nunca ofrezcas "No preguntar de nuevo" sin una fila en algún lugar que lo deshaga.

Cuánto mostrar al usuario. Si el proyecto tiene un registro, escribe el registro completo (campos a continuación) y verifica que la página en la que aterriza todavía esté dentro de los límites. Si no lo tiene, o el usuario solo pidió consejo, responde en palabras claras: qué añadir, dónde, cómo se llama, cuál es su valor predeterminado y por qué, y si se aplica a este dispositivo o a toda la cuenta. Campos como id, tier, owner y reviewed son contabilidad; déjalos fuera de una respuesta conversacional. Cuando no sepas algo que el registro necesita (si los ajustes se sincronizan entre dispositivos, qué páginas existen), expresa tu suposición en una cláusula y continúa.

Auditando una interfaz existente

El objetivo es una lista de hallazgos concretos y solucionables vinculados a números de regla, y una estructura propuesta. Lee references/rules.md primero para que los hallazgos puedan citar reglas, y usa la plantilla de informe en references/audit.md.

Una auditoría puede cubrir ajustes, navegación, barras de herramientas, o las tres. Audita lo que el usuario preguntó y lo que puedas ver. Si la pantalla no tiene ajustes, omite las partes de ajustes de la plantilla; no las estires para que encajen.

1. Inventario. Lista cada lugar donde una persona puede cambiar o activar algo: pantallas de ajustes, menús de cuenta, menús contextuales, diálogos por elemento, listas de navegación, barras de herramientas, tiras de iconos, banderas de línea de comandos, archivos de configuración. En un código base grande, delega el barrido o busca los patrones (etiquetas, interruptores, constructores de menús); no leas archivos enormes completos. Para cada control, registra su etiqueta tal como se muestra, su tipo, dónde vive y cómo se accede a él. Cuando un control no tiene ninguna etiqueta, dilo, descríbelo por posición y marca cualquier suposición sobre lo que hace como una suposición.
2. Mide. Cuenta lo que las reglas limitan: lugares para cambiar cosas, entradas de navegación de nivel superior, ajustes por página, profundidad, botones por barra de herramientas, controles solo de icono, controles sin nombre accesible, cuadros de búsqueda y cuántos conjuntos de comandos distintos muestran objetos del mismo tipo.
3. Encuentra los síntomas.
   • el mismo ajuste o comando accesible en más de un lugar, o dos controles que se apilan o pelean
   • un tema disperso en varias páginas
   • una cosa con varios nombres; un enlace cuya etiqueta difiere del título de su objetivo; nombres casi duplicados uno al lado del otro
   • páginas llamadas General, Misc, Otro, Avanzado
   • acciones (exportar, eliminar, cerrar sesión) sentadas entre preferencias o entre destinos
   • alcance explicado solo en texto de ayuda, o no explicado en absoluto
   • vocabulario del constructor en las etiquetas
   • grupos con un elemento y listas más largas que su límite
   • iconos sin palabras visibles; un icono usado para dos significados
   • barras de herramientas con más de cinco botones; conjuntos de comandos que difieren entre objetos del mismo tipo
   • sin marcador para la ubicación actual
   • más de un cuadro de búsqueda en una pantalla
   • mostrar, ocultar o reordenar controles ofrecidos como la cura para el desorden
4. Propón. Para ajustes: las categorías estándar que aplican más hasta dos temas del producto, como máximo nueve en total, con cada control mapeado exactamente a uno. Para navegación: como máximo nueve entradas de nivel superior, el resto bajo grupos etiquetados. Para barras de herramientas: un conjunto de comandos por tipo de objeto, cinco en la barra, el resto bajo Más. Lista lo que sale de la superficie por completo y a dónde va. Di que las agrupaciones son propuestas para confirmar con una clasificación de tarjetas y una prueba de árbol (cinco personas encuentran los grandes problemas; apunta al 80% de éxito en la tarea), porque las agrupaciones deben coincidir con cómo piensan los usuarios y eso no se puede leer del código.
5. Ordena los cambios para que aquellos que nadie tiene que volver a aprender vengan primero: palabras en los iconos y un marcador de ubicación actual, luego colapsar duplicados y unificar nombres, luego barras de herramientas consistentes, luego reagrupar. Mover cosas llega tarde porque le cuesta algo a los usuarios existentes. Si adoptar un registro está justificado, va al final y se ofrece, no se impone; el usuario preguntó qué cambiar en la pantalla.

Ordena los hallazgos por cuánto dañan a un nuevo usuario. Da crédito a lo que ya funciona: un registro existente, búsqueda, restablecimiento o mecanismo de dirección es la base sobre la que se construye la solución, y decirlo evita una reescritura que nadie necesita.

Construyendo una nueva superficie

1. Ejecuta las cinco preguntas en cada elemento primero. Una lista de deseos de producto siempre contiene cosas que deberían ser un mejor valor predeterminado, pertenecen al sistema o son acciones en lugar de preferencias. Deja los elementos cortados fuera del registro y listalos en tu resumen con la razón, para que el usuario pueda anularte.
2. Escribe los registros antes de cualquier marcado, siguiendo references/record-schema.md. Si existe un registro, añádelo.
3. Archiva cada registro con las siete preguntas (próxima sección). Deja fuera las categorías que estarían vacías. Una categoría con uno o dos ajustes está bien cuando la gente la busca por nombre (Notificaciones); de lo contrario, intégrala en su vecina. El estado sobre un tema permanece en la página de ese tema; solo la información de toda la aplicación va debajo de Acerca de.
4. Verifica los límites (abajo), a mano o con el verificador.
5. Dibuja el diseño estándar a partir de los registros, siguiendo references/visual-design.md para la disposición, tamaños, controles y estados, y references/patterns.md para el comportamiento. En resumen: lista de categorías junto a la página en pantallas anchas y delante de ella en las estrechas; una columna limitada a cerca de 1.100 px; etiqueta a la izquierda, control o valor actual a la derecha; filas relacionadas en grupos contenidos; interruptores para encendido y apagado, botones de opción para dos a cinco opciones, sin botón Guardar; objetivos de al menos 24 px y de 44 a 48 px para táctil; contraste de texto 4.5:1; nada mostrado solo por color. Cada fila muestra su alcance y, cuando difiere del valor predeterminado, un marcador de cambio con Restablecer. La búsqueda se sienta en la parte superior. Cada registro tiene una dirección estable. Las acciones se sientan aparte de las preferencias, las destructivas aparte de nuevo.
6. Di lo que asumiste: los valores predeterminados, alcances y propietarios que tuviste que adivinar son para que el usuario los confirme. Usa unassigned para un propietario desconocido; no inventes nombres de equipo.

Las categorías estándar

Haz estas en orden y detente en el primer sí. El orden es el desempate.

#	La pregunta	Categoría
1	¿Se trata de quién eres, cómo entras o qué pagas?	Cuenta
2	¿Decide cuándo o cómo el producto te interrumpe?	Notificaciones
3	¿Controla lo que otras personas, otras aplicaciones o el servicio pueden ver, conservar o hacer?	Privacidad y seguridad
4	¿Existe para que alguien con una necesidad particular pueda ver, escuchar o operar el producto?	Accesibilidad
5	¿Cambia solo cómo se ven las cosas?	Apariencia
6	¿Se trata de idioma, hora o formatos?	Idioma y región
7	¿Se trata de dónde se guardan los datos, cuánto o a través de qué red?	Datos y almacenamiento
	De lo contrario: ¿qué característica cambia?	Uno de hasta dos temas del producto (Mensajes, Editor, Reproducción)

Acerca de (versión, ayuda, legal) es un enlace al pie y no se cuenta. Los ajustes que un administrador hace para todos son una superficie separada. Una aplicación pequeña con menos de aproximadamente 15 ajustes usa una página con estos nombres como encabezados de grupo.

Así que un tono de llamada para llamadas es Notificaciones, no Llamadas; "reducir movimiento" es Accesibilidad, no Apariencia. Cuando un ajuste podría estar en dos, archívalo por el primer sí y pon las palabras de la otra categoría en sus palabras de búsqueda. references/categories.md cubre productos grandes, suites, nomenclatura y el razonamiento.

Estos nombres son los que los sistemas operativos ya usan. Empieza desde ellos y cámbialos solo cuando los propios usuarios del producto, en una clasificación de tarjetas, agrupen las cosas de manera diferente.

El registro

Campo	La pregunta que responde	Valores permitidos
id	¿Cuál es su nombre permanente?	Una ruta con puntos como chat.notifications.sound. Nunca reutilizado ni renombrado.
kind	¿Qué tipo de cosa es?	preference, action, status, list, destination, command
subject	¿De qué único sustantivo se trata?	Exactamente un tema. Este es su hogar.
scope	¿A quién o qué cambia?	item, device, account, organization
tier	¿Cuántas personas lo necesitan?	everyday, standard, advanced
label, summary	¿Cómo se llama y qué hace?	Una etiqueta simple; una oración sobre el resultado
search	¿Qué escribiría una persona para encontrarlo?	Sinónimos, el nombre antiguo, el término de jerga
value	¿Qué tipo de valor contiene?	Un tipo, con opciones o un rango
default, default_reason	¿Qué sucede si nadie lo toca?	El valor que la mayoría de las personas elegiría, y por qué
risk	¿Qué se rompe si se cambia?	safe, care (recuperable), destructive (perdido para siempre)
owner, reviewed	¿Quién decide cuándo desaparece?	Un propietario y la fecha en que se justificó por última vez

Los destinos y comandos usan un conjunto más corto de campos. El esquema completo está en references/record-schema.md, y assets/registry.example.json es un ejemplo funcional.

Los límites

| Límite | Valor | De dónde viene |