Design per interfaccia utente asincrona

5

Ho lavorato a un'integrazione che ha posto un'interessante enigma dell'interfaccia utente di cui vorrei ricevere suggerimenti.

L'interfaccia utente viene visualizzata all'interno di un prodotto di terze parti. Lo stato dell'interfaccia è fornito da chiamate a un servizio che ho scritto. Ci possono essere dei piccoli ritardi tra lo stato attuale che cambia l'interfaccia utente cambiando a causa del polling dello stato da parte della terza parte.

Quando un utente interagisce con l'interfaccia utente, le richieste vengono inviate alla mia applicazione. Questo influenza quindi lo stato e la successiva richiesta di polling dello stato aggiornerà l'interfaccia utente.

Il problema è che il ritardo tra premere un pulsante e vedere l'aggiornamento dell'interfaccia utente è forse di 1 o 2 secondi e nei test di usabilità posso vedere che le persone fanno ancora clic prima che l'interfaccia utente si aggiorni, pensando che non abbiano cliccato la prima volta.

Considerati i vincoli (possiamo solo aggiornare l'interfaccia utente tramite il meccanismo di polling - se lo aggiornassimo quando cliccato, il polling potrebbe tornare e sovrascrivere la modifica causando risultati imprevedibili / indesiderabili) ... cosa possiamo fare per fare l'esperienza utente è migliore.

La mia idea attuale è di mostrare un messaggio per un paio di secondi in modo che la gente sappia che il suo clic è stato accettato, il messaggio non sarà influenzato dal polling dello stato, quindi non verrebbe rimosso / sovrascritto prematuramente ecc. Sono sicuro ci sono altre idee là fuori e sono anche fiducioso che qualcuno ha un'idea migliore che ho!

    
posta Fenton 20.11.2011 - 22:48
fonte

2 risposte

1

Solo per gli scopi dei posteri, condividerò la soluzione.

Condizioni di gara

Il problema qui è che il meccanismo di polling avviene ogni n millisecondi, e una richiesta può essere in volo quando un utente fa clic, causando una condizione di competizione.

Percorso felice (il pulsante è abilitato, quindi disabilita e rimane in questo modo):

  • Sondaggio
  • Risposta (pulsante abilita)
  • Fai clic su (disabilita il pulsante)
  • Sondaggio
  • Risposta (pulsante di disattivazione)

Percorso delle condizioni di gara (il pulsante è abilitato, quindi il pulsante disabilita, abilita, disabilita - brutto stato di lampeggio):

  • Sondaggio
  • Fai clic su (disabilita il pulsante)
  • Risposta (pulsante abilita)
  • Sondaggio
  • Risposta (pulsante di disattivazione)

Soluzione: correlazione della versione dello stato

Quando l'utente interagisce con l'interfaccia utente, viene generata una nuova versione di stato (vale a dire un GUID, timestamp, ecc.)

Questa versione di stato viene inviata con ogni richiesta e restituita nella risposta.

Quando viene ricevuta una risposta, la versione dello stato viene confrontata e quelli che non corrispondono vengono scartati.

Esempio

Percorso felice:

  • Sondaggio (v1)
  • Risposta (pulsante abilita) (v1)
  • Fai clic su (disabilita pulsante) (v2)
  • Sondaggio (v2)
  • Risposta (pulsante di disabilitazione) (v2)

Percorso delle condizioni di gara:

  • Sondaggio (v1)
  • Fai clic su (disabilita pulsante) (v2)
  • Risposta ( scartata ) (v1)
  • Sondaggio (v2)
  • Risposta (pulsante di disabilitazione) (v2)
risposta data 21.02.2018 - 15:01
fonte
12

Mostra immediatamente un feedback : modifica lo stato visivo del pulsante, visualizza un bagliore animato.

Se la logica dell'app consente, disabilitare il pulsante una volta premuto, abilitarlo indietro quando arriva la risposta.

Una volta che la risposta è arrivata, mostra il feedback reale : aggiorna i controlli, rimuovi il throbber.

    
risposta data 20.11.2011 - 22:59
fonte

Leggi altre domande sui tag