Ieri sera stavo provando la nuova creatura di Mozilla Foundation: Fennec.

Fennec è un browser per dispositivi mobili (molto orientato a symbian al momento) derivato da firefox ma con un’interfaccia e una logica completamente studiata per schermi di piccole dimensioni.

Fennec fa della propria interfaccia il suo cuore avendo pensato molto bene alle priorità funzionali che un’utente necessita in mobilità. Ci troviamo così di fronte ad un’interfaccia molto semplice che concede il massimo dello spazio al contenuto e alle funzionalità primarie (bookmarks, search e reload) e porta in secondo piano tutte le funzionalità (come i tabs o gli strumenti di navigazione) che non sempre sono prioritarie.

Fennec introduce inoltre una gestione integrata della barra dell’URL, la ricerca, la storia e i preferiti spingendosi ancora oltre a ciò che è stato introdotto in firefox 3.

Probabilmente una volta sul mercato Fennec non sarà dominante suli dispositivi mobili ma prenderà sicuramente delle discrete quote di mercato offrendo così a chi sviluppa applicazioni web una piattaforma stabile, semplice e potente su cui appoggiarsi.

La griglia è a mio vedere uno degli elementi fondamentali per la sostenibilità di una qualsiasi interfaccia. Per esempio sulla griglia  si basa il presente e il futuro di ciò che potrà essere presentato su un sito in termini di struttura ed elementi di contenuto.

Da anni si discute sul come strutturare al meglio una grigli intermediando esigenze di risoluzione, di contenuti, di elementi dalla dimensione standardizzata (es: la pubblicità) e di percezione visiva senza però trovare una soluzione unica che si adatti a tutte le interfacce.

Fino ad oggi chi ha fatto il ragionamento più esteso e approfondito sulle griglie è stato Khoi Vinh con l’aiuto di Mark Boulton presentando durante SXSW Interactive una riflessione completa su come strutturare una griglia.

Comunque elidendo i ragionamenti più teorici sulla strutturazione delle griglie (che in genere vengono definite a livello di wireframes) vi è quasi sempre stato un problema a mantenerle poi coerenti nel visual design e nell’implementazione.

Oggi Nathan Smith ci da una mano nel risolvere questa problematica proponendo il 960 Grid System una libreria pronta per creare griglie a 12 e 16 colonne regolari all’interno di wireframes, photoshop e CSS.

Questa griglia è molto interessante per accellerare la progettazione e lo sviluppo ed eccelle nelle caratteristiche di percezione anche se pecca notevolmente nell’integrare i formati pubblicitari.

In ogni caso vi suggerisco di provarla

Ultimamente ho iniziato ad usare come riferimento Knol al posto di Wikipedia cercando di approfondire alcuni argomenti legati alle interfacce utente e ai processi mentali.

Utilizzandolo ho notato come il modello di Knol nonostante abbia una maggiore frammentazione delle informazioni fornisce una qualità di approfondimento eccelsa data dal modello “articolo personale” adottato da questa piattaforma. In pratica è facile trovare più articoli di più esperti, relazionati tra loro, che forniscono uno spettro molto ampio di punti di vista.

Se a questo unite l’indice di reputazione dell’autore/articolo, la discussione e tutti gli strumenti presenti in wikipedia è facile accorgersi di come a volte è molto più importante avere uno spettro di informazione più ampio (anche se a volte contrastante) piuttosto che unificato ed intermediato.

La verità non esiste, esiste una realtà personale fatta di punti di vista e questa realtà si può definire come conoscenza personale; conoscenza che Knol sa raccogliere molto bene.

Questo concetto tra l’altro può anche racchiudere in parte il concetto di personal knowledge management che abbiamo discusso più volte con Gianandrea dove si immaginava che un’utente in un suo spazio personale potesse gestirsi il suo punto di vista conoscitivo confrontandolo con quello comune.

Personalmente alla fine ritengo che in generale il valore della conoscenza sta proprio nella prospettiva più ampia regolata però dai vari indicatori di reputazione che fanno emergere la versione più comunemente accreditata.

Sul sito dell’italian information architecture summit 2007 sono stati pubblicati i video dei vari interventi tra cui il mio su facetag.

Vi consiglio di guardarveli un po’ tutti in quanto il livello degli argomenti è molto alto, in particolare quello di Eric Reiss (che è un vero è proprio attore

Stamattina leggendo questo post di Napolux mi sono reso conto di come molte persone alle nostre latitudini e longitudini ragionano quasi unicamente per schemi di bellezza e non per schemi di semplicità d’uso per le varie culture.

Dico questo perchè in questo caso specifico non è una questione di figa e non figa ma di utenti. Gli utenti cinesi non si trovano a proprio agio con l’interfaccia più semplice e grezza con cui ci siamo abituati e di fronte a test d’usabilità e ricerche etnografiche google già in passato si è trovato a dover differenziare il design per le varie culture.

Un altro esempio storico è la versione coreana di google che comprende direttamente un iconografia e una legenda senza le quali gli utenti locali non riuscirebbero ad usarlo.

Qualche giorno fa mi sono imbattuto (su segnalazione di Totanus) in un’esperienza molto particolare dal punti di vista di chi si occupa di progettazione e realizzazione vissuta da Ted Patrick, uno dei più attivi evangelisti Flex.

Ted come molti sviluppatori usa Flex (ma il discorso vale anche per altri linguaggi/ambienti di sviluppo) per prototipare gli applicativi che andrà in seguito a sviluppare nel dettaglio utilizzando chiaramente i componenti di default che sono disponibili. Questi componenti sono però pensati a livello visuale e funzionale per creare applicazioni potenzialmente finali.

Dove sta dunque il problema?

Il problema è che Ted quando mostra i suoi prototipi con una così alta fedeltà ai clienti si trova davanti un gruppo di persone che pensa che l’applicazione sia già terminata e dunque non comprende perchè dovrebbero pagarlo per realizzare la definitiva.

Questo problema è abbastanza noto a chi usa la prototipazione rapida da molti anni ed è il tipico rischio che in genere si prendono inconsciamente coloro che sviluppano in ambienti agili (es: ROR).

Infatti realizzare direttamente prototipi ad alta fedeltà da un lato accellera lo sviluppo ma dall’altro non da il tempo agli stakeholders di comprendere l’evoluzione e la maturazione del prodotto; non portando così il giusto ritmo nei cambiamenti di requisiti e facendo passare il progetto come “semplice”.

Ted dall’alto della sua esperienza ha risolto la situazione creando un foglio di stile per l’UI di default di Flex semplificato ai minimi termini (wireframes), soluzione che però probabilmente non gli risolverà comunque tutte problematiche date da un approccio prototipale diretto.