Cuando la computación deja de ser un lugar al que se va y se vuelve un aire que se respira.

Hay una pregunta que conviene hacerse antes de empezar este curso, y conviene hacérsela en voz baja, casi como quien se confiesa algo incómodo: ¿cuándo fue la última vez que ustedes interactuaron con una computadora? Si la respuesta fue "esta mañana, cuando abrí el laptop", están pensando en computación con la mente del siglo veinte. Si la respuesta honesta es "no sé, quizás hace cinco segundos, cuando mi reloj me vibró, o hace treinta, cuando el termostato del Uber ajustó la temperatura, o hace una hora, cuando el portón del edificio me reconoció", entonces ya están viviendo en el territorio de esta cápsula. La computación dejó de habitar el escritorio. Se mudó al ambiente. Y nosotros, sin darnos del todo cuenta, nos mudamos con ella.

Esta primera cápsula es la puerta de entrada al curso. No vamos a programar nada todavía, no vamos a diseñar prototipos, no vamos a evaluar usabilidad. Vamos a hacer algo más fundamental: vamos a ponerle nombre a lo que estamos rodeados, vamos a trazar el linaje histórico que nos trajo hasta acá, y vamos a entender por qué un investigador llamado Mark Weiser, a fines de los 80 en Xerox PARC, propuso una visión que sigue siendo —treinta y cinco años después— el norte teórico de buena parte de lo que hoy llamamos Sistemas Interactivos Ubicuos. Conviene empezar por el contraste: la Fig. 1.1 enfrenta los dos modelos que están en juego, y vale la pena tenerla a la vista durante todo el capítulo, porque casi todo lo que sigue es una consecuencia de pasar de su columna izquierda a la derecha.

¿Qué es —y qué no es— un sistema interactivo ubicuo?

Empecemos por la definición y, sobre todo, por sus bordes. Un sistema interactivo ubicuo es, en términos amplios, un sistema informático que cumple cuatro condiciones simultáneamente:

1. Trasciende el ordenador de sobremesa. No se limita al monitor-teclado-mouse encerrados en una oficina. La computación se reparte en dispositivos personales, objetos cotidianos, sensores ambientales, redes de muchos nodos pequeños en lugar de uno grande.
2. Se integra en el tejido de las actividades y los entornos. Vive en el hogar, en el transporte, en la calle, en el trabajo, en el cuerpo. No es algo a lo que uno "va": es algo que ya está cuando uno llega.
3. Permite interacciones más naturales. Voz, gesto, tacto, presencia, contexto, mirada, ritmo cardíaco, posición en el espacio. La interfaz se reparte en modalidades que se alinean con las capacidades humanas, en lugar de obligar al humano a doblarse hacia el teclado.
4. Tiende a la invisibilidad. Y este es el punto que más cuesta entender al principio, porque es contraintuitivo: el ideal de un sistema ubicuo no es exhibirse, sino desaparecer. Que el usuario piense en su tarea —cocinar, dormir, conducir, conversar, estudiar— y no en la herramienta computacional que está mediando esa tarea.

Qué no es

Conviene también demarcar lo que no es UbiComp, porque la palabra "ubicuo" se ha popularizado tanto que a veces se le pega a cualquier cosa con un chip adentro. Un televisor "smart" que requiere abrir un menú con un control remoto para cada acción no es particularmente ubicuo: es una PC con pantalla grande. Una app de fitness que demanda atención constante para registrar manualmente cada paso tampoco lo es: no se ha vuelto invisible. Un sistema domótico que sirve para impresionar visitas pero exige tres minutos de configuración para encender una luz —ese ejemplo es clásico— está en las antípodas del ideal. Lo ubicuo no se mide por la cantidad de tecnología presente, sino por la retracción de la tecnología desde el foco de atención.

Más adelante en el curso (en la cápsula sobre Calm Technology aplicada y en la de evaluación) volveremos sobre esto con métricas más rigurosas. Por ahora basta con la intuición: si una tecnología les exige atención que la tarea misma no exigiría, todavía no es ubicua.

Tres olas: cómo llegamos hasta acá

Mark Weiser, en uno de los pasajes más citados de su artículo de 1991 The Computer for the 21st Century, propuso leer la historia de la computación como una sucesión de tres grandes olas, cada una definida por la proporción entre personas y máquinas.

Primera ola — el mainframe (años 40 a 80)

Una máquina enorme, una sala entera dedicada a contenerla, aire acondicionado industrial, un sacerdocio de operadores en bata blanca. Muchas personas comparten una sola computadora. La interacción no era interactiva en el sentido moderno: era diferida —tarjetas perforadas, lotes, terminales de texto— y reservada a especialistas. La computadora era un recurso escaso, centralizado, casi mítico. Los usuarios no la veían: veían a la persona que la veía.

Segunda ola — la computadora personal (años 80 a 2000s)

Llega la PC. La interfaz gráfica WIMP (Windows, Icons, Menus, Pointer) cambia las reglas: la computación se vuelve directa, visual, accesible. La proporción se invierte: una persona, una computadora. Cada profesional tiene su máquina en el escritorio, cada hogar de clase media termina con un PC en el comedor. La computación se descentraliza y se masifica, pero sigue siendo un lugar: hay que ir a sentarse delante de ella. La metáfora del escritorio —archivos, carpetas, papelera— no es casual: el computador es un escritorio más, otro mueble.

Tercera ola — la computación ubicua (2000s al presente)

Tres fuerzas confluyen: miniaturización (chips más chicos, baratos, eficientes), conectividad inalámbrica (Wi-Fi, Bluetooth, LTE, redes mesh) y proliferación de sensores (acelerómetros, GPS, micrófonos, cámaras, biométricos) baratos como cualquier commodity. La proporción se vuelve a invertir: muchas computadoras sirven a cada persona. Un smartphone es ya una decena de computadoras (CPU, GPU, NPU, radios, controladores); a su alrededor orbitan smartwatches, auriculares, parlantes, sensores del auto, lectores de huella del portón, cámaras del campus, semáforos coordinados de la avenida. La computación se vuelve invisible no porque se esconda, sino porque se distribuye. Está por todos lados, y precisamente por eso deja de ser un lugar al que ir.

Weiser describió esa tercera ola antes de que existiera: la imaginó en Xerox PARC mientras la segunda ola apenas se consolidaba. Esa anticipación es parte de por qué su nombre sigue apareciendo en los syllabi de magíster treinta y cinco años después.

El paradigma UbiComp de Mark Weiser

Cuando Weiser acuñó el término ubiquitous computing a fines de los 80, su intuición no era simplemente cuantitativa —más computadoras, en más lugares— sino fenomenológica: cambiar la relación entre la persona y la máquina al punto de que la máquina se borre del centro de la conciencia.

En su artículo The Computer for the 21st Century (1991), abre con una frase que vale la pena memorizar:

"The most profound technologies are those that disappear. They weave themselves into the fabric of everyday life until they are indistinguishable from it."

Las tecnologías más profundas son las que desaparecen. Se tejen en la trama de la vida cotidiana hasta volverse indistinguibles de ella. Weiser ponía como ejemplo el motor eléctrico: a comienzos del siglo veinte, un motor eléctrico era una pieza visible, ruidosa, exhibida en cada electrodoméstico nuevo como sello de modernidad. Hoy hay docenas de motores eléctricos en cualquier cocina —en el refrigerador, en el microondas, en el extractor, en el lavavajillas— y no pensamos en ellos. No los nombramos. No los "usamos": están. La meta de Weiser era que la computación llegara al mismo estado de transparencia.

Weiser no se quedó en el ensayo: construyó hardware para probarlo. La Fig. 1.2 muestra las tres escalas de dispositivo con las que el equipo de Xerox PARC llevó la idea a una sala real, y lo interesante es que la progresión Tab → Pad → Board no es una escalera de potencia sino de rol social: cada tamaño sirve a un tipo distinto de acto cotidiano —marcar, anotar, discutir en grupo— igual que un post-it, un cuaderno y una pizarra no compiten entre sí.

Calm Technology — la tecnología serena

En 1996, junto a John Seely Brown, Weiser publica Designing Calm Technology, un texto breve pero filoso que aterriza la visión ubicua en un criterio de diseño: la tecnología debe operar en la periferia de la atención, no en el centro. La idea proviene de la psicología cognitiva: los humanos tenemos un foco atencional estrecho —podemos seguir una conversación, leer un párrafo, escribir un mail— pero también una atención periférica enorme, casi inconsciente, que registra el clima del aula, la postura de la persona al lado, el zumbido del refrigerador, la luz que cambia al atardecer. Una calm technology aprovecha esa periferia: informa sin interrumpir, está disponible sin demandar, y vuelve al foco solo cuando hace falta.

El ejemplo canónico de Weiser es la lámpara que cambia sutilmente de color según la cotización de un índice bursátil: uno no la mira, pero la nota; está al borde del campo visual, y cuando algo cambia bruscamente, el ojo se mueve solo. Compárese con una notificación push que vibra, suena y aparece en el centro de la pantalla: esa notificación es lo opuesto de calm. Es ruido en el foco.

Si cruzamos las dos dimensiones que están en juego en ese contraste —cuánto se retrae la tecnología del foco atencional y cuánto entiende de la situación en que se usa— obtenemos el mapa de la Fig. 1.3. Vale la pena discutir las posiciones antes de aceptarlas: el asistente de voz adapta muchísimo al contexto y sin embargo se hace notar todo el tiempo, así que cae lejos del ideal; el PC clásico no hace ninguna de las dos cosas. De los cuatro cuadrantes, solo uno es el que Weiser perseguía.

Los principios fundamentales

Si destilamos la visión de Weiser y la tradición posterior, el paradigma UbiComp se sostiene sobre cinco principios entrelazados:

• Invisibilidad. La tecnología se integra de forma transparente en el entorno y los objetos. El usuario interactúa con la tarea, no con la máquina.
• Context-awareness (conciencia del contexto). El sistema percibe ubicación, identidad del usuario, hora, actividad, estado físico y social, y reacciona a eso. Es la diferencia entre un timer fijo y un termostato que aprende cuándo uno llega a la casa.
• Inteligencia. No solo reaccionar, sino aprender, adaptarse, anticipar. La línea con la Ambient Intelligence —entornos digitales sensibles, responsivos, adaptativos, ubicuos e inteligentes— es porosa.
• Naturalidad en la interacción. Voz, gesto, tacto, mirada, proximidad. La máquina se dobla hacia las capacidades humanas, en lugar de exigir que el humano se doble hacia ella.
• Escalabilidad. El paradigma funciona desde lo más íntimo (un sensor en la muñeca) hasta lo más amplio (un edificio inteligente, una ciudad sensorizada).

Notarán que estos principios no son independientes: la invisibilidad sin contexto degenera en automatismo ciego; el contexto sin naturalidad de interacción produce sistemas que perciben mucho pero responden mal; la inteligencia sin escalabilidad funciona en el laboratorio y muere en la calle.

Voces que dialogan con Weiser

La visión ubicua no nace en el vacío ni se queda quieta. Conviene mencionar algunos interlocutores que aparecerán a lo largo del curso.

Donald Norman, padre del diseño centrado en el usuario, publica en 1998 The Invisible Computer, donde argumenta que el éxito de una tecnología se mide por su capacidad de volverse appliance: un artefacto especializado, simple, dedicado a una tarea concreta. Norman llega a la invisibilidad por otra puerta —la del diseño industrial y la usabilidad— pero converge con Weiser en la idea de que la PC general-purpose, abierta, configurable hasta el infinito, es un modelo agotado. Lo veremos en detalle en la cápsula sobre usabilidad y los Golfos de Ejecución y Evaluación.

Hiroshi Ishii, en el MIT Media Lab, propone en 1997 (junto a Brygg Ullmer) las Tangible Bits: interfaces que dan cuerpo físico a la información digital. Su famosa frase —"bridge the gap between cyberspace and the physical environment"— es una rama paralela del árbol ubicuo. Donde Weiser quería desaparecer la computación, Ishii quería encarnarla. Las dos rutas no son contradictorias: ambas atacan la tiranía del rectángulo iluminado en la cara. Volveremos sobre tangibles en la cápsula 04, sobre paradigmas de interacción.

Yvonne Rogers, una de las voces más influyentes del HCI contemporáneo, critica con respeto la visión de Weiser. Su objeción es elegante: la invisibilidad total infantiliza al usuario, lo deja sin agencia, lo convierte en pasajero de un sistema que decide por él. Rogers propone una alternativa que llama engaging UbiComp: tecnología que en lugar de retraerse, provoca nuevas formas de pensamiento, juego, creatividad, colaboración. Ambas escuelas seguirán dialogando hasta el final del curso: la una privilegia la calma, la otra el compromiso. No hay que elegir bando todavía.

Visión, futuro, tensiones

Treinta y cinco años después del paper de Weiser, parte de su visión se cumplió y parte se torció. Vale la pena mirar ambas caras antes de cerrar.

Lo que se cumplió

El Internet de las Cosas, hoy, conecta miles de millones de dispositivos: termostatos que aprenden, sensores industriales, cámaras públicas, parquímetros, contadores de luz, pulseras de actividad, balanzas que reportan al ginecólogo. La Inteligencia Ambiental inspira casas que se adaptan a la presencia, oficinas que ajustan iluminación según la ocupación, hospitales que monitorean signos vitales sin cables. Los smartphones operan como hubs personales —un centro de control que viaja con nosotros— y han convertido cada bolsillo en un nodo de la red ubicua. La realidad aumentada empieza a despegar, las gafas inteligentes vuelven a intentarlo, los asistentes de voz se instalan en cocinas y autos. El futuro de Weiser —al menos en infraestructura— está acá.

Lo que se torció

Pero la realización es ambigua. Muchos sistemas que se autodenominan "ubicuos" hoy fallan exactamente en lo que Weiser pedía: son ruidosos (notificaciones, vibraciones, parpadeos), opacos (uno no sabe qué dato envían, a quién, para qué), demandantes (configurar tres apps para que el termostato hable con el reloj). La calma se perdió en algún lado del camino. Buena parte de este curso será un intento de recuperarla.

Las tensiones abiertas son cinco, y vamos a volver sobre cada una en alguna cápsula posterior:

• Privacidad y seguridad. La recolección masiva de datos contextuales —dónde estoy, con quién, qué dije, qué compré, cuánto dormí— plantea preguntas que la ingeniería sola no responde. La cápsula 09 (Ética y seguridad) le dedicará un espacio entero.
• Complejidad y gestión. Un ecosistema de cincuenta dispositivos en una casa típica es difícil de mantener. La tecnología ubicua no debería sentirse como administrar una pequeña empresa.
• Interoperabilidad. Dispositivos de distintos fabricantes a menudo no se hablan. El sueño de Weiser presuponía estándares; la realidad nos da silos.
• Diseño de interacción. Crear interfaces verdaderamente calmas para esta complejidad sigue siendo difícil. Es el problema central de este curso.
• Brecha digital. Los beneficios de la ubicuidad no llegan a todos. La accesibilidad —que veremos en la cápsula 03, sobre diseño centrado y universal— es parte del problema, pero no la única.

Diseñar sistemas interactivos ubicuos hoy es, entonces, una práctica multidisciplinaria —informática, diseño, psicología cognitiva, ergonomía, ciencias sociales, ética— y un acto político: cada decisión técnica configura el grado de libertad, atención y privacidad que la gente tendrá en los próximos años. No es poca cosa.

Aprendizaje activo

Cerramos esta cápsula introductoria con una invitación a observar. La Actividad 1 del curso, Radar de Ubicuidad, les va a pedir trabajar en grupo —tres integrantes por equipo— para identificar tres dispositivos o sistemas cotidianos que ustedes consideren ejemplos de computación ubicua y posicionarlos en un radar de dos ejes: invisibilidad (cuánto la tecnología se retrae del foco atencional) en el eje horizontal, adaptación (cuánto el sistema percibe y responde al contexto) en el eje vertical. El ejercicio toma alrededor de 35 minutos: cinco para repasar §1.1 y §1.3 de esta cápsula, diez para elegir los ejemplos, diez para construir el radar dentro de Google Drawings, y diez para justificar en una tabla por qué cada dispositivo cae donde lo pusieron.

No les voy a adelantar respuestas porque la gracia del ejercicio es discutirlas en grupo —los desacuerdos que surgen al posicionar un smartphone, un AirPod, un detector de humo o un Apple Watch revelan más sobre los criterios de UbiComp que cualquier definición de manual. Lleguen con tres dispositivos en mente, eso sí, así no se les va el tiempo en la búsqueda. Y vengan dispuestos a defender su posición: los cuadrantes del radar son menos importantes que la justificación que sostiene cada decisión.

Diseñar lo que no se ve: cuando la interfaz se disuelve, la usabilidad se vuelve atmósfera.

De la pantalla al ambiente

Hubo una época —no tan lejana, en realidad— en que diseñar una interfaz quería decir diseñar una pantalla. Botones, menús, ventanas, cursores. La usabilidad era un asunto de píxeles bien puestos: que el botón "Aceptar" estuviera donde uno lo espera, que el ícono comunicara su función, que el flujo no tuviera trampas. La HCI clásica —Human-Computer Interaction— se construyó sobre la convicción de que un buen diseño era, sobre todo, un buen diseño visual de una superficie rectangular y luminosa.

Esa convicción sigue siendo cierta cuando hay pantalla. Pero la computación ubicua, como vimos en la cápsula anterior, propone otra cosa: que la tecnología se vuelva ambiente, que la interfaz se disuelva en el espacio. Y entonces aparece una pregunta fértil: ¿qué pasa con la usabilidad cuando no hay pantalla que diseñar?

Esta cápsula intenta responder. No con una teoría nueva —no hace falta inventar tanto— sino releyendo los principios clásicos de la HCI a la luz del entorno inteligente. Vamos a tomar las herramientas conocidas (las heurísticas de Nielsen, los golfos de Norman, la noción de feedback) y torcerlas un poco para que sigan siendo útiles cuando el sistema vive en el aire, en los objetos, en los gestos, en las luces del techo.

Usabilidad y UX: definiciones que envejecen bien

Antes de torcer nada, vale la pena fijar las definiciones clásicas. La Usabilidad, según la tradición HCI, es la facilidad con que las personas pueden usar una interfaz para alcanzar sus objetivos. Es un atributo de calidad medible. Jakob Nielsen, en Usability Engineering (1994), la descompone en cinco métricas concretas:

• Facilidad de aprendizaje: qué tan rápido aprende un usuario nuevo a hacer las tareas básicas.
• Eficiencia: qué tan rápido las hace cuando ya es experto.
• Memorabilidad: si las recuerda después de un tiempo sin usar el sistema.
• Errores: cuántos comete, qué tan graves son, y qué tan fácil es recuperarse.
• Satisfacción: cuán placentero es el uso.

La Experiencia de Usuario (UX) es un concepto más ancho. La usabilidad es una de sus piezas, pero la UX incluye también lo subjetivo y emocional: cómo se siente el usuario antes, durante y después de interactuar. Confianza, valor percibido, estética, sentido. Rogers, Sharp y Preece, en Interaction Design: Beyond Human-Computer Interaction (5ª ed., 2019), insisten en que la UX no se reduce al cumplimiento de objetivos: incluye el ánimo con el que se llega y con el que se sale.

Hasta acá, terreno conocido. La pregunta es qué le pasa a estos conceptos cuando los soltamos en un living lleno de sensores, parlantes que escuchan, lámparas que entienden, relojes que vibran.

Hacia la Tecnología Serena

La respuesta corta es que se transforman. La usabilidad deja de ser la facilidad de uso de una app y pasa a ser la fluidez de un ecosistema completo: un parlante inteligente, un termostato, un timbre con cámara, un reloj, una rutina automática que enciende luces a cierta hora. Eficiencia ya no significa "que el usuario haga las cosas rápido", sino que el sistema haga cosas por el usuario sin que tenga que pedirlo. La facilidad de aprendizaje, en el límite, tiende a cero: la interacción ideal es implícita, no se aprende, simplemente ocurre. Y la gestión de errores se vuelve crítica de otra manera, porque un error ya no es una ventana mal cerrada: es una puerta que no se desbloquea cuando uno llega cargado de bolsas, o un riego que se gatilla en pleno aguacero.

La UX, por su lado, deja de ser experiencia de uso de un producto y se vuelve experiencia de habitar un entorno. El objetivo no es solo que el momento puntual sea placentero: es que el ambiente entero —la suma de objetos invisibles trabajando coordinados— se sienta acogedor, tranquilo, confiable. Mark Weiser y John Seely Brown (1996) le pusieron nombre: Calm Technology, tecnología serena.

Tecnología que asiste sin interrumpir, que potencia sin oprimir, que está disponible sin imponerse. — la idea de Calm Technology (Weiser & Brown, 1996)

Diseñar para la serenidad es harto más difícil que diseñar para la atención. Captar atención lo hacen los pop-ups y los íconos rojos parpadeantes. Soltar atención, devolvérsela al usuario, es una disciplina mucho más sutil. De eso, en el fondo, va el resto de esta cápsula.

Las 10 heurísticas de Nielsen, releídas en ambiente

En 1994, Jakob Nielsen publicó en Usability Engineering una de las listas más citadas de la HCI: las diez heurísticas de usabilidad. No son leyes, son principios guía —reglas de pulgar que un equipo experimentado puede usar para auditar una interfaz sin estudio con usuarios. Su poder está en su economía: con diez ítems uno ilumina la mayoría de los problemas de una pantalla.

Pero las diez heurísticas nacieron para interfaces gráficas. Lo interesante es que no se vuelven obsoletas en UbiComp: se vuelven más exigentes. Cada una sobrevive el viaje al entorno inteligente, pero reinventa sus formas. La Fig. 2.1 resume esa traducción heurística por heurística; conviene leerla antes de entrar al detalle, porque deja ver el patrón común: lo que cambia no es el principio, es el canal por el que se cumple.

1. Visibilidad del estado del sistema

Clásica: el sistema informa al usuario, en todo momento, qué está pasando (barras de progreso, mensajes de confirmación, indicadores).

En UbiComp: el desafío es mostrar el estado sin pantalla. El feedback se vuelve ambiental y multimodal. Un anillo de luz en un parlante que pulsa cuando está escuchando. Una vibración corta en el reloj que confirma un pago. Un tono breve cuando un comando se procesó. El estado existe, pero se distribuye en el ambiente.

2. Relación entre el sistema y el mundo real

Clásica: el sistema habla el idioma del usuario, usando conceptos familiares (la papelera para eliminar, el escritorio para organizar).

En UbiComp: este principio deja de ser una metáfora y se vuelve literal. El sistema no imita el mundo real: se integra en él. La interacción se basa en acciones físicas (girar, tocar, mover), en lenguaje natural (pedir, conversar) y en contexto ambiental (hora, presencia, temperatura).

3. Control y libertad del usuario

Clásica: el usuario debe poder deshacer, cancelar, salir.

En UbiComp: el problema se complica. ¿Cómo se "deshace" una acción automática que el sistema tomó por su cuenta? Hace falta un escape ubicuo: un interruptor físico que prevalezca sobre los sensores, un "detente" claro por voz, una manera obvia de decirle al ambiente muchas gracias, ahora paro yo. La automatización sin freno es opresión.

4. Consistencia y estándares

Clásica: elementos similares se ven y se comportan igual a lo largo de la interfaz.

En UbiComp: la consistencia se exige a través de todo un ecosistema. Un comando de voz tiene que funcionar igual en la cocina y en el auto. La app del celular y la pantalla del refrigerador tienen que compartir lógica. Cuando el ecosistema lo construyen tres fabricantes distintos, esto se vuelve una pesadilla —y un problema de diseño abierto.

5. Prevención de errores

Clásica: mejor un diseño que no permite errores que un excelente mensaje de error.

En UbiComp: la prevención se vuelve proactiva y contextual. El sistema usa sus sensores para evitar acciones inapropiadas. No riega si acaba de llover. No sube la temperatura si hay una ventana abierta. No activa el modo "fuera de casa" si detecta movimiento adentro.

6. Reconocimiento antes que recuerdo

Clásica: hacer visibles las opciones para no obligar al usuario a memorizarlas.

En UbiComp: sin menús, el reconocimiento se basa en affordances físicas y ambientales. Un objeto que se ilumina al acercarse sugiere que es interactivo. Un dial físico que rota propone que se gira. El propio entorno debe sugerir qué es posible hacer.

7. Flexibilidad y eficiencia de uso

Clásica: atajos para expertos, simplicidad para principiantes.

En UbiComp: la eficiencia experta se traduce en rutinas y automatizaciones personalizadas. Un comando "Buenos días" que enciende luces, prende la cafetera y sube las persianas. El sistema aprende del usuario y le ofrece atajos compuestos.

8. Diseño estético y minimalista

Clásica: las interfaces no deben contener información irrelevante.

En UbiComp: el minimalismo se desplaza del look al comportamiento. Es lo que podríamos llamar minimalismo de la interrupción: la estética no está en cuánta belleza tiene la pantalla, sino en con qué elegancia el sistema opera en segundo plano sin molestar.

9. Ayudar a reconocer, diagnosticar y recuperar de errores

Clásica: mensajes de error claros, precisos, con una solución.

En UbiComp: los mensajes ya no pueden ser pop-ups. Deben comunicarse de forma contextual: una voz que dice "no te entendí, ¿puedes repetir?", una notificación específica en el celular cuando algo sale mal, una luz que cambia de color.

10. Ayuda y documentación

Clásica: si es necesario, ofrecer ayuda fácil de consultar.

En UbiComp: la documentación se transforma en onboarding y descubrimiento progresivo. El sistema enseña sugiriendo, no explicando. Propone automatizar una acción que el usuario hace tres veces seguidas. El manual se vuelve invisible: vive en las sugerencias del sistema.

Metáforas que se vuelven mundo

Hay una herramienta más, antiquísima en HCI, que conviene revisar aquí: las metáforas. La HCI clásica las usó masivamente para tender puentes entre lo digital y lo conocido. El "escritorio", las "carpetas", el "carrito de compras", la "papelera". Cada metáfora aprovecha la familiaridad del mundo físico para reducir la curva de aprendizaje de algo nuevo.

En UbiComp, las metáforas no se eliminan: se invierten. Ya no se trata de meter el mundo dentro de la pantalla, sino de que el propio mundo se vuelva interfaz. Agitar la mano para cerrar una llamada. Girar un dial físico para regular un termostato digital. Pasar la mano por encima de una lámpara para encenderla. La familiaridad ya no viene de íconos sino de gestos y acciones naturales que ya sabemos hacer en el mundo físico desde antes de que existiera computación de ninguna clase.

Esto conecta con un modelo mental profundo. Cada usuario llega a un sistema con una representación mental de cómo cree que funciona. Cuando esa representación coincide con cómo realmente funciona, el sistema "se entiende". Cuando no coinciden, aparecen los famosos golfos.

Los golfos de Norman, amplificados

Donald Norman, en User Centered System Design (1986) y de manera definitiva en The Design of Everyday Things (1988, reeditado en 2013 con un nuevo prefacio), describió dos brechas que dificultan toda interacción:

• Golfo de Ejecución: la distancia entre lo que el usuario quiere hacer y cómo saber qué acción realizar para conseguirlo. No sé cómo hacer lo que quiero hacer.
• Golfo de Evaluación: la distancia entre la acción ejecutada y la posibilidad de saber si funcionó y cuál es ahora el estado del sistema. Hice algo, pero no sé qué pasó.

La Fig. 2.2 sitúa los dos golfos donde realmente ocurren: uno se abre entre la intención y la acción, el otro entre el estado interno del sistema y lo que el usuario alcanza a percibir. Nótese que el sistema aparece en el diagrama como una caja cerrada — es esa opacidad la que hay que perforar con feedback.

En la HCI clásica, un golfo de ejecución se da cuando el usuario no sabe qué botón apretar. Un golfo de evaluación, cuando aprieta el botón y no aparece ningún feedback que confirme la acción. Norman pasó décadas argumentando que la mayoría de las frustraciones cotidianas con la tecnología no son culpa del usuario sino consecuencia de diseños que dejan abiertos estos dos golfos.

En UbiComp, ambos golfos se amplifican. Conviene entender por qué, porque ahí está buena parte de la dificultad de diseñar bien para el ambiente.

El golfo de ejecución se amplifica porque las affordances desaparecen. En una pantalla, un botón al menos parece un botón. En el aire, ¿cómo le pido al sistema que suba un grado el termostato? ¿Por voz? ¿Con una app? ¿Hay un gesto? ¿Hay que tocar la pared? La incertidumbre sobre cómo actuar es el golfo, y el ambiente sin pantalla casi no da pistas.

El golfo de evaluación se amplifica porque el feedback es más difícil de comunicar. El usuario dijo "sube un grado", pero ¿cómo sabe si el sistema la recibió, la procesó, la ejecutó? Si la temperatura va a tardar diez minutos en subir, ¿cómo sabe ahora mismo que algo está pasando? La ausencia de pantalla obliga a inventar otras formas de devolver una señal clara y oportuna.

Cerrar estos dos golfos es, literalmente, el trabajo del diseñador ubicuo.

Feedback multimodal: el puente sobre el golfo

Y acá es donde entra el feedback. El feedback es, dicho simple, lo que el sistema le devuelve al usuario para confirmar que algo está pasando. En la HCI clásica, el feedback es predominantemente visual: un texto que aparece, una animación de botón presionado, un campo que se resalta, una barra que se llena.

En UbiComp, el feedback debe ser multimodal: tiene que usar varios canales sensoriales, de manera apropiada y no invasiva. La Fig. 2.3 muestra un mismo evento confirmado por cuatro canales a la vez, y añade uno que suele olvidarse —el espacial: cuál de los muchos dispositivos del ambiente es el que está respondiendo—. Los tres primeros son los centrales:

• Feedback visual ambiental: cambios sutiles en luces del entorno. La habitación que se tiñe de un color tenue cuando alguien llama por interno. La lámpara del living que pulsa suavemente cuando el sistema está escuchando. Es información visual, pero distribuida en el ambiente, no concentrada en una pantalla.

• Feedback háptico: vibraciones discretas en dispositivos vestibles. El reloj que vibra una vez para confirmar un pago. El brazalete que pulsa cuando es momento de moverse. Información dirigida al usuario que la lleva puesta, sin molestar a nadie más en el espacio.

• Feedback auditivo: tonos breves e informativos. Un chime cuando el comando se procesó. Un sonido distinto cuando hay error. Una respuesta de voz cuando el sistema necesita confirmar algo. El audio tiene la ventaja de no requerir mirada: funciona aunque el usuario esté ocupado en otra cosa.

Un buen feedback ubicuo es contextual y sereno: aparece cuando hace falta, en el canal que menos interrumpe, con la intensidad mínima necesaria. Si el usuario está hablando por teléfono, el sistema no chilla un anuncio: vibra el reloj. Si la casa está en penumbras, el sistema no enciende una luz brillante: hace un cambio ínfimo en la luz que ya está. Si hay varias personas, el sistema sabe que el aviso es para una sola y no lo grita en el living.

Los wearables son aliados naturales del feedback ubicuo: el reloj inteligente, los anteojos con audio óseo, los anillos con háptica son canales privados dentro de un ambiente público. Esa privacidad permite que la información llegue sin interrumpir al resto.

La ecología del silencio

Hay una última idea que vale la pena instalar antes de cerrar. Diseñar feedback en UbiComp no es solo decidir qué se comunica: es decidir qué no se comunica. Cada notificación es una interrupción potencial. Si todos los dispositivos del ambiente emiten señales todo el tiempo, el resultado no es información: es ruido.

La Tecnología Serena de Weiser y Brown se construye sobre una ecología del silencio: la mayor parte del tiempo, el sistema no dice nada. Trabaja sin pedir atención. Solo cuando hace falta —un error, una confirmación necesaria, un evento importante— el sistema se manifiesta, y lo hace por el canal mínimo, con la intensidad mínima.

Diseñar para el silencio es, paradójicamente, una de las cosas más activas que puede hacer un diseñador. Implica decidir todo el tiempo qué señales suprimir, qué agrupar, qué postergar. Y exige empatía atenta: el sistema bien diseñado conoce el contexto del usuario y respeta sus prioridades. Sabe cuándo callarse.

Aprendizaje activo

En la próxima sesión vamos a poner estos principios a trabajar en la Actividad 2 — Urgencias Heurísticas. En grupo, eligen un sistema ubicuo real (un parlante inteligente, un termostato, un auto conectado, un electrodoméstico —no una app móvil ni una web) y hacen una auditoría heurística propia. Van a imaginar o actuar —bodystorming— una interacción problemática e identificar al menos tres violaciones a las heurísticas de Nielsen adaptadas al entorno inteligente.

Para cada violación van a producir un boceto del problema: un dibujo simple que muestre al usuario, al dispositivo y la acción fallida, con la heurística violada explícitamente anotada. Y van a explicar qué golfo se abre —el de ejecución, el de evaluación, o los dos— y por qué la ausencia de pantalla amplifica el problema.

Después viene la parte fértil: el rediseño. Por cada problema, un boceto de la versión sana de la interacción. La consigna explícita es justificar qué tipo de feedback multimodal —visual ambiental, háptico, auditivo, o combinaciones— usaron para cerrar el golfo y devolverle al sistema su carácter sereno. La actividad cierra con una exposición relámpago: un minuto por grupo, su violación más crítica y su rediseño.

No damos las soluciones acá. La gracia de la auditoría es que cada grupo descubra los golfos específicos del sistema que eligió. Lleven los ojos atentos al living y al auto: las violaciones heurísticas están en todas partes, y verlas es ya media solución.

Diseñar para humanos reales —los que tropiezan, olvidan, cargan bolsas y entran a la oscuridad— y no para el usuario promedio, que es un fantasma estadístico que nadie ha visto jamás.

El usuario promedio no existe

Hay una tentación silenciosa cuando uno diseña: pensar en alguien parecido a uno mismo. Manos sanas, vista veinte-veinte, atención plena, contexto despejado, batería al 80%. Ese usuario imaginario es cómodo porque no se queja, no improvisa, no llega con las manos llenas. No existe.

Lo que existe son personas. Una madre que entra a su casa de noche con bolsas en ambas manos y un niño dormido al hombro. Un señor de setenta y dos años con artritis y la audición venida a menos. Una estudiante que cocina escuchando un podcast mientras revisa el celular con la otra mano. Un conductor que no puede mirar la pantalla porque está cambiando de pista. Cuatro cuerpos, cuatro relaciones con el mismo entorno —y un sistema ubicuo que, si fue diseñado pensando en el usuario promedio, va a fallar para todos ellos en grados distintos.

Las dos herramientas que vamos a recorrer —el ciclo de Diseño Centrado en el Usuario (DCU) y los siete principios del Diseño Universal— no son procedimientos burocráticos. Son hábitos mentales para mantener cuerpo y contexto presentes al decidir.

El ciclo DCU, esa rueda que no se detiene

El DCU no es una técnica. Es un compromiso de proceso: poner a las personas y a su contexto en el centro de cada fase del diseño, desde el primer boceto hasta la décima iteración. Rogers, Sharp y Preece (2019) lo formalizan como un ciclo iterativo de cuatro fases que se retroalimentan. No se atraviesa una vez; se atraviesa muchas, cada vuelta más informada que la anterior. La Fig. 3.1 despliega esas fases en círculo, y lo importante del dibujo es la flecha que lo cierra: evaluar no termina el proceso, lo reinicia con mejor información que la vuelta anterior.

Las cuatro fases

Comprender el contexto. No basta con saber qué tarea quiere hacer la persona. Hay que saber dónde la hace, con qué cuerpo, con qué interrupciones, con qué herramientas a la mano, con qué luz, con qué ruido de fondo, con quién más en la pieza. Para un sistema ubicuo, esta fase es desproporcionadamente importante porque el contexto deja de ser un marco y se convierte en parte del input del sistema. La proximidad GPS, la hora del día, las manos ocupadas, el estado emocional inferido: todo eso es contexto operativo.

Especificar requisitos. Una vez comprendido el contexto, traducirlo a requisitos concretos: qué tiene que hacer el sistema, qué tiene que evitar, qué umbrales de proactividad son aceptables, qué errores son tolerables y cuáles son catastróficos. En UbiComp esta fase incluye decisiones sobre cuándo el sistema debe iniciativa y cuándo debe esperar al usuario.

Diseñar soluciones. Generar alternativas. Múltiples. Resistir la primera idea. Bocetar entornos, no pantallas. Storyboards de interacción en el tiempo y el espacio físico. Lo veremos en detalle en §3.4.

Evaluar con usuarios reales en su contexto. No en un laboratorio aséptico, no con prototipos brillantes en una sala universitaria. En la cocina real, con las bolsas reales, con el niño real al hombro. O lo más cerca de eso que las restricciones del proyecto permitan.

Si hay que quedarse con una sola imagen del proceso, la Fig. 3.2 lo resume en cuatro operaciones: diseñar, implementar, evaluar, mejorar. Cuatro operaciones que en un proyecto real nunca ocurren una sola vez ni en orden perfecto — pero ninguna de las cuatro puede faltar.

Lo que cambia en UbiComp

Suchman (1987), en Plans and Situated Actions, mostró que la interacción humana con máquinas nunca sigue el plan que el diseñador imaginó. La gente improvisa, retrocede, abandona, retoma. En sistemas de escritorio podías ignorar parcialmente esa lección porque la interfaz era explícita y el usuario miraba la pantalla. En sistemas ubicuos no podés: la interfaz está dispersa en el entorno, la atención está dividida, y la acción se sitúa en un espacio físico cambiante.

Por eso el DCU, llevado al territorio ubicuo, no se centra en el usuario frente a una pantalla sino en la interacción simbiótica entre las personas y sus entornos computacionalmente enriquecidos. La comprensión del contexto deja de ser actividad estática para convertirse en pilar dinámico del diseño.

Generar alternativas: no enamorarse de la primera idea

Una fase del DCU merece párrafo aparte: la ideación. La razón es psicológica. Cuando uno encuentra una solución que funciona —aunque sea a medias—, el cerebro la marca como "resuelto" y deja de buscar. Esa fijación es enemiga del buen diseño, y en sistemas ubicuos es especialmente peligrosa porque el espacio de soluciones incluye dimensiones que muchos diseñadores no exploran instintivamente: voz, gestos, presencia, ambient feedback, automatización proactiva, objetos cotidianos aumentados.

Técnicas y su giro ubicuo

La lluvia de ideas clásica se traslada del nivel de "características de una app" al nivel de "comportamientos de un entorno". La pregunta deja de ser qué funciones tendría esta app y se convierte en cómo podría este espacio ayudar a estas personas. El bocetado ya no dibuja pantallas: dibuja mapas de pieza, flujos de movimiento, ubicaciones de sensores. Los storyboards narran una secuencia de interacción a lo largo del tiempo y del espacio físico, como una tira cómica donde el entorno es uno de los personajes.

Hay una técnica que vale destacar porque parece tonta y no lo es: el bodystorming. En lugar de imaginar el escenario, el equipo lo actúa. Se camina por el espacio simulando la interacción, con prototipos de papel o sin nada, encarnando físicamente al usuario y al sistema. Aparecen cosas que en el papel quedan invisibles: que la persona pasa por la puerta cargando algo y la mano izquierda queda libre solo dos segundos, que el sensor ubicado a 1.80 metros no detecta a quien va sentado, que el comando de voz se pierde por el ruido del extractor. El cuerpo recuerda lo que el plano olvida.

Escenarios y casos de uso: narrativas para entornos

Una vez generadas las ideas, hay que volverlas concretas. Los escenarios de uso son narrativas: historias detalladas que describen cómo una persona específica realiza una tarea en un contexto particular. Sirven para tres cosas a la vez —comprender el flujo, identificar problemas, comunicar el diseño al equipo y al cliente.

Del escenario clásico al escenario ubicuo

Un escenario clásico de HCI dice algo así: "Ana, una estudiante, llega tarde a clase. Saca su tablet, abre la app de notas, crea una nueva nota y comienza a escribir." La acción transcurre frente a una pantalla, con la atención del usuario plenamente entregada a la interfaz.

El escenario ubicuo es distinto porque el sistema deja de ser herramienta y se convierte en un actor más de la narrativa. "Ana, una residente, llega en su auto. El sistema, al detectar su proximidad por GPS, abre la puerta del garaje. Los sensores del auto informan que el maletero está lleno. Al entrar a la casa con bolsas en las manos, el sistema proactivamente enciende un camino de luces hasta la cocina. Ana dice 'Ok casa, pon mi lista de cocina', y el sistema responde por los altavoces de la cocina." Misma persona, otra historia. Aquí aparecen el contexto ambiental (GPS, manos ocupadas), la proactividad (luces antes de pedirlas) y la multimodalidad (voz, audio, luz).

Casos de uso: estructura sobre la narrativa

El caso de uso es la formalización de uno o varios escenarios: flujo principal, flujos alternativos, flujos de error. La diferencia con el caso de uso clásico es que en UbiComp el "actor" puede no ser humano. Puede ser un sensor de movimiento, un evento temporal ("a las 22:00"), una condición ambiental ("luminosidad < 50 lux"). Los disparadores contextuales son ciudadanos de primera clase.

Modelar esto obliga a tomar decisiones que de otra manera quedarían implícitas: ¿el sistema actúa solo cuando lo pides o también cuando él decide?, ¿qué condiciones disparan qué?, ¿qué hace si dos condiciones se contradicen? Sin un modelo formal, estas preguntas terminan respondidas por defecto, normalmente mal.

Diseño Universal: los siete principios de Ronald Mace

En 1985, el arquitecto y diseñador industrial Ronald Mace —él mismo usuario de silla de ruedas desde los nueve años, después de tener polio— acuñó la expresión Universal Design para nombrar una idea sencilla pero radical: en lugar de diseñar para "el usuario estándar" y luego adaptar para personas con discapacidad, diseñar desde el principio para la mayor cantidad posible de personas, sin necesidad de adaptación posterior. La diversidad humana no es la excepción: es la norma.

La Fig. 3.3 recoge los siete principios con su criterio operativo al lado. Al leerla conviene detenerse en el cuarto y el sexto —información perceptible y esfuerzo físico bajo—, porque son los que un sistema ubicuo incumple con más facilidad: si la única señal de estado es una luz diminuta en un rincón, el sistema ya está excluyendo a alguien antes de que nadie lo use.

Mace y un grupo de colaboradores formalizaron en 1997 los siete principios que se siguen usando hoy. Cada principio fue pensado para arquitectura y productos físicos, pero —y este es el punto interesante para nosotros— gana profundidad cuando se aplica a entornos ubicuos, porque un entorno proactivo y multimodal tiene más herramientas para encarnarlos que un producto pasivo.

Uso equitativo

El diseño es útil para personas con diversas capacidades, proveyendo los mismos medios de uso (o equivalentes) y evitando la segregación. El ejemplo clásico: puertas automáticas, que benefician a la persona con silla de ruedas y, de paso, a quien lleva las manos llenas. En UbiComp esto se traduce en ofrecer múltiples modos de interacción equivalentes. Un sistema de climatización puede controlarse por voz, por app, por panel físico y de forma automática. Ningún modo es "el modo accesible". Todos son legítimos.

Flexibilidad en el uso

El diseño se acomoda a un amplio rango de preferencias y habilidades. Los subtítulos son el ejemplo clásico: útiles para personas sordas y también para quien mira video en un café ruidoso. En UbiComp el sistema se adapta dinámicamente al contexto. Un auto inteligente prioriza la voz y deshabilita la entrada táctil cuando el vehículo está en movimiento, no porque "el conductor tenga discapacidad" sino porque el contexto lo exige.

Uso simple e intuitivo

El diseño es fácil de entender, independientemente de la experiencia o conocimiento del usuario. En UbiComp la versión radical es que la mejor interfaz es la invisible. Entrar a una pieza oscura y que la luz se encienda es la cumbre del uso intuitivo: no hay nada que aprender porque no hay nada que hacer. El sistema actúa, la persona habita.

Información perceptible

El diseño comunica eficazmente, independientemente de las capacidades sensoriales del usuario, usando redundancia. El semáforo con señal sonora es el ejemplo clásico. En UbiComp el principio se vuelve retroalimentación multimodal: un horno que terminó la cocción avisa con notificación visual al móvil, sonido en el ambiente, vibración en el reloj. Ninguna modalidad sola es suficiente —el celular puede estar silenciado, el ambiente ruidoso, el reloj fuera del brazo— pero las tres juntas son robustas.

Tolerancia al error

El diseño minimiza los peligros y las consecuencias adversas de acciones accidentales. La función "deshacer" es el ejemplo clásico de software. En UbiComp es uno de los principios más difíciles, porque muchas acciones del entorno no son deshacibles —si abriste la puerta principal por un falso positivo, ya la abriste. La salvaguarda exige overrides físicos, confirmaciones explícitas para acciones irreversibles y un interruptor de emergencia que desactive toda la automatización.

Bajo esfuerzo físico

El diseño puede usarse con mínima fatiga. Las manillas tipo palanca en vez de pomos redondos son el ejemplo de oficio. En UbiComp la automatización proactiva es la máxima expresión del principio: eliminar el esfuerzo físico en tareas rutinarias. La luz que se enciende al entrar, la climatización que se ajusta cuando llegás del trabajo, la lavadora que avisa cuando termina.

Tamaño y espacio para el acceso y uso

Se proporciona tamaño y espacio apropiados para el acercamiento, alcance y uso, independientemente del tamaño corporal o la movilidad. Pasillos anchos, baños accesibles. En UbiComp aterriza en algo que muchos diseñadores olvidan: los sensores y actuadores tienen que estar ubicados pensando en cuerpos diversos. Cámaras a la altura adecuada para detectar a quien va sentado en silla y a quien va parado de 1.90. Micrófonos que capturen voces a distintos volúmenes. La ergonomía espacial no es opcional.

Discapacidades: del modelo médico al modelo social

El Diseño Universal está intrínsecamente ligado a una consideración activa de las personas en situación de discapacidad. Pero hay una distinción conceptual previa que conviene hacer explícita: hay un modelo médico y un modelo social de la discapacidad, y el segundo es el que sustenta el diseño inclusivo.

El modelo médico entiende la discapacidad como un atributo individual: la persona "tiene" una discapacidad, que es un problema suyo. El modelo social la entiende como un desajuste entre el cuerpo de la persona y las barreras del entorno. Una persona en silla de ruedas no es "discapacitada" en abstracto: es alguien para quien una escalera es una barrera, una rampa no lo es.

La discapacidad no está en el cuerpo: está en la fricción entre el cuerpo y el mundo construido.

El diseño inclusivo consiste, entonces, en remover barreras, no en compensar déficits. Para localizar dónde está la barrera sirven los dos artefactos que compara la Fig. 3.4: la persona, que es estática y acompaña todo el proyecto, y el journey map, que es dinámico y cambia con el escenario. El segundo es el que revela los puntos críticos, porque pone en la misma línea de tiempo la acción, la respuesta del sistema y el dolor.

Tipos de limitación y cómo los entornos ubicuos los abordan

Auditiva. Pérdida total o parcial de la audición. Se aborda con redundancia visual y háptica: un timbre que además de sonar parpadea las luces y vibra el reloj. Subtítulos en cualquier salida sonora. Notificaciones que nunca dependan únicamente del canal auditivo.

Visual. Desde baja visión y daltonismo hasta ceguera total. Contraste adecuado en displays, texto ajustable, lectores de pantalla. En UbiComp los entornos pueden ser consultados por voz y el feedback puede ser háptico y sonoro direccional —sonidos espacializados que indican de dónde viene la información.

Mental (psíquica e intelectual). Trastornos de ansiedad, depresión, limitaciones intelectuales, condiciones del espectro autista. El diseño debe favorecer lenguaje simple, estructura consistente, predictibilidad. Un sistema que detecta señales de estrés y reduce proactivamente los estímulos —baja el volumen, atenúa las luces, posterga notificaciones no críticas— es una expresión directa de este principio.

Física (motriz / orgánica). Limitaciones de movilidad y/o función de partes del cuerpo. Aquí el potencial de UbiComp es enorme: control total del entorno por voz, por seguimiento ocular, por switches especializados. Encender luces, abrir puertas, ajustar temperatura, llamar ayuda —todo sin requerir movilidad fina. No es un detalle de comodidad: es un cambio en la relación de la persona con su propia vida.

Limitaciones permanentes, temporales y situacionales

Una de las ideas más útiles del diseño inclusivo —Microsoft la popularizó en su Inclusive Design Toolkit— es que las limitaciones no son solo permanentes. Son también temporales (un brazo enyesado, una afonía, una conmoción) y situacionales (manos ocupadas con bolsas, ojos puestos en la ruta, oídos invadidos por ruido ambiente). Una persona sin discapacidad permanente atraviesa decenas de limitaciones situacionales al día. Diseñar para limitaciones es diseñar para todos, en algún momento de su vida.

Esta es la justificación pragmática del Diseño Universal: no es caridad ni cumplimiento normativo. Es eficacia. Un entorno que funciona bien para alguien con baja visión funcionará mejor para todos en condiciones de poca luz. Un sistema que escucha bien a alguien con dificultades del habla escuchará mejor a todos cuando hay ruido. La accesibilidad sube el piso para todos los habitantes del entorno.

Marco normativo en Chile

Dos referencias prácticas. La Ley 21.015 de Inclusión Laboral (Chile, 2017) establece la obligación de empresas e instituciones de incorporar personas con discapacidad. Las Web Content Accessibility Guidelines (WCAG) del W3C son el estándar internacional para accesibilidad digital; sus principios (perceivable, operable, understandable, robust) se traducen sin dificultad al diseño de sistemas ubicuos.

En la computación ubicua, el diseño inclusivo no es opcional. La tecnología que se incrusta en el entorno o une a los habitantes del espacio o los divide; no hay tercera opción.

Aprendizaje activo

En la Actividad 3 — Sprint de Diseño Ubi-Empático, cada grupo elegirá un escenario ubicuo concreto (casa inteligente para una persona mayor, smart workplace, retail inteligente, campus conectado, auto conectado) y aplicará en 45 minutos el ciclo del DCU comprimido en cinco fases.

Primero crearán una Persona —no un usuario promedio, sino alguien con limitaciones claras, permanentes, temporales o situacionales. Después mapearán su Journey Map contextual: cinco pasos que ilustren no clics sino el cuerpo moviéndose por el entorno, identificando para cada paso qué hace, qué espera del sistema, qué recibe, y dónde está el punto de dolor. Con esos puntos armarán una matriz de impacto-esfuerzo que les obligue a priorizar. Y cerrarán con un MVP de máximo 140 caracteres —un Producto Mínimo Viable descrito con la disciplina de un tuit, explicando cómo la mejora aprovecha capacidades ubicuas (proactividad, multimodalidad, sensores) para subir el piso de accesibilidad.

La restricción de 140 caracteres no es estética: es pedagógica. Obliga a destilar la esencia de la solución, a defender una sola decisión arquitectónica clara.

Cuando la computación deja la caja, el mouse y el teclado dejan de ser el único contrato. La mano vuelve a tocar, el cuerpo vuelve a gesticular, el aire vuelve a importar.

El escritorio era una excepción, no una regla

Por más de cuarenta años, interactuar con un computador significó la misma escena: una silla, una pantalla rectangular, un teclado y un dispositivo de apuntamiento. El paradigma WIMP (Windows, Icons, Menus, Pointer), nacido en Xerox PARC y popularizado por Apple y Microsoft, fue tan dominante que muchos olvidaron que era una convención, no una ley natural. La metáfora del escritorio funcionó porque ordenó un problema concreto: cómo mostrar varias tareas a la vez en una sola pantalla, manipulables por una persona sentada frente a ella.

Pero la computación ubicua cambió las premisas. Ya no hay una pantalla; hay decenas, esparcidas por el edificio. Ya no hay una persona sentada; hay personas caminando, hablando, cocinando, manejando, durmiendo. Ya no hay una tarea bien definida; hay flujos de actividad que se entrelazan con el entorno físico. En ese mundo, el mouse y el teclado son herramientas estupendas para escribir un correo, pero ridículas para apagar la luz del living, controlar la música en la cocina o mover una pieza en una mesa de juego compartida.

Esta cápsula recorre los paradigmas de interacción que han emergido para llenar ese vacío. No son sustitutos del WIMP: son complementos que se activan cuando el contexto lo pide. Cada uno tiene su lógica, sus afordancias, sus límites. Conocerlos no es un ejercicio enciclopédico; es ampliar el repertorio de soluciones cuando uno se sienta a diseñar un sistema ubicuo.

Interacción tangible: cuando los datos se vuelven cosa

En 1997, en la conferencia CHI, Hiroshi Ishii y Brygg Ullmer del MIT Media Lab presentaron un trabajo que se volvió canónico: Tangible Bits: Towards Seamless Interfaces between People, Bits and Atoms. La tesis era simple y radical. Las interfaces gráficas (GUI) habían encerrado la información en píxeles detrás de un vidrio. ¿Y si en vez de manipular representaciones de los datos con un cursor, manipuláramos los datos directamente con las manos, dándoles forma física, peso, textura?

La Fig. 4.1 muestra el caso de manual del paradigma: una mesa donde los bloques que se toman y se giran son el instrumento, no su representación. Y la Fig. 4.2 desarma esa misma idea en las cuatro piezas que la sostienen —objeto físico, bit acoplado, affordance del material y acoplamiento continuo—; la cuarta es la que más se descuida al prototipar: el valor digital tiene que cambiar mientras el objeto se mueve, no cuando se suelta.

Así nació la Interacción Tangible y, con ella, el campo de las Tangible User Interfaces (TUIs). El Tangible Media Group del MIT, fundado por Ishii, lleva casi tres décadas explorando esta idea. Su lema lo resume mejor que cualquier definición: las TUIs buscan traer la computación al mundo real, en contraposición a la realidad virtual que nos saca del mundo real.

Principios fundacionales

El diseño tangible se apoya en cuatro dimensiones que no existen en el diseño visual puro:

Materialidad. La forma, el peso, la textura, la temperatura del objeto no son decoración: son parte del lenguaje. Un cubo de madera lijada comunica algo distinto a un cubo de plástico brillante, aunque encarnen el mismo dato.

Encarnación física de los datos (physical embodiment). El objeto físico es la información, no una etiqueta puesta encima. Su posición, orientación, estado físico corresponde uno-a-uno a un estado digital. Cambia uno, cambia el otro.

Interacción corporal. Las manos —y a veces el cuerpo entero— manipulan los objetos. Esto activa habilidades motoras que llevamos desarrollando desde la cuna: agarrar, rotar, apilar, encajar.

Embeddedness. La interacción ocurre en el mundo físico del usuario, en su mesa, en su pieza, en su taller, no aislada en un rectángulo de vidrio.

Ejemplos para fijar la idea

El reacTable del grupo de Sergi Jordà en Barcelona (2006) es el caso de estudio clásico: una mesa circular donde colocar bloques físicos —osciladores, filtros, secuenciadores— genera música electrónica en vivo. Mover un bloque cambia un parámetro; rotarlo cambia otro; ponerlos cerca los conecta. Funciona porque la mesa es a la vez partitura, sintetizador e instrumento.

Conviene verlo funcionando antes de seguir: en el Fig. 4.3 se aprecia que no hay ningún modo ni menú en toda la sesión — la posición relativa entre bloques es el ruteo de la señal, y por eso dos personas pueden tocar a la vez sin negociar turnos.

Los bloques de programación tangible para niños (desde los AlgoBlocks de los noventa hasta KIBO hoy) reemplazan las líneas de código por piezas físicas que se ensamblan: encajar dos bloques significa secuenciar; añadir un bloque verde significa repetir. El niño piensa con las manos.

Las maquetas urbanas interactivas —como el Urp del propio MIT— permiten a planificadores mover edificios de cartón sobre una mesa y ver en tiempo real cómo cambia la sombra que proyectan, el flujo del viento o la silueta nocturna. La maqueta deja de ser un objeto pasivo y se vuelve simulador.

La ventaja profunda de las TUIs es expresiva y colaborativa. Varias personas pueden manipular el mismo sistema al mismo tiempo —imposible con un mouse compartido— y cada quien retiene una sensación de control físico que la pantalla no entrega. Hornecker y Buur (2006), en su trabajo sobre el marco conceptual de la interacción tangible, insisten precisamente en esta dimensión social: tocar juntos es interactuar juntos.

Interacción sin contacto: cuando ni siquiera hace falta tocar

Si la interacción tangible insiste en poner las manos sobre el objeto, la Interacción Sin Contacto (Touchless) va al otro extremo: controlar un sistema sin tocarlo en absoluto. Sensores —cámaras, infrarrojos, profundidad, radar, micrófonos— detectan la presencia, la postura, el gesto o la mirada del usuario a distancia, y traducen eso en comandos.

La Fig. 4.4 deja ver de una sola vez la promesa y el problema del paradigma: la mano queda libre de toda superficie, pero sostener el brazo en el aire cansa en menos de un minuto. Y como touchless y gestual se usan a menudo como sinónimos sin serlo, la Fig. 4.5 los enfrenta rasgo por rasgo: el primero capta cualquier movimiento y se aprende solo; el segundo exige memorizar un vocabulario, y su límite es ergonómico antes que técnico.

El catalizador comercial del paradigma fue el Microsoft Kinect, lanzado en 2010 para la consola Xbox 360. Por primera vez una cámara de profundidad asequible llegaba al hogar, y de pronto cualquier sala de estar se convertía en un detector de cuerpos en tiempo real. El Kinect demostró que el cuerpo entero podía ser controlador, y aunque su éxito comercial fue mixto, abrió una década de investigación en HCI sobre interacciones gestuales mid-air.

Cuándo no tocar es una ventaja

Hay escenarios donde el touchless no es una novedad sino una necesidad:

Higiene. Un cirujano en pabellón no puede tocar una pantalla para girar una resonancia: rompería la esterilidad. Un quiosco interactivo en un aeropuerto durante una pandemia se vuelve foco de contagio si todos lo tocan. El touchless resuelve ambos problemas sin sacrificar control.

Distancia. Hay objetos —pantallas grandes en una sala de control, vitrinas de museo, paneles en altura— a los que físicamente uno no llega. La interacción sin contacto permite manipularlos desde donde uno está parado.

Accesibilidad. Para personas con discapacidad motriz que no pueden operar un mouse, sensores que detectan movimientos de cabeza, mirada o respiración abren accesos imposibles con dispositivos convencionales.

Técnicas que vale la pena conocer

Algunos trabajos recientes muestran la riqueza del campo:

MatchPoint y TraceMatch (Clarke, Bellino, Esteves & Gellersen, 2017) utilizan una simple webcam para sincronizar el movimiento corporal del usuario con widgets que orbitan en pantalla. El sistema no necesita reconocer el cuerpo: basta con detectar que algo se mueve en fase con el widget. Es elegante porque elimina la calibración explícita.

El Fig. 4.6 muestra por qué esto es más robusto de lo que parece: el sistema nunca identifica qué parte del cuerpo se mueve —la cabeza, una mano, un objeto que el usuario sostiene—, solo detecta que algo se mueve en fase con el widget. No hay calibración ni parte del cuerpo privilegiada.

Orbits (Esteves et al., 2015) y Pursuits (Vidal, Bulling & Gellersen, 2013) aplican la misma idea al eye-tracking: el usuario mira un objeto en movimiento, el sistema detecta la persecución suave de la mirada (smooth pursuit), selecciona. Funciona en smartwatches, displays públicos, vitrinas. No requiere calibración previa. Estos enfoques comparten una intuición valiosa: en vez de pedirle al sistema que reconozca qué hace el usuario (lo que es difícil), le piden que reconozca correlaciones temporales entre lo que el sistema muestra y lo que el usuario hace (lo que es fácil).

Interacción gestual: el cuerpo como vocabulario

Estrechamente ligada al touchless, pero también presente en superficies táctiles, la Interacción Basada en Gestos convierte movimientos del cuerpo —principalmente manos y dedos, a veces cabeza, brazos o cuerpo entero— en comandos discretos o continuos.

Conviene distinguir tres familias:

Gestos en el aire (mid-air). Detectados por cámaras o sensores de movimiento como Kinect o Leap Motion. Permiten controlar a distancia. Su gran limitación es la fatiga: sostener un brazo levantado durante minutos produce el famoso gorilla arm syndrome, ese cansancio que vuelve insoportable cualquier interacción mid-air prolongada.

Gestos táctiles (touch). Realizados sobre superficies sensibles al contacto. Son omnipresentes: deslizar, pellizcar para zoom, doble tap, mantener pulsado. La generación que creció con smartphones los tiene tan automatizados que pellizcar para hacer zoom se siente innato, aunque sea pura convención cultural.

Gestos con el dispositivo. Movimientos realizados sosteniendo un artefacto: inclinar el smartphone para girar la cámara, agitarlo para deshacer, voltearlo para silenciar. Aprovechan los acelerómetros y giroscopios que llevan los móviles.

Diseñar un vocabulario gestual

El verdadero desafío no es técnico sino lingüístico. Un buen conjunto de gestos debe ser intuitivo (mapeo natural acción-efecto), memorable (uno no debería tener que consultar un manual cada vez), eficiente (rápido de ejecutar), distinguible (el sistema no debe confundir uno con otro) y libre de fatiga.

Trabajos como CycloStar o The Fat Thumb (Boring et al., 2012) muestran cómo se puede enriquecer el vocabulario táctil aprovechando dimensiones que la gente normalmente no piensa: el tamaño del contacto del pulgar, por ejemplo, puede diferenciar entre paneo y zoom sin que el usuario cambie de modo explícitamente.

El Fig. 4.7 ilustra bien esa economía de gestos: un único movimiento oscilatorio continuo sirve para navegar y hacer zoom, porque la amplitud del círculo controla la velocidad y el sentido de giro invierte la dirección. El gesto no termina y vuelve a empezar — se modula, y así desaparece el cambio de modo. The Fat Thumb resuelve el mismo problema por otra vía —el tamaño del área de contacto como dimensión extra— y lo veremos en video en la cápsula 06.

Thumb + Pen Interaction on Tablets (Pfeuffer, Hinckley, Pahud & Buxton, 2017) explora cómo combinar el tacto del pulgar con un lápiz óptico, asignando roles distintos a cada uno: el pulgar configura el modo, el lápiz ejecuta la acción. Es interacción bimanual asimétrica que sigue rindiendo frutos en tablets profesionales.

Puntero y táctil reinventados

Aunque exploramos paradigmas "más allá del escritorio", el puntero y el tacto no desaparecieron: se adaptaron.

El puntero, originalmente un cursor controlado por mouse, en sistemas ubicuos puede ser la mirada (eye-tracking), un punto del cuerpo (la mano en MatchPoint), la punta de un objeto tangible o un dispositivo apuntador como un control de Wii. La esencia se mantiene: mapear un punto en el espacio físico o corporal a un punto en la interfaz digital.

El tacto, por su parte, se ha vuelto omnipresente gracias a la tecnología capacitiva proyectada que llevan todas las pantallas multitáctiles modernas. Pero la investigación sigue empujando. Electrick (Zhang, Laput & Harrison, 2017) es un ejemplo precioso: usando tomografía de campo eléctrico, convierte cualquier superficie conductora de forma arbitraria —un volante, una pared pintada con tinta especial, un juguete— en una interfaz táctil. La pantalla deja de ser rectangular y se vuelve cualquier cosa. Diseñar para tacto en pantallas grandes o pequeñas exige consideraciones específicas: tamaño del objetivo (la regla de Fitts vuelve a aparecer), espacio para errores (los dedos no son punteros precisos), ergonomía de los gestos prolongados (sostener un brazo para tocar un display vertical cansa).

Inteligencia ambiental: cuando el entorno entero responde

Llegamos al paradigma más ambicioso. La Inteligencia Ambiental (Ambient Intelligence, AmI) no es una técnica de interacción puntual: es una visión integradora, formulada en los años 2000 por Emile Aarts y Stefano Marzano en el libro The New Everyday: Views on Ambient Intelligence (2003), y desarrollada en compilaciones como la de Weber, Rabaey & Aarts (2005) y los trabajos posteriores de Augusto y McCullagh (2007).

La Fig. 4.8 resume las cuatro propiedades que definen a uno de estos entornos —embebido, contextual, personalizado y anticipatorio— situadas alrededor de una escena doméstica. La cuarta es la más frágil de las cuatro: un sistema que responde antes de que se lo pidan es cómodo cuando acierta e insoportable cuando se equivoca.

La idea: en vez de que el usuario interactúe con dispositivos discretos, el entorno entero —la casa, la oficina, el hospital, la ciudad— se vuelve sensible, adaptable y responsivo. La tecnología se disuelve en el espacio y aparece sólo cuando se la necesita.

Esta visión no es ajena a lo que ya vimos en la primera cápsula con Mark Weiser: la AmI es, en muchos sentidos, la materialización europea (con fuerte impulso de Philips y la UE) de la calm computing que Weiser imaginó en California. Mike Kuniavsky, en Smart Things (2010), la extendió al mundo de productos comerciales: objetos cotidianos que ganan sensibilidad sin perder su esencia de objeto.

Las seis características del entorno inteligente

Un entorno verdaderamente AmI debería exhibir:

Sensibilidad: percibir el contexto —identidad de las personas, ubicación, actividad, estado emocional— mediante sensores variados.

Responsividad: reaccionar a esa percepción de forma oportuna.

Adaptabilidad: ajustar su comportamiento según necesidades cambiantes. Aprender.

Transparencia: operar en segundo plano, sin demandar atención constante.

Ubicuidad: la inteligencia distribuida por todo el espacio, no concentrada en un dispositivo.

Inteligencia: capacidad de inferir intenciones, tomar decisiones, actuar autónomamente cuando corresponde, a menudo apoyándose en machine learning.

Escenarios canónicos

Hogar inteligente: luces que se ajustan a la hora y a la actividad, calefacción que aprende preferencias, sistemas de seguridad que distinguen a los habitantes de extraños, asistentes que recuerdan tareas en el momento oportuno (no a la hora que uno los programó, sino cuando el contexto lo indica).

Oficina inteligente: salas de reunión que reconfiguran iluminación y proyección al detectar quiénes entran, sistemas de booking que aprenden patrones, espacios que negocian recursos compartidos.

Salud inteligente: monitorización no invasiva de adultos mayores en su casa, detección temprana de caídas o cambios de patrón, entornos que asisten sin estigmatizar. Este es probablemente el campo donde la AmI tiene mayor potencial humanitario.

El precio de la ambición

La AmI lleva décadas de promesa y todavía no llega completamente. Los desafíos son enormes:

Sensing robusto: los sensores reales fallan, los entornos cambian, las personas no se comportan como en el laboratorio.

Inferencia contextual: deducir intención a partir de señales es uno de los problemas abiertos más difíciles de la IA aplicada.

Interoperabilidad: los ecosistemas comerciales (Apple, Google, Amazon, Samsung) siguen siendo islas que no se hablan bien.

Privacidad y control: un entorno que todo lo ve y todo lo decide es exactamente el escenario distópico que las personas temen, con razón. La AmI sin un marco ético sólido es vigilancia con buena estética. A estos temas le dedicamos una cápsula completa más adelante.

Comparando los paradigmas: cuándo elegir qué

La Fig. 4.9 sitúa los cuatro paradigmas del capítulo según cuánto esfuerzo cognitivo exigen y cuán visible es su interfaz. Lo interesante no son los extremos —la GUI muy visible y demandante, lo ambient casi invisible y silencioso— sino los intermedios: lo gestual baja la visibilidad pero sube el esfuerzo, porque obliga a recordar un vocabulario que no está a la vista en ninguna parte.

Ningún paradigma es universalmente mejor. La pregunta correcta no es ¿cuál uso? sino ¿qué quiero hacer, dónde, con quién? Algunas heurísticas:

Si la tarea es manipulación compleja de objetos con varias personas a la vez —diseño urbano, composición musical, educación infantil—, lo tangible suele ganar.

Si la tarea es control a distancia o en condiciones de higiene crítica —cirugía, displays públicos, accesibilidad motriz—, el touchless o el gestual mid-air son los candidatos.

Si la tarea es navegación rápida y precisa sobre una interfaz rica —edición de texto, hojas de cálculo, trabajo de oficina—, el puntero y el tacto siguen siendo reyes.

Si lo que se quiere es disolver la interfaz por completo y que el entorno actúe en segundo plano —hogar, salud, oficina—, la AmI es el horizonte, aunque exija integración de todos los anteriores.

Una buena pista del oficio: los sistemas ubicuos reales rara vez usan un solo paradigma. Combinan. Un smart home tiene táctil (interruptores), touchless (asistente de voz), gestual (algunos controles), tangible (objetos físicos que actúan como triggers) y ambient (luces que cambian con la hora). La pregunta del diseñador es qué paradigma asignar a cada función según contexto, urgencia, formalidad y carga cognitiva.

Aprendizaje activo

Esto cierra con manos sobre la mesa. En la Actividad 4 — Storyboard de Paradigmas, ustedes van a:

1. Elegir, en grupo, uno de los paradigmas estudiados (Tangible, Sin Contacto, Gestual o Ambient Intelligence).
2. Diseñar un caso de uso cotidiano —distinto al de su proyecto del semestre— donde ese paradigma resuelva un problema concreto mejor que un teclado y un mouse.
3. Producir un storyboard de 3 a 6 viñetas (dibujadas a mano y fotografiadas, o hechas en Google Drawings) que muestren la interacción paso a paso.
4. Bajo cada viñeta, argumentar las ventajas del paradigma elegido frente a la alternativa tradicional.

El ejercicio es deliberadamente breve (40 minutos) y deliberadamente visual: contar una interacción en imágenes obliga a hacerse cargo de detalles que la prosa esconde —dónde está parado el usuario, qué tiene a mano, qué ve, qué oye, qué siente—. Esas son las preguntas que importan al diseñar ubicomp.

El smartphone que llevamos en el bolsillo es una sonda ubicua: nueve sentidos artificiales escuchando el mundo, esperando que alguien los conecte.

Cuando Mark Weiser imaginó la computación ubicua a comienzos de los noventa, no estaba describiendo un solo computador más potente. Estaba describiendo una red de dispositivos heterogéneos —tabs, pads, boards, en su vocabulario original— repartidos por el espacio físico, capaces de percibir, comunicarse y actuar sin reclamar atención. Esa visión solo se materializa si el silicio puede salir de la caja y tocar el mundo. Esta cápsula trata de las tecnologías habilitadoras que lo hacen posible: los sensores que escuchan, las placas que piensan, los actuadores que responden, y la conectividad que cose todo en un tejido.

No hace falta ir muy lejos para tener esa red delante: la Fig. 5.1 inventaría un smartphone corriente separando lo que capta del mundo de lo que devuelve al mundo. Casi todos los prototipos de este curso se construyen con esa lista y nada más.

Como dice Krumm en la introducción a Ubiquitous Computing Fundamentals (2009), ubicomp no es una tecnología puntual sino "una sopa de tecnologías" —sensores, redes, procesadores embebidos, modelos de contexto— cuya integración produce el efecto. Lo que sigue es el mapa básico de esa sopa.

El ciclo de interacción físico

En el corazón de cualquier sistema ubicuo hay un bucle que se repite a miles de hertz, sin descanso: percibir → procesar → actuar. El sensor lee una magnitud física —luz, aceleración, presión, sonido— y la convierte en una señal eléctrica. La placa de desarrollo interpreta esa señal, la combina con otras lecturas, consulta un modelo de contexto y decide. El actuador convierte esa decisión de vuelta en mundo físico: una vibración, un LED, una cortina que baja, una voz sintética que avisa que llegó la micro.

La Fig. 5.2 traza ese bucle en sus cuatro pasos. Lo decisivo del dibujo es la flecha de retorno: al modificar el entorno, el actuador cambia lo que el sensor leerá en el ciclo siguiente. De ahí salen tanto las conductas útiles —la luz que se mantiene encendida mientras haya alguien— como los bucles indeseados que aparecerán al prototipar.

Cada eslabón tiene su propia gramática. Los sensores se clasifican primero según la naturaleza de la señal que entregan:

• Sensores analógicos: producen una señal continua proporcional a la magnitud medida. Un termistor, por ejemplo, varía su resistencia eléctrica de manera continua con la temperatura. Para que el microcontrolador lo entienda hay que digitalizar la lectura mediante un conversor analógico-digital (ADC).
• Sensores digitales: ya entregan un valor numérico discreto, muchas veces a través de un protocolo serial (I2C, SPI, UART). El sensor hace internamente el muestreo y la cuantización, y el procesador solo lee un número.

Los actuadores son la contraparte simétrica. Si los sensores permiten al sistema escuchar el mundo, los actuadores le permiten hablar y actuar sobre él. Y entre ambos vive el procesamiento: el cerebro embebido que cierra el lazo.

La idea de "ciclo" no es decorativa. Es lo que diferencia un sensor aislado —un termómetro que solo muestra un número— de un sistema interactivo —un termostato que regula la calefacción según el patrón de ocupación de la casa. El sistema interactivo cierra el bucle. El termómetro lo deja abierto.

Los sentidos del sistema

La variedad de sensores que un sistema ubicuo puede integrar es, hoy, vertiginosa. Conviene organizarlos en familias funcionales para no perderse.

La Fig. 5.3 los agrupa por el fenómeno que miden y no por la tecnología que usan, y ese orden importa a la hora de diseñar: primero se decide qué se quiere saber del mundo, y solo después con qué medirlo.

Movimiento y orientación

Los acelerómetros miden la aceleración lineal en uno o más ejes. Detectan la inclinación (porque la gravedad es una aceleración constante hacia abajo), la sacudida, el paso. Cuando le das vuelta el celular y la pantalla rota, es el acelerómetro hablándole al sistema operativo. Los giroscopios miden la velocidad angular, es decir, qué tan rápido rota el dispositivo. Los magnetómetros detectan campos magnéticos —la brújula digital, en esencia. La combinación de los tres en una sola unidad se llama IMU (Inertial Measurement Unit) y permite un seguimiento robusto de orientación y movimiento en 3D. Toda la realidad virtual y aumentada moderna depende de IMUs miniaturizadas.

Localización

El GPS triangula la posición con satélites: funciona muy bien al aire libre, pésimo dentro de un edificio. Para suplir esa carencia, el posicionamiento indoor combina señales de Wi-Fi, balizas Bluetooth (beacons) o incluso luz visible (VLC, Visible Light Communication) para estimar dónde estás dentro de una sala.

Ambiente

Sensores de luz, temperatura, humedad, presión barométrica (que sirve para estimar altitud), calidad del aire (detectores de CO₂, COVs, partículas). Son los sensores que sostienen la Ambient Intelligence: una pieza que regula su climatización porque sabe cuánta gente hay adentro y cuán cargado está el aire.

Sonido

El micrófono es uno de los sensores más densos: cada segundo de audio contiene una cantidad enorme de información. Sirve para reconocimiento de voz, pero también para detectar eventos acústicos —una puerta que se cierra, un grifo abierto, un grito— como en el trabajo Whoosh (Reyes et al., 2016), que convierte soplidos en input para smartwatches.

Biometría y fisiología

Huella dactilar, reconocimiento facial, iris. Más adentro: el sensor PPG (fotopletismografía) que mide pulso cardíaco con luz infrarroja en los smartwatches, y el EDA (actividad electrodérmica) que detecta cambios sutiles en la conductancia de la piel asociados a la excitación emocional —un sensor querido por la computación afectiva y la investigación de UX.

Esta acumulación de sensores sobre el cuerpo tiene un antecedente obvio, y conviene tenerlo presente: la Fig. 5.4 describe el mismo bucle en el ser humano —los sentidos captan, el cerebro decide, el cuerpo actúa— porque es la plantilla de la que toda esta ingeniería es una imitación parcial.

Proximidad y presencia

Los PIR (Passive Infrared) detectan el calor de cuerpos en movimiento: son los responsables de que se enciendan las luces del pasillo cuando uno aparece. Los ultrasónicos miden distancias por eco. Los capacitivos detectan la cercanía de un objeto conductor sin tocarlo: así funcionan los botones sin contacto de los baños públicos.

Sensado avanzado y exótico

Acá empiezan los sensores que ya no son commodity. EM-Sense (Laput et al., 2015) usa el ruido electromagnético que emiten los dispositivos eléctricos para identificarlos al contacto: tocas un mouse y el sistema sabe que es un mouse, tocas un taladro y sabe que es un taladro. Electrick (Zhang, Laput & Harrison, 2017) convierte cualquier superficie pintada con tinta conductora en un panel táctil usando tomografía de campo eléctrico. Synthetic Sensors (Laput, Zhang & Harrison, 2017) propone virtualizar lecturas físicas en información de alto nivel: en vez de instalar veinte sensores en una cocina, un solo nodo multisensor aprende a inferir "el microondas está funcionando" o "alguien abrió la puerta de la nevera".

La gracia no está en un sensor individual sino en la fusión de sensores: combinar varias lecturas para inferir contexto. Un acelerómetro solo te dice que hay movimiento. Acelerómetro + GPS + micrófono te dicen que vas en una micro del Transantiago.

La Fig. 5.5 cierra el paralelismo: la misma cadena de la figura anterior, ahora con sensores, procesador y actuadores en los tres lugares que antes ocupaban los sentidos, el cerebro y el cuerpo. Diseñar un sistema ubicuo es, en el fondo, decidir qué parte de ese bucle humano se delega a la máquina.

La voz y los músculos

Si los sensores son los sentidos, los actuadores son la salida del sistema. Suelen ser menos espectaculares en el catálogo pero igual de críticos: sin un actuador, el sistema percibe pero no responde, y el bucle queda abierto.

• Actuadores visuales: LEDs (indicadores, notificaciones, iluminación ambiental), displays (LCD, OLED, e-ink en lectores de libros y etiquetas de góndola), proyectores (que abren la posibilidad de proyectar interfaces sobre cualquier superficie física).
• Actuadores auditivos: zumbadores para tonos simples, parlantes para audio rico (voz, música, alarmas habladas).
• Actuadores de movimiento y hápticos: motores de vibración para el feedback en celulares y wearables, motores DC y servomotores para mover cortinas o brazos robóticos, solenoides para acciones de empujar-tirar como en una cerradura inteligente.
• Actuadores térmicos: celdas de Peltier para calentar o enfriar una superficie. Aparecen en interfaces avanzadas que quieren producir feedback térmico —imaginar un controlador de videojuego que se calienta cuando el personaje cruza una zona de fuego.

La elección del actuador es una decisión de diseño tan importante como la del sensor. Un sistema bien sensado pero mal actuado es como una persona con muy buen oído que solo sabe gritar.

El cerebro embebido: placas de desarrollo

Entre los sensores y los actuadores vive un microcontrolador, y entre el prototipo y el producto, una placa de desarrollo. Las dos plataformas dominantes en docencia y prototipado son:

• Arduino: hardware y software abierto, originalmente construido en torno al microcontrolador ATmega328P de Atmel —8 bits, 16 MHz, 32 KB de flash, 2 KB de RAM. Suena ridículo en la era de los terabytes, pero esos recursos sobran para leer sensores, controlar actuadores y empujar bytes por un puerto serial. Sirve para experimentar y para escribir el código que más tarde correrá en hardware más serio.
• Raspberry Pi: ya no es un microcontrolador sino un computador de placa única (SBC) corriendo Linux. Tiene GPIOs como Arduino pero además tiene CPU multinúcleo, RAM en gigabytes, Wi-Fi, conector HDMI. Es la opción cuando el procesamiento incluye visión por computador, web server o cualquier cosa que necesite un sistema operativo completo.
• ESP32 (Espressif): el caballo de batalla actual de IoT. Microcontrolador dual-core a 240 MHz con Wi-Fi y Bluetooth integrados, costos en torno a un par de dólares, y un ecosistema enorme. Cuando hoy se diseña un objeto conectado que tenga que mandar lecturas a la nube por Wi-Fi, lo más probable es que adentro lleve un ESP32.
• Plataformas históricas como Phidgets (Greenberg & Fitchett, 2001) y .NET Gadgeteer (Villar et al., 2012) introdujeron la idea de "widgets físicos": módulos enchufables que abstraen el cableado y permiten que un diseñador, no solo un ingeniero, arme prototipos.

La diferencia entre microcontrolador y SBC importa porque define qué se puede hacer en el borde y qué hay que delegar a la nube. Un ESP32 puede leer cinco sensores y publicar JSON cada segundo, pero no puede correr un modelo de visión por computador. Una Raspberry Pi puede correr el modelo, pero come más watts y es menos confiable como sistema embebido 24/7.

Cámaras y visión por computador

Las cámaras merecen un párrafo aparte porque son sensores densos: cada frame contiene una cantidad de información que excede por órdenes de magnitud lo que entrega cualquier otro sensor. La visión por computador —el campo de la IA dedicado a procesar y entender imágenes— habilita reconocimiento de gestos y poses, seguimiento corporal (Kinect, MatchPoint), reconocimiento facial, eye-tracking, reconocimiento de objetos, OCR (como en CameraKeyboard de Bellino & Herskovic, 2019), realidad aumentada, lectura de códigos QR, comprensión semántica del entorno (como en Zensors de Laput et al., 2015).

El Fig. 5.6 muestra hasta dónde llega esa densidad cuando se la combina con lenguaje natural: se escribe la pregunta —¿hay fila en el mostrador?, ¿queda papel?— y el sistema la responde con visión por computador, apoyándose en trabajo humano cuando el modelo no alcanza. El sensor deja de ser una pieza de hardware y pasa a ser una pregunta.

El costo de esa densidad es la privacidad. Una cámara captura cualquier cosa que pase delante de su lente, incluyendo rostros, pantallas, documentos. Diseñar con cámaras exige preguntarse, antes de capturar un solo frame, qué se va a hacer con él, dónde se procesa, cuánto vive almacenado, y qué se le comunica al usuario sobre todo eso.

El Internet de las Cosas

El término Internet of Things se le atribuye a Kevin Ashton (1999, popularizado en 2009): la idea de una red donde los objetos físicos, equipados con sensores, actuadores y conectividad, recopilan e intercambian datos —muchas veces máquina-a-máquina (M2M), sin intervención humana directa. Ashton lo planteó pensando en logística y RFID, pero el concepto se desbordó: hoy IoT es la infraestructura básica de los hogares inteligentes, las ciudades inteligentes, la industria 4.0, la agricultura de precisión, la salud conectada.

Para Weiser, IoT es el sustrato técnico que permite que su visión deje de ser laboratorio: una red de dispositivos heterogéneos, distribuidos, comunicándose entre sí sin pedirle al humano que abra una app para cada cosa. La promesa es seductora. Los riesgos —seguridad, interoperabilidad, gobernanza de datos, obsolescencia programada— son justamente lo que abordaremos en la cápsula 09 sobre ética y seguridad. Por ahora basta con instalar la idea: ningún dispositivo ubicuo opera solo. Pertenece a una red.

El sistema nervioso: conectividad inalámbrica

Para que la red exista, los dispositivos tienen que comunicarse. Las opciones inalámbricas más usadas en ubicomp ocupan un espacio de diseño con tres ejes: alcance, ancho de banda y consumo energético. No hay una tecnología que gane en los tres: cada una sacrifica algo.

La Fig. 5.7 enfrenta los dos extremos de ese espacio —BLE y LoRa— en los seis parámetros que deciden un proyecto. No hay un ganador: hay una pregunta previa que elige por ti, y es si el dato viaja dentro de una habitación o a través de un campo.

• Wi-Fi (IEEE 802.11): la red local de la casa o la oficina. Alcance de decenas de metros, ancho de banda alto (suficiente para streaming de video), consumo moderado-alto. Requiere infraestructura (un router) y seguridad (WPA2 o WPA3). Es la opción por defecto cuando el dispositivo tiene enchufe.
• Bluetooth Classic y Bluetooth Low Energy (BLE): red personal de corto alcance (~10 m). El BLE en particular fue diseñado para consumir poquísima energía: una pulsera puede transmitir lecturas cardíacas durante semanas con una pila de botón. BLE se usa también para beacons —pequeños emisores que anuncian su identidad y permiten posicionamiento indoor o experiencias contextuales (un museo que entrega información sobre la pieza que tienes enfrente).
• NFC (Near Field Communication): alcance extremadamente corto (menos de 4 cm), basado en RFID. Lo que parece una limitación es en realidad un feature: el alcance mínimo fuerza la intencionalidad —no pagas con NFC por accidente, tienes que acercar el celular al lector. Comunicación rápida de establecer, modos activo y pasivo, consumo bajísimo. Usos: pagos sin contacto, tap-to-pair, etiquetas inteligentes.
• Zigbee y Z-Wave: protocolos de malla pensados para domótica. Bajo consumo, ancho de banda modesto, pero capaces de formar redes en malla donde cada dispositivo retransmite los mensajes de los demás, ampliando la cobertura sin necesidad de un único router potente.
• LoRa y LoRaWAN: cuando se necesita alcance grande (kilómetros) y consumo muy bajo, sacrificando ancho de banda. Sensores agrícolas, monitoreo ambiental, smart cities. Una pequeña baliza LoRa puede mandar un par de bytes cada media hora durante años con una pila.
• 5G y conectividad celular: cuando el dispositivo vive lejos de toda red local. Cara, energéticamente exigente, pero la única opción para flotas de vehículos o sensores en zonas remotas.

En la práctica, un sistema ubicuo suele combinar varias: BLE para hablarle al smartphone del usuario, Wi-Fi para subir datos a la nube, NFC para el emparejamiento inicial. La pregunta de diseño no es "qué red elijo" sino "qué red para qué eslabón".

Aprendizaje activo

La Actividad 5 — Hackea tu Smartphone convierte esta cápsula en práctica. El smartphone que andas trayendo es, probablemente, el dispositivo ubicuo más sofisticado que vas a tocar en todo el semestre: un nodo con nueve o diez sensores integrados, tres o cuatro radios inalámbricas, un procesador capaz, y una pantalla. Vamos a hacerle ingeniería inversa.

Y antes de abrirlo conviene mirar la Fig. 5.8, que muestra cómo ese mismo teléfono puede emular controles físicos: un interruptor de dos estados, una perilla que gira entre un mínimo y un máximo, un deslizador con su recorrido. La elección entre los tres no es estética — cada metáfora anuncia qué tipo de valor se está manipulando antes de que el usuario lo toque.

En grupos, en 45 minutos, harán tres cosas:

1. Inventario sensorial. Instalen una app gratuita (tipo Sensor Box o equivalente) que les muestre los sensores disponibles. Identifiquen al menos cinco —acelerómetro, giroscopio, magnetómetro, sensor de luz ambiental, micrófono, GPS, barómetro, NFC, lo que aparezca— y armen una tabla con su función.
2. Diseñen un micro-servicio IoT. Elijan dos sensores y una tecnología de red (BLE, Wi-Fi o NFC) que su smartphone soporte. Propongan un micro-servicio que resuelva un problema cotidiano combinándolos. No tiene que ser implementable hoy: tiene que ser coherente —que cada sensor aporte algo distinto, que la red elegida sea la apropiada para el patrón de comunicación.
3. Dibujen el diagrama de flujo-evento. Eventos de entrada (los sensores), procesamiento en el dispositivo, comunicación por la red al servicio IoT, acción/feedback de salida. Formas estándar de diagrama de flujo: rectángulos para procesos, rombos para decisiones, óvalos para inicio/fin.

Cerrarán con un elevator pitch de 60 segundos. La parte difícil no es identificar sensores —ya saben qué hay adentro de un smartphone. La parte difícil es justificar la elección: por qué estos dos sensores y no otros, por qué esta red y no otra. Esa justificación es el verdadero entregable.

Hay sensores que escuchan lo que el oído no oye y campos eléctricos que dibujan dedos sobre paredes. La interfaz, cuando madura, deja de ser pantalla y se vuelve física diminuta.

Las cápsulas anteriores trazaron el mapa: paradigmas (tangible, gestual, ambient), sensores, IoT. Esta cápsula entra al laboratorio. Acá conviven técnicas que cualquier estudiante de magíster en sistemas interactivos debería poder reconocer, explicar y, sobre todo, descomponer — porque cada una de ellas es un pequeño organismo con un sentido (señal), un órgano (sensor), un cerebro (procesado e inferencia) y una voz (feedback).

El catálogo es heterogéneo a propósito. Algunas técnicas explotan fisiología humana (la mirada, el ritmo, el habla). Otras explotan fenómenos físicos sutiles que pasaban inadvertidos hasta hace una década (ruido electromagnético ambiental, distribución de campo eléctrico en superficies conductoras). Y todas comparten una misma promesa ubicua: ampliar el ancho de banda entre persona y ambiente sin obligar al usuario a aprender una nueva gramática de gestos en cada dispositivo.

6.1 La mirada como entrada

La mirada es uno de los canales más informativos del cuerpo humano: indica atención, intención y curiosidad antes de que la mano se mueva. El seguimiento ocular (eye tracking) mide a dónde se está mirando usando, en su forma más común, cámaras infrarrojas que detectan el reflejo corneal y la pupila. La entrada por mirada (gaze input) usa esa señal como método de control — históricamente como apoyo a usuarios con discapacidad motora severa, hoy como modalidad complementaria en entornos manos libres.

Tres problemas clásicos han perseguido a la entrada por mirada desde sus inicios. Calibración: cada ojo es distinto, los modelos pierden precisión con cambios de iluminación o si el usuario mueve la cabeza, y recalibrar molesta. Toque de Midas: si mirar es activar, ¿cómo distingue el sistema entre observar y querer? El método tradicional ha sido el dwell time — fijar la vista durante 800 ms o más sobre un objetivo — pero esto es lento y propenso a falsos positivos. Precisión: el ojo nunca está quieto. Aun fijando, lo recorren sacádicos y microsacádicos involuntarios, por lo que apuntar a objetivos pequeños es físicamente imposible.

Smooth pursuit: la solución que vino del laboratorio

A mediados de la década de 2010, un grupo en Lancaster University propuso un giro elegante: en lugar de pedirle al ojo que fije, pedirle que persiga. Los movimientos oculares de persecución suave (smooth pursuit) son los que ejecutamos espontáneamente al seguir un objeto que se desplaza con velocidad predecible. Tienen una propiedad notable: no podemos generarlos voluntariamente sin un estímulo en movimiento que los induzca. Si una cámara detecta que el ojo se mueve con una trayectoria, esa trayectoria existe afuera.

Pursuits (Vidal, Bulling y Gellersen, 2013) fue la primera técnica en explotar esto. Coloca objetivos animados en pantalla; cada uno se mueve siguiendo una trayectoria distinta. El sistema correlaciona los movimientos oculares del usuario con cada trayectoria conocida. Cuando la correlación de una de ellas supera un umbral, esa es la seleccionada. Sin calibración, sin dwell, sin entrenamiento previo: el usuario simplemente mira al objetivo que quiere y, sin darse cuenta, su ojo lo sigue.

Orbits (Esteves, Velloso, Bulling y Gellersen, 2015) llevó la idea a smartwatches. En una pantalla de menos de 4 cm de diagonal, los botones convencionales son demasiado pequeños y la calibración ocular impracticable. Orbits asocia a cada control una pequeña órbita: un punto que gira a su alrededor con una fase, velocidad o sentido distintos. El usuario sigue con la mirada la órbita del control que quiere activar. La técnica es manos libres, robusta a imprecisión, y funciona en pantallas diminutas — siempre que el diseñador escoja con cuidado el número de objetivos y la variación entre órbitas para evitar correlaciones espurias.

AmbiGaze (Velloso et al., 2016) cierra el ciclo llevando smooth pursuit fuera de la pantalla. Aquí los objetivos animados no están en un display: están en los propios dispositivos del entorno. Las aspas de un ventilador giran, un punto láser orbita una lámpara, un altavoz hace pulsar un LED. El usuario mira al dispositivo que quiere controlar, su ojo persigue la animación, y el sistema infiere la intención. Es eye tracking sin pantalla — la conclusión natural de combinar gaze input con el paradigma ambient.

La Fig. 7.1 desarma el mecanismo en cuatro pasos —trayectoria animada, mirada rastreada, correlación, selección— y lo notable es la lista de lo que no hace falta: ni calibración previa, ni tocar, ni sostener la mirada fija. El Fig. 7.2 lo demuestra en la calle, con transeúntes que nunca configuraron nada.

Y como leer sobre correlación de trayectorias no es lo mismo que sentirla, aquí hay un prototipo para probarla: sincroniza el movimiento de tu cuerpo con una de las órbitas y observa cuánto tarda el sistema en decidir cuál estabas siguiendo. Fíjate en las dos cosas que hacen o rompen la técnica: cuántos objetivos hay a la vez, y cuánto se parecen entre sí sus trayectorias.

6.2 Reconocimiento y síntesis del habla

El habla es la modalidad de comunicación más natural entre humanos, y por décadas fue también la promesa incumplida de la interacción persona-máquina. Eso cambió. El reconocimiento del habla (Automatic Speech Recognition, ASR) convierte una señal de audio en texto. La arquitectura clásica combina un modelo acústico (qué fonemas componen la señal) con un modelo de lenguaje (qué secuencias de palabras son probables en este idioma y contexto); la transcripción más verosímil gana. Los sistemas modernos sustituyen ambos modelos por redes neuronales end-to-end, pero la estructura conceptual sobrevive.

La síntesis del habla (Text-to-Speech, TTS) hace el viaje inverso: parte de texto y produce audio. Analiza léxico y sintaxis del texto, traduce a fonemas, agrega prosodia (entonación, ritmo, énfasis) y sintetiza la onda. Las generaciones recientes de TTS neuronales han borrado casi por completo la frontera de la "voz robótica" — una voz sintética bien entrenada hoy resulta indistinguible de una grabación humana corta.

Combinar ASR y TTS produce sistemas de diálogo hablado: Siri, Alexa, el Asistente de Google. Su diseño abre preguntas que las heurísticas de Nielsen no responden directamente: ¿cómo señalar visibilidad de estado en una interfaz sin pantalla? ¿Cómo recuperarse de errores cuando el usuario no sabe qué frases acepta el sistema? Las respuestas — earcons de confirmación, repetición explícita ("escuché 'apagar la luz del living', ¿correcto?"), políticas de timeout — siguen siendo terreno activo de diseño.

6.3 Comprender el lenguaje: NLP

ASR convierte audio en texto, pero el texto bruto no es comprensión. El procesamiento del lenguaje natural (NLP) es el área que estudia cómo hacer que una máquina entienda y produzca lenguaje humano de manera significativa. Sus capas tradicionales — analizadas durante décadas por Manaris (1998) y otros — son léxica (¿qué palabras hay?), sintáctica (¿cómo se relacionan gramaticalmente?), semántica (¿qué significan en este contexto?) y pragmática (¿qué quiso decir el hablante?).

Para sistemas interactivos ubicuos, NLP es la diferencia entre un comando rígido y una conversación. Un altavoz inteligente que solo reconoce "OK Google, enciende la luz" pertenece al pasado; uno que comprende "está demasiado oscuro" y deduce la acción pertenece al presente. Las aplicaciones desbordan los altavoces: chatbots de atención al cliente, asistentes de escritura como WriteBetter (Bellino y Bascuñán, 2020), traducción automática, análisis de sentimientos sobre reseñas, resúmenes automáticos. En todos los casos, el reto del diseñador no es entrenar el modelo de lenguaje — eso lo hacen pocas empresas con muchísimos datos — sino integrarlo en una experiencia donde el usuario sepa qué puede pedir, reciba retroalimentación clara y pueda corregir el rumbo cuando la máquina se equivoca.

6.4 EM-Sense: escuchar el ruido invisible

Hasta aquí, las técnicas observadas usaban señales que el usuario produce intencionalmente: mirar, hablar. La siguiente clase de técnicas, en cambio, escucha el ambiente. Y de ahí se ha vuelto una especialidad de un grupo en particular: el Future Interfaces Group del CMU (Carnegie Mellon), dirigido por Chris Harrison, con figuras como Gierad Laput y Yang Zhang aportando algunas de las ideas más originales de la última década.

EM-Sense (Laput, Yang, Xiao, Sample y Harrison, 2015, UIST) parte de un hecho que parece anecdótico pero es enorme: la mayoría de los aparatos eléctricos del mundo emiten ruido electromagnético característico cuando funcionan. El motor de un cepillo de dientes, la fuente conmutada de un router, la pantalla de un microondas, el ventilador interno de un notebook — cada uno tiene una "firma" EM distinta, modulada por su electrónica interna.

Cuando una persona toca uno de estos objetos, su cuerpo — que es un conductor razonable — se acopla al circuito y propaga esa señal. EM-Sense pone un sensor capaz de captar el espectro EM en la muñeca del usuario (un smartwatch modificado con una radio definida por software, SDR). El watch capta el ruido propagado a través del cuerpo, le aplica una transformada de Fourier para extraer un espectro característico, y un clasificador entrenado por machine learning decide qué objeto fue tocado.

El resultado, con el hardware de 2015, ya distinguía decenas de objetos con precisión cercana al 96%. Lo más bonito es lo que no requiere: ningún objeto del entorno necesita ser instrumentado. No hay etiquetas RFID, ni cámaras, ni dispositivos extra.

La infraestructura de sensores es el propio mundo eléctrico que ya nos rodea.

EM-Sense es, en este sentido, un ejemplo perfecto de la calm technology de Weiser — la información se obtiene de fenómenos que ya estaban ahí pero que nadie escuchaba.

Las aplicaciones imaginadas por los autores recorren un espectro amplio. Lanzar una app de temporizador cuando el usuario toma el cepillo de dientes eléctrico. Inferir actividades cotidianas a partir de la secuencia de objetos manipulados. Reconocer si un electrodoméstico está prendido o apagado por su firma EM. Usar el toque a un objeto personal (la manija de la puerta de la oficina) como factor de autenticación implícita. Diferenciar quién toca qué en un entorno compartido.

La Fig. 7.3 explica por qué esto funciona sin instrumentar ningún objeto: la firma electromagnética la emite el propio aparato, el cuerpo hace de antena y el reloj solo tiene que clasificarla. El sensor no está en la cosa — está en la persona. El Fig. 7.4 lo muestra distinguiendo un taladro de un picaporte motorizado.

6.5 Electrick: tomografía táctil de bajo costo

Si EM-Sense escucha el mundo, Electrick (Zhang, Laput y Harrison, 2017, CHI) lo toca. Y resuelve un problema que parecía resuelto pero no lo estaba: convertir cualquier superficie de cualquier forma en una pantalla táctil sin gastar miles de dólares en un sensor capacitivo a medida.

La técnica se basa en tomografía de campo eléctrico (Electric Field Tomography, EFT). Cualquier objeto o superficie hecho de un material electrónicamente conductor pero con cierta resistividad — plásticos conductores como el ABS con carbono, Velostat, pinturas conductoras, hidrogeles tan domésticos como Jell-O o Play-Doh — sirve como sustrato. Se le pegan o instalan electrodos en el perímetro. Una pequeña corriente se inyecta entre pares de electrodos adyacentes, generando un campo eléctrico a través del material; el sistema mide el voltaje entre todos los demás pares.

Cuando un dedo humano toca la superficie, el cuerpo del usuario actúa como una vía a tierra y deriva parte del campo. Las medidas de voltaje se alteran de forma característica. Comparando los voltajes con un mapa de referencia, el sistema triangula el punto de contacto. Con suficientes electrodos y un modelo de inversión adecuado, la precisión es del orden de un centímetro o mejor — más que suficiente para botones, sliders, gestos amplios.

Lo que hace a Electrick excepcional no es la precisión sino la versatilidad de fabricación. Una mesa pintada con pintura conductora se vuelve táctil. Una pared con plancha de Velostat detrás del yeso se vuelve táctil. Un objeto impreso en 3D con filamento de ABS conductor se vuelve táctil. Un peluche relleno con material conductor se vuelve táctil. El componente electrónico que cierra el sistema es modesto: un microcontrolador con multiplexor analógico, conectores hacia los electrodos del perímetro y un puerto serial. Material: decenas de dólares. La técnica democratiza la fabricación de interfaces táctiles más allá de la pantalla rectangular.

La Fig. 7.5 resume los cuatro pasos de la técnica —pintura conductiva, electrodos en el borde, corriente inyectada, reconstrucción por tomografía— y el Fig. 7.6 la muestra aplicada sobre una pared, un volante y un juguete. Ni la escala ni el material siguen siendo una restricción.

6.6 Móviles y wearables: jugar con el factor de forma

Las técnicas anteriores funcionan en hardware exótico. Pero la plataforma ubicua más extendida es la que ya está en el bolsillo. Smartphones y smartwatches concentran sensores (cámara, micrófono, acelerómetro, giroscopio, GPS, magnetómetro), conectividad permanente y pantallas con resolución pero limitadas en tamaño. Diseñar para ellos exige reconocer las restricciones — uso con una mano, pulgar como dedo dominante, pantalla mínima en el reloj — y volverlas oportunidades.

Gestos optimizados para una mano

Cuando se sostiene un teléfono con una mano, el pulgar opera prácticamente todo, y su trayectoria útil dibuja un arco — no llega cómodamente a la esquina opuesta. The Fat Thumb (Boring et al., 2012) propuso usar el tamaño del área de contacto del pulgar como una modalidad extra, similar a presión: el pulgar plano sobre la pantalla activa un modo distinto al pulgar de punta, lo que permite alternar entre paneo y zoom sin levantar el dedo. Thumb + Pen Interaction on Tablets (Pfeuffer, Hinckley, Pahud y Buxton, 2017) explora la división del trabajo entre el pulgar de la mano que sostiene la tableta y un lápiz óptico en la otra: una bimanual asimétrica que aprovecha lo mejor de cada modalidad.

El Fig. 7.7 deja ver la economía de la propuesta: apoyar la yema o aplanar el pulgar alterna entre desplazar y hacer zoom, sin un botón nuevo ni un gesto que memorizar. El Fig. 7.8 ataca el mismo problema repartiendo el trabajo entre las dos manos de forma asimétrica — el pulgar fija el modo, el lápiz ejecuta.

Entrada acústica no vocal

Whoosh (Reyes et al., 2016) usa el micrófono del smartwatch para reconocer soplos del usuario — cortos, largos, direccionales — como comandos. Combinado con una carcasa impresa en 3D que modifica la acústica (Flutecase), la técnica permite navegar un menú soplando, sin tocar la pantalla, sin hablar. Es manos libres y voz libre — útil para contextos donde hablar molesta (una reunión) y donde tocar es incómodo (con guantes, con las manos sucias).

Ritmo y movimiento corporal

Una familia menos conocida pero conceptualmente rica es la de las técnicas basadas en ritmo. La idea: en lugar de identificar al usuario por su huella o reconocer un gesto puntual, identificar una secuencia temporal que el usuario produce y que el sistema relaciona con una opción visible. SEQUENCE (Bellino, 2018) lleva esta idea a un control remoto: cada elemento seleccionable en pantalla parpadea o se mueve con un ritmo distinto, y el usuario lo selecciona haciendo un movimiento corporal sincronizado con ese ritmo, capturado por la cámara frontal del smartphone. La técnica hereda del smooth pursuit la lógica de correlación, pero la traslada al cuerpo entero: el dedo, la cabeza, el torso pueden ser el "puntero". TraceMatch (Clarke et al., 2016) extendió la idea a controles que orbitan en pantalla, detectando coincidencias entre el movimiento del usuario y la trayectoria del objetivo a través de visión por computador.

La Fig. 7.9 muestra los cuatro pasos de esta familia y, sobre todo, su ventaja menos evidente: el canal es temporal y no espacial, así que la técnica no exige mirar y funciona con el dispositivo en el bolsillo. El Fig. 7.10 aplica la misma lógica de sincronía al movimiento corporal frente a una pantalla pública.

Multi-dispositivo y continuidad

Las pantallas grandes están en todas partes — paredes de visualización, TVs, monitores compartidos — y casi nunca son táctiles. Una vertiente de la investigación de los últimos años ha usado el smartphone como controlador para pantallas grandes. Touch&Screen ofrece una colección de widgets para pantallas murales operadas desde el teléfono. SleeD (von Zadow et al., 2014) va más allá: monta una pequeña pantalla táctil en la muñeca, que el usuario lleva como manga, y que sirve simultáneamente para detectar dónde toca la pared y para mostrar información detallada que la pared grande no muestra. La interacción se reparte entre lo que ve la pared (resumen, contexto) y lo que ve la muñeca (detalle, control).

Cámara como sensor de texto

CameraKeyboard (Bellino y Herskovic, 2019) usa la cámara del smartphone como soporte adicional para la entrada de texto, ampliando el ancho de banda del teclado virtual con información visual del entorno. Es un recordatorio de que sensores que ya están encendidos pueden hacer mucho más de lo que su uso "canónico" sugiere — un principio que recorre toda esta cápsula.

El Fig. 7.11 cierra la sección con el argumento más económico de todos: en lugar de pedir más pantalla, usa un sensor que el teléfono ya traía. Es el recordatorio de que ampliar el ancho de banda de entrada no siempre exige hardware nuevo.

El patrón común: señal, sensor, procesado, inferencia, feedback

Mirando el catálogo, emerge una arquitectura compartida que conviene hacer explícita:

1. Señal: el fenómeno físico que aporta información (movimiento ocular, onda sonora, ruido electromagnético, deriva de campo eléctrico, gesto corporal).
2. Sensor: el hardware que transduce esa señal a datos digitales (cámara infrarroja, micrófono, radio SDR, electrodos perimetrales, cámara RGB).
3. Procesado: la limpieza y reducción del dato bruto (filtrado, transformada de Fourier, suavizado, segmentación).
4. Inferencia o algoritmo: el modelo que extrae intención del dato procesado (correlación de trayectorias, clasificador ML, triangulación geométrica, modelo acústico + modelo de lenguaje).
5. Feedback o salida: la respuesta del sistema, idealmente inmediata y legible (selección de objeto, comando ejecutado, identificación de objeto tocado, transcripción de habla).

Una técnica avanzada se entiende cuando se puede recorrer esa pipeline sin saltarse pasos. Y se evalúa de forma crítica cuando se identifican sus puntos de falla: ¿qué pasa si la iluminación cambia (calibración del eye tracker)? ¿Qué pasa con ruido EM ambiental (EM-Sense en una oficina llena de equipos)? ¿Qué pasa si la superficie de Electrick se humedece o el material envejece? ¿Qué pasa si el usuario tiene un tic involuntario y arruina la sincronía rítmica?

Aprendizaje activo

En la próxima sesión te toca a vos diseccionar una técnica. Actividad 6 — Caja Negra de la Técnica te pide elegir, en grupo, una de las técnicas vistas (EM-Sense, Electrick, Orbits, Whoosh, SEQUENCE, AmbiGaze, Pursuits, Fat Thumb, lo que sea), y abrirle la caja negra mediante un diagrama de bloques que respete los cinco pasos: señal → sensor → procesado → inferencia → feedback.

Después vienen las dos partes difíciles: listar al menos tres limitaciones reales — no genéricas ("no es perfecta"), sino específicas y técnicamente argumentables ("EM-Sense falla cuando hay dos electrodomésticos del mismo modelo en el ambiente porque su firma EM es indistinguible") — y proponer una mejora o sensor auxiliar que mitigue una limitación. La mejora puede ser un sensor extra que aporte información complementaria, un cambio en el algoritmo, una modificación en el diseño físico de la interfaz, o una combinación. Lo que importa es que la propuesta sea concreta, factible y conectada a la limitación que dice atacar.

Cada grupo presenta 2-3 minutos: técnica, diagrama, limitaciones, propuesta. Recuerda que la caja negra deja de serlo cuando alguien la dibuja en cinco bloques con flechas claras.

Una caja de cartón con un smartphone adentro puede ser, durante quince minutos, el sistema más inteligente que vas a diseñar este año.

Hay una vieja tentación en el diseño de sistemas interactivos: empezar por el final. Especificar todo, modelar todo, comprar la placa correcta, imprimir la carcasa en 3D, soldar los cables, y solo entonces — exhausto, comprometido, sin presupuesto — mostrarlo a alguien. Para entonces el sistema ya existe, y descubrir que la interacción no funciona se vuelve un problema político antes que un problema de diseño. El prototipado existe precisamente para evitar esa trampa. Prototipar es comprimir el ciclo: pensar una idea, materializarla mal pero rápido, ponerla frente a un usuario, escuchar lo que rompe, y repetir. No se prototipa para producir un objeto: se prototipa para producir aprendizaje.

En esta cápsula vamos a desarmar el concepto con cuidado. Qué es un prototipo y qué no lo es. Qué dimensiones lo definen — fidelidad, alcance, interactividad. Qué técnicas conviene usar en cada fase del proceso de diseño. Y, sobre todo, cómo construir prototipos físico-digitales para sistemas ubicuos sin necesidad de un laboratorio de electrónica, combinando cartón con el dispositivo más cargado de sensores que ya llevamos en el bolsillo.

1. Qué es (y qué no es) un prototipo

Un prototipo es una representación tangible y experimental de una idea de diseño, creada para responder preguntas específicas y validar hipótesis. La definición parece inocua hasta que se subraya la palabra específicas. Un prototipo no responde a la pregunta universal "¿cómo sería el producto?", sino a preguntas locales: ¿el usuario entiende que debe girar la perilla? ¿el sensor detecta la presencia desde el otro lado de la sala? ¿la pantalla puede transmitir urgencia sin chillar? Cada prototipo tiene un foco, y ese foco es lo que justifica las decisiones de qué simular y qué dejar afuera.

Houde y Hill, en su clásico What do prototypes prototype? (1997), proponen leer cualquier prototipo a lo largo de tres ejes: el rol que el sistema cumple en la vida del usuario, la apariencia y sensación que produce al ser tocado o mirado, y la implementación técnica que lo hace posible. Un prototipo nunca cubre los tres ejes con la misma profundidad. Una maqueta en cartón cubre apariencia, un storyboard cubre rol, un fragmento de código de visión por computador cubre implementación. La pregunta inteligente no es ¿es realista?, sino ¿qué eje estoy explorando hoy?.

Cuando un equipo se atasca discutiendo si el prototipo "se ve mal" mientras la pregunta era sobre el rol del sistema, lo que falla no es el prototipo: es la conversación sobre el prototipo.

Bill Buxton, en Sketching User Experiences (2007), insiste en una distinción todavía más cortante: existe el boceto y existe el prototipo. El boceto es divergente — su trabajo es generar muchas opciones para descartar la mayoría. El prototipo es convergente — su trabajo es refinar una opción que ya creemos válida. Confundirlos cuesta caro. Tratar un boceto como prototipo paraliza la generación de ideas (porque cada opción cuesta demasiado de producir). Tratar un prototipo como boceto disuelve el foco (porque nadie se compromete a ninguna decisión). En la práctica del curso, los primeros días son de bocetos baratos, los siguientes de prototipos cada vez más comprometidos.

2. Las cinco preguntas a las que sirve un prototipo

Beaudouin-Lafon y Mackay, en su capítulo Prototyping tools and techniques del HCI Handbook (2012), sintetizan los cinco propósitos fundamentales de prototipar. Los repasamos porque cada propósito sugiere una técnica distinta:

• Exploración de ideas: probar y comparar conceptos antes de comprometerse con uno. Aquí mandan los prototipos baratos y desechables. Si la primera opción cuesta un día, no va a haber segunda opción.
• Comunicación: materializar la idea para que el equipo, los stakeholders y los usuarios la puedan discutir sin malentendidos. Una maqueta en cartón comunica una decisión arquitectónica mejor que diez páginas de documento.
• Obtención de feedback: poner el prototipo en manos de un usuario real y observar dónde se traba. Esta es la prueba de fuego del DCU: si no hay usuario, no hay feedback, y el prototipo se convierte en un objeto decorativo.
• Refinamiento de requisitos: validar que los requisitos declarados al inicio sobreviven al contacto con la realidad. Cuando el usuario interactúa con la maqueta, casi siempre aparecen requisitos ocultos que nadie había verbalizado.
• Reducción de riesgos: identificar problemas técnicos o de usabilidad antes de que el costo de corregirlos sea prohibitivo. Un problema descubierto con cartón cuesta cinco minutos; el mismo problema descubierto con la electrónica ya montada cuesta dos semanas.

Esto importa: si no sabes qué pregunta estás respondiendo, cualquier nivel de fidelidad te va a parecer insuficiente. Prototipar empieza por escribir la pregunta.

3. Las dimensiones del prototipo: fidelidad, alcance, reconfigurabilidad

Todo prototipo se ubica en un espacio multidimensional. No hay un eje único que decida si un prototipo es "bueno": la decisión es siempre sobre qué ejes maximizar dado el momento del proceso. La Fig. 8.1 pone los dos fracasos posibles en los extremos del espectro: por abajo, la idea que nunca se probó; por arriba, la demo bonita y vacía que impresiona sin haber respondido ninguna pregunta. El punto útil casi nunca está en los extremos.

La fidelidad mide qué tan parecido es el prototipo al producto final en apariencia, interacción y contenido. Un boceto en papel está en un extremo (baja fidelidad o lo-fi); un build casi funcional con la electrónica definitiva está en el otro (alta fidelidad o hi-fi). La tentación del estudiante es saltar a alta fidelidad demasiado pronto — un prototipo bonito convence más, dice el instinto. El error está en que un prototipo demasiado bonito también recibe menos crítica: el usuario lo trata como producto, no como hipótesis, y se calla las dudas que sí habría verbalizado frente a un pedazo de cartón. La baja fidelidad invita a la crítica porque no parece terminada.

La Fig. 8.2 muestra el mismo objeto prototipado cuatro veces, subiendo un escalón de fidelidad cada vez: cartón, madera cortada con láser, impresión 3D y aluminio fresado. Cada salto cuesta más y responde una pregunta distinta — el cartón contesta si el tamaño y el gesto funcionan; el aluminio, si el mecanismo aguanta.

El alcance distingue prototipos horizontales (cubren muchas funciones, todas superficialmente) de prototipos verticales (cubren una sola función, en gran profundidad). Un sistema ubicuo típico de este curso combina los dos: un horizontal para mostrar el flujo completo del escenario y uno o dos verticales para resolver las interacciones más delicadas, como el momento en que el sensor decide disparar una alerta.

La reconfigurabilidad es la dimensión que más rápidamente se infravalora. ¿Puedo modificar este prototipo para probar otra cosa, o cualquier cambio implica reconstruir desde cero? Un boceto en papel es infinitamente reconfigurable. Una placa con todo el firmware grabado no lo es. La reconfigurabilidad alta protege la iteración; la baja la castiga. En las primeras semanas, prioriza reconfigurabilidad sobre todo lo demás.

La Fig. 8.3 sitúa las técnicas en tres ejes que se contradicen entre sí, y ahí se ve por qué no hay una opción "correcta": los kits y el cartón se rehacen en minutos pero se parecen poco al producto final, mientras la impresión 3D se acerca al producto y cobra cada cambio con una noche de impresión. Elegir técnica es elegir qué se sacrifica.

Finalmente, el nivel de habilidad requerido para producir el prototipo afecta a quién puede participar de su construcción. Si solo una persona del equipo sabe soldar, el cuello de botella es esa persona. Si la construcción es accesible — tijeras, cartón, cinta — todos pueden iterar en paralelo. Esto es directamente político: la accesibilidad del método determina quién opina sobre el diseño.

4. Cinco técnicas que conviene tener en el cinturón

Hay un catálogo grande de técnicas; aquí cinco que cubren bien las etapas del curso.

Bocetado y paper prototyping. Lápiz, papel, post-its. Sirve para explorar interfaces gráficas y flujos de pantalla. Su gran virtud no es económica sino psicológica: nadie se enamora de un boceto, por lo que nadie se ofende cuando se tira. En la práctica, dibujar diez opciones de una interfaz toma menos tiempo del que toma armar una sola en Figma.

Maquetas digitales y wireframes (Figma, Sketch, Adobe XD). Suben un peldaño en fidelidad y permiten simular flujos clicables. Útiles cuando necesitas probar la navegación de una app o de un panel de control con un usuario que no estará al lado tuyo para narrarte el flujo. Cuidado con la trampa estética: Figma facilita el pixel-perfect, y un mock-up pixel-perfect inhibe la crítica conceptual.

Mago de Oz (Wizard of Oz, o WoZ). Un humano oculto simula al sistema. Sirve cuando la implementación técnica es cara o riesgosa — reconocimiento de voz, IA, fusión de sensores — pero la pregunta es de interacción: ¿el usuario hablaría con esto?, ¿esperaría que entendiera ironías?, ¿se frustra si tarda dos segundos en responder? El mago simula la respuesta, el sistema todavía no existe, pero el feedback es real. La Fig. 8.4 deja ver el reparto completo de la escena —usuario, interfaz real, mago detrás— y por qué funciona: se puede evaluar la experiencia completa antes de haber construido la inteligencia que la sostendría. A veces el hallazgo es que esa inteligencia no hacía falta.

Prototipado en video. Un cortometraje que muestra el sistema funcionando en su contexto de uso. No requiere que el sistema exista todavía: lo que importa es comunicar el rol que pretende cumplir. Es la herramienta canónica para vender una visión a un cliente o a un profesor que pide claridad sin haber escuchado todavía el detalle técnico.

Prototipado físico. Construcción de modelos con cartón, espuma, piezas impresas en 3D, o combinaciones. Va desde maquetas no funcionales — para probar forma, escala y ergonomía — hasta prototipos funcionales con electrónica básica. Para sistemas ubicuos, esta técnica es central: el sistema vive en el mundo físico, y discutirlo en pantalla es discutirlo a medias.

5. Sensores y actuadores: el ABC del prototipo que reacciona

Un prototipo físico cobra vida cuando empieza a percibir y a actuar. La intuición de la cápsula 05 vuelve aquí en clave práctica: un sensor es la entrada (cómo el sistema se entera del mundo) y un actuador es la salida (cómo el sistema interviene en el mundo).

La distinción útil para prototipar rápido es entre componentes específicos y componentes multipropósito. Un sensor de temperatura es específico: solo mide temperatura. Una cámara, en cambio, es multipropósito — con software adecuado puede detectar presencia, contar personas, leer marcadores ARUCO, reconocer caras, seguir manos, identificar gestos. Lo mismo con el micrófono (nivel de ruido, reconocimiento de habla, clasificación de eventos sonoros) y con los sensores inerciales (acelerómetro y giroscopio combinados detectan movimiento, inclinación, orientación tridimensional).

En el lado de los actuadores, los altavoces y las pantallas son los campeones multipropósito. Una pantalla puede simular casi cualquier display físico — un termómetro, una lámpara, un reloj, una alarma — si la programación visual es lo bastante convincente. Para una primera ronda de prototipado, una pantalla simulando una lámpara cuesta cero y comunica lo mismo que la lámpara real.

El corolario importante es éste: hoy, el dispositivo que combina más sensores y actuadores multipropósito en una sola pieza ya lo tenemos todos en el bolsillo. El smartphone es, para fines de prototipado, un laboratorio portátil. Saber explotar esa intuición es la diferencia entre necesitar dos semanas para mostrar una idea y necesitar dos horas.

6. La sinergia cartón + smartphone

Aquí entra la jugada que el curso recomienda para los primeros prototipos físico-digitales: combinar el cartón (el cuerpo) con el smartphone (los sentidos y el cerebro).

El cartón es el material ideal del prototipado lo-fi por razones que trascienden lo económico. Es barato, sí, pero también es versátil (se corta y se pega en minutos), moldeable (acepta curvas, solapas, compartimentos), y sobre todo es inacabado. Esa cualidad es la más subestimada: el cartón anuncia visualmente que el objeto no es final, que está abierto a ser modificado, que pedir un cambio no es una imposición. Cuando un usuario interactúa con un prototipo de cartón, no se inhibe; lo agarra, lo gira, lo critica.

El smartphone, por su lado, aporta lo que el cartón no puede: la capacidad de sentir y de responder. Embebido dentro de la maqueta, un teléfono puede medir movimiento, escuchar sonido, ver con su cámara, hablar por su altavoz, vibrar. Con la programación adecuada, simula un dispositivo "inteligente" sin que sea necesario soldar ni un solo cable.

La herramienta que el curso usa para articular esta combinación es el Protobject Framework — un framework de prototipado físico-digital desarrollado en el contexto del propio curso. Protobject convierte cada smartphone, tablet o computador en un nodo de una aplicación distribuida; cada nodo ejecuta una página HTML con componentes programados en JavaScript. La idea es que el prototipo no vive en un solo dispositivo: vive entre varios, conectados por mensajes, igual que un sistema ubicuo real.

La estructura se resume en una frase: un archivo de configuración declara las páginas y designa la principal, cada página HTML hace de dispositivo, y la Core API las pone a conversar con send().to() y onReceived(). El sistema no es ninguna de las páginas — es la conversación entre ellas.

La cápsula técnica que sigue a esta desarrolla Protobject completo — arquitectura, sensores, componentes de interfaz, integración con Arduino, patrones aplicados. Aquí solo importa quedarse con la idea: el framework existe para que la barrera de entrada al prototipado físico-digital sea baja, accesible desde el primer día de clase, y sin requerir hardware especializado para mostrar resultados.

7. Cuándo subir de fidelidad: Arduino, Raspberry Pi, ESP32

Llega un momento en que el smartphone no alcanza. La precisión de un sensor de temperatura comercial supera a la del teléfono; un servomotor necesita ser controlado con señales que el navegador no maneja directamente; un wearable no puede pesar trescientos gramos. Para esos casos, el espectro de prototipado se prolonga hacia el hardware dedicado.

Arduino es la plataforma canónica de hardware abierto. De bajo costo, con una comunidad enorme y documentación exhaustiva, sirve para leer sensores específicos y controlar actuadores (motores, LEDs, relés) en escenarios donde el smartphone no llega. Protobject Framework se integra con Arduino vía WebUSB, así que la transición no exige cambiar de paradigma de programación.

Raspberry Pi sube otro escalón: es un computador completo en una placa pequeña, capaz de correr Linux. Sirve cuando el prototipo requiere procesamiento más pesado — visión por computador local, servidor web embebido, modelos de machine learning corriendo en el dispositivo.

ESP32 / ESP8266 son microcontroladores baratos con Wi-Fi y Bluetooth integrados, especialmente cómodos para proyectos IoT donde muchos nodos pequeños tienen que conectarse a la red.

Phidgets — sensores y actuadores con conexión USB pensados para software developers sin experiencia en electrónica — son el último peldaño antes del hardware industrial.

El punto importante no es el catálogo: es que el espectro existe. Prototipas en cartón mientras la pregunta sea sobre el concepto de la interacción, y subes hacia Arduino o Raspberry Pi solo cuando la pregunta empieza a ser sobre la precisión o la escala. Saltar demasiado pronto al hardware dedicado es el error más común y el más costoso.

8. Una nota sobre la honestidad del prototipo

Hay una tentación final que conviene nombrar: el prototipo demasiado convincente. Cuando una maqueta queda demasiado pulida, los usuarios dejan de criticarla — la tratan como producto, no como hipótesis — y los stakeholders dejan de cuestionarla porque parece inversión consumada. Buxton lo dice claro: el prototipo debe ser honesto sobre qué es. Si está hecho de cartón, que se vea de cartón. Si simula un sensor con un mago, que el equipo sepa que es un mago. Esa transparencia es lo que mantiene viva la conversación de diseño.

Un prototipo honesto también admite sus límites de fidelidad. No intentes que un prototipo de baja fidelidad responda preguntas de alta fidelidad, ni viceversa. La pregunta correcta para una maqueta de cartón es "¿la forma comunica el rol?", no "¿el tiempo de respuesta es aceptable?". Confundir los niveles de pregunta es la fuente de la mitad de las discusiones inútiles en cualquier proyecto.

Aprendizaje activo

En la Actividad 7 — Prototype-Jam vamos a comprimir todo lo anterior en una sesión de dos horas: cartón, tijeras, cinta, y un celular por grupo. La consigna es simple — avanzar lo más posible en la materialización física del proyecto de curso de cada equipo — pero el método es exigente: brainstorming corto (diez minutos), ciclos rápidos de prototipado (cien minutos, alternando construir y documentar), consolidación de la bitácora (diez minutos). Cada funcionalidad construida debe quedar registrada con una o dos fotos y una descripción breve. No se busca perfección: se busca avance, cantidad, claridad. La sesión se entrega al final del día como una bitácora en PDF.

Cuando la interfaz se disuelve en el ambiente, evaluar deja de ser mirar una pantalla: es escuchar al cuerpo, al gesto, al silencio que aparece cuando algo simplemente funciona.

Hemos diseñado, prototipado, soldado, peleado con el cable suelto. Llega el momento incómodo: poner el sistema frente a alguien que no somos nosotros y preguntar, sin trampas, si funciona. La evaluación es la fase del Diseño Centrado en el Usuario donde el objeto se vuelve, por fin, objetivo de estudio. Donde el prototipo deja de ser nuestro hijo y se convierte en un sujeto experimental al que se le miden cosas. Y donde, casi siempre, descubrimos que lo que creíamos obvio no lo era para nadie más.

En los sistemas interactivos ubicuos esta fase tiene un agravante: no hay una pantalla a la que mirar. La interacción se distribuye en el espacio, en el cuerpo, en el ambiente. Un sensor detecta presencia, una luz cambia de color, un haptic vibra discreto en la muñeca. ¿Cómo se mide la usabilidad de algo que ni siquiera tiene un botón "OK"? ¿Cómo se observa el "click" cuando no hay clicks? Esta cápsula introduce el repertorio mínimo de métodos que un diseñador de sistemas ubicuos necesita dominar para responder esas preguntas sin engañarse a sí mismo.

¿Por qué evaluar?

Hay una tentación, muy común en proyectos de magíster, de tratar la evaluación como un trámite final: una prueba con tres amigos, una foto, una diapositiva con el SUS aplicado al apuro. Esa lectura es equivocada. La evaluación no es la última prueba antes de la entrega: es el bucle de retroalimentación que da forma al diseño. Cada iteración del prototipo debería ser empujada por evidencia, no por la intuición del equipo.

Jakob Nielsen (1993), en Usability Engineering, lo formuló con una claridad que sigue vigente más de tres décadas después: el costo de detectar un problema de usabilidad crece exponencialmente con el avance del proyecto. Encontrar un fallo de comprensión en un boceto en papel cuesta minutos; encontrar el mismo fallo después de fabricar el PCB cuesta semanas y plata. La pregunta correcta no es ¿cuándo evaluamos? sino ¿cuándo no estamos evaluando?. La evaluación es continua. Lo que cambia entre fases es la fidelidad de lo evaluado y la formalidad del método.

La Fig. 9.1 enfrenta los dos modos de evaluar por lo que cada uno puede responder, y ahí está la clave para elegir: lo cualitativo contesta por qué y sirve para generar hipótesis; lo cuantitativo contesta cuánto y sirve para confirmarlas. Son secuenciales antes que alternativos.

8.1 Tres familias: cuantitativo, cualitativo, mixto

La taxonomía clásica organiza los métodos por el tipo de dato que producen. Conviene tenerla mental como una brújula, no como una jaula.

Métodos cuantitativos

Producen números. Tiempos, tasas, conteos, puntajes en escalas. Responden a las preguntas cuánto, cuán rápido, cuántos. Ejemplos típicos: tiempo para completar una tarea, tasa de éxito, número de errores, puntaje en un cuestionario estandarizado como el SUS, logs de interacción del sistema (clicks, dwell time, eventos del sensor).

Su virtud es la comparabilidad. Si la versión A obtiene un SUS de 62 y la versión B obtiene 78, hay base para tomar una decisión que no depende del gusto del jefe. Permite test A/B, análisis estadístico, agregación entre estudios. Es el lenguaje que entienden las reuniones con stakeholders.

Su límite es brutal y se olvida con frecuencia: los números no explican el porqué. Si la versión A tarda más en promedio, los segundos no dicen si fue por torpeza del usuario, por una etiqueta ambigua, por un feedback inexistente o por un cable que se desconectó a mitad de la sesión.

La Fig. 9.2 recoge las métricas típicas de esta familia —tiempo en tarea, tasa de errores, escalas Likert, tamaño de muestra— junto con la condición que las vuelve válidas y que en un curso es la más difícil de cumplir: una muestra suficiente.

Métodos cualitativos

Producen observaciones, transcripciones, notas, citas textuales. Responden a las preguntas por qué y cómo. Ejemplos: observación directa, entrevistas, protocolo think-aloud, grupos focales, análisis temático de comentarios abiertos.

Su virtud es la profundidad. Un comentario espontáneo del tipo "esperaba que se prendiera la luz cuando levanté la mano, no después de tres segundos" vale, en términos de diseño, más que cien filas de Excel. Descubre problemas que nadie había anticipado, porque emerge de la interacción real, no de un cuestionario pre-fabricado.

Su límite es la subjetividad del analista y la dificultad de generalizar. Tres entrevistas profundas no son una muestra estadística; son una hipótesis. Útil, valiosa, pero hipótesis al fin.

Las cuatro técnicas de esta familia aparecen en la Fig. 9.3: entrevista uno a uno, grupo focal, observación directa y pensar en voz alta. Todas comparten el mismo perfil —muestras pequeñas, evidencia profunda— y entregan justamente lo que un promedio nunca muestra: el matiz y el contexto.

Métodos mixtos

Combinan ambos. La gracia no está en hacer "un poco de cada uno" sino en triangular: usar los datos cualitativos para explicar los cuantitativos, y los cuantitativos para evidenciar la magnitud de lo cualitativo. Cuando los dos enfoques convergen sobre el mismo hallazgo, la conclusión gana solidez. Cuando divergen, es señal de que hay algo interesante que entender.

En esta cápsula, y en la actividad que la cierra, vamos a privilegiar este tercer camino.

Para un prototipo ubicuo en fase temprana, evaluar solo con números equivale a medir la temperatura de una casa mirando el termómetro de la entrada: tienes un dato, pero te perdiste la mitad de la historia.

Otros ejes para clasificar una evaluación

Más allá del tipo de dato, una evaluación se puede leer por cuándo y contra qué se mide. La distinción más útil en un curso de prototipado es entre evaluación formativa y sumativa: la formativa ocurre mientras se diseña —su objetivo es descubrir qué arreglar en la próxima iteración— mientras que la sumativa llega al final, para juzgar si el sistema cumple. En este curso, casi todo lo que harán es formativo: evaluar para mejorar, no para calificar.

La Fig. 9.4 ordena ese eje temporal completo, del inicio a la entrega. En un proyecto de un semestre la lectura práctica es directa: la formativa es la que cambia el resultado, la sumativa apenas lo certifica.

Otro eje es absoluta vs relativa. Una evaluación absoluta mide el sistema contra un criterio o umbral fijo (¿el SUS supera 70?, ¿la tarea se completa en menos de un minuto?); una relativa lo compara con una alternativa (¿la versión A o la B?). La absoluta dice si algo es "suficientemente bueno"; la comparativa dice "cuál es mejor".

La Fig. 9.5 muestra cómo se ve una evaluación absoluta en la práctica: un solo sistema contrastado con criterios explícitos, sin ninguna alternativa al lado. Nótese que su producto no es una nota sino una lista de oportunidades de mejora.

Por último está el eje temporal. Un estudio transversal toma una instantánea: muchos usuarios —o varias condiciones— medidos una sola vez, en un mismo momento, ideal para comparar diseños rápido. Un estudio longitudinal sigue a los mismos usuarios a lo largo del tiempo, y revela lo que ninguna sesión única captura: el efecto de la novedad que se desvanece, el aprendizaje, el abandono. Para sistemas ubicuos —que conviven con el usuario durante meses— lo longitudinal es especialmente revelador, aunque cueste más.

Las dos figuras siguientes contrastan justamente eso. La Fig. 9.6 enfrenta, en un mismo momento, tres soluciones distintas para la misma tarea —una gestual, una por voz, una tangible— y obliga a definir de antemano qué significa "mejor". La Fig. 9.7, en cambio, sigue a un mismo prototipo versión tras versión midiendo siempre lo mismo: es la evidencia que convierte una serie de iteraciones en un argumento, porque sin ella decir que el diseño mejoró es apenas una opinión.

8.2 Evaluación con usuarios: las pruebas de usabilidad

Hay un dicho atribuido a Nielsen que conviene tatuarse: "Pay attention to what users do, not what they say." Las pruebas de usabilidad son el dispositivo metodológico que materializa esa máxima. Es el método por excelencia en DCU. Su esqueleto es invariante:

1. Definir objetivos. ¿Qué queremos averiguar? Una prueba de usabilidad sin pregunta es turismo etnográfico. "¿El usuario nuevo entiende que la luz cambia de color cuando el sistema lo reconoce?" es una pregunta. "¿Qué tal nuestro prototipo?" no lo es.

2. Reclutar participantes representativos. El público objetivo final, no nuestros compañeros que ya saben de qué se trata. Nielsen popularizó —y los datos del Nielsen Norman Group siguen sosteniendo— el hallazgo de que cinco usuarios bastan para detectar la gran mayoría de problemas de usabilidad en una iteración. No porque cinco sean estadísticamente suficientes, sino porque los problemas más graves son tan recurrentes que aparecen rápido. Mejor cinco rondas de cinco usuarios que una ronda de veinticinco.

3. Diseñar tareas realistas. No "haz click en el botón rojo": "Acabas de llegar a casa con las manos ocupadas y querís encender la luz del salón en un modo cómodo para leer." La tarea evoca el contexto. En ubicomp el contexto es la tarea.

4. Preparar el entorno. Laboratorio controlado vs. entorno natural (field evaluation). El laboratorio aísla variables; el campo conserva la validez ecológica. Para un sistema ubicuo, donde el ambiente físico es parte de la interacción, los estudios de campo cobran un peso especial. No es lo mismo probar un sensor de gestos en una sala silenciosa con luz controlada que en una cocina con niños y ruido.

5. Facilitar sin contaminar. El moderador guía, anima al think-aloud, no rescata. Cada vez que el moderador dice "haz click acá" mata un dato.

6. Recopilar. Observaciones, métricas, satisfacción. Audio, video, notas, logs.

7. Analizar. Buscar patrones, no anécdotas aisladas. Un usuario que se confunde es un dato; tres que se confunden en el mismo punto son un problema.

La Fig. 9.8 resume el protocolo en sus cuatro momentos: una tarea realista, el usuario verbalizando sin censura, un observador que anota sin intervenir, y el análisis que busca temas. La regla de oro está en el tercer paso — si sientes la necesidad de explicar algo, eso ya es un hallazgo.

Think-aloud: el método más simple y más subestimado

El protocolo think-aloud —pedirle al usuario que verbalice en voz alta lo que piensa mientras interactúa— es probablemente el invento más costo-efectivo en la historia de la HCI. Casi no requiere instrumental: un participante, una tarea, una grabadora. Y entrega un flujo continuo de evidencia sobre el modelo mental del usuario.

Funciona porque pone bajo presión los golfos de Norman (cápsula 02): el golfo de ejecución —"¿qué tengo que hacer para conseguir lo que quiero?"— y el golfo de evaluación —"¿pasó lo que yo quería?"—. Cuando el usuario dice "creo que ahora debería...", ahí estás escuchando, en directo, el golfo de ejecución. Cuando dice "¿esto funcionó? No sé...", ahí estás escuchando el golfo de evaluación. En sistemas ubicuos, donde el feedback suele ser sutil o ambiguo, este segundo golfo es el problema recurrente. El think-aloud lo expone sin filtros.

8.3 Recolección de datos: observación, entrevista, cuestionario

Las pruebas de usabilidad son un dispositivo; observación, entrevistas y cuestionarios son las técnicas dentro del dispositivo. Conviene tenerlas separadas en la cabeza.

Observación directa

Mirar al usuario actuar. Suena trivial; no lo es. Hay decisiones importantes: laboratorio o campo, observador pasivo o participante, grabación o solo notas. En sistemas ubicuos la observación tiene un valor especial porque la interacción muchas veces no produce trazas explícitas (no hay click que loguear): si no la viste, no ocurrió.

Cuidado con el efecto observador: el usuario que se sabe mirado actúa distinto. Se contrarresta con sesiones más largas (la incomodidad se diluye), con cámaras discretas, con observadores que no irrumpan. Y con el clásico recordatorio: "estamos probando el sistema, no a ti". Decirlo una vez no basta; conviene repetirlo.

Entrevistas

Conversaciones dirigidas. Tres registros:

• Estructuradas: lista cerrada de preguntas idénticas para todos. Comparables, frías.
• Semi-estructuradas: guión flexible con preguntas-ancla y libertad para profundizar. El formato más útil en prototipos en fase exploratoria.
• No estructuradas: conversación abierta. Riqueza máxima, control mínimo.

Una entrevista bien hecha no busca confirmar lo que ya creemos. Busca el conflicto, la sorpresa, la respuesta que no esperábamos. Si todas las entrevistas confirman nuestra hipótesis, probablemente estamos preguntando mal.

Cuestionarios

Preguntas escritas. Para muchos usuarios, en poco tiempo, con dato cuantitativo limpio cuando se diseñan bien. Sus tres traiciones clásicas:

1. La redacción ambigua que hace que dos personas respondan a preguntas distintas con el mismo número.
2. La escala mal calibrada (Likert de 4 puntos sin punto medio fuerza una opinión; de 7 puntos puede confundir).
3. La pregunta tendenciosa que invita a una respuesta ("¿qué tan increíble te pareció el sistema?" — no).

Una salida elegante a las dos primeras es usar un cuestionario estandarizado. Lo que nos lleva a la estrella del repertorio cuantitativo en HCI.

El System Usability Scale (SUS)

La Fig. 9.9 desarma el instrumento: diez afirmaciones de polaridad alternada, escala de 1 a 5, una fórmula ponderada que produce un puntaje de 0 a 100 y los umbrales de referencia con que se interpreta. Conviene fijar uno de esos umbrales desde ya: 68 no es "aprobado raspando", es el promedio de la industria.

John Brooke publicó en 1996 el System Usability Scale en un capítulo titulado, con honestidad disarmante, "SUS - A quick and dirty usability scale". La idea era simple: un cuestionario de diez ítems, en escala Likert de 1 a 5, que un usuario puede responder en un par de minutos al final de una sesión, y que produce un único número entre 0 y 100 representando la usabilidad percibida del sistema.

Sus diez afirmaciones alternan polaridad (cinco positivas, cinco negativas, para evitar el sesgo de aquiescencia) y cubren impresiones globales: facilidad de uso, complejidad percibida, integración entre funciones, necesidad de ayuda externa, consistencia, confianza. Ejemplos: "Creo que me gustaría usar este sistema con frecuencia", "Encontré el sistema innecesariamente complejo", "Pensé que el sistema era fácil de usar".

El puntaje SUS no es un porcentaje. Es una escala con su propia distribución empírica. Jeff Sauro y James Lewis (Quantifying the User Experience, 2016) han hecho un trabajo extenso normalizando e interpretando el SUS sobre miles de estudios: un puntaje cercano a 68 corresponde aproximadamente al promedio de la industria; sobre 80 se considera bueno; por debajo de 50, problemático. La traducción al castellano del instrumento original está validada en varios estudios y se usa rutinariamente en el mundo hispanohablante.

¿Por qué es tan popular? Porque es rápido, barato, comparable. Permite trackear la mejora de un sistema a lo largo de iteraciones, comparar versiones, comparar entre sistemas. Y porque, a pesar de su simplicidad, correlaciona razonablemente bien con otras métricas de usabilidad más caras.

¿Cuáles son sus límites? Los obvios: no dice qué está mal, solo cuán mal. Diez ítems no capturan el porqué de un puntaje bajo. Por eso el SUS funciona bien acompañado de método cualitativo, no como sustituto.

8.4 Evaluar sin usuarios: heurísticas y recorrido cognitivo

Hay momentos —especialmente al principio del proyecto o cuando se evalúan iteraciones rápidas— donde traer usuarios es caro o imposible. Para esos casos existen los métodos de inspección: expertos que evalúan el sistema sin usuarios.

La evaluación heurística de Nielsen (1990, con Molich; refinada en Usability Engineering, 1993) propone que un puñado de evaluadores (idealmente entre 3 y 5) inspeccionen la interfaz contrastándola con una lista corta de principios —las famosas diez heurísticas— y reporten las violaciones detectadas. Es rápida, no requiere usuarios, y captura una buena parte de los problemas de superficie. Su debilidad es que no captura problemas de modelo mental: un experto sabe demasiado para confundirse como un novato.

El recorrido cognitivo (cognitive walkthrough) es un método complementario: el evaluador recorre paso a paso una tarea típica y, en cada paso, se pregunta si un usuario novato sabría qué hacer y entendería el feedback recibido. Es particularmente útil para sistemas dirigidos a usuarios sin entrenamiento previo —un caso frecuente en ubicomp doméstico.

Estos métodos no reemplazan la evaluación con usuarios; son un cedazo previo que filtra los problemas más groseros antes de invertir en sesiones con personas reales.

El telón de fondo: el modelo de Norman

Conviene cerrar la parte teórica regresando a la cápsula 02. La evaluación, despojada de instrumental, es un instrumento para detectar dónde se rompen los siete pasos del modelo de acción de Donald Norman (The Design of Everyday Things, 1988): el ciclo que va de la meta del usuario (Goal) a la acción ejecutada (Acting) y al Doing —la acción percibida y evaluada—. Cada problema de usabilidad que descubrimos es, mirado de cerca, una fractura en uno de esos eslabones: el usuario no formula la meta correctamente porque no sabe qué puede pedirle al sistema; o sabe qué pedir pero no encuentra cómo ejecutar la acción; o ejecuta la acción y no recibe feedback que le confirme el resultado.

Los métodos cualitativos exponen dónde se rompe el ciclo. Los métodos cuantitativos miden con qué frecuencia y con qué costo. Juntos, dan la imagen completa.

Aprendizaje activo

En clase abrimos el espacio para Actividad 8 — Usability Speed-Test. Cada equipo va a montar, en sesenta minutos, una mini-evaluación mixta sobre el prototipo que viene construyendo. La estructura es deliberadamente apretada:

• Diez minutos para preparar la sesión: definir cómo se va a presentar el prototipo a un "usuario externo" (un compañero de otro grupo), describir un escenario realista —no una tarea abstracta— y formular una o dos preguntas de evaluación concretas. Sin pregunta no hay evaluación: hay un paseo.
• Quince minutos para diseñar el método mixto: elegir al menos una técnica cualitativa —típicamente think-aloud, entrevista semi-estructurada breve, o observación con notas— y al menos una técnica cuantitativa —un cuestionario corto inspirado en el SUS, un conteo de intentos, un ranking de funcionalidades—. La consigna es deliberada: no estás obligado a usar Google Forms, no estás obligado a medir tiempos. Lo importante es que ambas técnicas hablen entre sí.
• Veinte minutos para correr la sesión con 2-3 usuarios reclutados de otros grupos. Una introducción breve ("estamos probando el sistema, no a ti"), la interacción con think-aloud o lo que hayan elegido, y el feedback post-interacción. Documentar todo: notas, citas textuales, números crudos.
• Quince minutos para análisis, síntesis y reporte. La parte más difícil. Releer los apuntes, buscar patrones y no anécdotas, cruzar lo cualitativo con lo cuantitativo (un puntaje bajo en "facilidad de uso" se vuelve interpretable cuando una entrevista revela el porqué). Cerrar con un reporte de una página: objetivo, metodología, 2-3 insights clave, problema crítico identificado, recomendación concreta.

El entregable no es una diapositiva: es un documento sintético que debería poder leerse en dos minutos y dejar claro qué encontraron, por qué importa, qué van a cambiar en la próxima iteración.

Cada vez que un sistema desaparece en el ambiente, alguien sigue pagando la cuenta de su comodidad. Esta cápsula es sobre quién paga, con qué moneda, y cómo diseñar para que esa cuenta sea, por lo menos, visible.

Hay un momento incómodo que casi todo diseñador de sistemas ubicuos termina enfrentando. Pasa cuando uno mira el prototipo terminado — la cámara discreta sobre la pizarra, el sensor que escucha la habitación, el wearable que cuenta los pasos — y se da cuenta de que la pregunta interesante ya no es ¿funciona? sino ¿debería existir?. Las cápsulas anteriores trataron de hacer que la tecnología funcionara mejor: más sensible al contexto, más natural en el gesto, más cómoda al cuerpo, más robusta en el prototipo. Esta cápsula trata de la otra mitad del oficio: la que se pregunta a qué costo. Porque cada decisión de diseño que toma un sistema ubicuo es también una decisión política, ergonómica y ética, aunque el diseñador no la haya planteado en esos términos.

La unidad cierra el ciclo teórico del curso por una razón pedagógica precisa: solo se puede discutir seriamente sobre privacidad, vigilancia o sesgo cuando uno ya entiende cómo se construyen las cosas. Antes de eso, la discusión ética suena a panel de ONG. Después de haber prototipado, sensorizado, evaluado heurísticas y peleado con la fatiga del brazo en una interacción mid-air, las preguntas éticas dejan de ser abstractas. Se vuelven decisiones de diseño concretas, con costos reales.

La seguridad como problema de interacción, no de criptografía

La intuición popular dice que la seguridad informática es un asunto técnico: claves más largas, protocolos cifrados, hashes irrompibles. Esa intuición no está equivocada — está incompleta. La mayoría de los incidentes de seguridad documentados en las últimas dos décadas no se originan en una falla criptográfica, sino en una falla de interacción. El usuario hizo clic donde no debía, ignoró una advertencia que se mostraba demasiado seguido, compartió una contraseña porque la política exigía cambiarla cada quince días, o instaló un certificado falso porque la interfaz no le permitía distinguirlo del verdadero. El eslabón débil, dicen los manuales, es el humano. Pero esa frase es engañosa: el eslabón débil no es la persona, es la decisión de diseño que puso a esa persona en una situación imposible.

La definición que sintetiza el campo de la Usable Security la propusieron Garfinkel y Spafford:

Un computador es seguro si puedes confiar en que él y su software se comporten como tú esperas. — Garfinkel & Spafford

Lo notable de la frase es que la palabra clave no es seguro — es esperas. Si la interfaz no te permite formar expectativas correctas sobre lo que el sistema hace, no hay criptografía que te salve. El paper canónico que demostró esto fue Why Johnny Can't Encrypt (Whitten y Tygar, 1999): tomaron PGP 5.0, una herramienta criptográficamente sólida, y mostraron que usuarios técnicamente competentes no podían usarla correctamente — enviaban mensajes en claro, cifraban con la clave equivocada, no podían distinguir un mensaje firmado de uno simplemente recibido. PGP era seguro en el sentido matemático y absolutamente inseguro en el sentido humano. Veintiséis años después, el problema sigue siendo el mismo.

La perspectiva de HCI invierte la premisa habitual. Donde la ingeniería de seguridad clásica trata al usuario como adversario potencial — alguien que va a equivocarse y debe ser restringido — la perspectiva HCI lo trata como participante consciente: alguien que mantiene la seguridad si la interfaz le da el lenguaje, la visibilidad y el control para hacerlo. Sasse, Brostoff y Weirich (2001) lo formularon en un título que se volvió consigna: Transforming the weakest link. La hipótesis: la seguridad y la usabilidad no son antagónicas. Un sistema más predecible, más controlable y más comprensible es a la vez más seguro y más usable. Lo opuesto — la seguridad por opacidad, por confirmaciones repetidas, por permisos enterrados en menús de tres niveles — produce usuarios que aprenden a saltarse las protecciones, no a respetarlas.

Los diez principios de Ka-Ping Yee

En 2002 Ka-Ping Yee publicó User Interaction Design for Secure Systems, un texto breve que organiza el espacio en diez principios. No son reglas mecánicas — son ejes a lo largo de los cuales se puede evaluar si una interfaz facilita o entorpece el comportamiento seguro. Vale la pena recorrerlos no como lista, sino como mapa.

Antes de entrar en los diez principios conviene ver hacia dónde apuntan todos juntos: la Fig. 10.1 resume los cinco compromisos del privacy by design aplicados a lo ubicuo, y deja claro que ninguno de los cinco es una cláusula legal — los cinco son decisiones de diseño que se toman antes de escribir la primera línea de código.

Camino de menor resistencia. El comportamiento por defecto debe ser el comportamiento seguro. Los usuarios economizan esfuerzo — no por flojera, sino porque la atención es un recurso finito. Si la opción segura está a tres clics y la opción riesgosa a uno, no importa cuántas advertencias intercale: la gente elegirá un clic. Diseñar bien significa invertir esa asimetría.

Límites apropiados. Los permisos deben agruparse en unidades que tengan sentido para el usuario, no en unidades que tengan sentido para el programador. Usar la cámara es un permiso conceptualmente claro; acceder al driver v4l2 con flag de captura de buffer en modo raw no lo es. Los permisos demasiado granulares abruman; los demasiado amplios entregan más autoridad de la necesaria. El equilibrio se llama coarse enough to understand, fine enough to matter.

Autorización explícita. Por defecto, nadie tiene permisos. La autoridad se otorga, no se asume. Es lo opuesto al modelo opt-out en el que muchas aplicaciones se instalan con todo activado.

Visibilidad. El estado actual de la seguridad debe ser legible. El indicador del macOS que muestra cuándo la cámara está activa, el LED del Raspberry Pi que parpadea cuando el micrófono captura — son ejemplos minúsculos pero pedagógicamente claves. Un permiso invisible es, en la práctica, un permiso involuntario.

Revocabilidad. Lo que se otorgó, se puede quitar. Sin fricción, sin laberinto. Cerrar sesión en todos los dispositivos, eliminar mis datos, revocar el acceso de esta app — estas opciones deben existir y deben ser encontrables.

Capacidad esperada. La interfaz no debe prometer lo que el sistema no puede cumplir. Si una acción es irreversible, decirlo. Si un permiso no se puede revocar, advertirlo antes.

Identificabilidad. Lo igual debe verse igual, lo distinto debe verse distinto. Es el principio Gestalt aplicado a la seguridad: la diferencia entre un sitio https legítimo y uno phishing tiene que ser visualmente discriminable, no estar escondida en el detalle de un ícono.

Expresividad. La interfaz debe darle al usuario un lenguaje para articular la política que quiere implementar. Si yo quiero compartir un archivo con lectura para mi colega y escritura para mi coautor, la interfaz debe permitirme decir eso. Si me obliga a compartir con todos o con nadie, no es que esté siendo simple — está siendo coercitiva.

Claridad. Sin jerga, sin ambigüedad, sin advertencias genéricas que el usuario aprende a despachar con un clic automático.

Rendición de cuentas. Debe ser posible reconstruir quién hizo qué. Logs comprensibles, auditoría, identidad verificable cuando importa.

La belleza de estos diez principios es que ninguno es revolucionario en aislamiento. Lo revolucionario es asumir que la seguridad es diseño de interacción, no un parche que se le pega encima.

El cuerpo en el ambiente: ergonomía ubicua

La discusión cambia de registro cuando pasamos de la seguridad informática a la ergonomía. Aquí el problema no es quién accede a qué datos, sino qué le pasa al cuerpo y a la mente del usuario después de cien horas de uso. Y los sistemas ubicuos introducen formas de fatiga que las interfaces de escritorio nunca tuvieron que considerar.

El caso más documentado es el Gorilla Arm — el síndrome que aparece cuando un usuario tiene que mantener el brazo en el aire para interactuar mediante gestos. Hincapié-Ramos y colegas (CHI 2014) propusieron una métrica para cuantificarlo, Consumed Endurance, midiendo el costo metabólico de una postura mid-air sostenida. El hallazgo fue contundente: interacciones que en una demo de tres minutos parecen mágicas se vuelven insostenibles después de quince. El cuerpo no fue diseñado para mantener un brazo a noventa grados durante una jornada laboral. Cualquier sistema ubicuo que requiera gestos prolongados — sin un descanso periódico, sin un anclaje en una superficie, sin un fallback al toque — está diseñando para una demo, no para un uso real.

Hay variantes menos visibles. El Fat Thumb describe el costo de operar pantallas táctiles pequeñas con un dedo que es geométricamente más grueso que los targets que debe tocar — produce tensión repetitiva en la articulación. El peso y ajuste de unas gafas AR sobre el puente nasal, replicado a lo largo de una sesión de dos horas, produce dolores que ningún test usability detecta en una primera sesión. La portabilidad y la comodidad están en tensión perpetua: hacer un dispositivo más pequeño suele hacerlo menos cómodo de operar, y viceversa.

La ergonomía cognitiva es la otra mitad del cuadro. Las interfaces ubicuas — y especialmente las que superponen información sobre el mundo real, como AR — pueden saturar la atención del usuario hasta el punto en que el rendimiento se degrada. Mark Weiser hablaba de calm technology: tecnología que informa sin demandar, que vive en la periferia y reclama el centro solo cuando importa. La promesa era hermosa; la práctica, treinta y cinco años después, está saturada de notificaciones que pelean por la atención como ofertas de almacén. La ergonomía cognitiva es, en este sentido, un problema de diseño de información, no solo de postura.

Y luego está la ergonomía ambiental: el hecho banal de que estos sistemas se usan en movimiento, bajo el sol, en el metro, con un guante puesto, con las manos mojadas. Las interfaces que asumen condiciones de laboratorio fracasan en la calle. Un buen diseño ubicuo es un diseño que sobrevive a sus condiciones reales de uso, no a las del usability lab.

La ética ubicua: cuando el ambiente recuerda

Llegamos al núcleo más incómodo de la unidad. Los sistemas ubicuos no son neutros — no porque sus diseñadores sean malintencionados, sino porque la arquitectura de un sistema que recopila datos contextuales de forma constante tiene consecuencias éticas que ningún uso individual permite mitigar.

Helen Nissenbaum lo formuló en Privacy in Context (2010) con una intuición que cambió el debate: la privacidad no es secreto, es integridad contextual. La información que comparto con mi médico es la misma información, pero si circula al supermercado o al empleador, lo que se viola no es el secreto — se viola la norma de qué información fluye en qué contexto, hacia qué destinatarios, bajo qué condiciones. Un sistema ubicuo que recoge datos en un contexto (por ejemplo, mi gimnasio) y los reutiliza en otro (mi seguro de salud) puede no haber roto ninguna promesa explícita y aún así haber destruido la confianza que hacía posible el primer contexto. La privacidad, en esta lectura, es una propiedad relacional. No se protege con consentimiento general — se protege con normas de flujo informacional.

La distancia entre un sistema atento y uno invasivo se puede recorrer rasgo por rasgo, y la Fig. 10.2 la enfrenta punto por punto. Lo incómodo del cuadro es que ninguna de las seis diferencias, tomada por separado, parece grave: se llega a la vigilancia por acumulación de decisiones razonables.

Marc Langheinrich, en su paper fundacional Privacy by Design — Principles of Privacy-Aware Ubiquitous Systems (UbiComp 2001), tradujo esa intuición a principios de ingeniería para sistemas ubicuos específicamente. Sus principios siguen siendo el punto de partida obligatorio: notice (el usuario debe saber qué se recoge), choice and consent (debe poder decidir), anonymity and pseudonymity (cuando es posible, los datos deben desidentificarse), proximity and locality (procesar localmente antes que enviar a la nube), adequate security (la seguridad como prerrequisito ético, no como característica adicional) y access and recourse (poder consultar y disputar lo que el sistema sabe de uno). La lista no envejeció. La práctica industrial, en cambio, sí — y mayoritariamente en la dirección contraria a la que Langheinrich anticipó.

Shoshana Zuboff, en The Age of Surveillance Capitalism (2019), llevó la discusión al terreno político. Su tesis es que la computación ubicua, combinada con el modelo de negocio publicitario, produjo una economía donde el excedente conductual — los datos que se generan como subproducto de cualquier interacción — se ha vuelto materia prima de un mercado de predicciones sobre comportamiento humano. No es paranoia: es el modelo de negocio explícito de varias de las empresas más grandes del mundo. La pregunta para un diseñador de sistemas ubicuos no es si su prototipo, en isolation, viola la privacidad. La pregunta es si, al entrar en un ecosistema, alimenta una infraestructura que la viola en agregado. El diseño individual es, también, una decisión sobre el ecosistema que ayuda a construir.

Hay un tercer eje que no se puede esquivar: el sesgo algorítmico. Los sistemas que aprenden de datos del mundo real reproducen — y a menudo amplifican — los sesgos presentes en esos datos. Un detector de atención en un aula, entrenado con un conjunto de rostros mayoritariamente blanco, fallará sistemáticamente con estudiantes afrodescendientes. Un sistema de reconocimiento de voz entrenado con hablantes urbanos no entenderá a quien tiene acento del sur de Chile. Estos no son bugs — son las consecuencias estadísticas de qué datos se eligieron, y de qué problemas se decidió optimizar. La equidad algorítmica es un problema de diseño, no un parche de post-procesamiento.

La Fig. 10.3 traza el recorrido completo de ese sesgo: datos que no representan a todos, un modelo que optimiza el promedio, una decisión que discrimina y un daño que resulta invisible para quien diseñó el sistema — precisamente porque él sí estaba en el promedio.

Y queda la pregunta más espinosa: la autonomía. Los sistemas que se adaptan al usuario — que aprenden sus preferencias, anticipan sus necesidades, ajustan su comportamiento — están operando, inevitablemente, sobre la frontera entre asistencia y manipulación. Un sistema que me recomienda el mejor camino al trabajo es asistencia. Un sistema que aprende cuándo es más probable que compre algo y me lo ofrece en ese instante es algo distinto. La distinción no siempre es nítida; el diseño es lo que la traza, y el diseñador es responsable de dónde la traza.

La tensión que el curso evalúa

La prueba teórica del curso pide examinar críticamente la afirmación de que la visión de Mark Weiser sobre tecnología serena fracasó rotundamente — que en lugar de calma trajo vigilancia, en lugar de invisibilidad trajo opacidad, en lugar de liberación cognitiva trajo gestión tecnológica constante. La crítica no es injusta. Pero tampoco es completa. Las cápsulas anteriores enseñaron a diseñar sistemas que respondan al ambiente; esta cápsula recuerda que responder al ambiente es también vigilar el ambiente, y que el mismo gesto técnico — un sensor que escucha la habitación — sostiene tanto la calma weiseriana como la cacofonía de la economía del dato. La diferencia no está en el sensor: está en el contrato social, técnico y ético que rodea su uso.

El ensayo individual del curso pide articular esta tensión en 750-850 palabras, anclada en las experiencias prácticas del semestre — el prototipo del Prototype-Jam, la violación heurística detectada en Urgencias Heurísticas, los datos recolectados en Hackea tu Smartphone, y el debate del Comité de Impacto que esta cápsula prepara. La unidad no es accesoria al curso — es el lente final con el que se relee todo lo anterior.

Aprendizaje activo

La Actividad 9 — Comité de Impacto convierte estos principios en práctica viva. El caso de estudio es uno real: la Universidad Innovación Digital decide instalar un sistema de smart-camera en todas sus aulas. El sistema promete tres funciones — detección de atención de estudiantes, gestión de seguridad y ocupación, ajuste automático de iluminación y climatización — y declara que el procesamiento es local, que los metadatos son anónimos, y que los videos brutos se eliminan a las 24 horas.

El grupo se reparte en tres roles. La Defensa argumentará a favor: cómo los principios de Yee se cumplen, cómo la propuesta optimiza el aprendizaje sin sacrificar derechos, qué salvaguardas son suficientes. La Crítica atacará por la otra orilla: qué datos se recolectan más allá de lo declarado, qué inferencias se pueden hacer a partir de patrones de atención, qué sesgos podría introducir el sistema de visión por computador, qué pasa con el consentimiento del estudiante que entra al aula sin alternativa real de no ser observado, qué normas de integridad contextual (Nissenbaum) se están reordenando sin discusión. La Moderación facilita el debate, vigila los tiempos y redacta las recomendaciones consensuadas que el grupo entregará.

No es un ejercicio retórico. Es un entrenamiento en el músculo ético que un profesional ubicuo va a usar la primera semana de su primer trabajo, cuando alguien — un cliente, un jefe, un comité — le pida diseñar exactamente este sistema. Y necesitará tener formada la pregunta antes de tenerla que responder en serio.

El futuro no llega de golpe. Se filtra, se acomoda en los rincones, y un día nos damos cuenta de que ya estaba aquí.

Llegamos al final de un recorrido que empezó hace quince cápsulas con Mark Weiser sentado en Xerox PARC, escribiendo a mano una frase que iba a definir el resto del siglo: "las tecnologías más profundas son las que desaparecen". Desde entonces hemos atravesado heurísticas, prototipos, sensores, evaluaciones y comités de ética. Toca ahora la pregunta más difícil del curso: ¿hacia dónde va todo esto? No la respuesta de feria tecnológica, sino la respuesta sobria, anclada en lo que la investigación HCI documenta hoy. Esta cápsula es una mirada hacia adelante con los pies puestos en el suelo.

Casos que ya están en el aula

Antes de proyectar a diez años, conviene mirar lo que ya existe y funciona. Hemos visto sistemas a lo largo del curso, pero conviene reagruparlos como casos paradigmáticos porque cada uno encarna una forma distinta de habitar la computación ubicua.

AmbiGaze resuelve un problema viejo del eye-tracking: el "toque de Midas", esa maldición de que todo lo que miras se selecciona. La solución es elegante. Cada dispositivo del entorno —una lámpara, un ventilador, una persiana— se anima con un patrón de movimiento único. El usuario lo selecciona persiguiéndolo con la mirada (smooth pursuit) y el sistema, por correlación, sabe qué eligió. No hay calibración. No hay menú. Hay un mundo de objetos que se mueven discretamente y un ojo que decide. Es Weiser puro: la interfaz se diluye en el ambiente.

Electrick convierte cualquier superficie conductora en pantalla táctil. Pintas una mesa con pintura de carbono, pones electrodos en el perímetro, y el sistema infiere el toque por tomografía de campo eléctrico. La consecuencia práctica es enorme: muebles, juguetes, paredes enteras se vuelven interfaz. La consecuencia conceptual es más fina: derriba la última frontera entre "pantalla" y "mundo".

Zensors llevó la idea aún más lejos. ¿Por qué instalar sensores específicos para cada pregunta cuando ya hay cámaras en todas partes? Apunta una cámara, escribe una pregunta en lenguaje natural —"¿hay cola en la cafetería?"— y el sistema combina visión por computador, machine learning y crowdsourcing para responderla. Con el tiempo aprende a responder solo. Es el sueño del "sensor de propósito general", y prefigura mucho de lo que la IA generativa está empezando a hacer hoy.

Orbits y Whoosh son la dupla más juguetona. El smartwatch tiene una pantalla minúscula, así que en lugar de seguir miniaturizando botones, cambian de modalidad. Orbits usa mirada y smooth pursuit; Whoosh usa soplidos de distinta forma y dirección como vocabulario de comandos. Si modificas la carcasa con un Flutecase impreso en 3D, amplías el repertorio acústico. Son interacciones imposibles en un mouse y triviales en el cuerpo.

Estos cuatro casos no son ciencia ficción: están publicados en CHI, UIST y revistas de HCI desde hace una década o más. Importan porque trazan los vectores: mirada, tacto distribuido, lenguaje natural sobre sensores existentes, modalidades acústicas y corporales. Cada vector tiene un horizonte de diez años por delante.

La Fig. 11.1 reúne las seis líneas que están moviendo el campo en esta década, cada una con evidencia ya publicada. Al mirarla vale la pena resistir la tentación de leer solo las cinco tecnológicas: la sexta —la regulación— es la que va a decidir cuáles de las otras cinco llegan efectivamente al mercado.

Context-awareness profundo: del dónde al porqué

Durante años, "context-aware" significó esencialmente "sabe dónde estás". La nueva frontera es entender qué estás haciendo y, sobre todo, qué pretendes hacer. La fusión de sensores —acelerómetros, cámaras, micrófonos, fisiología, calendario, comunicaciones— permite inferir actividades cada vez más finas. La investigación apunta a tres capas progresivas: contexto físico (ubicación, hora, dispositivos), contexto de actividad (qué haces) y contexto de intención (qué quieres lograr en los próximos minutos u horas).

Esta última capa es la más interesante y la más delicada. Un sistema que infiere intenciones puede ayudarte de forma proactiva, pero también puede equivocarse de manera embarazosa o, peor, anticipar decisiones que no querías que se anticiparan. La línea entre asistencia y paternalismo se vuelve cartográficamente fina. Lo que la comunidad HCI viene insistiendo desde hace años —y conviene repetirlo aquí— es que anticipación sin transparencia es manipulación. El usuario debe saber qué se está infiriendo de él, con qué confianza, y debe poder corregirlo.

IA generativa: el momento incómodo

Desde 2022 los modelos generativos cambiaron la conversación. Ya no se trata sólo de inferir contexto sino de producir interfaces, contenidos y respuestas en tiempo real. La pregunta para UbiComp no es si la IA generativa entrará en las interfaces ubicuas —ya está entrando, en altavoces, gafas, autos, asistentes domésticos— sino cómo lo hará sin romper los principios de calm technology de Weiser.

Hay tres tensiones en juego. La primera: los LLM tienden a ser locuaces, y un sistema verdaderamente ubicuo necesita ser breve. La segunda: la generación impredecible choca con la previsibilidad que la interacción cotidiana exige (cuando aprieto el interruptor, espero que pase siempre lo mismo). La tercera: la latencia y el consumo energético de los modelos grandes son incompatibles con dispositivos que viven al margen de la atención.

La salida que la investigación está explorando es la arquitectura híbrida: modelos pequeños en el dispositivo para lo rutinario, modelos grandes en la nube para lo excepcional, y reglas deterministas en el medio para todo lo crítico. Es menos elegante que "todo IA" pero es lo que la disciplina HCI dicta cuando se toma en serio la fiabilidad.

Ecosistemas multi-dispositivo: el handoff sin fricción

Hoy tienes un teléfono, un computador, una TV, un reloj, un altavoz, un auto, una pulsera y, si tienes suerte, unas gafas inteligentes. Mañana tendrás todo eso más sensores de presencia, pantallas ambientales y objetos cotidianos enriquecidos. La pregunta de diseño ya no es "qué hace este dispositivo" sino "cómo se coordinan todos cuando estoy haciendo una sola tarea".

El concepto clave es handoff: la tarea que empezaste en el teléfono debe poder continuar en el laptop, mudarse a la TV cuando llegas al living, y volver al reloj cuando sales a caminar. Apple lo viene empujando hace años con Continuity; el resto del ecosistema está aún fragmentado. La investigación HCI propone marcos teóricos —device ecology, cross-device interaction, proxemic computing de Saul Greenberg— y prototipos donde el descubrimiento de dispositivos es inmediato, el contenido fluye y las interfaces se redistribuyen según la postura del usuario y la proximidad. Lo difícil no es la sincronización técnica: es decidir, en cada momento, qué dispositivo merece la atención.

Nuevas modalidades: cerebro, olfato, gusto, piel

El catálogo de modalidades de entrada y salida sigue creciendo. Tres frentes merecen atención porque están entrando del laboratorio al producto.

Interfaces cerebro-computadora (BCI). Hay dos escuelas. La invasiva —Neuralink y similares— implanta electrodos en la corteza y trabaja con pacientes con condiciones específicas. La no invasiva —OpenBCI, Muse, Emotiv— usa EEG superficial y consigue señales más ruidosas pero éticamente más asequibles. Para UbiComp lo relevante son las BCI no invasivas integradas en wearables: detectar estados atencionales, niveles de carga cognitiva, frustración o calma para que el ambiente se adapte. Es la promesa de la passive BCI, donde el cerebro no manda comandos sino que informa estado.

Olfato y gusto digitales. La investigación lleva décadas tropezando aquí. Hay prototipos de dispositivos que emiten secuencias controladas de moléculas (Aromajoin, Olorama) y otros que estimulan eléctricamente la lengua para evocar sabores (los trabajos de Nimesha Ranasinghe en Singapur). Está lejos de ser cotidiano. Pero los casos de uso son nítidos: ambient memory triggers, accesibilidad para personas con anosmia post-COVID, experiencias inmersivas. Aún no es producto, es horizonte.

Háptica avanzada y comunicación táctil. Lo más maduro del lote. Los actuadores ultrasónicos sin contacto (Ultraleap), las matrices de pines, los wearables con vibración localizada o térmica permiten transmitir información por la piel sin saturar oído ni vista. Para sistemas calm —que no quieren interrumpir— la piel es la modalidad obvia. Hiroshi Ishii viene defendiendo desde su manifiesto de Radical Atoms (2012) que los bits deben encarnar materia y la materia debe responder. Su laboratorio en el MIT Media Lab —el Tangible Media Group— sigue produciendo prototipos donde la superficie misma se deforma para mostrar información.

El salto de esa háptica hacia la lectura directa de señal cerebral es el que más titulares genera y el que conviene mirar con más calma. La Fig. 11.2 muestra el tipo de equipo que sacó el EEG del laboratorio clínico —portable, de electrodo seco, y con una resolución muy inferior a la clínica—, y la Fig. 11.3 detalla la cadena completa que va de esa señal a una respuesta del entorno. Nótese, para la discusión ética que viene después, que lo que se infiere es un estado —foco, fatiga, intención— y no un pensamiento.

Computación neuromórfica y edge AI

Una tendencia menos visible pero estructural: el desplazamiento del cómputo desde la nube hacia el borde. La nube tiene problemas de latencia, privacidad y dependencia de conectividad. La respuesta es edge AI: chips diseñados para correr modelos en dispositivos pequeños con poco consumo.

Aquí entra la computación neuromórfica, un paradigma inspirado en cómo el cerebro procesa información mediante "spikes" en lugar de operaciones síncronas. Chips como Loihi de Intel o Akida de BrainChip prometen consumos órdenes de magnitud menores para tareas de inferencia, en particular sobre datos sensoriales temporales. Para UbiComp esto importa porque los dispositivos verdaderamente ambientales no pueden permitirse cargar baterías ni mantener conexión permanente. La promesa es un sensor que vive con una pila de botón durante un año porque sólo despierta cuando algo relevante ocurre.

Es una promesa parcialmente cumplida, vale aclarar. La adopción comercial aún es marginal. Pero la dirección está clara: cómputo más cerca del sensor, modelos más pequeños, eficiencia energética como criterio de diseño tan importante como la precisión.

La Fig. 11.4 compara las dos arquitecturas en los seis puntos que deciden un diseño. Para un sistema ubicuo suelen pesar más la tercera y la cuarta fila —si funciona sin conectividad, si los datos salen del dispositivo— que la velocidad bruta, y ahí es donde el edge gana casi siempre.

Volver a Weiser

Conviene detenerse aquí y hacer el ejercicio honesto: ¿qué de lo que Mark Weiser escribió en 1991 se cumplió, y qué no?

Lo que acertó. Weiser dijo que la computación se distribuiría en pulgadas, pies y yardas —dispositivos personales, intermedios y ambientales—. Ese gradiente es hoy literalmente nuestra vida: reloj, teléfono, laptop, TV, sala. Acertó que la conectividad sería el sustrato invisible: el WiFi y la 5G son hoy infraestructura como lo es el agua corriente. Acertó que el cómputo abandonaría el escritorio y se incorporaría en objetos cotidianos: termostatos, lámparas, cerraduras, parlantes. Acertó, sobre todo, en la dirección del campo: la interfaz como ambiente.

Lo que no acertó —al menos no como él lo soñó. Weiser imaginó una computación calmada, que viviera "en la periferia de la atención". Lo que tenemos en cambio es una computación demandante, que pelea cada minuto por la cabeza del usuario. El smartphone es lo opuesto de calm technology: es un imán de atención diseñado para maximizar engagement. Weiser previó la ubicuidad pero no anticipó el modelo de negocio que iba a aprovecharla.

Tampoco anticipó la concentración del poder. Su visión sugería un ecosistema federado, abierto, donde dispositivos heterogéneos colaborarían por protocolos comunes. Lo que tenemos es un puñado de plataformas verticales que no hablan entre sí salvo a regañadientes. Apple, Google, Amazon, Microsoft —y en otro plano Meta y los gigantes chinos— controlan las capas críticas. La interoperabilidad sigue siendo aspiración.

Y no anticipó la dimensión política. La computación ubicua trae consigo vigilancia ambiental, perfilamiento conductual y asimetrías de poder que él, escribiendo desde el optimismo de Xerox PARC, no tematizó. Hicieron falta Genevieve Bell, Paul Dourish, Lucy Suchman y la corriente etnográfica de UbiComp para nombrar lo que la tecnología hacía socialmente. La pregunta no era ya sólo "¿cómo desaparece la interfaz?" sino "¿qué intereses se ocultan tras esa desaparición?".

Pranav Mistry, con su SixthSense de 2009, mostró que era técnicamente posible proyectar información sobre cualquier superficie con un sensor colgado del cuello. Pero el producto nunca llegó: hicieron falta otros quince años para que las gafas de realidad mixta empezaran a aproximarse a algo de eso, y todavía no resolvimos qué hacemos con ellas socialmente.

Volver a Weiser no es nostalgia. Es recordar que el norte teórico original sigue siendo válido —tecnología invisible, calmada, al servicio de la atención humana— aunque las fuerzas del mercado nos hayan empujado a otra parte.

La pregunta para uds, como futuros diseñadores, es si esa fuerza del mercado es destino o es disputa.

Ética y regulación: el cierre del paréntesis

Durante treinta años UbiComp operó en un vacío regulatorio cómodo. Eso terminó. El GDPR europeo (2016) estableció la primera arquitectura legal robusta sobre datos personales, con efectos extraterritoriales. El AI Act de la Unión Europea (2024) —el primer marco regulatorio amplio sobre inteligencia artificial— clasifica sistemas por nivel de riesgo y prohíbe directamente algunas aplicaciones (reconocimiento emocional en lugares de trabajo y centros educativos, social scoring gubernamental, identificación biométrica remota en espacios públicos salvo excepciones acotadas).

Esto tiene consecuencias prácticas para quien diseña sistemas ubicuos. Ya no basta con "es legal porque nadie nos prohibió hacerlo". Las preguntas que un comité de ética planteaba —las que vieron en la Actividad 9— son hoy también preguntas regulatorias: ¿qué datos recoges?, ¿con qué base legal?, ¿por cuánto tiempo?, ¿quién accede?, ¿cómo se borran?, ¿qué decisiones automatizadas se toman y con qué transparencia?

La buena noticia es que el campo HCI tiene herramientas: privacy by design de Ann Cavoukian, value-sensitive design de Batya Friedman, los marcos de Helen Nissenbaum sobre integridad contextual. La mala noticia es que las herramientas conviven con un mercado que premia la fricción mínima y la pregunta no preguntada. El diseñador ubicuo del 2026 tiene que vivir en esa tensión.

Estado deseado: qué nos gustaría llegar a ver en 2035

Si proyectamos diez años con honestidad —sin pirotecnia futurista pero sin cinismo—, hay un escenario plausible donde varias cosas se alinean. Dispositivos que duran años sin cargarse, con cómputo neuromórfico que sólo despierta cuando es necesario. Asistentes que entienden contexto e intención sin filtrar todo a la nube, gracias a modelos locales potentes y a aprendizaje federado. Interfaces que se redistribuyen entre los dispositivos del entorno según postura, proximidad y tarea, sin que el usuario tenga que orquestar nada. Hápticas y modalidades nuevas que carguen información sin saturar la atención. Y, ojalá, un marco regulatorio que haya internalizado las lecciones del decenio anterior, con sistemas que tengan que demostrar respeto a la autonomía como antes demostraban eficiencia.

Es plausible, no inevitable. Es lo que se decide hoy en cada laboratorio, en cada empresa, en cada aula como esta.

Aprendizaje activo

La Actividad 10 — Timeline 2025-2035 los va a poner en el asiento del que decide. En grupos elegirán un dominio —salud, transporte, educación, hogar, trabajo, comercio, entretenimiento— y proyectarán la evolución de una aplicación ubicua a lo largo de los próximos diez años. Construirán una línea de tiempo con el hito actual (2025), tres hitos intermedios (2027, 2031, 2033) y un estado deseado ambicioso pero defendible en 2035.

Pero la línea de tiempo es sólo la mitad del ejercicio. La otra mitad es el mapa de actores: ¿quién interactúa con su sistema en 2035? Usuarios, sí, pero también empresas, gobiernos, reguladores, otros sistemas, modelos de IA, comunidades afectadas. Identificar a cada actor y describir su rol obliga a pensar el sistema como ecosistema socio-técnico, no como producto aislado.

Cerrarán con un wireframe rápido de la interfaz clave en 2035. No diseño gráfico, estructura: ¿cómo se ve el sistema en uso?, ¿qué hace visible y qué deja invisible?, ¿cómo refleja —o se aleja de— los principios ubicuos que vimos a lo largo del semestre? La exposición será en formato Pecha-Kucha: 3-4 diapositivas, 20 segundos cada una, condensación brutal. Es el ejercicio de cierre del curso: tomar todo lo aprendido y proyectarlo como visión defendible.

1. Aarts, E., & Marzano, S. (Eds.). (2003). The New Everyday: Views on Ambient Intelligence. 010 Publishers.
2. Atzori, L., Iera, A., & Morabito, G. (2010). The Internet of Things: A survey. Computer Networks, 54(15), 2787-2805.
3. Baronti, P., Pillai, P., Chook, V. W., Chessa, S., Gotta, A., & Hu, Y. F. (2007). Wireless sensor networks: A survey on the state of the art and the 802.15.4 and ZigBee standards. Computer Communications, 30(7), 1655-1695.
4. Beaudouin-Lafon, M., & Mackay, W. E. (2012). Prototyping tools and techniques. In J. A. Jacko (Ed.), The Human-Computer Interaction Handbook: Fundamentals, Evolving Technologies, and Emerging Applications (3rd ed., pp. 1043-1066). CRC Press.
5. Bell, G., & Dourish, P. (2007). Yesterday's tomorrows: notes on ubiquitous computing's dominant vision. Personal and Ubiquitous Computing, 11(2), 133-143.
6. Bellino, A. (2018). SEQUENCE: a remote control technique to select objects by matching their rhythm. Personal and Ubiquitous Computing, 22(4), 751-770.
7. Bellino, A. (2025). Unlocking design spaces: Web-based interactive prototyping by repurposing everyday devices. SSRN Working Paper 5259499.
8. Bellino, A., & Bascuñán, D. (2020). Design and evaluation of WriteBetter: A corpus-based writing assistant. IEEE Access, 8, 70216-70233.
9. Bellino, A., De Michelis, G., & De Paoli, F. (2023). Design and evaluation of Protobject: a tool for rapid prototyping of interactive products. IEEE Access, 11, 13280-13292.
10. Bellino, A., & Herskovic, V. (2019). CameraKeyboard: A novel interaction technique for text entry through smartphone cameras. IEEE Access, 7, 167982-167996.
11. Bellino, A., & Herskovic, V. (2023). Protobject as a tool for teaching computational thinking to designers: student perceptions on usability. Proceedings of the 15th Biannual Conference of the Italian SIGCHI Chapter, 1-8.
12. Bellino, A., & Rocchesso, D. (2024). SoundOrbit: motion-correlation interaction with auditory orbital trajectories. Personal and Ubiquitous Computing, 28(5), 763-778.
13. Boring, S., Ledo, D., Chen, X. A., Marquardt, N., Tang, A., & Greenberg, S. (2012). The fat thumb: Using the thumb's contact size for single-handed mobile interaction. MobileHCI '12: Proceedings of the 14th International Conference on Human-Computer Interaction with Mobile Devices and Services, 39-48.
14. Brooke, J. (1996). SUS: A "quick and dirty" usability scale. In P. W. Jordan, B. Thomas, B. A. Weerdmeester, & I. L. McClelland (Eds.), Usability Evaluation in Industry (pp. 189-194). Taylor & Francis.
15. Buxton, B. (2007). Sketching User Experiences: Getting the Design Right and the Right Design. Morgan Kaufmann.
16. Cavoukian, A. (2009). Privacy by Design: The 7 Foundational Principles. Information and Privacy Commissioner of Ontario.
17. Center for Universal Design. (1997). The Principles of Universal Design (Version 2.0). North Carolina State University. (Redactados por B. R. Connell, M. Jones, R. Mace, J. Mueller, A. Mullick, E. Ostroff, J. Sanford, E. Steinfeld, M. Story y G. Vanderheiden.)
18. Chile. (2017). Ley 21.015: Incentiva la inclusión de personas con discapacidad al mundo laboral. Diario Oficial de la República de Chile.
19. Clarke, C., Bellino, A., Esteves, A., & Gellersen, H. (2017). Remote control by body movement in synchrony with orbiting widgets: An evaluation of TraceMatch. Proceedings of the ACM on Interactive, Mobile, Wearable and Ubiquitous Technologies, 1(3), 1-22.
20. Clarke, C., Bellino, A., Esteves, A., Velloso, E., & Gellersen, H. (2016). TraceMatch: A computer vision technique for user input by tracing of animated controls. UbiComp '16: Proceedings of the 2016 ACM International Joint Conference on Pervasive and Ubiquitous Computing, 298-303.
21. Clarke, C., & Gellersen, H. (2017). MatchPoint: Spontaneous spatial coupling of body movement for touchless pointing. UIST '17: Proceedings of the 30th Annual ACM Symposium on User Interface Software and Technology, 179-192.
22. Cooper, A. (1999). The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. Sams Publishing.
23. Cooper, A., Reimann, R., Cronin, D., & Noessel, C. (2014). About Face: The Essentials of Interaction Design (4th ed.). Wiley.
24. Dourish, P. (2001). Where the Action Is: The Foundations of Embodied Interaction. MIT Press.
25. Esteves, A., Velloso, E., Bulling, A., & Gellersen, H. (2015). Orbits: Gaze interaction for smart watches using smooth pursuit eye movements. UIST '15: Proceedings of the 28th Annual ACM Symposium on User Interface Software & Technology, 457-466.
26. European Union. (2024). Regulation (EU) 2024/1689 on artificial intelligence (Artificial Intelligence Act). Official Journal of the European Union.
27. Gomez, C., Oller, J., & Paradells, J. (2012). Overview and evaluation of Bluetooth Low Energy: An emerging low-power wireless technology. Sensors, 12(9), 11734-11753.
28. Greenberg, S., & Fitchett, C. (2001). Phidgets: Easy development of physical interfaces through physical widgets. UIST '01: Proceedings of the 14th Annual ACM Symposium on User Interface Software and Technology, 209-218.
29. Greenfield, A. (2006). Everyware: The Dawning Age of Ubiquitous Computing. New Riders.
30. Hart, S. G., & Staveland, L. E. (1988). Development of NASA-TLX (Task Load Index): Results of empirical and theoretical research. In P. A. Hancock & N. Meshkati (Eds.), Human Mental Workload (pp. 139-183). North-Holland.
31. Houde, S., & Hill, C. (1997). What do prototypes prototype? In M. Helander, T. Landauer, & P. Prabhu (Eds.), Handbook of Human-Computer Interaction (2nd ed., pp. 367-381). Elsevier.
32. Ishii, H., Lakatos, D., Bonanni, L., & Labrune, J.-B. (2012). Radical atoms: beyond tangible bits, toward transformable materials. interactions, 19(1), 38-51.
33. Ishii, H., & Ullmer, B. (1997). Tangible bits: towards seamless interfaces between people, bits and atoms. CHI '97: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 234-241.
34. Kaltenbrunner, M., Jordà, S., Geiger, G., & Alonso, M. (2006). The reacTable: A collaborative musical instrument. WETICE '06: 15th IEEE International Workshops on Enabling Technologies*, 406-411.
35. Krumm, J. (Ed.). (2009). Ubiquitous Computing Fundamentals. CRC Press.
36. Kuniavsky, M. (2010). Smart Things: Ubiquitous Computing User Experience Design. Morgan Kaufmann.
37. Langheinrich, M. (2001). Privacy by design — Principles of privacy-aware ubiquitous systems. In G. D. Abowd, B. Brumitt, & S. Shafer (Eds.), Ubicomp 2001: Ubiquitous Computing, LNCS 2201, 273-291.
38. Laput, G., Lasecki, W. S., Wiese, J., Xiao, R., Bigham, J. P., & Harrison, C. (2015). Zensors: Adaptive, rapidly deployable, human-intelligent sensor feeds. CHI '15: Proceedings of the 33rd Annual ACM Conference on Human Factors in Computing Systems, 1935-1944.
39. Laput, G., Yang, C., Xiao, R., Sample, A., & Harrison, C. (2015). EM-Sense: Touch recognition of uninstrumented, electrical and electromechanical objects. UIST '15: Proceedings of the 28th Annual ACM Symposium on User Interface Software & Technology, 157-166.
40. Laput, G., Zhang, Y., & Harrison, C. (2017). Synthetic sensors: Towards general-purpose sensing. CHI '17: Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems, 3986-3999.
41. Lewis, J. R. (2018). The System Usability Scale: Past, present, and future. International Journal of Human-Computer Interaction, 34(7), 577-590.
42. Mace, R. L. (1985). Universal design: Barrier-free environments for everyone. Designers West, 33(1), 147-152.
43. Malacria, S., Lecolinet, E., & Guiard, Y. (2010). Clutch-free panning and integrated pan-zoom control on touch-sensitive surfaces: The CycloStar approach. CHI '10: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 2615-2624.
44. Mistry, P., & Maes, P. (2009). SixthSense: A wearable gestural interface. SIGGRAPH ASIA '09: ACM SIGGRAPH ASIA 2009 Art Gallery & Emerging Technologies, 85.
45. Nielsen, J. (1993). Usability Engineering. Academic Press. (Reimpreso por Morgan Kaufmann.)
46. Nielsen, J. (1994). Enhancing the explanatory power of usability heuristics. CHI '94: Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 152-158.
47. Nissenbaum, H. (2010). Privacy in Context: Technology, Policy, and the Integrity of Social Life. Stanford University Press.
48. Norman, D. A. (1988). The Design of Everyday Things. Doubleday. (Reedición con nuevo prefacio: Basic Books, 2013.)
49. Norman, D. A. (2004). Emotional Design: Why We Love (or Hate) Everyday Things. Basic Books.
50. Pfeuffer, K., Hinckley, K., Pahud, M., & Buxton, B. (2017). Thumb + Pen interaction on tablets. CHI '17: Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems, 3254-3266.
51. Reyes, G., Zhang, D., Ghosh, S., Shah, P., Wu, J., Parnami, A., Bercik, B., Starner, T., Abowd, G. D., & Edwards, W. K. (2016). Whoosh: Non-voice acoustics for low-cost, hands-free, and rapid input on smartwatches. ISWC '16: Proceedings of the 2016 ACM International Symposium on Wearable Computers, 120-127.
52. Rocchesso, D., Bellino, A., & Perez, A. (2023). TickTacking — Drawing trajectories with two buttons and rhythm. Proceedings of the Sound and Music Computing Conference.
53. Rogers, Y., Sharp, H., & Preece, J. (2019). Interaction Design: Beyond Human-Computer Interaction (5th ed.). Wiley.
54. Saffer, D. (2008). Designing Gestural Interfaces: Touchscreens and Interactive Devices. O'Reilly Media.
55. Sauro, J., & Lewis, J. R. (2016). Quantifying the User Experience: Practical Statistics for User Research (2nd ed.). Morgan Kaufmann.
56. Stankovic, J. A. (2014). Research directions for the Internet of Things. IEEE Internet of Things Journal, 1(1), 3-9.
57. Stephanidis, C., & Salvendy, G. (Eds.). (2024). Human-Computer Interaction in Intelligent Environments. CRC Press.
58. Suchman, L. (1987). Plans and Situated Actions: The Problem of Human-Machine Communication. Cambridge University Press. (Reeditado y expandido como Human-Machine Reconfigurations, 2007.)
59. Velloso, E., Wirth, M., Weichel, C., Esteves, A., & Gellersen, H. (2016). AmbiGaze: Direct control of ambient devices by gaze. DIS '16: Proceedings of the 2016 ACM Conference on Designing Interactive Systems, 812-817.
60. Vidal, M., Bulling, A., & Gellersen, H. (2013). Pursuits: Spontaneous interaction with displays based on smooth pursuit eye movement and moving targets. UbiComp '13: Proceedings of the 2013 ACM International Joint Conference on Pervasive and Ubiquitous Computing, 439-448.
61. Villar, N., Scott, J., Hodges, S., Hammil, K., & Miller, C. (2012). .NET Gadgeteer: A platform for custom devices. Pervasive 2012, LNCS 7319, 216-233.
62. von Zadow, U., Büschel, W., Langner, R., & Dachselt, R. (2014). SleeD: Using a sleeve display to interact with touch-sensitive display walls. ITS '14: Proceedings of the 2014 ACM International Conference on Interactive Tabletops and Surfaces, 129-138.
63. W3C. (2023). Web Content Accessibility Guidelines (WCAG) 2.2. W3C Recommendation.
64. Weiser, M. (1991). The Computer for the 21st Century. Scientific American, 265(3), 94-104.
65. Weiser, M., & Brown, J. S. (1996). Designing calm technology. PowerGrid Journal, 1(1).
66. Whitten, A., & Tygar, J. D. (1999). Why Johnny can't encrypt: A usability evaluation of PGP 5.0. Proceedings of the 8th USENIX Security Symposium, 169-183.
67. Yee, K.-P. (2002). User interaction design for secure systems. In R. Deng, F. Bao, J. Zhou, & S. Qing (Eds.), Information and Communications Security (ICICS 2002), LNCS 2513, 278-290.
68. Zhang, Y., Laput, G., & Harrison, C. (2017). Electrick: Low-cost touch sensing using electric field tomography. CHI '17: Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems, 1-14.
69. Zuboff, S. (2019). The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power. PublicAffairs.