A ficha que se pode corrigir à mão

Uma ficha ditada tem sempre qualquer coisa errada, e até 12 de maio a única correção possível era dizer tudo outra vez. Nesse dia cada palavra da ficha passou a tocar-se e reescrever-se, os passos de uma receita assinalam-se, e a ficha apaga-se a partir dela própria. Foi preciso redesenhar uma caixa que o Android não mostrava, e resgatar três vezes a última frase que o botão «Concluído» engolia.

Uma ficha que só se podia voltar a ditar

Na véspera, a ficha tinha aprendido a preencher-se em campos declarados: um título, etiquetas, secções de ingredientes, passos. Mostrava-se limpa. Tinha um defeito que ninguém via enquanto não a usava a sério: era só de leitura.

E uma ficha ditada nunca fica totalmente certa. «Oitocentos gramas» transforma-se em «oito gramas». Um passo escorrega para o sítio errado. A etiqueta da preparação diz trinta minutos quando a massa precisa de uma hora com o repouso. São erros de um segundo, e a única resposta disponível era voltar a falar para repetir tudo, na esperança de que o segundo ditado não falhasse noutro sítio.

É o tipo de defeito que decide o uso real de um objeto. Uma ficha que não se pode corrigir é uma ficha que se acaba por deixar de abrir, porque já não se confia no que ela diz.

A manhã: uma receita que se cozinha a sério

O dia começou pelo caso de uso mais concreto: cozinhar com a ficha aberta.

Os ingredientes já tinham as suas caixas. Os passos, esses, eram apenas uma lista numerada. Tornámo-los tocáveis: um dedo sobre um passo, e o seu número passa de azul a cinzento, o texto fica riscado e esbatido. Os passos que restam mantêm o número azul, de modo que o olho encontra sozinho a próxima coisa a fazer. Os dois contadores estão separados de propósito: o que se tirou do frigorífico e o que já se fez não se misturam.

Um detalhe pediu mais reflexão do que parece. Uma segunda barra de progresso, para os passos, só aparece no momento em que se assinala o primeiro. Enquanto não se começou a cozinhar, a ficha fica calma, com uma única barra para os ingredientes. Uma ficha que mostra dois indicadores vazios ao abrir parece um painel de controlo, e ninguém quer um painel de controlo na cozinha.

Seguiram-se dois ajustes. A ficha assenta agora sobre um fundo ligeiramente creme enquanto os seus cartões de ingredientes continuam de um branco puro, para que os cartões flutuem em vez de se fundirem na página. E a memória recebeu uma instrução rígida para as suas receitas: os ingredientes agrupam-se por família, carne, peixe, legumes, farináceos, laticínios, especiarias, acabamento, nunca numa única lista plana. Uma lista plana de dezoito ingredientes lê-se mal no supermercado. Sete listas curtas leem-se corredor a corredor.

A caixa que não existia no Android

O primeiro percalço do dia foi visual, e foi instrutivo.

A caixa assinalada devia mostrar um pequeno degradê, de ciano a azul, com um visto branco lá dentro. Estava desenhada com uma biblioteca de gráficos vetoriais, metida numa moldura que cortava o que ultrapassasse os seus cantos arredondados, e pousada sobre uma sombra suave. No iPhone, perfeito. No Android, a caixa assinalada mostrava o seu halo azul e nada lá dentro: nem degradê, nem visto. Um quadrado vazio com sombra.

A causa é uma combinação conhecida de quem faz aplicações Android e desconhecida de todos os outros. No Android, uma sombra é calculada pelo sistema a partir de uma elevação, e essa elevação não se dá bem com uma moldura que recorta o seu conteúdo. O desenho vetorial lá dentro simplesmente nunca era renderizado. Nada falhava, nada avisava.

Em vez de procurar a combinação de definições que satisfaça as duas plataformas, a caixa foi redesenhada de uma peça com um motor gráfico que pinta diretamente no ecrã: o retângulo arredondado, o degradê e o traço do visto são desenhados numa única tela, numa única passagem nativa. A moldura que recortava desapareceu, a sombra ficou na vista exterior, onde o Android a espera. O visto é uma curva traçada à mão, três pontos unidos por um traço arredondado, em vez de um carácter de fonte cujo aspeto muda conforme o telemóvel.

A lição é simples: quando duas camadas de uma interface disputam o mesmo píxel, é melhor que só uma o pinte.

Tocar numa palavra para a mudar

Depois veio o editor, que é o coração do dia.

Um pequeno menu no canto superior direito da ficha propõe duas coisas: modificar, apagar. «Modificar» não faz aparecer um formulário. A ficha fica exatamente igual, exceto que tudo o que se pode mudar fica sublinhado com um tracejado discreto: o título, a citação de origem, a nota de memória, cada etiqueta, cada título de secção, cada nome de ingrediente e a sua quantidade, cada título de passo, o seu texto, a sua duração. Toca-se numa palavra, transforma-se num campo de texto com o cursor lá dentro. Escreve-se, sai-se do campo, está guardado.

A escolha de um único campo ativo de cada vez não é apenas estética. Um campo de texto custa muito mais a mostrar do que um simples texto, sobretudo no Android e sobretudo se aceitar várias linhas. Uma ficha de receita com quarenta campos todos ativos ao mesmo tempo começa a engasgar-se ao deslizar, e o teclado salta mal se lhe toca. Um campo de cada vez é uma ficha que continua a ser uma ficha até ao momento preciso em que se quer escrever nela.

À volta deste gesto de base, alguns acrescentos: uma etiqueta a mais, uma cruz para retirar uma, um ingrediente ou um passo a mais em qualquer secção, uma secção inteira a menos, uma lista ou uma sequência de passos nova no fundo da ficha. E uma pastilha «Concluído» no canto superior esquerdo para sair do modo de edição.

Cada modificação parte imediatamente para o servidor. A rota que até então só aceitava uma mudança de estado de uma memória, ativa, arquivada, silenciada, aceita agora também o seu conteúdo, os seus metadados e os seus temas, com a mesma regra de antes: só se modifica o que nos pertence, e o servidor verifica-o por si próprio. A transformação profunda de uma memória, a que lhe guarda a história na memória neural, continua a passar pela conversa. Esta rota é feita para retoques, não para revisões.

Apagar, por fim, pede uma confirmação e depois elimina a ficha de vez e fecha o painel. É a única operação verdadeiramente destrutiva de todo o dia, e a única que faz uma pergunta antes de agir.

O título que voltava atrás

O segundo percalço era mais sorrateiro, porque parecia uma avaria quando tudo funcionava.

Toca-se no título, corrige-se, sai-se do campo: o título antigo reaparece. Fecha-se a ficha, volta-se a abrir: o título novo está lá. A modificação tinha ficado guardada, só se recusava a mostrar-se de imediato.

A explicação está em quem possui o dado no ecrã. A ficha guardava uma cópia local do seu conteúdo para mostrar a correção sem esperar pelo servidor, e realinhava-se pelo que o seu elemento pai lhe dava sempre que este mudava. Mas o pai redesenha-se por mil razões que nada têm a ver com o conteúdo, e de cada vez estendia à ficha um objeto tecnicamente novo, de conteúdo idêntico. A ficha tomava esse objeto novo por uma verdadeira atualização e esmagava a sua correção fresca com a versão anterior. A correção só voltava ao reabrir, quando o pai tinha finalmente recarregado o dado real.

A solução não é um remendo, é uma mudança de casa. A cópia local saiu da ficha e subiu um andar, para o painel que a mostra: é ele que aplica a correção no ecrã primeiro, envia a gravação depois, e só se ressincroniza quando se muda mesmo para outra memória. A ficha voltou a ser o que sempre devia ter sido, um puro mostrador do que lhe é dado.

Na mesma passagem, uma quantidade um pouco longa, «quatro pedaços, oitocentos gramas» ao lado de um nome de ingrediente também um pouco longo, transbordava da sua linha e saía do cartão. Nome e quantidade foram empilhados em coluna em vez de alinhados lado a lado: a quantidade passa para baixo do nome, e já nada ultrapassa.

«Concluído» engolia a última frase

O terceiro percalço resistiu três vezes, e é o mais interessante do dia para quem constrói interfaces.

O cenário: modifica-se a duração de um passo, escreve-se «quarenta minutos» e, sem sair do campo, toca-se diretamente em «Concluído». A ficha volta ao modo de leitura. A duração mostra o valor antigo. Nada partiu para o servidor.

O que acontecia: o campo de texto guarda o seu valor no momento em que perde o foco. Mas «Concluído» desmonta o modo de edição de uma vez, e o campo é retirado do ecrã antes de ter perdido o foco. Os caracteres escritos viviam num rascunho, e o rascunho desaparecia com o campo.

Primeira resposta: o campo vigia agora o sinal de edição do seu pai. Se passar a «leitura» enquanto o campo ainda tem o foco, este guarda o seu rascunho antes de ser retirado. Segunda resposta, com cinto e suspensórios: o botão «Concluído» começa por baixar o teclado, o que faz o campo ativo perder o foco de forma natural, e só depois muda de modo.

Chegou para o título, as etiquetas, os ingredientes. Não para os passos.

Os passos tinham uma particularidade: em modo de leitura, cada linha de passo é um elemento tocável, para se poder assinalar. Em modo de edição, é um simples contentor. Duas naturezas diferentes. Ao passar de uma para a outra, o sistema de apresentação não atualiza a linha, destrói-a e fabrica uma nova. O campo de texto lá dentro é destruído com ela, antes mesmo de a sua vigilância do sinal de edição ter tido tempo de reagir. A primeira resposta estava certa, chegava tarde demais.

A terceira resposta executa-se no próprio momento da destruição do campo: se o campo tinha o foco e o seu rascunho difere do valor de origem, guarda o rascunho no seu último fôlego. Um ponto técnico conta aqui: nesse instante, o estado capturado na última pintura já não é fiável, é preciso ler os valores em referências mantidas atualizadas em contínuo. O mesmo mecanismo cobre de passagem a eliminação de uma secção enquanto se escreve nela, e qualquer outro caso em que a árvore de apresentação mude de forma à volta de um campo ativo.

Duas migalhas para terminar. Uma etiqueta de preparação que dizia «trinta minutos, mais repouso» estava bloqueada em vinte e oito caracteres e recusava a escrita: o limite subiu para sessenta. E o servidor escreve agora uma linha no seu registo a cada retoque recebido, e outra se a base de dados o recusar. Da próxima vez que uma modificação «não parecer guardada», saber-se-á numa leitura se o pedido nunca partiu ou se foi recusado à chegada. São duas avarias diferentes, e até então tinham a mesma cara.

O que o dia mudou

Estes trabalhos parecem remendos de interface. Aguentam-se juntos por uma ideia.

Uma ficha que a memória preenche por nós só vale alguma coisa se a pudermos voltar a tomar em mãos. Ditar é rápido, e é precisamente por isso que se deixam lá erros. No dia em que corrigir um erro custa menos do que deixá-lo, a ficha torna-se um objeto em que se confia. No dia em que uma lista se assinala passo a passo com as mãos cheias de farinha, saiu do telemóvel para entrar na cozinha.

O resto, a caixa invisível, o título que recuava, a frase engolida, é o custo dessa promessa. Cada um dos três defeitos tinha o mesmo sintoma, «a minha alteração não é aceite», e três causas sem qualquer relação. Foi isso que tornou o dia longo: sempre que o assunto parecia arrumado, o mesmo sintoma voltava por outra porta. Aprendemos a deixar de confiar no sintoma, e a procurar a causa de cada vez como se fosse a primeira.