Il progresso della progress bar

Posted on Saturday, November 22nd, 2008 at 16:18, under tech. Tags: , , , ,

Osservavo oggi la progress bar di Leopard mentre lentamente mi teneva informato sullo stato di alcuni updates. Probabilmente il mio umore non era già dei migliori: avevo appena resettato il Mac per un misterioso congelamento dell’interfaccia e mi aspettava un altro restart per l’installazione degli updates.

Forse è per questo che, guardando la barra, mi sono reso conto di una cosa. Le progress bar fanno schifo.

Non sto parlando di estetica, ma di problemi nell’interazione. Problemi gravi, a cui però ci siamo talmente abituati da non vederli più. In particolare i problemi sono due, a cui se ne può aggiungere un terzo – meno grave:

  1. Quando vedo una progress bar, mi aspetto che questa si riferisca all’operazione in corso. Il fatto che la barra arrivi al completamento e poi riparta da capo – senza che cambi il nome dell’operazione – è un esempio di pessimo design.
  2. Quando vedo una progress bar, mi aspetto che questa sia in rapporto 1:1 con l’operazione a cui si riferisce. Il fatto che la barra arrivi fino a metà e l’operazione si concluda – facendo quindi ripartire la barra da zero – è un altro esempio di pessimo design.
  3. Infine, una progress bar serve a dare due informazioni: una riguarda lo stato corrente dell’operazione, mentre l’altra è la conferma che qualcosa sta succedendo (ovvero: il computer non si è inchiodato). Se la barra si ferma per un’ora sul 23%, questa informazione viene persa. Lo stesso problema si ha quando la barra avanza di un pixel ogni 15 minuti: alzi la mano chi non ha mai usato il puntatore del mouse come indicatore per vedere se una barra avanzava o meno a livello subatomico :D

I primi due problemi sono quelli che ho notato oggi negli updates di Leopard, mentre il terzo è una caratteristica peculiare delle installazioni Adobe. Gli stessi problemi si riscontrano comunque in moltissimi altri casi.

Viene da chiedersi se mai avremo un qualche progresso verso delle progress bar migliori.

L’immagine è CC kbaird: http://flickr.com/photos/kevlar/2272366843/

3 Responses to “Il progresso della progress bar”

  1. Raibaz Says:

    Tutto vero :)

    In realtà i problemi, soprattutto i primi 2, non sono tanto della progress bar in sè per sè ma di chi ha progettato l’interfaccia dell’intera applicazione, visto che tipo, il primo problema, è facilmente risolvibile aggiornando il nome dell’operazione in corso quando si resetta la progressbar…evidentemente però, chi progetta le applicazioni di installazione di software ha in mente l’utente medio che non legge niente e schiaccia “avanti-avanti-avanti-avanti”, per cui una descrizione dettagliata delle operazioni in corso e un uso ponderato delle progressbar è superfluo :)

  2. Il punto 1 lo noto raramente sugli applicativi Mac e mi pareva che l’Update non lo facesse. Farò attenzione.

    Per il resto realizzare una progress bar non è affatto semplice. Perché un Interaction Designer può anche venire a dire allo sviluppatore: “Guarda, deve essere unica, fluida, calcolare il tempo nel modo giusto ed essere correttamente distribuita nel tempo” (ovvero, evitare i punti da te citati).

    Sarebbe fantastico se lo sviluppatore potesse farlo: il problema è:
    A.
    Una progress bar unica significa mettere assieme più step separati. Che so: inizia con un download, poi fa un controllo MD5 per verificare che sia corretto, poi lo apre, poi lo installa, poi fa l’operazione di ottimizzazione e infine chiude e pulisce.
    Più step separati significa però un enorme problema: io ho Fastweb, quindi il download mi verrà giù in quattro nanosecondi, mentre a mio zio in montagna con un 56k impiegherà mezz’ora: come dimensiono la prima fase? Dinamicamente? Posso fare un calcolo dinamico senza sapere gli altri 4 step quanto impiegheranno? No…
    Magari la verifica poi mio zio la fa con un Quad Core, mentre io ho un G4… lui impiegherà pochissimo mentre io sarò ancora lì a macinare dati.
    Eccetera.
    Come vedi, anche l’operazione più banale significa che di fatto la tua progressbar è in mezzo a una pletora di variabili hw e sw differenti, praticamente impossibili da calcolare.
    Quando vedi una barra che arriva a metà e poi si conclude, significa grosso modo un errore di stima nell’ultima fase (che so, un cleanup?) che magari sulle macchine in cui è stato progettato inizialmente impiegava realmente la metà del tempo.

    B.
    Se si congela si congela, non puoi farci niente. E se la barra à lunga X per una operazione che impiega ore, avanzerà di pochissimi pixel alla volta. E più di tanto non puoi farci. Al più metti un timer con il tempo stimato rimanente (con tutti i difetti del caso di una stima così precisa).
    Qui però puoi notare un dettaglio molto ben realizzato su OSX: la barra ha sovrapposto un overlay in movimento, che ti segnala che sta comunque lavorando, quindi hai due indicazioni: lo stato di avanzamento della barra e il movimento da destra verso sinistra delle ondine aqua, che rappresentano che “ci sta lavorando”.

    C.
    Non ci sono reali strumenti migliori per farlo. Punto iniziale, punto finale e il progresso dal primo al secondo è l’indicazione più chiara ed intuitiva del processo. Oggi spesso si usano i throbbe, che evitano di dover quantificare “a che punto si è”, ma in media è una perdita di feedback, anche se minimizzabile e a volte disorientante.

    Per questo non credo che ci sarà forse mai un progresso verso una barra realmente funzionante, perché in realtà anche queste funzionano messe in un contesto perfettamente rispondente alle specifiche… :|

  3. Simbul Says:

    Si, sono conscio dei problemi tecnici, ma la mia sensazione è che manchi proprio l’attenzione nei confronti delle progress bar, come se ormai fosse un dato di fatto che sono inaffidabili e non valesse la pena migliorarle.

    Riguardo al tuo punto (A), non pretendo che la barra avanzi in maniera sempre costante. Sarebbe molto bello ma – questo sì – anche irrealistico. Solo che se un’operazione deve impiegare 100 non può fermarsi a 50 (e non intendo che dal 50 in poi la barra si riempie molto velocemente: a 50 termina proprio l’operazione).

    Se si congela – punto (B) – non c’è molto da fare, ok. Però perché fare una barra lunga X per un’operazione di ore? Si suddivide l’operazione in step e si mostrano delle barre relative ai singoli step.
    L’overlay di OSX mi pare buono sulla carta, ma inutile in pratica: la percezione è che l’overlay sia parte integrante della grafica della barra e che quindi continui a ondeggiare anche se il processo sottostante è morto :D
    Lo stesso problema si trova, in misura molto maggiore, negli spinner usati nelle pagine web: spesso lo spinner gira come un pazzo ma sotto non accade nulla, ad esempio perché è fallita una chiamata ajax. In questo caso l’informazione non solo è meno ricca (non so a che punto sono) ma anche palesemente falsa (posso anche aspettare 10 giorni e non succederà niente).