Alberto Mucignat

random thoughts around web stuffs (è tutto un equilibrio sopra la follia…)

Velocità delle interazioni su mobile: ancora più importante che su desktop

Scritto il a proposito di User experience - 9 Commenti

Oggi Davide Casali ha scritto un post sulla lentezza del feedback della UI di Android. Ho già scritto diverse volte a proposito dell’importanza della velocità delle interazioni, ma il caso del mobile è ancora più emblematico.

Va detto che Android non può “controllare” l’hardware su cui gira, a differenza di Apple. Ma vorrei andare oltre Android e l’intreccio hw/sw. Penso a tutti i siti e le app mobile in genere, e faccio una considerazione più generale: se nel pc di casa/lavoro accettiamo forse un po’ di lentezza, su mobile la velocità è condizione necessaria.

Il tempo di una persona via mobile è sicuramente più parcellizzato e gli stimoli sono molto più rapidi e molto più sensibili al cambiamento rispetto al desktop. Per questo è necessario che la responsività dell’interfaccia sia immediata.

Convengo con Davide anche sulla chiosa finale: una delle cose più difficili è far capire ai clienti l’importanza della velocità. Un po’ perché di solito io lavoro con il Marketing, mentre è l’IT ad avere la responsabilità della performance. Un po’ perché la velicità è sempre considerata una “cosa tecnica”, che però ha effetti incredibili sulla user experience.

Insomma, per me la velocità è uno dei punti principali che hanno effetti sull’usabilità e la user experience in genere. È purtroppo un punto che i designer non riescono a controllare, ma è prioritario curare questo aspetto ed è compito nostro farlo presente a chi di dovere.

Tag: , ,

9 commenti ↓

  • #1 Matteo Balocco 26/10/2011 16:54

    Nella mia esperienza – aggiungo un elemento alla discussione, spostando un po’ l’oggetto, scusami – ho notato come l’implementazione di prototipi interattivi su iOS (usando Sencha Touch, per esempio) talvolta risulti controproducente proprio per le differenti performance che l’app nativa può offrire in confronto al suo omologo in js/html/css, magari incapsulato con phonegap.
    Per intenderci si verifica, talvolta, la percezione da parte dell’utente che l’app già “ci sia” (un po’ come accade con alcuni prototipi ad alta fedeltà), ma non è sufficientemente performante.
    Per dire: è un problema che si pone anche nella progettazione e implementazione di applicazioni/servizi su sistemi chiusi e altamente performanti.

  • #2 fullo 27/10/2011 12:02

    è più o meno per questo motivo che da un paio d’anni a questa parte porto avanti talk sul WPO (web performance optimization) per l’ottimizzazione a frontend. Pensa che oggi ne porto una a verona sullo sviluppo mobile ad una conferenza delphi :D

    cmq c’è da ricordarsi che sono attività relativamente nuove e, soprattutte, costose da implementare (non c’è una regola precisa, ma si lavora su analisi dei log ed euristiche) e di cui (in italia) non c’è grossa competenza. Inoltre i clienti non riescono a capirne il vero vantaggio fermandosi solo al “costa troppo”. :(

    per rispondere a @matteo la percezione dell’ “un po’ più lento” deriva dal fatto che le applicazioni embeddate in una web view (ie phonegap) fino alla versione 4 di iOS non hanno supporto alla GPU per usare il motore di render nativo (usato da safari mobile). Dalla versione 5 le cose cambieranno e quindi anche la velocità finale dell’app. Inoltre considera, che come per le app native, devi sempre far opera di ottimizzazione per garantire performance ottimali. L’utilizzo as-is di questi framework non porta certo a codice ottiimizzato…

  • #3 Matteo Balocco 27/10/2011 12:15

    Fullo, mi è chiarissimo. Il punto che ponevo (ma sono stato poco chiaro io) è che Sencha, per fare un esempio, può essere usato per prototipare app mobili. In fase di prototipazione l’ottimizzazione è (o potrebbe essere) secondaria, anche perché richiede tempo che in quella fase non c’è. Non è che dobbiamo iniziare a ragionare su una fase di prototipazione molto più integrata con quella che sarà la fase di sviluppo (anche tecnologicamente, come produzione di codice, dico)? Non so, eh… pongo la questione.

  • #4 Alberto 28/10/2011 16:08

    Dunque, se stai prototipando non sono fondamentali le performance, anche perché in fase di test puoi spiegare agli utenti e quindi si “accontentano”. Certo se le performance sono fondamentali per il tipo di interazione allora è chiaro che dev’essere responsiva al max. Chiaramente in produzione è un’altra cosa.

  • #5 Alberto 28/10/2011 16:11

    il ragionamento finale di matteo è l’eterna nostra discussione. ripeto quello che dico da tempo: credo che il max sarebbe riuscire a mettere assieme design+sviluppo (per chi ci riesce), ma nella maggior parte dei casi sono comunque 2 track che seguono percorsi diversi. per questo secondo me il design e tutti i suoi artefatti sono purtroppo “a perdere”, ma sono un investimento necessario. fermo restando che impostando il lavoro bene (usando dei framework css, per esempio) il lavoro di chi sviluppa dovrebbe essere facilitato.

  • #6 Matteo Balocco 28/10/2011 16:15

    Alberto, una domanda, se la cosa non espone troppo il tuo “metodo”… :)
    Tu fai vedere i prototipi al cliente oppure fai solo vedere i risultati dei testi, su wireframes e report?
    Perché io mi riferivo soprattutto all’impatto della performance del prototipo sul cliente e non tanto sull’utente finale (insomma, vero, il solito discorso su quanto deve essere alta la fedeltà della progettazione).

  • #7 Matteo Balocco 28/10/2011 16:16

    L’autocorrettore ha modificato test in testi, sorry.

  • #8 Alberto 28/10/2011 16:20

    noi ormai facciamo vedere tutto al cliente (o quasi). non mi preoccupa più la bassa fedeltà e i clienti ne sono consapevoli. altri clienti si ostinano a voler lavorare in alta fedeltà, ma prendono legnate…

  • [...] della velocità nella user experience ne ho parlato molte volte (ultimamente in relazione alla sua importanza maggiore in campo mobile), ma anche perché lo ritengo sempre di più un parametro chiave che però ha un problema: è poco [...]

Commenta il post ↓