LIBRO SEMÁNTICA — TEXTO COMPLETO


Fuente: introducción aportada en conversación + capítulos DOCX 1–36.
Nota: en este TXT no se incrustan imágenes/diagramas; se conservan las referencias textuales a figuras y tablas cuando aparecen en el documento.


# Introducción

## La pregunta que aparece al programar interfaces

Este libro nace de una práctica, no de una pretensión.

Durante años, trabajando en front-end, me encontré una y otra vez con preguntas que las herramientas habituales no terminaban de responder del todo.

No eran preguntas espectaculares. Eran preguntas pequeñas, de esas que aparecen mientras se construye una interfaz real:

¿Por qué un botón debe responder antes de confirmar?
¿Por qué guardar no se siente igual que completar?
¿Por qué una espera necesita parecer viva?
¿Por qué una advertencia corregible no debería sentirse como una amenaza?
¿Por qué una pérdida ya consumada no debería expresarse igual que un peligro?
¿Por qué un modal a veces cambia el marco y otras veces solo muestra contenido?
¿Por qué el color ha cargado con tanta semántica?
¿Por qué motion, sonido, forma, presencia, háptica y accesibilidad se tratan como capas separadas si el usuario las vive juntas?

No soy psicólogo.
No soy neurocientífico.
No pretendo dar lecciones en esos campos.

Soy un programador que, al construir interfaces, empezó a sospechar que faltaba un lenguaje para describir algo que ocurría todos los días delante de nosotros.

Las guías de diseño explicaban componentes.
Los frameworks ofrecían patrones.
Los sistemas de diseño ordenaban tokens.
La accesibilidad establecía criterios necesarios.
La psicología ofrecía fundamentos sobre percepción, atención, affordances, evaluación y acción.

Pero entre todo eso seguía apareciendo una zona difícil de nombrar:

qué ocurre perceptivamente cuando la interfaz responde,
espera,
advierte,
confirma,
pierde,
aparece,
cambia de marco
o sostiene un proceso.

Este libro intenta trabajar en esa zona.

No viene a sustituir la teoría de interfaces existente.
No viene a redefinir desde cero el diseño de interacción.
No viene a invadir campos que ya tienen desarrollos sólidos.

Viene a completar una pregunta concreta desde otra perspectiva:

> ¿podemos pensar la interfaz como una gramática de eventos perceptivos?

La web será el campo principal de ejemplos, porque ahí trabajo y porque ahí la fragmentación se ve con mucha claridad: DOM, CSS, JavaScript, estados, eventos, tokens, motion, accesibilidad, sonido y componentes aparecen como capas separadas.

Pero el usuario no vive capas.

Vive eventos.

Percibe que algo respondió.
Que algo sigue ocurriendo.
Que algo se guardó.
Que algo reclama atención.
Que algo puede perderse.
Que algo ya se perdió.
Que algo apareció.
Que algo cambió de marco.
Que algo quedó completado.

Este libro propone una forma de nombrar esos eventos.

No como verdad final.
No como dogma.
No como framework cerrado.

Sino como una herramienta para pensar mejor una parte de la interfaz que ya estaba funcionando, aunque muchas veces no tuviera nombre.

La hipótesis es sencilla:

> La interfaz no solo tiene componentes, estados y efectos.
> Tiene eventos perceptivos.
> Y esos eventos necesitan una gramática.


================================================================================
CAPÍTULO 1 — capitulo1_con_diagramas.docx
================================================================================
CAPÍTULO 1

Qué entendemos por interfaz

Hacia una definición operativa de la interfaz

La palabra interfaz parece clara hasta que uno intenta definirla con precisión.

En el trabajo cotidiano solemos usarla sin demasiadas dudas. Decimos que una interfaz tiene botones, menús, formularios, diálogos, listas, pestañas, estados de carga, mensajes de error y acciones disponibles. Decimos que una interfaz es clara, confusa, pesada, fluida, accesible, elegante o difícil de usar.

La palabra sirve para muchas cosas. Quizá por eso también oculta algunas.

Durante mucho tiempo, la definición más práctica ha sido suficiente: una interfaz es el punto de contacto entre una persona y un sistema. Es la superficie mediante la cual el sistema se vuelve visible, interpretable y manipulable.

Esa definición ha sido útil. Todavía lo es. Gracias a ella hemos aprendido a construir pantallas legibles, jerarquías visuales, patrones de navegación, controles reutilizables y guías de estilo.

El problema no es que esa definición sea falsa. El problema es que empieza a quedarse corta.

Porque cuando una persona usa una interfaz, no se relaciona únicamente con una superficie. También percibe respuestas, cambios, interrupciones, confirmaciones, esperas, apariciones, pérdidas, errores, desplazamientos, manipulaciones y consecuencias.

*Una interfaz no es solo aquello que está ahí. Es también aquello que ocurre.*

Si la interfaz se entiende solo como superficie, el componente tiende a convertirse en la unidad principal de análisis. Pero si la interfaz se entiende también como lugar donde ocurren transformaciones, aparece otra pregunta:

*¿Qué clase de evento está percibiendo el usuario?*

# 1. La interfaz como superficie

La concepción clásica de interfaz nace de una necesidad concreta: hacer que un sistema pueda ser usado. Un sistema informático, por sí mismo, no se ofrece directamente a la percepción humana. Sus operaciones internas no son visibles. Sus estados no se presentan espontáneamente como posibilidades comprensibles.

La interfaz aparece para mediar esa distancia. Convierte estructuras internas en formas perceptibles. Traduce posibilidades abstractas en controles. Presenta estados. Organiza caminos de acción.

Desde este punto de vista, la interfaz es una *superficie de traducción*. No una superficie en el sentido pobre de «lo visual», sino en el sentido de una zona de contacto: el lugar donde dos realidades distintas se encuentran.

Esta tradición ha producido herramientas indispensables: jerarquía visual, contraste, espaciado, agrupación, estados de componente, affordances, patrones de navegación, consistencia, accesibilidad, sistemas de diseño y componentes reutilizables.

Nada de eso queda invalidado por la propuesta de este libro. Una teoría del evento interactivo necesita apoyarse en esa base.

Principio

*La gramática del evento no sustituye a la gramática visual; la prolonga.*

Pero la superficie, por sí sola, no basta. Porque la experiencia de uso no está hecha solo de elementos dispuestos en el espacio. Está hecha de elementos que cambian, responden, aparecen, desaparecen, se desplazan, se fijan, se bloquean o se transforman.

*La interfaz no es una imagen. Es una situación que evoluciona.*

# 2. El límite de la superficie

Pensemos en algo sencillo: un usuario pulsa un botón para guardar cambios. Desde la implementación pueden ocurrir muchas cosas: se dispara un evento click, el botón entra en estado active, aparece un spinner, se envía una petición, se deshabilita el control, llega una respuesta, se muestra una confirmación, cambia un estado interno, quizá aparece un toast.

Técnicamente son muchas operaciones. Para el usuario, sin embargo, hay una secuencia más compacta: *he actuado; el sistema me ha sentido; algo está ocurriendo; el resultado ha quedado confirmado*.

Figura 1.1

La experiencia no se organiza según nuestras capas de implementación. Se organiza según unidades de sentido operativo.

Lo mismo sucede con un diálogo modal. Desde la superficie, es una capa que aparece sobre otra. Pero desde la experiencia, puede significar cosas muy distintas: una confirmación ligera, una interrupción crítica, un cambio temporal de foco, una elección irreversible.

*La interfaz no solo representa estados; también organiza transformaciones.*

# 3. Del objeto al cambio

El diseño de interfaces ha desarrollado una cultura poderosa alrededor del objeto. Definimos botones, inputs, selects, cards, dialogs, menus, tooltips, accordions, tabs. Cada componente tiene una anatomía, unas variantes, unos estados y unas reglas de uso.

Ese enfoque ha sido enormemente productivo. Pero el objeto no siempre es la unidad que el usuario necesita comprender. Un botón no es significativo solo por ser botón. Lo es por lo que permite hacer y por lo que ocurre cuando se actúa sobre él.

Por eso, para una teoría semántica de la interfaz, el centro debe desplazarse: del componente al evento, de la forma al cambio, del estado aislado a la transformación, de la propiedad visual al significado perceptivo.

Distinción clave

*Un componente es una entidad de diseño. Un evento es una unidad de experiencia.*

A partir de ahí aparece una segunda idea: una interfaz no es solo una superficie visible, sino la dimensión perceptible de un contexto operacional. Cuando usamos una interfaz, no estamos mirando figuras flotando en una pantalla. Estamos dentro de una situación de acción. Queremos hacer algo, corregir algo, elegir algo, esperar algo, confirmar algo. Hay objetivos, estados, restricciones, riesgos, expectativas y consecuencias. La interfaz es la forma sensible que adopta todo ese contexto.

# 4. Qué llamamos contexto operacional

Un contexto operacional es la situación de uso en la que una acción tiene sentido. No es solo la pantalla. No es solo el estado interno. Es el conjunto dinámico de condiciones que hacen que una acción signifique algo.

Figura 1.2

Cuando un usuario pulsa «Eliminar», el contexto operacional no se reduce al botón rojo. Incluye qué se elimina, si hay deshacer, si la acción es irreversible, si el elemento tiene valor, si forma parte de una estructura más grande, si el usuario espera confirmación y si la pérdida debe comunicarse como amenaza, riesgo o hecho consumado.

*El contexto operacional no es una capa más del sistema. Es aquello de lo que la interfaz es manifestación perceptible.*

# 5. La interfaz como dimensión perceptible

Si el contexto operacional es la situación de acción, la interfaz es aquello que permite percibirlo. No todo el contexto se vuelve sensible de la misma manera. Algunas partes se expresan mediante texto. Otras mediante posición. Otras mediante color. Otras mediante movimiento. Otras mediante sonido. Otras mediante ausencia, bloqueo, espera o silencio.

La interfaz no necesita contestar siempre con palabras. Parte de su trabajo consiste en distribuir respuestas entre señales perceptivas: posición, contraste, ritmo, continuidad, jerarquía espacial, tono, presencia, desaparición. Un campo que tiembla prepara la atención. Un botón que se comprime preserva la sensación de contacto. Un panel que aparece desde un origen hace visible una relación. Un objeto que se eleva al ser arrastrado hace sensible el cambio de régimen.

Por eso conviene hablar de *dimensión perceptible*. La interfaz es la zona donde el sistema se vuelve perceptivamente disponible para un cuerpo humano: visible, audible, táctil, temporalmente inteligible y accionable.

# 6. La interfaz no es solo visual

Uno de los supuestos más persistentes en el diseño de interfaces es que la interfaz es fundamentalmente visual. Este supuesto tiene razones históricas claras: la pantalla ha sido el medio dominante, las herramientas de diseño trabajan sobre superficies visuales, la web misma nació como documento visible.

Pero incluso dentro de lo visual, conviene distinguir canales que suelen mezclarse. Un cambio de color no comunica lo mismo que un desplazamiento. Una sombra no comunica lo mismo que un borde. Una aparición no comunica lo mismo que una vibración de alerta.

Figura 1.3

La interfaz no es visual más algunos extras. Es *perceptiva*. Y esa percepción se distribuye entre canales distintos, cada uno con mecanismos propios, reglas propias y condiciones propias de eficacia. El hecho de que algunos canales no estén disponibles en ciertos entornos no los vuelve teóricamente irrelevantes.

*La pregunta de fondo es siempre la misma: ¿qué necesita percibir el usuario para entender lo que ocurre?*

# 7. Estados, eventos y consecuencias

Un estado describe una condición relativamente estable: seleccionado, desactivado, cargando, inválido. Un evento describe una transformación: seleccionar, desactivar, empezar a cargar, fallar.

La diferencia importa porque el usuario necesita entender ambas cosas. Necesita saber que algo está seleccionado, pero también necesita percibir que la selección acaba de ocurrir. Necesita saber que algo está cargando, pero también necesita percibir cuándo empezó y si sigue vivo.

**PLANO**	**PREGUNTA**	**EJEMPLO**	**FORMA TÍPICA**
**Componente**	¿Qué es esto?	botón, modal, toast	Elemento del DOM
**Estado**	¿En qué condición está?	seleccionado, abierto, cargando	Clase CSS, propiedad
**Evento**	¿Qué cambio acaba de ocurrir?	seleccionar, abrir, iniciar carga	Transición, señal perceptiva
**Consecuencia**	¿Qué implica ahora?	quedó fijado, hay que esperar	Interpretación del usuario

*Tabla 1 — Los cuatro planos de análisis de la interfaz*

Una interfaz centrada solo en estados puede mostrar correctamente el resultado final, pero dejar pobremente articulado el cambio que llevó hasta él. Por eso este libro insistirá en que una interfaz no debería limitarse a mostrar estados finales. Debe hacer legibles las transformaciones relevantes.

# 8. Qué cuenta como evento interactivo

No cualquier cambio perceptible merece el mismo rango. Para hablar de evento interactivo en sentido fuerte hacen falta tres condiciones.

Primero, debe haber una modificación perceptible. Algo debe cambiar en el campo de experiencia del usuario.

Segundo, esa modificación debe tener relevancia operativa. Debe afectar a la acción, la atención o la interpretación del estado.

Tercero, debe poder inscribirse en una clase reconocible. Una teoría necesita identificar diferencias recurrentes.

Definición

*Un evento interactivo es una modificación perceptible del contexto operacional que tiene significado para la acción, la atención o la interpretación del estado.*

Esta definición excluye tanto la pura lógica interna como la ornamentación sin función. Un callback técnico no es necesariamente un evento interactivo. Una animación decorativa tampoco. Pero cuando una modificación perceptible ayuda al usuario a entender qué está ocurriendo, empieza a tener estatuto de evento significativo.

# 9. Un botón no es un evento

Tomemos un botón simple: «Guardar». Desde el punto de vista del componente tiene un label, un tamaño, una variante, estados hover, active, disabled. Pero desde el punto de vista del evento, el mismo botón puede participar en secuencias distintas.

Figura 1.4

En todos los casos el componente puede ser «un botón de guardar». Pero los eventos no son los mismos. Una teoría centrada solo en componentes tiende a ocultar esa diferencia. Una teoría centrada en eventos la vuelve explícita.

# 10. Abrir no siempre significa lo mismo

Un tooltip aparece. Un dropdown aparece. Un modal aparece. Una página nueva aparece. Una notificación aparece. Un error aparece. Superficialmente podríamos decir: todos son eventos de aparición. Pero esa descripción es demasiado gruesa.

Figura 1.5

Un tooltip revela información auxiliar sin cambiar el marco principal. Un modal reorganiza el foco operativo y subordina lo demás. Una notificación introduce un mensaje iniciado por el sistema. «Algo aparece» no basta. La pregunta relevante es: ¿qué tipo de aparición es esta dentro del contexto operacional?

# 11. Por qué esta redefinición importa al programar

Un *click* no es una semántica. Un *change* no es una semántica. Un *submit* no es una semántica. Un *drag* no es una semántica. Son disparadores técnicos. Pueden dar lugar a eventos interactivos muy distintos.

Un click puede ser contacto, consolidación, navegación, apertura, amenaza, pérdida o confirmación. Un submit puede ser inicio de proceso, culminación, fallo, riesgo o resolución. Un drag puede ser manipulación, desplazamiento, reordenación o descarte.

Cuando no tenemos vocabulario para estas diferencias, las resolvemos de forma local. Una teoría semántica permite que antes de discutir «qué transición ponemos aquí», podamos preguntar: *¿qué evento estamos haciendo perceptible?* Y antes de discutir «qué color usamos»: *¿este evento es evaluable o solo estructura el campo?*

# 12. Qué no estamos diciendo

No estamos diciendo que la interfaz clásica esté equivocada. No estamos diciendo que todo deba animarse, sonar o vibrar. No estamos diciendo que los componentes dejen de importar. No estamos diciendo que todo cambio sea semántico. No estamos diciendo que la ciencia pueda dictar cada duración o cada frecuencia.

Lo que sí estamos diciendo es más sencillo:

*La interfaz no se comprende del todo si solo se analiza como superficie de componentes. También debe analizarse como sistema perceptivo de eventos.*

# **13.

Esta idea se desarrollará con más precisión en el capítulo de fundamentos psicoperceptivos. Allí veremos que la interfaz no solo se organiza visualmente; también se apoya en percepción de campo, affordances, atención, evaluación, movimiento, sonido, multisensorialidad y experiencia corporal.

Por ahora basta con fijar una tesis:

DISTINCIÓN

La interfaz no es visual más algunos extras. Es perceptiva.

Síntesis**

*La interfaz es la dimensión perceptible de un contexto operacional.*

**ANTES**	**DESPUÉS**
Interfaz como superficie	Interfaz como dimensión perceptible
Componente como centro	Evento como unidad de significado
Estado final	Transformación significativa
Efecto local	Gramática del cambio
Implementación fragmentada	Experiencia unificada

*Tabla 2 — El desplazamiento conceptual que propone este libro*

El usuario no necesita percibir solo que algo existe, sino qué tipo de cambio ha ocurrido y qué implica. Desde aquí, el siguiente paso será desarrollar la noción de evento interactivo con más detalle.

Porque si la interfaz es la dimensión perceptible de un contexto operacional, entonces su unidad mínima de significado no puede ser únicamente el elemento visible.

Tiene que ser el cambio significativo.

Tiene que ser el evento.

La redefinición de interfaz como dimensión perceptible de un contexto operacional prepara el desplazamiento central del libro: del componente al evento. El componente sigue siendo necesario, pero ya no basta como unidad principal de significado. Cuando la interfaz cambia, responde, espera, interrumpe, confirma o pierde algo, el usuario no interpreta solo objetos: interpreta eventos.


================================================================================
CAPÍTULO 2 — capitulo2_con_diagramas.docx
================================================================================
CAPÍTULO 2

Por qué preguntamos ahora

Sedimentación, dependencia del camino y carga paradigmática

El capítulo anterior propuso una redefinición de la interfaz: no solo como superficie visible de componentes, sino como *dimensión perceptible de un contexto operacional*. Esa redefinición abre una pregunta incómoda.

Si la interfaz es algo más que una superficie, si el usuario no percibe solo botones, menús, colores o estados, sino también respuestas, esperas, confirmaciones, interrupciones, pérdidas, apariciones y cambios de marco, ¿por qué durante tanto tiempo hemos diseñado y programado como si esas dimensiones pertenecieran a capas separadas?

La respuesta fácil sería decir que el diseño de interfaces arrastra una deuda histórica. Pero lo que ha ocurrido no es exactamente deuda técnica. Muchas categorías no se adoptaron como soluciones provisionales, sino como supuestos tan naturales que ni siquiera parecían necesitar examen.

Este capítulo sostiene que el diseño de interfaces arrastra tres mecanismos entrelazados: sedimentación cultural (capas de convenciones heredadas que se acumulan sin revisión profunda), dependencia del camino (decisiones iniciales que se vuelven difíciles de abandonar porque el ecosistema se organiza alrededor de ellas) y carga paradigmática (supuestos invisibles que determinan qué preguntas parecen naturales y cuáles ni siquiera aparecen).

Figura 2.1

# 1. Por qué «deuda técnica» no basta

La deuda técnica implica normalmente tres cosas: una decisión consciente, un intercambio temporal y una posibilidad futura de corrección. Alguien sabe que está tomando un atajo, acepta el coste posterior y deja abierta la posibilidad de pagarlo.

Muchas convenciones del diseño de interfaces no nacieron así. Cuando se adoptaron categorías como *success*, *warning*, *danger* o *info*, no parece que la industria estuviera diciendo «esto es provisional hasta que desarrollemos una teoría afectiva más sólida». La convención era familiar, comprensible y útil. Parecía natural.

Lo mismo sucede con el sonido. La web nació en un contexto donde el audio era técnicamente difícil, socialmente problemático y muchas veces mal usado. La desconfianza tenía razones legítimas, pero no equivalía a una teoría perceptiva del canal auditivo.

Principio

*Una deuda técnica se contrae sabiendo que se contrae. Un supuesto no examinado opera precisamente porque no se percibe como supuesto.*

Figura 2.2

# 2. Sedimentación cultural

Las convenciones no se han contraído como deudas. Se han *sedimentado* como capas. Cada generación de herramientas, medios y prácticas ha depositado una capa sobre la anterior. La interfaz digital heredó convenciones del papel, del diseño editorial, de la señalización industrial, de los sistemas operativos de escritorio, de la web documental, de los frameworks CSS, de los sistemas de diseño corporativos y de las librerías de componentes.

Ninguna de esas capas es absurda. Cada una resolvió problemas reales en su momento. El problema aparece cuando olvidamos que eran respuestas situadas. Lo que nació como solución local puede convertirse, con el tiempo, en una categoría general no examinada.

Esa sedimentación no es mala en sí misma. Sería imposible diseñar sin herencia. Pero hay un límite. Algunas convenciones siguen funcionando porque capturan intuiciones perceptivas sólidas. Otras siguen simplemente porque el ecosistema se organizó alrededor de ellas. Y otras funcionaron en un medio anterior pero ya no bastan para un medio donde la interfaz es temporal, dinámica, multicanal y adaptativa.

Figura 2.3

# 3. Dependencia del camino

La sedimentación explica cómo se acumulan las convenciones. Pero no explica del todo por qué persisten cuando aparecen alternativas mejores. Ahí entra la dependencia del camino: una decisión inicial, tomada por razones concretas y a veces contingentes, puede condicionar todas las decisiones posteriores.

El ejemplo clásico es QWERTY. La distribución de teclado se estabilizó en un contexto tecnológico muy distinto del actual. Cuando aparecieron alternativas, ya no bastaba con demostrar que podían ser mejores. Había que vencer el coste de cambiar todo el ecosistema.

El diseño de interfaces tiene sus propios QWERTYs. La estructura *success / warning / danger / info* se difundió porque era útil, simple y fácil de implementar. Pero su permanencia actual no se debe necesariamente a que sea la mejor taxonomía afectiva posible. Se debe también a que frameworks, documentación, temas, equipos y hábitos se han organizado alrededor de ella.

*Una convención puede persistir no porque sea óptima, sino porque el coste de abandonar el camino que abrió se ha vuelto demasiado alto.*

**CONVENCIÓN**	**RAZÓN INICIAL**	**COSTE DE CAMBIARLA**	**PREGUNTA QUE ABRE**
**success/danger/info**	Categorías simples	APIs, temas, hábitos	¿Qué regiones afectivas necesita la interfaz?
**Motion como adorno**	Interfaz nació estática	Herramientas centradas en componentes	¿Qué significado temporal tiene cada evento?
**Sonido como accesorio**	Abuso histórico, autoplay	Desconfianza cultural	¿Cuándo el sonido comunica mejor?
**Visual como saco único**	Tradición gráfica	Disciplinas organizadas así	¿Qué canales se esconden dentro?
**Accesibilidad como corrección**	Diseño primero, adaptar después	Procesos separados	¿Cómo se redistribuye el significado?

*Tabla 1 — Algunos «QWERTYs» del diseño de interfaces*

Figura 2.4

# 4. Carga paradigmática

La sedimentación explica cómo se acumulan las capas. La dependencia del camino explica por qué persisten. Pero todavía queda un mecanismo más profundo: por qué ciertas preguntas ni siquiera aparecen.

Un paradigma no es solo un conjunto de prácticas. Es un marco que define qué preguntas parecen naturales, qué problemas merecen atención y qué soluciones resultan visibles. Si la interfaz se concibe fundamentalmente como superficie visual de componentes, entonces es natural preguntar por layout, color, estilo, estados y componentes. Es menos natural preguntar por evento, temporalidad, canales perceptivos, coordinación multicanal o semántica de la pérdida.

Formulados explícitamente, los supuestos del paradigma dominante pueden discutirse: que la interfaz es fundamentalmente visual, que el componente es la unidad principal, que el sonido y la háptica son añadidos, que el motion es suavizado o decoración, que los intents heredados son categorías naturales, que la accesibilidad se añade después. Pero mientras no se formulan, operan como normalidad.

*¿Qué evento necesita percibir el usuario y por qué canales debe hacerse legible?*

Figura 2.5

# 5. Por qué ahora

Lo que ha cambiado es la convergencia de varias condiciones. Las interfaces son más dinámicas, los canales disponibles se han multiplicado, la accesibilidad ha dejado de ser un añadido, la IA cambia la naturaleza de la interfaz, y los sistemas de diseño han madurado lo suficiente como para mostrar la capa que falta.

La semántica del evento se vuelve más importante cuanto menos visible es la causalidad interna del sistema. Cuando una interfaz sugiere, anticipa, completa, genera, advierte, modifica estados o toma iniciativas, el usuario necesita entender qué tipo de evento está ocurriendo.

Figura 2.6

# 6. Qué preguntas permite formular este libro

El objetivo no es declarar obsoletas las convenciones existentes. Muchas funcionan porque capturan regularidades perceptivas reales. El problema es no poder distinguir cuáles siguen siendo fundamento y cuáles son solo sedimento.

Este libro intenta abrir un espacio donde esas preguntas puedan formularse: ¿por qué una interfaz necesita distinguir contacto de consolidación? ¿Por qué una advertencia corregible no debería sentirse igual que una amenaza urgente? ¿Por qué abrir un panel no es lo mismo que cambiar de marco operativo? ¿Por qué la accesibilidad debería pensarse como redistribución semántica entre canales?

**SUPUESTO HEREDADO**	**PREGUNTA QUE AHORA PODEMOS FORMULAR**
**La interfaz es visual**	¿Qué canales perceptivos participan realmente?
**El componente es la unidad central**	¿Qué eventos atraviesan los componentes?
**Motion es decoración**	¿Qué significado temporal comunica el movimiento?
**Sonido es accesorio**	¿Qué eventos necesitan canal auditivo?
**Intent es color**	¿Qué evaluación afectiva comunica el evento?
**Accesibilidad es adaptación posterior**	¿Cómo migra el significado entre canales?
**Las convenciones son estándares**	¿Qué parte es fundamento y qué parte es sedimento?

*Tabla 2 — Qué abre este capítulo*

Figura 2.7

# 7. Síntesis

La noción de deuda técnica no basta para explicar la situación. Lo que encontramos es una mezcla de sedimentación cultural, dependencia del camino y carga paradigmática. La sedimentación explica cómo las convenciones se acumulan por capas. La dependencia del camino explica por qué persisten. La carga paradigmática explica por qué ciertas preguntas no aparecen dentro del marco dominante.

Este libro no propone rechazar esa herencia. Propone hacerla examinable. Y para examinarla necesitamos desplazar la pregunta.

*¿Qué evento necesita percibir el usuario?*

Si la interfaz es la dimensión perceptible de un contexto operacional, entonces su unidad mínima de significado no puede ser únicamente el componente.

Tiene que ser el cambio significativo.

Tiene que ser el evento.

Lo que ha cambiado no es que hayamos descubierto de pronto la percepción humana. La psicología de la percepción, la teoría de affordances, la atención, los modelos de evaluación afectiva, la multisensorialidad y los esquemas corporales llevan décadas ofreciendo herramientas para pensar mejor la interacción.

Lo que ha cambiado es la necesidad de reunir esos marcos en una teoría de interfaz.

Por eso el siguiente capítulo hará una pausa antes de entrar en evento, gramática e interacción semántica. Presentará los fundamentos psicoperceptivos que sostendrán el resto del libro. No para convertir el diseño en psicología aplicada mecánicamente, sino para evitar que la teoría semántica de la interfaz parezca una colección de intuiciones personales.


================================================================================
CAPÍTULO 3 — capitulo3_con_diagramas.docx
================================================================================
CAPÍTULO 3

Fundamentos psicoperceptivos de la interfaz

De qué está hecha la percepción interactiva

Si este libro sostiene que la interfaz debe entenderse como sistema perceptivo de eventos, no puede apoyarse solo en vocabulario de diseño, convenciones de framework o intuiciones de implementación. Necesita preguntarse cómo perciben las personas: cómo organizan un campo visual, cómo detectan cambios, cómo orientan la atención, cómo atribuyen causalidad, cómo evalúan una situación, cómo integran señales de varios canales y cómo convierten una acción en experiencia significativa.

*Una interfaz no se comprende solo como imagen, ni solo como estructura, ni solo como código. Se comprende como un campo perceptivo en el que un usuario atiende, actúa, evalúa, predice, recuerda e integra señales distribuidas entre varios canales.*

Figura 3.1

# 1. Por qué necesitamos fundamentos perceptivos

El diseño de interfaces ha construido una tradición práctica muy sólida. Sabemos organizar jerarquías visuales, usar contraste, agrupar elementos, diseñar componentes y sistemas. Pero si la interfaz hace perceptibles eventos, necesitamos explicar cómo un usuario percibe que algo ha ocurrido, que su acción fue registrada, que un estado quedó fijado, que una operación sigue viva, que una alerta reclama atención o que una pérdida ya se produjo.

Principio

*Si la interfaz es perceptiva, su teoría no puede depender solo de convenciones visuales. Debe apoyarse en cómo las personas perciben, atienden, actúan y evalúan cambios.*

# 2. Organización perceptiva: Gestalt, agrupación y figura/fondo

Un usuario no percibe una interfaz como suma neutra de elementos. La percibe como un campo organizado: unas cosas pertenecen juntas, otras quedan separadas; unas actúan como figura, otras como fondo. La revisión de Wagemans y colaboradores sobre un siglo de psicología Gestalt resume fenómenos como agrupación, organización figura/fondo, continuidad y cierre como principios centrales de la percepción visual.

Esto prepara una distinción esencial: *hay eventos que son figura y eventos que son fondo*. Un error dentro de un modal puede ser figura evaluable. La apertura del modal puede ser fondo estructural. Si no distinguimos ambas cosas, terminamos coloreando el contenedor en lugar del mensaje.

Figura 3.2

# 3. Affordances y acción situada

Una interfaz no es solo algo que el usuario observa. Es un campo de posibilidades. Gibson formuló la noción de affordance para nombrar lo que el entorno ofrece al organismo en términos de acción posible. Un botón ofrece ser pulsado. Un slider ofrece ser arrastrado. Un modal comunica que ciertas acciones quedan suspendidas y otras adquieren prioridad.

**AFFORDANCE**	**QUÉ OFRECE**	**EVENTO**	**LECTURA**
**Presionar**	Actuar sobre algo	contact	El sistema ha sentido mi acción
**Elegir**	Fijar una opción	commit.select	Esto queda elegido
**Manipular**	Mover directamente	handle	Estoy controlando este objeto
**Atender**	Mirar o responder	signal	Esto requiere mi atención
**Entrar/salir**	Cambiar disponibilidad	emerge / shift	Algo apareció / cambió el marco
**Esperar**	Sostener proceso	sustain	Esto sigue ocurriendo

*Tabla 1 — Affordances y eventos interactivos*

# 4. Atención, saliencia y carga cognitiva

Una interfaz siempre compite por recursos limitados. Cada señal, cada movimiento, cada sonido y cada color saturado tiene un coste. Posner estudió la orientación de la atención como un proceso que asigna recursos de procesamiento a una parte del campo perceptivo, incluso antes de que haya movimiento ocular explícito.

No todo evento debe reclamar atención. Un signal.alert sí puede justificar interrupción. Un emerge.reveal quizá solo debe hacer aparecer contenido. Un sustain.progress debe mantener conciencia de proceso sin competir con la tarea principal.

Figura 3.3

# 5. Appraisal: evaluación del evento

Algunos cambios no solo se perciben. Se evalúan: ¿esto es bueno o malo para mí?, ¿favorece mi meta?, ¿bloquea mi acción?, ¿puedo corregirlo?, ¿requiere respuesta inmediata? Scherer describe el proceso emocional como una secuencia de evaluaciones en términos de relevancia, implicaciones, capacidad de afrontamiento y significado normativo.

El appraisal permite formular una distinción que después será central: no todos los eventos son evaluables. Algunos son mensaje (fallo, advertencia, confirmación, pérdida). Otros son marco (apertura, expansión, navegación, sostenimiento). El intent tiene sentido cuando hay algo que evaluar.

Principio

*El intent no nace del color. Nace de la evaluación de un evento respecto a metas, riesgo, control y consecuencia.*

# 6. Valencia y arousal: el espacio afectivo

Si un evento es evaluable, necesitamos describir de qué tipo de evaluación se trata. El modelo circumplejo de Russell propone dos ejes: valencia (positivo/negativo) y arousal (baja/alta activación). Esto permite distinguir regiones que el semáforo heredado (success/warning/danger/info) mezcla.

No es lo mismo threat (negativo, alta activación) que loss (negativo, baja activación). No es lo mismo affirm (positivo leve) que fulfill (positivo, activación media-alta). Esta distinción permite formular los intents no como colores, sino como *regiones evaluativas del evento*.

Figura 3.4

# 7. Movimiento, causalidad y continuidad

En diseño de interfaces solemos hablar de «animación» como recurso visual añadido. Pero para esta teoría conviene distinguir animación de motion. La animación es la implementación. Motion es la percepción de que algo se mueve, se comprime, aparece, se desplaza o cambia de régimen en el tiempo.

Michotte mostró que ciertos patrones simples de movimiento producen una impresión directa de causación: si una respuesta ocurre cerca de la acción del usuario y con forma temporal adecuada, puede percibirse como consecuencia de esa acción. Si llega tarde o con forma incongruente, se percibe como evento separado.

Figura 3.5

# 8. Sonido, multisensorialidad e integración de canales

El sonido tiene propiedades que otros canales no tienen: puede percibirse sin mirar la pantalla, puede comunicar urgencia rápidamente, puede marcar cierre, confirmación o pérdida, y puede funcionar como canal de respaldo cuando motion o visión están reducidos. Spence revisa cómo ciertas correspondencias crossmodales — pitch con tamaño, brillo con peso, movimiento ascendente con resolución — aparecen de forma consistente.

Principio

*El problema histórico no ha sido el sonido en la interfaz. Ha sido el sonido sin gramática: arbitrario, desproporcionado o desacoplado del evento.*

El usuario no percibe motion, sonido, color y háptica como departamentos aislados. Wallace y colaboradores muestran que la capacidad del cerebro para ligar estímulos de distintas modalidades depende de su estructura temporal. Si el sonido llega demasiado tarde respecto al movimiento, el usuario percibe dos eventos, no uno. Una interacción semántica multicanal necesita congruencia temporal, de intensidad, de dirección y afectiva.

Figura 3.6

# 9. Esquemas sensoriomotores y cognición corporeizada

Muchas categorías que usamos para pensar interfaces proceden de patrones corporales básicos: contacto, presión, contenedor, camino, entrada, salida, peso, resistencia, pérdida, agarre, encaje, proceso. No las usamos solo como metáforas decorativas. Funcionan porque la interfaz digital se apoya en esquemas que el usuario ya conoce por su experiencia corporal.

Algunos esquemas son agentivos e implican acción y evaluación: contacto, elección, logro, pérdida, manipulación. Otros son estructurales y organizan el campo: contenedor, camino, proceso, entrada/salida. Esta diferencia prepara la distinción entre eventos valenciales y transicionales.

Figura 3.7

# 10. Accesibilidad como prueba de arquitectura perceptiva

Si una interfaz distribuye significado entre varios canales, debe preguntarse qué ocurre cuando uno se reduce. Si el color no basta, debe haber forma, texto o posición. Si se reduce motion, la causalidad debe apoyarse en otros recursos. Si el sonido está desactivado, una alerta debe seguir siendo perceptible.

Principio

*La accesibilidad no solo adapta la interfaz. Revela si el significado estaba bien distribuido entre canales.*

# 11. Cómo usará este libro estos fundamentos

**FUNDAMENTO**	**QUÉ EXPLICA**	**QUÉ APORTA A LA TEORÍA**
**Gestalt**	Agrupación, figura/fondo	Diferencia entre marco y mensaje
**Affordances**	Percepción de acción posible	Contexto operacional, contacto, manipulación
**Atención**	Saliencia, orientación, carga	Signal, proporción, interrupción
**Appraisal**	Evaluación respecto a metas	Semánticas valenciales/transicionales
**Valencia/arousal**	Estructura afectiva básica	Sistema de intents
**Motion**	Causalidad, continuidad, energía	Temporalidad y física del evento
**Sonido**	Urgencia, valencia, cierre	Microeventos auditivos
**Multisensorialidad**	Integración temporal de señales	Evento multicanal unificado
**Esquemas corporales**	Contacto, camino, contenedor, pérdida	Familias semánticas
**Accesibilidad**	Reducción o sustitución de canales	Migración semántica

*Tabla 2 — Mapa de fundamentos y función en el libro*

# **12.

El espacio evaluativo: valencia y activación

Hasta ahora hemos descrito cómo el usuario percibe, atiende y actúa. Falta una dimensión esencial: cómo evalúa lo que ocurre.

Cuando un evento interactivo sucede, el usuario no solo lo reconoce. También lo interpreta: ¿esto es bueno o malo para mí? ¿requiere acción inmediata? ¿puedo ignorarlo? ¿ya ocurrió o aún puedo evitarlo? ¿se resolvió algo que estaba pendiente?

Una forma útil de organizar estas evaluaciones es el espacio propuesto por James A. Russell, que describe los estados afectivos mediante dos dimensiones: valencia (positivo / negativo) y activación (baja / alta).

Este modelo no pretende capturar toda la complejidad emocional. Pero resulta suficiente para distinguir diferencias que una interfaz necesita comunicar de forma consistente.

Por ejemplo: no es lo mismo algo negativo urgente que algo negativo ya ocurrido; no es lo mismo una confirmación leve que una culminación; no es lo mismo informar que advertir; no es lo mismo pedir atención que registrar una pérdida.

Estas diferencias no son estilísticas. Son operativas.

Este libro utilizará ese espacio como base para definir los intents, no como una teoría psicológica completa, sino como una estructura mínima para organizar la evaluación del evento.

Síntesis**

La interfaz se percibe como campo organizado: por eso necesitamos Gestalt y figura/fondo. Se usa como campo de acción: por eso necesitamos affordances. Compite por atención limitada: por eso necesitamos saliencia y carga cognitiva. Comunica resultados, riesgos y pérdidas: por eso necesitamos appraisal. Modula tono afectivo: por eso necesitamos valencia y arousal. Cambia en el tiempo: por eso necesitamos motion. Puede sonar, vibrar, moverse y cambiar de presencia a la vez: por eso necesitamos multisensorialidad. Se apoya en experiencia corporal: por eso necesitamos esquemas. Y debe seguir siendo legible cuando un canal falta: por eso la accesibilidad es constitutiva, no añadida.

Estos fundamentos no pretenden probar una taxonomía definitiva ni dictar cada valor concreto de duración, frecuencia o intensidad. *La ciencia no sustituye al diseño. Lo disciplina.* Le impide confundir color con intent, motion con decoración, sonido con accesorio y evento técnico con significado experiencial.

*Una teoría semántica de la interfaz debe apoyarse en cómo los seres humanos perciben cambios, actúan sobre posibilidades, atienden señales, evalúan consecuencias e integran canales.*

El siguiente capítulo podrá volver ahora al concepto central del libro: el evento interactivo como unidad mínima de significado. Ya no partiremos solo de una intuición práctica. Tendremos un mapa de fundamentos que explica por qué el evento, y no solo el componente, puede convertirse en la unidad central de una teoría perceptiva de la interfaz.

Estos fundamentos no dictan una taxonomía cerrada. No prueban que solo existan siete familias ni seis intents. Lo que hacen es otra cosa: ofrecen criterios para que las categorías del libro no parezcan arbitrarias.

A partir de aquí, cuando hablemos de evento, gramática, interacción semántica, familias, intent y canales, no estaremos hablando de nombres inventados desde el diseño. Estaremos nombrando formas recurrentes de percibir, actuar, atender, evaluar e integrar cambios.

DISTINCIÓN

Este libro no inventa categorías perceptivas. Les da nombre dentro de la interfaz.


================================================================================
CAPÍTULO 4 — capitulo4_con_diagramas.docx
================================================================================
CAPÍTULO 4

El evento interactivo como unidad mínima de significado

Esta definición se apoya en los fundamentos anteriores. Desde la organización perceptiva, un evento modifica el campo: algo aparece, cambia de figura, se subordina. Desde las affordances, un evento modifica lo que el usuario puede hacer. Desde la atención, un evento puede orientar, reclamar o liberar foco. Desde el appraisal, un evento puede volverse evaluable: favorable, riesgoso, urgente, perdido o resuelto. Desde la multisensorialidad, un evento puede distribuirse entre varios canales y aun así percibirse como una sola unidad.

Por eso un evento interactivo no equivale a un click, a un callback ni a un cambio interno de estado. Un evento interactivo existe cuando una modificación perceptible altera la relación operativa entre usuario y sistema.

Qué cuenta como cambio significativo en una interfaz

El capítulo anterior propuso una redefinición inicial: la interfaz no es solo una superficie de componentes, sino la *dimensión perceptible de un contexto operacional*. Desde ahí aparecía una consecuencia inevitable: si la interfaz no solo muestra cosas, sino que también hace ocurrir transformaciones, entonces la unidad mínima de significado no puede buscarse únicamente en el componente. Tiene que buscarse en el cambio. Tiene que buscarse en el evento.

Su objetivo no es todavía cerrar la taxonomía de familias semánticas. Tampoco entrar en canales perceptivos, intents o valores concretos. Aquí necesitamos algo más básico: entender qué es un evento interactivo, qué lo diferencia de una acción técnica, de un estado, de una variación visual, de un efecto y de una consecuencia.

*¿Cuándo algo que cambia en una interfaz merece ser tratado como evento significativo?*

# 1. El cambio no basta

En una interfaz pasan muchas cosas. Un botón cambia de color al pasar el cursor. Un icono modifica su opacidad. Una lista se reordena. Un menú aparece. Un campo muestra un error. Un spinner empieza a girar. Un toast entra desde la esquina. Una tarjeta desaparece. Un sonido breve acompaña una confirmación. Una vibración responde al contacto. Una vista sustituye a otra.

Podríamos llamar «evento» a todo eso. Pero esa definición sería demasiado amplia. No todo cambio perceptible es un evento interactivo en sentido fuerte. Algunos cambios son ornamentales. Otros son puramente mecánicos. Otros son variaciones locales sin relevancia para la acción del usuario.

La pregunta no es simplemente: ¿algo ha cambiado? La pregunta es: *¿ese cambio modifica lo que el usuario entiende que está ocurriendo?*

Principio

*Un evento interactivo no es cualquier cambio perceptible. Es un cambio perceptible con relevancia operativa.*

# 2. Variación, efecto y evento

Una variación es un cambio perceptible de bajo compromiso semántico. Un botón que cambia su sombra al hover puede indicar interactividad, pero si no altera el estado ni comunica una acción registrada, no es todavía un evento interactivo pleno.

Un efecto es una realización perceptiva concreta: una animación, un sonido, una vibración, un cambio cromático, un fade, un bounce, un shake. El efecto pertenece al plano de los medios.

Un evento pertenece al plano del significado operativo. No se define por la forma que toma, sino por la transformación que vuelve legible.

Un shake puede ser un efecto. Pero «el sistema reclama atención por una discrepancia» es un evento. Un bounce puede ser un efecto. Pero «esta decisión ha quedado fijada» es un evento.

Figura 4.1

# 3. El evento no está en el código

Un *click* solo dice que ocurrió una activación de entrada. No dice qué significa esa activación para el usuario. El mismo click puede abrir un menú, confirmar una eliminación, seleccionar una opción, iniciar una carga, enviar un formulario, cerrar un diálogo o navegar a otro destino. Desde el código, todos empiezan igual. Desde la experiencia, no tienen nada que ver.

**PLANO**	**QUÉ REGISTRA**	**EJEMPLO**
**Evento técnico**	Una ocurrencia del sistema o dispositivo	click, submit, change, dragstart
**Evento interactivo**	Una transformación significativa para el usuario	Contacto, consolidación, señal, emergencia
**Interacción semántica**	Una forma recurrente de hacer legible esa transformación	contact, commit, signal, handle, emerge

*Tabla 1 — Tres planos del evento*

Distinción

*Un evento técnico ocurre en el sistema. Un evento interactivo ocurre para el usuario.*

# 4. El evento como transformación del contexto operacional

*Un evento interactivo es una modificación perceptible del contexto operacional que tiene significado para la acción, la atención o la interpretación del estado.*

Esta definición contiene tres condiciones. La primera: una modificación perceptible. Algo debe cambiar en el campo de experiencia. La segunda: relevancia operativa. El cambio debe afectar a lo que el usuario puede hacer, debe atender o necesita interpretar. La tercera: debe pertenecer a una clase reconocible — contacto, consolidación, señal, manipulación, emergencia, cambio de marco, sostenimiento.

Figura 4.2

Un botón que se comprime al ser pulsado comunica contacto. Un switch que cambia de estado comunica consolidación. Un modal que se abre comunica cambio de marco. Un spinner que aparece comunica sostenimiento. Un elemento que desaparece comunica pérdida o retirada. En todos estos casos, lo importante no es que algo cambie en pantalla. Lo importante es que el cambio reorganiza la relación entre usuario y sistema.

# 5. Acción, evento y consecuencia

La acción es lo que hace el usuario o el sistema. El evento es la transformación perceptible que esa acción produce. La consecuencia es lo que cambia después en el contexto operacional.

Figura 4.3

Acción, evento y consecuencia no siempre coinciden en el tiempo. A veces la acción y el evento están muy próximos. A veces la acción inicia un proceso. A veces la consecuencia llega después. A veces el sistema produce un evento sin acción inmediata del usuario: una notificación, una alerta, una sesión expirada.

# 6. Estado y evento: dos formas de sentido

Un estado describe una condición relativamente estable: seleccionado, abierto, cargando, inválido. Un evento describe una transformación: seleccionar, abrir, empezar a cargar, fallar. Los estados orientan. Los eventos explican cómo se llegó a esa orientación. El usuario necesita ambos.

**PLANO**	**PREGUNTA**	**EJEMPLO**	**RIESGO SI FALTA**
**Estado**	¿En qué condición está?	El switch está encendido	No sabe cómo actuar ahora
**Evento**	¿Qué cambio ocurrió?	El switch acaba de activarse	No sabe si su acción tuvo efecto
**Consecuencia**	¿Qué implica?	La preferencia ya se aplicó	No entiende el alcance del cambio

*Tabla 2 — Estado, evento y consecuencia*

Una interfaz centrada solo en estados puede mostrar el resultado final, pero dejar pobremente articulado el cambio que llevó hasta él. Una interfaz centrada solo en eventos puede volverse efímera. La teoría necesita ambos planos.

# 7. El evento tiene forma temporal

Un evento interactivo no es solo una etiqueta. Tiene forma en el tiempo. Algunos son casi puntuales. Otros tienen fase de entrada y salida. Otros son sostenidos. Otros tienen estructura interna compleja.

Figura 4.4

Un contacto se siente como ataque. Una consolidación se siente como asentamiento. Una señal se siente como irrupción. Una emergencia se siente como entrada de presencia. Un cambio de marco se siente como cruce de umbral. Un sostenimiento se siente como continuidad. Una manipulación se siente como trayectoria.

La temporalidad no es decoración. Es parte de la semántica.

# 8. El evento tiene granularidad

Los eventos pueden observarse a distintas escalas. A escala pequeña, un botón responde al contacto. A escala media, una operación se inicia. A escala de flujo, un usuario completa un proceso. La teoría necesita permitir todos los niveles, pero sin mezclarlos.

Conviene distinguir entre *microeventos* (cambios inmediatos), *eventos compuestos* (varias fases), *secuencias semánticas* (encadenamientos de familias distintas) y *consecuencias operativas* (estabilización del nuevo contexto).

Principio

*No todos los eventos tienen el mismo tamaño. Algunos son microeventos; otros son secuencias completas de transformación.*

# 9. El evento tiene origen

Un evento puede estar iniciado por el usuario o por el sistema. Cuando el usuario inicia, la interfaz debe preservar la relación causal entre acción y respuesta. Cuando el sistema inicia, la cuestión principal es atención: el usuario necesita saber por qué algo aparece o por qué se interrumpe el flujo.

**ORIGEN**	**PREGUNTA DEL USUARIO**	**EJEMPLO**	**RIESGO**
**Usuario**	¿Mi acción tuvo efecto?	Pulsar, arrastrar, seleccionar	Pérdida de agencia
**Sistema**	¿Por qué ocurre esto ahora?	Notificación, alerta, sesión expirada	Interrupción o sorpresa
**Mixto**	¿Qué parte depende de mí?	Guardar con validación, subir archivo	Ambigüedad causal

*Tabla 3 — Origen del evento*

# 10. El evento tiene dirección

Algunos eventos son reversibles. Otros no. Algunos abren posibilidades. Otros las cierran. Abrir no significa lo mismo que cerrar. Seleccionar no significa lo mismo que deseleccionar. Eliminar no significa lo mismo que ocultar.

Muchas implementaciones tratan estas parejas como simples reversos animados. Pero perceptivamente eso es insuficiente. Entrar y salir no son la misma narración en sentido contrario.

Figura 4.5

# 11. El evento tiene valencia o estructura

Algunos eventos son evaluables. Comunican algo que puede leerse como bueno, malo, urgente, grave, reparable o perdido. Una confirmación puede ser positiva. Una alerta puede ser amenazante. Un fallo puede exigir corrección.

Otros eventos son estructurales. No comunican por sí mismos una evaluación, sino una reorganización del campo perceptivo: algo aparece, se expande, cambia de plano, desplaza el foco, sostiene una operación.

*Hay eventos que son mensaje. Hay eventos que son marco.*

**TIPO**	**QUÉ HACE**	**EJEMPLO**	**¿ACEPTA INTENT?**
**Evaluable**	Comunica resultado, riesgo, pérdida o logro	Confirmación, alerta, error, eliminación	Sí
**Estructural**	Organiza presencia, foco, marco o continuidad	Abrir, expandir, navegar, sostener	Normalmente no
**Compuesto**	Combina marco y mensaje	Modal de error, wizard con validación	En el mensaje, no en el marco

*Tabla 4 — Eventos evaluables y eventos estructurales*

# 12. El evento puede ser simple o compuesto

Muchos eventos reales no pertenecen a una sola familia de forma pura. Son composiciones. Un modal de confirmación destructiva combina cambio de marco y señal de amenaza. Un drag hacia una papelera combina manipulación y pérdida. Un guardado largo combina contacto, sostenimiento y consolidación.

Figura 4.6

*Un evento compuesto debe poder descomponerse en eventos simples sin perder la unidad de experiencia.*

# 13. El evento tiene huella

Un evento no termina siempre cuando acaba su animación. A veces deja un estado. A veces deja una marca visual. A veces deja una obligación. A veces deja una pérdida. A veces deja una posibilidad nueva.

Conviene distinguir entre *duración expresiva* (el tiempo durante el cual el evento se vuelve perceptible), *estado resultante* (la condición que queda después), *consecuencia operativa* (lo que cambia en el campo de acción) y *huella semántica* (el modo en que el evento sigue importando después de ocurrir).

Principio

*La duración de un evento no equivale a su importancia. Lo decisivo es la consecuencia que deja en el contexto operacional.*

# 14. El evento puede fallar

Un evento falla cuando la transformación que intenta comunicar no llega al usuario con la claridad adecuada. Puede fallar por latencia, por indiferenciación, por exceso, por ambigüedad, por canal único, por incongruencia multicanal o por falsa valencia.

Estos fallos muestran que la semántica no es un lujo. Es una forma de evitar ambigüedad, exceso y pérdida de continuidad. Una interfaz puede funcionar técnicamente y fallar semánticamente: ejecutar la acción correcta y aun así dejar al usuario con la pregunta «*¿qué acaba de pasar exactamente?*»

# 15. Del evento a la interacción semántica

El evento es la transformación significativa. La interacción semántica es la forma recurrente de hacerla legible. El evento de que el sistema ha registrado una acción se hace legible mediante la familia de contacto. El evento de que una decisión ha quedado fijada se hace legible mediante la familia de consolidación. El evento de que el sistema reclama atención se hace legible mediante la familia de señal.

Figura 4.7

# 16. Qué no estamos diciendo

No estamos diciendo que cada microcambio deba convertirse en categoría. No estamos diciendo que toda animación sea un evento. No estamos diciendo que la interfaz deba explicar explícitamente cada transformación. No estamos diciendo que el usuario deba aprender una taxonomía consciente.

*Cuando una transformación afecta a la acción, la atención o la interpretación del estado, la interfaz debería tener una forma consistente de hacerla perceptible. Eso es todo.*

Una gramática del evento no obliga a expresarlo todo con más fuerza. Al contrario, ayuda a decidir qué merece expresión y qué debe permanecer silencioso.

# 17. Síntesis

El evento interactivo es la unidad mínima de cambio significativo en una interfaz. No coincide con el componente, ni con el estado, ni con el evento técnico, ni con el efecto.

**IDEA**	**SÍNTESIS**
**El cambio no basta**	Solo hay evento cuando el cambio importa operativamente
**El efecto no basta**	Una animación o sonido no son semánticos por sí mismos
**El código no basta**	Un evento técnico no define el significado experiencial
**El estado no basta**	El usuario necesita comprender la transformación
**La duración no basta**	La importancia depende de la consecuencia
**La semántica organiza**	Una interacción semántica hace legible una clase de evento

*Tabla de síntesis del capítulo*

El capítulo anterior redefinió la interfaz. Este capítulo ha definido el evento. El siguiente paso será explicar por qué esos eventos necesitan una gramática: un sistema estable de diferencias que permita reconocerlos, componerlos y expresarlos sin depender de decisiones locales aisladas.

La pregunta ya no será solo: *¿qué evento ha ocurrido?* Sino: *¿cómo puede una interfaz hacer que esa clase de evento sea reconocible cada vez que ocurre?*


================================================================================
CAPÍTULO 5 — capitulo5_con_diagramas.docx
================================================================================
CAPÍTULO 5

Por qué una gramática del evento

De la intuición a la estructura

El capítulo anterior nos dejó en un punto delicado. Ya no estamos hablando solo de componentes. Tampoco solo de estados. Hemos empezado a llamar *evento interactivo* a una modificación perceptible del contexto operacional que tiene significado para la acción, la atención o la interpretación del estado.

Esa definición cambia el problema. Si la interfaz no solo muestra cosas, sino que hace perceptibles transformaciones, entonces no basta con preguntarse qué elementos hay en pantalla. Hay que preguntarse qué tipos de cambio ocurren, cómo se distinguen, cómo se repiten y cómo el usuario aprende a reconocerlos.

Si cada una de esas transformaciones se resuelve de forma local, la interfaz puede seguir funcionando, pero su lenguaje queda fragmentado. Cada componente decide cómo responder. Cada pantalla decide cómo animar. Cada equipo decide cuándo usar color, sonido, vibración o silencio. El usuario, entonces, no aprende una estructura común: interpreta caso por caso.

*¿Puede una interfaz tener una gramática de sus eventos?*

# 1. Por qué la palabra gramática

La palabra «gramática» no se usa aquí por adorno. Tampoco pretende trasladar de forma literal la gramática de una lengua natural al diseño de interfaces. Se usa porque necesitamos nombrar algo que las palabras «estilo», «patrón», «efecto», «animación» o «taxonomía» no terminan de cubrir.

Una taxonomía clasifica. Una guía de estilo normaliza la forma. Un patrón resuelve un problema recurrente. Un efecto materializa una respuesta perceptiva concreta. Una gramática, en cambio, define un sistema de diferencias y relaciones que permite producir significado reconocible. No se limita a decir qué unidades existen. También define cómo se distinguen, cómo se combinan, cuándo una forma cambia de sentido, qué variaciones son aceptables y qué combinaciones producen ruido o ambigüedad.

**CONCEPTO**	**QUÉ HACE**	**POR QUÉ NO BASTA**
**Efecto**	Materializa una respuesta perceptiva	Puede existir sin significado estable
**Patrón**	Resuelve un problema recurrente de interacción	Suele estar ligado a casos concretos
**Guía de estilo**	Normaliza la forma visual	No siempre explica el significado del cambio
**Taxonomía**	Clasifica tipos de evento	No define composición, modulación ni canal
**Gramática**	Define diferencias, relaciones y reglas de combinación	Es el nivel necesario para articular eventos como lenguaje

*Tabla 1 — Por qué gramática y no otro concepto*

# 2. Qué define una gramática del evento

La interfaz ya tiene gramáticas parciales. Tiene una gramática visual: jerarquía, contraste, alineación, proximidad. Tiene una gramática de componentes: botones, campos, menús. Tiene una gramática de estados: hover, focus, active, disabled. Pero todavía no suele tener una gramática explícita del evento: una forma sistemática de distinguir entre tocar, fijar, advertir, emerger, cambiar de marco, manipular, sostener, completar o perder.

Definición

*Una gramática del evento es el sistema de diferencias, relaciones y reglas de composición mediante el cual una interfaz hace reconocibles las clases significativas de cambio que ocurren dentro de un contexto operacional.*

Esta definición contiene piezas: diferencias (no todo cambio significa lo mismo), relaciones (los eventos se encadenan y componen), reglas de composición (contacto → sostenimiento → consolidación es una secuencia, no una acumulación de efectos), y reconocimiento (la gramática existe para el usuario, no para el sistema).

No llamamos gramática a esta capa porque queramos hacer una metáfora elegante. La llamamos gramática porque necesitamos algo más que una lista de eventos: necesitamos un sistema que defina diferencias, relaciones, combinaciones, modulaciones y límites de expresión. La palabra gramática aparece, entonces, porque el problema ya no es solo identificar eventos, sino articularlos. Una interfaz necesita distinguirlos, repetirlos con estabilidad, combinarlos en secuencias, modularlos cuando son evaluables, distribuirlos entre canales perceptivos y reducirlos cuando la accesibilidad o el contexto lo exigen. Esa red de distinciones y reglas es lo que este libro llama gramática del evento.

Figura 5.1

# 3. Responder no es suficiente

El usuario pulsa: algo cambia. Envía: aparece un spinner. Falla: el campo se marca en rojo. Desde el punto de vista técnico, hay respuesta. Pero desde el punto de vista perceptivo: *¿qué clase de respuesta es esa?*

Si todo se resuelve con respuestas locales, la interfaz puede funcionar pero no construir lenguaje. El usuario aprende por contexto, pero ese aprendizaje procede de su esfuerzo por reconstruir lo que el sistema no diferencia.

Principio

*Una interfaz no necesita responder más. Necesita responder con diferencias que tengan significado.*

Figura 5.2

# 4. El problema de los efectos aislados

Un efecto aislado responde a una pregunta local: *¿cómo hacemos que esto se note?* Una gramática responde a otra: *¿qué clase de transformación necesita hacerse perceptible aquí?* Si empezamos por el efecto, la interfaz se llena de soluciones agradables pero no coherentes. Si empezamos por el evento, el efecto se convierte en realización de una diferencia previa.

Distinción clave

*Un efecto pregunta: ¿cómo se ve o se siente esto? Una gramática pregunta: ¿qué diferencia debe reconocer el usuario?*

# 5. Tres fallos de una interfaz sin gramática

Indiferenciación: eventos distintos se sienten iguales. Todo resultado positivo es success, todo problema es danger, toda espera es spinner. La interfaz tiene vocabulario, pero es demasiado pequeño para las diferencias que necesita expresar.

Arbitrariedad: el mismo tipo de evento se expresa de formas distintas según el lugar. Una selección rebota en una pantalla, cambia solo de color en otra. La gramática permite variación sin perder identidad.

Capricho: estímulos sin necesidad semántica. Una animación porque «da vida», un sonido porque «queda premium». Cada estímulo que no aporta significado añade ruido. Una gramática no solo dice cómo expresar; también ayuda a decidir cuándo callar.

Figura 5.3

# 6. Gramática y economía cognitiva

Cada vez que la interfaz cambia, el usuario responde a preguntas: ¿qué cambió? ¿lo causé yo? ¿sigue ocurriendo? ¿terminó? ¿es bueno o malo? ¿debo actuar? La gramática no elimina trabajo cognitivo. Lo distribuye mejor.

**SIN GRAMÁTICA**	**CON GRAMÁTICA**
El usuario interpreta cada cambio por contexto	El usuario reconoce familias de cambio
Los efectos son soluciones locales	Los efectos expresan eventos identificables
El color carga con demasiada semántica	La semántica se distribuye entre canales
La accesibilidad elimina señales sin reemplazo	La carga semántica puede migrar entre canales

*Tabla 2 — Qué reduce una gramática del evento*

# 7. De la consistencia visual a la consistencia semántica

La consistencia visual responde a: *¿esto pertenece al mismo sistema formal?* La consistencia semántica responde a otra: *¿esto pertenece a la misma clase de evento?* Un sistema puede ser visualmente consistente y semánticamente pobre: paleta impecable, componentes bien construidos, pero eventos indiferenciados.

Figura 5.4

# 8. Los niveles de la gramática

Cinco niveles que no deben mezclarse: la familia (qué clase de evento), el verbo (qué ocurre concretamente), la fase (en qué momento temporal), el intent (cómo se evalúa si es evaluable) y la realización (cómo se expresa por canales concretos).

Si mezclamos familia y efecto, acabamos diciendo «este evento es un bounce». Si mezclamos intent y color, «esto es rojo». Si mezclamos evento técnico y semántica, «esto es un click». Separar niveles permite pensar mejor.

Figura 5.5

# 9. Composición y proporción

Los eventos reales rara vez aparecen aislados. Un guardado largo contiene contacto, sostenimiento y consolidación. Una eliminación contiene contacto, señal de amenaza, cambio de marco y pérdida. Sin gramática, son acumulación de efectos. Con gramática, cada parte tiene función.

Además, no todas las diferencias merecen la misma intensidad. Si cada guardado automático se celebra como culminación, la recompensa se desgasta. Si cada validación fallida se trata como amenaza, la interfaz fatiga.

Principio

*La intensidad de una señal debe ser proporcional a la consecuencia perceptiva del evento.*

**EVENTO**	**CONSECUENCIA**	**INTENSIDAD RECOMENDABLE**
**Contacto común**	Baja, inmediata	Mínima y breve
**Autoguardado**	Positiva leve	Confirmación suave
**Operación larga completada**	Positiva con tensión previa	Resolución más expresiva
**Eliminación irreversible**	Alta consecuencia	Señal grave, no necesariamente ruidosa
**Amenaza activa**	Urgencia alta	Máxima claridad

*Tabla 3 — Proporción semántica*

# 10. La gramática debe ser multicanal

Si todo depende del color, falla ante daltonismo. Si todo depende del motion, falla ante reducción de movimiento. La gramática debe distribuir significado de forma que el evento tenga identidad que sobreviva a la reducción de un canal.

*La accesibilidad no solo elimina canales; obliga a redistribuir significado.*

Figura 5.6

# 11. La gramática debe admitir silencio

No todo contacto necesita sonido. No toda selección necesita celebración. No toda espera necesita animación constante. Un efecto agradable una vez puede volverse insoportable al repetirse cien veces al día.

Principio

*Una gramática perceptiva no consiste en expresar siempre más, sino en saber cuándo una señal debe permanecer mínima o incluso silenciosa.*

# 12. Gramática no significa rigidez

Una gramática no elimina estilo. Lo hace más responsable. Un sistema financiero, una herramienta creativa y un editor de código no deberían sonar igual. Pero si pertenecen a la misma familia de evento, deberían conservar relación reconocible con esa familia. La gramática no fija una única forma. Fija una relación entre significado y expresión.

# 13. Gramática y aprendizaje implícito

El usuario no debe aprender la gramática explícitamente. Funciona por familiaridad, por recurrencia, por diferencia sensible. El aprendizaje implícito requiere suficiente regularidad para reconocer y suficiente elasticidad para adaptarse.

**CONDICIÓN**	**QUÉ APORTA**
**Recurrencia**	El patrón aparece suficientes veces
**Diferenciación**	No se confunde con otros eventos
**Estabilidad**	Conserva núcleo semántico
**Proporción**	La intensidad coincide con la importancia
**Multicanalidad**	Puede sobrevivir a cambios de canal
**Sobriedad**	No fatiga por repetición

*Tabla 4 — Condiciones del aprendizaje implícito*

# 14. La gramática como herramienta para programadores

Programar interfaces implica tomar decisiones sin nombre claro. ¿Este click confirma contacto o fija estado? ¿Este open revela contenido o cambia de marco? ¿Este drag manipula, reordena o elimina? Sin gramática, se resuelve con lógica local. Con gramática, se separan los niveles.

Figura 5.7

# 15. Lo que una gramática debe responder

**PREGUNTA**	**RESPUESTA QUE BUSCA**
**¿Qué clase de evento es?**	Familia semántica
**¿Qué ocurrió concretamente?**	Verbo o variante
**¿En qué momento está?**	Fase temporal
**¿Es evaluable?**	Posibilidad de intent
**¿Qué canales participan?**	Realización multicanal
**¿Qué intensidad merece?**	Proporción
**¿Qué pasa si un canal falta?**	Migración semántica
**¿Con qué otros eventos se compone?**	Secuencia o composición

*Tabla 5 — Preguntas mínimas de una gramática del evento*

# 16. Qué no estamos diciendo

No estamos diciendo que todas las interfaces necesiten una gramática explícita con nombres técnicos. No estamos diciendo que cada evento deba disparar motion, sonido o háptica. No estamos diciendo que la gramática deba ser idéntica en todos los productos.

*Si una interfaz produce transformaciones significativas de forma recurrente, necesita una manera consistente de hacerlas perceptibles.*

# 17. Síntesis

*Una interfaz madura no solo necesita componentes consistentes. Necesita eventos consistentes.*

**DISTINCIÓN**	**POR QUÉ IMPORTA**
**Efecto y evento**	El efecto es medio; el evento es significado
**Estado y transformación**	El usuario necesita saber qué cambió
**Marco y mensaje**	No todo evento acepta intent
**Canal y significado**	Ningún canal agota la semántica
**Intensidad y consecuencia**	No todo merece la misma energía
**Silencio y ausencia**	No expresar también puede ser decisión semántica

*Tabla de síntesis del capítulo*

El siguiente paso será definir con más precisión la unidad que articula esa consistencia: la *interacción semántica* como configuración perceptiva recurrente que hace legible una clase de evento dentro de un contexto operacional.


================================================================================
CAPÍTULO 6 — capitulo6_con_diagramas.docx
================================================================================
CAPÍTULO 6

Qué es una interacción semántica

La forma perceptiva recurrente de un evento

Los capítulos anteriores han preparado el terreno. Primero redefinimos la interfaz como *dimensión perceptible de un contexto operacional*. Después introdujimos el *evento interactivo* como unidad mínima de cambio significativo. Explicamos por qué las convenciones heredadas no han formulado antes estas preguntas. Y desarrollamos por qué esos eventos necesitan una gramática.

Ahora aparece la pregunta central de este capítulo:

*Una interacción semántica es una configuración perceptiva recurrente mediante la cual una interfaz hace legible una clase de evento dentro de un contexto operacional.*

# 1. Por qué necesitamos otro término

Un componente nombra una unidad estructural. Un estado nombra una condición estable. Un evento técnico nombra una ocurrencia del sistema. Un efecto nombra una realización perceptiva. Un patrón nombra una solución recurrente. Un intent nombra el tono evaluativo. Pero entre todo eso falta una capa: la unidad que puede decir *esto es una clase de evento que la interfaz necesita hacer reconocible*.

La interacción semántica nombra la capa donde componentes, estados, efectos y colores se organizan alrededor de un significado operativo.

**TÉRMINO**	**QUÉ NOMBRA**	**POR QUÉ NO BASTA**
**Componente**	Una unidad estructural	No dice qué evento ocurre
**Estado**	Una condición estable	No explica la transformación
**Evento técnico**	Una ocurrencia del sistema	No contiene significado experiencial
**Efecto**	Una realización perceptiva	Puede existir sin semántica
**Patrón**	Una solución recurrente	Puede contener varias semánticas
**Intent**	Tono evaluativo	No define la clase de evento
**Interacción semántica**	Forma recurrente de hacer legible un evento	Articula significado y percepción

*Tabla 1 — Por qué no basta con los términos existentes*

Figura 6.1

# 2. Definición de interacción semántica

La definición contiene cinco partes: configuración perceptiva (puede incluir movimiento, color, sonido, presencia, háptica), recurrente (debe poder reaparecer en distintos componentes y situaciones), hace legible (su función es reducir ambigüedad), una clase de evento (contacto, consolidación, señal, manipulación, emergencia, cambio de marco, sostenimiento) y dentro de un contexto operacional (el significado no existe en abstracto).

Definición

*Interacción semántica: configuración perceptiva recurrente que hace reconocible una clase de evento interactivo dentro de un contexto operacional.*

# 3. No es una interacción concreta

El mismo gesto puede pertenecer a semánticas distintas. Un click puede ser contacto, confirmación, navegación, advertencia, pérdida, apertura, cierre o selección. La interacción concreta es la superficie gestual. La interacción semántica es la lectura significativa de lo que ocurre.

**INTERACCIÓN CONCRETA**	**PUEDE SIGNIFICAR**	**SEMÁNTICA POSIBLE**
**Pulsar botón**	El sistema registró mi gesto	Contacto
**Pulsar botón**	La acción quedó confirmada	Consolidación
**Pulsar botón**	Se abre una superficie	Emergencia
**Pulsar botón**	Entro en otro flujo	Cambio de marco
**Pulsar botón**	Pierdo un recurso	Pérdida / commit
**Arrastrar elemento**	Lo estoy moviendo	Manipulación

*Tabla 2 — Un mismo gesto, múltiples semánticas posibles*

# 4. No es una animación

Un bounce puede expresar selección, culminación, encaje o celebración. Un fade puede expresar aparición, retirada, pérdida o simple suavizado. La animación es ambigua hasta que se integra en una gramática. El orden correcto no es: *tenemos un bounce → ¿qué significa?* Sino: *necesitamos expresar consolidación → ¿qué configuración perceptiva la hace legible?*

Distinción clave

*La animación pertenece al plano de la realización. La interacción semántica pertenece al plano del significado operativo.*

Figura 6.2

# 5. No es un componente

La semántica de contacto puede aparecer en un botón, un icon button, una tarjeta clicable, un slider thumb o un control de reproducción. La consolidación puede aparecer en un switch, un checkbox, un chip, un filtro. La señal puede aparecer en un toast, un banner, un badge, un error inline. Si una categoría depende de un componente concreto, todavía no es una interacción semántica en sentido fuerte.

Figura 6.3

# 6. No es un patrón de diseño

Un modal de confirmación destructiva puede contener cambio de marco, señal de amenaza, consolidación y pérdida. Un toast puede contener señal con intent de riesgo, confirmación o pérdida. El patrón organiza una solución de interfaz. La semántica organiza el significado perceptivo de los eventos que ocurren dentro.

Figura 6.4

# 7. No es un intent

La semántica responde a *¿qué clase de evento ocurre?* El intent responde a *¿cómo debe evaluarse afectivamente?* No es lo mismo commit + fulfill, signal + fulfill y contact + affirm. En todos hay valencia positiva, pero no el mismo evento. El intent colorea o modula la semántica. No la sustituye.

**PREGUNTA**	**PERTENECE A**	**EJEMPLO**
**¿Qué clase de evento ocurre?**	Semántica	Contacto, señal, consolidación, emergencia
**¿Qué ocurrió concretamente?**	Verbo	Guardar, eliminar, abrir, seleccionar
**¿En qué fase está?**	Fase	Enter, exit, start, progress, drop
**¿Cómo se evalúa?**	Intent	Neutral, affirm, fulfill, risk, threat, loss
**¿Cómo se expresa?**	Canales	Motion, sonido, color, presencia, háptica

*Tabla 3 — Semántica e intent no son lo mismo*

# 8. La interacción semántica como unidad de articulación

Articula tres planos: el evento que ocurre, el significado operativo que ese evento tiene, y la forma perceptiva que permite reconocerlo. Si nos quedamos demasiado arriba, solo tenemos conceptos abstractos. Si bajamos demasiado pronto, solo tenemos recursos. La interacción semántica conecta ambas capas.

Figura 6.5

# 9. Toda interacción semántica responde a una pregunta perceptiva

Una semántica merece existir cuando responde a una pregunta que aparece una y otra vez en la interacción. No porque sea bonita ni porque encaje en un framework, sino porque el usuario necesita resolver esa diferencia para actuar con claridad.

**PREGUNTA PERCEPTIVA**	**FAMILIA SEMÁNTICA**
**¿El sistema ha sentido mi acción?**	Contacto / contact
**¿Esto ha quedado fijado?**	Consolidación / commit
**¿Algo reclama mi atención?**	Señal / signal
**¿Estoy controlando este objeto?**	Manipulación / handle
**¿Algo ha aparecido o desaparecido?**	Emergencia / emerge
**¿Ha cambiado el marco operativo?**	Cambio de marco / shift
**¿Esto sigue ocurriendo?**	Sostenimiento / sustain

*Tabla 4 — Preguntas perceptivas y familias semánticas*

# 10. Tiene una firma, no una receta

Una receta fija valores: duración 180ms, scale 0.97, frecuencia 2600 Hz. Una firma semántica dice algo más abstracto: breve, inmediata, proporcional, causalmente ligada a la acción, con baja persistencia. La receta puede cambiar. La firma debe permanecer.

Distinción clave

*Una receta fija valores. Una firma conserva identidad bajo variación.*

# 11. Puede realizarse por varios canales

Si el usuario reduce motion, la semántica no debería desaparecer. Si el sonido está desactivado, la información no debería perderse. La interacción semántica es lo que permite esa migración: sabemos qué significado debía transportarse, así que podemos redistribuirlo.

Figura 6.6

# 12. Tiene estructura temporal

**SEMÁNTICA**	**FORMA TEMPORAL**	**LECTURA**
**Contacto**	Puntual	«me ha sentido»
**Consolidación**	Breve + resolutiva	«esto quedó fijado»
**Señal**	Entrada + posible persistencia	«atiende esto»
**Emergencia**	Entrada / salida	«algo entra o sale del campo»
**Cambio de marco**	Cruce de umbral	«ahora estás en otro régimen»
**Manipulación**	Pick / carry / drop	«lo agarro, lo muevo, lo coloco»
**Sostenimiento**	Inicio / continuidad / fin	«sigue ocurriendo»

*Tabla 5 — Formas temporales de las semánticas*

# 13. Puede componerse con otras semánticas

Un guardado largo: contacto → sostenimiento → consolidación. Una eliminación: contacto → señal de amenaza → cambio de marco → pérdida. Un drag a papelera: manipulación → señal de destino → pérdida. La gramática permite asignar cada función a su lugar.

Figura 6.7

# 14. Tiene fronteras

**NO CONFUNDIR**	**DIFERENCIA**
**Contacto / consolidación**	Registrar gesto no es fijar estado
**Emergencia / señal**	Aparecer no es reclamar atención
**Emergencia / cambio de marco**	Entrar en campo no es cambiar régimen
**Sostenimiento / culminación**	Seguir ocurriendo no es haber terminado
**Ocultación / pérdida**	Retirar de la vista no es destruir
**Intent / semántica**	El tono evaluativo no define el tipo de evento

*Tabla 6 — Fronteras semánticas importantes*

# 15. Requiere estabilidad y elasticidad

La estabilidad está en el núcleo: qué pregunta responde, qué tipo de evento hace legible, qué forma temporal tiene. La elasticidad está en la realización: duración, intensidad, estilo, tema, plataforma, accesibilidad.

Principio

*La identidad de una interacción semántica no está en repetir siempre la misma forma, sino en conservar la misma función perceptiva bajo variaciones controladas.*

# 16. Puede ser mínima

A veces será casi invisible. A veces una latencia ajustada. A veces una microcompresión. A veces un silencio deliberado. Cuanto más frecuente es un evento, más sobria debe ser su expresión.

Principio

*Semántico no significa intenso. Significa proporcional, reconocible y necesario.*

# 17. Cómo saber si algo merece ser interacción semántica

**CONDICIÓN**	**PREGUNTA**
**Recurrencia**	¿Aparece en muchos contextos?
**Relevancia operativa**	¿Afecta a acción, atención o estado?
**Diferenciabilidad**	¿Se distingue de otras semánticas?
**Estabilidad**	¿Puede aprenderse?
**Multicanalidad**	¿Puede expresarse por más de un canal?
**Economía cognitiva**	¿Ayuda a comprender mejor?
**Proporción**	¿Su intensidad corresponde a su consecuencia?

*Tabla 7 — Condiciones mínimas de una interacción semántica*

*Una interacción semántica no se declara; se justifica.*

# 18. Ejemplo: selección

El usuario marca una opción. Desde la implementación: click, state.selected = true, class="selected". Desde la experiencia: *una decisión del usuario queda fijada*. La selección no es mero contacto. Comunica «esto queda elegido». Si usamos la misma respuesta que para un botón cualquiera, el usuario siente que tocó pero no necesariamente que eligió.

# 19. Ejemplo: notificación

Un toast aparece, un badge cambia, un banner se muestra. La semántica no es «toast» — toast es un patrón. La semántica es señal: el sistema inicia comunicación y reclama cierto grado de atención. El intent modula: neutra si informa, riesgo si advierte, amenaza si exige reacción, pérdida si registra algo consumado.

# 20. Ejemplo: manipulación

Arrastrar un elemento no es solo pulsar y mover. Es una experiencia continua con fases: pick, carry, drop. En el pick, el objeto cambia de régimen. En el carry, conserva continuidad con el gesto. En el drop, el resultado se evalúa. La evaluación se concentra en el drop. El carry debe permanecer neutro.

Figura 6.8

# 21. Lo que una interacción semántica debe especificar

**CAMPO**	**PREGUNTA**
**Qué comunica**	¿Qué tipo de evento vuelve legible?
**Pregunta perceptiva**	¿Qué necesita resolver el usuario?
**Fronteras**	¿Con qué no debe confundirse?
**Temporalidad**	¿Cómo ocupa el tiempo?
**Origen**	¿Responde al usuario o parte del sistema?
**Intent**	¿Es evaluable o estructural?
**Canales**	¿Por dónde se expresa mejor?
**Accesibilidad**	¿Cómo migra si un canal falta?
**Proporción**	¿Cuánta energía merece?
**Errores**	¿Cómo suele fallar?

*Tabla 8 — Ficha mínima de una interacción semántica*

# 22. Qué no estamos diciendo

*Cuando una clase de evento aparece de forma recurrente y afecta a la acción, la atención o la interpretación del estado, la interfaz necesita una forma consistente de hacerla reconocible. A esa forma consistente la llamamos interacción semántica.*

# 23. Síntesis

**CONCEPTO**	**QUÉ RESPONDE**
**Componente**	¿Qué elemento participa?
**Evento técnico**	¿Qué ocurrió en el sistema?
**Evento interactivo**	¿Qué transformación percibe el usuario?
**Interacción semántica**	¿Cómo se hace reconocible esa clase de transformación?
**Intent**	¿Cómo se evalúa afectivamente, si procede?
**Realización**	¿Por qué canales se expresa?

*Tabla 9 — Qué responde cada capa*

*Una interfaz no solo necesita componentes reutilizables. Necesita formas recurrentes de hacer legibles sus eventos.*

El siguiente capítulo desarrollará los criterios para decidir cuándo una diferencia merece convertirse en interacción semántica. Porque no todo cambio necesita nombre propio. Pero los cambios que organizan la experiencia sí.


================================================================================
CAPÍTULO 7 — capitulo7_con_diagramas.docx
================================================================================
CAPÍTULO 7

Criterios para identificar una interacción semántica

Cuándo una diferencia merece convertirse en lenguaje

Si una interacción semántica es una forma recurrente de hacer legible una clase de evento, necesitamos decidir qué diferencias merecen convertirse en semánticas y cuáles no. Si distinguimos demasiado poco, la interfaz se empobrece. Si distinguimos demasiado, la gramática se vuelve opaca.

Figura 7.1

# 1. El riesgo de declarar semánticas por intuición

Una semántica no se justifica porque podamos nombrarla. Se justifica porque nombra una diferencia que el usuario necesita reconocer de forma recurrente para actuar con claridad.

Principio

*Una interacción semántica no existe porque tenga nombre. Existe cuando nombra una diferencia que el usuario necesita percibir.*

# 2. Criterio 1: relevancia operativa

Una diferencia merece convertirse en semántica si afecta a la acción, a la atención o a la interpretación del estado. Una semántica no debería nacer de una variación estética, sino de una diferencia operativa.

# 3. Criterio 2: recurrencia estructural

Una interacción semántica debe corresponder a una clase de evento que reaparece en distintos lugares, componentes o situaciones. Si solo ocurre en un caso específico, puede resolverse como comportamiento local.

Figura 7.2

# 4. Criterio 3: diferenciabilidad perceptiva

No basta con que internamente sepamos que dos eventos son distintos. El usuario debe poder percibir esa diferencia. Contacto no debería sentirse igual que consolidación. Aparición no debería sentirse igual que señal. Cambio de marco no debería sentirse igual que expansión.

Principio

*Una diferencia que no puede percibirse todavía no funciona como diferencia semántica.*

Figura 7.3

# 5. Criterio 4: estabilidad de significado

Una semántica debe conservar su significado a través de distintas realizaciones. Si solo existe cuando usamos una animación concreta, no es todavía una semántica fuerte. Es un efecto. La semántica de contacto puede expresarse con microcompresión visual en web, pulso háptico en móvil, sonido breve sin motion o cambio de foco visible. La realización cambia; el significado permanece.

# 6. Criterio 5: elasticidad de realización

Una interfaz bancaria, una aplicación médica, una herramienta creativa y un editor de código no deberían expresar igual sus eventos. Pero si pertenecen a la misma familia de evento, deberían conservar relación reconocible con esa familia.

Figura 7.4

# 7. Criterio 6: economía cognitiva

Una interacción semántica debe reducir carga interpretativa. Si una categoría nueva obliga a pensar más, recordar más o diferenciar matices irrelevantes, probablemente no merece existir. La pregunta: *¿esta semántica ayuda al usuario a interpretar mejor el evento o solo satisface nuestra necesidad interna de clasificar?*

# 8. Criterio 7: transversalidad

Si una supuesta semántica solo existe dentro de un componente concreto, quizá no estamos ante una semántica sino ante un patrón local. La transversalidad es lo que convierte una respuesta en lenguaje del sistema.

Figura 7.5

# 9. Criterio 8: compatibilidad multicanal

Una semántica no debería depender exclusivamente de un único canal. Si se reduce motion, parte del significado puede migrar a color, forma, texto o sonido. Si el color no es fiable, la forma, el texto, la posición o el icono deben sostener la diferencia.

Principio

*Una semántica no debería vivir en un canal. Debería poder viajar entre canales sin perder su función.*

# 10. Criterio 9: capacidad de composición

Las interacciones semánticas no aparecen siempre aisladas. Una categoría merece entrar en la gramática si puede componerse con otras sin generar ambigüedad. Esto exige fronteras claras.

Figura 7.6

# 11. Criterio 10: proporción expresiva

Si todo suena, nada importa. Si todo vibra, la háptica se vuelve ruido. Si todo rebota, la confirmación pierde valor. La proporción expresiva pregunta: *¿cuánta energía perceptiva merece este evento?*

**EVENTO**	**CONSECUENCIA**	**FRECUENCIA**	**INTENSIDAD**
**Contacto cotidiano**	Baja	Alta	Mínima
**Autoguardado**	Baja positiva	Alta	Confirmación suave
**Operación completada**	Media-alta	Baja	Resolución perceptible
**Amenaza activa**	Alta	Baja	Interrupción justificada
**Pérdida consumada**	Alta, ya ocurrida	Baja	Gravedad sin alarma

*Tabla 1 — Proporción expresiva*

# 12. Criterio 11: asimetría significativa

Abrir no significa lo mismo que cerrar. Seleccionar no significa lo mismo que deseleccionar. Eliminar no significa lo mismo que restaurar. La asimetría es especialmente clara en semánticas como handle, donde pick, carry y drop no son fases equivalentes.

Principio

*Una salida no es siempre una entrada invertida. Puede tener otro significado, otra energía y otra consecuencia.*

# 13. Criterio 12: sobriedad y silencio

No todo contacto necesita sonido. No toda confirmación necesita celebración. No toda espera necesita animación constante. Un sonido agradable una vez puede volverse insoportable cincuenta veces al día.

Figura 7.7

# 14. Criterio 13: posibilidad de validación

Si una semántica está bien definida, deberíamos poder comprobar si ayuda. Si retrasamos el contacto, debería disminuir la sensación de agencia. Si usamos la misma firma para contacto y consolidación, deberían aumentar las dudas sobre si el estado quedó fijado. La validación convierte la semántica en hipótesis de diseño, no en opinión estética.

# 15. Criterio 14: compatibilidad con accesibilidad

Si la semántica desaparece al quitar un canal, era demasiado frágil. Un error no puede depender solo del rojo. Una alerta no puede depender solo del sonido. Una manipulación no puede depender solo de sombra si el contraste es pobre.

Principio

*La accesibilidad no solo adapta la interfaz. Revela si la semántica estaba bien distribuida.*

# 16. Matriz de decisión

**CRITERIO**	**PREGUNTA**	**SI LA RESPUESTA ES NO…**
**Relevancia**	¿Afecta a acción, atención o estado?	Es variación local
**Recurrencia**	¿Aparece en distintos contextos?	Es caso específico
**Diferenciabilidad**	¿Se distingue perceptivamente?	Se fusiona con otra
**Estabilidad**	¿Mantiene significado bajo variación?	Es receta o efecto
**Elasticidad**	¿Puede adaptarse a plataformas?	Es demasiado rígida
**Economía**	¿Reduce ambigüedad?	Añade ruido taxonómico
**Transversalidad**	¿Atraviesa componentes?	Es patrón local
**Multicanalidad**	¿Puede migrar entre canales?	Es frágil
**Composición**	¿Se combina sin confusión?	Necesita mejores fronteras
**Proporción**	¿Intensidad corresponde al evento?	Puede fatigar o trivializar
**Sobriedad**	¿Sabe cuándo callar?	Puede sobreestimular
**Validación**	¿Produce predicciones observables?	Es opinión difícil de evaluar
**Accesibilidad**	¿Sobrevive a reducción de canal?	No está completa

*Tabla 2 — Matriz para aceptar una interacción semántica*

# 17. Tres ejemplos

Selection: sí merece semántica, como commit.select. Fija estado persistente, tiene recurrencia alta, se diferencia de contacto, acepta intent.

Hover: no como semántica propia. Estado de disponibilidad con relevancia operativa limitada, salvo que revele evento.

Manipulation: sí, como handle. Evento continuo irreducible con estructura pick/carry/drop, alta transversalidad y multicanalidad.

Figura 7.8

# 18. Qué no estamos diciendo

*Una diferencia debe convertirse en interacción semántica solo cuando ayuda de forma recurrente, perceptible y proporcional a comprender un evento operativo.*

# 19. Síntesis

**CRITERIO**	**FUNCIÓN**
**Relevancia operativa**	Asegura que la diferencia importa
**Recurrencia**	Evita categorías demasiado locales
**Diferenciabilidad**	Garantiza que pueda percibirse
**Estabilidad**	Permite aprendizaje
**Elasticidad**	Permite adaptación
**Economía cognitiva**	Evita ruido taxonómico
**Transversalidad**	Separa semántica de componente
**Multicanalidad**	Evita fragilidad de canal único
**Composición**	Permite secuencias complejas
**Proporción**	Calibra intensidad
**Sobriedad**	Permite callar
**Validación**	Convierte la semántica en hipótesis comprobable
**Accesibilidad**	Asegura distribución robusta del significado

*Tabla 3 — Síntesis de criterios*

*Una interacción semántica no se acepta porque sea posible. Se acepta porque es necesaria.*

El siguiente capítulo dará el paso que estos criterios preparan: ¿qué familias de evento sobreviven a estos criterios y merecen formar parte de la gramática fundamental de la interfaz?


================================================================================
CAPÍTULO 8 — capitulo8_con_diagramas.docx
================================================================================
CAPÍTULO 8

De las clases de evento a las familias semánticas

Cómo reducir sin empobrecer

Los capítulos anteriores han construido ya las piezas necesarias. Este capítulo aplica los criterios del capítulo anterior. La pregunta ya no es qué es una interacción semántica, sino: *¿qué familias de evento sobreviven cuando aplicamos esos criterios?*

La respuesta que propone este libro es una reducción desde un campo exploratorio amplio hacia siete familias fundamentales: contact, commit, signal, handle, emerge, shift, sustain. Esta reducción no busca empobrecer el sistema. Busca conservar las diferencias esenciales sin convertir cada matiz en categoría raíz.

Estas familias no son categorías de diseño. Son categorías perceptivas.

Cada una se apoya en una forma distinta de organizar la experiencia: contact se apoya en agencia y causalidad inmediata; commit en cierre cognitivo y memoria de estado; signal en atención y saliencia; handle en acción corporal y manipulación; emerge en figura/fondo y presencia; shift en cambio de marco cognitivo; sustain en continuidad temporal y reducción de incertidumbre.

PRINCIPIO

Las familias no salen de componentes. Salen de preguntas perceptivas recurrentes.

Figura 8.1

# 1. De una lista exploratoria a una gramática manejable

En los primeros borradores aparecía una lista amplia de trece semánticas. Esa lista cumplió una función necesaria: abrir el campo y mostrar que la interfaz contiene tipos de cambio muy distintos. Pero una lista exploratoria no es todavía una gramática madura. La reducción debe hacerse separando niveles: no todo debe ser familia. Algunas diferencias pertenecen al verbo, a la fase, al intent o a la realización.

**NIVEL**	**PREGUNTA**	**EJEMPLO**
**Familia**	¿Qué clase perceptiva de evento es?	contact, commit, signal
**Verbo**	¿Qué ocurrió concretamente?	select, delete, notify, expand
**Fase**	¿En qué momento temporal está?	enter, exit, pick, carry, drop
**Intent**	¿Cómo se evalúa, si procede?	neutral, affirm, fulfill, risk, threat, loss
**Realización**	¿Por qué canales se expresa?	motion, sonido, color, presencia, háptica

*Tabla 1 — Niveles de la gramática*

Figura 8.2

# 2. Las siete preguntas fundamentales

Aplicando los criterios aparece una estructura compacta de siete preguntas perceptivas. No son preguntas que el usuario formule verbalmente. Son preguntas operativas que la interfaz debe responder.

*Las familias semánticas no forman una jerarquía moral. Distinguen funciones perceptivas.*

Figura 8.3

# 3. Las siete familias fundamentales

**3.1. contact**

Comunica que una acción directa del usuario ha sido registrada. *¿El sistema ha sentido mi acción?* No comunica todavía resultado ni estado persistente. Comunica acoplamiento acción-respuesta. Aquí se reubica la antigua semántica feedback. Ejemplos: contact.press, contact.release, contact.activate.

**3.2. commit**

Comunica que algo ha quedado fijado, resuelto o establecido. *¿Esto ha quedado fijado?* Aquí entran selección, confirmación, guardado, cancelación, fallo, eliminación, restauración, culminación o pérdida consumada. Es una de las familias más claramente evaluables.

**3.3. signal**

Comunica que el sistema inicia una señal para orientar la atención. *¿Algo reclama mi atención?* No todas las señales son alertas. También hay anuncios, recordatorios, hints, badges y énfasis. Acepta intent plenamente.

**3.4. handle**

Comunica manipulación directa de un objeto. *¿Estoy controlando directamente este objeto?* Tiene estructura temporal propia: pick → carry → drop. El carry es estructural y neutro. La evaluación aparece sobre todo en el drop.

**3.5. emerge**

Comunica aparición, retirada o disponibilidad en el campo perceptivo. *¿Algo ha entrado o salido del campo?* Normalmente no acepta intent. Una aparición no es buena o mala por aparecer. Lo evaluable puede estar dentro de lo que aparece.

**3.6. shift**

Comunica cambio de marco operativo. *¿Sigo en el mismo marco o ha cambiado el régimen?* Cambiar de vista, de modo, avanzar en un wizard o entrar en edición reorganiza el marco desde el que se interpreta la interfaz. Normalmente no acepta intent.

**3.7. sustain**

Comunica continuidad operativa. *¿Esto sigue ocurriendo?* No comunica resultado. Comunica que una operación sigue viva. Si un proceso se vuelve problemático, lo más limpio es componer sustain.progress con signal.warn + risk, en lugar de convertir todo el proceso en evento evaluativo.

**FAMILIA**	**PREGUNTA**	**QUÉ COMUNICA**	**TEMPORALIDAD**	**INTENT**
**contact**	¿me ha sentido?	Registro de acción	Puntual	Leve
**commit**	¿quedó fijado?	Estado o consecuencia	Resolutiva	Sí
**signal**	¿debo atender?	Mensaje del sistema	Entrada + persist.	Sí
**handle**	¿lo controlo?	Manipulación directa	pick/carry/drop	En drop
**emerge**	¿apareció?	Presencia/disponibilidad	enter/exit	Normalmente no
**shift**	¿cambió el marco?	Cambio de régimen	leave/arrive	Normalmente no
**sustain**	¿sigue?	Continuidad de proceso	start/progress/end	Normalmente no

*Tabla 2 — Las siete familias fundamentales*

# 4. Lo que se pierde y lo que se conserva

La reducción no elimina las semánticas exploratorias. Las reubica.

**SEMÁNTICA EXPLORATORIA**	**REUBICACIÓN EN FAMILIAS**
**feedback**	contact
**selection**	commit.select
**completion**	commit.complete + fulfill
**destruction**	commit.delete + loss
**notification**	signal.notify
**attention**	signal.alert / signal.warn
**emphasis**	signal.emphasize
**revelation**	emerge.reveal
**expansion**	emerge.expand
**context**	shift si cambia marco; emerge si solo aparece superficie
**navigation**	shift.navigate
**persistence**	sustain
**manipulation**	handle.pick / carry / drop

*Tabla 3 — Reubicación de las semánticas exploratorias*

# 5. Tres casos difíciles

**5.1. El caso context**

Cuando algo aparece sin cambiar profundamente el régimen operativo, estamos cerca de emerge. Cuando reorganiza el foco, bloquea el fondo o impone un nuevo régimen, estamos en shift. Un tooltip es emerge. Un modal bloqueante es shift. La pregunta: *¿solo aparece algo o cambia el régimen de operación?*

Figura 8.4

**5.2. El caso signal**

Las tres semánticas previas (notification, attention, emphasis) comparten una función profunda: el sistema intenta modificar la atención del usuario. Lo que cambia es la intensidad, el tono, la persistencia y el intent. La familia es la misma: signal. La variación ocurre por verbo, prioridad e intent.

**5.3. El caso commit**

Commit no significa «guardar». Significa que algo queda fijado en el contexto operacional. Aquí conviene anticipar una distinción importante: threat comunica que algo está en peligro o exige reacción inmediata. loss comunica que algo ya se perdió. No son el mismo estado afectivo. Una amenaza todavía convoca acción. Una pérdida consumada registra consecuencia. Tratar una pérdida como amenaza comunica urgencia donde ya no hay nada que evitar.

Figura 8.5

# 6. Familias e intents

Las familias dicen *qué tipo de evento ocurre*. Los intents dicen *cómo se evalúa afectivamente*, cuando el evento es evaluable. La lista de intents:

**INTENT**	**FUNCIÓN**
**neutral**	Operación sin juicio afectivo específico
**affirm**	Confirmación positiva leve
**fulfill**	Resolución positiva de una tensión u objetivo
**risk**	Problema corregible, sin urgencia extrema
**threat**	Amenaza activa, requiere atención o acción inmediata
**loss**	Pérdida consumada, algo ya dejó de estar disponible

*Tabla 4 — Los seis intents*

No todas las familias aceptan intent. Emerge, shift y sustain normalmente no. Contact puede aceptar modulación leve. Commit y signal lo aceptan plenamente. Handle lo acepta sobre todo en drop.

*El intent modula eventos evaluables, no eventos cuya función es estructurar el campo perceptivo.*

# 7. Ejemplo narrativo: eliminar una tarea

Imaginemos una aplicación de gestión de proyectos. El usuario ve una tarea con archivos adjuntos y comentarios. Abre el menú de acciones y pulsa «Eliminar».

1. contact.press — el sistema registra el gesto. Todavía no se ha eliminado nada.

2. signal.warn + threat — el sistema advierte. El usuario aún puede evitar la consecuencia. Corresponde threat, no loss.

3. shift.enter-mode — aparece un modal de confirmación. El modal reorganiza el marco operativo. El intent no pertenece al modal como contenedor, sino al mensaje evaluable dentro de él.

4. commit.delete + loss — el usuario confirma. La tarea deja de existir. Aquí entra loss: no debe sonar ni moverse como threat. Necesita registrar consecuencia, no preparar reacción.

5. sustain.progress — si hay sincronización remota. El sostenimiento no es negativo por sí mismo.

6. emerge.present — aparece una barra de undo. La aparición no es la pérdida. La pérdida ya ocurrió en el paso 4.

7. signal.announce + neutral — el sistema informa del resultado y ofrece deshacer.

Figura 8.6

# 8. Por qué no seis

Podría parecer tentador agrupar shift dentro de emerge. Pero cambiar de marco operativo no es lo mismo que hacer aparecer algo. Un tooltip aparece pero no cambia el marco. Un cambio de vista puede no «aparecer» como capa pero desplaza al usuario a otro régimen. Si eliminamos shift, la teoría pierde capacidad para nombrar una de las experiencias más frecuentes en interfaces complejas: cruzar un umbral operativo.

# 9. Por qué no doce

Algunas de las semánticas iniciales son mejor entendidas como verbos, variantes, fases o intents. Como muestra la tabla de reubicación, cada semántica exploratoria encuentra sitio como verbo, fase o composición dentro de las siete familias. Si conservamos todas como raíz, la gramática se vuelve más pesada y menos aprendible. La teoría no pierde precisión al reducirlas; gana organización.

# 10. Síntesis

La taxonomía no pretende agotar todas las interfaces posibles ni fijar una verdad natural inmutable. Es una hipótesis teórica compacta: suficientemente pequeña para aprenderse, suficientemente rica para distinguir los cambios que una interfaz necesita hacer legibles.

**FAMILIA**	**PREGUNTA CENTRAL**
**contact**	¿El sistema ha sentido mi acción?
**commit**	¿Esto ha quedado fijado o resuelto?
**signal**	¿Algo reclama mi atención?
**handle**	¿Estoy controlando directamente este objeto?
**emerge**	¿Algo ha entrado o salido del campo?
**shift**	¿Ha cambiado el marco operativo?
**sustain**	¿Esto sigue ocurriendo?

*Tabla 5 — Síntesis de las siete familias*

*Una familia semántica no es una etiqueta para un efecto. Es una respuesta estable a una pregunta perceptiva recurrente.*

El siguiente capítulo desarrollará la distinción que atraviesa todo el sistema: por qué algunas familias y eventos aceptan intent y otras no. Porque no todos los cambios son mensaje. Algunos son marco.


================================================================================
CAPÍTULO 9 — capitulo9_con_diagramas.docx
================================================================================
CAPÍTULO 9

Semánticas valenciales y transicionales

Qué eventos son mensaje y qué eventos son marco

El Capítulo 3 presentó varios fundamentos que ahora convergen en una distinción central.

Desde el appraisal, algunos eventos se evalúan respecto a metas, control, urgencia y consecuencia. Desde la Gestalt, algunos eventos funcionan como figura y otros como fondo. Desde las affordances, los eventos operativos pueden portar valencia, mientras los estructurales organizan posibilidades. Desde la atención, una señal puede reclamar procesamiento, pero una transición puede solo orientar.

Todas esas distinciones apuntan a una misma idea:

PRINCIPIO

Hay eventos que son mensaje. Hay eventos que son marco.

Los primeros pueden portar intent. Los segundos normalmente no.

El error no es usar intent. El error es aplicarlo al evento equivocado. Un modal puede contener una amenaza, pero el modal no es la amenaza. Un spinner puede preceder a un fallo, pero el spinner no es el fallo.

PRINCIPIO

El intent modula la figura evaluable, no el fondo estructural.

Principio

*El error no es usar intent. El error es aplicarlo al evento equivocado. El intent modula la figura evaluable, no el fondo estructural.*

# 2. Qué significa que un evento sea evaluable

Un evento es evaluable cuando puede juzgarse en relación con las metas, expectativas o riesgos del usuario. Puede ser bueno o malo, leve o grave, puede exigir acción inmediata o permitir revisión, puede resolver una tensión o abrir un problema.

Un evento transicional o estructural no porta, por sí mismo, un juicio afectivo. Su función es reorganizar el campo perceptivo, revelar disponibilidad, mantener continuidad o cambiar el marco operativo. Dice *algo apareció*, *has cambiado de marco* o *el proceso sigue vivo* — pero no dice todavía bueno, malo, grave, logrado o perdido.

**TIPO**	**QUÉ HACE**	**EJEMPLOS**	**INTENT**
**Evaluable**	Porta juicio sobre el evento	Confirmar, fallar, advertir, perder	Sí
**Estructural**	Organiza el campo perceptivo	Abrir, expandir, navegar, sostener	Normal. no
**Compuesto**	Contiene marco y mensaje	Modal de error, wizard con validación	En el mensaje

*Tabla 1 — Evento evaluable y evento estructural*

# 3. Neutralidad no es ausencia de intent

*neutral* no debería convertirse en una manera de decir «no hemos pensado si este evento acepta intent». Un signal.announce + neutral sí tiene sentido: el sistema comunica algo sin valencia fuerte. Pero un emerge.open no necesita intent neutro para funcionar. Su función no es evaluar, sino organizar presencia.

Distinción

*neutral es un intent de baja valencia. La ausencia de intent es otra cosa: indica que el evento no pertenece al plano evaluativo.*

# 4. Recordatorio: los seis intents

**INTENT**	**FUNCIÓN MÍNIMA**
**neutral**	Evaluación sin tono fuerte
**affirm**	Confirmación positiva leve
**fulfill**	Resolución positiva
**risk**	Problema corregible
**threat**	Amenaza activa
**loss**	Pérdida consumada

*Tabla 2 — Los seis intents (recordatorio — el Capítulo 9 los desarrollará en detalle)*

Figura 9.2

# 5. Fundamento: appraisal

La teoría del appraisal explica por qué algunos eventos aceptan intent y otros no. El appraisal es el proceso por el cual un estímulo se evalúa en relación con metas, control, consecuencias y urgencia. Un error de validación dispara preguntas de appraisal: ¿bloquea mi objetivo? ¿puedo corregirlo? ¿es urgente? Pero la apertura de un panel o el cambio de vista no disparan el mismo tipo de evaluación.

Figura 9.3

# 6. Fundamento: figura y fondo

La percepción organiza el campo en figura y fondo. Algunos eventos son figura: el error, la advertencia, la confirmación, la pérdida. Otros son fondo estructural: el modal, el panel, la expansión, la navegación, la espera. La valencia no está en el modal como estructura. Está en el mensaje que el modal contiene.

Figura 9.4

# 7. Fundamento: esquemas sensoriomotores

Algunos esquemas son agentivos: contacto, elección, señal, logro, pérdida, manipulación/drop. Otros son estructurales: contenedor, camino, proceso, entrada/salida, plano, carry. Los esquemas agentivos tienden a admitir evaluación porque implican logro, fallo, contacto, elección, pérdida o control. Los estructurales organizan el espacio de experiencia.

Figura 9.5

# 8. Confirmaciones desde affordances, atención y afecto

Desde las affordances, los eventos operativos e informativos tienden a ser evaluables porque afectan a lo que el usuario puede hacer o debe interpretar. Las affordances estructurales organizan el campo sin portar juicio por sí mismas.

Desde la atención, signal.alert puede reclamar evaluación porque introduce una figura que el usuario debe atender. emerge, shift y sustain muchas veces redirigen o acompañan la atención sin convertir ese cambio en mensaje afectivo.

Desde el modelo valencia-arousal, los intents tienen sentido cuando un evento puede ubicarse en una región evaluativa. Una expansión no es positiva por expandirse. Una navegación no es exitosa por cambiar de vista. Una espera no es amenaza por durar.

*La convergencia es clara: el intent pertenece al evento que porta juicio, no al evento que organiza el espacio donde ese juicio aparece.*

# 9. Mapa de familias según evaluabilidad

**FAMILIA**	**NATURALEZA**	**RELACIÓN CON INTENT**	**EJEMPLO**
**contact**	Agentiva inmediata	Modulación leve o anticipatoria	contact.press + threat si acción grave
**commit**	Evaluable	Acepta intent plenamente	commit.complete + fulfill
**signal**	Informativa/atencional	Acepta intent plenamente	signal.warn + risk
**handle**	Mixta	Intent sobre todo en drop	handle.drop + risk o commit.loss
**emerge**	Estructural	Normalmente no	emerge.open
**shift**	Estructural	Normalmente no	shift.navigate
**sustain**	Estructural/temporal	Normalmente no	sustain.progress

*Tabla 3 — Familias semánticas y relación con intent*

# 10. Reglas de composición

Regla 1 — El intent va en el evento evaluable. Incorrecto: emerge.open + risk. Correcto: emerge.open → signal.warn + risk.

Regla 2 — El marco puede contener mensaje, pero no absorberlo. Incorrecto: shift.enter-mode + threat. Correcto: shift.enter-mode → signal.alert + threat.

Regla 3 — El proceso no es el resultado. Incorrecto: sustain.progress + fulfill. Correcto: sustain.progress → commit.complete + fulfill.

Regla 4 — La amenaza no es la pérdida. Incorrecto: commit.deleted + threat. Correcto: commit.delete + loss. Y si antes hay advertencia: signal.warn + threat → commit.delete + loss.

Regla 5 — En manipulación, el carry no debe cargar el juicio. Incorrecto: handle.carry + threat. Correcto: handle.carry → signal.warn + threat (si zona destructiva) → commit.delete + loss (si se suelta ahí).

Figura 9.6

# 11. Antipatrones comunes

**ANTIPATRÓN**	**QUÉ CONFUNDE**	**CORRECCIÓN**
**Modal rojo**	Marco con mensaje	shift + signal.threat
**Spinner de error**	Proceso con resultado	sustain + commit.fail
**Success de navegación**	Cambio de marco con logro	shift + commit.fulfill si procede
**Danger para pérdida**	Amenaza con pérdida	commit.delete + loss
**Alerta para toda aparición**	Emergencia con señal	emerge + signal solo si hay mensaje

*Tabla 4 — Antipatrones y correcciones*

# 12. Ejemplo: archivo no guardado al cerrar

El usuario edita un documento y pulsa cerrar. La interfaz detecta cambios sin guardar.

1. contact.press — el sistema confirma que recibió el gesto.

2. signal.warn + risk — el sistema detecta cambios sin guardar. Todavía no hay pérdida; hay riesgo corregible.

3. shift.enter-mode — aparece un diálogo que bloquea la salida. El modal reorganiza el marco. El intent no pertenece al modal.

Si el usuario elige guardar: commit.save + affirm. Si descarta: commit.discard + loss. Si cancela: commit.cancel + neutral.

4. shift.exit-mode — el modal se cierra. La salida del modal no es éxito ni pérdida. Libera el marco.

Figura 9.7

# 13. Consecuencias para diseño e implementación

Reduce sobreactuación: si solo los eventos evaluables reciben intent, la interfaz reserva la energía afectiva para donde realmente la necesita.

Mejora la composición: cada parte de una operación compuesta tiene su función asignada.

Mejora la accesibilidad: si sabemos qué evento porta el significado evaluable, podemos redistribuirlo mejor cuando un canal se reduce.

Evita falsas emociones: una interfaz no debería comunicar amenaza cuando hay pérdida, ni celebración cuando solo hay confirmación suave.

# 14. Síntesis

Este capítulo ha introducido una distinción central: no todos los eventos aceptan intent porque no todos los eventos son evaluables. Esta distinción no convierte los eventos estructurales en secundarios ni prohíbe que una transición tenga atmósfera. Solo establece que el intent debe vivir donde hay evaluación operativa, no donde solo hay organización del campo.

**FAMILIA**	**EVALUABILIDAD**	**REGLA PRÁCTICA**
**contact**	Leve o anticipatoria	Puede anticipar peso pero no porta resultado
**commit**	Alta	Es el lugar natural del intent
**signal**	Alta	Comunica el tono del mensaje
**handle**	Mixta; sobre todo en drop	El carry no carga juicio; el drop sí
**emerge**	Estructural	El intent va en lo que emerge, no en la emergencia
**shift**	Estructural	El intent va en el evento dentro del nuevo marco
**sustain**	Estructural	Si falla, componer con signal o commit

*Tabla 5 — Síntesis: evaluabilidad por familia*

*El intent no es una propiedad del componente, ni del contenedor, ni de la transición. Es una modulación evaluativa del evento que porta juicio.*

El siguiente capítulo desarrollará en detalle el sistema de intents: por qué success / warning / danger / info no basta, por qué loss debe separarse de threat, por qué affirm no es lo mismo que fulfill, y por qué info quizá no es un intent sino una función de señal.


================================================================================
CAPÍTULO 10 — capitulo10_con_diagramas.docx
================================================================================
CAPÍTULO 10

Intent: más allá del semáforo

Por qué success, warning, danger e info no bastan

El capítulo anterior estableció una regla fundamental:

PRINCIPIO

El intent vive en el evento evaluable, no en el contenedor estructural.

Un modal no es peligroso por abrirse. Una carga no es negativa por durar. Una navegación no es exitosa por cambiar de pantalla. El intent debe aplicarse allí donde el evento porta juicio.

Ahora aparece otra pregunta:

PRINCIPIO

¿Qué intents merece tener una interfaz?

1. El intent como problema no examinado

Existe en el diseño de interfaces una convención tan extendida que ha dejado de parecer convención.

Cuando algo ha ido mal, usamos rojo. Cuando algo requiere precaución, usamos amarillo. Cuando algo ha ido bien, usamos verde. Cuando algo es informativo, usamos azul.

A ese conjunto lo llamamos danger, warning, success, info. Pero la estructura permanece.

Lo notable no es que usemos esa convención. Lo notable es que casi nunca preguntamos de dónde viene, qué cubre, qué omite y qué mezcla.

¿Por qué success debe cubrir tanto una operación importante completada como un autoguardado menor?

¿Por qué danger debe cubrir tanto una amenaza activa como una pérdida ya consumada?

¿Por qué warning mezcla un riesgo corregible y a veces una amenaza seria?

¿Por qué info aparece junto a los intents si muchas veces no comunica valencia, sino solo saliencia atencional?

La pregunta del capítulo es:

PRINCIPIO

¿Qué ocurre cuando dejamos de tratar el intent como color y empezamos a tratarlo como evaluación perceptiva del evento?

2. La herencia del semáforo

La taxonomía heredada no nació en las interfaces digitales. Antes de que existieran botones verdes de success o alertas rojas de danger, esos colores ya cargaban con una historia de señalización industrial, ferroviaria y vial.

El rojo, el amarillo y el verde pertenecían a entornos donde una señal debía reconocerse rápido, a distancia y con consecuencias físicas claras. Eran instrucciones operativas. Esa estructura era adecuada para señalización porque resolvía un problema urgente: decisiones rápidas con bajo coste interpretativo.

Pero no era una teoría afectiva completa. No pretendía distinguir amenaza activa de pérdida consumada, ni confirmación suave de culminación significativa.

Cuando las interfaces gráficas empezaron a necesitar comunicar estados, heredaron esa estructura porque ya era comprensible. El diseño digital no inventó esa asociación. La recibió. El problema no fue heredar. El problema fue olvidar que se estaba heredando.

Con el tiempo, la asociación cromática dejó de parecer convención histórica y empezó a parecer estructura natural. El rojo pasó a llamarse danger. El verde, success. El amarillo, warning. Y el azul terminó ocupando el cajón residual: info.

Ahí ocurrió la mutación decisiva:

PRINCIPIO

Una convención cromática empezó a funcionar como si fuera una taxonomía semántica.

3. De la carretera a la pantalla

La web estabilizó esa mutación. Frameworks como Bootstrap ofrecieron clases contextuales simples: success, warning, danger, info. Aquella decisión era razonable y barata cognitivamente. Pero al entrar en CSS, tokens, componentes y guías, dejó de parecer un atajo. Se convirtió en vocabulario.

El núcleo siguió siendo: positivo, precaución, negativo grave, informativo, neutral.

Ese núcleo parecía suficiente mientras el intent solo modificaba color. Pero en una interfaz perceptiva multicanal, el intent puede modular motion, sonido, duración, ritmo, intensidad, persistencia, profundidad, forma, háptica y silencio.

En ese momento, la convención heredada muestra sus límites. Porque una cosa es elegir un color. Otra muy distinta es decidir cómo debe moverse, sonar, durar, aparecer, persistir o sentirse un evento.

4. Qué codifica realmente la convención heredada

Si examinamos success, warning, danger e info, vemos que no forman una taxonomía afectiva completa. Forman una taxonomía cromática útil. Eso no las vuelve inútiles. Las vuelve insuficientes.

Danger mezcla amenaza activa, fallo grave y pérdida consumada. Success mezcla confirmación suave, resolución positiva y culminación. Warning no distingue riesgo corregible de amenaza próxima. Info muchas veces no expresa evaluación afectiva, sino saliencia atencional.

PRINCIPIO

La convención heredada codifica colores útiles. La teoría del intent debe codificar regiones evaluativas del evento.

Por eso necesitamos separar: threat ≠ loss, affirm ≠ fulfill, info ≠ intent.

5. Qué debería ser un intent

Un intent es la modulación evaluativa de un evento interactivo.

Primero, pertenece al evento, no al componente. Segundo, pertenece al plano evaluativo, no a cualquier cambio. Tercero, debe poder modular varios canales. Cuarto, debe expresar una región afectiva funcional, no una etiqueta genérica.

6. El espacio afectivo

El sistema de intents se apoya en el espacio valencia/activación descrito por James A. Russell. No como teoría completa de la emoción, sino como base operativa.

La valencia distingue lo positivo de lo negativo. La activación distingue baja y alta movilización atencional.

No es lo mismo threat que loss. Ambos son negativos, pero uno tiene alta activación y convoca acción; el otro registra consecuencia consumada con activación más baja. Tampoco es lo mismo affirm que fulfill. Ambos son positivos, pero uno confirma suavemente; el otro resuelve una tensión.

7. Las seis regiones evaluativas

INTENT	REGIÓN EVALUATIVA	LECTURA
neutral	baja activación, sin valencia fuerte	el evento no requiere evaluación afectiva significativa
affirm	valencia positiva, baja activación	confirma sin alterar significativamente el foco
fulfill	valencia positiva, activación media-alta	marca resolución de tensión o culminación
risk	valencia negativa, activación media	problema corregible que requiere atención
threat	valencia negativa, alta activación	exige atención urgente y posible acción inmediata
loss	valencia negativa, menor activación y posterioridad	registra consecuencia ya consumada

PRINCIPIO

Los intents no son colores ni estilos. Son regiones evaluativas del evento que pueden expresarse mediante distintos canales perceptivos.

8. Lo que la convención heredada pierde

Threat convoca acción. Loss registra consecuencia. Affirm confirma normalidad. Fulfill resuelve tensión. Info no responde a cómo se evalúa el evento, sino a si debe ser notado.

CONVENCIÓN	QUÉ MEZCLA	SEPARACIÓN PROPUESTA
danger / error	amenaza, fallo, pérdida	threat, risk, loss
warning	riesgo corregible, amenaza	risk, a veces threat
success	confirmación, resolución, logro	affirm, fulfill
info	saliencia, mensaje neutro	signal.announce + neutral

9. Cómo modula el intent

El intent no se expresa solo en color. Puede hacerse perceptible mediante duración, energía de motion, timbre sonoro, persistencia, profundidad, forma, háptica o silencio.

10. Neutralidad no es ausencia de intent

Neutral ocupa una región de baja activación sin carga evaluativa fuerte. Pero no todo evento sin carga evaluativa necesita recibir neutral. Algunos eventos simplemente no pertenecen al plano evaluativo: emerge.open, shift.navigate o sustain.progress pueden no necesitar intent.

11. Familia e intent

La familia dice qué tipo de evento está ocurriendo. El intent dice en qué región evaluativa cae ese evento. Los canales dicen cómo se vuelve perceptible esa evaluación.

12. Antipatrones

ANTIPATRÓN	QUÉ OCULTA
derivar intent de color	oculta el espacio valencia/activación
usar danger para pérdida	oculta la diferencia temporal antes/después
usar success para todo	oculta la diferencia entre baja y mayor activación positiva
usar info como intent	oculta la diferencia entre saliencia y evaluación

13. Ejemplo narrativo

Autoguardado: commit.save + affirm. Región: valencia positiva, baja activación.

Envío completado: commit.submit + fulfill. Región: valencia positiva, activación media-alta.

Eliminación previa: signal.warn + threat. Región: valencia negativa, alta activación, antes de la consecuencia.

Eliminación consumada: commit.delete + loss. Región: valencia negativa, menor activación, después de la consecuencia.

14. Principios

El intent pertenece al evento, no al componente.

El intent modula el plano evaluable, no el estructural.

El intent se deriva de la evaluación del evento en el espacio valencia/activación, no del color con que se represente.

15. Síntesis

Con este capítulo, el sistema de intents deja de ser una variación cromática y pasa a funcionar como capa evaluativa del evento. A partir de ahora, color, motion, sonido, forma, presencia, háptica y tiempo no definirán el intent: lo expresarán.

Figura 10.1

Figura 10.2


================================================================================
CAPÍTULO 11 — capitulo11_con_diagramas.docx
================================================================================
CAPÍTULO 11

LOS CANALES PERCEPTIVOS DE LA INTERFAZ

Por dónde se vuelve sensible un evento

Hasta aquí hemos hablado de eventos.

Hemos definido la interfaz como la dimensión perceptible de un contexto operacional. Hemos explicado que el usuario no percibe solo componentes, sino transformaciones: algo responde, algo se fija, algo aparece, algo reclama atención, algo se pierde, algo continúa, algo cambia de marco. Hemos llamado evento interactivo a esa modificación perceptible del contexto operacional que tiene significado para la acción, la atención o la interpretación del estado.

Pero un evento no se percibe en abstracto.

Para que exista en la experiencia del usuario, debe tomar cuerpo en algún canal. Debe durar, moverse, aparecer, sonar, cambiar de color, ocupar un plano, modificar una forma, dejar una marca, producir contacto o retirarse.

A esa materia sensible la llamaremos canales perceptivos de la interfaz.

Un canal perceptivo no es una propiedad técnica. No es opacity, transform, box-shadow, background-color, AudioContext o vibration API. Esas son herramientas. El canal es lo que el usuario percibe a través de ellas: presencia, movimiento, profundidad, forma, color, sonido, contacto, tiempo, continuidad, urgencia, peso, pérdida, confirmación.

El desarrollador escribe transform: scale(.97). Pero el usuario no percibe “un transform”. Percibe que el botón cede brevemente a su acción.

El desarrollador escribe box-shadow. Pero el usuario no percibe “un box-shadow”. Percibe elevación, plano, separación o prioridad.

El desarrollador dispara un sonido breve. Pero el usuario no percibe “un wav” o “un oscillator”. Percibe confirmación, aviso, cierre, amenaza o recompensa.

El problema de muchas interfaces no es que carezcan de efectos. Es que esos efectos no están organizados como canales de significado.

El mapa completo: del evento a la lectura perceptiva

Figura 11.1

Antes de entrar canal por canal conviene situar la arquitectura completa del sistema.

La teoría que este libro propone no empieza en los canales. No empieza en el color, ni en motion, ni en sonido, ni en una vibración. Empieza en el evento.

Un evento interactivo ocurre dentro de un contexto operacional. Ese evento pertenece a una familia semántica. Puede concretarse mediante un verbo o una fase. Si es evaluable, puede recibir un intent. Y solo entonces se materializa mediante canales perceptivos.

La secuencia completa es:

evento interactivo

→ familia semántica

→ verbo / fase

→ evaluación si procede

→ intent

→ canales perceptivos

→ lectura unificada

Ejemplo:

commit.complete + fulfill

→ motion resolutivo

→ sonido breve ascendente

→ color positivo

→ marca persistente

→ lectura: objetivo cumplido

Otro ejemplo:

signal.warn + risk

→ forma de callout

→ color de advertencia moderada

→ icono

→ texto persistente

→ lectura: revisa esto

Y otro:

contact.press

→ baja latencia

→ estado pressed

→ micro motion opcional

→ háptica opcional

→ lectura: el sistema ha sentido mi acción

Esta secuencia evita un error frecuente: empezar por el efecto.

Si empezamos por el efecto, preguntamos:

PRINCIPIO

¿qué animación queda bien aquí?

Si empezamos por el canal, preguntamos:

PRINCIPIO

¿qué sonido usamos?

Si empezamos por el color, preguntamos:

PRINCIPIO

¿esto va en rojo, verde o amarillo?

Pero la pregunta correcta es anterior:

PRINCIPIO

¿qué evento necesita percibir el usuario?

Solo después podemos decidir por qué canales conviene expresarlo.

Crear una cadena vertical o horizontal:

EVENTO INTERACTIVO

↓

FAMILIA SEMÁNTICA

↓

VERBO / FASE

↓

EVALUACIÓN SI PROCEDE

↓

INTENT

↓

CANALES PERCEPTIVOS

↓

LECTURA UNIFICADA

Añadir ejemplo lateral:

signal.alert + threat

→ presencia fuerte

→ color saliente

→ forma clara

→ sonido opcional

→ texto persistente

→ lectura: atiende ahora

PRINCIPIO

Los canales no se coordinan entre sí en abstracto. Se coordinan alrededor de un evento.

Principio añadido

PRINCIPIO

No se diseña un canal primero. Se identifica el evento y después se decide qué canales lo vuelven perceptible.

1. Por qué hablar de canales

----------------------------

Durante mucho tiempo hemos tratado la interfaz como si tuviera una división simple:

visual

auditivo

háptico

Y dentro de “visual” hemos metido casi todo: color, forma, layout, sombra, movimiento, aparición, profundidad, iconografía, estado, foco, contraste.

Pero esa agrupación es demasiado gruesa.

Un cambio de color no comunica lo mismo que un desplazamiento. Una sombra no comunica lo mismo que un borde. Una aparición no comunica lo mismo que un temblor. Un icono no comunica lo mismo que una deformación. Una transición lenta no comunica lo mismo que una respuesta instantánea.

Todo puede entrar por la vista, pero no todo pertenece al mismo canal perceptivo.

El tiempo comunica inmediatez, espera, continuidad, persistencia o resolución.

Motion comunica causalidad, trayectoria, energía, masa y cambio.

La presencia comunica aparición, retirada, disponibilidad o desaparición.

La profundidad comunica plano, jerarquía, elevación, subordinación o régimen operativo.

La forma comunica límite, affordance, contorno, agrupación, iconografía y estabilidad.

El color comunica saliencia, estado, valencia y refuerzo, pero no debería cargar solo con todo el significado.

El sonido comunica urgencia, cierre, confirmación, alarma, pérdida o recompensa con una velocidad que el canal visual no siempre alcanza.

La háptica comunica contacto, impacto, resistencia, fricción y encaje, aunque su disponibilidad dependa mucho del dispositivo y, en la web, siga siendo limitada.

2. Fundamento psicoperceptivo: por qué no basta con decir “visual”

------------------------------------------------------------------

La separación entre canales no nace de una ocurrencia terminológica. Nace de una observación básica: la percepción humana no procesa todas las señales de una interfaz como si fueran una sola materia uniforme.

Incluso dentro de lo que solemos llamar visual, hay dimensiones perceptivas distintas. El color no comunica lo mismo que la forma. La forma no comunica lo mismo que la profundidad. La profundidad no comunica lo mismo que el movimiento. La presencia no comunica lo mismo que la posición. Todas pueden llegar por la vista, pero no cumplen la misma función cognitiva.

La psicología Gestalt mostró que la percepción organiza el campo visual según principios como proximidad, semejanza, continuidad, cierre, región común, figura/fondo y destino común. Esto ayuda a explicar por qué una interfaz no se percibe como una lista de elementos, sino como un campo organizado de relaciones.

La teoría de affordances añade otra dimensión: no percibimos solo propiedades visibles, sino posibilidades de acción. Un botón no es solo una forma rectangular; es algo que ofrece ser presionado. Un objeto elevado no es solo un objeto con sombra; puede sugerir manipulación. Un campo con borde activo no es solo un contorno; indica disponibilidad de entrada.

La atención introduce un tercer plano. Algunas señales orientan, otras interrumpen, otras sostienen y otras fatigan. Por eso no basta con decir que algo “se ve”: hay que preguntar qué demanda atencional genera.

La integración multisensorial añade todavía otra capa. Cuando motion, sonido, háptica y color ocurren de manera temporal y semánticamente congruente, el usuario puede percibirlos como un único evento. Cuando se desacoplan, los percibe como señales separadas o incluso contradictorias.

Por eso este libro distingue canales perceptivos. No porque cada canal tenga fronteras absolutas, sino porque cada uno tiende a transportar tipos distintos de significado.

3. Propiedad técnica y canal perceptivo

--------------------------------------

Una misma propiedad técnica puede participar en varios canales.

Opacity puede comunicar aparición, retirada, debilitamiento, indisponibilidad o subordinación del fondo.

Scale puede comunicar contacto, profundidad, énfasis, celebración o manipulación.

Box-shadow puede comunicar profundidad, elevación, foco, manipulación o cambio de plano.

Color puede comunicar estado, categoría, saliencia, valencia o marca.

Sonido puede comunicar contacto, alerta, cierre, pérdida o logro.

Vibración puede comunicar contacto, impacto, encaje, rechazo o amenaza corporal.

Por eso no basta con definir tokens técnicos. Hace falta una capa semántica que pregunte:

PRINCIPIO

¿qué dimensión del evento comunica esta propiedad?

4. El evento como composición perceptiva

----------------------------------------

Una interacción semántica no se expresa necesariamente por un solo canal.

Un contact.press puede combinar tiempo breve, micro motion, estado visual y quizá háptica.

Un commit.complete + fulfill puede combinar motion resolutivo, sonido ascendente, color positivo y marca persistente.

Un signal.warn + risk puede combinar color moderado, forma de callout, icono, texto y persistencia.

Un handle.pick puede combinar profundidad, sombra, motion de elevación, forma de agarre y háptica opcional.

Un sustain.progress puede combinar tiempo, presencia persistente, barra, texto de estado y motion suave.

Lo importante es que el usuario no perciba esos canales como piezas separadas, sino como una lectura coherente del evento.

La gramática no pregunta primero:

PRINCIPIO

¿qué animación ponemos?

Pregunta:

PRINCIPIO

¿qué evento debe hacerse perceptible y qué canales lo expresan mejor?

5. La web como campo principal de ejemplos

------------------------------------------

Este libro toma la web como campo principal de observación.

No porque la teoría se limite a la web, sino porque en la web la fragmentación de los canales se vuelve especialmente visible. El desarrollador trabaja con DOM, CSS, JavaScript, estados, clases, media queries, eventos técnicos, tokens, componentes, Web Audio API y accesibilidad. Cada capa tiene su propia lógica.

Y, sin embargo, el usuario no experimenta esas capas por separado.

La web también muestra muy bien las asimetrías entre canales:

- color, forma, presencia y motion están muy disponibles;

- sonido existe, pero está condicionado por políticas del navegador, permisos, contexto de uso y cultura del silencio;

- háptica existe de manera limitada e inconsistente;

- profundidad es simulada, pero perceptivamente poderosa;

- tiempo y latencia dependen de rendimiento, red, dispositivo y sincronización del render.

La web será nuestro laboratorio principal. No será el límite de la teoría.

6. Síntesis

-----------

Un evento interactivo necesita hacerse sensible.

Los canales perceptivos no son efectos decorativos ni propiedades técnicas aisladas. Son vías por las que el usuario percibe que algo responde, aparece, se fija, reclama atención, se pierde, continúa o cambia de marco.

La tesis del capítulo puede formularse así:

PRINCIPIO

El evento es la unidad de significado. Los canales son la materia sensible que lo hace perceptible.


================================================================================
CAPÍTULO 12 — capitulo12_con_diagramas.docx
================================================================================
CAPÍTULO 12

TIEMPO, LATENCIA Y SINCRONÍA

El canal que atraviesa todos los canales

Antes de que algo se mueva, suene, vibre o cambie de color, ocurre en el tiempo.

El tiempo no es una propiedad secundaria de la interfaz. Es el canal que organiza la relación entre acción, espera, continuidad, consecuencia y memoria.

Una interfaz puede sentirse inmediata, fluida, lenta, rota, viva, bloqueada o concluida según su temporalidad. La misma respuesta, con el mismo color y el mismo componente, cambia de significado si llega demasiado tarde o demasiado pronto.

En una teoría del evento interactivo, el tiempo no es solo duración de animación.

Es una forma de significado.

1. La interfaz como experiencia temporal

---------------------------------------

Solemos pensar la interfaz como espacio: una pantalla, una disposición, un layout, una jerarquía. Pero la interacción no ocurre solo en el espacio. Ocurre en secuencias.

El usuario actúa. El sistema responde. Algo empieza. Algo continúa. Algo se detiene. Algo termina. Algo queda.

Cada momento tiene significado.

Una respuesta inmediata comunica contacto. Una espera sin señal comunica duda. Una espera con señal comunica proceso. Una culminación comunica cierre. Una señal persistente comunica relevancia. Una desaparición demasiado rápida puede parecer error o pérdida. Una notificación demasiado larga puede convertirse en ruido.

El tiempo convierte un cambio en evento.

2. Fundamento psicoperceptivo: tiempo, agencia y espera

-------------------------------------------------------

El tiempo es uno de los canales más estudiados en interacción humano-computador, aunque a menudo se trate solo como rendimiento técnico.

En HCI clásica se han propuesto umbrales temporales aproximados que siguen siendo útiles como orientación: una respuesta casi inmediata tiende a sentirse como parte del gesto; una demora breve puede mantenerse dentro del flujo de pensamiento; una espera más larga exige feedback explícito para no convertirse en incertidumbre.

Estos umbrales no son leyes absolutas, pero ayudan a entender algo fundamental: el tiempo modifica la interpretación del evento.

Cuando la respuesta llega muy cerca de la acción, el usuario puede atribuirla a su propio gesto. Esa atribución sostiene la sensación de agencia. En una interfaz, el contacto no se comunica solo con un cambio visual, sino con un cambio suficientemente próximo a la acción.

Por eso contact.press depende tanto de la latencia. Si el sistema responde tarde, el evento deja de sentirse como contacto y empieza a sentirse como una reacción posterior del sistema.

La espera activa otro mecanismo. Cuando el usuario actúa y el resultado no llega, necesita saber si el sistema sigue trabajando. La ausencia de señal durante una espera puede interpretarse como bloqueo, fallo o pérdida de control. De ahí la función de sustain: no comunicar resultado, sino continuidad.

La sincronía multisensorial también depende del tiempo. Si un movimiento, un sonido y una vibración pertenecen al mismo evento, deben estar suficientemente coordinados para que el usuario los perciba como una unidad. Si llegan desfasados, pueden sentirse como eventos separados.

El tiempo, por tanto, no es solo duración. Es la condición que permite percibir causalidad, continuidad, espera, resolución y unidad multicanal.

3. Latencia

-----------

Latencia es el intervalo entre la acción del usuario y la respuesta perceptible del sistema.

No es solo una métrica técnica. Es una condición de agencia.

Cuando el usuario pulsa un botón, arrastra un objeto, escribe una tecla o activa un control, necesita que el sistema responda lo bastante rápido como para que esa respuesta se atribuya a su acción.

Si la respuesta llega dentro de una ventana breve, el usuario siente:

PRINCIPIO

lo he hecho yo.

Si llega demasiado tarde, empieza a sentir:

PRINCIPIO

el sistema ha hecho algo después.

Esa diferencia es semántica.

4. Duración

-----------

Duración no es lo mismo que latencia.

La latencia pregunta: ¿cuándo empieza la respuesta?

La duración pregunta: ¿cuánto dura la expresión del evento?

Un evento demasiado corto puede no ser percibido.

Un evento demasiado largo puede sentirse pesado, teatral o intrusivo.

La duración debe corresponder a la función semántica del evento.

Contact debe ser breve. Sustain puede ser prolongado. Signal puede necesitar persistencia. Commit necesita resolución. Emerge necesita entrada y salida. Handle necesita continuidad durante el gesto.

5. Espera

---------

La espera es una de las situaciones temporales más delicadas.

Cuando el usuario actúa y el sistema no puede dar un resultado inmediato, aparece una pregunta:

PRINCIPIO

¿esto sigue vivo o se ha roto?

Ahí nace sustain.

Sustain no comunica éxito ni error. Comunica continuidad operativa.

Un spinner, una barra de progreso, un skeleton, un texto “guardando…” o una actualización periódica no son elementos decorativos. Son formas de decir:

PRINCIPIO

el sistema sigue trabajando.

6. Persistencia y huella

------------------------

No todo evento termina cuando termina su animación.

Una selección queda marcada. Una alerta permanece hasta ser atendida. Un resultado deja estado. Una pérdida deja ausencia o undo. Un proceso deja progreso.

Conviene distinguir duración expresiva, persistencia, huella y caducidad.

La persistencia es especialmente importante para accesibilidad. Una señal efímera puede no ser percibida por todos los usuarios. Si la información es importante, debe dejar alguna huella.

7. Secuencia

------------

El significado temporal depende también del orden.

No es lo mismo:

signal.warn + threat

commit.delete + loss

que:

commit.delete + loss

signal.warn + threat

En el primer caso, la interfaz advierte antes de la pérdida. En el segundo, advierte después de que ya no hay nada que evitar.

El orden cambia el sentido.

8. Tiempo e intent

------------------

El intent también modula el tiempo.

Affirm suele ser breve, suave, de baja activación. Fulfill puede durar algo más porque marca resolución de una tensión. Risk necesita persistir lo suficiente para que el usuario lo procese. Threat debe entrar rápido y con alta saliencia. Loss puede ser breve, grave y dejar huella.

La posición de un intent en el espacio valencia/activación tiene consecuencias temporales. Un threat, por su alta activación, debe entrar rápido y con suficiente saliencia. Un loss, aunque negativo, no necesita la misma urgencia, porque registra una consecuencia ya consumada.

9. Accesibilidad temporal

-------------------------

El tiempo también es accesibilidad.

No todos los usuarios procesan los cambios a la misma velocidad. No todos ven una señal efímera. No todos pueden actuar antes de un timeout. No todos interpretan una animación rápida.

La accesibilidad temporal incluye duración suficiente de mensajes importantes, control sobre pausas y timeouts, evitar desapariciones críticas, no depender de instantes efímeros y mantener estados importantes después del evento.

Principio:

PRINCIPIO

Si un evento importante solo existe durante un instante, muchos usuarios no lo recibirán.

10. Síntesis

------------

El tiempo atraviesa todos los canales.

Define si una respuesta se siente causada por la acción del usuario o como evento separado. Define si una espera parece proceso o bloqueo. Define si una señal se percibe o se pierde. Define si una culminación cierra una tensión o pasa desapercibida.

La tesis:

PRINCIPIO

El tiempo no acompaña al evento. El tiempo forma parte de su significado.


================================================================================
CAPÍTULO 13 — capitulo13_con_diagramas.docx
================================================================================
CAPÍTULO 13

MOTION: LA FÍSICA PERCIBIDA DEL EVENTO

Movimiento, causalidad, continuidad y energía

Animación es la técnica.

Motion es la percepción del cambio en movimiento.

Una animación puede ser una transición CSS, un transform, un keyframe, un spring, un fade, un slide, un scale, un spinner o una interpolación entre estados. Pero motion, en este libro, no es la propiedad técnica que cambia. Es lo que el usuario percibe cuando algo se desplaza, se comprime, se eleva, se asienta, se resiste, tiembla, colapsa o entra en el campo.

Motion comunica causalidad, continuidad, energía, masa, dirección y régimen.

1. Fundamento psicoperceptivo: movimiento, causalidad y continuidad

-------------------------------------------------------------------

Motion se apoya en mecanismos básicos de percepción del movimiento.

Uno de los fundamentos más relevantes para interfaces es la percepción de causalidad. Los estudios clásicos de Michotte mostraron que ciertas secuencias simples de movimiento se perciben directamente como relaciones causales: un objeto se mueve hacia otro, lo toca, y el segundo empieza a moverse. El observador no percibe simplemente dos desplazamientos sucesivos, sino una relación de causa.

En interfaz ocurre algo parecido, aunque a otra escala. Cuando el usuario pulsa un botón y el botón se comprime inmediatamente, la respuesta se interpreta como consecuencia del gesto. Si la respuesta llega tarde o con una forma no relacionada, esa atribución se debilita.

Motion también sostiene la continuidad de objeto. Cuando un elemento cambia de posición, se expande o se desplaza hacia otro lugar, el movimiento permite al usuario percibir que sigue siendo el mismo objeto en otra condición. Sin movimiento, el cambio puede sentirse como desaparición de una cosa y aparición de otra.

Otro fundamento importante es la predicción sensorimotora. Cuando algo empieza a moverse, el usuario genera expectativas sobre su trayectoria, velocidad y destino. Si el movimiento se corta, salta o contradice la física implícita que sugiere, aparece una sensación de extrañeza.

Finalmente, el movimiento comunica energía y masa mediante claves temporales: velocidad, aceleración, desaceleración, rebote, rigidez, fricción, overshoot o colapso. La interfaz no tiene peso real, pero motion puede producir una lectura de peso, ligereza, resistencia o pérdida de energía.

Estos fundamentos no dictan una curva universal. Pero sí justifican la tesis central:

DISTINCIÓN

Motion no es decoración; es una forma de comunicar cómo ocurre un cambio.

2. Causalidad

-------------

La primera función de motion es preservar causalidad.

Cuando el usuario pulsa un botón y el botón se comprime de inmediato, la interfaz comunica:

PRINCIPIO

mi acción produjo una respuesta.

Esa relación es la base de contact.

3. Continuidad

--------------

Motion permite que el usuario perciba que algo sigue siendo lo mismo a través del cambio.

Una tarjeta que se desplaza hasta otra posición sigue siendo la misma tarjeta. Un panel que se expande desde su encabezado sigue perteneciendo a ese origen. Un indicador activo que se desliza de una pestaña a otra conserva continuidad de navegación. Un objeto arrastrado mantiene identidad durante el gesto.

Sin continuidad, el usuario debe reconstruir el cambio con memoria y razonamiento.

4. Energía, masa y activación

-----------------------------

Motion comunica energía.

Un movimiento rápido y seco puede comunicar urgencia. Un movimiento suave puede comunicar calma. Un rebote puede comunicar elasticidad o celebración. Un colapso puede comunicar pérdida de energía. Un shake puede comunicar discrepancia o alerta. Un asentamiento puede comunicar cierre.

La energía del movimiento puede reforzar la activación del evento. Un threat, situado en una región de alta activación negativa, puede admitir entradas más rápidas, tensas o salientes. Un risk necesita una tensión más moderada. Un affirm debe ser suave y breve. Un fulfill puede tener más resolución. Un loss puede usar descenso, contracción o retirada grave, no la energía urgente de una amenaza activa.

5. Dirección

------------

Motion comunica de dónde viene algo y hacia dónde va.

Un dropdown que emerge desde su trigger se entiende como dependiente de ese control. Un modal que aparece centrado comunica un marco dominante. Un panel que entra desde un borde comunica procedencia lateral. Una tarjeta que colapsa hacia una zona de descarte comunica retirada o pérdida.

La dirección no es decorativa. Es orientación.

6. Motion y familias

--------------------

Contact usa motion para causalidad inmediata.

Commit usa motion para asentamiento y cierre.

Signal usa motion para llamar atención.

Handle usa motion para control continuo.

Emerge usa motion para aparición y retirada.

Shift usa motion para cambio de marco.

Sustain usa motion para continuidad.

7. Motion y accesibilidad

-------------------------

Motion es poderoso, pero delicado.

Puede ayudar a entender causalidad y continuidad. También puede producir mareo, distracción, fatiga o malestar vestibular.

Reducir motion no debe significar eliminar semántica. Si motion transportaba contacto, debe migrar a estado visual, sonido opcional o háptica. Si transportaba continuidad, debe migrar a texto o estado. Si transportaba cambio de marco, debe migrar a foco, título, estructura y landmarks.

Principio:

PRINCIPIO

Reducir motion no significa eliminar el tiempo ni el significado. Significa expresarlos sin movimiento problemático.

8. Síntesis

-----------

Motion es la física percibida del evento.

No pregunta “cómo animar esto”.

Pregunta “qué clase de cambio necesita percibir el usuario”.


================================================================================
CAPÍTULO 14 — capitulo14_con_diagramas.docx
================================================================================
CAPÍTULO 14

Presencia y profundidad

Lo que está, lo que aparece y lo que ocupa un plano

A veces lo decisivo no es que algo se mueva.

A veces lo decisivo es que algo aparece.

Un tooltip entra en el campo.

Un dropdown se abre bajo un botón.

Un panel lateral se despliega.

Un modal se impone sobre la página.

Una tarjeta desaparece de una lista.

Una barra de undo aparece después de eliminar.

Un objeto arrastrado se eleva sobre el layout.

En todos esos casos, la interfaz no solo muestra o esconde elementos. Reorganiza la presencia y la profundidad del campo perceptivo.

La presencia responde:

PRINCIPIO

¿esto está aquí, aparece, permanece o se retira?

La profundidad responde:

PRINCIPIO

¿en qué plano ocurre y qué prioridad tiene?

Ambos canales son esenciales para entender emerge, shift, handle, signal y commit.delete + loss.

1. Presencia no es existencia técnica

Un elemento puede existir técnicamente y no estar presente para el usuario.

Puede estar en el DOM, pero oculto.

Puede estar fuera del viewport.

Puede estar colapsado.

Puede estar subordinado.

Puede estar inaccesible por foco.

Puede existir como estado interno, pero no como experiencia.

Y al revés: algo puede ser técnicamente transitorio y tener una presencia perceptiva muy fuerte, como un modal, una alerta o un toast.

Por eso, en este libro, presencia no significa existencia técnica.

Significa existencia perceptiva.

La pregunta no es:

¿está renderizado?

sino:

¿forma parte del campo perceptivo del usuario?

2. Fundamento psicoperceptivo: figura/fondo, plano y claves de profundidad

Presencia y profundidad se apoyan en la forma en que la percepción organiza el campo visual.

La psicología Gestalt mostró que no percibimos elementos aislados, sino relaciones: agrupación, continuidad, figura/fondo, cierre, proximidad, semejanza y destino común. Esto es fundamental para entender por qué un modal, un tooltip o un dropdown no son solo rectángulos que aparecen en pantalla. Cada uno reorganiza el campo de una manera distinta.

La distinción figura/fondo es especialmente importante. Cuando un modal aparece sobre una página, el contenido anterior no desaparece necesariamente, pero pasa a funcionar como fondo subordinado. El modal se convierte en figura operativa.

La profundidad se construye mediante claves perceptivas como oclusión, sombra, escala relativa, desenfoque, superposición y tratamiento del fondo. La pantalla es plana, pero esas claves permiten leer relaciones como:

esto está delante

esto queda detrás

esto flota

esto depende de aquello

esto domina el marco actual

Por eso shift.enter-mode no se comunica solo porque aparece un modal, sino porque cambia la relación de planos. En handle.pick, la profundidad comunica otro cambio: el objeto pasa del layout al régimen de manipulación. En emerge, la presencia permite leer aparición o retirada. En loss, la ausencia misma puede comunicar que algo dejó de estar disponible.

3. Emerge, shift y signal: tres formas de aparecer

No todo lo que aparece pertenece a la misma familia.

Un tooltip aparece.

Un dropdown aparece.

Un modal aparece.

Un toast aparece.

Un error inline aparece.

Pero no son el mismo evento.

TOOLTIP

emerge.present

Aparece información auxiliar.

No cambia el marco.

No reclama atención urgente.

Debe estar anclado al elemento que explica.

DROPDOWN

emerge.open

Aparecen opciones locales.

La superficie depende de un trigger.

El fondo sigue activo.

No hay cambio de régimen operativo completo.

MODAL

shift.enter-mode

Aparece una superficie, sí, pero su función principal no es aparecer.

Su función es cambiar el marco operativo: subordina el fondo, captura foco y exige una acción dentro de un nuevo régimen.

TOAST

signal.notify + neutral

Aparece un mensaje iniciado por el sistema.

La presencia sirve a la señal.

ERROR INLINE

signal.warn + risk

Aparece junto a un campo, pero su función no es solo presencia. Reclama atención sobre un problema corregible.

La pregunta clave es:

PRINCIPIO

¿algo apareció o el sistema está reclamando atención? ¿algo apareció o cambió el marco operativo?

Figura 14.1

SUPERFICIE	FAMILIA DOMINANTE	LECTURA
Tooltip	`emerge.present`	aparece ayuda auxiliar
Dropdown	`emerge.open`	aparecen opciones locales
Modal	`shift.enter-mode`	cambia el marco operativo
Toast	`signal.notify`	el sistema comunica algo
Error inline	`signal.warn + risk`	hay un problema corregible

4. Profundidad no significa importancia

Un error frecuente es asumir que todo lo que está “más arriba” es más importante.

No necesariamente.

Un dropdown puede flotar sin ser importante.

Un tooltip puede estar por encima sin ser urgente.

Un objeto arrastrado puede elevarse porque está bajo control, no porque sea crítico.

Un modal puede estar delante porque cambia el marco, no porque su contenido sea necesariamente peligroso.

La profundidad comunica plano, relación y régimen operativo. La importancia afectiva depende del evento evaluable.

Por eso:

shift.enter-mode

signal.warn + threat

es más preciso que:

shift.enter-mode + threat

El modal cambia el plano.

La advertencia porta la amenaza.

Caja de principio

DISTINCIÓN

Más profundidad no significa más peligro. Significa otro plano operativo.

5. Desaparecer no significa perder

La desaparición visual es ambigua.

Una tarjeta puede desaparecer porque:

- se cerró;

- se ocultó;

- se filtró;

- se colapsó;

- se descartó;

- se eliminó;

- se perdió.

Si la interfaz no distingue esas diferencias, el usuario debe adivinarlas.

emerge.close

significa:

PRINCIPIO

se cerró una superficie.

emerge.hide

significa:

DISTINCIÓN

sigue existiendo, pero no está visible.

emerge.collapse

significa:

PRINCIPIO

el contenido volvió a estar contenido.

commit.delete + loss

significa:

PRINCIPIO

dejó de estar disponible.

La presencia debe hacer legible si algo se retira de la vista o si realmente deja de existir operativamente.

Figura 14.2

Cuatro tarjetas con la misma silueta que se retira:

Cerrar

emerge.close

“se retiró la superficie”

Ocultar

emerge.hide

“sigue existiendo”

Colapsar

emerge.collapse

“vuelve al contenedor”

Eliminar

commit.delete + loss

“dejó de estar disponible”

PRINCIPIO

La desaparición visual es ambigua. La semántica debe distinguir retirada, ocultación, colapso y pérdida.

6. Ejemplo narrativo: tarjeta eliminada con undo

Un usuario elimina una tarjeta de una lista.

Una solución pobre:

la tarjeta hace fade out

Problema: el usuario puede no saber si se ocultó, se filtró, se movió o se eliminó.

Una solución semántica:

signal.warn + threat

commit.delete + loss

emerge.present undo

signal.announce + neutral

Primero, si la acción es destructiva, puede haber una advertencia.

Después, al confirmar, la tarjeta se retira como consecuencia:

commit.delete + loss

Pero la interfaz no debería limitarse a hacerla desaparecer. Debe dejar huella:

emerge.present undo

La barra de undo no es la pérdida. La pérdida ya ocurrió en el commit. La barra emerge como posibilidad temporal de reparación.

Canales:

- presencia: la tarjeta deja de estar;

- motion: retirada o colapso;

- forma: barra de undo;

- texto: “Tarjeta eliminada”;

- tiempo: undo persistente lo suficiente;

- color: refuerzo sobrio;

- accesibilidad: anuncio si procede.

Lectura:

PRINCIPIO

esto se eliminó, pero todavía puedes deshacerlo.

7. Ejemplo narrativo: command palette

Una command palette aparece sobre la interfaz.

Podría parecer un caso de emerge, porque “aparece algo”. Pero semánticamente es más fuerte.

La command palette cambia el régimen operativo:

- captura foco;

- convierte el teclado en canal principal;

- permite ejecutar acciones globales;

- subordina el fondo;

- introduce un modo temporal.

Por tanto:

shift.enter-mode

No:

emerge.open

Aunque la superficie aparezca, su función principal no es presencia local. Es cambio de marco.

Canales:

- profundidad: superficie dominante;

- presencia: entrada clara;

- foco: input activo;

- forma: shell reconocible;

- motion: entrada rápida;

- accesibilidad: gestión de foco, escape, retorno.

Lectura:

PRINCIPIO

ahora estás operando sobre el sistema entero desde otro modo.

8. Accesibilidad de presencia y profundidad

Presencia y profundidad pueden ser claras visualmente y opacas para otros modos de interacción.

Un modal visualmente evidente puede fallar si no gestiona foco.

Un fondo oscurecido puede parecer subordinado, pero seguir activo para teclado.

Un toast puede aparecer visualmente, pero no ser anunciado.

Un dropdown puede flotar, pero no estar relacionado con su trigger.

Un cambio de vista puede ser visible, pero no mover foco ni actualizar título.

La accesibilidad exige coherencia entre:

plano visual

foco

árbol accesible

orden de lectura

estado operativo

Si algo emerge visualmente, también debe emerger operativamente.

Si un fondo queda subordinado visualmente, también debe quedar subordinado en la interacción.

9. Antipatrones

ANTIPATÓN	QUÉ FALLA	CORRECCIÓN
Dropdown como modal	profundidad excesiva	mantener anclaje local
Modal como popover	marco insuficiente	subordinar fondo y foco
Todo lo que aparece parece alerta	exceso de saliencia	separar `emerge` de `signal`
Desaparición ambigua	no se sabe si se ocultó o perdió	distinguir `hide` / `delete + loss`
Fondo visualmente bloqueado pero activo	incoherencia	gestionar foco e interacción
Toast efímero importante	pérdida de información	persistencia / historial

10. Síntesis

Presencia y profundidad comunican existencia perceptiva, plano y régimen.

Presencia pregunta:

PRINCIPIO

¿esto está, aparece, permanece o se retira?

Profundidad pregunta:

PRINCIPIO

¿en qué plano ocurre y qué prioridad tiene?

La tesis del capítulo:

PRINCIPIO

La interfaz no solo muestra elementos. Hace entrar, salir, elevarse, subordinarse y desaparecer partes del contexto operacional.

Reglas centrales:

Aparecer no es advertir.

Aparecer no es cambiar de marco.

Flotar no significa ser importante.

Desaparecer no significa perder.


================================================================================
CAPÍTULO 15 — capitulo15_con_diagramas.docx
================================================================================
CAPÍTULO 15

Forma: límite, affordance e iconografía

Lo que se reconoce antes de colorearse, moverse o sonar

Antes de que una interfaz use color, motion, sonido o háptica, ya está diciendo algo mediante la forma.

Un botón parece pulsable antes de estar coloreado.

Un campo parece editable antes de mostrar validación.

Un icono sugiere una acción antes de recibir un tooltip.

Un borde separa una región antes de que haya profundidad.

Una tarjeta agrupa contenido antes de que se eleve.

Un contorno de foco indica disponibilidad antes de cualquier sonido.

La forma es uno de los canales más discretos de la interfaz, pero también uno de los más persistentes.

No aparece solo cuando ocurre un evento. Está ahí continuamente, estructurando lo que puede tocarse, leerse, separarse, agruparse o reconocerse.

La forma responde a preguntas como:

¿esto es accionable?

¿esto está separado?

¿esto pertenece a este grupo?

¿esto es editable?

¿esto está activo?

¿esto está enfocado?

¿esto representa una acción conocida?

1. Fundamento psicoperceptivo: Gestalt, contorno y affordance

La forma se apoya en dos familias de fundamentos: organización perceptiva y percepción de acción posible.

Desde la organización perceptiva, la Gestalt mostró que el sistema perceptivo tiende a agrupar y separar elementos según proximidad, semejanza, continuidad, cierre, región común y figura/fondo. Un borde puede convertir varios elementos en una región común. Una forma repetida puede indicar pertenencia. Una discontinuidad puede marcar separación. Un contorno cerrado puede hacer que algo se perciba como unidad.

Desde la teoría de affordances, especialmente en Gibson, la forma también sugiere posibilidades de acción. Una superficie con relieve, borde, tamaño táctil y posición estable puede sugerir presión. Un asa visible puede sugerir arrastre. Un campo rectangular con cursor puede sugerir escritura. Un chevron puede sugerir expansión. Un icono de papelera puede sugerir eliminación.

La iconografía añade una capa más: condensa acciones o estados en siluetas aprendidas. Pero los iconos no son universales. Funcionan cuando el sistema cultural, el contexto y la redundancia los sostienen.

Por eso una X puede ser cerrar, cancelar, borrar o eliminar. Un check puede ser seleccionar, confirmar o completar. Un triángulo puede ser play, expansión o advertencia. Un punto rojo puede indicar nuevo, grabando, error o alerta.

La forma no es solo lo que algo parece. Es parte de lo que el sistema ofrece hacer.

2. Forma como límite

Una de las funciones principales de la forma es establecer límite.

Un límite permite saber:

esto es una unidad

esto pertenece aquí

esto no pertenece allí

esto puede manipularse como objeto

esto es una región de acción

Sin límites, la interfaz se vuelve ambigua.

Un bloque de contenido sin borde, sombra, fondo o separación puede no parecer una tarjeta.

Un grupo de botones sin región común puede parecer una lista de acciones inconexas.

Un área de drop sin contorno puede no parecer destino.

Un campo sin forma puede no parecer editable.

Una alerta sin contenedor puede confundirse con texto ordinario.

El límite puede expresarse con borde, fondo, espacio, radio, sombra, contorno, región común o alineación.

No siempre hace falta una línea. A veces el espacio basta. A veces el fondo basta. Pero cuando la estructura lo requiere, debe haber una señal de pertenencia y separación.

3. Forma como affordance

Una forma puede invitar o bloquear acción.

Un botón bien formado no necesita explicar demasiado que puede pulsarse.

Un slider bien formado no necesita decir que puede arrastrarse.

Un input bien formado no necesita tutorial para indicar escritura.

Un chip bien formado sugiere selección, filtro o etiqueta.

Un handle visible sugiere que algo puede moverse.

La forma participa en las familias semánticas antes de que el evento ocurra.

FORMA EN `CONTACT`

Un control debe parecer activable antes de recibir contacto.

button

icon button

toolbar item

card clickable

Si su forma no sugiere acción, el usuario primero debe adivinar que puede actuar.

FORMA EN `COMMIT`

Una opción seleccionable debe distinguirse de texto ordinario.

checkbox

radio

switch

chip

toggle

La forma ayuda a decir:

PRINCIPIO

esto puede quedar elegido.

FORMA EN `SIGNAL`

Una señal necesita forma reconocible para no confundirse con contenido ordinario.

banner

badge

callout

inline error

toast

La forma marca que eso debe leerse como comunicación del sistema.

FORMA EN `HANDLE`

La manipulación necesita affordances explícitas:

drag handle

grip dots

drop zone

resize corner

Si no hay forma que sugiera agarre, la manipulación depende de descubrimiento accidental.

FORMA EN `EMERGE`

Un trigger debe sugerir que puede abrir algo:

chevron

caret

plus

disclosure shape

La forma anticipa el evento de aparición.

FORMA EN `SUSTAIN`

Un proceso necesita una forma que represente continuidad:

bar

circle

skeleton

track

timeline

La forma hace visible el tipo de espera.

Figura 15.1

Crear una matriz visual:

contact → botón / superficie

commit → check / toggle / selected pill

signal → callout / badge / alert

handle → grip / drop zone

emerge → chevron / disclosure

shift → modal shell / stepper

sustain → progress bar / skeleton

PRINCIPIO

La forma puede anticipar, sostener o fijar la lectura semántica de un evento.

4. Forma y estado

La forma también comunica estado.

No solo mediante color. Muchas veces el estado debe poder reconocerse por forma, contorno, icono, densidad, posición o marca.

Ejemplos:

seleccionado

enfocado

desactivado

expandido

colapsado

inválido

editable

arrastrable

bloqueado

Si el estado solo cambia de color, la semántica es frágil.

Una opción seleccionada puede necesitar check, borde, fondo, marca persistente o cambio de peso.

Un campo inválido puede necesitar icono, mensaje, borde y relación espacial.

Un accordion expandido puede necesitar cambio de chevron, contorno y relación con el contenido desplegado.

La forma permite que el estado sobreviva cuando el color no basta o cuando motion se reduce.

5. Forma e intent

La forma no es intent, pero puede reforzarlo.

Un risk puede usar forma de advertencia moderada: icono, callout, borde, contenedor local.

Un threat puede usar forma más contundente: bloque dominante, icono claro, agrupación crítica.

Un loss puede usar formas de ausencia o registro: espacio vacío, estado tachado, undo, recurso retirado.

Un affirm puede usar forma pequeña y estable: check discreto, marca de guardado, estado aplicado.

Un fulfill puede usar forma más resolutiva: check grande, pantalla de completado, progreso al 100%.

Esto es importante porque los intents no deben depender solo del color.

6. Ejemplo narrativo: campo inválido

Un usuario deja vacío un campo obligatorio.

Evento:

signal.warn + risk

Una solución pobre:

border-color: red;

El color cambia, pero el evento depende casi por completo del color.

Una solución semántica:

- borde o contorno;

- icono de advertencia;

- mensaje vinculado;

- forma de callout local;

- relación espacial clara;

- persistencia hasta corrección;

- aria-describedby;

- no solo rojo.

La forma ayuda a responder:

¿dónde está el problema?

¿qué campo afecta?

¿es corregible?

¿qué debo hacer?

El error no debería sentirse como amenaza global si solo es un riesgo local corregible.

7. Ejemplo narrativo: selección de filtro

Un usuario selecciona un filtro en una lista de chips.

Evento:

commit.select + affirm

Si solo cambia el color del chip, puede entenderse, pero depende demasiado del canal cromático.

La forma puede reforzar el estado:

- check interno;

- borde más definido;

- fondo persistente;

- cambio de peso;

- botón de remove;

- posición dentro de un grupo activo.

La pregunta perceptiva es:

PRINCIPIO

¿esto quedó elegido?

La forma debe dejar huella.

Un contacto se siente y desaparece. Una selección debe permanecer.

8. Ejemplo narrativo: área de drop

Un usuario arrastra un archivo a una zona de subida.

Antes de que el archivo entre, la zona debe sugerir que acepta drop.

Eso es forma como affordance.

Recursos posibles:

- contorno discontinuo;

- icono de upload;

- texto breve;

- tamaño suficiente;

- fondo suave;

- cambio de forma al hover;

- estado válido / inválido.

Secuencia:

handle.carry

signal/affordance de destino

handle.drop

commit.upload + affirm/fulfill

Si la zona no tiene forma suficiente, el usuario no sabe dónde soltar.

Si solo se colorea al pasar por encima, quizá llega tarde.

La forma debe anticipar la posibilidad de acción.

9. Accesibilidad de la forma

La forma es crucial para accesibilidad.

Si todo depende de color, la forma debe sostener el significado.

Si una animación se reduce, la forma puede dejar estado persistente.

Si el sonido no está disponible, la forma puede reforzar señal.

Si el usuario usa teclado, el foco debe tener forma clara.

Problemas frecuentes:

- foco invisible;

- iconos sin texto;

- áreas clicables sin forma clara;

- contornos demasiado sutiles;

- targets demasiado pequeños;

- drop zones no accesibles por teclado;

- botones que parecen texto;

- texto que parece botón.

La accesibilidad de la forma no es solo contraste. Es reconocimiento de función.

10. Síntesis

La forma es el canal del límite, la affordance y el reconocimiento estructural.

Comunica:

dónde empieza y termina algo

qué pertenece junto

qué puede hacerse

qué estado tiene

qué acción representa

La tesis:

PRINCIPIO

La forma no dice solo cómo se ve algo. Dice qué es, dónde termina y qué permite hacer.


================================================================================
CAPÍTULO 16 — capitulo16_con_diagramas.docx
================================================================================
CAPÍTULO 16

COLOR: REFUERZO SEMÁNTICO Y VALENCIA

El canal que más hemos confundido con la semántica

El color es uno de los canales más poderosos de la interfaz.

También es uno de los más peligrosos.

Durante décadas, buena parte de la semántica visual se ha delegado en el color: rojo para error, amarillo para advertencia, verde para éxito, azul para información.

Pero el color no es la semántica.

Es un canal que puede reforzarla.

1. Fundamento psicoperceptivo: saliencia, contraste y codificación

------------------------------------------------------------------

El color se apoya en varios mecanismos perceptivos.

El primero es la saliencia. Un color que contrasta con su entorno puede llamar la atención antes de que el usuario lea el contenido.

El segundo es el contraste. El color no se percibe de forma aislada, sino en relación con fondo, luminancia, saturación y contexto.

El tercero es la codificación aprendida. Rojo como peligro, verde como positivo, amarillo como precaución y azul como información funcionan porque los usuarios los han visto muchas veces, no porque formen por sí solos una teoría completa del afecto.

El cuarto es la variabilidad perceptiva. No todos los usuarios distinguen los mismos colores, ni en las mismas condiciones.

Por eso el color es fuerte, pero incompleto.

2. Color e intent

-----------------

El color no define el intent. El intent proviene de la evaluación del evento en el espacio valencia/activación; el color es solo uno de los canales que puede reforzarlo.

Rojo, amarillo, verde o azul no son la semántica. Son recursos expresivos que pueden ayudar a comunicar amenaza, riesgo, confirmación, resolución, pérdida o neutralidad.

La diferencia entre threat y loss no nace de dos tonos de rojo. Nace de una diferencia evaluativa: en threat todavía hay algo que evitar; en loss la consecuencia ya ocurrió.

La diferencia entre affirm y fulfill no nace de dos verdes. Nace de una diferencia entre confirmación suave y resolución positiva. El color puede reforzar esa diferencia, pero no debe sustituirla.

3. La herencia del semáforo

---------------------------

El capítulo 10 desarrolló la crítica al semáforo. Aquí solo aplicamos su consecuencia al canal color.

La convención heredada funciona como atajo cromático, pero no como teoría semántica completa.

Danger mezcla threat y loss. Success mezcla affirm y fulfill. Info mezcla saliencia con evaluación.

El color debe quedar subordinado al evento, no al revés.

4. Accesibilidad cromática

--------------------------

El color no debe ser el único medio para comunicar información crítica.

Error solo en rojo. Link solo por color. Selección solo por fondo verde. Gráfica solo por colores. Validación solo por verde/rojo.

Todo eso es frágil.

El color debe trabajar con forma, icono, texto, posición, patrón, estado persistente y contraste suficiente.

5. Síntesis

-----------

El color orienta atención, refuerza estado, modula valencia y construye identidad visual.

Pero cuando trabaja solo, la semántica queda expuesta.

PRINCIPIO

El color expresa el intent. No lo define.


================================================================================
CAPÍTULO 17 — capitulo17_con_diagramas.docx
================================================================================
CAPÍTULO 17

Sonido: urgencia, valencia y microeventos auditivos

Cuando la interfaz también se oye

La web ha tratado el sonido con desconfianza durante mucho tiempo.

No sin razón.

Durante años, el sonido en interfaces web estuvo asociado a malas prácticas: música automática, anuncios intrusivos, notificaciones insistentes, páginas que sonaban sin permiso, efectos gratuitos y experiencias imposibles de usar en oficinas, bibliotecas, transporte público o espacios compartidos.

La consecuencia cultural fue clara:

PRINCIPIO

mejor que la interfaz no suene.

Esa reacción era comprensible. Pero también produjo una simplificación peligrosa: confundir el mal uso del sonido con la inutilidad del sonido.

El problema histórico no ha sido el sonido en sí.

Ha sido el sonido sin gramática.

Un sonido arbitrario molesta.

Un sonido demasiado largo invade.

Un sonido inesperado sobresalta.

Un sonido repetido fatiga.

Un sonido sin relación clara con el evento parece decoración o ruido.

Pero un sonido breve, proporcionado, sincronizado con el evento y opcional para el usuario puede comunicar cosas que otros canales comunican peor.

1. Fundamento psicoperceptivo: correspondencias, roughness e integración audiovisual

El sonido se apoya en varios fenómenos perceptivos relevantes para la interfaz.

El primero son las correspondencias crossmodales. Charles Spence ha revisado un amplio cuerpo de investigaciones que muestra que las personas tienden a asociar ciertos rasgos auditivos con rasgos visuales o espaciales: pitch alto con objetos más pequeños, brillantes o elevados; pitch bajo con objetos más grandes, oscuros o pesados.

Estas correspondencias no deben leerse como reglas universales cerradas, pero sí como orientaciones útiles para diseñar congruencia entre canales.

Para interfaz, esto significa que el sonido puede reforzar cualidades que también comunica motion o profundidad:

tono más agudo → ligereza, pequeñez, puntualidad

tono más grave → peso, gravedad, cierre

ascenso tonal → apertura, logro, resolución

descenso tonal → cierre, caída, pérdida

timbre limpio → claridad, confirmación, baja tensión

timbre áspero → urgencia, alarma, tensión

El segundo fundamento es la roughness o aspereza acústica. Ciertos timbres ásperos o modulados tienden a aumentar la saliencia y la sensación de alarma. Esto no significa que toda alerta de interfaz deba sonar como alarma. Significa lo contrario: la aspereza acústica tiene tanta carga atencional que debe reservarse para eventos donde esa carga esté justificada.

El tercer fundamento es la integración audiovisual. Cuando un sonido ocurre en sincronía con un movimiento, una aparición o una vibración, el usuario puede percibirlos como un único evento. Si el sonido llega tarde, demasiado pronto o con una cualidad incongruente, se separa de la experiencia y se convierte en ruido añadido.

El cuarto fundamento conecta con el sistema de intents. Las variaciones en pitch, timbre, ataque y duración pueden modular la activación y la valencia percibida del evento. Un fulfill puede admitir un sonido más ascendente o resolutivo. Un risk puede usar un sonido contenido y seco. Un threat puede justificar mayor saliencia. Un loss puede usar descenso, gravedad o decaimiento, no alarma sostenida.

Un sonido no es “amenazante” por una frecuencia aislada. Lo es por la relación entre pitch, timbre, ataque, duración, contexto, volumen, repetición y evento.

2. Qué comunica el sonido

El sonido puede comunicar:

- contacto;

- cierre;

- urgencia;

- valencia;

- presencia fuera de foco;

- materialidad;

- pérdida;

- resolución.

Su fuerza está en que no exige que el usuario mire el lugar donde ocurre el evento.

Una señal visual puede pasar desapercibida si el usuario mira otra zona. Un sonido breve puede alcanzar al usuario aunque su atención visual esté en otro lugar.

Eso no significa que deba usarse para todo.

Significa que, cuando un evento necesita atravesar el campo atencional, el sonido puede ser un canal muy eficaz.

3. Sonido y familias semánticas

CONTACT

contact.press

Un microclick breve puede reforzar que el sistema recibió la acción.

Pero no todos los contactos deben sonar. En interfaces de alta frecuencia, sonorizar cada press se vuelve insoportable.

El sonido de contact debe ser breve, limpio, opcional y fácil de desactivar.

COMMIT

commit.save + affirm

commit.complete + fulfill

commit.delete + loss

El sonido puede marcar cierre o resultado.

affirm puede ser casi imperceptible.

fulfill puede ser más resolutivo.

loss puede ser más grave o descendente.

SIGNAL

signal.notify + neutral

signal.warn + risk

signal.alert + threat

El sonido es especialmente potente en signal, porque puede alcanzar al usuario fuera del foco visual.

Pero también es donde más riesgo hay de invadir.

Una notificación informativa no debería sonar como alarma. Una amenaza crítica sí puede justificar un sonido más saliente.

HANDLE

El sonido puede reforzar pick y drop, no tanto carry.

handle.pick

handle.drop

El carry suele ser silencioso porque es una fase de control continuo. Sonorizar el arrastre completo fatiga.

EMERGE

Normalmente no necesita sonido.

Un tooltip, dropdown o popover no debería sonar salvo que contenga una señal evaluable.

SHIFT

El cambio de marco puede tener sonido en casos específicos, pero normalmente profundidad, foco y motion bastan.

SUSTAIN

El sonido sostenido es peligroso.

Un proceso en curso no debería emitir un loop audible salvo en contextos muy particulares. El sonido puede marcar inicio o fin, pero rara vez debe acompañar toda la espera.

4. Sonido e intent

El sonido puede modular intent con mucha precisión.

neutral → silencio o sonido mínimo

affirm → breve, limpio, suave

fulfill → ascendente, resolutivo

risk → seco, moderado, contenido

threat → saliente, áspero, ataque claro

loss → grave, descendente, seco

La diferencia entre threat y loss es crucial.

Un sonido de amenaza prepara para actuar.

Un sonido de pérdida registra que algo ya ocurrió.

No deben sonar igual.

5. Ejemplo narrativo: autoguardado

Un editor guarda cambios automáticamente.

Evento:

commit.save + affirm

¿Debe sonar?

Depende.

Si el autoguardado ocurre cada pocos segundos, probablemente no. Sería fatigante.

Si ocurre al final de una edición importante, puede haber una confirmación discreta.

Una solución semántica:

- texto “guardado”;

- marca visual breve;

- color positivo discreto;

- sin sonido por defecto;

- sonido opcional si el usuario lo activa.

El intent es affirm, no fulfill.

No hay tensión fuerte que celebrar. Solo normalidad confirmada.

6. Ejemplo narrativo: subida completada

Un usuario sube un archivo grande.

Secuencia:

contact.press

sustain.progress

commit.complete + fulfill

Aquí el sonido puede tener sentido.

Durante sustain, silencio.

Al completar, un sonido breve y resolutivo puede marcar cierre.

El sonido no comunica que el proceso estaba vivo. Eso lo hacía el progreso visual.

El sonido comunica:

PRINCIPIO

ya terminó.

Esto es especialmente útil si el usuario dejó de mirar la barra de progreso.

7. Ejemplo narrativo: alerta crítica

Una sesión está a punto de expirar.

Evento:

signal.alert + threat

Aquí el sonido puede ser apropiado porque:

- el usuario puede no estar mirando;

- hay urgencia;

- todavía puede actuar;

- el evento exige atención.

Pero debe tener límites:

- no sonar indefinidamente;

- no ser exageradamente estridente;

- permitir silencio;

- tener equivalente visual persistente;

- no repetirse sin control.

La alerta sonora debería decir:

PRINCIPIO

atiende ahora.

No:

PRINCIPIO

entra en pánico.

8. Ejemplo narrativo: eliminación

El usuario elimina una tarjeta.

Antes de confirmar:

signal.warn + threat

Puede haber sonido si el evento es grave y requiere atención.

Después de confirmar:

commit.delete + loss

Si hay sonido, debería ser distinto.

threat puede tener más ataque y saliencia.

loss puede ser más seco, grave, descendente o apagado.

El sonido de pérdida no debe sonar como alarma activa, porque ya no hay nada que evitar. Debe registrar consecuencia.

Caja de principio

PRINCIPIO

El sonido de amenaza prepara para actuar. El sonido de pérdida registra que algo ya ocurrió.

9. Sonido y web

En la web, el sonido necesita una doble justificación:

1. perceptiva;

2. social.

Técnicamente puede producirse audio con Web Audio API. Pero hay restricciones reales:

- políticas de autoplay;

- necesidad de gesto del usuario;

- variación entre navegadores;

- dispositivos silenciados;

- entornos compartidos;

- rechazo cultural al audio web.

Por eso en web el sonido debe ser:

- desactivable;

- bajo control del usuario;

- no crítico como única vía;

- breve;

- vinculado a eventos claros;

- probablemente iniciado tras interacción;

- respetuoso con contexto.

10. Accesibilidad sonora

El sonido nunca debe ser el único canal de información crítica.

Usuarios sordos o con hipoacusia pueden no percibirlo.

Usuarios con sonido desactivado no lo recibirán.

Usuarios en entornos ruidosos pueden perderlo.

Usuarios con sensibilidad auditiva pueden rechazarlo.

Por tanto:

- una alerta sonora debe tener equivalente visual;

- una confirmación sonora debe tener estado visible;

- una pérdida sonora debe dejar huella;

- una notificación sonora debe tener texto;

- el usuario debe poder reducir o desactivar sonido.

11. Antipatrones

ANTIPATÓN	PROBLEMA	CORRECCIÓN
sonido decorativo	ruido	vincular a evento
sonido largo	invasión	microsonidos
alerta solo sonora	inaccesibilidad	respaldo visual
mismo sonido para todo	indiferenciación	familias + intents
alarma menor	fatiga	separar `risk` / `threat`
loop de carga	molestia	silencio durante sustain
sin control	rechazo	preferencias

12. Síntesis

El sonido es uno de los canales más peligrosos y más potentes.

Comunica contacto, cierre, urgencia, valencia, pérdida, materialidad y eventos fuera del foco visual.

Su regla central:

PRINCIPIO

Si un sonido no ayuda a reconocer qué ocurrió, cuándo ocurrió o cómo debe evaluarse, probablemente sobra.


================================================================================
CAPÍTULO 18 — capitulo18_con_diagramas.docx
================================================================================
CAPÍTULO 18

Háptica y vibración

Contacto, impacto, resistencia y encaje

La interfaz no solo puede verse u oírse.

También puede sentirse.

Al menos en algunos dispositivos.

Un teléfono puede responder con un pulso breve al tocar una tecla.

Un reloj puede vibrar para avisar de una notificación.

Un mando puede transmitir impacto, fricción o tensión.

Un trackpad puede simular un click que no existe físicamente.

Un sistema móvil puede usar háptica para reforzar selección, error, encaje o alerta.

La háptica es el canal perceptivo que comunica mediante sensación corporal: vibración, presión, resistencia, impacto, textura, pulso o ritmo táctil.

En la web, este canal todavía es limitado. Pero esa limitación técnica no elimina el canal como dimensión teórica.

La teoría debe distinguir:

la háptica como canal perceptivo

la háptica como capacidad disponible en una plataforma concreta

1. Fundamento psicoperceptivo: tacto, cuerpo y acción

La háptica se apoya en un hecho básico: la interacción con el mundo no es solo visual. Tocamos, presionamos, agarramos, soltamos, sentimos resistencia, textura, peso, impacto y vibración.

La percepción táctil y propioceptiva participa en cómo entendemos la acción. Cuando una interfaz simula contacto, no está inventando una categoría nueva. Está apoyándose en una experiencia corporal primaria: tocar algo y recibir una respuesta.

Por eso un pequeño pulso puede reforzar contact.press: el usuario no solo ve que el sistema respondió; lo siente.

La háptica también conecta con esquemas sensoriomotores de la cognición corporeizada. Esquemas como CONTACTO, IMPACTO, RESISTENCIA, ENCAJE o PÉRDIDA tienen una base corporal que puede trasladarse, de forma limitada, a la interfaz.

La investigación sobre tactons ha mostrado que los parámetros hápticos pueden codificar información mediante duración, ritmo, intensidad, localización o frecuencia. Esto permite pensar la háptica como canal semántico, no solo como buzz genérico.

Un pulso breve no comunica lo mismo que una vibración larga.

Un doble pulso no comunica lo mismo que un pulso único.

Un pulso fuerte no comunica lo mismo que uno suave.

Un patrón rítmico no comunica lo mismo que un impacto seco.

La háptica se integra con motion y sonido. Cuando el usuario suelta un objeto y ve que encaja, un pulso háptico sincronizado puede reforzar la sensación de drop. Si el pulso llega tarde, se separa del evento. Si es demasiado fuerte, comunica gravedad donde quizá solo había encaje leve.

2. Qué comunica la háptica

La háptica puede comunicar:

- contacto;

- impacto;

- encaje;

- rechazo;

- resistencia;

- alerta corporal;

- pérdida;

- ritmo.

Mientras motion puede simular la física visual de un evento, la háptica puede reforzar su dimensión corporal.

Un botón que se comprime comunica contacto visual.

Un pulso háptico breve comunica contacto táctil.

Un objeto que se asienta comunica encaje visual.

Un pequeño pulso al soltar comunica encaje corporal.

Una alerta visual comunica urgencia.

Una vibración fuerte o repetida comunica urgencia corporal.

3. Háptica y familias semánticas

CONTACT

contact.press

Es la familia háptica más básica.

Un pulso breve comunica:

PRINCIPIO

el sistema ha sentido mi acción.

Pero no todos los contactos deben vibrar. En interfaces de alta frecuencia, la háptica puede cansar rápidamente.

COMMIT

commit.select + affirm

commit.complete + fulfill

commit.fail + risk

commit.delete + loss

La háptica puede reforzar selección, cierre, rechazo o pérdida.

Un pulso suave puede marcar selección.

Un pulso más definido puede marcar final de operación.

Un patrón de rechazo puede marcar fallo.

Una vibración seca puede marcar pérdida.

SIGNAL

signal.alert + threat

La háptica puede reclamar atención corporal.

Pero debe reservarse para señales importantes. Una vibración por cada notificación menor convierte el cuerpo del usuario en superficie de ruido.

HANDLE

handle.pick

handle.drop

La háptica puede reforzar agarre, encaje, rechazo o destino.

El carry normalmente debería permanecer sin vibración continua, salvo simulaciones especializadas de fricción.

EMERGE

Normalmente no necesita háptica.

Un tooltip, dropdown o popover no debería vibrar al aparecer.

SHIFT

Puede usar háptica en cambios de modo muy significativos, pero con moderación.

SUSTAIN

La háptica sostenida es muy delicada. En general, no debería usarse para procesos continuos.

4. Háptica e intent

La háptica puede modular intent, aunque con menos sutileza que color, motion o sonido en muchas plataformas.

neutral → ausente o mínima

affirm → pulso suave

fulfill → pulso más definido / doble suave

risk → pulso contenido

threat → vibración fuerte o doble

loss → pulso seco / pesado

La diferencia entre threat y loss vuelve a ser importante.

Una amenaza prepara acción.

Una pérdida registra consecuencia.

La háptica de amenaza puede ser más activadora. La de pérdida puede ser más seca y conclusiva.

5. La web y sus límites hápticos

En la web, la háptica sigue siendo un canal débil.

La Vibration API permite patrones básicos de vibración en algunos dispositivos, pero no ofrece control fino sobre textura, intensidad, localización o calidad del motor. Además, su soporte y comportamiento varían entre navegadores y plataformas. Muchos contextos de escritorio no tienen háptica disponible.

Esto significa que en web no podemos asumir la háptica como canal principal.

La teoría puede incluirla, pero la implementación web debe tratarla como:

- opcional;

- degradable;

- nunca única;

- dependiente de dispositivo;

- sujeta a permisos o políticas;

- controlable por el usuario.

La pobreza háptica de la web no invalida la teoría. Solo impone una regla:

PRINCIPIO

En web, la háptica debe ser enriquecimiento, no soporte semántico obligatorio.

6. Ejemplo narrativo: teclado móvil

Un teclado móvil puede usar háptica para reforzar cada tecla.

Evento:

contact.press

La háptica comunica contacto.

Pero el evento es de frecuencia altísima. El usuario puede pulsar cientos de teclas en pocos minutos.

Por eso:

- pulso muy breve;

- intensidad baja;

- desactivable;

- sin variación dramática;

- sin intent fuerte.

Un teclado que vibra demasiado convierte el contacto en fatiga.

Aquí la semántica correcta es casi invisible:

PRINCIPIO

estoy tocando, el sistema responde, puedo seguir.

7. Ejemplo narrativo: selección de chip

El usuario selecciona un filtro.

Evento:

commit.select + affirm

Una háptica suave puede reforzar que la selección quedó aplicada, especialmente en móvil.

Pero no debe sentirse como logro importante.

affirm, no fulfill.

Expresión posible:

- pulso único suave;

- marca visual persistente;

- color positivo leve;

- sin sonido por defecto.

La háptica aquí refuerza estado, no celebra.

8. Ejemplo narrativo: drag-and-drop táctil

En una interfaz táctil, el usuario arrastra una tarjeta.

Secuencia:

handle.pick

handle.carry

handle.drop

PICK

Un pulso breve puede comunicar agarre.

Lectura:

PRINCIPIO

lo has cogido.

CARRY

Normalmente silencio háptico.

El usuario necesita control, no ruido táctil continuo.

DROP VÁLIDO

Pulso de encaje.

Lectura:

PRINCIPIO

encajó aquí.

DROP INVÁLIDO

Pulso de rechazo.

Lectura:

PRINCIPIO

no puede ir aquí.

DROP DESTRUCTIVO

Composición:

handle.drop

commit.delete + loss

La háptica puede comunicar consecuencia, pero con cuidado: no debe parecer amenaza si la pérdida ya ocurrió.

9. Ejemplo narrativo: alerta en wearable

En un reloj, la háptica puede ser el canal principal de una señal.

Evento:

signal.alert + threat

Aquí la vibración tiene sentido porque:

- la pantalla es pequeña;

- el usuario puede no estar mirando;

- el dispositivo está en contacto con el cuerpo;

- la señal puede requerir atención inmediata.

Pero incluso aquí debe haber control:

- patrón reconocible;

- duración limitada;

- posibilidad de silenciar;

- prioridad bien definida;

- no usar el mismo patrón para todo.

La háptica de wearable puede ser muy efectiva, pero precisamente por eso debe ser sobria.

10. Accesibilidad háptica

La háptica puede ayudar a algunas personas y molestar a otras.

Puede servir como canal alternativo cuando el sonido está desactivado.

Puede reforzar contacto.

Puede ayudar en wearables o contextos donde la visión está ocupada.

Pero también puede ser problemática:

- sensibilidad táctil;

- vibración molesta o dolorosa;

- fatiga por repetición;

- dispositivos con vibración demasiado brusca;

- falta de control de intensidad;

- patrones indistinguibles;

- interferencia con ayudas de accesibilidad.

Por eso la háptica debe ser:

- desactivable;

- proporcional;

- infrecuente cuando es intensa;

- nunca única para información crítica;

- ajustable si la plataforma lo permite;

- coherente con el evento.

La accesibilidad háptica no consiste en añadir vibración para “mejorar accesibilidad”. A veces la vibración reduce accesibilidad.

11. Antipatrones

ANTIPATRÓN	PROBLEMA	CORRECCIÓN
vibrar por todo	fatiga corporal	reservar para eventos relevantes
mismo buzz para todo	indiferenciación	variar duración, ritmo, intensidad
háptica crítica sin respaldo	inaccesibilidad	canales alternativos
háptica desincronizada	ruido	sincronía con press/drop/señal
intensa y frecuente	rechazo	reducir intensidad
asumir háptica rica en web	inconsistencia	tratar como opcional

12. Síntesis

La háptica es el canal corporal de la interfaz.

Comunica contacto, impacto, encaje, rechazo, resistencia, alerta y pérdida mediante sensación táctil.

Su fuerza está en que hace sentir el evento en el cuerpo.

Su riesgo está precisamente ahí: puede invadir, fatigar o excluir si se usa mal.

La tesis:

DISTINCIÓN

La háptica no es vibración añadida. Es la posibilidad de hacer corporalmente perceptible un evento.

Regla práctica:

PRINCIPIO

Diseñar la semántica para que pueda vivir sin háptica, y enriquecerla con háptica cuando la plataforma y el usuario lo permitan.


================================================================================
CAPÍTULO 19 — capitulo19_con_diagramas.docx
================================================================================
CAPÍTULO 19

ACCESIBILIDAD PERCEPTIVA Y REDUCCIÓN DE CANALES

Cuando no todos perciben el mismo evento

Una teoría multicanal tiene una obligación inmediata: no puede asumir que todos los usuarios perciben los mismos canales, con la misma intensidad, en las mismas condiciones y con la misma tolerancia.

La accesibilidad no debería aparecer al final como cumplimiento. En este libro ocupa un lugar más profundo:

PRINCIPIO

La accesibilidad es la prueba de estrés de una semántica perceptiva.

1. Fundamento psicoperceptivo: variabilidad perceptiva y redistribución del significado

--------------------------------------------------------------------------------------

La accesibilidad perceptiva se apoya en una idea simple: no todos los usuarios disponen de los mismos canales en las mismas condiciones.

La visión puede estar reducida. El color puede no discriminarse. El sonido puede estar desactivado. El movimiento puede producir malestar. La háptica puede no existir. La atención puede estar fragmentada. El tiempo de procesamiento puede variar.

Esto significa que una semántica perceptiva no puede depender de una única vía sensorial.

Los fundamentos del Capítulo 3 ayudan a entender por qué:

- la Gestalt explica que la organización visual puede fallar si figura, fondo o agrupación no son claras;

- las affordances explican que una acción puede no percibirse como disponible si su forma no la sugiere;

- la atención explica que una señal puede no alcanzar el foco si no tiene suficiente saliencia;

- el appraisal explica que una evaluación puede perderse si el evento no comunica riesgo, pérdida o resolución;

- el espacio valencia/activación explica que el intent puede perderse si solo vive en color;

- la multisensorialidad explica que un evento puede sobrevivir si su significado migra entre canales;

- la cognición corporeizada explica que algunos usuarios pueden necesitar otras vías para percibir contacto, encaje o resistencia.

La pregunta central no es solo:

PRINCIPIO

¿puede el usuario acceder al componente?

Sino:

PRINCIPIO

¿puede comprender qué evento ocurrió y qué implica?

2. Canal único y fragilidad

---------------------------

Si el significado crítico vive en un solo canal, la semántica es vulnerable.

Error solo rojo. Contacto solo motion. Alerta solo sonido. Pérdida solo desaparición. Progreso solo spinner. Selección solo color.

Todos son frágiles.

3. Migración semántica

----------------------

Cuando un canal se reduce, no basta con quitarlo. Hay que preguntar:

PRINCIPIO

¿qué significado transportaba ese canal?

Si motion transportaba causalidad, debe migrar a estado, texto, sonido o háptica. Si color transportaba valencia, debe migrar a forma, icono, texto o posición. Si sonido transportaba urgencia, debe migrar a presencia, persistencia o live region. Si háptica transportaba encaje, debe migrar a motion, forma o sonido.

4. Accesibilidad y familias

---------------------------

Contact debe sobrevivir sin motion. Commit debe dejar huella. Signal no puede depender solo de color o sonido. Handle necesita alternativas a drag. Emerge debe sincronizar presencia visual y operativa. Shift debe gestionar foco y orientación. Sustain necesita texto, estado y control.

5. Síntesis

-----------

La accesibilidad perceptiva no es una excepción al sistema. Es la prueba de que familias, intents y canales no dependen de una condición ideal de percepción.

Una interacción semántica es robusta cuando conserva su significado bajo condiciones variables.


================================================================================
CAPÍTULO 20 — capitulo20_con_diagramas.docx
================================================================================
CAPÍTULO 20

COORDINACIÓN MULTICANAL

Cuando varios canales dicen un solo evento

Una interfaz semántica no consiste en activar muchos canales.

Consiste en que, cuando varios canales participan, digan lo mismo.

O mejor:

PRINCIPIO

que participen en la misma lectura del evento.

1. Fundamento psicoperceptivo: integración multisensorial y congruencia

-----------------------------------------------------------------------

La coordinación multicanal se apoya en un principio general de la percepción: el sistema perceptivo tiende a integrar señales de distintas modalidades cuando parecen pertenecer al mismo evento.

Esa integración depende de varios factores:

- proximidad temporal;

- correspondencia espacial;

- congruencia semántica;

- intensidad compatible;

- relación causal plausible;

- expectativas previas;

- coherencia afectiva.

Si un movimiento, un sonido y una vibración ocurren en el momento adecuado y parecen corresponder al mismo tipo de evento, el usuario puede percibirlos como una unidad.

Si llegan desfasados, con intensidades contradictorias o con significados afectivos distintos, se separan.

La idea de integración temporal explica por qué un sonido de contacto que llega tarde se percibe como añadido, no como parte del press. La correspondencia crossmodal explica por qué un objeto que se mueve como algo pesado pero suena como algo ligero produce conflicto. La teoría de valencia/activación explica por qué los canales deben modular el mismo intent.

2. La secuencia completa del sistema

------------------------------------

La coordinación no empieza en los canales. Empieza en el evento.

La secuencia completa es:

evento interactivo

→ familia semántica

→ verbo / fase

→ evaluación si procede

→ intent

→ canales coordinados

Si se rompe esta secuencia, aparecen errores:

- canales sin evento;

- intent sin familia;

- color sin evaluación;

- sonido sin necesidad;

- motion sin semántica;

- accesibilidad como parche posterior.

3. Congruencia

--------------

La coordinación exige congruencia temporal, semántica, afectiva, de intensidad y accesible.

4. Redundancia significativa

----------------------------

La redundancia no es repetir por repetir.

Es hacer que el significado sobreviva cuando un canal falla.

5. Sobrecarga

-------------

La alternativa a la fragilidad no es saturación.

Una interfaz puede activar demasiados canales: cada click vibra, cada confirmación suena, cada cambio rebota, cada error interrumpe, cada success celebra.

El resultado no es claridad. Es fatiga.

6. Síntesis

-----------

La Parte II ha separado los canales para poder entenderlos.

Pero el usuario no vive esos canales separados.

La interfaz debe volver a unirlos.

La tesis:

DISTINCIÓN

Una interacción semántica multicanal no es una colección de efectos. Es una composición perceptiva orientada a un único evento.

CIERRE DE LA PARTE II

Con este capítulo se cierra la Parte II.

Hemos separado los canales para poder entenderlos:

- tiempo;

- motion;

- presencia;

- profundidad;

- forma;

- color;

- sonido;

- háptica;

- accesibilidad;

- coordinación multicanal.

Pero el usuario no vive esos canales como capas separadas. Los vive como un único evento, o como ruido si la coordinación falla.

La tesis de esta parte puede formularse así:

PRINCIPIO

El evento es la unidad de significado. Los canales son la materia sensible. La coordinación convierte esa materia en experiencia perceptiva unificada.

La siguiente parte volverá al eje semántico del sistema: las familias del evento. Allí veremos cómo contact, commit, signal, handle, emerge, shift y sustain no son categorías abstractas, sino formas recurrentes de organizar acción, consecuencia, atención, manipulación, presencia, marco y continuidad.

FIN DE LA PARTE II REESCRITA


================================================================================
CAPÍTULO 21 — capitulo21_con_diagramas.docx
================================================================================
Capítulo 21

Las familias semánticas del evento

Qué nombran, de dónde vienen y cómo se usan

Hasta aquí, el libro ha construido una serie de piezas:

- la interfaz como dimensión perceptible de un contexto operacional;

- el evento interactivo como unidad mínima de significado;

- una gramática del evento;

- las interacciones semánticas;

- criterios para identificar diferencias relevantes;

- la distinción entre eventos valenciales y transicionales;

- un sistema de intents;

- y una teoría de canales perceptivos.

A partir de este punto, el libro cambia de plano.

Deja de construir la teoría general y empieza a recorrer, una por una, las familias que organizan la semántica del evento interactivo.

Pero antes de entrar en cada familia, conviene responder tres preguntas:

Principio

¿Qué es exactamente una familia semántica? ¿De dónde sale este conjunto concreto? ¿Cómo debe leerse dentro del sistema?

1. Qué es una familia semántica

Una familia semántica no es un componente.

No es un botón, ni un modal, ni un toast, ni un dropdown, ni un loader.

Tampoco es un efecto.

No es un fade, ni un slide, ni un bounce, ni un sonido, ni una vibración.

Una familia semántica es:

Principio

una clase de evento perceptivamente recurrente que responde a una misma pregunta del usuario.

Por ejemplo:

contact → ¿el sistema ha sentido mi acción?

commit → ¿algo quedó fijado o tuvo consecuencia?

signal → ¿algo reclama mi atención?

handle → ¿estoy manipulando directamente algo?

emerge → ¿algo entró o salió del campo?

shift → ¿cambió el marco operativo?

sustain → ¿esto sigue ocurriendo?

Estas preguntas no son arbitrarias. Surgen de cómo el usuario organiza la experiencia interactiva: acción, respuesta, proceso, atención, presencia, manipulación, consecuencia.

Una familia no describe cómo se implementa algo.

Describe qué tipo de evento está ocurriendo.

2. De dónde salen las siete familias

Las familias no aparecen por enumeración arbitraria.

El sistema partió de un conjunto más amplio de semánticas exploratorias: feedback, selection, revelation, context, expansion, navigation, notification, attention, emphasis, completion, destruction, persistence y manipulation.

Ese conjunto era útil para descubrir diferencias. Pero era demasiado granular como sistema canónico.

Al aplicar criterios de relevancia operativa, diferenciabilidad perceptiva, recurrencia, capacidad de composición, economía cognitiva y compatibilidad multicanal, el conjunto se redujo a siete familias:

contact

commit

signal

handle

emerge

shift

sustain

No son las únicas posibles en un sentido absoluto, pero forman un conjunto mínimo y suficiente para describir la mayoría de eventos interactivos sin redundancia excesiva.

Cada familia cubre una región distinta del espacio de interacción:

- acción → contact

- consecuencia → commit

- atención → signal

- manipulación → handle

- presencia → emerge

- marco → shift

- proceso → sustain

3. Fundamento psicoperceptivo de las familias

Las familias no son categorías de diseño. Son categorías perceptivas.

Cada una nombra una estructura recurrente de la experiencia:

Familia	Fundamento perceptivo dominante
`contact`	agencia, causalidad inmediata, esquema táctil
`commit`	cierre, consecuencia, memoria de estado
`signal`	atención, saliencia, orientación
`handle`	control motor, manipulación, continuidad sensorimotora
`emerge`	figura/fondo, presencia, aparición perceptiva
`shift`	cambio de marco, orientación, modelo mental
`sustain`	continuidad temporal, espera, reducción de incertidumbre

Esto es importante.

Si las familias se presentan solo como “eventos de UI”, pueden parecer inventadas. Pero no lo son. Son nombres operativos para estructuras que el usuario ya experimenta en la interacción.

El libro no inventa esas estructuras. Las hace explícitas.

4. Qué no son las familias

No son componentes

Un modal no es una familia.

Puede participar en:

shift.enter-mode

signal.alert + threat

Un dropdown no es una familia.

Puede ser:

emerge.open

Un botón no es contact. Un botón puede participar en contact.press, pero también en commit, signal o shift según el evento.

No son efectos

Un fade no es emerge.

Un slide no es shift.

Un bounce no es fulfill.

Un shake no es threat.

Los efectos son realizaciones posibles en canales. La familia es el evento.

No son estados

“Loading”, “error”, “success” no son familias.

Son mezclas de familia, verbo e intent:

loading → sustain.progress

error → commit.fail + risk

success → commit.complete + fulfill

5. La estructura completa del sistema

Una familia no actúa sola.

Forma parte de una estructura mayor:

familia.verbo + intent

Ejemplos:

contact.press + neutral

commit.save + affirm

commit.complete + fulfill

signal.warn + risk

signal.alert + threat

commit.delete + loss

handle.drop + risk

La familia nombra el tipo de evento.

El verbo concreta la acción.

El intent modula la evaluación.

Y todo eso se expresa mediante canales:

tiempo

motion

presencia

profundidad

forma

color

sonido

háptica

6. Familias y evaluabilidad

No todas las familias aceptan intent de la misma manera.

Familia	Relación con intent
`contact`	leve, anticipatoria
`commit`	plena
`signal`	plena
`handle`	sobre todo en `drop`
`emerge`	normalmente no
`shift`	normalmente no
`sustain`	normalmente no

Esta no es una prohibición rígida, pero sí una regla de claridad:

Principio

el intent vive donde hay evaluación del evento, no donde solo hay organización del campo.

7. Cómo leer los capítulos de familias

Cada familia se desarrollará desde ocho planos:

1. qué pregunta responde;

2. qué eventos incluye;

3. cuál es su fundamento psicoperceptivo;

4. qué canales la expresan mejor;

5. cómo se relaciona con intent;

6. ejemplos prácticos;

7. riesgos y antipatrones;

8. consideraciones de accesibilidad.

No se trata de describir componentes, sino patrones de evento.

8. Ejemplo transversal

Tomemos una acción simple: eliminar un elemento.

contact.press

signal.warn + threat

commit.delete + loss

Tres familias distintas:

- contact → acción registrada;

- signal → advertencia;

- commit → consecuencia.

Tres preguntas distintas:

¿he pulsado?

¿puedo evitarlo?

¿qué ocurrió?

Si todo se tratara como un solo estado danger, se perderían esas distinciones.

9. Síntesis

Las familias semánticas son el eje de la gramática del evento.

No describen componentes, ni estilos, ni efectos, ni estados. Describen clases de evento perceptivamente recurrentes.

Familia	Pregunta
`contact`	¿el sistema ha sentido mi acción?
`commit`	¿algo quedó fijado o tuvo consecuencia?
`signal`	¿algo reclama mi atención?
`handle`	¿estoy manipulando algo directamente?
`emerge`	¿algo entró o salió del campo?
`shift`	¿cambió el marco operativo?
`sustain`	¿esto sigue ocurriendo?

La tesis del capítulo:

Principio

La interfaz no se organiza solo en componentes. Se organiza en familias de eventos que responden a preguntas perceptivas recurrentes.

Fig. 1 — Las familias son respuestas a preguntas perceptivas recurrentes.

Fig. 2 — La familia define qué ocurre. El intent cómo se evalúa. Los canales lo hacen perceptible.


================================================================================
CAPÍTULO 22 — capitulo22_con_diagramas.docx
================================================================================
Capítulo 22

Contact

La respuesta mínima del sistema a la acción del usuario

Antes de que una interfaz confirme, advierta, complete, falle o pierda algo, ocurre un momento previo.

El usuario actúa.

Pulsa. Toca. Hace click. Arrastra. Escribe. Activa.

Y entonces aparece una pregunta inmediata:

Principio

¿El sistema ha sentido mi acción?

Ese momento es contact.

1. Qué es `contact`

Contact es la familia semántica de la recepción de la acción.

No comunica resultado. No comunica éxito. No comunica error. No comunica estado final.

Comunica algo más básico:

Principio

la acción del usuario ha entrado en el sistema.

Ejemplos:

contact.press

contact.tap

contact.activate

contact.focus

contact.trigger

Un botón que se hunde ligeramente. Una tecla virtual que responde al toque. Un switch que muestra estado pressed. Un item que empieza a estar bajo el dedo.

Todo eso pertenece a contact.

2. Qué no es `contact`

contact no es commit.

contact.press ≠ commit.save

El sistema puede haber recibido la acción sin haber producido todavía resultado.

contact no es signal.

contact.press ≠ signal.warn

No reclama atención ni advierte. Solo registra acción.

contact no es handle.

contact.press ≠ handle.pick

Puede iniciar una manipulación, pero no es la manipulación.

contact no es intent.

contact.press + neutral

puede ser suficiente.

contact es anterior a la evaluación.

3. Fundamento psicoperceptivo: agencia, causalidad inmediata y esquema táctil

contact se apoya en la percepción de agencia: la tendencia del usuario a atribuir un cambio al propio gesto cuando la respuesta ocurre con suficiente proximidad temporal y formal.

Cuando el sistema responde inmediatamente al gesto, el usuario percibe:

yo hice esto → el sistema respondió

Si la respuesta se retrasa:

yo hice esto → … → algo ocurrió

la relación causal se debilita.

Este fundamento conecta con la percepción de causalidad dinámica: ciertos cambios próximos en el tiempo y coherentes en su forma tienden a organizarse como relación causa-efecto. En interfaz, la microrespuesta de un control preserva esa lectura causal.

También se apoya en esquemas sensorimotores básicos. Tocar algo y recibir una respuesta es una experiencia corporal primaria: presión, resistencia, rebote, click, vibración. La interfaz digital toma prestada esa estructura para hacer que una acción abstracta se sienta registrada.

Por eso contact no es decoración. Es la semántica mínima de agencia.

4. La pregunta perceptiva

contact responde a:

Principio

¿el sistema ha sentido mi acción?

Si la respuesta es clara, el usuario continúa.

Si no, aparecen comportamientos compensatorios:

- doble click;

- repetición del toque;

- espera insegura;

- frustración;

- abandono de la operación.

Muchos problemas de UX no son errores funcionales. Son fallos de contact.

5. Contact y latencia

El canal crítico de contact es el tiempo.

Latencia	Lectura
muy baja	contacto
media	respuesta
alta	duda / desconexión

Un contacto correcto:

input → feedback inmediato

Un contacto fallido:

input → silencio → feedback

Esto no es un problema estético. Es un problema semántico.

Principio

Un contacto bonito pero tardío es peor que un contacto simple pero inmediato.

6. Canales de `contact`

contact suele apoyarse en pocos canales.

Canal	Función
Tiempo	respuesta inmediata
Motion	microrespuesta
Forma	estado pressed / foco
Sonido	click breve opcional
Háptica	pulso breve opcional
Color	secundario

El color puede acompañar, pero no debe ser el canal principal. El contacto se siente sobre todo por tiempo, microcambio y relación causal.

7. Contact y verbos

contact no es un único gesto.

press

tap

activate

focus

trigger

Ejemplos:

contact.press

contact.focus

contact.trigger

Cada uno mantiene la misma lógica:

Principio

acción registrada, no resultado.

8. Contact frente a Commit

Ejemplo clave:

contact.press

commit.save + affirm

contact dice:

Principio

he pulsado.

commit dice:

Principio

se guardó.

Error típico:

contact.press + fulfill

Esto hace que el sistema diga “ya terminó” cuando solo ha empezado.

Principio

Contact inicia. Commit resuelve.

9. Contact frente a Signal

contact.press

signal.warn + risk

Contact:

Principio

he actuado.

Signal:

Principio

atiende esto.

No deben mezclarse. Un contacto no debería reclamar atención si todavía no hay nada que evaluar.

10. Contact en componentes web

Botón

contact.press

microcompresión, estado pressed, retorno rápido.

Input

contact.focus

cursor visible, contorno, foco.

Toggle

contact.press

commit.toggle + affirm

el press registra; el toggle fija.

Link

contact.press

shift.navigate

la presión no es la navegación.

Drag

contact.press

handle.pick

el contacto inicia el agarre, pero no lo agota.

11. Contact e intent

Normalmente:

contact + neutral

o incluso sin intent explícito.

En acciones graves, la interfaz puede anticipar el peso mediante forma, color o señal previa, pero el intent fuerte no debería vivir en el contacto, sino en la señal o consecuencia posterior.

Ejemplo:

contact.press

signal.warn + threat

commit.delete + loss

12. Contact y accesibilidad

contact debe sobrevivir sin motion, sonido o háptica.

Canal ausente	Sustituto
Motion	estado pressed, foco visible
Sonido	estado visual
Háptica	tiempo + forma
Visión	anuncio o feedback auditivo si procede

Si el usuario duda si ha actuado, el problema no es solo de rendimiento. Es de semántica de contacto.

13. Antipatrones

Antipatrón	Problema
Contacto tardío	rompe agencia
Contacto exagerado	teatraliza acciones menores
Contacto como éxito	promete resultado antes de tiempo
Sin feedback	incertidumbre
Solo color	feedback débil o inaccesible
Sonido en todo	fatiga

14. Síntesis

contact es la familia de la agencia mínima.

No evalúa. No resuelve. No advierte.

Responde a una única pregunta:

Principio

¿el sistema ha sentido mi acción?

Su regla práctica:

Principio

Cuanto más frecuente es una acción, más inmediato y más discreto debe ser su contacto.

Fig. 1 — La percepción de agencia depende de la proximidad entre acción y respuesta.


================================================================================
CAPÍTULO 23 — capitulo23_con_diagramas.docx
================================================================================
Capítulo 23

Commit

Cuando algo queda fijado, seleccionado, completado o perdido

Si contact responde a:

Principio

¿el sistema ha sentido mi acción?

commit responde a una pregunta distinta y decisiva:

Principio

¿qué ha pasado como consecuencia de esa acción?

Aquí es donde la interfaz deja de registrar gestos y empieza a producir realidad operativa.

Algo queda seleccionado. Algo se guarda. Algo se envía. Algo se completa. Algo falla. Algo se descarta. Algo se elimina. Algo se pierde.

Ese momento —cuando el sistema fija un estado o produce una consecuencia— es commit.

1. Qué es `commit`

Commit es la familia semántica de la fijación de estado o consecuencia.

No es el inicio. No es el proceso. No es la advertencia.

Es el momento en que el sistema dice:

Principio

esto ya ocurrió.

Ejemplos:

commit.select

commit.save

commit.submit

commit.complete

commit.fail

commit.delete

commit.restore

commit.cancel

commit.expire

commit.discard

Todos comparten una propiedad:

Distinción

después de este evento, el sistema ya no es exactamente el mismo que antes.

2. Qué no es `commit`

commit no es contact.

contact.press ≠ commit.save

El sistema puede haber recibido la acción sin haber producido todavía el resultado.

commit no es sustain.

sustain.progress ≠ commit.complete

El proceso puede seguir en curso.

commit no es signal.

signal.warn ≠ commit.fail

Una advertencia no es un resultado.

commit no es shift.

shift.navigate ≠ commit.submit

Cambiar de pantalla no equivale a completar una operación.

3. Fundamento psicoperceptivo: cierre, consecuencia y memoria de estado

commit se apoya en una necesidad fundamental de la acción: saber cuándo una operación produjo consecuencia.

El usuario no solo necesita actuar. Necesita saber qué quedó después de actuar.

Esta familia se sostiene sobre tres dimensiones psicoperceptivas:

3.1. Cierre cognitivo

Una acción abierta genera incertidumbre. El usuario necesita percibir cuándo puede dejar de vigilarla. commit cierra la secuencia.

acción → resultado

Sin cierre, la acción queda suspendida.

3.2. Consecuencia operativa

El usuario necesita saber si algo cambió en el sistema: una opción quedó marcada, un documento fue guardado, un archivo se eliminó, una operación falló.

3.3. Memoria de estado

Un buen commit deja huella. No desaparece como un contacto. Puede quedar como estado seleccionado, mensaje, ausencia, historial, undo, marca de completado o error persistente.

Por eso commit no solo ocurre. Se recuerda.

4. La pregunta perceptiva

commit responde:

Principio

¿qué ha quedado fijado?

O:

¿se guardó?

¿se eligió?

¿se envió?

¿se completó?

¿falló?

¿se perdió?

5. Verbos de `commit`

commit tiene verbos que definen el tipo de consecuencia:

select

toggle

save

submit

complete

fail

delete

restore

cancel

reset

expire

discard

Ejemplos:

commit.select + affirm

commit.complete + fulfill

commit.fail + risk

commit.delete + loss

6. Tipos de commit

6.1. Fijación de estado

commit.select

commit.toggle

commit.save

Lectura:

Principio

algo queda aplicado o guardado.

6.2. Resolución de proceso

commit.complete

commit.submit

commit.fail

Lectura:

Principio

un proceso terminó.

6.3. Consecuencia irreversible o crítica

commit.delete

commit.discard

commit.expire

Lectura:

Principio

algo deja de estar disponible.

Tipo	Ejemplo	Lectura
Estado	`commit.select`	esto queda elegido
Proceso	`commit.complete`	esto terminó
Consecuencia	`commit.delete`	esto ya no está

7. Canales de `commit`

A diferencia de contact, commit suele requerir huella.

Canal	Función
Forma	estado persistente
Presencia	aparición o retirada
Motion	asentamiento o cierre
Color	refuerzo de estado o valencia
Sonido	cierre opcional
Háptica	impacto o encaje opcional
Tiempo	marca el momento de resolución

8. Commit e intent

commit es una de las familias donde el intent vive con más fuerza.

`affirm`

commit.save + affirm

Lectura:

Principio

todo va bien.

`fulfill`

commit.complete + fulfill

Lectura:

Principio

objetivo logrado.

`risk`

commit.fail + risk

Lectura:

Principio

algo no se completó, revisa.

`loss`

commit.delete + loss

Lectura:

Principio

esto ya se perdió.

El intent no cambia el evento. Cambia cómo se evalúa su consecuencia.

9. Commit vs Contact

contact.press

commit.save + affirm

Error común:

contact.press + fulfill

Problema:

Principio

se celebra antes de saber el resultado.

10. Commit vs Sustain

sustain.progress → commit.complete

sustain mantiene.

commit cierra.

Confundirlos produce incertidumbre.

11. Ejemplos prácticos

Guardar

contact.press

sustain.progress

commit.save + affirm

Enviar

contact.press

sustain.progress

commit.submit + fulfill

Error

contact.press

commit.fail + risk

Eliminación

signal.warn + threat

commit.delete + loss

Toggle

contact.press

commit.toggle + affirm

12. Accesibilidad

commit debe ser visible, persistente y comprensible.

Debe sobrevivir sin color, sonido o motion.

Canal ausente	Sustituto
Color	forma + texto
Motion	estado persistente
Sonido	mensaje visible
Háptica	estado + motion

Si el usuario no sabe qué ocurrió después de actuar, el commit falló.

13. Antipatrones

Antipatrón	Problema
Sin commit visible	incertidumbre
Commit efímero	no deja huella
Todo es success	trivializa resultados
Todo es danger	mezcla pérdida y amenaza
Celebración constante	fatiga
Sin diferencia entre affirm y fulfill	pérdida de matiz
Resultado solo en color	inaccesible

14. Síntesis

commit es la familia donde la interfaz produce consecuencias.

Comunica:

Dimensión	Pregunta
Estado	¿qué quedó aplicado?
Resultado	¿qué ocurrió?
Cierre	¿puedo continuar?
Consecuencia	¿qué cambió en el sistema?
Evaluación	¿cómo debo interpretarlo?

La tesis:

Distinción

El significado de la interfaz no está en el click. Está en lo que queda después.

Regla principal:

Principio

Todo evento importante debe dejar una huella perceptible de su consecuencia.

Fig. 1 — Después de commit, el sistema ya no es el mismo que antes.


================================================================================
CAPÍTULO 24 — capitulo24_con_diagramas.docx
================================================================================
Capítulo 24

Signal

Cuando el sistema reclama atención

Si contact responde a:

Principio

¿el sistema ha sentido mi acción?

y commit responde a:

Principio

¿qué ha pasado como consecuencia?

signal responde a una pregunta distinta:

Principio

¿debo atender esto?

Aquí el flujo se invierte.

No es el usuario quien actúa primero. Es el sistema quien orienta, interrumpe o reclama la atención.

Una advertencia antes de eliminar. Un error en un campo. Un badge que indica algo nuevo. Una notificación. Un mensaje informativo. Un aviso de expiración de sesión. Una validación. Una señal de progreso que requiere atención.

Todo eso pertenece a signal.

1. Qué es `signal`

Signal es la familia semántica de la orientación y reclamación de atención.

No ejecuta una acción. No fija un resultado. No cambia el marco por sí sola.

Hace algo más básico:

Principio

dirige la percepción del usuario hacia algo relevante.

Ejemplos:

signal.announce

signal.notify

signal.warn

signal.alert

signal.inform

signal.emphasize

signal.remind

2. Qué no es `signal`

signal no es commit.

signal.warn ≠ commit.fail

Una advertencia no es un resultado. Un resultado puede necesitar señal, pero no son lo mismo.

signal no es contact.

No es respuesta a acción. Puede aparecer sin gesto directo.

signal no es emerge.

emerge.open ≠ signal

Algo puede aparecer sin reclamar atención.

signal no es shift.

Un modal no es la señal. El mensaje dentro puede serlo.

3. Fundamento psicoperceptivo: atención, saliencia y carga cognitiva

signal se apoya en la orientación atencional.

La percepción no procesa todo por igual. El sistema atencional decide qué entra en foco, qué queda en fondo, qué se pospone y qué interrumpe.

Una señal puede:

- orientar la atención;

- informar;

- advertir;

- interrumpir;

- mantener algo en vigilancia;

- fatigar.

El concepto clave es saliencia: la capacidad de un estímulo para destacar del fondo y reclamar procesamiento.

Pero la saliencia tiene coste.

Demasiada saliencia produce ruido. Poca saliencia produce invisibilidad.

Por eso signal no es simplemente “mostrar algo”. Es regular cuánta atención se pide.

Esta familia se apoya en mecanismos de orientación atencional y en la distinción entre estímulos que simplemente aparecen y estímulos que exigen procesamiento.

4. La pregunta perceptiva

signal responde:

Principio

¿debo notar esto?

Y, en casos de mayor urgencia:

Principio

¿debo actuar ahora?

5. Tipos de señal

5.1. `signal.announce`

signal.announce + neutral

Comunica:

Principio

esto existe, sin urgencia.

5.2. `signal.notify`

signal.notify + neutral / affirm

Comunica:

Principio

algo ocurrió, pero no requiere acción inmediata.

5.3. `signal.warn`

signal.warn + risk

Comunica:

Principio

revisa esto.

5.4. `signal.alert`

signal.alert + threat

Comunica:

Principio

atiende ahora.

Tipo	Intent	Lectura
announce	neutral	existe
notify	neutral / affirm	ocurrió algo
warn	risk	revisa
alert	threat	actúa ahora

6. Canales de `signal`

signal es una familia multicanal fuerte.

Canal	Función
Presencia	aparición visible
Forma	separar de contenido
Color	valencia y saliencia
Texto	significado explícito
Tiempo	persistencia
Motion	entrada / énfasis
Sonido	opcional, fuera de foco
Háptica	opcional, alertas

El texto es especialmente importante. Es el canal que puede explicar con precisión qué ocurre y qué debe hacer el usuario.

7. Signal e intent

La relación con intent es central.

signal + intent

- signal.announce + neutral → sin carga afectiva fuerte.

- signal.notify + affirm → confirmación ligera.

- signal.warn + risk → problema corregible.

- signal.alert + threat → urgencia.

loss es menos común en signal, porque la pérdida suele vivir en commit. Pero una señal puede anunciar una pérdida ya ocurrida:

signal.announce + loss

si lo que el sistema hace es comunicar una consecuencia previa.

8. Signal vs Emerge

emerge.open

signal.warn + risk

- emerge → aparece algo.

- signal → eso que aparece importa.

Error común:

emerge.open + danger

Se está cargando el contenedor, no el evento evaluable.

9. Signal vs Commit

signal.warn + risk

commit.fail + risk

- signal puede ocurrir antes o durante.

- commit ocurre como resultado.

Ejemplo:

signal.warn + risk

Principio

revisa este campo.

commit.fail + risk

Principio

la operación no se completó.

10. Ejemplos prácticos

Error de formulario

signal.warn + risk

- forma: inline;

- color: moderado;

- texto: claro;

- persistente hasta corrección.

Notificación informativa

signal.notify + neutral

- presencia leve;

- no interrumpe.

Alerta crítica

signal.alert + threat

- presencia fuerte;

- posible sonido;

- persistente hasta acción.

Información contextual

signal.announce + neutral

No es intent info. Es señal neutra.

11. Accesibilidad

signal es la familia más crítica en accesibilidad.

Debe:

- no depender solo de color;

- tener texto claro;

- ser persistente si importa;

- usar live region si procede;

- no ser solo sonora;

- no desaparecer demasiado rápido;

- no interrumpir sin necesidad.

Problema	Solución
solo color	añadir texto/icono
solo sonido	añadir visual
efímero	persistencia
fuera de foco	live region
exceso de alerta	graduar

12. Antipatrones

Antipatrón	Problema
Todo es alert	fatiga
Info como intent	confusión
Warning para todo	pierde significado
Señales efímeras	no se procesan
Exceso de motion	ruido
Modal para todo	interrupción

13. Síntesis

signal es la familia de la atención.

No actúa. No fija. No transforma el sistema directamente.

Hace algo más básico:

Principio

dirige la percepción del usuario.

Comunica:

Dimensión	Pregunta
Atención	¿debo mirar esto?
Urgencia	¿debo actuar ahora?
Saliencia	¿qué destaca?
Contexto	¿qué significa esto?

La tesis:

Principio

Una interfaz no solo responde a acciones. También guía la atención.

Fig. 1 — Signal no es solo mostrar algo. Es regular cuánta atención se pide.


================================================================================
CAPÍTULO 25 — capitulo25_con_diagramas.docx
================================================================================
Capítulo 25

Handle

Cuando el usuario manipula directamente un objeto

Hasta ahora hemos visto familias donde la interacción suele ser discreta: contact registra una acción, commit fija una consecuencia y signal reclama atención.

Pero hay un tipo de interacción donde el evento no cabe en un instante.

El usuario no solo pulsa. No solo confirma. No solo observa.

El usuario manipula.

Arrastra. Reordena. Redimensiona. Desliza. Mueve. Agarra. Suelta.

Aquí aparece otra pregunta:

Principio

¿estoy controlando directamente este objeto?

Esa pregunta define handle.

1. Qué es `handle`

Handle es la familia semántica de la manipulación directa.

No es una acción puntual. No es un resultado. No es una señal.

Es una relación continua entre el usuario y un objeto.

Ejemplos:

handle.pick

handle.carry

handle.drop

handle.drag

handle.resize

handle.rotate

handle.reorder

A diferencia de otras familias, handle no es un instante. Es una secuencia sostenida en el tiempo.

2. Qué no es `handle`

handle no es contact.

contact.press ≠ handle.pick

contact inicia. handle continúa.

handle no es commit.

handle.drop ≠ commit.delete

Soltar no es necesariamente el resultado. El resultado ocurre después o en composición.

handle no es sustain.

sustain.progress ≠ handle.carry

Un proceso automático no es control directo.

handle no es shift.

Mover un objeto no es cambiar de vista.

3. Fundamento psicoperceptivo: control directo, esquema corporal y continuidad

handle se apoya en la percepción de control directo sobre un objeto.

Cuando el usuario arrastra algo, espera que ese objeto:

- responda inmediatamente;

- siga su gesto;

- conserve identidad;

- tenga comportamiento coherente;

- se asiente, encaje o se rechace al soltar.

Esto conecta con esquemas sensoriomotores básicos: agarrar, trasladar, soltar.

El usuario no piensa en eventos discretos. Piensa:

Principio

estoy moviendo esto.

La interfaz debe sostener esa ilusión. Si el objeto se retrasa, el control se rompe. Si se mueve de forma extraña, el usuario pierde confianza. Si no se sabe qué se está manipulando, hay ambigüedad.

handle es una de las familias más corporales del sistema porque convierte la interfaz en espacio de acción continua.

4. Las fases de `handle`

handle tiene tres fases fundamentales.

4.1. Pick

handle.pick

Pregunta:

Principio

¿he agarrado esto?

Canales:

- profundidad;

- motion;

- forma;

- háptica opcional.

Lectura:

Principio

esto está bajo mi control.

4.2. Carry

handle.carry

Pregunta:

Principio

¿sigue bajo mi control?

Canales:

- motion continuo;

- latencia mínima;

- coherencia espacial.

Lectura:

Principio

estoy moviendo esto.

4.3. Drop

handle.drop

Pregunta:

Principio

¿qué ocurrió al soltar?

Aquí handle se conecta con otras familias:

handle.drop

commit.reorder + affirm

commit.delete + loss

signal.warn + risk

Lectura:

Principio

esto se colocó / esto no encaja / esto se perdió.

Fase	Evento	Lectura
Pick	`handle.pick`	agarro
Carry	`handle.carry`	controlo
Drop	`handle.drop`	suelto / evalúo

5. Canales de `handle`

handle es una de las familias más exigentes en canales.

Canal	Función
Tiempo	latencia mínima
Motion	continuidad
Profundidad	régimen de manipulación
Forma	objeto activo / asa
Color	destino válido/inválido
Sonido	opcional en pick/drop
Háptica	opcional en pick/drop

Motion y profundidad son centrales. El objeto debe sentirse separado del layout mientras está en control directo.

6. Handle y evaluación

handle tiene una relación especial con intent.

El carry normalmente no debe cargar intent. Durante el carry el usuario planifica y controla. La evaluación aparece sobre todo en el drop.

Ejemplo:

handle.pick

handle.carry

handle.drop + risk

si el destino es inválido.

O:

handle.pick

handle.carry

commit.delete + loss

si el drop produce eliminación.

Esto evita inyectar evaluación en una fase que aún no tiene resultado.

7. Ejemplos prácticos

Drag & drop

contact.press

handle.pick

handle.carry

handle.drop

commit.move + affirm

Reordenar lista

handle.pick

handle.carry

handle.drop

commit.reorder + affirm

Resize

handle.resize

commit.resize + affirm

Slider

handle.drag

commit.set + affirm

8. Accesibilidad

handle es la familia más difícil de hacer accesible porque suele depender de gesto continuo, precisión motora y control espacial.

Soluciones:

- alternativa por teclado;

- botones subir/bajar;

- selección + acción;

- zonas explícitas;

- feedback textual;

- estado del objeto;

- cancelación clara;

- no depender solo de drag-and-drop.

Principio

La accesibilidad no exige el mismo gesto. Exige el mismo resultado operativo.

9. Antipatrones

Antipatrón	Problema
Lag en drag	pierde control
Sin elevación	no se entiende pick
Objeto rígido	no sigue gesto
Drop ambiguo	no se sabe resultado
Sin alternativa	inaccesible
Feedback continuo	fatiga
Intent durante carry	ruido evaluativo

10. Síntesis

handle es la familia de la manipulación directa.

Comunica:

Dimensión	Pregunta
Control	¿esto está bajo mi acción?
Continuidad	¿sigue siendo el mismo objeto?
Movimiento	¿lo estoy moviendo?
Resultado	¿qué ocurre al soltar?

La tesis:

Principio

Handle convierte la interfaz en espacio de acción continua.

Su regla principal:

Principio

El objeto debe sentirse bajo control en todo momento.

Fig. 1 — Handle no es un evento puntual. Es una secuencia sostenida.


================================================================================
CAPÍTULO 26 — capitulo26_con_diagramas.docx
================================================================================
Capítulo 26

Emerge

Cuando algo entra o sale del campo perceptivo

Hasta ahora hemos visto familias en las que el sistema responde, fija consecuencias, reclama atención o permite manipular objetos.

Pero hay otra clase de evento más silenciosa y estructural.

Algo aparece. Algo se revela. Algo se despliega. Algo se oculta. Algo se retira. Algo entra en el campo perceptivo. Algo deja de estar presente.

Fig. 1 — Emerge hace que algo pase a ocupar una figura reconocible en el campo.

Ese evento no siempre comunica éxito, error, riesgo o pérdida. Muchas veces solo reorganiza la presencia.

La pregunta de emerge es:

Principio

¿algo ha entrado o salido del campo perceptivo?

1. Qué es `emerge`

Emerge es la familia semántica de la aparición y retirada perceptiva.

No nombra el contenido que aparece. No nombra su evaluación. No nombra necesariamente una decisión del usuario.

Nombra el hecho de que algo pasa a estar presente o deja de estarlo.

Ejemplos:

emerge.present

emerge.dismiss

emerge.open

emerge.close

emerge.expand

emerge.collapse

emerge.reveal

emerge.hide

emerge no dice todavía:

esto es bueno

esto es malo

esto es urgente

esto se perdió

Dice:

Principio

esto entra en el campo esto sale del campo

2. Qué no es `emerge`

emerge no es signal.

emerge.open ≠ signal.warn

Algo puede aparecer sin reclamar atención urgente.

Si lo que aparece contiene una advertencia, entonces tenemos composición:

emerge.open

signal.warn + risk

emerge organiza presencia. signal reclama atención.

emerge no es shift.

emerge.open ≠ shift.enter-mode

Un elemento puede aparecer sin cambiar el marco operativo.

emerge no es commit.

emerge.dismiss ≠ commit.delete + loss

Cerrar un panel no es perder un recurso.

3. Fundamento psicoperceptivo: figura/fondo, presencia y organización del campo

emerge se apoya en la organización perceptiva del campo.

La percepción no recibe la pantalla como una lista plana de elementos. Organiza lo que aparece como figura, fondo, región, objeto, superficie, contorno, relación y prioridad.

En esa organización, la aparición de una nueva figura modifica el campo perceptivo.

Un tooltip que aparece junto a un término no solo añade un rectángulo: convierte una información auxiliar en figura local.

Un dropdown que se abre no solo añade opciones: revela una región dependiente de un control.

Un accordion que se expande no solo aumenta la altura de una sección: convierte contenido oculto en parte del campo procesable.

emerge suele ser transicional: reorganiza la presencia para que algo pueda verse, leerse, elegirse o evaluarse.

4. La pregunta perceptiva

emerge responde:

Principio

¿qué acaba de entrar o salir del campo?

Y también:

¿de dónde viene?

¿a qué pertenece?

¿puedo interactuar con ello?

¿es temporal o persistente?

¿se ha ocultado o se ha perdido?

5. Verbos de `emerge`

Verbo	Lectura
`present`	algo se muestra
`dismiss`	algo se retira de la atención
`open`	una superficie o región se abre
`close`	una superficie o región se cierra
`expand`	una región crece y revela contenido
`collapse`	una región se contrae
`reveal`	algo oculto se hace visible
`hide`	algo sigue existiendo pero deja de verse

6. Tipos de `emerge`

Aparición anclada

emerge.open

Dropdown, tooltip, popover.

Lectura:

Principio

esto viene de aquí.

Expansión interna

emerge.expand

Accordion, details, sección desplegable.

Lectura:

Principio

esto estaba contenido aquí.

Retirada reversible

emerge.dismiss

emerge.close

emerge.hide

Lectura:

Principio

se fue de la vista, pero no se perdió.

Aparición auxiliar

emerge.present

Ejemplo:

commit.delete + loss

emerge.present undo

7. Canales de `emerge`

Canal	Función
Presencia	hacer visible o retirar
Motion	mostrar origen, entrada, salida
Profundidad	indicar plano flotante o dependencia
Forma	definir superficie o región
Tiempo	duración de aparición y retirada
Color	secundario
Sonido	normalmente no
Háptica	normalmente no

emerge debe ser legible, no necesariamente saliente.

8. Emerge e intent

emerge normalmente no acepta intent.

Su función principal es estructural: introduce presencia. Lo evaluable será lo que aparece dentro o lo que ocurre después.

Incorrecto:

emerge.open + threat

Más preciso:

emerge.open

signal.warn + threat

La amenaza está en la advertencia, no en el hecho de abrir.

9. Emerge vs Signal

Tooltip:

emerge.present

Alerta inline:

signal.warn + risk

Composición:

emerge.present

signal.warn + risk

Lectura:

Principio

algo aparece y ese algo contiene una advertencia.

10. Emerge vs Shift

Dropdown:

emerge.open

Modal:

shift.enter-mode

El primero introduce presencia local. El segundo cambia régimen operativo.

11. Emerge vs Commit/Delete

emerge.dismiss

significa:

Principio

se retiró de la vista.

commit.delete + loss

significa:

Principio

dejó de estar disponible.

No es lo mismo ocultar que perder.

Fig. 2 — La semántica debe distinguir retirada, ocultación, colapso y pérdida.

12. Ejemplos prácticos

Dropdown

contact.press

emerge.open

commit.select + affirm

emerge.close

Tooltip

contact.focus

emerge.present

emerge.dismiss

Accordion

contact.press

emerge.expand

emerge.collapse

Eliminación con undo

signal.warn + threat

commit.delete + loss

emerge.present undo

13. Accesibilidad

emerge tiene riesgos importantes.

Riesgo	Soporte necesario
contenido aparece pero no se anuncia	estado abierto/cerrado
tooltip inaccesible	alternativa textual / descripción
dropdown sin teclado	navegación y escape
accordion visual solamente	`aria-expanded`, relación trigger-panel
popover flotante	foco y cierre claro
contenido oculto aún accesible	coherencia DOM/árbol accesible

Principio

Si algo emerge visualmente, también debe emerger operativamente.

14. Antipatrones

Antipatrón	Qué falla	Corrección
Todo lo que aparece parece alerta	exceso de saliencia	separar `emerge` de `signal`
Dropdown como modal	profundidad excesiva	mantener anclaje local
Tooltip inaccesible	información perdida	descripción accesible
Cerrar como eliminar	confusión de consecuencia	separar `dismiss` y `delete + loss`
Fade sin origen	dependencia ambigua	motion anclado
Contenido oculto pero accesible	incoherencia operativa	sincronizar DOM/ARIA/visibilidad

15. Síntesis

emerge es la familia de la presencia.

Comunica:

Dimensión	Pregunta
Aparición	¿qué acaba de entrar en el campo?
Retirada	¿qué acaba de salir?
Origen	¿de dónde viene?
Dependencia	¿a qué pertenece?
Reversibilidad	¿se ocultó o se perdió?
Campo	¿cómo se reorganiza lo visible?

Tesis:

Principio

Emerge no dice qué significa lo que aparece. Dice que algo ha pasado a estar presente.

Regla:

Principio

La aparición debe ser proporcional al régimen que introduce.


================================================================================
CAPÍTULO 27 — capitulo27_con_diagramas.docx
================================================================================
Capítulo 27

Shift

Cuando cambia el marco operativo

Hasta ahora hemos visto eventos que ocurren dentro de un mismo contexto: el sistema responde, algo queda fijado, algo reclama atención, el usuario manipula, algo aparece o desaparece.

Pero hay un tipo de evento distinto.

No cambia solo un elemento. No aparece solo una superficie. No se completa solo una acción.

Cambia el lugar desde el que todo lo demás se interpreta.

El usuario pasa a otro estado del sistema.

Ese evento es shift.

1. Qué es `shift`

Shift es la familia semántica del cambio de marco operativo.

No describe un contenido. No describe una señal. No describe una acción puntual.

Describe algo más profundo:

Principio

el contexto en el que el usuario actúa ha cambiado.

Ejemplos:

shift.enter-mode

shift.exit-mode

shift.navigate

shift.step

shift.route

shift.context

shift.return

Abrir un modal. Entrar en edición. Ir a otra pantalla. Avanzar en un flujo. Cambiar de vista. Activar un modo especial.

2. Qué no es `shift`

shift no es emerge.

emerge.open ≠ shift.enter-mode

Un dropdown aparece. Un modal cambia el contexto.

shift no es commit.

shift.navigate ≠ commit.submit

Ir a otra pantalla no implica que la operación haya terminado.

shift no es signal.

Un cambio de vista no es una advertencia.

shift no es handle.

Manipular un objeto no es cambiar el marco.

3. Fundamento psicoperceptivo: cambio de marco, orientación y modelo mental

shift se apoya en un fenómeno clave: el usuario opera siempre dentro de un modelo mental activo.

Fig. 1 — El cambio no es solo visual. Es semántico.

Cuando ese modelo cambia, la percepción cambia con él.

Ejemplos:

- editar vs visualizar;

- navegar vs confirmar;

- formulario vs resultado;

- lista vs detalle;

- búsqueda vs navegación;

- selección simple vs modo bulk.

Estos no son cambios visuales únicamente. Son cambios en:

qué puedo hacer

qué significa cada acción

qué es relevante

qué está permitido

qué queda subordinado

cómo vuelvo

El usuario necesita reorientarse.

Si el sistema no comunica el cambio de marco, aparece desorientación:

¿dónde estoy?

¿qué ha cambiado?

¿puedo volver?

¿qué puedo hacer ahora?

shift no es opcional. Es necesario para mantener coherencia cognitiva.

4. La pregunta perceptiva

shift responde:

Principio

¿sigo en el mismo contexto o estoy en otro?

Y también:

¿puedo hacer lo mismo aquí?

¿cómo vuelvo?

¿qué cambió?

qué es ahora lo importante?

5. Tipos de `shift`

Navegación

shift.navigate

Lista → detalle. Página A → página B.

Lectura:

Principio

estoy en otro lugar.

Cambio de modo

shift.enter-mode

shift.exit-mode

Visualizar → editar. Normal → selección múltiple.

Lectura:

Principio

estoy en otro régimen.

Flujo paso a paso

shift.step

Paso 1 → paso 2 → paso 3.

Lectura:

Principio

avanzo en un proceso.

Cambio de contexto local

shift.context

Filtro activo, modo bulk, vista agrupada.

Lectura:

Principio

el significado del campo cambió.

6. Canales de `shift`

shift es altamente multicanal.

Canal	Función
Profundidad	nuevo plano
Presencia	aparición del nuevo contexto
Motion	transición orientadora
Tiempo	duración suficiente
Forma	estructura del nuevo estado
Foco	punto de entrada
Color	apoyo de modo
Sonido	ocasional

El foco es especialmente importante.

Principio

Si cambia el contexto, debe cambiar el foco.

7. Shift y familias relacionadas

Con `emerge`

emerge.open

shift.enter-mode

Diferencia:

- emerge → aparece algo;

- shift → cambia el sistema de acción.

Con `commit`

commit.submit + fulfill

shift.navigate

Una operación puede terminar y después llevar a otra vista.

Con `signal`

shift.enter-mode

signal.warn + threat

Un modal puede cambiar el marco y contener una advertencia.

8. Shift vs Emerge

Dropdown:

emerge.open

Modal:

shift.enter-mode

Propiedad	Dropdown	Modal
Cambia contexto	no	sí
Bloquea fondo	no	sí
Requiere decisión	normalmente no	a menudo sí
Foco cambia	local	dominante

9. Ejemplos prácticos

Navegación

contact.press

shift.navigate

Modal

contact.press

shift.enter-mode

signal.warn + threat

Wizard

shift.step

Modo edición

shift.enter-mode

handle.edit

commit.save + affirm

shift.exit-mode

10. Accesibilidad

shift es crítico en accesibilidad.

Debe:

- mover foco;

- anunciar cambio;

- actualizar título;

- definir landmarks;

- permitir volver;

- evitar desorientación;

- bloquear correctamente lo que ya no es operativo.

Problema	Efecto
foco no cambia	confusión
título no cambia	desorientación
fondo activo	incoherencia
navegación invisible	pérdida
modo sin anuncio	acciones mal interpretadas

Principio

Si el usuario no sabe dónde está, el shift falló.

11. Antipatrones

Antipatrón	Problema
Todo es modal	exceso de cambio
Cambio sin foco	desorientación
Animación sin orientación	ruido
Navegación sin contexto	pérdida
Modal sin bloqueo	incoherencia
Shift invisible	confusión
Modo sin salida clara	ansiedad

12. Síntesis

shift es la familia del cambio de contexto.

Comunica:

Dimensión	Pregunta
Contexto	¿dónde estoy?
Acción	¿qué puedo hacer?
Continuidad	¿de dónde vengo?
Orientación	¿cómo vuelvo?

Tesis:

Principio

Shift redefine el espacio de acción del usuario.

Regla:

Principio

Todo cambio de contexto debe ser explícito y orientado.

Fig. 2 — Ambas superficies aparecen, pero solo una cambia el marco operativo.


================================================================================
CAPÍTULO 28 — capitulo28_con_diagramas.docx
================================================================================
Capítulo 28

Sustain

Cuando algo sigue ocurriendo sin haber terminado

Hay eventos que no se resuelven en un instante.

El usuario pulsa guardar, pero el guardado tarda. Envía un archivo, pero la subida avanza lentamente. Abre una vista, pero los datos aún no llegan. Inicia una búsqueda, pero el sistema sigue procesando. Sincroniza un documento, pero todavía no hay resultado.

En todos esos casos, el evento principal no es todavía éxito, error, pérdida ni confirmación. Tampoco es simplemente contacto.

Algo está ocurriendo, pero aún no ha terminado.

Esa es la región de sustain.

La pregunta perceptiva de sustain es:

Principio

¿esto sigue ocurriendo?

O, dicho desde la experiencia del usuario:

Principio

¿el sistema sigue vivo o se ha quedado bloqueado?

1. Qué es `sustain`

Sustain es la familia semántica de la continuidad operativa.

Comunica que una operación, estado o proceso sigue activo aunque todavía no haya producido una consecuencia final.

Ejemplos:

sustain.start

sustain.progress

sustain.loading

sustain.waiting

sustain.syncing

sustain.streaming

sustain.processing

sustain.pending

sustain.end

Un spinner puede ser sustain. Una barra de progreso puede ser sustain. Un skeleton puede ser sustain. Un texto “guardando…” puede ser sustain. Un indicador de sincronización puede ser sustain.

Pero sustain no es el spinner. No es la barra. No es el skeleton. No es el texto.

Es la clase de evento que esos recursos intentan hacer perceptible:

Principio

una operación continúa sin haber llegado aún a su resultado.

2. Qué no es `sustain`

Sustain no es contact.

contact.press ≠ sustain.progress

contact confirma que el sistema recibió la acción. sustain confirma que la operación iniciada sigue viva.

Sustain no es commit.

sustain.progress ≠ commit.complete

Un proceso en curso no es culminación.

Sustain no es signal.

sustain.progress ≠ signal.warn

Un proceso no es alerta por el hecho de durar.

Sustain no es emerge.

emerge.present ≠ sustain.progress

Puede aparecer un indicador, pero la aparición no es el proceso.

3. Fundamento psicoperceptivo: continuidad temporal, incertidumbre y confianza

Sustain se apoya en una necesidad básica de la interacción:

Principio

cuando no hay resultado inmediato, el usuario necesita saber si el sistema sigue funcionando.

La ausencia de respuesta prolongada no se percibe como neutral. Se percibe como ambigua.

El usuario empieza a preguntarse:

¿se ha bloqueado?

¿lo he hecho mal?

¿debo esperar?

¿debo repetir?

¿perderé lo que estaba haciendo?

sustain reduce esa incertidumbre.

Trabaja con tres dimensiones:

1. Continuidad temporal

El usuario necesita percibir que el proceso no se ha detenido.

2. Predicción

Si hay progreso medible, el usuario puede anticipar el final.

3. Confianza operativa

Una señal proporcional permite sostener la confianza sin vigilancia constante.

Fig. 1 — Sin señal parece fallo; con demasiada señal parece amenaza.

Por eso sustain no es un detalle visual. Es una forma de mantener abierta una operación en la mente del usuario.

4. La pregunta perceptiva

Sustain responde:

Principio

¿esto sigue ocurriendo?

Y también:

¿está vivo?

¿está bloqueado?

¿avanza?

¿cuánto falta?

¿puedo hacer otra cosa?

¿puedo cancelar?

¿debo esperar?

5. Tipos de `sustain`

Tipo	Qué comunica	Ejemplo	Riesgo
`loading`	carga indeterminada	skeleton, spinner	bloqueo aparente
`progress`	avance medible	barra, porcentaje	progreso falso
`syncing`	alineación de estado	guardando en nube	confundir con commit
`processing`	cálculo interno	búsqueda, IA, exportación	opacidad
`streaming`	flujo continuo	respuesta en vivo	no distinguir final
`waiting`	dependencia externa	esperando servidor	frustración

6. Canales de `sustain`

Canal	Función
Tiempo	sostener continuidad
Presencia	mantener visible el estado
Forma	representar proceso
Motion	indicar actividad o avance
Texto	explicar qué ocurre
Color	bajo, como estado auxiliar
Sonido	normalmente evitar
Háptica	normalmente evitar

El texto es muchas veces el canal más honesto de sustain.

Un spinner sin texto dice:

Principio

algo pasa.

Un texto dice:

Principio

esto es lo que pasa.

7. Sustain e intent

Sustain normalmente no acepta intent por sí mismo.

Un proceso en curso no es positivo o negativo por estar en curso.

Puede volverse problemático, pero entonces se compone:

sustain.progress

signal.warn + risk

Puede terminar bien:

sustain.progress

commit.complete + fulfill

Puede fallar:

sustain.progress

commit.fail + risk

El intent aparece en la señal o en el resultado, no en la continuidad misma.

8. Sustain vs Commit

contact.press

sustain.progress

commit.save + affirm

Sustain mantiene abierta la operación. Commit la cierra.

Si el sistema muestra “guardado” mientras todavía está guardando, rompe la confianza. Si mantiene “guardando…” después de haber guardado, también.

9. Sustain vs Signal

Sustain acompaña.

Signal reclama atención.

Si un proceso tarda más de lo esperado:

sustain.processing

signal.warn + risk

Si falla:

commit.fail + risk

No todo proceso lento debe convertirse en alerta. Pero todo proceso que se aleja de las expectativas debe comunicarlo.

10. Ejemplos prácticos

Guardado remoto

contact.press

sustain.progress

commit.save + affirm

Subida de archivo

contact.press

sustain.progress

commit.complete + fulfill

Búsqueda

contact.submit

sustain.processing

emerge.present results

IA generando respuesta

contact.submit

sustain.streaming

commit.complete + affirm / fulfill

Sincronización offline

sustain.syncing

commit.save + affirm

o si falla:

sustain.syncing

commit.fail + risk

11. Accesibilidad

sustain debe ser accesible porque la espera genera incertidumbre.

Problema	Riesgo	Corrección
solo spinner	ambiguo	texto de estado
motion continuo	malestar	reduced motion
sin progreso	ansiedad	barra o explicación
sin cancelación	bloqueo	control del usuario
sin final claro	duda	commit visible
anuncios excesivos	ruido	live regions dosificadas
skeleton largo	sensación de vacío	mensaje o alternativa

La accesibilidad de sustain consiste en hacer soportable la espera.

12. Antipatrones

Antipatrón	Qué falla	Corrección
spinner eterno	ansiedad	progreso, texto, control
spinner sin texto	ambigüedad	estado explícito
progreso falso	desconfianza	progreso real o indeterminado
sustain como alarma	sobreactuación	neutralidad + signal si procede
resultado sin cierre	duda	commit claro
espera invisible	fallo percibido	indicador de continuidad
loop sonoro	fatiga	silencio

13. Síntesis

Sustain es la familia de la continuidad operativa.

No responde a:

¿se recibió mi acción?

Eso era contact.

No responde a:

¿ya terminó?

Eso será commit.

Responde a:

¿esto sigue ocurriendo?

Su función es mantener la confianza durante el intervalo entre acción y resultado.

Dimensión	Pregunta
Continuidad	¿sigue vivo?
Progreso	¿avanza?
Tiempo	¿debo esperar?
Estado	¿qué está haciendo?
Control	¿puedo cancelar o seguir?
Cierre	¿cuándo pasó a commit?

Tesis:

Principio

Sustain mantiene abierta una operación sin convertirla todavía en resultado.

Regla principal:

Principio

Todo proceso que no termina de inmediato debe indicar que sigue vivo, sin parecer alarma ni celebración.

# Cierre de los capítulos 20–28

Con estos capítulos queda consolidado el bloque de coordinación y familias semánticas.

La teoría ya no se limita a nombrar siete palabras. Cada familia queda vinculada a:

- una pregunta perceptiva;

- un fundamento psicoperceptivo;

- una relación con intent;

- unos canales dominantes;

- ejemplos concretos;

- criterios de accesibilidad;

- antipatrones.

Esta revisión corrige el problema anterior: las semánticas ya no aparecen como fichas técnicas, sino como estructuras perceptivas del evento interactivo.

Fig. 2 — Sustain mantiene abierta la operación. Commit la cierra.


================================================================================
CAPÍTULO 29 — capitulo29_con_diagramas.docx
================================================================================
CAPÍTULO 29

Composición de eventos semánticos

Secuencias, reglas y solapamientos

Hasta ahora hemos separado.

Hemos separado familias semánticas:

contact

commit

signal

handle

emerge

shift

sustain

Hemos separado intents:

neutral

affirm

fulfill

risk

threat

loss

Hemos separado canales:

tiempo

motion

presencia

profundidad

forma

color

sonido

háptica

Esa separación era necesaria. Sin ella, todo se mezcla: un click parece éxito, un modal parece amenaza, un spinner parece error, una desaparición parece pérdida, una advertencia parece resultado.

Pero una interfaz real no ocurre por piezas aisladas.

El usuario no vive una familia semántica cada vez. Vive flujos. Pulsa. Espera. Recibe una señal. Corrige. Confirma. El sistema procesa. Algo queda fijado. Algo se pierde. Algo aparece como reparación. Algo cambia de marco.

Una interacción real suele ser una composición temporal de eventos semánticos.

La pregunta de este capítulo es:

PREGUNTA DEL CAPÍTULO

¿Cómo se combinan las familias semánticas sin que la interfaz pierda claridad?

Figura 29.1

1. Por qué necesitamos composición

Una familia semántica aislada explica un tipo de evento. Pero una operación de interfaz casi nunca es un solo evento.

Guardar no es solo commit.save. Eliminar no es solo commit.delete. Arrastrar no es solo handle.carry. Enviar un formulario no es solo submit. Abrir un modal no es solo shift.enter-mode. Cargar una vista no es solo sustain.loading.

Cada operación contiene fases. Por ejemplo, guardar un documento remoto puede componerse así:

contact.press → sustain.progress → commit.save + affirm

La pulsación fue recibida. El sistema trabajó. El resultado quedó guardado.

Si omitimos contact, el usuario duda si actuó. Si omitimos sustain, la espera parece bloqueo. Si omitimos commit, no hay cierre.

La operación no se entiende por un único efecto. Se entiende por la relación entre eventos.

DISTINCIÓN

Una interacción real no es una familia aislada. Es una composición temporal de eventos.

2. Secuencias básicas

Hay composiciones muy frecuentes.

2.1. ACCIÓN INMEDIATA CON RESULTADO SIMPLE

contact.press → commit.toggle + affirm

El usuario activa un switch. Lectura: me ha sentido → el estado quedó aplicado. No hace falta sustain si la operación es inmediata.

2.2. ACCIÓN CON PROCESO INTERMEDIO

contact.press → sustain.progress → commit.save + affirm

El usuario guarda cambios en servidor. Lectura: me ha sentido → sigue trabajando → quedó guardado.

2.3. ACCIÓN CON CULMINACIÓN

contact.press → sustain.progress → commit.complete + fulfill

El usuario exporta un vídeo, sube un archivo o completa un flujo importante. Lectura: me ha sentido → sigue procesando → objetivo cumplido. Aquí fulfill tiene más sentido que affirm, porque se resuelve una tensión o meta.

2.4. ACCIÓN DESTRUCTIVA CON ADVERTENCIA

contact.press → signal.warn + threat → commit.delete + loss

El usuario elimina un proyecto. Lectura: me ha sentido → puedo evitar una consecuencia grave → algo dejó de estar disponible. La amenaza vive antes de la pérdida. La pérdida vive después de la consecuencia.

2.5. ELIMINACIÓN CON REPARACIÓN

signal.warn + threat → commit.delete + loss → emerge.present undo

El usuario confirma eliminar una tarjeta y aparece una barra de deshacer. Lectura: puedes evitarlo → ya se perdió → puedes repararlo temporalmente. El undo no borra la pérdida. La recontextualiza como parcialmente reversible.

2.6. MANIPULACIÓN DIRECTA

contact.press → handle.pick → handle.carry → handle.drop → commit.reorder + affirm

El usuario reordena una lista. Lectura: me ha sentido → lo agarro → lo controlo → lo suelto → quedó reordenado.

OPERACIÓN	SECUENCIA SEMÁNTICA	LECTURA
Activar switch	contact.press → commit.toggle + affirm	acción recibida, estado aplicado
Guardar remoto	contact.press → sustain.progress → commit.save + affirm	acción, proceso, cierre
Completar flujo	contact.press → sustain.progress → commit.complete + fulfill	acción, espera, objetivo cumplido
Eliminar	contact.press → signal.warn + threat → commit.delete + loss	acción, advertencia, pérdida
Deshacer eliminación	commit.delete + loss → emerge.present undo	pérdida con reparación temporal
Reordenar	contact.press → handle → commit.reorder + affirm	agarre, control, resultado

3. Las reglas no son dogmas

Las reglas de composición no deberían parecer mandamientos arbitrarios.

No decimos que contact va antes de commit porque sí. Decimos que si el usuario actúa, necesita primero percibir que su acción fue recibida antes de poder interpretar el resultado.

No decimos que threat debe ir antes de loss porque lo dice la taxonomía. Decimos que una amenaza convoca acción antes de la consecuencia; una pérdida registra consecuencia después.

No decimos que sustain debe terminar en commit. Decimos que un proceso abierto necesita algún tipo de cierre, resultado, cancelación, fallo o persistencia explicada.

Cada regla debe derivarse de una necesidad perceptiva.

4. Reglas de composición

REGLA 1 — CONTACT PRECEDE AL RESULTADO CUANDO HAY ACCIÓN DIRECTA

Si el usuario actúa directamente, la interfaz debe comunicar recepción antes de comunicar consecuencia.

contact.press → commit.save + affirm

Fundamento: agencia, causalidad acción-respuesta, reducción de duda.

Error: commit.save + affirm sin contacto perceptible. El usuario puede no saber si la acción fue registrada o si el estado cambió por otra razón.

REGLA 2 — SUSTAIN PRECEDE AL COMMIT CUANDO HAY ESPERA

Si la operación no termina de inmediato, debe sostenerse antes de resolverse.

contact.press → sustain.progress → commit.complete + fulfill

Fundamento: continuidad temporal, reducción de incertidumbre, mantenimiento de confianza.

Error: contact.press → silencio → commit.complete + fulfill. La operación puede funcionar técnicamente, pero la espera se percibe como bloqueo.

REGLA 3 — THREAT PRECEDE A LOSS

Threat vive antes o durante una posible consecuencia. Loss vive después.

signal.warn + threat → commit.delete + loss

Fundamento: temporalidad de la evaluación, espacio valencia/activación, diferencia entre prevenir y registrar.

Error: commit.delete + threat. Después de la eliminación, ya no hay nada que evitar. La amenaza se vuelve disonante.

REGLA 4 — EMERGE NO DEBE ABSORBER EL INTENT DEL CONTENIDO

Una superficie puede aparecer sin ser evaluable.

emerge.open → signal.warn + risk

Fundamento: figura/fondo, evento estructural vs evento evaluable, marco ≠ mensaje.

Error: emerge.open + risk. La apertura no es el riesgo. El riesgo está en el mensaje que aparece.

REGLA 5 — SHIFT DEBE ORIENTAR EL CAMBIO DE MARCO

Cuando cambia el marco operativo, el usuario necesita orientación. shift.enter-mode debe acompañarse de foco, título, profundidad, estructura y salida clara.

Fundamento: cambio de modelo operativo, orientación espacial/cognitiva, gestión de foco.

Error: un modal aparece visualmente, pero el foco permanece detrás.

REGLA 6 — HANDLE CONCENTRA EVALUACIÓN EN EL DROP

Durante handle.carry, el usuario está controlando. La evaluación aparece sobre todo al soltar.

handle.pick → handle.carry → handle.drop + risk

Fundamento: control motor continuo, separación entre manipulación y resultado, economía atencional.

Error: hacer que todo el carry parezca amenaza porque el usuario pasa cerca de una zona destructiva. Mejor: handle.carry + signal.warn + threat solo cuando la zona destructiva se vuelve destino probable.

REGLA 7 — TODO PROCESO ABIERTO NECESITA SALIDA

Un sustain no puede quedar suspendido indefinidamente sin cambio de estado. Posibles salidas: commit.complete + fulfill, commit.save + affirm, commit.fail + risk, signal.warn + risk, commit.cancel + neutral.

Fundamento: cierre cognitivo, confianza, memoria de estado.

Error: spinner eterno.

REGLA	FUNDAMENTO
contact precede a resultado	agencia y causalidad
sustain precede a commit si hay espera	continuidad temporal
threat precede a loss	antes/después de consecuencia
emerge no absorbe intent	figura/fondo; marco ≠ mensaje
shift debe orientar	cambio de modelo operativo
handle.drop concentra evaluación	control continuo vs resultado
sustain necesita salida	cierre cognitivo

5. Ejemplo largo: subida con fallo parcial y recuperación

Veamos una composición más compleja.

El usuario sube un archivo grande para enviarlo a revisión. Durante la subida, la conexión falla parcialmente. El sistema conserva parte del progreso, muestra una advertencia y permite reintentar. El usuario reintenta y la subida termina correctamente.

5.1. ACCIÓN INICIAL

contact.press — el usuario pulsa "Subir". Canales: respuesta inmediata, estado pressed, micro motion opcional.

5.2. SUBIDA EN CURSO

sustain.upload — el sistema empieza a subir. Canales: barra de progreso, texto "Subiendo archivo…", presencia persistente, baja saliencia.

5.3. ADVERTENCIA CORREGIBLE

signal.warn + risk — la conexión se interrumpe parcialmente. No es threat si no hay urgencia inmediata. No es loss si no se perdió definitivamente. Canales: callout, color moderado de advertencia, texto descriptivo, presencia persistente.

5.4. REINTENTO AUTOMÁTICO O DISPONIBLE

sustain.retrying — el sistema intenta continuar. Canales: indicador de reintento, texto "Reintentando…", baja saliencia.

5.5. RESULTADO PARCIAL

commit.partial + risk — parte de la operación no se completó. Este commit no es fulfill ni loss completo. Es un resultado problemático, corregible. Canales: estado de progreso parcial, mensaje descriptivo, color de advertencia.

5.6. APARICIÓN DE RECUPERACIÓN

emerge.present recovery — aparece una opción de reintentar o continuar. La aparición no es el riesgo. La opción emergente ofrece reparación. Canales: botón de reintentar, presencia clara.

5.7. REINTENTO DEL USUARIO

contact.press → sustain.progress — el usuario pulsa "Reintentar". El sistema vuelve a trabajar. Canales: barra de progreso restaurada, texto "Subiendo…".

5.8. CIERRE POSITIVO

commit.complete + fulfill — la subida termina. Aquí fulfill tiene sentido porque había tensión, espera y recuperación. Canales: motion resolutivo, marca de completado, color positivo, sonido breve opcional.

MOMENTO	FAMILIA	INTENT	LECTURA
Pulsar subir	contact.press	—	el sistema me ha sentido
Subiendo	sustain.upload	—	sigue trabajando
Problema de red	signal.warn	risk	hay algo corregible
Reintento	sustain.retrying	—	intenta recuperarse
Resultado parcial	commit.partial	risk	algo quedó incompleto
Opción de recuperación	emerge.present recovery	—	aparece una reparación
Reintentar	contact.press	—	recibió mi acción
Subida completada	commit.complete	fulfill	objetivo cumplido

6. Eventos simultáneos y solapados

Hasta ahora hemos hablado de secuencias lineales. Pero una interfaz real también tiene simultaneidad.

Un proceso puede seguir en curso mientras aparece una advertencia:

sustain.progress + signal.warn + risk

Un usuario puede estar arrastrando mientras se aproxima a una zona destructiva:

handle.carry + signal.warn + threat

Un modal puede cambiar el marco mientras dentro aparece una señal:

shift.enter-mode + signal.alert + threat

Un sistema puede estar sincronizando mientras muestra un estado parcial:

sustain.syncing + commit.partial + risk

Una notificación puede llegar mientras el usuario está manipulando un objeto:

handle.carry + signal.notify + neutral

La composición no siempre es una cadena. A veces es una superposición.

7. Regla de dominancia atencional

Cuando dos eventos se solapan, uno debe dominar la atención y el otro debe mantenerse como contexto.

La jerarquía de dominancia sigue tres criterios:

El evento evaluable domina sobre el estructural. Un signal.warn + risk que aparece durante un sustain.progress debe convertirse en figura. El proceso queda como contexto.

El evento con mayor activación domina sobre el de menor activación. Un signal.alert + threat domina sobre un signal.notify + neutral. La amenaza reclama atención; la notificación espera.

El evento más reciente domina sobre el anterior cuando ambos son del mismo nivel. Si durante un sustain.progress aparece un commit.partial + risk, el resultado parcial toma prioridad sobre el indicador de proceso.

CRITERIO	REGLA
Evaluabilidad	lo evaluable domina sobre lo estructural
Activación	lo más activado domina sobre lo menos activado
Recencia	si el nivel es similar, domina lo más reciente

Ejemplo:

sustain.progress + signal.warn + risk

El proceso sigue, pero la advertencia debe ser figura. Lectura correcta: el sistema sigue trabajando, pero hay algo que revisar. No: el proceso falló completamente.

Otro ejemplo:

handle.carry + signal.warn + threat

El usuario sigue manipulando, pero la zona destructiva reclama atención. Lectura correcta: sigues controlando el objeto, pero si lo sueltas ahí habrá consecuencia.

Otro ejemplo:

handle.carry + signal.notify + neutral

El usuario está arrastrando y llega una notificación del sistema. Handle domina porque el usuario está en control motor activo. La notificación no debe interrumpir ni reclamar foco. Debe esperar o aparecer sin competir con la manipulación.

COMPOSICIÓN	EVENTO DE CONTEXTO	EVENTO DOMINANTE
sustain.progress + signal.warn	proceso en curso	advertencia
handle.carry + signal.threat	manipulación	zona peligrosa
shift.enter-mode + signal.alert	nuevo marco	alerta interna
sustain.syncing + commit.partial	sincronización	resultado parcial
emerge.present + signal.notify	aparición	mensaje del sistema
handle.carry + signal.notify	manipulación activa	handle domina, notificación espera

8. Jerarquía dentro de una composición

Una composición necesita jerarquía. No todos los eventos deben expresarse con la misma intensidad.

En una operación larga:

contact.press → sustain.progress → commit.complete + fulfill

Contact debe ser inmediato y discreto. Sustain debe sostener sin fatigar. Commit debe cerrar con claridad. Si los tres tienen la misma energía, la secuencia se vuelve plana.

En una operación destructiva:

signal.warn + threat → commit.delete + loss → emerge.present undo

Threat debe destacar antes. Loss debe registrar después. Undo debe permanecer como reparación, sin parecer otra amenaza.

La jerarquía se establece mediante tres principios:

El evento evaluable recibe más intensidad que el estructural. Commit.complete + fulfill merece más energía perceptiva que el sustain que lo precedió. Signal.warn + threat merece más saliencia que el emerge.open que lo contiene.

El evento con mayor activación recibe más intensidad que el de menor activación. Un threat necesita más saliencia que un affirm. Un fulfill necesita más resolución que un neutral. Un loss necesita más gravedad que un risk.

El evento de cierre recibe más presencia que los intermedios. En contact → sustain → commit, el commit es el cierre. Debe ser el momento perceptivo más claro de la secuencia. El sustain acompaña. El contact inicia.

Cuando todos los eventos compiten por la misma atención, la composición se convierte en ruido. Cuando están bien graduados, la secuencia se lee como una historia perceptiva coherente.

9. Antipatrones de composición

9.1. COMMIT ANTICIPADO

La interfaz muestra éxito antes de terminar.

contact.press → commit.complete + fulfill → sustain.progress

Problema: promete resultado antes de que exista. Corrección: contact.press → sustain.progress → commit.complete + fulfill.

9.2. THREAT DESPUÉS DE LOSS

commit.delete + loss → signal.alert + threat

Problema: comunica urgencia cuando ya no hay prevención posible. Corrección: signal.warn + threat → commit.delete + loss.

9.3. EMERGE COMO ALERT

Un dropdown aparece con la energía de una alerta.

Problema: aparición local se confunde con señal urgente. Corrección: emerge.open sin intent, salvo que contenga un signal.

9.4. SUSTAIN SIN SALIDA

Un spinner queda indefinido.

Problema: proceso sin cierre. Corrección: sustain.progress → commit.complete / commit.fail / signal.warn / cancel.

9.5. HANDLE EVALUADO TODO EL TIEMPO

Todo el arrastre está teñido de amenaza.

Problema: el usuario pierde sensación de control. Corrección: mantener carry neutro y señalizar solo destinos o drop.

9.6. NOTIFICACIÓN QUE INTERRUMPE MANIPULACIÓN

Una notificación reclama foco mientras el usuario arrastra.

Problema: rompe el control motor activo. Corrección: la notificación espera o aparece sin competir con handle.

10. Síntesis

La composición convierte familias aisladas en interacción real.

Una interfaz no debe preguntarse solo: ¿qué evento es este?

También debe preguntarse: ¿qué ocurrió antes? ¿qué viene después? ¿qué evento domina la atención? ¿qué evento queda como contexto? ¿qué resultado cierra la secuencia? ¿qué huella queda?

DISTINCIÓN

Una interacción real no es una familia aislada. Es una composición temporal de eventos semánticos.

PRINCIPIO

Toda composición debe preservar la pregunta perceptiva de cada evento sin hacerlos competir innecesariamente.

La composición es donde la gramática deja de ser vocabulario y empieza a comportarse como lenguaje.

Figura 29.2

Figura 29.3

Figura 29.4


================================================================================
CAPÍTULO 30 — capitulo30_con_diagramas.docx
================================================================================
CAPÍTULO 30

Matrices semánticas

Familias, intents y canales

El capítulo anterior mostró que una interacción real no suele ser una familia aislada. Una operación de interfaz encadena eventos: contacto, proceso, señal, consecuencia, aparición, cambio de marco o manipulación. La gramática se vuelve útil cuando permite leer esas secuencias sin confundirlas.

Pero para diseñar, revisar o documentar una interfaz hace falta otro paso.

No basta con saber que existe contact, commit, signal, handle, emerge, shift y sustain. Tampoco basta con saber que existen neutral, affirm, fulfill, risk, threat y loss.

Hay que saber qué canales expresan mejor cada familia y cómo cambia esa expresión cuando aparece un intent.

Este capítulo introduce dos herramientas: la matriz de familias × canales y la matriz de intents × canales. No son tablas cerradas ni recetas universales. Son mapas de decisión.

PREGUNTA DEL CAPÍTULO

¿Qué canal debe dominar cada evento y qué función cumple en él?

1. Para qué sirve una matriz semántica

Una matriz semántica convierte la teoría en una herramienta de trabajo. Permite pasar de frases generales como "este evento necesita feedback" a preguntas más precisas: ¿es contact o commit? ¿hay proceso intermedio? ¿hay intent evaluativo? ¿el canal dominante debe ser tiempo, motion, forma, presencia o sonido? ¿qué ocurre si el usuario reduce motion? ¿qué queda después del evento?

Por ejemplo, un botón "Guardar" no debería resolverse diciendo "añade una animación de success." Sino: contact.press → sustain.progress si hay espera → commit.save + affirm. Y entonces la matriz ayuda a decidir: contact.press necesita tiempo y micro motion; sustain.progress necesita presencia, texto y progreso; commit.save + affirm necesita marca discreta, quizá color suave, quizá sonido opcional.

La matriz obliga a separar lo que muchas veces se decide junto.

PRINCIPIO

Una matriz semántica no dice qué efecto usar. Dice qué función debe cumplir cada canal dentro del evento.

2. Cómo leer las matrices

Las matrices de este capítulo no usan solo valores como "alto", "medio" o "bajo". Esa forma puede ser útil, pero es insuficiente. Decir que motion es "alto" en contact no explica qué hace motion ahí. Es mejor decir: motion en contact → causalidad inmediata. Decir que color es "alto" en signal tampoco basta. Es mejor decir: color en signal → saliencia y valencia.

Por eso las celdas de estas matrices describen función, no solo intensidad. La pregunta para cada celda es: ¿qué aporta este canal a esta familia o intent?

3. Matriz de familias y canales

La primera matriz cruza las siete familias semánticas con los canales perceptivos principales. No pretende decir que todos los eventos de una familia usen siempre los mismos canales. Pretende mostrar qué canales suelen dominar y qué función suelen cumplir.

FAMILIA	TIEMPO	MOTION	PRESENCIA / PROFUNDIDAD	FORMA	COLOR	SONIDO	HÁPTICA
contact	causalidad inmediata	microrespuesta al gesto	casi nula	estado pressed / foco	secundario	click opcional	pulso breve
commit	momento de cierre	asentamiento / retirada	huella o consecuencia	marca persistente	refuerzo evaluativo	cierre opcional	impacto / encaje
signal	persistencia suficiente	entrada o énfasis	figura atencional	callout / badge / alerta	saliencia y valencia	fuera de foco	alerta corporal
handle	baja latencia	seguimiento continuo	elevación / plano activo	grip / zona destino	válido / inválido	pick/drop opcional	pick/drop
emerge	entrada y salida	origen / retirada	presencia local	superficie / contenedor	apoyo menor	normalmente no	normalmente no
shift	transición orientadora	cruce de marco	plano dominante / fondo	estructura del nuevo contexto	modo o estado	raro	raro
sustain	continuidad	actividad o progreso	estado persistente	barra / skeleton / indicador	bajo	evitar loop	evitar

4. Lectura por familia

4.1. CONTACT

Contact depende principalmente del tiempo. Si la respuesta llega tarde, pierde su función aunque el motion sea bonito. El canal dominante es la latencia: el usuario debe percibir que el sistema ha sentido su acción. Motion puede ayudar mediante microcompresión o respuesta breve. Forma puede reforzar con un estado pressed. Sonido y háptica son opcionales.

Función dominante: tiempo + motion → agencia inmediata.

Riesgo: convertir cada contacto en espectáculo, sonido o vibración.

4.2. COMMIT

Commit necesita dejar huella. No basta con que algo cambie por un instante. El usuario debe percibir que algo quedó fijado, resuelto, eliminado, cancelado o restaurado. Motion puede comunicar asentamiento o retirada. Forma y presencia sostienen el estado. Color puede reforzar intent. Sonido o háptica pueden marcar cierre en eventos relevantes.

Función dominante: forma + presencia + motion → consecuencia perceptible.

Riesgo: commit efímero sin huella, o sobrecelebración de acciones rutinarias.

4.3. SIGNAL

Signal necesita entrar en la atención. Sus canales fuertes son presencia, forma, color y texto. El sonido puede ser útil cuando la señal debe alcanzar al usuario fuera del foco visual. Motion puede introducir o enfatizar, pero debe dosificarse.

Función dominante: presencia + forma + texto + color → atención orientada.

Riesgo: depender solo de color o convertir todo en alerta.

4.4. HANDLE

Handle requiere baja latencia, continuidad y profundidad. Motion es central porque sostiene el control. Profundidad indica que el objeto salió del flujo normal. Forma define objeto, grip y zonas destino. Color puede indicar válido/inválido, pero no debe dominar el carry.

Función dominante: motion + profundidad + forma → control directo.

Riesgo: perder agencia por lag, destino ambiguo o falta de alternativa accesible.

4.5. EMERGE

Emerge necesita hacer legible la entrada o salida de algo en el campo perceptivo. Presencia y motion son centrales. Profundidad ayuda si la superficie flota. Forma define el tipo de superficie. Color, sonido y háptica suelen ser secundarios.

Función dominante: presencia + motion + forma → aparición reconocible.

Riesgo: que una aparición local se sienta como alerta o como cambio de marco.

4.6. SHIFT

Shift necesita orientar un cambio de marco. Sus canales principales son profundidad, presencia, foco, estructura y motion. Color puede reforzar modo activo. Sonido y háptica son raros.

Función dominante: profundidad + foco + estructura → cambio de contexto.

Riesgo: que el usuario no sepa dónde está, qué cambió o cómo volver.

4.7. SUSTAIN

Sustain necesita sostener continuidad sin fatigar. El canal principal es el tiempo. Presencia mantiene visible el estado. Forma representa proceso. Motion puede indicar actividad pero debe ser de baja demanda. Sonido y háptica deben evitarse.

Función dominante: tiempo + presencia + forma → proceso vivo.

Riesgo: spinner eterno, espera silenciosa o sustain que parece alarma.

5. Matriz de intents y canales

La segunda matriz cruza los intents con los canales. Aquí la pregunta cambia. Ya no preguntamos qué familia es, sino cómo debe evaluarse afectivamente este evento. Los intents no definen el evento. Lo modulan. Por eso esta matriz no se usa sola. Siempre debe leerse junto a una familia.

INTENT	TIEMPO	MOTION	PRESENCIA	FORMA	COLOR	SONIDO	HÁPTICA
neutral	funcional	mínimo	baja	estructura clara	sin carga	normalmente no	normalmente no
affirm	breve	asentamiento suave	baja / discreta	marca ligera	positivo discreto	breve opcional	pulso suave
fulfill	cierre más marcado	resolución visible	media	final claro	positivo claro	ascendente breve	pulso definido
risk	persistente	tensión moderada	local y estable	callout / borde / icono	advertencia moderada	seco contenido	pulso contenido
threat	entrada rápida	saliente / tenso	dominante	bloque crítico	alta saliencia	urgente opcional	vibración fuerte
loss	breve + huella	retirada / descenso	ausencia visible	undo / registro / tachado	grave / desaturado	seco / grave	pulso seco

6. Lectura por intent

neutral — ausencia de juicio afectivo fuerte, no ausencia de estructura. Puede necesitar forma y texto, pero no carga intensa de color, sonido o motion. Riesgo: hacer invisible lo que necesita ser notado.

affirm — confirma suavemente, baja activación positiva. Marca ligera, color discreto, asentamiento breve. No es "objetivo logrado," es "todo va bien." Riesgo: celebrar lo rutinario.

fulfill — resolución positiva, mayor activación que affirm porque cierra una tensión. Motion resolutivo, color positivo visible, sonido ascendente opcional. Riesgo: trivializar el logro o convertirlo en espectáculo.

risk — problema corregible, región negativa moderada. Callout local, color de advertencia, icono, texto, persistencia hasta corrección. Dice "revisa esto," no "actúa ahora." Riesgo: expresarlo como amenaza.

threat — amenaza activa, alta activación negativa. Presencia dominante, alta saliencia, forma crítica, sonido opcional. Dice "atiende ahora." Riesgo: usarlo para todo y destruir su fuerza.

loss — pérdida consumada, comparte valencia negativa con threat pero con menor activación y distinta temporalidad. Retirada, ausencia, huella, undo, color grave. Dice "esto ya se perdió," no alarma sostenida. Riesgo: hacerlo sonar como amenaza cuando ya no hay prevención posible.

Figura 30.1

7. Cómo usar las matrices juntas

Las dos matrices deben cruzarse. No basta con elegir familia. No basta con elegir intent. La lectura final surge de la combinación.

Ejemplo: commit.save + affirm. Familia commit pide huella, cierre, estado persistente. Intent affirm pide baja activación, confirmación suave, poca saliencia. Resultado: marca discreta de guardado, color positivo bajo, sin sonido por defecto, motion mínimo.

Otro ejemplo: signal.alert + threat. Familia signal pide atención, presencia, texto, forma clara. Intent threat pide alta activación, urgencia, acción inmediata. Resultado: presencia dominante, forma crítica, texto claro, color saliente, sonido opcional, persistencia hasta acción.

Figura 30.2

Otro ejemplo: commit.delete + loss. Familia commit pide consecuencia, huella, cierre. Intent loss pide gravedad, baja activación relativa, ausencia significativa. Resultado: retirada del objeto, mensaje de pérdida, undo si existe, color grave/desaturado, sin alarma sostenida.

8. Celdas prohibidas o raras

No todas las combinaciones tienen el mismo sentido.

emerge.open + threat — normalmente incorrecta. La amenaza está en el contenido o señal, no en la apertura. Mejor: emerge.open → signal.warn + threat.

sustain.progress + fulfill — normalmente incorrecta. El proceso no es el resultado. Mejor: sustain.progress → commit.complete + fulfill.

handle.carry + loss — normalmente incorrecta. La pérdida se produce en el resultado, no en el carry. Mejor: handle.drop → commit.delete + loss.

contact.press + fulfill — normalmente incorrecta. El contacto no es culminación. Mejor: contact.press → sustain.progress → commit.complete + fulfill.

COMBINACIÓN	PROBLEMA	ALTERNATIVA
emerge.open + threat	evalúa el marco, no el contenido	emerge.open → signal.warn + threat
sustain.progress + fulfill	confunde proceso y resultado	sustain.progress → commit.complete + fulfill
contact.press + loss	confunde recepción y consecuencia	contact.press → commit.delete + loss
handle.carry + loss	evalúa antes del drop	handle.drop → commit.delete + loss
shift.enter-mode + risk	evalúa el cambio de marco	shift.enter-mode → signal.warn + risk

9. Matrices y accesibilidad

Las matrices también sirven para revisar accesibilidad. Si un evento depende de un solo canal, la matriz lo revela.

signal.warn + risk — si solo se expresa con color amarillo, falta forma, texto, persistencia, icono, relación con el campo.

commit.select + affirm — si solo se expresa con color verde, falta check, borde, estado persistente, forma seleccionada.

sustain.progress — si solo se expresa con spinner, falta texto, estado, quizá progreso real, anuncio controlado.

La matriz obliga a preguntar: ¿qué canal domina? ¿qué canal respalda? ¿qué canal falla? ¿qué canal sobra?

10. Antipatrones de matriz

10.1. USAR TODOS LOS CANALES PORQUE LA MATRIZ LOS MENCIONA

La matriz no obliga a activar todo. Muestra posibilidades y funciones. La matriz también sirve para quitar: si un commit.save + affirm ya tiene marca visual persistente y color positivo, añadir sonido, háptica y motion resolutivo probablemente sobra. La pregunta no es solo "¿qué canal puedo añadir?" sino también "¿qué canal puedo omitir sin perder la lectura?"

10.2. INTERPRETAR LA MATRIZ COMO RECETA FIJA

Cada contexto modifica la decisión. Una app médica, una herramienta creativa y un dashboard financiero no deberían modular igual.

10.3. CONFUNDIR CANAL DOMINANTE CON CANAL ÚNICO

Dominante no significa exclusivo.

10.4. USAR INTENT SIN FAMILIA

risk no dice qué ocurrió. Necesitamos: signal.warn + risk, commit.fail + risk o handle.drop + risk.

10.5. USAR FAMILIA SIN CANAL SUFICIENTE

commit.delete + loss sin huella, sin texto ni ausencia significativa, puede no entenderse.

11. Síntesis

Las matrices semánticas convierten la teoría en herramienta.

La matriz de familias responde: ¿qué tipo de evento es y qué canales suelen hacerlo legible?

La matriz de intents responde: ¿cómo debe evaluarse el evento y qué modulación perceptiva necesita?

Usadas juntas, permiten pasar de una decisión vaga como "pon feedback de success" a una decisión semántica: commit.save + affirm → huella discreta → color positivo leve → sin sonido por defecto → persistencia breve.

PRINCIPIO

Una matriz semántica no prescribe efectos. Organiza funciones perceptivas.

PRINCIPIO

No preguntes primero qué canal usar. Pregunta qué evento debe percibirse y qué función debe cumplir cada canal.


================================================================================
CAPÍTULO 31 — capitulo31_con_diagramas.docx
================================================================================
CAPÍTULO 31

Rangos psicoperceptivos orientativos

Duración, intensidad, persistencia y fatiga

El capítulo anterior convirtió las familias, intents y canales en matrices de decisión.

Pero una matriz todavía deja abierta una pregunta práctica:

PREGUNTA DEL CAPÍTULO

¿Cuánto debe durar, persistir o intensificarse cada evento para conservar su lectura?

Cuánto debe durar un contact.press. Cuánta presencia necesita un signal.warn + risk. Cuánta intensidad puede tener un signal.alert + threat. Cuánto tiempo debe permanecer un undo. Cuánto motion empieza a fatigar. Cuándo un sustain.progress deja de tranquilizar y empieza a desesperar. Cuándo un sonido breve ayuda y cuándo invade.

Esta pregunta es peligrosa. Si damos valores demasiado concretos, caemos en falsa precisión. Si no damos ninguno, dejamos al lector igual que antes.

Por eso este capítulo no propone leyes. Propone rangos psicoperceptivos orientativos. Un rango no dice "usa siempre 120 ms." Dice algo más útil: esta clase de evento suele necesitar una temporalidad breve para preservar su función perceptiva. O: esta señal debe persistir mientras el usuario pueda actuar sobre ella. O: esta intensidad debe mantenerse baja porque el evento ocurre con mucha frecuencia.

Los rangos son regiones de diseño, no números sagrados.

1. Por qué hablar de rangos

La semántica perceptiva no solo depende de qué canal usamos. También depende de cuánto lo usamos.

Un motion correcto puede fallar por exceso de duración. Un color adecuado puede fallar por exceso de saturación. Una señal necesaria puede fallar por desaparecer demasiado pronto. Un sonido útil puede fallar por repetirse demasiado. Un loader puede fallar por durar sin explicar nada. Una vibración puede fallar por ser demasiado intensa o demasiado frecuente.

El canal no trabaja solo por presencia o ausencia. Trabaja por intensidad, duración, ritmo, persistencia, frecuencia y contexto.

DISTINCIÓN

Un rango psicoperceptivo no es una ley. Es una zona en la que un evento conserva mejor su lectura.

2. Fundamento: umbrales, atención y fatiga

Los rangos se apoyan en tres ideas ya desarrolladas en la Parte II.

2.1. VENTANAS DE PERCEPCIÓN

El Capítulo 12 explicó que el tiempo modifica la lectura del evento. Una respuesta muy próxima a la acción se percibe como contacto. Una respuesta más tardía se percibe como reacción. Una espera prolongada exige señal explícita. Por eso contact necesita vivir cerca del gesto.

2.2. ACTIVACIÓN ATENCIONAL

Los intents tienen distinta activación. Affirm es positivo y bajo en activación. Fulfill es positivo y más resolutivo. Risk es negativo moderado. Threat es negativo de alta activación. Loss es negativo, pero no necesariamente urgente. Por eso no todos deben tener la misma intensidad, duración o persistencia.

2.3. FATIGA SENSORIAL

Un canal puede funcionar bien una vez y volverse insoportable por repetición. Un sonido de confirmación puede ser agradable una vez y molesto cincuenta veces. Una microvibración puede reforzar contacto en un gesto aislado y fatigar en un teclado. Un motion de éxito puede resultar expresivo una vez y ridículo si ocurre cada minuto. La frecuencia modifica el rango aceptable.

Figura 31.1

3. Rangos temporales orientativos

No hay valores universales, pero sí regiones útiles.

EVENTO	REGIÓN TEMPORAL ORIENTATIVA	FUNDAMENTO
contact.press	dentro de la ventana de atribución causal	agencia acción-respuesta
commit.save + affirm	breve, sin interrumpir flujo	confirmación suave
commit.complete + fulfill	breve-media, más resolutivo	cierre de tensión
emerge.tooltip	breve-media	aparición auxiliar
emerge.dropdown	breve	opciones locales
shift.enter-mode	media, con orientación	cambio de marco
signal.warn + risk	persistente hasta corrección	permitir acción correctiva
signal.alert + threat	entrada rápida + persistencia hasta acción	urgencia
commit.delete + loss	breve + huella	consecuencia consumada
sustain.progress	mientras dure el proceso	continuidad
handle.carry	baja latencia continua	control directo

Lo importante no es memorizar la tabla. Es entender la lógica. Un contact demasiado largo deja de ser contacto. Un signal.warn + risk demasiado breve no permite corregir. Un sustain.progress sin continuidad parece bloqueo. Un loss sin huella puede parecer simple desaparición.

4. Contact: el rango de la agencia

Contact es la familia más sensible al tiempo. Su pregunta es: ¿el sistema ha sentido mi acción? Para responder, debe ocurrir dentro de la ventana de atribución causal descrita en el Capítulo 12. No necesita durar mucho. Necesita empezar pronto.

Un buen contact.press puede ser casi instantáneo y muy breve: estado pressed, microcompresión, cambio de foco, pulso háptico leve, click opcional. Su función no es expresar belleza. Es preservar agencia.

Si el sistema no puede ejecutar la operación inmediatamente, debe al menos responder al contacto y después sostener el proceso: contact.press → sustain.progress → commit.save + affirm.

Antipatrón: silencio → commit.save + affirm. El sistema puede haber funcionado, pero el usuario no percibe agencia.

5. Commit: el rango del cierre

Commit necesita una señal de cierre. No debe ser tan breve que pase desapercibida. No debe ser tan larga que teatralice el resultado. La duración depende del intent.

commit.save + affirm — confirmación suave, breve, discreta, baja activación. Lectura: guardado, puedes seguir.

commit.complete + fulfill — resolución positiva, puede tener más duración, más motion o más presencia. Lectura: objetivo cumplido.

commit.delete + loss — consecuencia consumada, cierre breve pero huella suficiente. Lectura: esto ya no está disponible.

La clave: commit no siempre necesita más intensidad. Necesita claridad de consecuencia.

6. Signal: el rango de la atención

Signal trabaja con atención, y la atención tiene coste. Una señal demasiado débil se pierde. Una señal demasiado fuerte fatiga. Una señal demasiado breve no se procesa. Una señal demasiado persistente se convierte en ruido.

SIGNAL	PERSISTENCIA	INTENSIDAD
signal.announce + neutral	breve o contextual	baja
signal.notify + neutral	breve-media	baja-media
signal.warn + risk	hasta corrección/cierre	media
signal.alert + threat	hasta acción	alta, pero no infinita

Un risk necesita tiempo para que el usuario lo procese y corrija. Un threat necesita entrar rápido y permanecer mientras la acción sea necesaria. Pero una amenaza no debería gritar indefinidamente.

7. Handle: el rango del control

Handle tiene requisitos de rango muy específicos porque es la única familia de control motor continuo.

Durante handle.carry, la latencia debe ser mínima y constante. Cualquier retraso rompe la sensación de control directo. El usuario no interpreta un lag como "el sistema procesa" — lo interpreta como "no estoy controlando esto."

En handle.pick, el rango es breve: un cambio de estado inmediato (elevación, sombra, háptica) que diga "lo tienes." En handle.drop, el rango depende del resultado: si es commit.reorder + affirm, marca breve; si es commit.delete + loss, huella y gravedad.

La regla de handle: el carry debe ser silencioso y fluido. La evaluación se concentra en pick y drop.

Antipatrón: motion durante todo el carry que compite con el control del usuario. O lag variable que hace que el objeto "salte."

8. Sustain: el rango de la espera

Sustain existe porque hay tiempo sin resultado. Su rango no se mide como un evento breve, sino como una continuidad.

DURACIÓN PERCIBIDA	NECESIDAD
muy breve	quizá no mostrar nada o feedback mínimo
breve	indicador simple
media	texto de estado
larga	progreso, explicación o control
indefinida	alternativa, cancelación o cambio de estado

Un spinner breve puede funcionar. Un spinner largo se vuelve pregunta. Un spinner eterno se vuelve acusación.

La regla: cuanto más dura una espera, más información debe ofrecer.

9. Emerge y shift: rangos de entrada y orientación

Emerge — una aparición local debe ser lo bastante clara para que el usuario entienda qué apareció, de dónde viene y a qué pertenece. Pero no debe tener el peso de un cambio de marco. Un tooltip, dropdown o popover necesita entrada breve y ligera. Si dura demasiado o tiene demasiada profundidad, puede parecer shift.

Shift — un cambio de marco necesita más orientación. Abrir un modal, entrar en edición, cambiar de vista o activar una command palette implica otra relación operativa. La transición debe ser suficiente para orientar, pero no tan larga que interrumpa.

10. Sonido y háptica: rangos de intrusión

Sonido y háptica entran en el cuerpo o en el entorno del usuario. Por eso sus rangos deben ser más conservadores.

Eventos frecuentes: sonido/háptica mínimos o ausentes. Eventos raros y relevantes: sonido/háptica posibles. Eventos críticos: sonido/háptica opcionales, nunca únicos. Sustain: evitar sonido/háptica continuos. Contact frecuente: evitar refuerzo fuerte. Threat: entrada saliente, no bucle agresivo.

Figura 31.2

11. Saturación y frecuencia

La intensidad aceptable depende de la frecuencia. Un evento que ocurre una vez al día puede permitirse más presencia. Un evento que ocurre cien veces por hora debe ser casi invisible.

EVENTO	FRECUENCIA PROBABLE	INTENSIDAD RECOMENDABLE
contact.press	muy alta	mínima
commit.save + affirm	alta	discreta
sustain.progress	media	baja saliencia
signal.notify + neutral	media	controlada
signal.warn + risk	media-baja	clara
commit.complete + fulfill	baja-media	resolutiva
signal.alert + threat	baja	alta, pero breve
commit.delete + loss	baja	grave, con huella

PRINCIPIO

La gramática debe tener memoria de frecuencia. No todo evento puede pedir atención como si fuera único.

12. Rangos y accesibilidad

Los rangos también deben adaptarse a accesibilidad. Un usuario puede necesitar más tiempo para leer una señal. Otro puede necesitar menos motion. Otro puede tener sonido desactivado. Otro puede fatigarse con vibración.

Por eso los rangos no pueden ser fijos. Deben poder ajustarse mediante reduced motion, controles de sonido, duración suficiente de mensajes, persistencia de estados importantes, opción de cerrar manualmente, evitar timeouts injustificados y alternativas a señales efímeras.

Una señal importante no debería desaparecer antes de que el usuario haya tenido oportunidad razonable de procesarla.

13. Tabla síntesis de rangos

FAMILIA / INTENT	RANGO ORIENTATIVO	EVITAR
contact	inmediato, muy breve	retraso o teatralización
commit + affirm	breve y discreto	celebración
commit + fulfill	breve-media, resolutivo	trivialidad o espectáculo
signal + risk	persistente hasta corrección	desaparición rápida
signal + threat	entrada rápida + persistencia sobria	alarma sostenida
commit + loss	breve + huella	desaparición sin registro
handle	latencia mínima continua	lag o evaluación durante carry
emerge	entrada/salida ligera	peso de modal
shift	transición orientadora	cambio invisible
sustain	mientras dure proceso	spinner eterno sin información

14. Antipatrones de rango

14.1. MICROFEEDBACK LENTO

Un contact que empieza tarde. Problema: se pierde agencia.

14.2. CONFIRMACIÓN EXCESIVA

Un affirm que se celebra como fulfill. Problema: todo parece logro.

14.3. WARNING FUGAZ

Un risk que desaparece antes de corregir. Problema: el usuario no puede actuar.

14.4. THREAT INFINITO

Una alerta de sesión que suena en loop, vibra el dispositivo y parpadea sin control. El usuario no puede silenciarla sin atender. Si está en una reunión, en transporte público o usando auriculares, la interfaz se convierte en agresión. El problema no es la amenaza — la sesión sí puede expirar. El problema es que la intensidad no tiene techo ni control. La entrada puede ser saliente, pero la persistencia debe ser sobria: presencia visual firme, texto claro, sonido breve si procede, y después silencio mientras la alerta siga visible.

14.5. LOSS SIN HUELLA

Algo se elimina y desaparece sin rastro. Problema: se confunde pérdida con ocultación.

14.6. SPINNER ETERNO

Proceso sin explicación ni salida. Problema: se rompe confianza.

14.7. HANDLE CON LAG VARIABLE

Un objeto arrastrado que a veces sigue el gesto y a veces salta. Problema: el usuario pierde sensación de control directo.

15. Síntesis

Los rangos psicoperceptivos no son valores universales. Son regiones de diseño. Sirven para mantener la función del evento: contact → agencia, commit → cierre, signal → atención, handle → control, emerge → presencia, shift → orientación, sustain → continuidad.

PRINCIPIO

Un evento no solo necesita el canal correcto. Necesita la cantidad correcta de canal.

PRINCIPIO

La intensidad debe corresponder a consecuencia, urgencia, frecuencia, reversibilidad y accesibilidad.


================================================================================
CAPÍTULO 32 — capitulo32_con_diagramas.docx
================================================================================
CAPÍTULO 32

Accesibilidad aplicada

Migración semántica en flujos reales

La accesibilidad ya apareció varias veces en este libro. Apareció en la Parte I como prueba de que una semántica no debe depender de un único canal. Apareció en la Parte II como reducción de canales. Apareció en las familias semánticas como exigencia concreta.

Pero hasta ahora la accesibilidad ha sido tratada sobre todo por partes. Este capítulo la aplica a flujos completos.

Un usuario con reduced motion no pierde "una animación"; puede perder causalidad, continuidad, cambio de marco o cierre. Un usuario que no distingue color no pierde "rojo o verde"; puede perder riesgo, amenaza, confirmación o pérdida. Un usuario sin sonido no pierde "un aviso"; puede perder una señal fuera de foco. Un usuario que navega con teclado no pierde "drag"; puede perder la posibilidad de manipular. Un usuario que usa lector de pantalla no pierde "layout"; puede perder presencia, marco, orden y consecuencia.

PREGUNTA DEL CAPÍTULO

¿La semántica del evento sobrevive en condiciones perceptivas distintas?

Figura 32.1

1. Accesibilidad aplicada no es traducción literal

Cuando un canal se reduce, la solución no consiste en copiar el mismo estímulo por otro canal. La pregunta es anterior: ¿qué significado transportaba ese canal?

Si el motion transportaba contacto, el reemplazo debe conservar contacto. Si transportaba continuidad, debe conservar continuidad. Si el color transportaba riesgo, el reemplazo debe conservar riesgo corregible. Si el sonido transportaba amenaza, el reemplazo debe conservar urgencia.

Esto es migración semántica.

PRINCIPIO

La accesibilidad aplicada no conserva necesariamente los mismos estímulos. Conserva la misma lectura semántica.

2. Caso 1: error de formulario

Evento base: signal.warn + risk. El usuario intenta enviar un formulario y un campo obligatorio está vacío. La lectura semántica esperada es: hay un problema corregible aquí. No: todo ha fallado. No: hay una amenaza crítica.

2.1. VERSIÓN FRÁGIL

input border: red. Problemas: depende solo de color, no explica qué ocurre, no comunica corrección, puede no ser detectado por usuarios con baja visión o daltonismo, puede no estar vinculado al campo, puede no ser anunciado tras submit.

2.2. VERSIÓN ACCESIBLE SEMÁNTICAMENTE

CANAL	FUNCIÓN
Color	refuerzo de advertencia moderada
Forma	borde, callout o contorno local
Icono	reconocimiento rápido
Texto	explicación del problema
Presencia	persistencia hasta corrección
Foco	llevar al primer error si bloquea envío
Relación accesible	mensaje vinculado al campo
Tiempo	no desaparecer automáticamente

2.3. MIGRACIONES

Sin color: el campo sigue comunicando error mediante icono, mensaje, borde, posición y relación con el campo.

Sin color Y sin visión parcial: el mensaje debe estar vinculado al campo mediante aria-describedby. El usuario debe poder oír: "El campo correo electrónico es obligatorio."

Sin motion: no pasa nada si el error no tiembla. El mensaje persistente sostiene la semántica.

Con varios errores: conviene añadir resumen ("Hay 3 errores en el formulario") y permitir saltar a cada campo.

3. Caso 2: operación larga con reduced motion

Secuencia base: contact.press → sustain.progress → commit.complete + fulfill. El usuario sube un archivo grande.

3.1. QUÉ SE PERDERÍA SI SOLO QUITAMOS MOTION

Si eliminamos todas las animaciones sin más: el contacto puede sentirse menos inmediato, el progreso puede parecer estático, el cierre puede perder resolución, el usuario puede no distinguir entre proceso activo y resultado final. Reducir motion no debe amputar la estructura temporal.

3.2. VERSIÓN ACCESIBLE SEMÁNTICAMENTE

Contact: estado pressed claro, cambio inmediato de forma, foco visible, quizá sonido o háptica opcional.

Sustain: barra de progreso sin motion excesivo, texto "Subiendo archivo…", porcentaje si existe, estado persistente, actualización discreta.

Commit: mensaje visible, marca de completado, estado persistente, sonido opcional, color positivo claro pero no único.

La lectura se conserva: me ha sentido → sigue trabajando → objetivo cumplido. Aunque el movimiento se reduzca.

DISTINCIÓN

Reduced motion no significa interfaz sin tiempo. Significa tiempo expresado por canales menos problemáticos.

4. Caso 3: eliminación con undo

Secuencia base: signal.warn + threat → commit.delete + loss → emerge.present undo.

4.1. VERSIÓN FRÁGIL

Botón rojo, tarjeta desaparece, toast breve "Eliminado", undo aparece durante dos segundos, sin anuncio accesible, foco queda en lugar ambiguo. Problemas: amenaza y pérdida se comunican con el mismo color, la desaparición puede parecer ocultación, el undo puede no percibirse, usuarios de teclado o lector pueden perder contexto.

4.2. VERSIÓN ACCESIBLE SEMÁNTICAMENTE

Antes (signal.warn + threat): texto claro, forma de advertencia, presencia suficiente, foco en decisión, color como refuerzo. Lectura: puedes evitar una consecuencia.

Después (commit.delete + loss): retirada de la tarea, mensaje de consecuencia, actualización de lista, huella temporal, no alarma sostenida. Lectura: esto ya se eliminó.

Reparación (emerge.present undo): barra o mensaje persistente, botón de deshacer claro, tiempo suficiente, foco no perdido, anuncio si procede. Lectura: puedes reparar temporalmente.

MOMENTO	EVENTO	RIESGO	SOPORTE NECESARIO
Antes	signal.warn + threat	no percibir gravedad	texto, foco, forma, color
Después	commit.delete + loss	confundir con ocultación	mensaje, huella, actualización
Reparación	emerge.present undo	no llegar a deshacer	persistencia, botón claro, foco/anuncio

5. Caso 4: drag-and-drop accesible

Secuencia base: handle.pick → handle.carry → handle.drop → commit.reorder + affirm.

5.1. VERSIÓN FRÁGIL

Solo funciona con ratón o touch. No hay alternativa de teclado. No se anuncia la posición. No hay forma clara de cancelar. La semántica de manipulación depende completamente de un gesto físico y visual.

5.2. QUÉ DEBE CONSERVARSE

La accesibilidad no exige que todos hagan el mismo gesto. Exige que todos puedan realizar y comprender el mismo evento operativo. El evento no es "arrastrar con ratón." El evento es: mover un objeto de una posición a otra.

5.3. VERSIÓN ACCESIBLE SEMÁNTICAMENTE

Opciones: activar modo "mover" con teclado, seleccionar elemento, botones "subir"/"bajar", elegir destino, anunciar posición actual, anunciar resultado, permitir cancelar, marcar destino válido, conservar foco.

Lo importante es que la semántica se conserva: he elegido este objeto → lo estoy moviendo → quedó en otra posición.

PRINCIPIO

La accesibilidad no exige el mismo gesto. Exige el mismo evento operativo comprensible.

6. Caso 5: señal crítica sin sonido ni color

Evento base: signal.alert + threat. La sesión expirará en 30 segundos si el usuario no actúa.

6.1. SIN SONIDO

La amenaza debe migrar a: presencia dominante, texto claro, cuenta atrás si procede, color de alta saliencia, forma crítica, foco si bloquea acción, persistencia hasta respuesta.

6.2. SIN COLOR

Debe sobrevivir mediante forma, texto, icono, posición, persistencia, quizá motion contenido.

6.3. SIN SONIDO Y SIN COLOR

Este es el caso extremo donde la migración se pone a prueba. La amenaza debe sobrevivir solo con forma, texto, posición, tamaño y persistencia. Un bloque de texto grande, bien posicionado, con icono reconocible, foco capturado y cuenta atrás textual puede comunicar urgencia sin depender de color ni sonido. Si la semántica sobrevive aquí, la arquitectura multicanal funciona.

6.4. CON LECTOR DE PANTALLA

Debe anunciarse con prioridad adecuada, pero sin crear ruido continuo. La semántica no es "hacer ruido." Es permitir acción antes de la consecuencia.

7. Principios de accesibilidad aplicada

Principio 1 — Conservar significado, no estímulo. Si un canal se reduce, pregunta qué significado transportaba.

Principio 2 — Diferenciar evento y gesto. El gesto puede cambiar. El evento debe mantenerse. Drag físico puede convertirse en mover con teclado.

Principio 3 — No depender de color para intent. Risk, threat, loss, affirm y fulfill deben sobrevivir sin color.

Principio 4 — No depender de motion para causalidad. Si el movimiento se reduce, la agencia debe migrar a estado, foco, texto, sonido o háptica opcional.

Principio 5 — No depender de sonido para urgencia. Una amenaza debe tener presencia visual/textual suficiente.

Principio 6 — No hacer efímero lo importante. Señales críticas y resultados relevantes deben dejar huella.

Principio 7 — Adaptar intensidad. Accesibilidad también significa reducir fatiga sensorial.

8. Ficha de migración semántica

Para revisar un flujo:

Flujo: eliminar tarea con undo. Evento principal: commit.delete + loss. Familias: signal, commit, emerge. Intents: threat, loss, neutral. Canales dominantes: presencia, forma, texto, color. Sin color: se mantiene con texto, forma, icono. Reduced motion: retirada menos animada, huella persistente. Sin sonido: no afecta. Teclado: foco en confirmación y luego undo. Lector: anuncio de eliminación y acción disponible. Significado en riesgo: pérdida + reparación temporal. Migración: mensaje persistente + undo + actualización de lista.

Figura 32.2

9. Antipatrones de accesibilidad aplicada

9.1. ADAPTAR EL COMPONENTE, NO EL EVENTO

El componente cumple WCAG, pero el flujo completo no se entiende. El usuario puede activar cada control pero no comprende la secuencia semántica.

9.2. QUITAR MOTION SIN SUSTITUIR SIGNIFICADO

Se elimina mareo, pero también causalidad y continuidad. El usuario deja de percibir qué causó qué.

9.3. SILENCIAR SIN RESPALDO

Se apaga sonido, pero la alerta fuera de foco se pierde. El usuario no tiene otra forma de saber que algo reclama atención.

9.4. ALTO CONTRASTE SIN ESTRUCTURA

Se mejora visibilidad, pero la jerarquía de eventos sigue confusa. Se ve mejor, pero no se entiende mejor.

9.5. TECLADO SIN SEMÁNTICA

Se puede llegar al control, pero no entender el estado, resultado o consecuencia del evento.

9.6. LECTOR DE PANTALLA SIN SECUENCIA

Se anuncian piezas aisladas, pero no el flujo. El usuario oye elementos pero no comprende la operación.

10. Síntesis

La accesibilidad aplicada es donde la teoría multicanal demuestra si funciona.

No basta con que un canal tenga alternativa. No basta con que un componente cumpla una regla. No basta con que haya etiquetas.

PRINCIPIO

Una adaptación accesible no conserva necesariamente los mismos estímulos. Conserva la misma lectura semántica.

PRINCIPIO

Cuando un canal falla, migra el significado, no el adorno.

Figura 32.3


================================================================================
CAPÍTULO 33 — capitulo33_con_diagramas.docx
================================================================================
CAPÍTULO 33

Antipatrones globales

Cuando la gramática se rompe

Una teoría no se entiende del todo hasta que muestra sus errores.

Hasta ahora hemos definido eventos, familias, intents, canales, composición, matrices, rangos y accesibilidad aplicada. Pero en una interfaz real, los problemas no siempre aparecen como fallos aislados. Muchas veces aparecen como rupturas de gramática.

No es solo que una animación sea demasiado larga. No es solo que un color tenga poco contraste. No es solo que un sonido moleste. El problema más profundo suele ser otro: el sistema comunica una clase de evento distinta de la que realmente está ocurriendo.

PREGUNTA DEL CAPÍTULO

¿Qué ocurre cuando la interfaz dice una cosa y el evento significa otra?

1. Todo es success

Qué se hace mal: toda operación positiva se comunica igual. Un autoguardado, un toggle, una preferencia cambiada, un formulario enviado, una subida terminada — todo recibe el mismo verde, el mismo check, la misma animación. commit.save + affirm y commit.complete + fulfill quedan aplastados bajo una sola categoría: success.

Por qué parece correcto: porque ambos casos son positivos. El sistema hizo algo bien. La convención heredada del semáforo refuerza esta simplificación.

Qué fundamento viola: la distinción entre valencia y activación. Affirm confirma normalidad. Fulfill resuelve una tensión. El autoguardado no debería sentirse como culminación.

Corrección: separar confirmación suave (marca discreta, baja saliencia, sin sonido) de resolución positiva (motion resolutivo, cierre visible, color positivo más claro).

PRINCIPIO

Si todo es success, nada se siente realmente logrado.

2. Todo es danger

Qué se hace mal: todo evento negativo fuerte se comunica igual. Una advertencia, un recurso eliminado, un fallo de validación, una conexión perdida, una acción irreversible — todo se comunica con rojo, alerta y tono grave.

Por qué parece correcto: porque todos tienen valencia negativa. La convención permite agruparlo todo bajo danger.

Qué fundamento viola: la diferencia temporal y afectiva entre risk (problema corregible), threat (amenaza activa) y loss (pérdida consumada). Una amenaza convoca acción. Una pérdida registra consecuencia. Un riesgo pide corrección. Si una pérdida se comunica como amenaza, el sistema genera urgencia donde ya no hay prevención posible.

Corrección: separar los tres casos. signal.warn + risk para "revisa esto." signal.alert + threat para "actúa ahora." commit.delete + loss para "esto ya se perdió."

PRINCIPIO

No todo lo negativo debe gritar. A veces debe corregirse. A veces debe evitarse. A veces solo debe registrarse.

3. Info como cajón de sastre

Qué se hace mal: todo lo que no es success, warning o danger se llama info. Un dato contextual, un mensaje neutro, una notificación, un consejo, una ayuda, una confirmación leve — todo cae en info.

Por qué parece correcto: porque info parece una categoría segura. No es positivo ni negativo.

Qué fundamento viola: la separación entre saliencia atencional y evaluación afectiva. Info no responde a "¿cómo se evalúa esto?" sino a "¿debo notarlo?" Eso pertenece mejor a signal.

Corrección: sustituir info como intent por composiciones de señal neutra. signal.announce + neutral para información contextual. signal.notify + neutral para notificación sin carga evaluativa.

DISTINCIÓN

Info no es una emoción del evento. Es una función de atención.

4. Todo lo que aparece es alerta

Qué se hace mal: cualquier cosa que aparece se diseña como si reclamara atención fuerte. Un tooltip entra con demasiada saliencia. Un dropdown parece una alerta. Una ayuda contextual usa color de warning.

Por qué parece correcto: porque si algo aparece, el equipo quiere que el usuario lo vea. Entonces se aumenta contraste, motion, sombra o color.

Qué fundamento viola: la diferencia entre emerge y signal. Emerge introduce presencia. Signal reclama atención. No toda aparición es una señal.

Corrección: emerge.open para dropdown. emerge.present para tooltip. signal.warn + risk solo si lo que aparece comunica problema corregible. signal.alert + threat solo si exige atención inmediata.

DISTINCIÓN

Aparecer no es advertir. Entrar en el campo no es reclamarlo entero.

5. Modal rojo

Qué se hace mal: un modal contiene una advertencia y todo el modal se vuelve peligroso. Fondo rojo, borde rojo, botones rojos, toda la superficie absorbe el intent.

Por qué parece correcto: porque el contenido del modal es grave. Parece razonable que el modal completo se diseñe como danger.

Qué fundamento viola: la distinción entre marco y mensaje. El modal es shift.enter-mode — cambia el marco operativo. La advertencia dentro del modal es signal.warn + threat. El modal no es la amenaza. El mensaje porta la amenaza.

Corrección: componer shift.enter-mode + signal.warn + threat. El modal comunica cambio de marco mediante profundidad y foco. La advertencia comunica amenaza mediante forma, texto, color e icono.

PRINCIPIO

El intent debe vivir en la figura evaluable, no en el contenedor estructural.

6. Spinner de error

Qué se hace mal: un proceso en curso se comunica con color, motion o tono de error. Un spinner rojo. Un loader tenso. Una espera con alarma.

Por qué parece correcto: porque esperar genera ansiedad. El equipo quiere avisar de que algo importante está ocurriendo.

Qué fundamento viola: la diferencia entre sustain y signal/commit. sustain.progress comunica "esto sigue ocurriendo," no "esto falló" ni "esto es peligroso."

Corrección: mantener sustain neutro. Si aparece un problema durante el proceso: sustain.progress + signal.warn + risk. Si falla: commit.fail + risk.

DISTINCIÓN

Una espera no es un error por durar. Es un proceso que necesita continuidad.

7. Commit anticipado

Qué se hace mal: la interfaz comunica resultado antes de que exista. Un botón muestra success al pulsar. Un formulario dice "enviado" antes de recibir respuesta.

Por qué parece correcto: porque el sistema quiere dar feedback rápido y sentirse optimista.

Qué fundamento viola: la diferencia entre contact, sustain y commit. Contact dice "he recibido tu acción." Sustain dice "sigo trabajando." Commit dice "ya terminó." Si se usa commit en el momento de contact, la interfaz promete una consecuencia que aún no existe.

Corrección: contact.press → sustain.progress → commit.complete + fulfill.

PRINCIPIO

No celebres lo que todavía no ha ocurrido.

8. Pérdida sin huella

Qué se hace mal: algo desaparece y no queda rastro. Una tarjeta se elimina con fade out. Un archivo desaparece de una lista. No hay mensaje, undo, registro ni estado.

Por qué parece correcto: porque visualmente la desaparición parece suficiente. El objeto ya no está. La interfaz se limpió.

Qué fundamento viola: la diferencia entre desaparición y pérdida. emerge.hide no es commit.delete + loss. Una pérdida no solo retira presencia — cambia disponibilidad operativa.

Corrección: commit.delete + loss con huella: retirada, mensaje, undo si existe, actualización de estado.

DISTINCIÓN

Una pérdida importante no debe desaparecer como si solo se hubiera ocultado.

9. Drag sin alternativa

Qué se hace mal: la única forma de manipular un objeto es arrastrar con ratón o touch.

Por qué parece correcto: porque visualmente el drag-and-drop es intuitivo para muchos usuarios.

Qué fundamento viola: la accesibilidad operativa de handle. Handle no significa "arrastrar con ratón." Significa "controlar directamente un objeto."

Corrección: ofrecer alternativas: botones subir/bajar, seleccionar y elegir destino, mover con teclado, anuncio de posición, cancelación clara.

PRINCIPIO

La interfaz puede cambiar el gesto. No debe perder el evento.

10. Sonido decorativo

Qué se hace mal: la interfaz suena sin necesidad semántica. Cada click suena. Cada notificación suena igual. Cada éxito tiene chime. Los procesos tienen loop sonoro.

Por qué parece correcto: porque el sonido parece añadir riqueza o personalidad.

Qué fundamento viola: la relación entre canal y evento. El sonido no debe existir porque "queda bien." Debe reforzar una dimensión que el evento necesita.

Corrección: sonido solo si responde a función clara: contacto, cierre, urgencia, pérdida, fuera de foco.

PRINCIPIO

Si un sonido no ayuda a reconocer qué ocurrió, cuándo ocurrió o cómo debe evaluarse, probablemente sobra.

11. Todo vibra

Qué se hace mal: la interfaz usa háptica para todo. Cada toque, selección, error, scroll y notificación vibra.

Por qué parece correcto: porque la háptica parece reforzar contacto.

Qué fundamento viola: la proporcionalidad corporal. La háptica ocurre en el cuerpo del usuario. Puede ayudar pero también invadir y fatigar.

Corrección: reservar háptica para contacto relevante, pick/drop, encaje, alerta importante, pérdida significativa. Debe ser opcional, proporcional y nunca única.

DISTINCIÓN

La háptica no es más feedback. Es contacto corporal con el evento.

12. Color como semántica

Qué se hace mal: el color define el significado completo del evento. Rojo = error. Verde = success. Amarillo = warning. Azul = info.

Por qué parece correcto: porque es la convención heredada. Fácil, familiar, rápida.

Qué fundamento viola: el principio central del sistema de intents. El intent no nace del color. Nace de la evaluación del evento en el espacio valencia/activación.

Corrección: partir de evento → evaluación → intent → canales. No de color → significado.

PRINCIPIO

El color expresa la semántica. No la funda.

13. Señales efímeras

Qué se hace mal: mensajes importantes aparecen y desaparecen demasiado rápido. Un error, una pérdida, una advertencia, un undo — el usuario no alcanza a leer, actuar o recuperar.

Por qué parece correcto: porque el diseño busca no interrumpir. Los mensajes efímeros parecen ligeros y poco invasivos.

Qué fundamento viola: accesibilidad temporal y persistencia semántica. Si un evento exige acción, corrección o reconocimiento, debe persistir lo suficiente.

Corrección: affirm breve. Risk hasta corrección. Threat hasta acción. Loss con huella. Undo con duración suficiente y accesible.

DISTINCIÓN

Lo importante no debe existir solo durante un instante.

14. Shift invisible

Qué se hace mal: el contexto cambia pero el usuario no recibe orientación. Una nueva vista aparece sin foco. Un modal abre pero el lector sigue en el fondo. Un modo de edición se activa sin señal.

Por qué parece correcto: porque visualmente el cambio parece claro para quien lo diseña.

Qué fundamento viola: la función de shift. El usuario necesita saber dónde está, qué puede hacer, cómo vuelve, qué cambió.

Corrección: todo shift debe cuidar foco, título, profundidad, landmarks, navegación de retorno, estado de modo.

PRINCIPIO

Si el usuario no sabe dónde está, el shift falló.

15. Tabla resumen

ANTIPATRÓN	QUÉ CONFUNDE	CORRECCIÓN
Todo es success	affirm con fulfill	separar confirmación y culminación
Todo es danger	risk, threat, loss	separar riesgo, amenaza y pérdida
Info como cajón	saliencia con intent	signal + neutral
Todo aparece como alert	emerge con signal	separar presencia y atención
Modal rojo	marco con mensaje	shift + signal.threat
Spinner de error	proceso con fallo	sustain + señal si procede
Commit anticipado	contacto con resultado	contact → sustain → commit
Pérdida sin huella	ocultación con pérdida	commit.loss + huella
Drag sin alternativa	gesto con evento	alternativa operativa
Sonido decorativo	canal con adorno	sonido solo si comunica evento
Todo vibra	feedback con invasión	háptica proporcional
Color como semántica	canal con intent	intent antes que color
Señales efímeras	ligereza con pérdida	persistencia proporcional
Shift invisible	cambio sin orientación	foco y estructura

16. Síntesis

Los antipatrones globales muestran que la gramática puede romperse de muchas formas. No basta con que un componente funcione. No basta con que una animación sea fluida. No basta con que un color sea reconocible. La pregunta es: ¿el sistema comunica el evento correcto, con la intensidad correcta, por los canales correctos, en el momento correcto?

DISTINCIÓN

Un antipatrón semántico no es solo una mala práctica visual. Es una contradicción entre el evento que ocurre y el evento que la interfaz hace percibir.

PRINCIPIO

Cuando una interfaz se siente rara, muchas veces no falla el efecto. Falla la gramática.

Figura 33.1

Figura 33.2

Figura 33.3


================================================================================
CAPÍTULO 34 — capitulo34_con_diagramas.docx
================================================================================
CAPÍTULO 34

Validación de una semántica perceptiva

Cómo saber si el sistema comunica lo que cree comunicar

Una teoría de la interfaz no debería sostenerse solo porque suene coherente. Si este libro propone una gramática perceptiva del evento, debe poder hacerse una pregunta incómoda:

PREGUNTA DEL CAPÍTULO

¿Cómo sabemos si el usuario percibe el evento que creemos estar comunicando?

Porque una interfaz puede estar muy bien construida desde el punto de vista técnico y aun así fracasar semánticamente. El botón funciona. La animación corre a 60 fps. El color cumple contraste. Pero el usuario puede no entender qué ocurrió, si el sistema recibió su acción, si algo sigue procesando, si algo ya terminó, si debe corregir, si algo se perdió.

Figura 34.1

1. Qué significa validar una semántica

Validar una semántica perceptiva significa comprobar si existe correspondencia entre tres cosas: el evento que el sistema quería comunicar, las señales perceptivas utilizadas y la lectura real del usuario.

Si el sistema quería comunicar signal.warn + risk pero el usuario lee signal.alert + threat, la semántica falló. Si quería comunicar commit.delete + loss pero el usuario lee emerge.hide, la semántica falló. Si quería comunicar sustain.progress pero el usuario lee "sistema bloqueado", la semántica falló.

PRINCIPIO

Una semántica no se valida preguntando si el efecto gusta. Se valida preguntando qué evento ha entendido el usuario.

2. Qué no es validación semántica

No es solo usabilidad general — un usuario puede completar una tarea sin entender los eventos intermedios. No es test de preferencia — preguntar si gusta una animación no valida si comunica contact o commit. No es solo accesibilidad técnica — roles correctos no garantizan lectura correcta. No es solo QA funcional — que el estado cambie no significa que el usuario lo perciba.

3. Qué se valida

NIVEL	PREGUNTA
Familia	¿qué tipo de evento percibió?
Verbo	¿qué cree que ocurrió concretamente?
Intent	¿cómo evalúa el evento?
Canal	¿qué señales usó para entenderlo?
Secuencia	¿entendió el orden de los eventos?
Accesibilidad	¿se conserva la lectura si se reduce un canal?
Fatiga	¿la señal sigue siendo proporcional en repetición?

4. Protocolo 1 — Test de lectura inmediata

Mostrar una interacción y preguntar inmediatamente: ¿qué acaba de ocurrir?

Ejemplo contact: evento diseñado contact.press. Respuestas esperadas: "he pulsado", "el botón respondió." Respuestas problemáticas: "se ha guardado", "no sé si ha pasado algo."

Ejemplo sustain: evento diseñado sustain.progress. Respuestas esperadas: "está cargando", "sigue trabajando." Respuestas problemáticas: "ha fallado", "se bloqueó."

Ejemplo loss: evento diseñado commit.delete + loss. Respuestas esperadas: "se eliminó", "ya no está." Respuestas problemáticas: "se ocultó", "se cerró", "no sé dónde fue."

PRINCIPIO

Si el usuario no puede decir qué ocurrió, la interfaz no comunicó un evento. Comunicó un cambio.

Figura 34.2

5. Protocolo 2 — Test de diferenciabilidad

Comparar dos eventos y preguntar: ¿qué diferencia percibes?

Ejemplo contact vs commit: evento A contact.press, evento B commit.save + affirm. Respuesta esperada: "en el primero solo responde, en el segundo se guardó." Respuesta problemática: "parecen lo mismo."

Ejemplo risk vs threat: evento A signal.warn + risk, evento B signal.alert + threat. Pregunta: ¿cuál requiere actuar antes? Respuesta esperada: "la segunda." Respuesta problemática: "parecen igual de graves."

Figura 34.3

6. Protocolo 3 — Test de intent

Validar si el usuario percibe correctamente la evaluación del evento. No se pregunta "¿esto es risk?" Se pregunta con lenguaje natural.

INTENT	PREGUNTA DE VALIDACIÓN
neutral	¿esto parece informativo sin carga fuerte?
affirm	¿esto confirma que todo va bien sin interrumpir?
fulfill	¿esto parece objetivo cumplido?
risk	¿esto parece corregible?
threat	¿esto exige actuar ahora?
loss	¿esto ya ocurrió y dejó consecuencia?

7. Protocolo 4 — Test de reducción de canal

Probar el mismo evento reduciendo un canal: sin color, con reduced motion, sin sonido, solo teclado, lector de pantalla. La pregunta no es "¿se sigue viendo parecido?" sino "¿se sigue entendiendo el mismo evento?"

8. Protocolo 5 — Test de secuencia

Mostrar una operación completa y preguntar: ¿qué pasó primero, después y al final? Si el usuario percibe solo "hubo error y luego success", la composición perdió matiz.

9. Protocolo 6 — Test de fatiga

Un evento puede funcionar una vez y fallar por repetición. Preguntas: ¿seguiría siendo tolerable después de 20 veces? ¿se vuelve molesto? ¿pierde significado? Un microclick puede ser útil una vez pero fatigar en cada tecla. Un guardado con animación puede ser agradable una vez pero absurdo en cada autoguardado.

10. La ficha completa de validación semántica

Nombre del flujo:

Evento o secuencia evaluada:

Familia esperada:

Intent esperado:

Canales usados:

Canal dominante:

Lectura esperada:

Lectura real:

Diferencia detectada:

¿Se distingue de eventos cercanos?

¿Sobrevive sin color?

¿Sobrevive con reduced motion?

¿Sobrevive sin sonido?

¿Sobrevive con teclado?

¿Produce fatiga por repetición?

Corrección propuesta:

11. Cómo interpretar los resultados

La validación busca patrones. Si un usuario se confunde, puede ser ruido. Si varios confunden lo mismo, hay problema.

RESPUESTA DEL USUARIO	DIAGNÓSTICO PROBABLE	CORRECCIÓN
"No sé qué pasó"	evento poco legible	reforzar presencia / texto / huella
"Se guardó" ante contact	commit anticipado	separar contact de commit
"Parece peligroso" ante risk	exceso de activación	reducir saliencia
"Parece oculto" ante loss	falta huella	mensaje / undo / registro
"Parece modal" ante dropdown	profundidad excesiva	reducir shift, reforzar emerge
"Se bloqueó" ante sustain	continuidad insuficiente	texto / progreso
"Molesta tras repetir"	fatiga sensorial	reducir intensidad / frecuencia

12. Validación sin laboratorio

No hace falta laboratorio formal. Un equipo puede hacer validación semántica con prototipo interactivo, 5-8 usuarios, grabación de pantalla, preguntas inmediatas, comparación entre variantes, prueba con reduced motion, revisión con teclado, revisión sin color.

PRINCIPIO

La validación semántica no pregunta si el usuario puede usar la interfaz. Pregunta si puede leer lo que la interfaz está diciendo.

13. Antipatrones de validación

Preguntar si gusta — gusto no equivale a lectura. Validar solo resultado final — el usuario puede completar la tarea sin entender los eventos intermedios. Probar solo versión completa — si no pruebas reducción de canales, no sabes si la semántica es robusta. Confundir rapidez con claridad — una interacción rápida puede ser ambigua. Preguntar con términos del sistema — no preguntes "¿percibiste risk?" sino "¿esto parecía corregible o urgente?" Ignorar fatiga — una microinteracción agradable puede ser insoportable en repetición.

14. Síntesis

La validación semántica convierte la teoría en herramienta comprobable.

DISTINCIÓN

Una semántica perceptiva no debe defenderse solo porque suene coherente. Debe poder ponerse a prueba.

PRINCIPIO

Si el usuario interpreta otro evento distinto del que el sistema quería comunicar, la semántica falló aunque la interfaz funcione.


================================================================================
CAPÍTULO 35 — capitulo35_con_diagramas.docx
================================================================================
CAPÍTULO 35

De la teoría al sistema

Nombres, documentación, tokens y diseño operativo

Una teoría de interfaz no se vuelve útil solo porque esté bien formulada. Se vuelve útil cuando puede entrar en el trabajo diario de un equipo. Cuando ayuda a nombrar eventos. Cuando permite documentar decisiones. Cuando ordena tokens. Cuando mejora revisiones de diseño. Cuando evita discusiones vagas.

PREGUNTA DEL CAPÍTULO

¿Cómo puede una teoría así entrar en un sistema de diseño sin convertirse en un framework rígido?

1. La gramática no es un framework

Este libro no propone que todos los equipos adopten los mismos nombres internos, los mismos tokens ni la misma arquitectura. La gramática cumple otra función: obliga a distinguir funciones que la implementación no debería mezclar.

Un equipo puede llamar a algo danger. Otro puede llamarlo destructive. Otro puede usar critical. Lo importante no es el nombre exacto. Lo importante es que el sistema distinga: risk ≠ threat ≠ loss, affirm ≠ fulfill, emerge ≠ shift, contact ≠ commit.

PRINCIPIO

La gramática no obliga a una implementación concreta. Obliga a no confundir funciones perceptivas distintas.

2. Por qué llevar la gramática al sistema

Si la gramática se queda solo en el libro, sirve para pensar. Pero si entra en el sistema, también sirve para coordinar. En muchos equipos, las decisiones sobre interfaz se reparten: diseño visual define color, frontend implementa estado, UX define copy, accesibilidad revisa foco, producto define prioridad, motion se añade al final, sonido ni se considera.

La gramática permite alinear esas decisiones alrededor de un evento. Por ejemplo, signal.warn + risk implica: copy que explica un problema corregible, color que refuerza advertencia sin amenaza, forma que localiza el problema, motion contenido, accesibilidad que persiste y vincula al campo.

Figura 35.1

3. Tres niveles de adopción

3.1. NIVEL CONCEPTUAL

El equipo usa la gramática como lenguaje de revisión. Preguntas típicas: ¿esto es contact o commit? ¿esto es risk o threat? ¿esta desaparición es hide o loss? No requiere cambiar código ni tokens. Solo requiere cambiar cómo se conversa.

3.2. NIVEL DOCUMENTAL

El sistema de diseño documenta eventos semánticos. Cada evento tiene pregunta perceptiva, canales recomendados, errores comunes, accesibilidad y ejemplos. Aquí la gramática se vuelve documentación.

3.3. NIVEL OPERATIVO

La gramática entra en tokens, componentes, eventos declarativos o herramientas. Este nivel es más potente pero también más peligroso. Si se implementa sin criterio, puede convertirse en rigidez.

4. Naming: nombrar eventos, no efectos

Muchos sistemas nombran por apariencia (red-alert, green-success, slide-in, shake-error) o por componente (ButtonDanger, SuccessToast, ErrorModal). Ese naming mezcla planos.

Una gramática semántica intenta nombrar por evento: contact.press, commit.save + affirm, signal.warn + risk, commit.delete + loss.

NAMING HABITUAL	PROBLEMA	NAMING SEMÁNTICO
redAlert	color como significado	signal.alert + threat
successToast	componente + color	commit.save + affirm
dangerButton	intent en componente	commit.delete + loss
loadingSpinner	canal como evento	sustain.progress
shakeError	efecto como semántica	signal.warn + risk
modalDanger	contenedor como amenaza	shift.enter-mode + signal.warn + threat

5. Tokens semánticos

Los tokens suelen organizarse por propiedades: color.red.500, duration.200, shadow.lg. Eso es necesario pero no suficiente. Una gramática semántica no sustituye esos tokens. Los organiza en un nivel superior. Pero hay que pensar en firmas perceptivas, no en tokens de intent que parezcan tokens de color.

Figura 35.2

6. Firma perceptiva

Una firma perceptiva es el conjunto de decisiones de canal asociadas a un evento. Por ejemplo, commit.save + affirm: tiempo breve, motion asentamiento mínimo, forma marca persistente, color positivo discreto, sonido no por defecto. La firma perceptiva evita que cada canal se decida por separado.

7. Fichas de evento semántico

Una documentación de sistema podría incluir fichas como esta:

Ficha: commit.delete + loss. Pregunta: ¿qué dejó de estar disponible? Canales dominantes: presencia, forma, texto. Canales de apoyo: color, motion, sonido opcional. Firma perceptiva: retirada del objeto, mensaje de consecuencia, huella o registro, undo si existe. Accesibilidad: no depender solo de desaparición visual, anunciar pérdida si procede, mantener undo el tiempo suficiente. No usar: alarma sostenida de threat, solo color rojo, fade out sin huella. Antipatrones cercanos: todo es danger, pérdida sin huella, threat después de loss.

Ficha: signal.warn + risk. Pregunta: ¿qué requiere revisión? Canales dominantes: forma, texto, presencia. Firma: callout local, mensaje claro, persistencia hasta corrección, color moderado. Accesibilidad: mensaje vinculado al campo, no depender solo de color, no desaparecer automáticamente. No usar: alarma de threat, modal si no cambia el marco, shake agresivo.

Ficha: commit.complete + fulfill. Pregunta: ¿qué objetivo quedó cumplido? Canales dominantes: motion, presencia, forma. Firma: cierre resolutivo, marca de completado, color positivo visible, sonido breve opcional. No usar: success genérico para todo, celebración excesiva, desaparición sin estado final.

Figura 35.3

8. Documentar decisiones, no solo componentes

Un design system suele documentar componentes: Button, Modal, Toast, Tooltip, Spinner. Pero un botón puede participar en contact.press, commit.delete + loss, signal.warn + threat, shift.navigate. Un modal puede participar en shift.enter-mode, signal.alert + threat, commit.cancel + neutral. La documentación debería incluir una capa de eventos, no solo de componentes.

9. Tokens de canal y tokens de evento

Tokens de canal definen propiedades perceptivas básicas: color.red.600, motion.duration.short. Tokens de evento agrupan decisiones por semántica: event.signal.warn.risk podría mapear a color intent.risk.color, shape callout.warning, duration persistent.untilResolved. El token de evento no reemplaza los tokens de canal. Los coordina.

10. Cuidado: tokens no son verdad

Si el sistema convierte la gramática en tokens demasiado rígidos, puede matar la adaptación contextual. Un signal.warn + risk en un campo de formulario no es igual que en una operación financiera. La gramática orienta. No sustituye al juicio.

DISTINCIÓN

Un token semántico no debe congelar la experiencia. Debe impedir que se confundan funciones distintas.

11. Cómo usarlo en revisión de diseño

En lugar de decir "el modal se siente raro" podemos preguntar: ¿es realmente shift o solo emerge? ¿el intent vive en el mensaje o en el contenedor? ¿el commit deja huella? ¿el signal persiste lo suficiente? ¿la semántica sobrevive sin motion?

PREGUNTA	DETECTA
¿Qué evento ocurre?	ambigüedad de familia
¿Hay intent?	evaluación ausente o excesiva
¿Dónde vive el intent?	contenedor coloreado
¿Qué canal domina?	sobrecarga o fragilidad
¿Qué queda como huella?	commit débil
¿Qué pasa sin color?	dependencia cromática
¿Qué pasa con reduced motion?	pérdida de causalidad
¿El evento es frecuente?	fatiga sensorial
¿Hay cierre?	sustain infinito

Figura 35.4

12. De la gramática al sistema sin dogmatismo

El peligro de toda gramática es convertirse en policía. Este libro no propone eso. La pregunta no es "¿hemos aplicado la taxonomía de forma perfecta?" sino "¿hemos evitado confundir eventos perceptivamente distintos?"

13. Síntesis

Convertir la teoría en sistema no significa construir un framework universal. Significa introducir una capa de lenguaje donde antes solo había componentes, estilos y efectos.

NIVEL	USO
Conceptual	conversaciones y revisión
Documental	guías, fichas, ejemplos
Operativo	tokens, eventos, componentes

DISTINCIÓN

La gramática no obliga a una implementación concreta. Obliga a distinguir funciones que la implementación no debería mezclar.

PRINCIPIO

Nombra eventos antes de nombrar efectos.


================================================================================
CAPÍTULO 36 — capitulo36_con_diagramas.docx
================================================================================
CAPÍTULO 36

Cierre

Hacia una interfaz con gramática perceptiva propia

Este libro empezó con una incomodidad. No con una certeza.

La incomodidad de trabajar durante años construyendo interfaces y sentir que muchas decisiones importantes quedaban repartidas en capas separadas: componentes, estados, estilos, animaciones, sonidos, accesibilidad, validaciones, loaders, modales, notificaciones, tokens, eventos técnicos.

El usuario no percibe "un componente." No percibe "un token." No percibe "un transition-duration." Percibe otra cosa: algo respondió, algo empezó, algo sigue ocurriendo, algo se guardó, algo reclama atención, algo puede perderse, algo ya se perdió, algo apareció, algo cambió de marco, algo quedó completado.

La pregunta inicial era sencilla, pero difícil de formular:

PREGUNTA DEL CAPÍTULO

¿Por qué no tenemos un lenguaje más claro para hablar de lo que ocurre cuando una interfaz responde?

1. Lo que este libro ha intentado hacer

Este libro no ha intentado fundar una teoría definitiva de la interfaz. Ha intentado algo más concreto: nombrar la capa de eventos perceptivos que ya existe entre el sistema y el usuario.

Para nombrarla, el libro ha propuesto una gramática: evento interactivo → familia semántica → verbo/fase → evaluación → intent → canales perceptivos → lectura unificada.

2. La interfaz como contexto operacional perceptible

La primera decisión fue dejar de entender la interfaz solo como superficie. Una interfaz es la dimensión perceptible de un contexto operacional. El componente sigue importando, pero deja de ser la unidad central del significado. Lo que importa no es solo qué objeto hay en la interfaz. Importa qué evento hace perceptible.

3. El evento como unidad mínima de significado

La segunda decisión fue tomar el evento interactivo como unidad mínima. No el evento técnico del navegador. No el callback. No el estado interno. Sino el cambio perceptible que modifica la relación del usuario con el sistema.

4. Las familias semánticas

Para ordenar esos eventos, el libro propuso siete familias como siete preguntas perceptivas recurrentes:

FAMILIA	PREGUNTA
contact	¿el sistema ha sentido mi acción?
commit	¿algo quedó fijado o tuvo consecuencia?
signal	¿algo reclama mi atención?
handle	¿estoy manipulando directamente un objeto?
emerge	¿algo entró o salió del campo perceptivo?
shift	¿cambió el marco operativo?
sustain	¿esto sigue ocurriendo?

5. El intent más allá del color

Después vino la pregunta evaluativa. Durante años hemos tratado success, warning, danger e info como si fueran una taxonomía suficiente. Pero gran parte de esa estructura procede de una herencia cromática. El libro propuso separar el intent del color. Un intent es una región evaluativa del evento: neutral, affirm, fulfill, risk, threat, loss. Un autoguardado no es una culminación. Un riesgo corregible no es una amenaza activa. Una amenaza no es una pérdida consumada. El color puede reforzar todo eso. Pero no debe definirlo.

6. Los canales como materia sensible

Un evento no existe en abstracto. Debe materializarse por canales: tiempo, motion, presencia, profundidad, forma, color, sonido, háptica. Pero ningún canal debería cargar solo con todo el significado. Una semántica robusta puede migrar. La accesibilidad no es posterior a la semántica. Es la prueba.

7. Composición, matrices y validación

La última parte intentó convertir la teoría en herramienta. Composiciones, matrices, rangos, fichas de migración, antipatrones y protocolos de validación. No como burocracia, sino como formas de hacer una pregunta simple: ¿la interfaz comunica el evento que cree comunicar?

8. Lo que este libro viene a completar

Este libro no nace contra la teoría de interfaces existente. No intenta corregir desde fuera todo lo que el diseño de interacción, la usabilidad, la accesibilidad, la arquitectura de información, los sistemas de diseño, la ergonomía, la psicología de la percepción o la investigación HCI ya han construido.

Existen teorías, métodos y guías muy desarrolladas para pensar la interfaz: cómo organizar información, cómo diseñar flujos, cómo construir componentes, cómo hacer sistemas consistentes, cómo asegurar accesibilidad, cómo evaluar usabilidad, cómo jerarquizar contenido, cómo trabajar con affordances, cómo diseñar navegación, cómo reducir carga cognitiva.

Este libro no pretende sustituir nada de eso. Su intención es más limitada y más concreta.

Durante años de trabajo en front-end, algunas preguntas seguían apareciendo sin encontrar un lenguaje suficientemente preciso: ¿qué diferencia hay entre que el sistema reciba una acción y que confirme un resultado? ¿por qué una espera necesita sentirse viva? ¿cuándo una aparición es solo presencia y cuándo se convierte en señal? ¿por qué una amenaza no debería expresarse igual que una pérdida? ¿por qué el color ha cargado con demasiada semántica? ¿cómo migra el significado si el usuario reduce motion, no oye sonido o no distingue color?

Estas preguntas no niegan la teoría existente. Nacen en una zona que muchas veces queda entre varias disciplinas: entre componente y experiencia, entre estado técnico y percepción, entre efecto visual y significado, entre accesibilidad y semántica, entre motion y evento, entre color e intent.

Este libro intenta trabajar precisamente ahí. No redefine la interfaz desde cero. Propone una capa complementaria: una gramática perceptiva del evento interactivo.

DISTINCIÓN

Este libro no viene a reemplazar la teoría de interfaces. Viene a completarla desde la pregunta por el significado perceptivo del evento.

9. Lo que sí propone

Propone que la interfaz tiene una capa semántica que merece ser nombrada. Propone que entre el sistema técnico y la experiencia del usuario hay eventos perceptivos que pueden organizarse. Propone que el intent no debería vivir en el color, sino en la evaluación del evento. Propone que los canales deben coordinarse alrededor de una lectura única. Propone que la accesibilidad es una prueba de si el significado estaba bien distribuido. Y propone que el trabajo de interfaz necesita un lenguaje más preciso para hablar de lo que ocurre.

10. Volver al programador front-end

Al final, este libro vuelve al lugar del que salió. A un programador front-end enfrentado a decisiones aparentemente pequeñas: ¿este botón solo responde o confirma? ¿este loader tranquiliza o parece bloqueo? ¿esta alerta es riesgo o amenaza? ¿esta eliminación avisa o ya registra pérdida? ¿este modal es marco o mensaje? ¿qué cree el usuario que acaba de ocurrir?

Ninguna de esas preguntas es menor. Este libro ha intentado ofrecer un vocabulario para pensarlas con más claridad. No para eliminar la intuición. Sino para darle estructura.

11. Una teoría provisional

Toda gramática de interfaz debe ser provisional. Las plataformas cambiarán. Los dispositivos cambiarán. La IA modificará muchas interacciones. La háptica será más rica. Las interfaces espaciales traerán otros problemas. La accesibilidad seguirá ampliando el campo.

Por eso esta teoría no debe cerrarse sobre sí misma. Quizá algunas familias cambien. Quizá aparezcan nuevas. Quizá algunos intents se dividan. Quizá otros equipos encuentren mejores nombres. Eso no debilita el proyecto. Lo mantiene vivo.

Una gramática no existe para impedir que el lenguaje evolucione. Existe para hacer posible una conversación más precisa.

12. Cierre

Si este libro tiene algún valor, no está en haber resuelto definitivamente la interfaz. Está en haber intentado formular con claridad una pregunta que aparece una y otra vez en la práctica:

PRINCIPIO

¿Cuándo un cambio en la interfaz deja de ser efecto y se convierte en significado?

Las teorías existentes nos ayudan a pensar muchas cosas: estructura, usabilidad, accesibilidad, affordances, atención, percepción, diseño visual, navegación, consistencia, componentes y sistemas. Este libro ha intentado añadir una pieza más a esa conversación: el evento interactivo como unidad semántica perceptible.

Este libro empezó con fragmentación. Componentes por un lado. Estados por otro. Motion por otro. Color por otro. Sonido por otro. Accesibilidad por otro.

Y termina con una propuesta de unión: evento, familia, intent, canales, accesibilidad, validación. No como sistema cerrado. Sino como lenguaje compartido.

PRINCIPIO

La interfaz no solo debe funcionar. Debe hacer perceptible lo que ocurre.

PRINCIPIO

Este libro no intenta cerrar la teoría de la interfaz. Intenta ofrecer un lenguaje para una capa que ya estaba operando sin nombre.