Chi o cosa ha deciso la durata del timeout di rete convenzionale?

Il tuo collega di lavoro ha torto totalmente sulla relazione tra timeout e esperienza utente. Certo, l'utente vorrebbe una risposta entro un secondo, ma desidera una risposta di successo . Cambiare il timeout in un secondo non aiuta in questo. Preferisco avere un'applicazione che mi dia quello che voglio entro tre secondi da quello che mi dice in un secondo che non riesco a ottenere quello che voglio.

Il tuo criterio dovrebbe essere: Impostare il timeout su un valore x, in modo che sia molto improbabile che il server risponda a tutti se non ha risposto entro x secondi. Se lo si imposta più in alto non aiuta, se lo si imposta in basso si perdono le risposte valide dal server.

Se hai richieste server in cui sai che l'utente sarà in attesa: invia la richiesta e avvia un timer. Se la richiesta non risponde entro un secondo, mostra un'interfaccia utente che mostra che l'app è occupata e ha un pulsante di annullamento. Se la richiesta risponde, rimuovi l'interfaccia utente (ma lasciala per almeno mezzo secondo per evitare "lampeggiante" se una richiesta richiede esattamente 1,1 secondi). Se l'utente preme "Annulla", annulla la richiesta, se possibile, assicurati che qualsiasi risposta che potrebbe arrivare sia ignorata (quando annullo un'operazione, mi aspetto che venga cancellata). È possibile visualizzare un errore se si ottiene un timeout dopo 60 secondi.

E se hai un'operazione che consiste in più richieste, trattala come una singola unità.

Ci sono stati articoli relativi ai tempi di risposta per consentirci di avere un ritardo accettabile da una prospettiva psicologica.

Presumibilmente 0,1 secondi si sente istantaneo per un utente, dopo di che il ritardo è evidente.

1 secondo è il maggior numero di ritardi che puoi avere quando l'utente non si sente interrotto dal ritardo.

10 secondi è presumibilmente l'importo massimo che deve essere mantenuto per l'attenzione dell'utente, dopo di che gli utenti tendono a voler fare qualcos'altro nel frattempo.

Anche se non ho mai sentito parlare di 30 secondi usati come metrica particolare o tempo di attesa "standard", anche se lo vedo spesso.

Spero che ti aiuti!

Vorrei anche fare riferimento al articolo di NNGroup @Neil pubblicato . Tuttavia, imporre un timeout solo per il gusto di credere che aumenterà l'esperienza utente è oltre ogni limite.

Le richieste rapide aumentano l'esperienza dell'utente, non i timeout che generano messaggi di errore.

Dicendo qualcosa sulla falsariga di "La richiesta è scaduta, riprova". non è affatto probabile che crei utenti felici. In realtà è probabile che crei più infuriato poiché il tuo compito è quello di assicurarti che la richiesta funzioni correttamente. Questo vuol dire che il timeout non ha aumentato l'esperienza dell'utente in alcun modo concepibile.

Ora passiamo ad un'altra area: cosa succede se le richieste effettivamente iniziano a rallentare a causa di qualcosa di molto semplice come un aumento del carico sui server? I tuoi utenti andranno bene finché una richiesta richiede meno di un secondo.

Cosa succede se iniziano a prendere più di un secondo? Bene, all'improvviso ci sono molti utenti con richieste che scadono - e vedono messaggi di errore che sfuggono al loro controllo. Cosa succede quando le richieste iniziano a scadere? Dalla mia esperienza personale le persone iniziano a rinfrescare / fare clic sui pulsanti molto. È molto probabile che aumenti solo i problemi di caricamento.

The question becomes: what's a good timeout value and how can you determine one from data rather than feeling like you're shooting in the dark?

Questo dipende molto dalla richiesta. In particolare, è logico che una richiesta possa richiedere molto tempo? Gli utenti sono spesso disposti ad aspettare un po 'per le cose che si aspettano di prendere tempo. La generazione di un report sembra un'attività tipica in cui ci si potrebbe aspettare un ritardo di almeno alcuni secondi, ma in questi casi è possibile in genere aiutare l'utente a prevedere un po 'di attesa.

Come punto di arrivo, ritengo che impostare 1 secondo come ambizione per il tempo medio di richiesta sia notevole, ma non imporre una tale regola arbitraria ai tuoi utenti.