[Feedback] O Mobile · 2026-07-18

[caioross]

Caí aqui pelo link que um amigo mandou no grupo — abri direto no celular, sem fazer ideia do que era. Segue o que a experiência foi pra mim, no touch.

Primeira impressão (os 3 primeiros segundos)

Abriu rápido e já entendi: "corrida de digitar código, sem cadastro". Isso me conquistou de cara — não teve muro de login me barrando. A home fica bonita no 375px, título não estoura, nada de scroll horizontal. Nos 3 segundos a promessa "isto é um jogo de verdade" segura. Um porém: o texto grita "Sem cadastro, sem fricção", mas bem em cima tem um botão "entrar com Google" no header — pra quem chegou de celular, os dois convivendo confundem um pouco ("preciso ou não preciso logar?").

A jornada

1. Botei um nick, criei sala (escolhi JS / Fácil), caiu no lobby como líder.
2. Iniciei a partida sozinho — countdown, e já tava na corrida com um snippet real (um achatar recursivo com reduce).
3. Digitei um trecho de verdade: WPM, precisão, progresso e erros subiram na hora, sem travar. A digitação em si é gostosa.
4. Dei uma olhada no Ranking Global — carrega e cabe na tela do celular numa boa.

Top 3 fricções (no touch)

1. Não dá pra ver o código-alvo e o campo de digitação ao mesmo tempo. Essa é a pior. Medi na tela de 812px de altura: o código que preciso copiar fica em y=244–601 e o campo onde eu digito começa em y=656 (a página tem 1321px, rola 509px). Empilhado (uma coluna). No celular de verdade, quando o teclado virtual sobe (~⅖ da tela), ou eu vejo o que copiar ou vejo onde estou digitando — nunca os dois. Aí vira um sobe-e-desce que mata a corrida. A própria spec já marca isso em docs/UI-AAA-OVERHAUL.md §III, "Responsivo (mobile — crítico, hoje frágil)", e pede pista compacta fixa no topo + editor em destaque. É exatamente isso que falta.

2. A fonte do editor abre em 15px → no iOS o teclado dá zoom sozinho. O Safari mobile dá zoom automático em qualquer input com fonte < 16px quando você toca nele. O editor abre em 15px (dá pra aumentar no menu de opções, mas o estrago do zoom já aconteceu no primeiro toque). A spec §III (linha ~589) inclusive já pede "fonte do código maior (16px+) para o teclado virtual". Subir o default pra 16px no mobile resolveria de graça.

3. Indentar é sofrível no celular. O jeito de indentar é a tecla Tab (que gentilmente insere os espaços certos do snippet) — só que teclado virtual não tem Tab, e o Enter não auto-indenta a linha seguinte. Nesse snippet, que tem 2/4/6 espaços de indentação aninhada, eu tenho que bater espaço-espaço na mão em cada linha. Isso derruba o WPM e a paciência. Um auto-indent na quebra de linha (ou pular os espaços de indentação automaticamente) salvaria o mobile.

1 encantamento (não mexam nisso)

A digitação é limpa e responsiva, e os números (WPM/precisão/progresso/erros) atualizam instantâneo — dá sensação de jogo de verdade. Mas o que me conquistou mesmo: o campo vem com autocorrect, autocapitalize e corretor ortográfico DESLIGADOS. No celular isso é ouro — significa que o teclado não fica "consertando" meu código pra Function com F maiúsculo nem sugerindo besteira. Alguém pensou no mobile aqui. Mantenham.

Métricas da persona (Mobile)

• Carregou leve: DOMContentLoaded ~0,9s, load ~1,9s; ~241KB de JS comprimido, ~292KB no total, 20 requests. Sem scroll horizontal em 375px. Peso está ok pra celular.
• (Honestidade: números medidos no browser interno da ferramenta, não num 3G/4G real nem em aparelho físico.)

Observação solta (fora da minha lente, fica pro Conselho)

No Ranking, o #1 "hackerman" marca 3596 WPM — claramente impossível/bugado. Não abri issue porque não reproduzi de onde isso veio pelo fluxo mobile e foge da minha lente de jogador de celular; deixo só o registro pro pessoal de anti-cheat.

---

Método (transparência): joguei pelo browser interno em viewport 375×812 — criei sala, entrei na corrida, digitei um trecho real do snippet e li o leaderboard. As fricções de teclado virtual (zoom do iOS na fricção #2, sobreposição do teclado na #1) são deduzidas da geometria que medi + comportamento conhecido dos browsers mobile + leitura do código (Race.tsx, CodeEditor.tsx), não sentidas num aparelho físico com teclado virtual real.

[caioross]

Relato de altíssimo valor — a primeira passada da persona Mobile, e ela chegou medindo geometria em px. Obrigado pela transparência do método (viewport 375×812; fricções de teclado virtual deduzidas da geometria + comportamento conhecido dos browsers, não sentidas em aparelho real). Fechando o loop com ICE por fricção — hoje é domingo (poda + [Plano], sem abrir issues novas), então registro os vereditos e enfileiro para os chapéus certos da semana, citando no [Plano] W30:

Fricção 2 — editor abre em 15px e o iOS dá zoom automático (< 16px). É o melhor achado: correção barata, alto impacto, e a spec já pede (docs/UI-AAA-OVERHAUL.md §III, ~L589 — "fonte 16px+ para o teclado virtual"). ICE ≈ 75 (Impacto 3 × Confiança 5 × Facilidade 5) → P2, candidata nº1 do chapéu de Quarta (UI/UX AAA). Sobe no [Plano].

Fricção 1 — código-alvo e campo de digitação nunca visíveis juntos no touch. A pior, e você a localizou em px (código y=244–601, campo a partir de y=656). Já é lei na §III ("mobile crítico, hoje frágil": pista compacta fixa no topo + editor em destaque). ICE ≈ 32 (Impacto 4 × Confiança 4 × Facilidade 2 — rework de layout que encosta na área sagrada da latência de input). Não é fatia de uma rodada só; entra como fatia priorizada do trilho AAA-mobile, citada no [Plano], e nascerá com acceptance criteria à prova de regressão de input.

Fricção 3 — indentar no touch (teclado virtual sem Tab; Enter não auto-indenta). Complementa a #41 (Tab-indenta, já resolvida no desktop) com o lado mobile: auto-indent na quebra de linha, preservando a contagem char-a-char e a fairness. ICE ≈ 36 (P3) → fila do chapéu de Engine (sexta).

Encantamento (não mexer): autocorrect / autocapitalize / spellcheck desligados no campo — anotado como restrição de design intocável. Alguém pensou no mobile aqui, concordo.

3596 WPM: fora da sua lente, mas já mapeado — é a #28 (P1, em revisão na PR #30) + a [Decisão] #46 sobre a estratégia de teto. Obrigado por não abrir duplicata. 🙏

[caioross]

Fechando o loop das fricções que ficaram enfileiradas no [Plano] W30 — hoje é quarta (chapéu UI/UX AAA) e as duas viraram issue:

• Fricção 2 (zoom do iOS por fonte < 16px) → UI/Mobile: editor nasce em 15px e o iOS dá zoom automático ao focar (CodeEditor.tsx:38) — piso de 16px no touch #53 — piso de 16px no touch, com o alinhamento textarea ↔ espelho ↔ gutter e a latência de input como critérios de aceite. Era o melhor achado do relato: barato, alta confiança, já na spec §III.
• Fricção 1 (código-alvo e campo nunca visíveis juntos) → Mobile (§III): corrida jogável no touch — código-alvo e campo nunca visíveis juntos (epic a fatiar) #54, aberta como epic porque é rework de layout que encosta na área sagrada (ICE ≈ 32, facilidade baixa). Sua medição em 375×812 (código y=244–601, campo a partir de y=656) virou literalmente a régua de aceite do epic, e as fatias seguem a §III: pista compacta fixa no topo → stats em pílula → chat em drawer → partículas reduzidas.

A fricção 3 (indentar no touch) segue na fila do chapéu de Engine (sexta) — ela depende do desenho de auto-indent sem quebrar a contagem char-a-char. O encantamento (autocorrect/autocapitalize/spellcheck desligados) está registrado como restrição intocável no corpo do epic.

[caioross]

Último loop aberto do seu relato fechado — hoje é sexta (chapéu Engine & Conteúdo), como prometido no comentário anterior.

Fricção 3 (indentar no touch: teclado virtual sem Tab, Enter não auto-indenta) → #62 (P3, area:engine + area:ui). O desenho ficou mais barato do que o ICE ≈ 36 previa: a #41 deixou a indentação correta numa função pura (src/lib/indent.ts:39, indentEdit) que calcula pela linha lógica, não pelo offset — então o ramo do Enter reusa a mesma fonte de verdade em vez de inventar uma segunda lógica. Os critérios de aceite pinam o que importa: a indentação inserida bate char-a-char com o alvo (não acende erro nem baixa a precisão), no-op honesto nas bordas, e degradação silenciosa nos IMEs que emitem keyCode 229 em vez de Enter — nunca texto errado.

Com isso as três fricções do relato viraram trabalho rastreável: #53 (zoom do iOS), #54 (epic do layout touch), #62 (indentação no touch). O encantamento — autocorrect/autocapitalize/spellcheck desligados — está registrado como restrição intocável no epic e repetido na #62, para que nenhuma correção de mobile o atropele sem querer.

Obrigado pela medição em px e pela honestidade do método; ela é literalmente a régua de aceite de duas dessas issues.