If the implementation is hard to explain, it's a bad idea.

Qualche giorno fa (il 21 ottobre) ho avuto la possibilità di partecipare al Google Developer Day, l’evento organizzato da Google per promuovere i nuovi prodotti per gli sviluppatori.

E’ stata una esperienza piuttosto interessante soprattutto per uno come me che ha sempre guardato allo sviluppo di software più come ad un divertimento che come ad un lavoro. Ecco alcune considerazioni sparse e forse pure sconclusionate sull’esperienza.

• Non ci sono più i nerd di una volta. Niente occhiali spessi, niente brufoli, pochi vestiti trasandati. La popolazione era più che altro costituita da ragazzi universitari e sviluppatori di aziende di software ben vestiti che facevano sfoggio di palmari, Iphone, Black Berry e quant’altro. Peccato, io ero affezionato al mio stereotipo.
• Il cibo era in linea con le aspettative, ovvero ottimo. Peccato che la grande ressa di fronte al buffet mi abbia costretto a mangiare in piedi e piuttosto in fretta per arrivare in tempo al codelab di App Engine.
• Il keynote è stato davvero molto orientato al marketing dei prodotti Google. Un 10 va comunque al buon Brian Fitzpatrick che ha presentato con grande stile e facendo divertire la platea. Oggetto della presentazione è stato quello che non si fa fatica a definire come un altro capitolo del piano per il “dominio del mondo” di Google. Dopo aver di fatto ottenuto il primato nella gestione dell’accesso all’informazione sul web Google ha deciso di aprire sempre più il suo modello di business (similmente a quanto hanno già iniziato a fare Amazon). Un progetto che si fonda su la creazione di nuovi client (Android e Chrome) e sulla promozione di tecnologie lato server (App Engine, Google Data API, Open Social) che consentano un più semplice accesso programmatico ai dati e lo sviluppo di applicazioni basate su una infrastruttura scalabile.
• App Engine? Mixed feelings. La talk ed il codelab su App Engine erano la cosa che mi incuriosiva di più. Sono arrivato all Google Developer Day interessato alla nuova piattaforma ma con qualche dubbio, ne sono uscito ancora più dubbioso. App Engine è una idea ottima ma ci vorrà del tempo prima che diventi qualcosa di davvero usabile. Perché? Ecco le prime cose che mi vengono in mente:

• Mancanza di support per il threading
• Manca la possibilità di creare operazioni ripetute a intervalli regolari (tipo crontab)
• Manca la possibilità di creare thread
• Il fatto che sia basato su un database non relazionale (Bigtable) rende piuttosto complicato lavorare con i framework esistenti come Django. Bigtable inoltre non supporta l’integrità referenziale, lasciando dunque il compito di mantenere la coerenza interna dei dati allo sviluppatore.

Momento migliore? Lo scambio di battute con uno degli ingegneri di Google durante il codelab: Io (copiando ed incollando un pezzo di codice dalla documentazione di App Engine) : – This is cut & paste programming! Lui (ridendo): – This is the way I do it!

L’usabilità è spesso vista come una disciplina complessa, fatta di test lunghi e costosi e di procedure articolate che non danno un immediato riscontro della loro efficacia. Se in parte questo è vero non bisogna dimenticare che il modo migliore per far fruttare le nozioni di usabilità è considerarle come parte del ciclo produttivo di un prodotto software e in particolare di un sito web. Usabilità in questo senso è anche un certo sguardo con cui osservare un prodotto, una attenzione ad alcune semplici linee guida che possono fare la differenza. Provo ad illustrare questo approccio con una piccola sfida: scegliere un sito web e fare, in un tempo massimo di 15 minuti, una valutazione che evidenzi i principali errori di usabilità.

Nell’analisi mi servirò delle dieci euristiche di Nielsen per il design di interfacce: dieci principi facili da ricordare ed utili per dare un giudizio sull’usabilità di un qualunque prodotto interattivo.

La prima “cavia” di questo esperimento è il sito dell’ aeroporto internazionale “Diagoras” di Rodi. Cominciamo con il fare qualche considerazione sull’obbiettivo del sito: un utente che cerca il sito di un aeroporto si aspetta in generale di trovare informazioni su tale aeroporto, dove sta, quanto è distante dalla città, quali sono i servizi di cui dispone, ed altre informazioni utili per chi ha intenzione di arrivare o partire da quella località.

Detto questo diamo un’occhiata sito, cronometro alla mano per 15′, navigando ed indicando le zone problematiche. Il risultato è visibile qui sotto:

Vediamo ora di raggruppare i vari problemi in base alla linee guida violate:

• Visibilità e riconoscibilità dello stato del sistema (problema 3). I link non sono rappresentati secondo una modalità che indichi se sono stati cliccati o se sono cliccabili.
• Consistenza e rispetto degli standard (problema 3 e 4) I link non sono rappresentati secondo la convenzione più diffusa ne sono resi riconoscibili in qualunque altro modo. Il link identificato dal punto 4 porta ad una pagina in greco, lingua differente dal resto del sito.
• Estetica e design minimalista (problemi 1, 2, 6) Il design non è elastico ed a una risoluzione superiore a 800×600 il testo dell’intestazione tende a sovrapporsi, le informazioni scritte in verticale sono molto complicate da leggere, il nome del webmaster non è un contenuto particolarmente interessante (a parte forse per il webmaster stesso), dovrebbe essere messo in posizione più defilata
• Riconoscimento senza ricorrere alla memoria (problema 7) Il link evidenziato porta alla versione in greco del sito, sarebbe importante rendere il link più esplicito infatti chi si trova davanti una lingua che non conosce cerca di andarsene al più presto.

Un discorso a parte è rappresentato dal problema n°5, si tratta del classico link rotto, un problema che potrebbe anche essere temporaneo.

Beh, non male per una osservazione di soli 15 minuti su un sito così semplice. Per ora mi fermo qui, se questa idea piace potrei pensare di fare qualche altra analisi lampo. Chissà intanto se qualcuno riesce a trovare qualche altra violazione dei principi di usabilità…