Progettare una ricerca

Definire la ricerca#section1

Tra i soggetti che rientrano nella performance web, l’ottimizzazione delle immagini è particolarmente vasta. C’è una gran varietà di formati, codifiche e tool di ottimizzazione, ciascuno dei quali è progettato per rendere le immagini sufficientemente piccole per l’uso sul web, mantenendo una qualità visuale ragionevole. Trovare l’equilibrio tra velocità e qualità è davvero tutto quello che c’è nell’ottimizzazione delle immagini.

Questo equilibrio tra performance e qualità visiva mi ha indotto a considerare il modo in cui le persone percepisconola qualità delle immagini. La qualità dell’immagine lossy, in particolare. Alla fine, questo flusso di pensieri mi ha portato a una serie di domande che hanno incoraggiato la progettazione e lo sviluppo di un questionario sulla percezione della qualità delle immagini. L’idea del sondaggio è che gli utenti forniscono delle valutazioni soggettive sulla qualità. Questo viene fatto chiedendo ai partecipanti di dare un voto alle immagini senza un riferimento oggettivo a quella che è la “perfezione”. Questo è, dopo tutto, il modo in cui le persone vedono le immagini in situ.

Una parola sui sondaggi#section2

Quando si vuole quantificare il comportamento degli utenti, è inevitabile almeno prendere in considerazione un sondaggio se non addirittura sceglierlo alla fine per raccogliere dei dati da un gruppo di persone. Dopo tutto, i sondaggi sono perfetti quando il vostro obiettivo è ottenere qualcosa di misurabile. Tuttavia, il sondaggio è uno strumento seducente ma pericoloso, come ci avverte Erika Hall. Sono semplici da fare e condurre e se ne abusa regolarmente nella loro divulgazione. Non sono degli ottimi tool per valutare il comportamento passato. Sono altrettanto scarsi (se non peggio) nel predire il comportamento futuro. Per esempio, la scala da 1 a 10 spesso usata per i questionari di soddisfazione dei clienti non dicono davvero molto riguardo a quanto siano effettivamente soddisfatti i clienti o quanto sia probabile che compreranno un prodotto in futuro.

La sfortunata realtà, tuttavia, è che al posto del mio controllo su centinaia di partecipanti di persona, il sondaggio è l’unico strumento veramente pratico che ho per misurare come le persone percepiscono la qualità dell’immagine così come se (e potenzialmente come) le misurazioni della performance sono collegate a queste percezioni. Quando ho progettato il sondaggio, mi sono attenuto alle seguenti linee guida:

• non chiedere ai partecipanti nulla di diverso dalle loro percezioni sul momento. Quando un partecipante è passato oltre, il suo ricordo di ciò che ha appena fatto diminuisce rapidamente con il passare del tempo.
• Non dare per scontato che i partecipanti sappiano tutto quello che fate. Guidateli con del testo rilevante che descriva sinteticamente cosa vi aspettate da loro.
• Non chiedere ai partecipanti di fornire valutazioni con input grezzi. Utilizzate un tipo di input che consenta loro di valutare con precisione la qualità dell’immagine su una scala congruente con il range di codifica di qualità di immagine lossy.

Procedendo, tutto quello che possiamo fare è riconoscere che stiamo interpretando dei dati ottenuti sotto l’ipotesi che i partecipanti siano sinceri e comprendano il task che gli è stato assegnato. Anche se la metrica della percezione viene scartata dai dati, ci sono ancora delle metriche di performance oggettive raccolte che potrebbero narrare una storia avvincente. Da qui, si tratta di definire le domande che guideranno la ricerca.

Fare le domande giuste#section3

Nella ricerca, state cercando delle risposte a delle domande. Nel caso di questo particolare lavoro, volevo risposte alle seguenti domande:

• quanto sono accurate le percezioni delle persone sulla qualità delle immagini lossy in relazione all’effettiva qualità?
• Le persone percepiscono la qualità delle immagini JPEG in maniera diversa dalle immagini WebP?
• La performance gioca un ruolo in tutto ciò?

Sono domande importanti. Per me, tuttavia, rispondere all’ultima domanda era l’obiettivo primario. Ma la strada per le risposte era (e continua ad essere) un viaggio complesso di scelte di design e sviluppo. Cominciamo coprendo alcune delle tecniche usate per raccogliere informazioni dai partecipanti al sondaggio.

Scoprire le caratteristiche del device e del browser#section4

Quando si misura la percezione della qualità delle immagini da parte delle persone, bisogna tenere in considerazione i device. Dopo tutto, lo schermo di un determinato device sarà più o meno capace di altri. Fortunatamente, feature HTML quali srcset e picture sono molto appropriate per inviare l’immagine migliore a ogni dato schermo. Ed è di vitale importanza perché la percezione della qualità dell’immagine secondo una persona può essere influenzata negativamente se un’immagine è della dimensione sbagliata per lo schermo del device. Di contro, la performance può subire un impatto negativo se un’immagine di qualità eccessivamente alta viene mandata a un device con uno schermo piccolo. Questi sono fattori che meritano di essere presi in considerazione quando si scoprono le relazioni potenziali tra la performance e la qualità percepita.

Rispetto alle caratteristiche e condizioni del browser, JavaScript ci dà moltissimi strumenti per identificare aspetti importanti del device di un utente. Per esempio, la proprietà currentSrc rivela quale immagine si sta mostrando da un array di immagini responsive. In assenza di currentSrc, posso in qualche modo assumere con sicurezza che manchi il supporto per srcset o picture e utilizzare il fall-back al valore src del tag img:

const surveyImage = document.querySelector(".survey-image");
let loadedImage = surveyImage.currentSrc || surveyImage.src;

In merito alle capacità di schermo, devicePixelRatio ci dice la densità di pixel dello schermo di un determinato device. In assenza di devicePixelRatio, potete tranquillamente assumere un valore di fallback di 1:

let dpr = window.devicePixelRatio || 1;

devicePixelRatio è supportato in maniera eccellente dai browser. È altamente improbabile che quei pochi browser che non lo supportano (i.e., IE 10 e precedenti) siano usati su display ad alta densità.

Il fedele metodo getBoundingClientRect recupera la larghezza resa di un elemento img, mentre la proprietà complete dell’interfaccia di HTMLImageElement determina se un’immagine abbia finito di caricarsi. L’ultima di queste due è importante, perché potrebbe essere preferibile scartare risultati individuali in situazioni in cui le immagini non si sono caricate.

Nei casi in cui JavaScript non è disponibile, non possiamo raccogliere nessuno di questi dati. Quando raccogliamo le valutazioni dagli utenti che hanno disabilitato JavaScript (o che in alternativa non possono far girare JavaScript), devo accettare che ci saranno dei gap nei dati. L’informazione base che siamo ancora in grado di raccogliere fornisce però alcuni valori.

Fare sniffing per il supporto di WebP#section5#section5

Come ricorderete, una delle domande iniziali che ho posto era come gli utenti percepissero la qualità delle immagini WebP. Il request header Accept di HTTP rende pubblico il supporto di WebP in browser come Chrome. In questi casi, l’header Accept potrebbe essere così:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

Come potete vedere, il content type WebP di image/webp è uno dei content type pubblicizzati nel contenuto dell’header. Nel codice server side, potete controllare Accept per la sotto-stringa image/webp. Ecco come potrebbe apparire nel codice back-end in Express:

const WebP = req.get("Accept").indexOf("image/webp") !== -1 ? true : false;

In questo esempio, sto registrando il support status del browser per WebP in una costante JavaScript che posso usare in seguito per modificare l’invio dell’immagine. Avrei potuto usare l’elemento picture con più source e lasciare che fosse il browser a capire quale usare basandosi sul valore dell’attributo type dell’elemento source, ma questo approccio ha dei chiari vantaggi. Primo, c’è meno markup. Secondo, il sondaggio non dovrebbe sempre scegliere una sorgente WebP semplicemente perché il browser è in grado di usarla. Per ogni determinato campione del sondaggio, l’app dovrebbe decidere a caso tra un’immagine WebP e una JPEG. Non tutti i partecipanti che usano Chrome dovrebbero valutare solo immagini WebP, ma piuttosto un mix di entrambe i formati.

Registrare i dati della performance della API#section6

Ricorderete che una delle prime domande a cui mi sono prefissato di rispondere era se la performance avesse un impatto sulla percezione della qualità dell’immagine. A questo punto dello sviluppo della web platform, ci sono varie API che aiutano a cercare una risposta:

• Navigation Timing API (Level 2): questa API traccia le metriche di performance per il page load. Più di questo, dà insight nelle specifiche fasi di page loading, come redirect, request e response time, DOM processing e altro.
• Navigation Timing API (Level 1): Simile al Level 2 ma con delle differenze chiave. Ai tempi esposti dal Level 1 dell’API manca l’accuratezza di quelli nel Level 2. Inoltre, le metriche del Level 1 sono espresse in Unix time. Nel sondaggio, i dati sono raccolti solo dal Level 1 dell’API se il Level 2 non è supportato. È lontano dall’essere l’ideale (ed è anche tecnicamente obsoleto), ma aiuta a riempire dei piccoli gap.
• Resource Timing API: Simile a Navigation Timing, ma Resource Timing raccoglie metriche su varie fasi di caricamento delle risorse della pagina piuttosto che della pagina stessa. Di tutte le API usate nel sondaggio, Resource Timing è quella più utilizzata, perché aiuta a raccogliere metriche sul caricamento dei campioni di immagini che l’utente valuta.
• Server Timing: in browser selezionati, questa API viene portata nell’interfaccia della Navigation Timing Level 2 quando una page request risponde con un response header Server-Timing. Questo header è open-ended e può essere popolato con le tempistiche relative alle fasi di processing back-end. Questo è stato aggiunto al secondo giro del sondaggio per quantificare il tempo di processing back-end in generale.
• Paint Timing API: attualmente solo in Chrome, questa API riporta due metriche di paint, first paint e first contentful paint. Poiché una parte significativa di utenti del web usa Chrome, potremmo essere in grado di osservare delle relazioni tra la qualità percepita dell’immagine e le metriche di paint.

Usando queste API, possiamo registrare le metriche di performance per la maggior parte dei partecipanti. Ecco un esempio semplificato di come il sondaggio usi la Resource Timing API per raccogliere metriche di performance per il campione di immagine caricato:

// Get information about the loaded image
const surveyImageElement = document.querySelector(".survey-image");
const fullImageUrl = surveyImageElement.currentSrc || surveyImageElement.src;
const imageUrlParts = fullImageUrl.split("/");
const imageFilename = imageUrlParts[imageUrlParts.length - 1];

// Check for performance API methods
if ("performance" in window && "getEntriesByType" in performance) {
  // Get entries from the Resource Timing API
  let resources = performance.getEntriesByType("resource");

  // Ensure resources were returned
  if (typeof resources === "object" && resources.length > 0) {
    resources.forEach((resource) => {
      // Check if the resource is for the loaded image
      if (resource.name.indexOf(imageFilename) !== -1) {
        // Access resource images for the image here
      }
    });
  }
}

Se è disponibile la Resource Timing API e il metodo getEntriesByType ritorna dei risultati, viene ritornato un oggetto con le tempistiche, che assomiglia a questo:

{
  connectEnd: 1156.5999999947962,
  connectStart: 1156.5999999947962,
  decodedBodySize: 11110,
  domainLookupEnd: 1156.5999999947962,
  domainLookupStart: 1156.5999999947962,
  duration: 638.1000000037602,
  encodedBodySize: 11110,
  entryType: "resource",
  fetchStart: 1156.5999999947962,
  initiatorType: "img",
  name: "https://imagesurvey.site/img-round-2/1-1024w-c2700e1f2c4f5e48f2f57d665b1323ae20806f62f39c1448490a76b1a662ce4a.webp",
  nextHopProtocol: "h2",
  redirectEnd: 0,
  redirectStart: 0,
  requestStart: 1171.6000000014901,
  responseEnd: 1794.6999999985565,
  responseStart: 1737.0999999984633,
  secureConnectionStart: 0,
  startTime: 1156.5999999947962,
  transferSize: 11227,
  workerStart: 0
}

Prendo queste misurazioni ma mano che i partecipanti valutano le immagini e li memorizzo in un database. Lungo il percorso quando voglio scrivere delle query e analizzare i dati che ho, posso far riferimento al Processing Model for the Resource and Navigation Timing APIs. Con SQL e i dati a mia disposizione, posso misurare le fasi distinte delineate dal modello e vedere se esistono delle correlazioni.

Avendo discusso i dettagli tecnici di come si possono raccogliere i dati dai partecipanti a un sondaggio, spostiamo ora l’attenzione al design e agli user flow del sondaggio.

Progettare il sondaggio#section7

Sebbene i sondaggi tendano ad avere dei design e user flow piuttosto semplici rispetto ad altri siti, dobbiamo rimanere coscienti del percorso dell’utente e degli ostacoli che un utente potrebbe affrontare.

L’entry point#section8

Quando i partecipanti arrivano alla home page, vogliamo essere diretti nella nostra comunicazione con loro. Il testo introduttivo della home page accoglie i partecipanti, dà loro una spiegazione stringata di cosa aspettarsi e presenta due scelte di navigazione:

Da qui, i partecipanti o iniziano il sondaggio o leggono la privacy policy. Se l’utente decide di partecipare al sondaggio, raggiungerà una pagina che gli chiederà gentilmente quale sia la sua professione e gli richiederà di dichiarare eventuali problemi alla vista. I campi per queste domande possono essere lasciati in bianco, dal momento che qualcuno potrebbe non sentirsi a proprio agio a rilasciare questo tipo di informazione. Oltre questo punto, il sondaggio inizia sul serio.

Il manuale introduttivo del sondaggio#section9

Prima che l’utente inizi a valutare le immagini, verrà re-diretto a una pagina di spiegazioni. Questa pagina descrive cosa ci si aspetta dai partecipanti e spiega come valutare le immagini. Nonostante il sondaggio sia promosso nei luoghi di design e sviluppo dove i lettori lavorano regolarmente con le immagini sul web, un manuale è ancora utile per essere sicuri che tutti siano allineati. Il primo paragrafo della pagina sottolinea che gli utenti stanno valutando la qualità dell’immagine, non il contenuto dell’immagine. Questo è importante. In assenza di qualsiasi contesto, i partecipanti possono effettivamente valutare le immagini per il loro contenuto, che non è quello che chiediamo. Dopo questo chiarimento, viene dimostrato il concetto di qualità lossy dell’immagine con il seguente schema:

Infine, si spiega la funzione dell’inserimento della valutazione. Probabilmente, i più potrebbero dedurne il funzionamento, ma del testo esplicativo aiuta a rimuovere ogni ambiguità residua. Non è necessariamente saggio supporre che l’utente sappia tutto quello che sapete voi. Quello che è ovvio per uno non lo è necessariamente per un altro.

La pagina con i campioni di immagine#section10

Questa pagina è l’evento principale ed è dove i partecipanti valutano la qualità delle immagini che vengono loro mostrate. Contiene due aree principali su cui focalizzarsi: il campione dell’immagine e l’input usato per valutare la qualità dell’immagine.

Esulando un attimo dall’ordine, discutiamo prima dell’input. Ho rimuginato un po’ su alcune opzioni quando si è trattato di decidere che input type usare. Ho preso in considerazione un input select con delle scelte grossolanamente predefinite, un input con un type number e altre scelte. Tuttavia, quello che mi sembrava avesse più senso per me, è stato un input slider con type range.

Un input slider è più intuitivo di un input testuale o di un elemento select popolato con varie scelte. Dal momento che stiamo chiedendo una valutazione soggettiva riguardo a qualcosa con un così grande range di interpretazioni, uno slider permette ai partecipanti maggior granularità nelle loro valutazioni e dà ulteriore accuratezza ai dati raccolti.

Ora parliamo del campione dell’immagine e di come viene selezionato dal codice di back-end. Ho deciso da subito nello sviluppo del sondaggio che volevo immagini che non fossero note nelle collezioni di foto stock esistenti. Volevo anche fonti non compresse così non avrei presentato ai partecipanti degli esempi di immagine ri-compressa. Per fare ciò, mi sono procurato delle immagini da un fotografo locale. Le venticinque immagini che ho scelto erano immagini raw minimamente processate dalla macchina fotografica del fotografo. Il risultato era un insieme logico di immagini che sembravano visualmente legate le une alle altre.

Per valutare correttamente la percezione attraverso l’intero spettro delle impostazioni di qualità, avevo bisogno di generare ogni immagine dalle fonti di cui sopra a novantasei diverse impostazioni di qualità da 5 a 100. Per tenere conto delle diverse larghezze e densità di pixel degli schermi esistenti, ogni immagine doveva essere generata a quattro diverse larghezze per ogni impostazione di qualità: per la precisione, 1536, 1280, 1024 e 768 pixel. Esattamente il lavoro per cui è stato creato srcset!

Per completare il tutto, le immagini dovevano anche essere codificate sia in formato JPEG sia in formato WebP. Come risultato, il sondaggio estrae a caso tra 768 immagini per campione in tutto il range di qualità, il tutto inviando anche l’immagine migliore per lo schermo del partecipante. Questo significa che sui 25 campioni di immagine che i partecipanti valutano, il sondaggio le sceglie da un insieme di 19.200 immagini in totale.

Ora che abbiamo esaminato la nascita e la progettazione del sondaggio, vediamo come il sondaggio è stato migliorato implementando il feedback degli utenti nel secondo round.

Ascoltare i feedback#section11

Quando ho lanciato il secondo round del sondaggio, ho ricevuto una valanga di feedback da designer, developer, accessibility advocate e addirittura ricercatori. Sebbene le mie intenzioni fossero buone, avevo inevitabilmente tralasciato alcuni aspetti importanti, che avevano reso necessario farne un secondo giro. Iterazione e miglioramento sono cruciali nel migliorare l’utilità di un design e questo sondaggio non faceva eccezione. Quando miglioriamo i design con il feedback dagli utenti, portiamo un progetto da “nella media” a “memorabile”. Arrivare a questo punto significa gestire il feedback senza problemi e affrontare degli item distinti e perseguibili. Nel caso del sondaggio, incorporare il feedback non solo produceva una user experience migliore, ma migliorava anche l’integrità dei dati raccolti.

Creare un input slider migliore#section12

Sebbene il primo round del sondaggio fosse stato utile, mi sono imbattuto in alcuni problemi con l’input slider. Nel primo round del sondaggio, l’input aveva questo aspetto:

Ci sono stati due reclami ricorrenti riguardo a questa specifica implementazione. Il primo era che i partecipanti sentivano di dover allineare la propria valutazione a una delle etichette sotto la traccia di scorrimento. Ciò non era auspicabile per il semplice fatto che il cursore è stato scelto specificamente per incoraggiare i partecipanti a fornire valutazioni sfumate.

La seconda lamentela è stata che il pulsante di invio rimaneva disabilitato fino a quando l’utente non interagiva con il cursore. Questa scelta progettuale aveva lo scopo di impedire ai partecipanti di fare semplicemente clic sul pulsante di invio su ogni pagina senza classificare le immagini. Sfortunatamente, questa implementazione era involontariamente ostile all’utente e necessitava di miglioramenti, perché impediva agli utenti di classificare le immagini senza una spiegazione chiara e ovvia del perché.

Risolvere il problema con le etichette significava ridisegnare il cursore come appariva in Figura 3. Ho rimosso completamente le etichette per eliminare la tentazione degli utenti di allineare le loro risposte ad essi. Inoltre, ho modificato la proprietà background dello slider con un pattern gradiente, che suggeriva ulteriormente la granularità dell’input.

Il problema del pulsante di invio riguardava la modalità di richiesta degli utenti. Nel primo round era visibile il pulsante di invio, tuttavia lo stato disabilitato non era abbastanza ovvio per alcuni. Dopo aver consultato un collega, ho trovato una soluzione per il secondo round: al posto del pulsante di invio inizialmente visibile, è nascosto da del testo guida:

Una volta che l’utente interagisce con il cursore e valuta l’immagine, viene attivato un evento change associato all’input, che nasconde il testo guida e lo sostituisce con il pulsante di invio:

Questa soluzione è meno ambigua e instrada i partecipanti lungo il percorso desiderato. Se una persona con JavaScript disabilitato visita il sondaggio, il testo guida non viene mai mostrato e il pulsante di invio è immediatamente utilizzabile. Questo non è l’ideale, ma non esclude i partecipanti senza JavaScript.

Affrontare i problemi di scorrimento#section13

La pagina del sondaggio funziona particolarmente bene con l’orientamento verticale. I partecipanti possono vedere tutta l’immagine (o la maggior parte di essa) senza dover scorrere. Tuttavia, nelle finestre del browser o dei dispositivi mobili con orientamento orizzontale, l’immagine del sondaggio può essere più grande della viewport:

Lavorare con uno spazio verticale così limitato è difficile, specialmente nel caso in cui lo slider deve essere fissato nella parte inferiore dello schermo (che gestiva un precedente feedback dell’utente dal primo round di test). Dopo aver discusso il problema con i colleghi, ho deciso che gli indicatori animati negli angoli della pagina dovevano segnalare agli utenti che c’è ancora una parte dell’immagine da vedere.

Quando l’utente raggiunge la parte inferiore della pagina, gli indicatori di scroll spariscono. Poiché le animazioni possono dare fastidio ad alcuni utenti, si è usata una media query prefers-reduced-motion per disabilitare questa (e tutte le altre) animazioni se l’utente ha dichiarato di preferire movimenti ridotti. Nel caso in cui JavaScript sia disabilitato, gli indicatori di scrolling sono sempre nascosti nell’orientamento portrait dove è meno probabile che siano utili e sempre visibili nel landscape, dove è più probabile che siano più necessari.

Evitare il sovradimensionamento dei campioni di immagine#section14

Un problema che è stato portato alla mia attenzione da un collega è stato il modo in cui l’immagine del sondaggio sembrava espandersi senza limiti con la viewport. Sui dispositivi mobili questo non è un problema, ma su schermi di grandi dimensioni e persino su display ad alta densità di dimensioni modeste, le immagini possono essere ridimensionate eccessivamente. Poiché l’attributo srcset del tag responsive img specifica un’immagine con risoluzione massima di 1536w, un’immagine può iniziare a ridimensionarsi a “small” per dimensioni superiori a 768 pixel di larghezza su dispositivi con un device pixel ratio pari a 2.

Un po’ di sovradimensionamento è inevitabile e accettabile. Tuttavia, quando è eccessivo, gli artefatti di compressione in un’immagine possono diventare più pronunciati. Per gestire la cosa, la max-width dell’immagine del sondaggio è impostata a 1536px per i display standard a partire dal secondo giro. Per i device con una device pixel ratio di 2 o superiore, la max-width dell’immagine del sondaggio è impostata alla metà di quello, ossia a 768px:

Questa piccola (ma importante) correzione assicura che le immagini non siano ridimensionate oltre un limite ragionevole. Con una risorsa immagine ragionevolmente dimensionata nella viewport, i partecipanti valuteranno le immagini in prossimità o in corrispondenza delle dimensioni naturali di una determinata immagine, in particolare su schermi grandi.

Il feedback degli utenti è prezioso. Questi ed altri punti di feedback di UX che ho incorporato hanno migliorato sia la funzione del sondaggio sia l’integrità dei dati raccolti. È bastato sedersi con gli utenti e ascoltarli.