La massiva immissione sul mercato di terminali internet-enabled (palmari, smartphones, tablet-pc) solleva oggi un problema del tutto inedito: la coerenza logica della organizzazione dell’informazione fra devices atipici ed eterogenei. Tale problema p

Disponibilità Vs. Confezionamento dell’informazione

Già l’avvento dei telefonini basati su protocollo WAP 1.0 aveva creato una prima forzatura di tipo progettuale: l’impossibilità della compresenza sul minuscolo schermo di menu e contenuto (una notizia o un lancio, ad esempio) aveva costretto l’information architect a progettare percorsi brevissimi fra il primo livello e il contenuto da fruire, in alcuni casi causando macroscopici quanto inevitabili errori dovuti alla confusione fra “livello di priorità “ dell’informazione, e “livello logico” della stessa. A ben guardare però, tale esperienza può fornire all’information architect un segnale importantissimo per l’impostazione del proprio lavoro negli anni a venire: il sostanziale insuccesso commerciale della navigazione WAP messo in relazione con la straordinaria penetrazione del telefono cellulare ci rivela non soltanto il dato evidente dell’immaturità del sistema, ma anche e sopratttutto il fatto che l’utente, abituato ormai ad un evoluto sistema semantico offerto quotidianamente dai media tradizionali (web incluso), non privilegia la disponibilità dell’informazione al suo confezionamento.

Wireless devices: diversi ma uguali

Superata l’esperienza WAP 1.0, la materia hardware e software di cui oggi disponiamo è certamente più ricca, e pone quindi, a partire dai concetti appena espressi, prospettive più interessanti. La nuova implementazione WAP (2.0) ha infatti affiancato XHTML al linguaggio WML utilizzato nella prima implementazione del protocollo. Questo aspetto porta con sè due vantaggi: in primo luogo un effettivo avvicinamento delle varie piattaforme, in secondo luogo una maggiore ricchezza semantica per la strutturazione e il confezionamento dell’informazione. Tuttavia le distanze sono ancora forti: un palmare Ipaq può contare su uno schermo di 320×240 pixel, un processore fino a 400Mhz e 65.000 colori, ma, come tutti i terminali Microsoft based (Smartphones compresi) non supporta CSS nè XHTML; un Sony Ericsson T68i ha uno schermo di soli 101×80 pixel, ma offre pieno supporto XHTML. I cellulari della famiglia 92xx Nokia addirittura ribaltano l’aspect ratio dello schermo, che in questo caso si sviluppa in larghezza anzichè in altezza, così come nei prototipi di frontalini per automobili web-enabled.

Come porsi allora di fronte a uno scenario così mutevole e complesso? La risposta più semplice, confortata dalla tecnologia disponibile, potrebbe essere questa: progettiamo un’interfaccia logica diversa per ognuno dei terminali (o insiemi di terminali) disponibili sul mercato, in modo da sfruttare le migliori caratteristiche di ciascuno di essi. Del resto l’identificazione lato server del terminale connesso è già possibile, così come è già possibile fornire un diverso template specifico per ciascun terminale. Le questioni legate al branding le consegnamo nelle mani dei web designer, e noi information architects abbiamo la coscienza a posto e andiamo a dormire tranquilli. Ma è veramente così? La realtà purtroppo ci dice che un approccio “a valle” del problema è tutt’altro che esaustivo, e la mancanza di una visione d’insieme del progetto informativo che sia realmente indipendente dal device di fruizione, alla lunga (nuovi terminali, nuove implementazioni software) può degenerare, costringendo a stancanti e costose revisioni di progetto fino al rischio di un sostanziale annullamento complessivo della continuità progettuale.

Alla ricerca di un filo conduttore

Facendo salvi i concetti tecnici di device detection e conseguente template ottimizzato per ciascun terminale (o tipologia di terminale) connesso, è proprio sull’aspetto progettuale “a monte” che è possibile intervenire in forme nuove, ad integrazione di uno schema tecnico di per se valido ma insufficiente a garantire l’organicità dell’informazione. Nonostante le differenze, è infatti possibile (e probabilmente necessario) tentare l’identificazione di un punto di equilibrio fra l’eterogeneità dei supporti e la coerenza/consistenza del progetto di comunicazione/informazione, mantenendo un radicale livello di astrazione sia rispetto all’architettura server sia ai singoli device. Si tratta di progettare un’interfaccia astratta dalla sua singola implementazione, una sorta di matrice di templates che sia basata su blocchi logici ricombinabili in modo dipendente da dimensione ed aspect ratio degli schermi, e dalle varie capabilities dei terminali in questione. Tali combinazioni daranno poi vita alle differenti incarnazioni dei templates, la cui similiarità sarà direttamente proporzionale alla buona impostazione del progetto di matrice. Naturalmente tale approccio deve giovarsi di soluzioni grafiche/visuali che esulano dallo specifico dell’information architecture, ma che debbono necessariamente essere sviluppate in modo organico a questa metodologia di base: sfruttare ad esempio il ridimensionamento “a runtime” senza perdita di qualità delle immagini jpeg, o l’utilizzo esteso di gif in cosiddetta pixel-art (senza antialias) per l’aspetto iconico.

Certo, la sfida è ardua e i tempi sono difficili, ma certamente in una fase storica in cui i mille mestieri nati dall’atomizzazione della figura generica di web designer sono alla ricerca di una solida definizione, è proprio nella esplosione dei contenuti al di fuori del browser che il mestiere di information architect può finalmente consacrare la propria indipendenza professionale.