2012-08-23 9 views
10

Questa domanda riguarda il tentativo di trovare una giustificazione scientificamente o statisticamente difendibile per la scelta di un timeout. Voglio dire che ogni app deve farlo, ma qual è il timeout ottimale? Abbiamo bisogno di più persone per rispondere o commentare. +3, +4 non significa che la domanda è stata risolta. Una domanda importante merita più risposte. Tutti possiamo beneficiare di questa conoscenza.Cos'è avg. timeout della connessione ottimale per l'app mobile?

Fondamentalmente cercando di confrontare:

a short timeout of say 20 seconds, but two connection attempts are made 

vs

one long connection attempt of say 40 or 60 seconds. 

Che ha le migliori possibilità di stabilire una connessione? Abbiamo bisogno di fatti concreti. Finora i numeri che ottengo sono dappertutto negli anni 10, 42, 60. Ma cosa è veramente ottimale?

Ora, naturalmente, dopo 5-10 secondi, l'utente deve essere informato di un problema in ogni caso, ma quale è l'approccio migliore per stabilire una connessione.

Nota: sono consapevole che esistono molti fattori, ma come sviluppatori di app non è sempre possibile ottenere il permesso di esaminare la situazione del segnale Wi-Fi, ecc. Tuttavia, deve esserci una risposta razionale a ciò che è meglio in media.

+2

La risposta è chiaramente 42. O 60, questo è ciò che [AndroidHttpClient] (http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.1.1_r1/ android/net/http/AndroidHttpClient.java # AndroidHttpClient) utilizza come predefinito. – zapl

+0

Ma si tenta di connessione durante questo tempo? –

+0

Afaik no. Il problema con le connessioni mobili è che cadranno regolarmente per diversi secondi e se i tuoi timeout sono troppo stretti potresti non ottenere nulla. – zapl

risposta

8

Spererete di ottenere risposte migliori, ma dall'esperienza personale posso parlare del lato utente delle cose. Se apro un'app che richiede una connessione dati, come il mio browser Web o un client social, desidero che scada in meno di 5 secondi, perché non dovrebbe richiedere molto tempo per determinare se effettivamente ho una connessione o no .

È possibile considerarlo dal punto di vista del dispositivo, ma è altamente variabile (wifi rispetto a 3G, chip di rete specifico, sistema operativo, connessione dati attualmente attiva, ecc. Potresti farla finita con 30 secondi se la connessione dati non è necessariamente critica per l'applicazione, ma il punto principale è che la limitazione tecnologica è solo una parte del tempo necessario per il timeout della connessione.

+0

Penso che questo offra informazioni su quando un utente deve essere a conoscenza di un potenziale errore di connessione. Sto anche cercando di determinare quale sia l'approccio ottimale per ottenere effettivamente una connessione all'interno di una finestra di dire 60 secondi. è una lunga prova o diversi tentativi più brevi. –

5

Metto sempre dieci secondi al massimo, anche se è una preferenza personale. Pensa se stai tenendo il telefono per cinque secondi e stai aspettando che le informazioni vengano visualizzate. Sarei già frustrato, quindi aggiungere il doppio valore sembra appropriato. Se c'è un problema mi piacerebbe sapere su di esso tramite un Toast, vista piè di pagina o qualcos'altro.

+0

Concordo sul fatto che alcune informazioni debbano apparire all'utente entro 5-10 secondi. –

0

Ecco cosa the UX research says about user attention (parti interessanti sono evidenziati):

  • Più lungo di 1 secondo flusso pause di pensiero
  • Più lungo di 10 secondi perde le attenzioni degli utenti
  • più semplici le attività devono essere completate entro 1 minuto

Quindi se è un compito importante per l'utente, il ritardo di 60 secondi è OK. Altrimenti più di 10 secondi è un problema. La cosa particolare è che il periodo di tempo compreso tra 20 e 50 secondi non influisce in alcun modo sull'impatto dell'utente: è tutto il tempo dopo che "l'attenzione è stata persa", ma prima "abbandonerà un compito".

In sostanza, se non è possibile scendere a un limite di time-out di 10 secondi, non preoccuparsi e affrontare il problema UX in un modo diverso.

Ovviamente, questo non si applica a tutte le situazioni, quindi portalo con un pizzico di sale.

Problemi correlati