Dê às pessoas algo para vincular e sobre o qual possam falar
(simonwillison.net)- Se você quer que as pessoas entendam e compartilhem um projeto ou recurso de produto, antes de repetir explicações é preciso ter uma página dedicada na web
- O ChatGPT Code Interpreter, apesar de ser um recurso poderoso, teve nomeação e capacidade de descoberta instáveis na documentação oficial, então explicações feitas por outras pessoas acabaram virando links mais úteis
- Os casos de Claude Artifacts e GitHub Codespaces·Copilot mostram que, quando um recurso se torna um alvo vinculável, fica mais fácil compartilhá-lo e explicá-lo
- Quando um conceito é organizado em uma página separada, como Boring Technology de Dan McKinley, até quem está ouvindo falar dele pela primeira vez consegue acompanhar rapidamente o contexto com um único link
- O valor de uma página dedicada não se limita à visibilidade em buscas: ela também evita que seja necessário repetir a mesma explicação em conversas na web
Por que páginas vinculáveis são necessárias
- Alvos sobre os quais você quer que outras pessoas entendam e conversem, como projetos, ideias ou recursos de produto, precisam de uma página vinculável
- Hiperlinks são o meio básico de expandir conversas na web, pois permitem apontar para uma explicação definitiva sem precisar reescrevê-la toda vez
- Sem uma página dedicada, a atenção e o tráfego de busca podem acabar indo para explicações feitas por terceiros ou para páginas que dominaram os termos de busca
O problema de descoberta do ChatGPT Code Interpreter
- ChatGPT Code Interpreter é um recurso que permite ao ChatGPT escrever e executar código Python durante o processo de resposta
- O recurso em si é poderoso, mas, se você não souber como ativá-lo por prompt, é difícil até perceber que ele existe
- Ao procurar Code Interpreter no site da OpenAI, aparecem uma documentação técnica sobre um recurso de API ou um tópico antigo no fórum, o que causa confusão
- Ao apresentar esse recurso, a página de tag de code-interpreter acaba sendo um link mais útil do que uma página oficial da OpenAI
- Mais tarde, a documentação real foi encontrada, mas o título era Data analysis with ChatGPT, e como o termo “Code Interpreter” não aparecia na página, era difícil encontrá-la
- A OpenAI vem mudando o nome desse recurso entre Code Interpreter, Advanced Data Analysis e Data analysis with ChatGPT
Exemplos de boas páginas de recursos
- O recurso Artifacts do Claude tem ao menos uma página de ajuda fácil de encontrar
- Porém, o post de anúncio do Artifacts foi compartilhado junto com o lançamento do Claude 3.5 Sonnet, então é difícil vê-lo como um alvo de link claro só para Artifacts
- O GitHub oferece páginas de apresentação separadas para cada recurso
- Quando um recurso tem sua própria página dedicada, surge um ponto de referência para explicá-lo, vinculá-lo e compartilhá-lo
Boring Technology: quando um conceito vira um site
- Em 2015, Dan McKinley cunhou o termo Boring Technology no ensaio Choose Boring Technology
- A ideia central é que a capacidade de uma equipe de desenvolvimento para resolver novos problemas é limitada, então essa capacidade deve ser usada nas partes que tornam o produto único
- Nas demais áreas, deve-se escolher a tecnologia mais previsível e mais conhecida, cujos bugs e limitações já foram compreendidos e discutidos por muito tempo na internet
- Essa ideia também foi organizada no site boringtechnology.club
- Quando alguém não conhece esse termo, compartilhar um único link já permite que a pessoa entenda o contexto em poucos minutos
Ideias pessoais também precisam de páginas compartilháveis
- Ideias como baked data, git scraping e prompt injection também foram organizadas em páginas que podem ser compartilhadas com frequência
- Porém, sem até mesmo garantir um domínio separado, a mensagem de que “esta é a página principal que deve ser vinculada” pode ficar mais fraca
- Um alvo de link claro aumenta a capacidade de compartilhamento e de conversa em torno de uma ideia
Um valor que pesa mais nas conversas do que no SEO
- Um dos propósitos mais óbvios de uma página dedicada é o SEO
- Quando usuários pesquisam um recurso do produto, eles devem chegar ao seu site, e não a uma página criada por terceiros
- Mas o valor maior aparece nas conversas
- Ao explicar um conceito, em vez de reescrever um parágrafo, você pode compartilhar um link com a explicação definitiva
- Se você quer que as pessoas entendam e discutam uma ideia, projeto ou recurso, precisa criar uma página da web à altura disso
1 comentários
Comentários do Hacker News
A rsync.net é um serviço que faz bem esse tipo de coisa. Por exemplo, não lembro de ter visto em outros serviços algo como uma página do CEO.
Não sei se isso é realmente útil, e nunca precisei encaminhar nada ao CEO, mas, mesmo não sendo cliente, foi a primeira página que me veio à cabeça assim que li este texto.
[1]: https://www.rsync.net/products/ceopage.html
É uma página pensada para que o participante possa encaminhá-la diretamente ao chefe, sem precisar inventar sozinho uma justificativa profissional convincente.
A esta altura, eu imaginaria que a OpenAI já teria contratado redatores de documentação técnica, mas, pelo LinkedIn, parece que não. Então não é tão surpreendente que a documentação esteja nesse estado ruim.
Não entendo por que eles não contratam uma função dedicada à documentação. Ou acham que não é importante, ou priorizam friamente o crescimento acima da documentação; seja qual for o motivo, no fim estão prejudicando a si mesmos.
O texto referencia https://boringtechnology.club/, que é um excelente slide deck sobre deixar o esforço de inovação apenas para soluções realmente únicas.
No resto, é melhor ir com o máximo possível de tecnologia entediante. Vejo com frequência demais equipes de desenvolvimento tentando inovar até nas camadas mais baixas e perdendo de vista qual valor estão realmente entregando. Quero gravar esse slide deck na minha visão de mundo.
Mais um ótimo texto do Simon. Ontem à noite incorporei esse conceito diretamente em um projeto novo. Eu queria mostrar evidências de que o Google Gemini App censura o yt-dlp, mas a API do Gemini não, e ao mesmo tempo criar um caminho de entrada para o projeto e também os motivos de negócio que o Simon mencionou.
https://topicalsource.dev/chat/84a0d6dd-f66f-4f12-af17-5e99c...
Também usei localStorage para salvar a lista de chats públicos visitados. Assim, quando você volta, consegue ver outros chats que leu, e fica mais fácil encontrá-los do que vasculhar o histórico de mensagens para descobrir de onde veio o link original.
Links mortos são a pior coisa. Será que alguém não consegue criar uma extensão de navegador que use GPT para alucinar o site de um link morto?
Artistas simplesmente linkam sites de redes sociais, mas contas podem ser suspensas e nomes de usuário podem mudar. Desenvolvedores também “linkam” dependências sem considerar que o repositório pode desaparecer; se ninguém tiver feito backup, o código-fonte daquela versão pode desaparecer junto; uma versão de pacote pode ser removida do registro; ou a documentação online da dependência pode sumir.
[1]: simplesmente adicionar nome+versão ao arquivo de manifesto e esquecer para sempre. Mesmo que se adicione cache, não é um espelho de verdade, muito menos uma forma de conseguir compilar por conta própria as dependências em caso de desastre.
Se as pessoas fossem descrevendo, uma por uma, como aquela página era antigamente, ou rastreassem a web em busca de pistas, seria uma ideia bem interessante. Até daria para trazer de volta o banner “em construção”.
Gosto do blog do Simonw. Desde setembro do ano passado, venho lendo o blog dele usando o interpretador Python. Ele disse que começou a fazer isso sozinho para criar aplicações inteiras na hora.
Só que ainda não está claro para mim como fazer. Achei que haveria alguma opção ou botão fácil, mas não encontrei. Eu poderia ter me esforçado mais para descobrir, mas, se houvesse um link prático ou tutorial, acho que eu teria continuado a usar o GPT em vez de ignorá-lo quase por completo.
Nesse contexto, o meme de resposta a incidentes da Square continua vivo em https://outage.party/
Eu odiava de verdade uma boa parte dos produtos da Microsoft justamente por esse motivo. Produtos que mudavam de nome, como VSTS/VSO/Dev Ops, ou coisas como o SharePoint eram especialmente terríveis. Um deep link tinha 700 caracteres, com dezenas de strings de consulta em base64 e caminhos absurdos anexados. Era de enlouquecer aquele tipo de resposta: “Qual é o problema? É só usar um encurtador de URL, não? URLs são longas mesmo, não tem o que fazer”.
Em 2014, uma ferramenta interna da equipe mostrava o estado dos recursos do sistema, e todos os recursos e estados estavam em um banco de dados SQL. Só que a aplicação web era uma SPA de antes de existirem coisas como roteadores, e não atualizava a URL nem aceitava deep links. Para enviar por e-mail ou mensageiro um problema em um recurso específico, era preciso explicar: “Vá à ferramenta X, pesquise por Y e clique em Z -> W -> M -> O -> K; você vai ver ali”. Eu ficava muito irritado por não poder simplesmente compartilhar um link como https://X.com/Y/Z/W/M/O/K para um estado profundamente aninhado. Mesmo falando disso várias vezes, eu só ouvia que “não é prioridade e também não é algo tão grave assim”.
Uma vez tive a oportunidade de trabalhar por duas semanas em algo que eu queria corrigir, e decidi criar uma alternativa que aceitasse deep links. Também fiz com que todos os deep links, ao receberem o prefixo
/api/, retornassem o conteúdo como JSON. Foi um grande sucesso na equipe e na empresa; mesmo a minha ferramenta sendo muito mais simples e tendo menos recursos, o uso da ferramenta X caiu quase da noite para o dia. No fim, a maioria das pessoas queria uma forma fácil de compartilhar links, não uma “SPA poderosa para se aprofundar e investigar”.Um mês depois, a equipe da ferramenta X anunciou com alarde, em um e-mail para a empresa toda, que passaria a aceitar deep links. Mas considerou sem importância o recurso simples de retornar dados JSON com o prefixo
/api/. Cinco anos depois, a UI da minha ferramenta estava ultrapassada, mas o serviço em si foi promovido a serviço interno essencial, porque muitas equipes tinham criado automações em torno das URLs com prefixo/api/; no fim, aquela equipe teve de pegar o código e mantê-lo.Como fã do Simonw, para mencionar algo que ninguém ainda apontou, outros exemplos em que o Simon oferece algo para as pessoas linkarem também funcionam muito bem no HN: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Simon frequentemente resume muito rapidamente notícias em andamento que pessoas próximas da área de IA já conhecem, mas que o público mais amplo ainda não sabe. Ele torna fatos relevantes rapidamente linkáveis e acessíveis, permitindo que pessoas mais distantes do assunto também participem da discussão.
Concordo com a frase “hiperlinks são a melhor coisa da Web”. Mais precisamente, são hiperlinks e URLs.
URLs são a pedra fundamental da Web. Elas nos permitem referenciar textos e outros recursos de uma forma precisa, que esperamos ser universal e duradoura. Sempre fico frustrado ao ver que as pessoas não percebem essa maravilha. Por exemplo, em vez de colar um link em uma mensagem, dizem “procure isso no YouTube”. Dar a um texto um endereço permanente na Web aumenta sua visibilidade e também reduz a necessidade de o autor reescrever a mesma ideia
Ensaio clássico relacionado: Cool URIs don't change. [0][1]
[0] https://www.w3.org/Provider/Style/URI
[1] https://news.ycombinator.com/item?id=23865484
Na prática, o efeito é este: se você está conversando com alguém, ou em uma sessão de perguntas e respostas de uma apresentação, e quer dizer “sim, nós também pensamos nisso, e há informações relacionadas em acmeinitiative.example.com/skub”, mesmo que ainda não tenha escrito o texto em
/skub, naquele momento você pode definir imediatamente/skubcomo o identificador designado para esse texto. O texto pode ser escrito depois e aparecer ali, e quem tiver interesse poderá encontrá-lo por aquela URL a qualquer momento. O mesmo vale para textos escritos por outras pessoas ou recursos externos: você pode criar uma URL improvisada no seu próprio namespace e, depois, quando tiver tempo, redirecioná-la para o link originalJá ouvi muitas gravações, podcasts etc. com profissionais técnicos inteligentes que claramente possuem seus próprios domínios, mas não usam esse método. Em geral, eles murmuram alguma descrição que talvez seja encontrável, ou tentam lembrar o título e acabam falando algo meio errado. Com isso, todos os ouvintes interessados precisam gastar individualmente tempo e atenção para procurar, e uma quantidade enorme de energia coletiva é desperdiçada
O FB bloqueia muitos sites, até blogs aleatórios, sob a justificativa de compartilhamento de conteúdo protegido por direitos autorais; o reddit bloqueia todos os
.ru, vários sites de arquivo, links do Telegram etc. O Twitter bloqueou algumas plataformas de blog, e muitos sites menores também bloqueiam o Discord. O bloqueio ao Discord até pode ser justificável, mas seria bom se essa tendência virasse um motivo para as pessoas saírem de láPrimeiro, ela imediatamente desperta aquela sensação desagradável de AOL Keyword. Segundo, ignora completamente o conceito de bolha de busca. Mesmo usando o mesmo termo de busca, os resultados que você e eu recebemos podem ser muito diferentes. Terceiro, se URLs e hiperlinks já existem, não há necessidade de me dar trabalho extra. Se você mandar o link direto, eu consigo ver exatamente ao que você se referiu, sem precisar me perder entre inúmeros vídeos de reação
Mas muitos sites e serviços não gostam disso, porque veem como uma invasão do seu território de atenção. Quando, como autor, eu linko uma ideia que já expressei cuidadosamente em um post de blog ou em um livro, o comentário é removido ou censurado por “promoção”. Hoje em dia, no HN, para evitar punições, acabo muitas vezes simplesmente copiando e colando o texto original que escrevi, em vez de oferecer um link para que o leitor possa explorar mais a fundo. Há uma lacuna clara entre a boa forma “acadêmica” de disseminar informação que defendemos e a realidade dos sistemas que controlam a expressão