UX más allá de la aplicación: islas, widgets, relojes e interfaces del sistema

Actualizado: 6 de noviembre de 2026.

Una buena aplicación ayuda incluso cuando su pantalla está cerrada. Una isla muestra cuándo llegará el coche. El reloj permite pausar el entrenamiento. Un widget recuerda la próxima tarea. El billete aparece junto al torno. Este artículo es un atlas práctico de esas interacciones: qué elegir, dónde funciona, cómo integrarlo y cómo evitar que un servicio útil se convierta en una fuente constante de distracciones.

Imaginad un viaje cotidiano. Una persona pide un taxi, vuelve a sus mensajes, ve la hora de llegada en la parte superior de la pantalla, recibe una señal en el reloj y sale hacia el coche. En ese tiempo utiliza vuestro producto varias veces, aunque apenas abre la aplicación. Esta es la experiencia que vamos a diseñar.

Documentación revisada al 5 de noviembre de 2026. Es una revisión de mecanismos y decisiones de diseño, no una prueba de laboratorio de todos los dispositivos. La existencia de una API, el acceso de la aplicación y la visualización real en el teléfono son tres condiciones independientes. Los ejemplos son propios y esquemáticos: explican la composición de la información, sin reproducir la interfaz de un sistema concreto. Llamaremos «superficie» al lugar de interacción: pantalla de bloqueo, widget, reloj, tarjeta del sistema o indicador físico.

1. Principio fundamental: reducir el esfuerzo, no aumentar la presencia

El cliente suele formularlo así: «Hagamos una Dynamic Island para que el usuario vea más nuestra marca». Es más útil preguntar: «¿Qué pregunta hace la persona una y otra vez a la aplicación?». Si es «cuándo llegará el repartidor», un estado compacto está justificado. Si es «no olvides nuestra suscripción», esa superficie adicional probablemente se convierta en publicidad.

Una interfaz externa tiene cuatro componentes: contexto, información útil, acción disponible y condición de desaparición. Para un taxi son esperar el coche, el ETA, contactar con el conductor y el final del viaje. Para un widget de hábitos: rutina diaria, resultado actual, marcar la tarea y poder retirar el widget. Si el equipo no puede describir estos cuatro componentes, es pronto para dibujar una cápsula.

Fórmula práctica: sacad fuera la respuesta por la que la persona vuelve a la aplicación. Pero conservad la posibilidad de abrir el historial completo, comprobar detalles y corregir errores. Una tarjeta pequeña debe acortar el camino al resultado, no ocultar la complejidad.

2. Mapa completo: de la notificación al mundo físico

Aquí, completo significa cubrir las clases de interacción. Es imposible enumerar para siempre todos los modelos, capas e integraciones de socios: cambian de forma independiente. Por eso empezaremos por categorías estables y después veremos las diferencias entre plataformas.

Otra capa la forman los banners, snackbar, toast, bottom sheet, coach mark, chat de soporte y centro de mensajes internos. Son útiles cuando la persona ya está en el producto. No deben confundirse con superficies del sistema: un botón flotante de una web no se convierte en una isla del sistema al cerrar la pestaña.

3. Cómo elegir una superficie: seis preguntas antes de diseñar

1. ¿La persona espera un cambio o busca información por iniciativa propia? Un evento importante inesperado necesita una señal. Para una consulta diaria suele bastar un widget.
2. ¿El proceso está ocurriendo ahora? Un viaje actual y una entrega dentro de tres días requieren representaciones diferentes.
3. ¿Se entiende lo esencial de un vistazo? Si hay que comparar diez parámetros, la superficie pequeña debe abrir una pantalla completa.
4. ¿Hace falta una acción? «Pausa» sirve para un control breve; «modificar un pedido complejo» suele requerir la aplicación.
5. ¿Quién más verá los datos? Pantalla de bloqueo, reloj, pantalla del coche y altavoz generan riesgos distintos de exposición.
6. ¿Qué ocurrirá sin permiso o conexión? Ese caso se diseña junto al principal, no después de recibir quejas.

Una prueba útil: retirad el logotipo del diseño. Si la interfaz deja de tener sentido, quizá se creó para dar presencia a la marca. Si quedan «en 4 minutos», «dirígete a la puerta B» o «pausar entrenamiento», habéis encontrado valor real para el usuario.

4. Live Activities y Live Updates: tarea parecida, mecanismos distintos

Apple: ActivityKit gestiona el ciclo de vida

Una Live Activity representa una tarea actual; Dynamic Island es uno de sus lugares de visualización. ActivityKit gestiona creación, actualización y finalización, mientras WidgetKit y SwiftUI definen la interfaz. Se diseñan estados diferentes: compact, minimal, expanded y pantalla de bloqueo. Los dispositivos sin isla también forman parte del caso de uso.

Los límites de duración y datos, las acciones con App Intents, las actualizaciones APNs del servidor y otras pantallas se explican en la guía práctica de Dynamic Island y Live Activities. Las capacidades de los botones en Apple Watch no pueden extrapolarse automáticamente a CarPlay.

Android: notificación semántica cuya representación decide el sistema

La aplicación describe una actividad actual y solicita la promoción de la notificación. El sistema comprueba propiedades, ajustes y disponibilidad. ProgressStyle sirve para fases; MetricStyle, para magnitudes medidas en versiones compatibles. Ni crear la notificación ni tener una versión nueva de Android garantiza una cápsula concreta.

La guía específica de Android Live Updates muestra ejemplos Kotlin, permisos, estilos, actualizaciones en segundo plano, finalización y pruebas de integraciones OEM. El caso de uso, la admisibilidad de la API y la visualización real se comprueban por separado.

Qué no debe trasladarse entre plataformas

No trasladéis los límites de Apple a Android, las reglas de Google a un canal OEM chino ni la compatibilidad de una forma a la interactividad. No prometáis un diseño idéntico píxel a píxel. Pueden compartirse el estado del pedido, el significado del texto y el comando; tamaños, botones, duración y transporte de actualizaciones siguen siendo propios de cada plataforma.

5. Fabricantes Android: mapa de acceso, no desfile de logotipos

Samsung Now Bar, Xiaomi HyperIsland, OPPO Fluid Cloud, vivo Origin Island y HONOR Magic Capsule resuelven tareas parecidas, pero no forman un SDK único. En unos casos basta un mecanismo del sistema adecuado; en otros hacen falta aprobar el caso, una plantilla específica y un canal de actualización del fabricante.

Al evaluar una integración, comprobad cuatro cosas: modelo y firmware, mercado, acceso de la aplicación concreta y caso realmente compatible. Una demostración del producto confirma una función para el usuario, pero no necesariamente una vía abierta para APK externos. En Huawei también hay que distinguir EMUI de HarmonyOS nativa.

La tabla completa de fabricantes y condiciones de integración está en la guía Android. Para Glyph Matrix y otros paneles traseros hay una investigación sobre pantallas adicionales: acceder a la isla no equivale a acceder a cualquier pantalla del dispositivo.

6. Widgets, Controls y acciones rápidas: a menudo más útiles que una isla

La isla funciona bien para un proceso limitado. El widget, para consultar información de forma habitual. La previsión, las tareas, el saldo de tiempo, la próxima reunión o el control del hogar no tienen que convertirse en una notificación permanente en directo.

Android ofrece App Widgets con distintos tamaños y tipos de interacción. Jetpack Glance permite escribir esas interfaces de forma declarativa, pero Glance no equivale a una pantalla arbitraria de Jetpack Compose: sus posibilidades y entorno son distintos. En Apple, WidgetKit reúne widgets, complicaciones y Controls; su documentación muestra dónde están disponibles esas vistas.

Diseñad el widget con cuatro estados: sin datos, datos vigentes, datos desactualizados y acción pendiente de confirmación. «Cero tareas» y «No se han podido cargar las tareas» son mensajes distintos. La hora de actualización resulta más útil que una etiqueta decorativa «Live» si no existe sincronización continua real.

Quick Settings Tile sirve para operaciones breves y repetidas: iniciar una grabación, activar un modo de la aplicación o arrancar un temporizador. En Apple, Controls y App Shortcuts pueden resolver la misma necesidad del producto. Mediante App Intents, las acciones quedan disponibles en Siri, Shortcuts, Spotlight y otros accesos del sistema.

Para un acceso directo, «Escanear documento» es mejor que «Abrir aplicación». Un interruptor debe mostrar su estado: «Grabando», «En pausa», «Sin permiso». Para un comando enviado al servidor, primero se muestra la espera y luego el resultado confirmado. Pulsar el botón todavía no significa que la puerta se haya abierto o el pedido cancelado.

Cómo crear un widget útil, en vez de una página de inicio reducida

Partid de una pregunta recurrente: «¿Qué tengo después?», «¿Qué pedido está en camino?», «¿Está apagada la luz?». Un widget pequeño debe ofrecer una respuesta principal y un siguiente paso claro. En un tamaño mayor puede añadirse contexto, pero no otra versión independiente del estado de la aplicación.

• Tareas: lista seleccionada, próximo elemento y finalización confirmada de una tarea concreta.
• Hogar inteligente: dispositivo seleccionado, vigencia del estado y comando explícito; hasta que responda el dispositivo, se muestra la espera.
• Viajes: próximo vuelo o pedido actual con acceso preciso a los detalles. Una actividad en directo puede ser más adecuada para seguir continuamente un proceso breve.
• Sesión de concentración: hora de finalización conocida y controles compatibles. La actualización del widget no debe simular un servicio de temporizador en ejecución constante.

En Apple hacen falta Widget Extension, configuración, provider y timeline con datos reales. Para que el usuario elija un objeto se usan WidgetConfigurationIntent y AppIntentTimelineProvider; para botones interactivos disponibles en la versión objetivo, App Intents. El contenedor compartido de datos entre aplicación y extensión debe estar realmente configurado. Solicitar a WidgetCenter que recargue el timeline no garantiza una hora exacta de actualización.

En Android, la implementación incluye GlanceAppWidget, receiver, metadatos del provider, tamaños y controladores de acciones. Tras guardar datos nuevos hay que solicitar por separado la actualización de la instancia correspondiente. La guía de Glance muestra la relación entre provider, datos y actualización, y SizeMode ayuda a preparar el contenido para distintos tamaños. Dos widgets pueden tener cuentas y objetos distintos; sus ajustes no deben fusionarse accidentalmente.

Comprobad adición, configuración, tamaño mínimo, redimensionado, eliminación, falta de conexión, cierre de sesión y pulsaciones repetidas. La vista previa puede usar datos didácticos; el widget real debe mostrar honestamente que no hay resultado. Una web convencional puede tener paneles útiles, pero su HTML no instala un widget de WidgetKit o Glance en la pantalla de inicio.

7. Relojes inteligentes: no son un teléfono reducido

La persona mira el reloj caminando, entrenando o con las manos ocupadas. Por eso, una integración útil empieza seleccionando información. Que la pantalla del teléfono tenga diez campos no justifica llevar diez campos a la muñeca.

Diferenciad cinco mecanismos: notificación reenviada, indicador en la esfera, tarjeta en una pila o Tile, actividad actual y aplicación independiente. El primero puede funcionar sin una aplicación propia para reloj; el último hace falta para lógica autónoma, sensores, registro de entrenamientos y acciones complejas. No prometáis autonomía solo porque una notificación del teléfono aparezca en el reloj.

En Apple Watch, una Live Activity del iPhone puede aparecer en Smart Stack, y un diseño propio de watchOS permite seleccionar mejor su contenido. Apple también explica las diferencias de navegación según exista o no una aplicación watchOS. Una complicación en la esfera resuelve una tarea todavía más breve: un indicador y un acceso claro.

Wear OS incluye aplicaciones, notificaciones, complicaciones, Tiles y widgets. Por eso es más útil consultar el mapa actual de interfaces de Wear OS que el antiguo esquema de «esfera y mosaicos». Desde Wear OS 7 están documentadas las Live Updates locales y las transferidas desde el teléfono; el fabricante también determina la transferencia y las actualizaciones excesivas pueden ocultar datos para ahorrar batería.

Garmin es un ecosistema independiente. Connect IQ distingue esferas, campos de datos, widgets, aplicaciones y proveedores de audio. Para un producto deportivo, un campo de datos propio dentro del entrenamiento habitual puede ser más útil que una aplicación independiente. Los relojes de otros fabricantes y los anillos inteligentes deben evaluarse según su SDK concreto: acceder a mediciones no implica acceder a la interfaz o a vibraciones arbitrarias.

Para un entrenamiento, un mínimo razonable es tiempo, una métrica esencial y un botón grande de pausa. Finalizar debe distinguirse de pausar y protegerse contra pulsaciones accidentales. Perder la conexión con el teléfono no debe presentar un pulso antiguo como actual: la disponibilidad del sensor, la grabación y la sincronización se describen por separado.

8. Multimedia, llamadas, conversaciones y ventanas flotantes

Estos casos ya tienen semántica propia en el sistema. Android MediaSession transmite el estado del reproductor y los comandos al sistema, auriculares, Android Auto y Wear OS. Una sesión multimedia bien implementada puede ofrecer más accesos útiles que una cápsula decorativa propia. En Apple también se usan Now Playing y los comandos remotos del sistema para reproducir contenido, sin disfrazar el reproductor de entrega.

Picture-in-Picture permite conservar un pequeño contexto visual, por ejemplo una videollamada o un videotutorial. Decidid primero si el usuario necesita realmente la imagen. Para un pódcast suelen importar más pausa y avance. Para una llamada, el estado del micrófono, la cámara y la finalización; estas acciones no pueden ser ambiguas.

Para conversar existen notificaciones con respuesta y conversation bubbles. Pero ese no es el único significado de Bubbles: Android 17 añade App Bubbles como modo de multitarea en ventanas, separado de la API de conversaciones. La aplicación debe funcionar correctamente en una ventana pequeña y redimensionable, conservar su estado y no exigir un tamaño fijo a pantalla completa.

Una superposición propia sobre otras aplicaciones es otra tecnología que requiere acceso independiente. No forma parte de la isla del sistema ni recibe sus garantías. Un servicio convencional no debería empezar por ahí: comprobad primero la superficie del sistema que corresponde a la tarea.

9. Wallet, QR y App Clips: a veces ni siquiera hace falta abrir la aplicación

Tarjetas de embarque, billetes, pases, tarjetas de fidelización y llaves digitales forman una clase independiente de interfaces. La pregunta principal es: «¿Podré pasar o utilizar el servicio?». Un recordatorio bonito no sustituye un pase válido.

Google Wallet ofrece distintas categorías de objetos digitales. En Apple, la creación y distribución de pases Wallet incluye la firma con certificado. No todos los tipos de objetos y funciones están disponibles para cualquier emisor: un billete con código y una llave digital protegida son integraciones muy diferentes.

Al diseñar un billete, comprobad el funcionamiento sin conexión, la vigencia de hora y lugar, cancelaciones, cambios y lectura real del código por un escáner. No sustituyáis la validación por una imagen estática. Para una visita puntual puede bastar una página móvil de compra, añadir el billete a Wallet y un correo de confirmación claro.

QR y NFC pueden abrir el contexto adecuado: una mesa, un aparcamiento o el alquiler de un dispositivo. En Apple, App Clip permite ofrecer una parte breve del recorrido sin instalar la aplicación completa. Requiere preparación específica y cumplir las condiciones de la plataforma. Una página móvil convencional abierta por QR es más sencilla si la tarea encaja realmente en la web.

10. Pantallas externas, coche, voz y señales físicas

Pantalla trasera: cinco contratos de software distintos

Los smartphones no plegables también pueden tener pantallas adicionales. Pero son superficies diferentes: una ventana Android convencional, una pantalla para Presentation, un área de un plegable mediante WindowAreaController, una matriz del fabricante con SDK o un panel del sistema con un conjunto limitado de tarjetas. Antes del diseño hay que determinar qué contrato está disponible para la aplicación.

Nothing tiene un Glyph Matrix Developer Kit público: visualización desde la aplicación mediante setAppMatrixFrame() y Glyph Toys independientes con su propio ciclo de vida. Ulefone Armor 30/33 Pro documenta una pantalla trasera convencional y duplicación, por lo que la primera tarea puede ser adaptar la aplicación. Las tarjetas de usuario Xiaomi y el editor de animaciones ASUS no demuestran por sí solos una API abierta para dibujar arbitrariamente.

El mismo límite se aplica a los sitios: un navegador en una segunda pantalla permite adaptar la página, pero una PWA no obtiene acceso a un panel cerrado. La investigación específica de pantallas traseras compara Xiaomi, Nothing, Ulefone, ASUS y DOOGEE y muestra cómo trabajar con Presentation, WindowManager y SDK OEM.

Plegables, AOD y traslado entre pantallas

La pantalla exterior de un teléfono plegable es especialmente valiosa para consultas rápidas: estado de pedido, audio o una acción breve. Pero una interfaz adaptable de la aplicación principal no garantiza acceso a la pantalla exterior. Deben comprobarse el modo, fabricante, categorías de aplicaciones y mecanismo de publicación de la tarjeta. AOD es otro contexto: menor brillo, frecuencia limitada de actualización y riesgo de exposición de datos.

Handoff transfiere la propia tarea. En Android 17 existe una API para transferir actividades entre dispositivos, incluidos los datos para recuperar el contexto. El valor aparece cuando el segundo dispositivo abre el documento, pedido o fase correctos. Abrir la página de inicio no crea por sí solo una experiencia continua.

Flip, Fold y teléfonos convencionales: adaptad la ventana disponible

La pantalla interior de un Fold abierto, la exterior estrecha, media pantalla en multitarea y un teléfono con el teclado abierto plantean condiciones distintas para la misma tarea. Elegir la interfaz empieza por el ancho y alto disponibles, tamaño del texto, márgenes del sistema y forma de entrada. El nombre del modelo no sustituye estas mediciones.

Para sitios y PWA primero hace falta una adaptación completa a la ventana convencional: Grid/Flexbox, límites de ancho, redistribución de acciones, container queries para componentes en distintos paneles y desplazamiento accesible. Comprobad orientación horizontal con poca altura, teclado, zoom, recortes y barras del navegador. La unidad dvh sirve para la altura dinámica, pero no resuelve por sí sola el comportamiento de cualquier teclado en pantalla.

Si el navegador informa realmente de segmentos de pantalla, pueden considerarse horizontal-viewport-segments y la geometría viewport-segment. Sin esos datos no debe inventarse la posición de la bisagra a partir del nombre del modelo. La página base debe funcionar correctamente como en cualquier ventana redimensionable.

En una aplicación Android utilizad las bibliotecas de diseño adaptable adecuadas al proyecto: las clases de tamaño de ventana consideran tanto ancho como alto. Para listas y detalles relacionados existen componentes scaffold preparados. WindowManager comunica el estado y la geometría del pliegue: si separa áreas y si oculta contenido. No todo pliegue necesita un hueco vacío ni toda pantalla grande necesita dos columnas.

En una aplicación Apple basad el diseño en el contenedor, las zonas seguras y Dynamic Type. ViewThatFits ayuda a reorganizar un grupo local de acciones, y NavigationSplitView, los paneles relacionados en plataformas compatibles. Trasladar las reglas Android sobre bisagras a Apple sin una API correspondiente sería una suposición.

1. Abrid una tarjeta concreta y empezad a escribir un borrador.
2. Cambiad el ancho, girad la ventana o desplegad el dispositivo; después volved al estado anterior.
3. Abrid el teclado y comprobad el acceso al campo, al error y a la acción principal.
4. Aumentad el texto y comprobad una traducción larga y el orden del foco.
5. Confirmad que se conservan selección, borrador, navegación y operación en curso sin reiniciarla.

Adaptar la aplicación principal no concede acceso a una pantalla exterior cerrada de un Flip. El acceso al panel se comprueba por separado, y la reorganización ocurre dentro de la ventana autorizada. Una captura de un navegador de escritorio estrecho tampoco confirma el funcionamiento del pliegue físico o del teclado móvil real.

Coche, auriculares y comandos de voz

Android Auto y Android Automotive OS admiten determinadas categorías de aplicaciones; CarPlay también establece sus capacidades y requisitos. La pantalla del coche no es otro lugar donde colocar cualquier tarjeta. En movimiento importan más un comando breve, una referencia grande y una carga de atención mínima.

Los auriculares sirven para navegar, controlar la reproducción y dar confirmaciones breves. Un flujo de voz debe aclarar ambigüedades: «¿Qué temporizador quieres detener?», en lugar de detener uno al azar. Hay que confirmar el éxito del comando y evitar pronunciar datos sensibles sin considerar el contexto. Altavoces inteligentes y gafas requieren comprobar la plataforma concreta y las interfaces abiertas a terceros; no puede suponerse una API general para «mostrar en cualquier gafa».

Respuesta háptica, luz, NFC, BLE y UWB

Los haptics del sistema permiten transmitir respuesta mediante el tacto. Diseñad un vocabulario pequeño de señales distinguibles: acción aceptada, límite alcanzado y atención necesaria. No codifiquéis por vibración un mensaje largo que la persona deba adivinar.

NFC sirve para acercar y abrir un contexto; BLE, para conectar dispositivos cercanos; UWB, para casos compatibles de medición de distancia y posición. La Ranging API de Android 16 reúne varias tecnologías de medición de distancia, pero no añade hardware inexistente. Primero se comprueban las capacidades de ambos dispositivos y después se diseña la interacción. La proximidad no autentica por sí sola ni autoriza abrir una cerradura o pagar.

La biometría y las passkeys ayudan a confirmar la identidad en estos recorridos. Su función es autorizar y reducir fricción en un paso sensible; no son un canal de mensajes independiente ni justifican trasladar todas las operaciones a la pantalla bloqueada.

11. Qué puede hacer un sitio web o una PWA

Esta distinción es esencial para un equipo web. Una PWA instalada no se convierte automáticamente en una aplicación nativa con ActivityKit, Android Live Updates, complicaciones propias o cápsulas OEM. Esa integración requiere una vía nativa documentada y, a veces, una extensión o aplicación complementaria.

Aun así, un sitio puede resolver gran parte de la tarea: página clara de estado del pedido, enlace profundo, billete añadido a Wallet mediante integración del servidor, Web Push donde sea compatible, menú del sistema para compartir, evento de calendario y acceso por QR. WebKit admite Web Push para aplicaciones web añadidas a la pantalla de inicio desde iOS/iPadOS 16.4; la solicitud de permiso debe seguir una acción del usuario. Son notificaciones, no autorización para crear una Live Activity arbitraria.

Para una compra ocasional, una cita o consultar un billete, un buen recorrido web puede ser mejor que exigir instalar una aplicación. Un entrenamiento diario con sensores y reloj autónomo tiene motivos muy diferentes para elegir desarrollo nativo. Elegid la tecnología después de describir la experiencia que la audiencia realmente necesita.

12. Mensajes dentro de la aplicación: banners, consejos y chat

Las superficies del sistema ayudan fuera de la pantalla principal, pero parte de la comunicación debe permanecer junto a la acción. Si un error pertenece a un campo, conviene explicarlo junto a él. Una acción completada no siempre necesita además un push. Lo siguiente son recomendaciones de diseño para elegir formato, no restricciones de un sistema concreto.

El chat flotante no debe tapar el pago, el teclado ni las acciones principales en móvil. Abrirse automáticamente no equivale a ayudar. «¿Necesitas ayuda con la entrega?» resulta más oportuno tras un problema real que una ventana genérica diez segundos después de entrar.

En un asistente de IA, distinguid respuesta, propuesta de acción y acción ejecutada. «Puedo cambiar la cita» no significa «La cita se ha cambiado». Antes de modificar algo, mostrad el objeto elegido y las consecuencias relevantes; después, el resultado confirmado. Si no encuentra respuesta, indicad el límite y una vía disponible de soporte, conservando el contexto de la consulta.

Correo, SMS y mensajes en aplicaciones de mensajería son otra clase: canales externos de entrega. Se eligen según consentimiento, urgencia y duración necesaria de la información. Conviene conservar un recibo, pero no duplicar cada minuto de viaje en todos los canales. Un fallo del push no autoriza por sí solo enviar SMS sin reglas y consentimiento previos.

13. Casos prácticos: qué sacar exactamente fuera

Una entrega a lo largo del tiempo

Pedido realizado: confirmación y acceso a detalles. Preparación en curso: estado discreto, si la plataforma admite el caso. El repartidor se acerca: el ETA y el punto de encuentro pasan a ser principales. El repartidor ha llegado: cambia el sentido de la tarjeta: ahora hace falta una acción, no otro porcentaje. Pedido recibido: termina el seguimiento activo; el historial queda en la aplicación. Pedir una valoración es otra tarea, no una razón para mantener la isla.

Si la previsión pasa de cuatro a siete minutos, hay que mostrarlo con honestidad. Si las coordenadas dejan de actualizarse, no puede seguirse descontando con seguridad el tiempo de llegada. En un temporizador se conoce el transcurso local del tiempo; para un repartidor, eso no sustituye los datos nuevos.

Analizar una tarea de IA

Al generar un documento sirven fases reales: «analizando materiales», «preparando el borrador», «revisando el resultado». Si el servidor no mide el grado de finalización, mejor no mostrar porcentaje. El final debe llevar al resultado concreto; el error, a una explicación clara y un reintento permitido. Una superficie en directo solo es adecuada después de comprobar los criterios de la plataforma y la necesidad de seguimiento continuo.

14. Lo más importante del diseño: los estados invisibles

Un diseño bonito suele mostrar un minuto de éxito. Un producto real debe resistir pérdida de red, cierre de sesión, finalización, mensajes repetidos y revocación de permisos. El modelo recomendado distingue el estado de la tarea del estado de su representación.

• Tarea: creada, activa, pausada, requiere acción, finalizada, cancelada o con error.
• Datos: vigentes, desactualizados o no disponibles.
• Representación: no creada, visualización solicitada, acceso restringido, ocultada por el usuario o finalizada.

«El usuario retiró la tarjeta» no significa «El usuario canceló el taxi». «La aplicación se descargó de memoria» no significa «El pedido terminó». «El proveedor aceptó el push» no significa «La pantalla se actualizó». Separar estos conceptos evita toda una clase de errores de soporte y analítica.

Definid la vigencia de cada tipo de dato. El ETA de una entrega y la hora de una reunión caducan de maneras distintas. Cuando vence el plazo, la tarjeta debe dejar de aparentar un estado actual confirmado. A veces basta «datos de las 12:06»; otras, hay que retirar la métrica o finalizar la vista. La regla depende del caso y de las API disponibles.

Diseñad la finalización por separado: retirar inmediatamente puede privar a la persona del resultado final; una tarjeta eterna genera ruido visual. Definid para cada superficie qué permanece, cuánto tiempo y adónde lleva la pulsación. Los límites de la plataforma tienen prioridad.

15. Arquitectura: tarea única, adaptadores independientes

En un producto multiplataforma conviene separar estado de negocio, transporte de actualizaciones y representación visual. El servidor conoce el estado del pedido. El temporizador local conoce cuándo termina. El adaptador conoce qué datos y acciones permite cada superficie.

Un modelo ilustrativo de evento podría ser así. Es un esquema propio de la aplicación, no un formato del SDK:

{
  "activityId": "delivery_204",
  "revision": 18,
  "phase": "courier_approaching",
  "updatedAt": "2026-11-05T12:06:00Z",
  "validUntil": "2026-11-05T12:08:00Z",
  "estimatedArrivalAt": "2026-11-05T12:10:00Z",
  "allowedActions": ["open_order", "contact_courier"],
  "privacyClass": "personal"
}

revision ayuda a rechazar una actualización tardía. validUntil establece hasta cuándo se puede confiar en los datos. estimatedArrivalAt guarda una previsión de tiempo, no una cadena ya formateada como «4 min». La localización y la representación corresponden al adaptador. El campo de privacidad determina qué información puede llegar a una superficie pública.

Pero el JSON no garantiza nada por sí solo. Hacen falta gestionar duplicados y desorden, recuperar el estado tras reiniciar, revocar tokens inválidos, detener correctamente las actualizaciones y usar enlaces profundos seguros. Al abrir el pedido se comprueban de nuevo cuenta y acceso: un identificador en el enlace no equivale a autorización.

Los comandos de las distintas superficies deben llegar a una misma lógica de negocio. Si la persona pulsa «Pausa» casi simultáneamente en reloj y teléfono, dos solicitudes no deben reactivar el entrenamiento. Conviene un comando «establecer pausa», en lugar de «invertir estado» a ciegas, junto con idempotencia de la operación.

El transporte se elige por separado: APNs/ActivityKit, notificaciones Android, push OEM, actualización local o sincronización del reloj. No puede suponerse que una interfaz en directo mantiene el proceso en memoria. Tampoco debe utilizarse un foreground service solo para sostener una tarjeta publicitaria. El trabajo en segundo plano debe corresponder a la tarea real y a las reglas del sistema.

16. Permisos, privacidad, accesibilidad y coste de la atención

Desde Android 13, la mayoría de notificaciones requiere POST_NOTIFICATIONS. Conviene pedir permiso cuando la utilidad está clara: después de elegir «seguir el viaje», no durante el primer contacto con la aplicación. Si se deniega, indicad dónde consultar el estado manualmente; no repitáis la misma solicitud en cada inicio.

La superficie adicional debe respetar los ajustes de la persona. Ocultación, silencio, modo de concentración y bloqueo del contenido en pantalla son parte del recorrido. Trasladar una notificación desactivada a una superposición agresiva no respeta la decisión del usuario.

Preparad contenido seguro específico para la privacidad: «Hay una actualización del pedido», sin dirección, nombre ni importe. Una acción sensible debe superar la verificación de identidad necesaria. Abrir detalles y confirmar una operación financiera requieren distintos permisos, aunque ambos botones quepan en la misma tarjeta.

La accesibilidad necesita etiquetas legibles, significado independiente del color, texto ampliado y nombres de acciones correctos para lectores de pantalla. «Pausar entrenamiento» es más claro que dos rayas verticales sin explicación. Comprobad traducciones largas, formatos de hora, unidades y dirección del texto. En relojes y AOD, aplicad estos requisitos considerando sus límites.

No todo cambio de fase merece vibración. En una entrega pueden separarse los cambios discretos de estado del momento de salir. En un temporizador no tiene sentido sonar con cada actualización. Con varios dispositivos, primero se estudia cómo reenvía el sistema las notificaciones y después se añaden reglas propias, para evitar dos canales independientes del mismo evento.

17. Qué comprobar antes de publicar

La matriz de pruebas combina dispositivo × compilación del sistema × región × versión de la aplicación × ajustes × caso de uso. No bastan la marca y el número de Android. Una integración OEM crítica necesita pruebas en un dispositivo real del mercado objetivo, no solo en emulador.

Guardad en cada prueba modelo, región del firmware, compilación exacta, permisos y resultado observado. «Nos funciona en Samsung» no es reproducible. «En este modelo y compilación, con estos ajustes, la entrega obtuvo una tarjeta en bloqueo» ya es un registro útil de compatibilidad.

Criterio mínimo de preparación: el usuario entiende el estado, realiza la acción necesaria, puede detener la visualización, no recibe datos falsamente actuales y conserva un recorrido funcional si la superficie adicional no está disponible.

18. Cómo medir la utilidad cuando se abre menos la aplicación

Una integración exitosa puede reducir las aperturas. Si antes una persona consultaba cinco veces al repartidor y ahora mira una vez el reloj, la caída de app opens no implica un peor producto. Por eso las métricas deben relacionarse con la tarea completada.

• Esfuerzo: número de transiciones y tiempo hasta responder una pregunta concreta.
• Resultado: recogidas exitosas, acciones completadas y proporción de cambios importantes perdidos.
• Fiabilidad: retraso de actualizaciones, estados desactualizados y errores de comandos.
• Coste: batería, red y mantenimiento de las distintas integraciones.
• Control del usuario: desactivaciones, ocultaciones y quejas por señales repetidas.

Separad las etapas: el dispositivo admite el mecanismo → se concede permiso → se acepta la solicitud → una API disponible confirma el estado de la representación → la persona interactúa → se completa la tarea. Puede no existir una API que confirme la visualización real. No registréis una «impresión» solo porque el servidor envió un push, ni interpretéis automáticamente la ausencia de pulsación como ausencia de utilidad.

Para priorizar, utilizad datos propios: proporción de casos adecuados, dispositivos compatibles, frecuencia y reducción esperada del esfuerzo. Es un modelo estimativo, no un coeficiente sectorial demostrado. Tras publicar, comparad grupos equivalentes; quienes añadieron un widget por iniciativa propia podían ser más activos ya antes del experimento.

19. Plan práctico de implementación

1. Describid una tarea. Quién espera qué cambio, qué hará después y cuándo termina la visualización.
2. Comprobad la audiencia. Sistema, modelos, mercados, relojes y frecuencia del caso. No elijáis un fabricante por lo vistoso de su presentación.
3. Construid el recorrido básico. Estado fiable en aplicación o web, notificaciones necesarias, enlaces y permisos correctos.
4. Elegid una superficie externa. Entrega: actividad actual; hábitos: widget; audio: sesión multimedia; entrenamiento: reloj.
5. Describid todos los estados y acciones. Incluidos caducidad, ocultación y finalización. Después diseñad tamaños y animación.
6. Comprobad el acceso de la plataforma. API pública, versiones, admisión OEM, región, límites y reglas de distribución.
7. Lanzadlo en un grupo compatible limitado. Comprobad el resultado de la tarea y el coste de atención; ampliad después de confirmar la utilidad.

Este orden no impone «primero islas, luego relojes». Para música, la primera inversión es la sesión multimedia; para deporte, un recorrido autónomo en la muñeca; para billetes, Wallet. La mejor superficie es la que ayuda a vuestra audiencia en su contexto real.

Descubrir primero las oportunidades del proyecto y después elegir casos

Ambos skills ofrecen un modo de investigación independiente. El agente estudia pantallas reales, tareas de usuario, datos, targets nativos y API ya integradas; después propone casos adecuados: qué esfuerzo repetido eliminan, dónde estarán disponibles, qué falta para implementarlos y cuánto cambio requieren. Los formatos e integraciones que no encajan deben recibir una explicación clara, sin entrar en una lista obligatoria.

Las propuestas reciben ID breves. La persona elige qué implementar ahora, posponer o descartar; el agente conserva esa elección y pasa a implementar lo seleccionado. La recomendación no cuenta por sí sola como decisión del usuario. Si la tarea ya está definida —por ejemplo, crear un widget de pedidos—, no hace falta volver a elegir.

Ejemplo de solicitud: $interaction-surfaces — «Analiza mi proyecto, propón casos útiles con sus ventajas, dependencias y dificultad estimada. Déjame elegir antes de implementar». Para reorganizar la interfaz según tamaño de ventana y postura del dispositivo, el mismo modo existe en $adaptive-interfaces.

Un skill específico para sitios y aplicaciones adaptables

Para trabajar con formatos de ventana podéis instalar Adaptive Interfaces desde el repositorio de GitHub. El paquete en inglés abarca web/PWA, Android, Apple, React Native y Flutter: ventanas estrechas, orientación horizontal, Flip/Fold, pliegues, teclado, zonas seguras, escala del texto y conservación de la tarea durante las transiciones.

En Codex podéis pasar esta orden al instalador integrado:

$skill-installer install https://github.com/wladislaw353/agent-skills/tree/main/skills/adaptive-interfaces

Después de clonar el repositorio, colocad el contenido de la carpeta skills/adaptive-interfaces en ~/.agents/skills/adaptive-interfaces/. Para invocarlo explícitamente, utilizad $adaptive-interfaces; también se permite la selección automática para una tarea adecuada. La integración correspondiente sigue necesitando acceso a la pantalla del fabricante y pruebas reales en dispositivo.

Skill para Codex y Claude Code: aplicar el enfoque a vuestro proyecto

Esta investigación nos llevó a crear skills abiertos para Codex y Claude Code que analizan un proyecto y proponen mejoras útiles para su sitio web o aplicación. Interaction Surfaces ayuda a descubrir superficies e interacciones adecuadas y Adaptive Interfaces orienta la adaptación entre tamaños y pantallas. Las propuestas son opcionales: el usuario elige qué escenarios aportan valor y cuáles quiere implementar.

Podéis trasladar el enfoque de esta serie a un agente de IA: instalar el skill Interaction Surfaces desde GitHub. El paquete está escrito en inglés y ayuda a elegir superficies de interacción útiles al desarrollar interfaces, incluso cuando la tarea todavía no menciona islas, widgets ni relojes.

Incluye instrucciones de implementación, ejemplos y enlaces a documentación oficial:

• Widgets útiles: selección de una tarea recurrente, WidgetKit, Android App Widgets/Glance, configuración, acciones, datos y actualizaciones.
• Android: Live Updates, permisos, ProgressStyle y MetricStyle, ejemplo Kotlin, diagnóstico de promoción e integración de casos OEM.
• Apple: ActivityKit, WidgetKit, estados de Dynamic Island, ejemplo Swift, App Intents y actualizaciones mediante APNs.
• Relojes: Apple Watch y Wear OS, complicaciones, widgets y Tiles, HealthKit, Health Services, WatchConnectivity y Data Layer.
• Pantallas adicionales: DisplayManager, Presentation, WindowManager, Glyph Matrix y comprobación del acceso real a paneles de fabricantes.

El skill trata por separado los datos desactualizados, la falta de conexión, permisos, finalización y pruebas en dispositivo. Sus instrucciones ayudan a implementar la integración; no sustituyen el acceso al SDK, la aprobación del fabricante ni las pruebas del modelo concreto.

Instalación desde GitHub: en Codex podéis pasar esta orden al instalador integrado de skills:

$skill-installer install https://github.com/wladislaw353/agent-skills/tree/main/skills/interaction-surfaces

En Claude Code podéis instalar toda la colección de este mismo repositorio de GitHub como plugin. Las instrucciones específicas para Claude Code incluyen comandos de instalación y actualización. Tras instalar están disponibles /agent-skills:adaptive-interfaces y /agent-skills:interaction-surfaces. Si instaláis manualmente carpetas individuales en ~/.claude/skills/ , se utilizan los nombres breves /adaptive-interfaces y /interaction-surfaces.

Instalación: clonad el repositorio de GitHub y copiad la carpeta skills/interaction-surfaces completa en ~/.agents/skills/. El archivo debe quedar en la ruta ~/.agents/skills/interaction-surfaces/SKILL.md; conservad las carpetas references y agents junto a él. Es el directorio de usuario indicado en la documentación de OpenAI sobre skills locales.

Para invocarlo explícitamente en Codex, escribid: $interaction-surfaces y describid la tarea, por ejemplo: «Diseña el seguimiento de pedidos para iOS y Android, elige superficies externas adecuadas e impleméntalas en el proyecto actual». También se permite la selección automática del skill. Si no aparece tras instalarlo, reiniciad Codex.

Preguntas frecuentes

Una buena interfaz externa desaparece a tiempo

La fuerza de estas tecnologías es que la persona no tiene que atender continuamente a la aplicación. Obtiene una respuesta, decide y sigue con lo suyo. Hace falta más que una animación atractiva: un modelo claro de la tarea, datos fiables, respeto a los ajustes y compatibilidad verificada.

Diseñad para minimizar el esfuerzo necesario para completar la tarea, no para maximizar los lugares donde mostrar el producto. Así, islas, widgets, relojes y señales físicas pasan a formar parte de un mismo servicio útil.