Dictáfono de voz primero: push-to-talk y PendingCreation

Puntos clave a recordar: El Dictáfono de TAMSIV se basa en tres decisiones de diseño: push-to-talk (sin escucha continua) para la batería y la privacidad, el patrón PendingCreation (vista previa antes de guardar) para mantener al usuario en control, y dos modos STT (nativo gratuito vs. Deepgram en la nube) para adaptarse al plan de precios. La voz no es una característica, es el producto.

La promesa de TAMSIV se resume en una frase: crear una tarea hablando, más rápido que escribiendo. No es un gadget de voz injertado en una aplicación de tareas clásica. La voz es la interfaz principal, el teclado es el respaldo. Toda la UX del Dictáfono se deriva de esta promesa.

Aquí están las decisiones de diseño, los compromisos técnicos y los patrones que hacen que el Dictáfono de TAMSIV funcione a diario.

¿Por qué elegir push-to-talk en lugar de escucha continua?

Esta es la primera decisión de diseño, y la más importante. Tenía dos opciones: escucha continua (como Alexa o Google Home) o push-to-talk (presionar para hablar).

Elegí push-to-talk por tres razones:

• La batería: la escucha continua mantiene el micrófono activo permanentemente. En un smartphone, esto es un gran consumo de energía. El STT (Speech-to-Text) continuo consume del 10 al 15% de la batería por hora, según los benchmarks de Android. Inaceptable para una aplicación de productividad que debe permanecer abierta en segundo plano.
• La privacidad: un micrófono siempre abierto da miedo. Los usuarios no confían, y tienen razón. El push-to-talk es explícito. Tú presionas, tú hablas, tú sueltas. No hay ambigüedad sobre lo que se graba.
• El ruido ambiental: en un café, en la calle, en el transporte, la escucha continua capta todo. La Detección de Actividad de Voz (VAD) no es perfecta. El push-to-talk elimina el problema: la aplicación solo escucha cuando el usuario lo decide.

El VAD de Deepgram gestiona automáticamente el final de la frase en modo nube. En modo nativo, es el STT del dispositivo el que detecta el silencio. En ambos casos, el usuario no necesita cronometrar su suelta, el sistema sabe cuándo termina la frase.

¿Cómo funciona el patrón PendingCreation?

Este es el patrón más importante de TAMSIV. Y probablemente el menos intuitivo para alguien que no ha trabajado en una aplicación de voz.

El problema: el reconocimiento de voz no es perfecto. La IA puede malinterpretar. "Comprar pan" podría convertirse en "A comprar pin". Si se guarda directamente en la base de datos, el usuario se encuentra con datos corruptos sin darse cuenta.

La solución: el PendingCreation.

1. El usuario dicta: "Añade una tarea para mañana: llamar al dentista, prioridad alta"
2. El STT transcribe el audio a texto
3. El texto se envía al LLM a través de WebSocket
4. El LLM analiza y llama a la función create_task con los parámetros extraídos (título, fecha, prioridad)
5. El backend devuelve un function_result con una vista previa
6. El usuario ve la propuesta en pantalla: título, fecha, prioridad
7. Puede modificar, validar o cancelar
8. Solo después de la validación, la tarea se guarda en la base de datos (Supabase)

El principio: la voz acelera la entrada, pero el humano decide. Nada se guarda sin validación explícita. Esto parece añadir un paso, pero en la práctica, la validación toma medio segundo (un toque) y da una sensación de control que los usuarios aprecian enormemente.

Este patrón es particularmente importante para los eventos de calendario, donde un error de fecha puede tener consecuencias reales (perder una cita).

¿Cuál es la diferencia entre STT nativo y STT en la nube?

TAMSIV ofrece dos modos de reconocimiento de voz, configurables por el administrador:

Modo nativo (por defecto)

• Gratuito: utiliza el motor STT integrado en el dispositivo (Google Speech-to-Text en Android, Apple Speech en iOS)
• Local: no se envía ningún dato de audio a un servidor externo (con los modelos offline)
• Calidad variable: depende del dispositivo, el idioma y el modelo descargado
• Utilizado para: el plan Free

Modo en la nube (Deepgram)

• De pago: facturación por el número de segundos de audio procesados
• Consistente: calidad uniforme independientemente del dispositivo
• Preciso: mejor gestión de acentos, ruido ambiental y vocabulario técnico
• Utilizado para: los planes Pro y Team

La elección entre nativo y nube es una decisión de segmentación de producto, no solo una decisión técnica. El plan Free ofrece una experiencia de voz funcional. El plan Pro ofrece una experiencia de voz fiable. Es un argumento de venta claro para la actualización, detallado en los planes de suscripción de RevenueCat.

Entre bastidores, el cambio entre los dos modos es transparente. La comparativa STT nativo vs Deepgram detalla las diferencias técnicas en profundidad.

¿Por qué el Dictáfono es la primera pestaña de la aplicación?

En la navegación de TAMSIV, el Dictáfono es la primera pestaña. No las tareas. No las notas. No el calendario. El micrófono.

Es una elección deliberada. En la mayoría de las aplicaciones de productividad, la voz es una característica secundaria, un pequeño botón de micrófono escondido en una esquina. En TAMSIV, es lo contrario: la voz es EL producto. La pantalla táctil es el complemento.

El orden de las pestañas (personalizable por el usuario, guardado en la base de datos) sigue esta jerarquía por defecto:

1. Dictáfono — la acción principal (crear por voz)
2. Feed — ver tu actividad reciente
3. Agenda — organizar tu tiempo
4. Grupos — colaborar
5. Social — descubrir
6. Perfil — ajustes

Si abres TAMSIV, te encuentras con el micrófono. Un solo gesto para empezar a dictar. Es la filosofía "voice-first" llevada al máximo.

¿Cómo mejora la retroalimentación háptica la experiencia de voz?

La retroalimentación háptica es un detalle sutil pero crucial. Con cada cambio de estado del Dictáfono, el teléfono vibra ligeramente:

• Inicio de grabación: vibración corta (50ms) — "te escucho"
• Fin de grabación: vibración doble — "entendí, estoy procesando"
• Vista previa recibida: vibración larga (100ms) — "aquí está mi propuesta"
• Validación exitosa: vibración de confirmación — "está guardado"

El usuario siente físicamente cuando la aplicación escucha, cuando procesa y cuando ha terminado. Esto es particularmente importante cuando se dicta sin mirar la pantalla, conduciendo, cocinando, caminando.

Este principio de retroalimentación multimodal (visual + háptica + sonora opcional) es una recomendación clásica del Nielsen Norman Group para interfaces en tiempo real.

¿Cómo interpreta la IA el dictado?

El texto transcrito por el STT se envía al LLM (a través de OpenRouter) con un system prompt específico. La IA tiene acceso a 7 function tools:

• create_task — crear una tarea con título, fecha, prioridad, recurrencia
• update_task — modificar una tarea existente
• create_memo — crear una nota de voz estructurada
• update_memo — modificar una nota
• create_calendar_event — crear un evento de calendario
• ask_clarification — pedir una aclaración si la solicitud es ambigua
• end_conversation — terminar la conversación correctamente

La IA no se limita a transcribir, comprende la intención. "Recuérdame comprar pan mañana por la mañana" se convierte en un create_task con un recordatorio configurado para el día siguiente a las 9h. "Nota para más tarde: idea de característica para el feed" se convierte en un create_memo con la etiqueta "idea".

El historial de conversación permite encadenar: "Añade una tarea" → "De hecho, ponla para el viernes" → "Y añade una nota sobre ella". La IA comprende el hilo.

¿Cuáles son los límites del voice-first?

Ser honesto sobre los límites es esencial. El voice-first no es adecuado para todo:

• Entornos ruidosos: incluso con un buen STT, dictar en un bar es tedioso. El teclado sigue disponible como respaldo.
• Contenido complejo: dictar una nota de 3 párrafos con viñetas y formato es tedioso. El editor de texto enriquecido toma el relevo.
• Privacidad en público: dictar "Cita con el oncólogo el miércoles" en el metro, nadie quiere eso.
• Precisión de las fechas: "La semana que viene" es ambiguo. El patrón PendingCreation permite corregir, pero el teclado sigue siendo más preciso para fechas complejas.

TAMSIV no obliga a nadie a usar la voz. Cada pantalla tiene un formulario clásico como alternativa. La voz es más rápida en el 80% de los casos, el 20% restante tiene el teclado.

¿Cómo optimizar la latencia del pipeline de voz?

La latencia percibida es el factor número uno de la experiencia de voz. Si el usuario habla y espera 5 segundos antes de ver la vista previa, vuelve al teclado. El pipeline completo:

Audio → STT → Texto → WebSocket → LLM → Function calling → Respuesta → TTS → Audio

Cada etapa tiene su propia latencia:

• STT nativo: ~200-500ms (local, rápido)
• STT Deepgram: ~300-800ms (red, más preciso)
• LLM a través de OpenRouter: ~1-3 segundos (el cuello de botella)
• TTS OpenAI: ~500ms-1s (streaming de audio)

Total: 2 a 5 segundos desde que el usuario termina de hablar hasta que escucha la respuesta. Esto es aceptable para una interacción conversacional (comparable a un humano que piensa), pero requiere una retroalimentación visual continua: el botón animado Nebula muestra una animación mientras la IA procesa.

¿Cómo construir una experiencia voice-first en tu aplicación?

Si quieres integrar la voz como interfaz principal en tu aplicación, aquí tienes las lecciones aprendidas de TAMSIV:

1. Push-to-talk, no escucha continua: ahorro de batería, respeto a la privacidad, fiabilidad.
2. Vista previa antes de guardar: el patrón PendingCreation no es negociable. El usuario siempre debe poder corregir.
3. Retroalimentación multimodal: visual + háptica + sonora. El usuario debe saber en todo momento lo que hace la aplicación.
4. Teclado de respaldo: la voz no reemplaza al teclado, lo complementa. Ofrece siempre una alternativa manual.
5. Segmenta el STT: nativo para el gratuito, en la nube para el premium. Es una palanca de monetización natural.

El recorrido de más de 650 commits de TAMSIV demuestra que una experiencia de voz sólida requiere decenas de iteraciones. El primer prototipo funcionaba, pero la versión actual es 10 veces más fluida gracias a los comentarios de los usuarios y a la integración continua de la IA.

Preguntas frecuentes

¿Funciona el Dictáfono sin conexión?

Parcialmente. El STT nativo funciona sin conexión (si el modelo de idioma está descargado en el dispositivo). Pero el LLM y el TTS requieren una conexión a internet. En modo offline, el usuario puede dictar texto sin formato, pero la IA no puede interpretar ni estructurar la tarea.

¿Qué idiomas son compatibles con el Dictáfono?

El STT nativo es compatible con todos los idiomas instalados en el dispositivo (generalmente más de 50). El STT Deepgram es compatible con los principales idiomas europeos. La IA comprende los 6 idiomas de TAMSIV (FR, EN, DE, ES, IT, PT) gracias a la internacionalización completa.

¿Cómo gestiona el Dictáfono los acentos y dialectos?

El STT nativo depende del modelo de idioma del dispositivo; los acentos regionales suelen gestionarse bien para los idiomas principales. Deepgram destaca en los acentos gracias a modelos entrenados con corpus diversos. La IA (LLM) comprende las formulaciones regionales sin problema.

¿Se pueden dictar tareas mientras se conduce?

Sí, es un caso de uso diseñado. El push-to-talk requiere un gesto inicial, pero la retroalimentación háptica y la respuesta TTS permiten dictar y confirmar sin mirar la pantalla. Atención: la validación final (tocar "Confirmar") requiere una mirada; una futura versión podría añadir la confirmación por voz.

¿El Dictáfono consume mucha batería?

No. El push-to-talk solo activa el micrófono durante el dictado (unos segundos). La conexión WebSocket es ligera y persistente. El consumo principal proviene del LLM y del TTS, que son llamadas de red puntuales. En uso normal (5-10 dictados al día), el impacto en la batería es insignificante.