Testare su dispositivi che non possiedi

Un simulatore ti parla del layout. Non può dirti come si sente la pagina su un Android di quattro anni fa, e fingere il contrario è il modo in cui i bug arrivano in produzione.

4 min di lettura

Simulator Panel mostra in anteprima una pagina su più dimensioni di dispositivo contemporaneamente, con DevTools integrati — console, rete e archiviazione — più cattura di screenshot su tutti i dispositivi, profilazione di prestazioni e accessibilità, verificatore di contrasto, validatore delle aree tattili e configurazioni di dispositivo personalizzate.

Ciò che cambia il flusso di lavoro è la parte multi-dispositivo. Ridimensionare una finestra è una sequenza; vedere quattro larghezze affiancate è un confronto — ed è nel confronto che noti che il layout a schede collassa in modo goffo esattamente a un breakpoint.

Quali dimensioni tenere davvero aperte

La tentazione è aggiungere ogni dispositivo dell’elenco. Otto anteprime significano otto finestrelle e smetti di leggerle tutte.

Quattro è il numero che resta utile:

  • Un telefono piccolo — la larghezza più stretta che dichiari di supportare. È qui che il testo va a capo male e i pulsanti si accavallano.
  • Un telefono grande — dove sta davvero il tuo traffico mobile.
  • Un tablet in verticale — la dimensione che tutti dimenticano e quella in cui i layout desktop compaiono nel momento sbagliato.
  • Un portatile — non un monitor da 27 pollici. La maggior parte dei visitatori desktop sta su 13 o 14 pollici, e i design fatti su monitor grandi lì si rompono regolarmente.

Le configurazioni personalizzate valgono una volta sola se hai un vero sbilanciamento di pubblico: una risoluzione da chiosco, un tablet specifico usato da un cliente. Fallo una volta, salvalo, non pensarci più.

I due controlli che valgono ogni volta

Gli strumenti di accessibilità hanno la fama di produrre cento avvisi su cui nessuno agisce. Questi due sono diversi, perché falliscono per motivi che risolvi in un minuto e perché toccano persone reali subito.

Contrasto. Il testo grigio su sfondo bianco è il difetto di accessibilità più comune del web, e di solito arriva quando qualcuno schiarisce un colore per rendere il design più calmo. Il verificatore ti dà un numero; se non passa, scurisci il testo invece di discutere con il numero.

Aree tattili. Un controllo che va bene col mouse può essere davvero difficile col pollice. Il validatore segnala ciò che è troppo piccolo, e la soluzione di solito è il padding, non un redesign. Conta soprattutto nell’anteprima del telefono piccolo, cioè proprio quella che si salta.

Esegui entrambi prima della revisione, non dopo. Un problema di contrasto trovato in revisione costa un giro completo; trovato nel pannello costa una battuta di tasto.

Screenshot su tutti i dispositivi in un colpo

La cattura complessiva è più utile di quanto sembri, per un motivo preciso: è il modo più rapido di rendere discutibile un problema di layout.

«Su mobile si vede male» apre una discussione. Quattro screenshot a quattro larghezze allegati alla scheda ne chiudono una. E poiché gli scatti vengono dallo stesso momento, nessuno può insinuare che stessi guardando una build vecchia.

Allegali alla scheda invece di incollarli in chat. La scheda è il posto in cui qualcuno guarderà tra tre settimane chiedendosi perché sia cambiato il padding.

Cosa un simulatore non può dirti

Questa è la parte su cui vale la pena essere onesti, perché la modalità di fallimento è silenziosa.

Un simulatore renderizza la tua pagina a una data dimensione, nel tuo motore di rendering, sulla tua macchina, sulla tua connessione. È accurato sul layout e inutile su tutto il resto.

Non ti dirà che la pagina impiega undici secondi su un Android di quattro anni fa, che il font viene reso diversamente su un iPhone vero, che l’intestazione fissa copre il campo quando si apre la tastiera a schermo, o che l’animazione scatta su hardware senza una GPU decente. Sono questi i bug che arrivano in produzione dopo un passaggio pulito nel simulatore.

Quindi: usa il pannello per layout, contrasto e aree tattili — le cose in cui è davvero bravo — e tieni sulla scrivania un telefono Android economico ma vero per tutto il resto. Un dispositivo fisico intercetta una categoria di problemi che nessun simulatore raggiunge.

Per il lato prestazioni, Web Analyzer misura una pagina come viene effettivamente servita, non come si renderizza in locale. È una domanda diversa da «il layout regge», e vale la pena porla separatamente prima di un lancio.

Domande frequenti

Quante anteprime di dispositivo dovrei tenere aperte?

Quattro: telefono piccolo, telefono grande, tablet in verticale e portatile. Otto anteprime sono otto finestrelle e smetti di leggerle tutte. Il portatile conta più di un monitor grande: la maggior parte dei visitatori desktop sta su 13 o 14 pollici.

Quali controlli di accessibilità valgono davvero?

Contrasto e aree tattili, ogni volta. Entrambi falliscono per motivi risolvibili in un minuto ed entrambi toccano utenti reali subito. Eseguili prima della revisione, non dopo: in revisione un problema di contrasto costa un giro completo.

Posso smettere di testare su dispositivi reali?

No. Un simulatore è accurato sul layout e cieco su tutto il resto: prestazioni reali, resa dei font, tastiera a schermo che copre un campo, animazioni su hardware debole. Tieni un Android economico sulla scrivania.

Qual è il modo più rapido di segnalare un problema di layout?

Cattura tutti i dispositivi in un colpo e allega le immagini alla scheda. Quattro larghezze dallo stesso momento trasformano «su mobile si vede male» da discussione in fatto, e la scheda è dove qualcuno lo cercherà dopo.

Moduli usati