Duas tiranias acidentais do software

Apps fecharam as fronteiras

Matuschak abre com uma afirmação simples e desconfortável: o software pessoal prometia ferramentas sob medida, mas virou uma paisagem de monolitos e cercas. O modelo de app, argumenta ele, empurrou os criadores a montar pacotes voltados ao maior mercado possível, e os usuários ficaram capazes de tocar apenas nos botões que o fornecedor oferecia. O resultado, diz, é que os fluxos de trabalho cedem mal ao que as pessoas realmente precisam.

Nos deixamos levar sem perceber por duas teorias acidentais. A primeira é o modelo de aplicação, e isso levou a pacotes de tamanho único.

Vivemos numa paisagem de jardins murados, e o resultado é que nossos fluxos de trabalho muitas vezes não funcionam do jeito que queremos.

O próximo alvo é a própria programação, que Matuschak não descreve como uma linguagem universal, mas como uma especialização que ocupou espaço demais. Em vez de virar alfabetização de massa, diz ele, ficou nas mãos de uma pequena classe técnica, e isso acabou desacelerando a invenção até mesmo dentro da indústria e da pesquisa em HCI^*. Não é só uma queixa contra usuários passivos; é uma acusação à cultura que decide quem pode imaginar novas ferramentas.

Não criamos uma nova alfabetização universal; criamos um sacerdócio especializado.

A versão familiar dessa queixa é que os usuários finais são relegados ao papel de consumidores passivos do meio dinâmico.

Agentes abrem as bordas

Matuschak diz que os agentes de código finalmente estão tornando prático um antigo ambição de HCI: deixar os usuários ampliarem o software que realmente usam, sem reescrevê-lo do zero. O alvo não são recursos marginais, mas as superfícies centrais do trabalho — aquelas que hoje continuam trancadas dentro de apps enormes e rígidos. Na leitura dele, a mudança ainda não é uma revolução de massa, mas o primeiro espaço que os agentes abrem dentro da vida cotidiana de não programadores.

Quero ver o sonho da mídia pessoal dinâmica realizado para as partes mais importantes da prática das pessoas.

Essas partes muitas vezes acontecem em apps enormes, extremamente complexos.

A medida dessa mudança é cautelosa. Ele diz que vê painéis pessoais, automações, scripts que conectam sistemas incompatíveis, mas admite que, por enquanto, os agentes produzem sobretudo glue code nas margens do trabalho real, não extensões profundas das interfaces principais. É uma transição importante: a tecnologia que promete democratizar a programação parece, por ora, melhor em costurar do que em reinventar.

Para Matuschak, o problema é estrutural: plugins tradicionais vivem em painéis separados, enquanto a parte do software que realmente importa continua intocada. Em apps como Photoshop ou Premiere, observa ele, uma extensão que tocasse a superfície principal teria de recriar quase toda a complexidade do app, e isso desanima tanto desenvolvedores quanto ferramentas automatizadas. , diz ele em essência, porque a alternativa seria um caos difícil de governar.

Se quisermos sair de monólitos em silos, vamos precisar de um substrato mais maleável do que os agentes de código zero a um de hoje.

Se plugins pudessem entrar e mudar as coisas, o caos chegaria rápido.

Obsidian como teste prático

Na demonstração, a questão não é outro recurso chamativo, mas o fato de duas extensões diferentes coexistirem no mesmo editor sem reconstruir todo o resto do zero. Matuschak mostra primeiro um plugin que ancora citações ao EPUB, depois outro que sincroniza áudio e transcrição, para chegar a uma tese simples: , enquanto a composição a torna de fato utilizável.

Agora ainda é só um documento Markdown. Mas daqui para frente é texto puro, então posso estender meus comentários, mover tudo para dentro do documento, copiar, colar, tratar isso como um meio.

Aqui tenho uma nova ideia, um tipo diferente de diretiva Markdown que chamei de diretiva de transcrição. Posso apertar play e obter a reprodução de áudio sincronizada com a transcrição do texto.

A sequência serve a uma demonstração precisa. Se um novo comportamento pode ser inserido, separado, copiado e até combinado com outro comportamento sem perder o resto do editor, então o plugin não é decoração, mas infraestrutura. É aí que o argumento sai de truques individuais e vai para a arquitetura que os torna possíveis.

O que é empolgante nesta demo não é o design de interação daqueles plugins. O que é empolgante é que isso não é um sistema de pesquisa: eu o trouxe para o Obsidian, um processador de texto de produção que eu realmente uso.

Aqui Matuschak insiste na fronteira entre laboratório e uso cotidiano. Uma interface interessante, sugere ele, é ruim se vive só num artigo, porque o usuário ainda precisa sair do próprio ambiente e pagar o custo de um software separado. O Obsidian, assim, vira prova de que invenção útil não é só o que funciona, mas o que entra no fluxo normal de trabalho.

Leitura como meio dinâmico

Em , Matuschak muda dos apps para a leitura. Se sistemas de escrita podem ser estendidos por plugins que atuam sobre o mesmo texto e os mesmos estados, diz ele, então a pergunta real é por que a leitura ainda fica confinada a PDFs e páginas estáticas, como se o suporte cognitivo tivesse de terminar na margem. Seu movimento é generalizar a lógica do CodeMirror para um reader que não apenas exibe conteúdo, mas o torna combinável, anotável, vivo.

O problema, na verdade, é pior do que precisar de ferramentas extensíveis para profissionais. Leitores sérios nem têm ferramentas profissionais em primeiro lugar.

Nossos ambientes de leitura evoluíram muito pouco. E, no entanto, há tanto espaço para eles evoluírem.

Aqui o argumento muda de escala. Matuschak insiste que o meio da leitura deveria fazer pelo entendimento o que o Figma faz pelo layout ou um mixer faz pelo som: absorver parte da carga mental e tornar os efeitos das escolhas visíveis quase em tempo real. Hoje, argumenta ele, as pessoas ainda trabalham sobre imagens de papel numa tela, enquanto o texto permanece inerte e o leitor carrega todo o peso.

Quando itero num sistema de design no Figma, consigo ver em tempo real como minhas escolhas afetam o layout e o peso em todas as telas do app que estou projetando. Quando mixo uma faixa, os visualizadores de espectro me ajudam a identificar e corrigir rapidamente trechos embolados.

Para mostrar que não está falando de forma abstrata, Matuschak lista uma pequena genealogia de leitores aumentados já existentes: Skim, SiteSee, Papio, Liquid Text, Space Ink, Quantum Country^*. Mas o ponto não é celebrar cada projeto individualmente. É que todos continuam segregados em seus próprios sistemas, obrigando qualquer pessoa que queira usá-los a trocar de leitor o tempo todo, assim como as primeiras demos de plugins ficaram presas num protótipo de laboratório.

Programação desacelera a invenção

Para Matuschak, o problema já não é só escrever código mais rápido. O verdadeiro gargalo é que a programação ocupou espaço cultural demais na invenção de interfaces, deixando design e conhecimento de domínio em segundo plano. Assim, argumenta ele, mesmo quando a área celebra criatividade, muitas vezes acaba produzindo variações cautelosas de formas já conhecidas.

Acho que o problema central é que inventar no meio dinâmico exige programação demais.

Se novas interfaces são bloqueadas sobretudo por trabalho imaginativo de design e conhecimento profundo de domínio, então essa assimetria coloca pressão seletiva nas habilidades erradas.

Matuschak invoca Alan Cooper e *The Inmates Are Running the Asylum*, o livro que nos anos 1990 acusou programadores de impor interfaces feias e hostis. Ele diz que essa crítica já produziu um ajuste útil, porque a especialização abriu espaço para design de interação e padrões de interface se espalharam. Mas, para ele, o problema antigo era só a primeira camada.

Cooper se preocupava com uma tirania acidental de programadores submetendo as pessoas a interfaces de usuário ridiculamente ruins. Eu me preocupo com uma tirania acidental de programadores freando a imaginação nas interfaces de usuário.

A virada decisiva, na leitura dele, é cultural: quase todo ambiente que fala de interfaces acaba povoado por programadores, treinados mais em análise do que em design ou trabalho de domínio. Matuschak insiste que isso cria uma seleção distorcida, porque não programadores continuam dependentes de outros justamente quando deveriam iterar, errar e de fato usar o protótipo. Nesse ponto, diz ele, o trabalho deriva para o que é mais fácil fazer sozinho — muitas vezes design visual — enquanto a parte realmente dinâmica continua inacabada.

Programação sem design ou conhecimento de domínio pode produzir interfaces funcionais, ainda que muitas vezes chatas ou defeituosas, enquanto design ou conhecimento de domínio sem programação fica parado na prancheta.

O custo e o futuro do protótipo

Matuschak encerra deslocando o peso do código para o custo mental de passar horas nele, sem recuar da aposta. Agentes, diz ele, podem fragmentar a atenção e facilitar uma espécie de agitação produtiva que parece demais uma fuga do pensamento lento; ainda assim, continuam sendo, para ele, a melhor forma de fazer mais ideias entrarem cedo no pipeline do produto.

Os custos são reais, mas estamos arcando com eles por enquanto porque agentes de código são uma boa notícia para a invenção.

Quero aumentar o fluxo imaginativo no topo do funil. Essa fase inicial pressiona menos a qualidade do software.

A distinção dele é nítida: um protótipo precisa ser real o bastante para que designers e colegas sintam como uma ideia se comporta em contexto. É aí que ele cita o valor de protótipos de alta fidelidade para mídia dinâmica, em contraste com artboards estáticos e demos clicáveis que dizem pouco sobre como uma interface realmente se comporta.

Um protótipo precisa ser real o suficiente para permitir que o designer entenda como sua ideia se desenvolve em um contexto autêntico e a comunique claramente aos outros.

Um protótipo de alta fidelidade pode especificar claramente um novo comportamento dinâmico.