Sobrescrevendo o atalho de teclado "localizar na página" do navegador

Olá, sou fã do Discourse, venho de uma pequena comunidade que está discutindo a migração do vBulletin5. Uma pessoa se opôs ao Discourse porque “O sequestro do Ctrl+f é mau” e, depois de entender o que ela queria dizer, tenho que concordar. Há um sério problema de usabilidade na forma como o Discourse lida atualmente com o Ctrl+f, que é o atalho do navegador para “Localizar texto nesta página”.

O problema

  • Às vezes, o Ctrl+f funciona como deveria e o Discourse usa a função de localizar integrada ao navegador, fazendo com que a página role até a primeira ocorrência imediatamente conforme você digita. O Ctrl+G leva você à próxima ocorrência.
    • A vida é boa.
  • Outras vezes, o Ctrl+f não funciona e, em vez disso, mostra uma lista de resultados de uma pesquisa no banco de dados.
    • Ele não rola a página até a primeira ocorrência enquanto o usuário digita.
    • A frase pesquisada é destacada apenas se já estiver na tela.
    • Ele não permite pesquisar termos muito curtos, como “UX”.
    • Ele não aceita Ctrl+G para mostrar a próxima ocorrência.
    • Ele mostra resultados para tópicos irrelevantes que o Ctrl+f não mostraria se não conseguisse encontrar o termo na página.
  • Por que isso falha é completamente invisível para os usuários, mas é extremamente frustrante. Eles sentem que a capacidade de pesquisar dentro de uma página foi retirada sem nenhuma explicação.
  • Não adianta dizer a eles que pressionar Ctrl+f duas vezes fará uma pesquisa no navegador, pois isso falharia ao encontrar posts que realmente existem.

A causa raiz

Isso não é um problema cosmético, mas um problema fundamental de usabilidade que o Discourse precisará corrigir na raiz: a ilusão de que toda uma conversa está realmente no DOM do navegador, quando, na verdade, ela é carregada dinamicamente.

Quando há mais de vinte posts em um tópico, o Discourse envia os posts para o navegador apenas conforme necessário. Você pode visualizar um thread com mais de 1000 posts com quase nenhuma carga no servidor, porque a maior parte do DOM são apenas esqueletos vazios. Essa é uma ideia brilhante, mas é também o que faz o Ctrl+f quebrar misteriosamente.

Não estou sugerindo eliminar a ilusão, pois acho que ela vale a pena. O Discourse fez certo ao abandonar a antiga maneira de dividir conversas em páginas arbitrárias com cerca de 40 posts cada.

O Discourse apenas precisa fazer um trabalho melhor em tornar a ilusão perfeita.

Soluções

Para ser honesto, não sei qual é a melhor solução para isso, mas tenho algumas ideias que espero que sejam úteis.

Quebrando conscientemente a ilusão

Primeiro, aqui estão algumas ideias simples que são razoáveis se o Discourse for quebrar a ilusão ao alternar para uma pesquisa no banco de dados,

  1. Avise o usuário sobre o que está acontecendo. Coloque uma pequena nota onde a caixa de localizar do navegador normalmente apareceria, com um pedido de desculpas e uma explicação.
  • “Pedimos desculpas, mas este tópico tem 1002 posts, e seu navegador tem apenas 7__deles carregados, então a função Localizar na Página provavelmente não funcionará. Se você quiser tentar mesmo assim, pressione Ctrl+f novamente.”
  1. Dê algum controle ao usuário. Quando um usuário pressionar Ctrl+f, mostre um botão para que os usuários possam carregar manualmente o texto de todos os posts do tópico no DOM.
  • Se isso for considerado impossível devido ao limite de 100 posts armazenados em cache no navegador de uma só vez, mostre um botão que permita aos usuários voltar ao antigo modo de visualização de tópicos: divididos por página.
  • “Clique aqui para ver este tópico de uma forma que funciona com Ctrl+f: [Página 1] [2] [3] [4] [5] [6] [7] [8] [9] […] [>>]”
  1. Aumente o limite padrão de 20 posts para 100 posts. Isso pode não ser muito difícil de alterar, já que o Discourse já consegue armazenar esse número de posts em cache no DOM.

Reparando a ilusão

Claro, essas ideias são feias e eu as considero apenas soluções temporárias. Eventualmente, a melhor solução seria o Discourse implementar o Ctrl+f de uma forma que funcione como as pessoas esperam. Replicar no Discourse o que o navegador faz para pesquisas interativas valeria muito a pena, mas imagino que seria difícil.

No entanto, pode haver uma solução (relativamente) simples.

Não remover texto do DOM

Acredito que a melhor solução para o Discourse seja remover apenas objetos de mídia dos posts, não o texto. Assim, não haveria necessidade de “sequestrar o Ctrl+f” e substituí-lo por uma pesquisa no banco de dados.

A função Localizar na Página pesquisa apenas texto, então não há necessidade de o navegador ter todo o DOM carregado para poder pesquisar. O texto é incrivelmente leve para enviar, especialmente se o servidor HTTP tiver a compressão gzip ativada. O texto também não ocupa muita memória em um navegador web.

Vocês sabem disso melhor do que eu, mas tenho algumas suposições:

  • Tamanho médio de um post: 5 KiB de texto
  • Comprimento médio de um tópico: 50 respostas.
  • Texto médio a ser transferido: 250 KiB, o que parece razoável.

Claro, cada byte importa para a responsividade. Se minhas estimativas estiverem erradas e o tamanho do texto for um problema, preencher o DOM com texto poderia ser feito como um processo em segundo plano após as partes importantes da página terem sido enviadas. Se o DOM não tiver sido completamente preenchido com texto no momento em que o usuário pressionar Ctrl+f, um medidor pode aparecer, informando ao usuário para aguardar e mostrando o progresso enquanto o texto vai sendo carregado.

Obrigado

Embora seja um problema sério que o Ctrl+f quebre a ilusão criada pelo Discourse, estou impressionado com o trabalho incrível que os desenvolvedores do Discourse fizeram ao criar essa ilusão em primeiro lugar. Tenho certeza de que eles eventualmente encontrarão a correção certa para isso também.

Obrigado por dedicar seu tempo a considerar minhas sugestões.

Atenciosamente,

Sr.(a) F.N.

3 curtidas

Compartilho sua sensação de que a UX aqui é frustrante e surpreendente. Para mim, é semelhante a dificuldade de tentar rolar para cima e para baixo em um tópico simples com 30 mensagens. É a única coisa sobre o Discourse que me deixa envergonhado.

Fico me perguntando se o equilíbrio entre uma boa UX em threads pequenas e médias versus não quebrar em threads grandes está realmente certo. No meu projeto, threads muito grandes provavelmente não serão um grande problema, então é frustrante ter a UX comprometida pelas necessidades delas.

Lembro de ter lido que o verdadeiro problema que limita a abordagem atual era o tempo de renderização no Android. Se for esse o caso, parece uma pena limitar todos os dispositivos com base nas limitações de alguns.

Gostaria muito de saber se é razoavelmente possível para um desenvolvedor personalizar:
(1) o número de tópicos por bloco (por exemplo, variar conforme o dispositivo)
(2) manter os tópicos já renderizados visíveis, em vez de descarregá-los como ocorre atualmente (o que torna a rolagem de volta ao topo desconfortável)

Agradeço por entender que esta é uma área realmente complexa, sem soluções ideais, e que muito esforço já foi dedicado a ela.

1 curtida

Houve muitas boas ideias sobre isso neste tópico, a implementação atual (ainda) é horrível.
Não faça isso, apenas não substitua atalhos poderosos. Mesmo a antiga abordagem de Quadros de Avisos com vários botões de pesquisa é mais acessível. Encontre uma boa maneira de pesquisar um tópico ou deixe que o usuário carregue todo o conteúdo relevante no DOM (o que também é horrível). Um dos co-fundadores deu o melhor conselho, pressione duas vezes. Parece que somos mais inteligentes…