Padrões modernos de navegação no iOS

 (frankrausch.com)
6 pontos por GN⁺ 2023-12-13 | 3 comentários | Compartilhar no WhatsApp
  • A navegação em apps iOS deve distinguir claramente hierarquia, overlays e fluxos dentro da view para que o usuário entenda a localização atual e o caminho de volta
  • Os padrões estruturais se dividem em Drill-Down, Flat, Pyramid e Hub-and-Spoke, e o significado das transições de tela muda entre explorar uma árvore, dividir por abas, mover-se entre telas irmãs ou voltar a um hub
  • Overlays são recursos para chamar atenção, mas o grau em que bloqueiam a tela de trás e a ação exigida do usuário mudam conforme são modais ou não e o nível de fricção
  • A navegação embutida deve ficar dentro de uma view específica ou de um modal, e deve ser projetada para que mudanças de estado ou fluxos Step-by-Step não pareçam deslocamentos hierárquicos
  • As abas devem ser previsíveis, Cancel não deve descartar dados imediatamente, e em apps iOS é mais adequado manter limites claros de hierarquia, estado e modal do que permitir deslocamentos arbitrários

Três eixos da navegação no iOS

  • Apps iOS normalmente são compostos por uma árvore hierárquica fixa com vários níveis
  • A navegação estrutural ajuda o usuário a entender de onde veio, onde está dentro da hierarquia e como voltar à posição original
  • Overlays podem aparecer sobre qualquer contexto e também podem se sobrepor a outros overlays
    • Overlays modais não desaparecem até que o usuário execute alguma ação e bloqueiam a interface ao fundo
    • Overlays não modais não bloqueiam o app
  • A navegação embutida é mais adequada quando fica contida dentro de uma view específica ou de um overlay modal, de acordo com o modelo estrutural e espacial do iOS

Padrões de navegação estrutural

  • Drill-Down

    • Drill-Down é um padrão para explorar uma estrutura em árvore de informações por meio de listas em etapas
    • A transição animada sugere um movimento horizontal entre colunas
      • Mover para a direita significa entrar em um nível mais profundo da hierarquia da árvore
      • Mover para a esquerda significa voltar a um nível superior
    • A navegação Drill-Down tem estrutura modeless, então perguntas como salvar ou não não interrompem a exploração da hierarquia
    • A Navigation Bar mostra o título da tela atual, e o Disclosure indicator em uma linha de lista indica que é possível entrar em um nível mais profundo
    • O botão Back é um caminho claro para voltar ao nível superior, e quando houver espaço é melhor usar como rótulo o título da tela pai em vez do genérico “Back”
    • O gesto de deslizar da borda esquerda da tela para a direita tem a mesma função do botão Back
    • Implementações customizadas devem oferecer transições interativas e canceláveis controladas por screen-edge pan gesture, como no padrão do iOS
    • Em idiomas lidos da direita para a esquerda, a direção da navegação e a disposição dos controles são espelhadas conforme a direção de leitura
    • A estrutura em árvore pode ser criada dinamicamente para filtragem de banco de dados
      • Em um app de música, é possível fazer Drill-Down até o mesmo álbum a partir de pontos de entrada diferentes, como Artist, Album e Genre, além de usar uma interface de busca
    • Drill-Down é uma variação de uma coluna por tela das Miller columns no estilo do Finder do macOS

  • Flat

    • O padrão Flat divide a hierarquia no nível raiz e a exibe com uma tab bar
      • No iPad, pode ser exibido com uma sidebar
    • Os itens da tab bar são escolhidos com base nas funções principais do app e moldam as expectativas do usuário e seu modelo mental do aplicativo
    • Um dos itens da tab bar está sempre selecionado, e a seleção ativa determina o conteúdo exibido na área principal do app
    • O item atualmente selecionado na tab bar não deve mudar programaticamente sem interação do usuário, nem indiretamente por meio de toque em outro botão da interface
    • A tab bar permanece visível em toda a tela do app, exceto quando fica temporariamente encoberta por uma sheet modal
    • As abas podem ser usadas como filtros ou como diferentes pontos de entrada para grandes coleções de conteúdo, como bibliotecas de música, vídeo ou fotos
    • Cada seção mantém seu próprio estado de navegação em sub-hierarquias
    • Os itens da tab bar devem se comportar de forma previsível e não devem abrir sheets nem executar ações
    • O menu hamburger é uma forma oculta de navegação em contraste com a tab bar
      • Quando toda a interface de navegação fica escondida atrás de um pequeno ícone, a descoberta se torna pior
      • Ele virou moda no iOS por volta de 2015, mas os criadores de apps abandonaram o menu hamburger depois que estudos mostraram que a tab bar é muito mais fácil de encontrar

  • Pyramid

    • O padrão Pyramid permite mover-se rapidamente entre views irmãs no mesmo nível hierárquico sem voltar à tela pai
    • Em apps de mídia, o gesto de swipe horizontal é frequentemente usado para navegar entre views irmãs
    • Botões também podem ser usados, como os botões em forma de chevron Next Message e Previous Message do app Mail no iOS
    • O app Fotos do iOS é um exemplo do padrão Pyramid
      • Você toca em uma foto para abri-la em tela cheia e depois desliza para a esquerda ou direita para passar para imagens adjacentes
    • Em coleções pequenas, usa-se page control para visualizar o número total de itens e a posição do item atual entre seus irmãos
    • O iOS App Switcher implementa o padrão Pyramid para alternar rapidamente entre apps, oferecendo navegação mais rápida do que passar pela tela Home

  • Hub-and-Spoke

    • O padrão Hub-and-Spoke é adequado quando há grandes coleções não relacionadas entre si no topo da hierarquia
    • Para alternar entre views filhas em tela cheia, sempre se volta primeiro ao hub
    • A tela Home do iOS é uma coleção de todos os aplicativos instalados e funciona como um estado neutro confiável do sistema operacional
    • O Home indicator na parte inferior da tela é uma rota de escape fácil de aprender e sempre disponível, levando de volta à interface familiar da tela Home
    • Esse padrão quase não é usado dentro de apps
      • Quase nunca é necessário, dentro de um app, um nível de separação tão forte quanto o que existe entre aplicativos no nível do sistema operacional

Navegação por overlay

  • High-Friction Modal

    • Overlays High-Friction Modal bloqueiam a tela de trás até que o usuário tome uma decisão, como sheets ou caixas de alerta com várias ações
    • Ao redigir um e-mail ou criar um evento no calendário, é preciso escolher entre avançar com Done ou Send ou desistir com Cancel
    • O botão Cancel não deve descartar diretamente nenhum estado nem dado
      • Ao tocar em Cancel em uma sheet modal, sempre deve aparecer uma caixa de confirmação adicional como proteção
      • Em uma caixa de alerta, Cancel nunca deve ser uma ação destrutiva
    • Modais se concentram em concluir tarefas específicas e independentes, como redigir e-mail ou adicionar um evento ao calendário

  • Low-Friction Modal

    • Low-Friction Modal bloqueia o restante do app, como sheets, menus e popovers, mas não exige uma decisão “um ou outro”
    • Deve ser fácil fechar, seja pressionando um botão de fechar ou deslizando a sheet para baixo
    • Tocar fora de um context menu ou de um popover faz com que desapareçam
    • Uma caixa de alerta com apenas um botão OK é fácil de fechar, mas baixa fricção não é o mesmo que fricção zero
    • Alertas de ação única devem ser evitados sempre que possível
      • Eles interrompem o fluxo do usuário e muitas vezes podem ser substituídos por texto inline ou notificações não modais

  • Non-Modal

    • Overlays Non-Modal cobrem parte da tela, mas não bloqueiam a interface ao fundo
    • Por não bloquear, a fricção é baixa ou inexistente
    • Eles podem aparecer em resposta a gatilhos externos ao app, como notificações do sistema operacional
    • Quando desaparecem automaticamente, devem fornecer informações periféricas que possam ser vistas rapidamente com interrupção mínima
    • Overlays temporários não modais podem incluir interação opcional
      • É possível tocar na notificação ou deslizar o indicador de volume antes que desapareça para ajustar o volume
    • Um overlay que não bloqueia o restante do aplicativo e também não aparece nem desaparece automaticamente pode ser chamado de palette

Navegação embutida

  • State Change

    • Uma única view pode ter vários estados
    • Uma view de lista pode ter estados empty, loading e populated sem parecer que sua posição na hierarquia de navegação mudou
    • É preciso garantir que a mudança de estado não seja, na prática, hierárquica nem modal
    • Em mudanças de estado no mesmo lugar, deve-se evitar transições em tela cheia
    • Exemplos incluem modo de edição de lista, interface de navegador web, mapa de ruas com pan e imagem com zoom
    • Opções de view mudam apenas a forma como o conteúdo é exibido, sem alterar a localização do usuário
      • Alternar entre list view e thumbnail view é só trocar a visualização da mesma informação no mesmo contexto

  • Step-by-Step

    • O padrão Step-by-Step conecta uma sequência linear de telas, como tour guiado, fluxo de configuração ou tutorial de onboarding
    • Processos que exigem inserir muitos dados, como o checkout de uma loja online, também podem precisar de várias etapas
    • Mover-se para frente e para trás dentro da sequência não altera o nível hierárquico, e isso o diferencia do padrão Drill-Down
    • É melhor apresentar a sequência Step-by-Step dentro de um overlay modal
      • Nesse contexto, o botão Back tem um propósito diferente do botão Back de um Drill-Down hierárquico
    • O processo normalmente termina com um botão Done ou Close, e esse botão também fecha o modal que o contém
    • O número de etapas e o caminho podem mudar conforme as opções escolhidas
    • Wizard e assistant são outros nomes para esse padrão
    • Processos Step-by-Step podem parecer cansativos
      • Se os usuários provavelmente executarão isso com frequência, vale considerar combinar várias etapas em diferentes estados dentro de uma única view para aumentar a densidade de informação e reduzir mudanças de contexto

  • Content-Driven

    • A navegação Content-Driven faz hyperlinks ou botões teleportarem o usuário para outra página ou view
    • A navegação web no navegador funciona desse jeito
    • Em apps iOS, é melhor evitar esse padrão, exceto em apps que exibem hipertexto, jogos imersivos ou conteúdo não linear semelhante
    • Se o app precisar mostrar conteúdo em hipertexto, pode-se considerar colocá-lo dentro de uma interface de navegador com controles de voltar e avançar
    • Mudanças de estado em uma interface de navegador independente são mais fáceis de entender do que mudanças inesperadas de posição na hierarquia do aplicativo
    • Links podem ser usados para mover-se entre apps
    • Deep Links levam o usuário da hierarquia profunda de um app ou site para outro app usando URL scheme ou Universal Links associados a um domínio

Referências

Leituras relacionadas

3 comentários

 
GN⁺ 2023-12-13
Comentários do Hacker News

  • É algo que já foi muito comentado, mas o bom uso desses padrões foi uma das várias razões pelas quais o Apollo era muito melhor que o app oficial do Reddit
    A navegação, os gestos e os comportamentos eram consistentes, e esses conceitos nem são difíceis. Basta se importar o suficiente para segui-los, mas é desanimador ver tantos apps que não fazem isso

    • É a diferença entre um app otimizado para ser um bom app e um app otimizado para engajamento e vendas
      É parecido com supermercados que mudam periodicamente a disposição das prateleiras. Se a navegação, os gestos e os comportamentos forem consistentes, o usuário consegue obter o que quer e sair de forma eficiente demais
    • Nunca vi um app tão confuso quanto o app oficial do Reddit, e me considero de inteligência mediana
      Modero um subreddit com 30 mil pessoas, então preciso conseguir usar o Reddit no celular, mas é quase impossível. Tudo exige ações demais, e não dá para saber onde você está; é um lixo completo
    • É realmente vergonhoso como Steve Huffman arruinou o Reddit ao acabar com o Apollo
      Eu já tinha largado o Reddit alguns anos antes, mas isso foi o último prego no caixão
    • O app oficial do Reddit é um dos poucos apps em que eu regularmente me perco
      Voltar à tela principal exige tanta energia mental que eu simplesmente forço o encerramento e abro de novo
    • No Apollo também dava para abrir subreddits, perfis de usuário, posts e outras camadas, empilhando-as infinitamente, então podia ficar confuso
      Depois de alguns níveis, para voltar à primeira tela era preciso continuar deslizando ou apertando voltar até chegar lá, o que era bem trabalhoso. Talvez exista algum gesto mágico que eu não conheça

  • Eu estremeço quando vejo a expressão “padrões de navegação do iOS”. Não há padrão, e isso é uma das piores coisas do iOS em comparação com o Android
    No Android, voltar é fácil e pode ter vários significados. Uso iOS há mais de um ano e acabo tentando às cegas um dos dois “padrões” de voltar, depois procurando um botão em algum lugar fora do alcance da minha mão. E mesmo assim às vezes não funciona
    Não se deve deixar padrões nas mãos dos desenvolvedores; isso precisa ser corrigido no nível do sistema operacional. Desenvolvedores não querem que usuários saiam de partes do app. Por exemplo, tente voltar no Instagram Reels

    • “No Android, voltar é fácil e pode ter vários significados” é, para mim, uma das piores coisas do Android
      O botão de voltar não tem nenhuma consistência quanto ao que faz. Mesmo sendo desenvolvedor, eu me pego pensando no que voltar deveria fazer em uma situação específica. Deve ir para a tela anterior ou subir um nível na navegação em drill-down? É ambíguo, e às vezes as duas coisas são iguais, mas nem sempre
      Às vezes ele sobe um nível na estrutura de navegação, às vezes vai para a tela anterior, às vezes fecha uma caixa de diálogo e às vezes até fecha o app. Dependendo do contexto, qualquer ação é possível, e, se várias se aplicarem, não fica claro qual delas será. A única forma de descobrir é apertar e ver o que acontece
      Odeio elementos de interface de usuário ambíguos. Quando clico em algo, quero saber que ação será executada
    • A experiência da pilha de atividades do Android é a parte de que mais gosto no design do sistema
      Ela cria uma consistência profunda, fazendo com que a navegação não seja cansativa. Eu realmente gostaria que o iOS tivesse isso embutido da mesma forma
      A pilha de atividades funciona entre apps, então, mesmo quando vários apps lidam juntos com uma tarefa, o gesto de voltar sempre leva você para a tela imediatamente anterior
    • Não entendo por que o botão de voltar do iOS fica tão espalhado por aí
      Às vezes fica no canto superior esquerdo, às vezes no canto inferior esquerdo, às vezes no canto inferior direito, e deve haver apps que o colocam em outros lugares
      No Android há um botão de voltar do sistema operacional que está sempre ao alcance mesmo usando com uma mão. Esse método é muito superior
    • Sobre “não deixar padrões nas mãos dos desenvolvedores; isso precisa ser corrigido no nível do sistema operacional”, acho que a Apple não fez isso porque é praticamente impossível
      Por exemplo, se você pode alterar o conteúdo de uma view, também pode apagar todo o conteúdo e substituí-lo por algo completamente novo. Se isso acontece por alguma ação do usuário, na prática é como “navegar para uma nova tela”. Mas, se o desenvolvedor não usar a chamada de API proposta do sistema operacional, createNewView, e apenas alterar o conteúdo da view atual, o gesto em nível de sistema operacional não funciona
      Dito isso, a Apple poderia tornar obrigatório o uso dessa API do sistema operacional para passar na revisão. Ainda assim, acho que há certo grau de subjetividade em definir o que é uma “nova view para a qual se pode voltar” e o que é uma “view existente cujo conteúdo apenas mudou”
    • O menu de compartilhamento é o pior. Não sei como alguém deveria descobrir aquilo
      Ele mostra contatos, aplicativos, itens na vertical, itens na horizontal e outros itens embaixo, que só aparecem depois que você descobre que precisa puxar para cima. A posição muda de app para app, e o ícone não tem nada a ver com “compartilhar” ou “copiar/colar”
      Pessoas que cresceram com smartphones conseguem se adaptar, como sempre. Se você não tinha mais de 40 ou 50 anos quando eles surgiram, em geral dá para se adaptar. A maior parte das coisas modernas é terrivelmente projetada e frequentemente instável. O Apple TV também é assim; dá vontade de começar a falar sobre trocar a senha do Wi-Fi. Isso é necessário para contornar bugs, mas não entendo por que apertar o botão de ligar/desligar não reinicia o aparelho

  • Não sei se é suficientemente relacionado, mas no Mac e agora no iPadOS (https://useyourloaf.com/blog/ipad-customizable-toolbars/), os controles de barra de ferramentas integrados oferecem um alto nível de personalização pelo usuário
    Dá para experimentar isso em vários apps nativos, incluindo o Finder
    Widgets integrados poderosos são um elemento subestimado no desktop Mac, e também é algo que me preocupa à medida que o SwiftUI toma conta. Também é uma grande vantagem no iOS, mas aparece relativamente menos porque é comum demais os apps quererem aplicar seu próprio design
    Mas talvez eu esteja lembrando errado: acho que os apps antigos de iOS davam suporte nativo à personalização da barra de abas. É claramente diferente de uma barra de ferramentas, mas permitir editar a ordem das abas e quais abas de fato aparecem parecia um equivalente espiritual da personalização de barra de ferramentas integrada. Só que não vejo isso há anos
    Pela documentação, ainda existe. Fico curioso se alguém conhece algum app que ainda use esse padrão: https://developer.apple.com/documentation/uikit/uitabbarcont...
    De todo modo, barras de abas são ótimas. É assim que a maioria dos apps de Apple TV que usei funciona, e a experiência consistente é excelente

    • No começo, era bem comum misturar as abas e colocar ou tirar só o que você queria
      Lembro que, quando o Facebook ainda era decente, talvez por volta do iOS 7, dava para mudar itens como chat, feed, notificações e grupos dessa forma
    • Vários apps da Apple, como Apple Store e Music, usam a barra de abas inferior, mas sem personalização
      Fora da Apple, os apps que me vêm à cabeça migraram todos há muito tempo para menus hambúrguer difíceis de descobrir
    • No Mac, eu gostaria que mais apps usassem a barra de ferramentas padrão
      A possibilidade de personalização é boa, mas é algo raro de encontrar em implementações próprias
    • UITabBar sempre foi dolorosamente limitado para personalizar também do ponto de vista do programador, e quase nenhum projeto se importava com a parte de o usuário poder alterá-lo diretamente
      Acho que a Apple travou tanto a aparência que acabou fazendo todo mundo substituí-lo por outra coisa
    • Ainda sinto falta do recurso que permitia reorganizar a barra de ferramentas em apps de iOS como o Music
      Há 2 abas do Apple Music que literalmente nunca uso. Eu gostaria de poder ir direto para playlists e álbuns

  • A afirmação do primeiro item de que “a navegação drill-down não tem estado” me parece o contrário
    A tela N depende do que você fez antes, e você também pode voltar para lá, então é uma estrutura com muito estado. Para ser útil, ela precisa de fato rastrear estado interno. Por exemplo, o conteúdo da lista depende do estado N-1; caso contrário, seria horrível
    Uma UI sem estado seria algo como um modal de um único nível. Ou ele existe, ou não existe. Especialmente se for temporário e não houver uma forma de “retomar”, dá para considerá-lo ainda mais fortemente sem estado
    Ao longo dos anos, vi muitas discussões usando “com estado” em sentidos completamente diferentes, e recentemente isso explodiu em volume. Por isso estou quase chegando à conclusão de que quase ninguém concorda entre si sobre o significado, e poucos percebem isso
    Fico curioso sobre o que UI com estado significa para vocês. A diferença é interessante

    • Concordo que a expressão “UI com estado” é geralmente ambígua, mas, no contexto de navegação, costumo ouvir chamarem uma hierarquia de sem estado e uma pilha de atividades de com estado
      Em uma hierarquia como a do iOS, todo filho deve ter exatamente um pai, então, se você souber qual é a página atual, sabe o que o botão “voltar” fará. Independentemente de como você chegou a essa página, ele sobe um nível na hierarquia até a página pai
      Em uma pilha de atividades como a do Android, a página atual por si só não basta; é preciso saber como você chegou a ela. Isso porque o botão “voltar” significa voltar no histórico
      Muitos sites oferecem suporte aos dois. O botão de voltar do navegador tem estado e navega pelo histórico pessoal, mas a navegação dentro da página, como breadcrumbs, normalmente não tem estado e não depende do caminho específico pelo qual você chegou àquela página. Claro que há exceções. Muitas interfaces de busca podem ser consideradas com estado, porque, se você entra em um item e depois volta usando a navegação dentro da página, retorna ao termo pesquisado anteriormente, não à página pai
    • Para mim, UI com estado significa que o frontend usa variáveis para gerenciar o próprio comportamento

  • Vejo uma formulação imprecisa aqui: a parte que diz que “deslizar da borda esquerda da tela para a direita é igual a pressionar o botão de voltar”
    Se você for implementar isso diretamente, não deve ser um gesto de deslizar, e sim um gesto de arrastar a partir da borda. Deve ser um gesto de arrastar interativo que acompanha o dedo e pode ser cancelado; caso contrário, a sensação fica errada

    • Acho que o app iOS do X/Twitter e o app do Reddit têm esse problema
      Acontece com frequência demais de eu estar digitando algo com dedicação, só encostar de leve na borda do celular, e o comentário inteiro desaparecer
    • Deslizar da esquerda para a direita para voltar é uma forma terrível de implementar um “botão de voltar” e nunca deveria ser feito. Sempre deve haver um botão de voltar de verdade
      O motivo é que canhotos existem. Não é um movimento natural nem confortável para fazer com o polegar esquerdo. Também não dá para inverter a direção para canhotos: se a leitura é da esquerda para a direita, um deslize para a direita parece avançar, não voltar
      No geral, não gosto de navegação por deslizes. No iOS, é especialmente ruim. Ao deslizar de baixo para cima, sobe algum menu que contém coisas realmente importantes, mas que você nunca consegue encontrar quando precisa, e que é acionado por engano o tempo todo quando está rolando uma página da web
      Mais amplamente, sinto que o iOS degenerou em um sistema operacional horrivelmente complexo e um pesadelo para navegar, e que a Apple precisa voltar a levar UI/UX a sério. O problema principal parece ser a expectativa de que o telefone realize inúmeras tarefas para as quais ele nem era adequado em primeiro lugar
    • O Sailfish OS lida com isso de forma correta e consistente em todos os apps
      https://sailfishos.org/
      No geral, acho mais simples e melhor que iOS e Android

  • Um material muito bom para quem tem dificuldade com software visual
    Os diagramas e as explicações claras são excelentes

  • Frank Rausch é o criador do melhor app da Wikipedia, o “V for Wiki”
    Então acho que, quando ele fala sobre design e experiência do usuário no iOS, vale a pena ouvir
    https://web.archive.org/web/20211223231349/https://v-for-wik...

    • À parte isso, não sei o que aconteceu com o V For Wiki
      Eu usava todos os dias e, de repente, um dia ele parou de funcionar; quando procurei na App Store, tinha desaparecido. Fiquei realmente chateado

  • Seria bom poder desativar o gesto em que “deslizar da borda esquerda da tela para a direita equivale a apertar o botão de voltar”
    Acontece muitas vezes de eu acionar o voltar enquanto faço rolagem horizontal, comum em páginas da web que não se ajustam à tela

  • O iOS faz isso muito bem
    Um aplicativo típico de iOS tem uma arquitetura fixa, como uma árvore hierárquica com vários níveis, e essa estrutura rígida torna as opções de navegação previsíveis. Padrões de navegação estruturais dão ao usuário confiança sobre de onde veio, onde está na hierarquia e como voltar ao lugar original
    Já no Android, o gesto de voltar às vezes leva para a página anterior e, às vezes, fecha o app por completo. Era tão inconsistente que, depois de 12 anos usando Android, mudei para iOS

    • Foi assim desde o começo
      É surpreendente que eu tenha aguentado nada menos que 12 anos antes de decidir que não dava mais

  • Quando comecei a desenvolver para iPhone, ou seja, na época em que o SDK oficial tinha acabado de sair, a Apple era muito rigorosa com as Human Interface Guidelines e a documentação sobre o que compunha uma boa UI e quais padrões padrão seguir também era muito boa
    Mas, com a transição para o design “flat”, parece que isso desapareceu completamente. Acho que o principal motivo é que esses documentos já não faziam mais sentido
    Antes era algo muito claro, como “deixe as interações do usuário claramente visíveis”; agora virou “isso pode ser clicável, pode ser apenas texto, ou talvez exija um toque longo”
 
genkino 2023-12-13

Olá! Eu também percebi isso quando compartilhei este texto com um colega. Disseram que, em vez de "nebigeisyeon", a forma padrão de acordo com a ortografia coreana é "naebigeisyeon". Haha. Como é uma pronúncia vinda do inglês, na verdade pode ser um pouco ambíguo dizer qual está "certo". Mas, como é um lugar que muita gente vê, achei que seria melhor usar a forma padrão, então estou deixando este comentário de passagem.
 
xguru 2023-12-14

Este texto é um resumo feito pelo GPT-4. O GPT usa bem “navegação”, mas parece que às vezes também mistura com uma variante de grafia. Já deixei corrigido, haha