Blog
AI/Voice
8 de janeiro de 202610 min

Ditafone voice-first: push-to-talk e PendingCreation

Pontos-chave a reter: O Ditafone do TAMSIV baseia-se em três decisões de design: push-to-talk (sem escuta contínua) para a bateria e privacidade, o padrão PendingCreation (pré-visualização antes de guardar) para manter o utilizador no controlo, e dois modos STT (nativo gratuito vs. cloud Deepgram) para se adaptar ao plano de preços. A voz não é uma funcionalidade — é o produto.

A promessa do TAMSIV resume-se numa frase: criar uma tarefa falando, mais rápido do que digitando. Não é um gadget de voz enxertado numa aplicação de tarefas clássica. A voz é a interface principal — o teclado é o fallback. Toda a UX do Ditafone deriva desta promessa.

Aqui estão as decisões de design, os compromissos técnicos e os padrões que fazem o Ditafone do TAMSIV funcionar no dia a dia.

Pessoa falando no smartphone enquanto caminha numa rua da cidade ao nascer do sol
O principal caso de uso: ditar uma tarefa a caminhar, sem tirar as mãos dos bolsos.

Porquê escolher o push-to-talk em vez da escuta contínua?

Esta é a primeira decisão de design, e a mais importante. Eu tinha duas opções: escuta contínua (como Alexa ou Google Home) ou push-to-talk (pressionar para falar).

Escolhi o push-to-talk por três razões:

  • A bateria: a escuta contínua mantém o microfone ativo permanentemente. Num smartphone, isso é um dreno de energia. O STT (Speech-to-Text) contínuo consome 10 a 15% da bateria por hora, de acordo com os benchmarks Android. Inaceitável para uma aplicação de produtividade que deve permanecer aberta em segundo plano.
  • A privacidade: um microfone sempre aberto, isso assusta. Os utilizadores não confiam — e têm razão. O push-to-talk é explícito. Tu pressionas, falas, soltas. Sem ambiguidade sobre o que é gravado.
  • O ruído ambiente: num café, na rua, nos transportes — a escuta contínua capta tudo. A Deteção de Atividade de Voz (VAD) não é perfeita. O push-to-talk elimina o problema: a aplicação só ouve quando o utilizador decide.

O VAD do Deepgram gere automaticamente o fim da frase no modo cloud. No modo nativo, é o STT do dispositivo que deteta o silêncio. Em ambos os casos, o utilizador não precisa de cronometrar o seu lançamento — o sistema sabe quando a frase terminou.

Como funciona o padrão PendingCreation?

Este é o padrão mais importante do TAMSIV. E provavelmente o menos intuitivo para alguém que não trabalhou numa aplicação de voz.

O problema: o reconhecimento de voz não é perfeito. A IA pode interpretar mal. "Comprar pão" pode tornar-se "A chetar do pin". Se guardarmos diretamente na base de dados, o utilizador fica com dados corrompidos sem se aperceber.

A solução: o PendingCreation.

  1. O utilizador dita: "Adiciona uma tarefa para amanhã: ligar para o dentista, prioridade alta"
  2. O STT transcreve o áudio para texto
  3. O texto é enviado para o LLM via WebSocket
  4. O LLM analisa e chama a função create_task com os parâmetros extraídos (título, data, prioridade)
  5. O backend devolve um function_result com uma pré-visualização
  6. O utilizador vê a proposta no ecrã: título, data, prioridade
  7. Pode modificar, validar ou cancelar
  8. Só após a validação, a tarefa é guardada na base de dados (Supabase)

O princípio: a voz acelera a entrada, mas o humano decide. Nada é guardado sem validação explícita. Parece adicionar um passo, mas na prática, a validação leva meio segundo (um toque) e dá uma sensação de controlo que os utilizadores apreciam imenso.

Este padrão é particularmente importante para os eventos de agenda, onde um erro de data pode ter consequências reais (perder um compromisso).

Qual é a diferença entre STT nativo e STT cloud?

O TAMSIV oferece dois modos de reconhecimento de voz, configuráveis pelo administrador:

Modo nativo (por defeito)

  • Gratuito: utiliza o motor STT integrado no dispositivo (Google Speech-to-Text no Android, Apple Speech no iOS)
  • Local: nenhum dado de áudio é enviado para um servidor externo (com os modelos offline)
  • Qualidade variável: depende do dispositivo, do idioma e do modelo descarregado
  • Utilizado para: o plano Free

Modo cloud (Deepgram)

  • Pago: faturação pelo número de segundos de áudio processados
  • Consistente: qualidade uniforme independentemente do dispositivo
  • Preciso: melhor gestão de sotaques, ruído ambiente e vocabulário técnico
  • Utilizado para: os planos Pro e Team

A escolha entre nativo e cloud é uma decisão de segmentação de produto, não apenas uma decisão técnica. O plano Free oferece uma experiência de voz funcional. O plano Pro oferece uma experiência de voz fiável. É um argumento de venda claro para o upgrade, detalhado nos planos de subscrição RevenueCat.

Nos bastidores, a mudança entre os dois modos é transparente. A comparação STT nativo vs Deepgram detalha as diferenças técnicas em profundidade.

Microfone de estúdio profissional com ondas sonoras visualizadas em anéis de luz azul
Do som bruto ao texto estruturado: o STT é a primeira etapa do pipeline de voz.

Porquê o Ditafone é o primeiro separador da aplicação?

Na navegação do TAMSIV, o Ditafone é o primeiro separador. Não as tarefas. Não os memorandos. Não a agenda. O microfone.

É uma escolha deliberada. Na maioria das aplicações de produtividade, a voz é uma funcionalidade secundária — um pequeno botão de microfone escondido num canto. No TAMSIV, é o contrário: a voz é O produto. O ecrã tátil é o complemento.

A ordem dos separadores (personalizável pelo utilizador, guardada na base de dados) segue esta hierarquia por defeito:

  1. Ditafone — a ação principal (criar por voz)
  2. Feed — ver a atividade recente
  3. Agenda — organizar o tempo
  4. Groups — colaborar
  5. Social — descobrir
  6. Profile — definições

Se abrires o TAMSIV, tu vais dar de caras com o microfone. Um único gesto para começar a ditar. É a filosofia "voice-first" levada ao máximo.

Como o feedback háptico melhora a experiência de voz?

O feedback háptico é um detalhe subtil mas crucial. A cada mudança de estado do Ditafone, o telefone vibra ligeiramente:

  • Início da gravação: vibração curta (50ms) — "estou a ouvir-te"
  • Fim da gravação: vibração dupla — "entendi, estou a processar"
  • Pré-visualização recebida: vibração longa (100ms) — "aqui está a minha proposta"
  • Validação bem-sucedida: vibração de confirmação — "está guardado"

O utilizador sente fisicamente quando a aplicação está a ouvir, quando está a processar e quando terminou. Isso é particularmente importante quando se dita sem olhar para o ecrã — a conduzir, a cozinhar, a caminhar.

Este princípio de feedback multimodal (visual + háptico + sonoro opcional) é uma recomendação clássica do Nielsen Norman Group para interfaces em tempo real.

Como a IA interpreta o ditado?

O texto transcrito pelo STT é enviado para o LLM (via OpenRouter) com um system prompt específico. A IA tem acesso a 7 ferramentas de função:

  • create_task — criar uma tarefa com título, data, prioridade, recorrência
  • update_task — modificar uma tarefa existente
  • create_memo — criar um memorando de voz estruturado
  • update_memo — modificar um memorando
  • create_calendar_event — criar um evento de agenda
  • ask_clarification — pedir um esclarecimento se a solicitação for ambígua
  • end_conversation — terminar a conversa de forma limpa

A IA não se limita a transcrever — ela compreende a intenção. "Lembra-me de comprar pão amanhã de manhã" torna-se um create_task com um lembrete configurado para o dia seguinte às 9h. "Nota para mais tarde: ideia de funcionalidade para o feed" torna-se um create_memo com a tag "ideia".

O histórico de conversação permite encadear: "Adiciona uma tarefa" → "Na verdade, coloca-a para sexta-feira" → "E adiciona um memorando sobre isso". A IA compreende o fluxo.

Quais são os limites do voice-first?

Ser honesto sobre os limites é essencial. O voice-first não é adequado para tudo:

  • Ambientes ruidosos: mesmo com um bom STT, ditar num bar é penoso. O teclado permanece disponível como fallback.
  • Conteúdo complexo: ditar um memorando de 3 parágrafos com marcadores e formatação é tedioso. O editor de rich text assume o controlo.
  • Privacidade em público: ditar "Consulta com o oncologista quarta-feira" no metro, ninguém quer isso.
  • Precisão das datas: "Na próxima semana" é ambíguo. O padrão PendingCreation permite corrigir, mas o teclado é mais preciso para datas complexas.

O TAMSIV não obriga ninguém a usar a voz. Cada ecrã tem um formulário clássico como alternativa. A voz é mais rápida em 80% dos casos — os 20% restantes têm o teclado.

Mão a pressionar um botão luminoso num ecrã de smartphone, interação tátil
Push-to-talk: um gesto, uma ação. A simplicidade como filosofia de design.

Como otimizar a latência do pipeline de voz?

A latência percebida é o fator número um da experiência de voz. Se o utilizador fala e espera 5 segundos antes de ver a pré-visualização, ele volta ao teclado. O pipeline completo:

Áudio → STT → Texto → WebSocket → LLM → Chamada de função → Resposta → TTS → Áudio

Cada etapa tem a sua própria latência:

  • STT nativo: ~200-500ms (local, rápido)
  • STT Deepgram: ~300-800ms (rede, mais preciso)
  • LLM via OpenRouter: ~1-3 segundos (o gargalo)
  • TTS OpenAI: ~500ms-1s (streaming de áudio)

Total: 2 a 5 segundos desde o momento em que o utilizador termina de falar até o momento em que ouve a resposta. Isso é aceitável para uma interação conversacional (comparável a um humano a pensar), mas requer um feedback visual contínuo — o botão animado Nebula exibe uma animação enquanto a IA processa.

Como construir uma experiência voice-first na tua aplicação?

Se tu quiseres integrar a voz como interface principal na tua aplicação, aqui estão as lições tiradas do TAMSIV:

  1. Push-to-talk, não escuta contínua: economia de bateria, respeito pela privacidade, fiabilidade.
  2. Pré-visualização antes de guardar: o padrão PendingCreation é inegociável. O utilizador deve sempre poder corrigir.
  3. Feedback multimodal: visual + háptico + sonoro. O utilizador deve saber a cada instante o que a aplicação está a fazer.
  4. Fallback teclado: a voz não substitui o teclado — ela complementa-o. Oferece sempre uma alternativa manual.
  5. Segmenta o STT: nativo para o gratuito, cloud para o premium. É uma alavanca de monetização natural.

O percurso de mais de 650 commits do TAMSIV mostra que uma experiência de voz sólida exige dezenas de iterações. O primeiro protótipo funcionava — mas a versão atual é 10x mais fluida graças aos feedbacks dos utilizadores e à integração contínua de IA.

FAQ

O Ditafone funciona offline?

Parcialmente. O STT nativo funciona offline (se o modelo de idioma estiver descarregado no dispositivo). Mas o LLM e o TTS necessitam de uma ligação à internet. No modo offline, o utilizador pode ditar texto bruto, mas a IA não consegue interpretar nem estruturar a tarefa.

Que idiomas são suportados pelo Ditafone?

O STT nativo suporta todos os idiomas instalados no dispositivo (geralmente mais de 50). O STT Deepgram suporta os principais idiomas europeus. A IA compreende os 6 idiomas do TAMSIV (FR, EN, DE, ES, IT, PT) graças à internacionalização completa.

Como o Ditafone gere os sotaques e os dialetos?

O STT nativo depende do modelo de idioma do dispositivo — os sotaques regionais são geralmente bem geridos para os idiomas principais. O Deepgram destaca-se nos sotaques graças a modelos treinados em corpus diversificados. A IA (LLM) compreende as formulações regionais sem problemas.

Pode-se ditar tarefas a conduzir?

Sim, é um caso de uso concebido. O push-to-talk requer um gesto inicial, mas o feedback háptico e a resposta TTS permitem ditar e confirmar sem olhar para o ecrã. Atenção: a validação final (toque em "Confirmar") requer um olhar — uma futura versão poderá adicionar a confirmação por voz.

O Ditafone consome muita bateria?

Não. O push-to-talk só ativa o microfone durante o ditado (alguns segundos). A ligação WebSocket é leve e persistente. O consumo principal vem do LLM e do TTS, que são chamadas de rede pontuais. Em utilização normal (5-10 ditados por dia), o impacto na bateria é negligenciável.