Apenas recursos normais da web

• Com o aumento de novas plataformas de mídia social, clientes, apps e portas web baseadas em React Native, tem se tornado comum que sites percam comportamentos básicos da web que os usuários esperam
• A pressão por lançar rápido, a ausência de engenheiros de UI, o design mobile-first para toque e implementações que substituem comportamentos nativos do navegador com JavaScript são apontados como as principais causas
• Recursos nativos do navegador como copiar texto, clicar com o botão direito em links e usar ctrl + click, zoom do navegador, layout responsivo, :hover e :focus, atualização de URL e histórico, barras de rolagem e ctrl + f devem continuar funcionando normalmente
• Em cartões clicáveis, remover pointer-events ou sobrepor camadas, assim como implementar navegação com div e on-click em vez de âncoras, quebra a experiência normal de links
• Há muita sobreposição com violações de acessibilidade, mas apps web devem manter os recursos normais da web que os usuários esperam, em vez de tentar parecer apps móveis

---

Comportamentos básicos que os sites perderam

• É cada vez mais comum que projetos web bloqueiem recursos normais da web que os usuários esperam
• Com o aumento de novas plataformas de mídia social, surgem vários clientes e apps, e também há muitos casos de tentativa de compartilhar código entre plataformas, como com React Native
• Essas tentativas em si são positivas, mas junto com requisitos básicos de acessibilidade, como texto alt em imagens, também acabam faltando formas normais de interação na web
• Entre as causas, podemos destacar:
  • pressão para lançar rapidamente algo em um nível testável
  • ausência de engenheiros de UI no projeto
  • design que prioriza entrada por toque no mobile e ignora outros métodos de entrada ou dispositivos
  • implementações que contornam ou substituem comportamentos nativos do navegador com JavaScript

Recursos normais da web que devem ser mantidos

• Deve ser possível copiar texto
  • Em componentes de cartão clicáveis, remover pointer-events ou sobrepor camadas clicáveis pode impedir a seleção e a cópia de texto
• Elementos que navegam como links devem oferecer a funcionalidade de link normalmente
  • Deve ser possível abrir o menu de contexto com o botão direito para copiar o texto do link ou o endereço
  • Atalhos comuns de link para abrir em nova aba, como ctrl + click no Windows, devem funcionar
  • Em vez de mover a navegação com on-click em uma div, deve-se usar um elemento âncora
• Ao usar o zoom do navegador, o layout não deve quebrar, e o usuário deve poder ampliar para ler
• Em vez de cair simplesmente em um layout móvel ao ficar mais estreita que 1200px, uma web responsiva deve usar bem o espaço mesmo em viewports menores
  • Mastodon e Twitter podem ser vistos como exemplos em que a UI continua familiar e o espaço é, em geral, bem aproveitado quando a largura do navegador diminui
• Apps web devem oferecer corretamente estados de interação como :hover, :focus e :active
  • Em casos de apps React Native portados para a web, às vezes não há estilos de :hover ou :focus, ou aparece um estilo de :active estranho, como se estivesse desabilitado
• Se, após um clique, a UI mudar completamente como se fosse uma nova página, o histórico do navegador e a URL também devem mudar junto
  • Se não for possível criar link para um estado de UI que parece uma página independente, e esse estado desaparecer após navegar, a usabilidade piora
• Barras de rolagem não devem ser ocultadas
  • O usuário pode querer clicar e arrastar a barra de rolagem
• Atalhos normais do navegador não devem ser interceptados por funções internas do app
  • Se ctrl + f abrir uma busca customizada do app, a busca na página pode deixar de funcionar como de costume
• Há bastante sobreposição com itens que podem ser vistos como violações de acessibilidade, mas o foco aqui é evitar que apps web quebrem as expectativas básicas de navegador dos usuários
• Casos omitidos podem continuar sendo discutidos no Mastodon

[plastic041]

Parece que o conteúdo principal está incorreto.

[xguru]

Nossa, que curioso. Parece que o rastreamento desse próprio post do blog está ficando meio estranho. Acho que vou dar uma olhada na parte do crawler.

[GN⁺]

Comentários do Hacker News

• Quando você aprende web primeiro com React e só depois aprende HTML, pode acabar deixando de se importar com o comportamento padrão dos links
  Quando entrei na equipe, todos os links eram botões, elementos arbitrários ou eram tratados com onClick; ninguém reclamava, mas Ctrl+clique era inútil e o menu de clique direito não oferecia as opções esperadas
  Acho que, quando se trata de links, não há espaço para negociação

  • Eu realmente odeio esse abuso de JS, que está quebrando cada vez mais coisas que deveriam ser feitas do jeito correto
    Até uma plataforma de documentação chamada archbee, que recebeu investimento da YC, não permite abrir resultados de busca em uma nova aba; é preciso abrir um no separador atual ou então voltar, pesquisar de novo e abrir o próximo resultado
    Dá para ver o exemplo aqui: https://docs.sparklayer.io/
  • Na nova versão web do Reddit, todos os links são botões, então não dá para abrir em uma nova aba
    É muito estranho e enlouquecedor que um serviço de internet tão grande tenha um problema de acessibilidade tão óbvio
  • Cerca de metade do motivo de eu usar nitter em vez do Twitter é isso
    Também tem o fato de não precisar de conta, mas eu consigo clicar com o botão direito em threads de tweets e abri-las em uma nova aba
    Pela natureza das conversas no Twitter, eu quero abrir várias threads em novas abas mantendo a posição da página original, mas a UI real do Twitter torna isso bem difícil
  • A questão dos links é uma colina em que vale resistir até o fim, sempre
    Poucas coisas me incomodam mais do que isso; se tivesse que citar uma, seria quebrar o histórico de navegação do navegador
  • Em sites com uma tela de lista e uma tela de detalhes, é um desastre de uso da web quando não dá para clicar com o botão direito em um item, ou usar uma extensão, para abrir a tela de detalhes em uma nova aba
    Se o voltar funcionasse de forma imediata e fluida, até daria para perdoar, mas na prática você fica esperando o conteúdo recarregar e ainda perde a posição da rolagem
    Pior ainda são sites como o Facebook, que forçam o mesmo estado de pop-up de chat em várias abas. Se você fecha em uma aba, fecha nas outras também, sendo que há um motivo para ter várias abas abertas

• No momento em que se mexe no comportamento fornecido por padrão, acho que se assume também a responsabilidade por ele
  A “funcionalidade” criada não fica restrita ao escopo estreito pretendido pelo designer; ela passa a fazer parte de toda a experiência que o visitante realmente vivencia
  Se você muda a lógica do botão de voltar, está mudando o próprio significado que voltar tem naquele site, e também precisa assumir a responsabilidade por usuários confusos e irritados xingarem o “site quebrado” como consequência
  É preciso pensar se você está mesmo preparado para se responsabilizar até por comportamentos que variam entre navegadores e sistemas operacionais, como a barra de rolagem
  No fim, é como fazer o site falar uma espécie de crioulo, então não é de surpreender se o visitante não entender essa língua ou a “interpretar errado”
  Esses recursos não são apenas algo a evitar por gentileza com o visitante; os ganhos parecem limitados e os prejuízos, quase ilimitados

  • É isso mesmo. Sites se beneficiam de idiomas de design lapidados ao longo de muito tempo
    Sites que ignoram esses idiomas ficam mais difíceis de usar porque não falam a linguagem com a qual os usuários estão acostumados
    Há também um texto longo sobre a perda dos idiomas de design: https://loeber.substack.com/p/4-bring-back-idiomatic-design

• Penso nisso como a appificação dos sites, e isso precisa parar agora
  Sites devem voltar para renderização do lado do servidor e acrescentar apenas o JavaScript necessário
  Por outro lado, apps web podem lidar um pouco mais com a UX se isso tiver valor para o usuário, mas, enquanto estiverem dentro do navegador, os princípios básicos ainda se aplicam
  Apoio apps web como uma plataforma de desenvolvimento acessível a todos fora dos muros das app stores, mas precisamos parar de tratar todo site como se fosse um app
  Se é uma página que você quer que apareça nos resultados de mecanismos de busca, então não é um app web, é um site

  • Seria bom se, para documentos brutos, o navegador pudesse enviar Accept: text/markdown, mas acho que esse navio já zarpou no momento em que o CSS apareceu
  • Talvez você goste deste texto: https://notan.app/
  • Concordo com a frase “sites devem voltar para renderização do lado do servidor e um pouco de JS”
    Felizmente, graças a coisas como React Server Components, parece que estamos voltando à direção de adicionar JavaScript aos poucos aos sites, o que é bom
  • Um bom app web também pode ser um site
    É um problema possível, se for dedicado tempo suficiente a ele

• Não entendo por que sites de bancos bloqueiam colar
  Quando você percebe que não pode colar, já copiou o texto
  Digitar à mão aumenta a chance de erro e, se a área de transferência estiver contaminada, no momento em que você percebe a proibição de colar, a cópia já foi feita

  • Parece que algum lugar tipo “Introdução à programação de formulários” inclui código para bloquear copiar e colar, e essa ideia deixou milhares de descendentes pela web inteira
    Parece que as pessoas imaginam que isso é uma medida de segurança e passam a copiar voluntariamente
    Para começo de conversa, não entendo o motivo de bloquear o usuário de colar
  • O site do meu banco não só bloqueia colar a “senha”, como também bloqueia a entrada pelo teclado
    Essa “senha” tem míseros 6 dígitos e eu nem posso defini-la. Como se 6 dígitos fossem muito mais seguros do que uma string aleatória de 16 caracteres gerada por um gerenciador de senhas
    Ele obriga a entrada por botões em posições aleatórias na página, mas, se o dispositivo já está infectado a ponto de ter teclas e cliques registrados, acho que o atacante também conseguiria simplesmente ler a senha na memória do navegador
  • Há alguns dias me cadastrei em um novo ISP e o campo de senha bloqueava colar, quebrando o gerenciador de senhas
    Do ponto de vista de segurança, é uma decisão incrivelmente ruim
  • Normalmente começa quando uma empresa está tendo problemas com tráfego de bots
    Tentam várias coisas para atrapalhar os bots e, um dia, desenvolvedores pressionados por um gerente intermediário bloqueiam copiar e colar na página de login, e os bots param por um instante
    Alguns dias depois os bots contornam isso, mas a “correção” anterior fica ali com a ideia de que “talvez bloqueie alguns bots”
    Assim, umas 10 linhas de JavaScript sobrevivem até a reescrita v6 e, meses ou anos depois do novo começo, a mesma proibição volta a ser incluída
    De forma alguma estou falando por experiência própria
  • Não estou dizendo que seja esse o caso, mas já existiu malware de área de transferência que, se o conteúdo copiado parecesse um endereço de Bitcoin, o trocava pelo endereço dele próprio
    https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
    Talvez tenham pensado em algo desse tipo

• Fico irritado quando desenvolvedores de JS extravagantes escondem complexidade e funcionalidades que ninguém pediu por trás de menus select que parecem HTML nativo
  Vejo isso com frequência em entradas de cidade e estado: a cidade é um campo de texto e o estado é um menu suspenso/select
  Como sou do Texas, eu digito a cidade, uso Tab para ir ao menu de estado, aperto t, t e passo para o próximo elemento do formulário
  Só que hoje em dia muitas vezes é uma entrada de busca textual fantasiada de dropdown, então t, t vira literalmente uma busca por tt, em vez de selecionar Texas depois de Tennessee
  Só funciona como esperado para quem clica no triângulo com o mouse e rola a lista de estados
  Se não está quebrado, não conserte

  • Isso, em grande parte, era um problema causado por uma lacuna da plataforma web
    Historicamente, o <select> de verdade era muito difícil ou impossível de estilizar ou ter seu comportamento estendido, então muitos apps o reimplementaram por conta própria, geralmente de forma péssima
    Parece que estão surgindo novos substitutos nativos que podem ser estilizados
    Além disso, como era difícil compartilhar código entre apps, frameworks e empresas, só grandes empresas conseguiam criar substitutos de componentes nativos com funcionalidade completa, acessibilidade e customização
    Web Components podem resolver isso permitindo colaboração global em componentes comuns de ponta, como <select>
    Texto relacionado: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...

• Acho que boa parte do comportamento quebrado de links vem da falta de métodos de nível mais alto para sobrescrever o comportamento padrão de links
  Por exemplo, eu não quero anexar um listener de evento de clique só para abrir um link em um modal. O evento de clique é baixo demais em nível, então preciso verificar manualmente as teclas modificadoras
  O que eu realmente quero é dizer ao navegador: “se a URL da janela atual estiver prestes a mudar por causa deste elemento âncora, chame esta função em vez disso”
  Assim, o usuário pode abrir livremente o link em uma nova janela ou nova aba e, nesse caso, meu código não é executado
  Com CSS é a mesma coisa: não quero especificar imagens de cursor para todos os elementos e pseudoclasses. Quero dizer: “onde você usaria o cursor padrão de mão/espera/redimensionamento, use esta imagem customizada”
  Assim, mesmo que surjam novos elementos ou UIs, o código fica preparado para o futuro
  Algumas APIs de navegador parecem sofrer às vezes do problema XY

  • Isso é bem possível com JavaScript
    Basta registrar onclick na tag e, no manipulador de evento, cancelar a navegação padrão
    Se o usuário desativar JavaScript, o site continua funcionando bem, e comportamentos nativos do navegador, como o menu de link com clique direito ou Ctrl+clique, também continuam funcionando
    Só que é um “truque” bastante obscuro; seria bom se a API do DOM facilitasse mais isso
  • https://developer.mozilla.org/en-US/docs/Web/API/Navigation_...
    Acho que esse é um caso de uso da Navigation API
  • Finalmente vi meu pensamento expresso online
    O que precisamos não é de eventos de clique ou ponteiro, mas de um evento visit de nível mais alto

• Quando vi o Flutter Gallery pela primeira vez, fiquei surpreso porque tudo parecia quebrado no navegador web: https://gallery.flutter.dev
  Acho que o exemplo Reply em especial era assim
  Ctrl+clique ou botão do meio do mouse em links não funcionavam, clique direito também não, seleção e cópia de texto não funcionavam, pela estrutura técnica não dava para inspecionar elementos, e nada acontecia ao tentar dar zoom na página
  Lembrando dessa experiência e de algumas implementações de SPA feitas com tecnologias mais tradicionais, este texto me parece correto

  • Flutter é mais um beco sem saída no caminho rumo a um framework de desenvolvimento unificado
    Seja na web ou no mobile, nenhum demo de Flutter jamais me convenceu de que oferece uma UX aceitável
  • Parece que ele também lida de forma estranha com seleção de texto em navegadores móveis
    Se a promessa do Flutter é ser igual em todos os lugares, este demo deve ser igualmente ruim no desktop

• Também gostaria que o comportamento de rolagem não fosse sobrescrito
  Não se deve tentar melhorá-lo para deixar a rolagem “mais suave”
  No Windows pode parecer aceitável, mas no Mac, ao usar dispositivos de entrada da Apple, o movimento do dedo no trackpad ou no mouse corresponde 1:1 ao movimento do alvo da rolagem
  Esse tipo de “melhoria” geralmente dá a sensação de rolar dentro de melaço
  Em geral, não se deve tentar melhorar o comportamento padrão do navegador

• Uma das coisas que detesto na bagunça da Web moderna é mexer na History API
  Quando você entra em uma página clicando em um link que parece interessante em lugares como o HN e começa a rolar, cada cabeçalho ou elemento pouco importante adiciona um item ao histórico
  Para voltar ao site original, é preciso apertar Voltar umas um milhão de vezes
  Odeio todo mundo que faz isso

  • Também quero acrescentar aqui o scroll infinito
    Basta usar paginação
    Ela permite links, busca, navegação e funciona corretamente com o histórico
    O scroll infinito estraga tudo isso sem grande motivo

• Na verdade, há aqui dois problemas tão antigos quanto a Web: baixas expectativas e a ausência de padrões ou critérios que definam pessoas ou práticas
  Hoje, quando você olha as vagas, todas dizem “Senior Fullstack Engineer”, mas, ao entrar nos detalhes, muitas vezes o que realmente querem é uma combinação de Java ou Python, R, Spring e SQL
  Se não é fullstack e mesmo assim escrevem isso, estão desperdiçando o tempo das pessoas e sinalizando ao público que não entendem ou não se importam com tecnologia
  Em programação, isso é chamado de “problema X/Y”. É um antipadrão em que se deveria resolver o estado final desejado X, mas, em vez disso, fala-se apenas da abordagem Y que se quer adotar
  Por isso, empregadores recebem 500 currículos para uma vaga e ainda assim sentem que ninguém é adequado
  O ponto de partida deveria ser o objetivo: “Estamos contratando para criar este tipo de app cliente/servidor; a pessoa candidata deverá escrever e dar suporte aos recursos X, Y e Z, e as restrições são A, B e C”
  O motivo pelo qual as empresas costumam não conseguir fazer isso é que, em geral, elas não sabem o que realmente fazem e já carregam tecnologias quebradas depois de passarem por vários caminhos errados. É por isso que se chama dívida técnica
  Com objetivos claros assim, na entrevista tanto a empresa quanto a pessoa candidata sabem o que devem verificar e conseguem filtrar uma à outra de forma adequada. Caso contrário, vira um processo horrível que parece uma mistura de encontro às cegas com game show
  Por exemplo, a vaga pode especificar que está contratando para criar uma aplicação de conferência de mídia altamente distribuída, que a pessoa desenvolvedora escreverá TypeScript, conectará dados de stream de sockets por meio de pipes, trabalhará tanto no navegador quanto no servidor e escreverá automação de testes
  As restrições operacionais incluem conformidade com WCAG AA, uma checklist de conformidade de privacidade criada pelo departamento jurídico e considerações de desempenho voltadas à velocidade de execução e à latência de rede; a pessoa candidata ideal deve demonstrar na entrevista soluções para latência de rede, lógica de aplicações no navegador e gerenciamento de estado de dados em streaming