La soluzione proposta consiste nel definire due o più gruppi di colonne assegnando varie classi (Es: essential, optional, etc..) quindi utilizzare delle media-query CSS per visualizzare e nascondere gruppi di colonne in base alle dimensioni del display.

Si tratta dunque di un esempio di design responsivo.

Trovando la soluzione molto interessante ho costruito un plugin jQuery che rende estremamente semplice realizzare sulle proprie pagine web quanto spiegato nell’articolo.

>>> Vai alla demo! <<<

MediaTable in Azione:

In questo primo screenshoot vediamo una tabella di cui sono visualizzate solamente le colonne veramente importanti. Siamo su di uno schermo di piccole dimensioni!

Cliccando sul menu “columns” (il cui nome è configurabile) si apre un menu contenente l’elenco completo delle colonne disponibili nella tabella. Possiamo variare a piacere il numero di colonne visualizzate mettendo in relazione informazioni differenti.

Questo menu è generato automaticamente! Il sorgente di questo esempio, come spiegato successivamente, è una semplice tabella dati HTML!

>>> Vai alla demo! <<<

Come si usa MediaTable?

MediaTable richiede la definizione di una tabella HTML definita correttamente ovvero con THEAD e TBODY. Le colonne di intestazione vanno raggruppate per classe in base alla priorità di visualizzazione.

Via CSS si imposteranno dei breakpoint su cui definire quali gruppi di colonne visualizzare.
Il plugin costruisce inoltre un menu delle colonne disponibili per consentire una selezione manuale esplicita delle colonne da visualizzare.

Il nostro esempio utilizza 3 gruppi di colonne:

• essential – visibili su qualunque schermo
• optional – visibili dai 768px (iPad portrait)
• n/a – visibili dai 1024px (iPad landscape)

Un’ulteriore classe “persist” è utilizzata per identificare colonne che non sono gestite dal menu. Impostando una colonna con le classi essential e persist essa non potrà mai essere nascosta!

<table class="mediaTable">
<thead>
<tr>
<th class="essential persist">Employee</th>
<th class="essential">xHTML</th>
<th class="optional">HTML5</th>
<th class="essential">CSS</th>
<th class="essential">JS</th>
<th class="optional">jQuery</th>
<th class="optional">jQueryUI</th>
<th>jQuery Mobile</th>
<th>Sencha Touch</th>
<th class="essential">PHP</th>
<th>PHP (OO)</th>
<th class="optional">CakePHP</th>
</tr>
</thead>
<tbody>
<tr>
<td>Marco Pegoraro</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
<td class="yes">y</td>
</tr>
<tr>
....
</tr>
</tbody>
</table>

Il codice javascript per l’inizializzazione del plugin è estremamente semplice:

0

$('.mediaTable').mediaTable();

Tutte le tabelle aventi classe “mediaTable” verranno attivate per consentire la selezione dei campi ed il comportamento responsivo rispetto alle dimensioni dello schermo.

>>> Vai alla demo! <<<

Compatibilità:

Ho testato il plugin sui seguenti sistemi:

• Mac OsX, Firefox 9.0.1
• Mac OsX, Firefox 4.0
• Mac OsX, Chrome 16
• Mac OsX, Safari 5.1.2
• Windows7, IE9
• Windows7, IE8, IE7, IE6 (with respond.js for media-query)
• Windows7, Firefox 7.0.9

Fork on GitHub:

Il plugin è di libera distribuzione!

Link al progetto pubblico su GitHub!

Segnala presso:

L’argomento:

Queste versioni di Internet Explorer non supportano le Media Query (nè HTML5… anzi, non supportano nulla!) ma fortunatamente esistono delle librerie che – via javascript – risolvono il problema.

• css3-mediaqueries-js - supporto esteso alle media query CSS3
• respond.js – supporto ottimizzato alle media query CSS3 per il “mobile first” responsive design

Io utilizzo respond.js perchè mi interessa solamente intercettare le dimensioni dello schermo ed agire di conseguenza sulla presentazione della pagina web ed è proprio su questa libreria che si concentra l’errore segnalato in questo post.

L’errore:

Questa libreria va in errore quando il foglio di stile contiene delle regole vuote:

body {}

La soluzione:

La semplicissima soluzione consiste nell’inserire almeno uno spazio all’interno delle parentesi graffe:

body { }

Conclusioni:

Molti di voi sostengono – a ragione – che questo tipo di istruzioni non dovrebbero esistere in un foglio di stile in quanto sono un semplice spreco di spazio e di tempo di caricamento. Sono pienamente d’accordo!

Tuttavia in piena fase di sviluppo molti sviluppatori usano scrivere il set completo di “css handler” per definire le regole interne in un secondo momento. In questo caso – in progettazione – questo bug può far perdere tempo prezioso e la soluzione proposta in questo articolo diventa utilissima!

Segnala presso:

Scarico, installo, avvio e… scopro con immensa delusione che l’applicazione non è altro che una lunga e pesante serie di immagini inserite in un carosello! Niente più di un pdf o di un eBook… semmai con notevoli funzioni in meno perchè non è possibile inserire segnalibri o condividere i contenuti!

Che valore aggiunto da questa App?

Le schede contenute nell’App sono delle semplici immagini: scansioni di una brochure o di un libretto!
Ovviamente i contenuti ci sono, ma sono di difficile lettura.

Le schermate accorpano una o più scansioni di pagine del catalogo cartaceo ed è necessario applicare lo zoom anche per leggere i titoli!
Sono sicuro che sull’iPad il problema è leggermente meno pesante grazie alle maggiori dimensioni dello schermo ma ciò non giustifica un prodotto simile!

Linee guida di pubblicazione sull’AppStore:

L’AppStore è l’ambiente di distribuzione delle applicazioni per iPod, iPhone e iPad.
Le applicazioni qui presenti dovrebbero essere soggette a stretti controlli di qualità tra i quali cito:

https://developer.apple.com/appstore/resources/approval/guidelines.html

L’applicazione Trentino Holiday 2011 è chiaramente frutto di una semplice scansione di una versione cartacea dei medesimi contenuti e come tale dovrebbe essere distribuita come eBook e non come App!

Quali accorgimenti adottare per migliorare il risultato?

Il passaggio da rivista cartacea ad applicazione (nativa/web/sito/eBook) deve inevitabilmente passare attraverso una fase di discussione e riorganizzazione dei contenuti.

Lo strumento “carta” consente di sfogliare mentre lo strumento “computer” consente di navigare.
Sono sistemi di accesso alle informazioni estremamente diversi ed è importante che l’utente riceva ciò che si aspetta di ottenere!

Utilizzo della rivista cartacea:

La rivista cartacea ha un accesso principale di tipo sequenziale: parto da pagina 1 e arrivo a pagina x. La maggior parte delle riviste mette a disposizione un indice per un accesso diretto alle informazioni. L’indice analitico dei contenuti è un metodo di accesso secondario nella rivista cartacea!

Utilizzo della rivista digitale:

Il computer ci ha abituati al “point and click” ovvero alla selezione di oggetti di interesse. Quando ci troviamo davanti al desktop siamo abituati a cliccare direttamente su di un’icona piuttosto che scorrere l’elenco delle icone disponibili fino a trovare l’opzione desiderata.
Nel computer l’accesso diretto ai contenuti è primario.

Dovrebbe quindi essere chiaro come gli articoli (anche le sezioni degli articoli) di una rivista dovrebbero essere riorganizzati in “schede”: piccoli nuclei di contenuto messi in relazione con altri nuclei tramite i collegamenti.

L’applicazione deve dunque mettere a disposizione un sistema di navigazione predeterminata per il raggiungimento di una determinata scheda.
Intendo la definizione di menu e sottomenu che permettano all’utente di operare una semplice ricerca tramite la selezione progressiva di opzioni semplici.

Il concetto di “opzione semplice” è vitale al successo dell’applicazione mobile (iPhone/iPad). Su questo tipo di dispositivi l’utente non vuole utilizzare la tastiera per effettuare una ricerca a parole chiave bensì utilizzare le dita per navigare attraverso un sistema di filtro progressivo il quale aiuta ad identificare un numero sempre più circoscritto di “schede” tra cui scegliere la propria lettura.

Contenuti Aumentati:

Un’altro accorgimento utile nella realizzazione di un’App per riviste o cataloghi è l’inserimento di azioni utente sulle schede di contenuti.

L’ida di base è che l’utente non si limita a leggere i contenuti sull’iPhone ma li vuole condividere, segnalare, commentare, esportare etc.

Operazioni quali “invia ad un amico”, “condividi su facebook”, “aggiungi a preferiti” o simili diventano armi importanti per coinvolgere l’utente nell’utilizzo dell’App ed ottenerne così il consenso.

Ovviamente questo richiede l’esistenza di una struttura web (un sito) parallelo nel quale pubblicare parte dei contenuti delle schede fornendo così i link che possono essere condivisi tra i vari social network.

Conclusioni

Lo strumento mobile App è sicuramente potente ed allettante per moltissime realtà editoriali ma bisogna fare molta attenzione a non cadere nel banale pubblicando soluzioni frettolose ed abbozzate come l’App oggetto di questo articolo.

Segnala presso:

L’utente medio cerca informazioni complete e aggiornate in una grafica accattivante.
Il nostro scopo (di web designer) è soddisfare questi bisogni e renderci conto che essi evolvono nel tempo e questa evoluzione è determinata da tecnologia e moda.

In questo articolo spiego come le tecniche di Web Design Progressivo e Web Design Adattivo possono essere utilizzate come compromesso vincente per la realizzazione di progetti web attuali e retro compatibili.

HTML4, xHTML Transitional, xHTML Strict, HTML5, CSS2, CSS3, Javascript, jQuery (e altri frameworks) sono le infrastrutture che abbiamo a disposizione per realizzare una pagina web. Come capita in moltissimi ambiti lavorativi dobbiamo avere le competenze necessarie per scegliere lo strumento giusto per il lavoro da realizzare.

Un esempio pratico di questa affermazione è HTML5: è una novità sulla bocca di tutti ed introduce nuove ed interessanti funzionalità alle pagine web (io utilizzo già HTML5 per molti miei lavori!).
Eppure se dobbiamo realizzare un progetto web per una Pubblica Amministrazione italiana non possiamo farne uso! Siamo obbligati dalla Legge Stanca ad utilizzare xHTML.

Vecchie abitudini dure a morire!

In principio era Explorer (e Netscape!) e poi pian piano abbiamo assistito (noi utenti del Web) alla nascita degli altri browsers. Da sempre agenzie e clienti chiedono (pretendono) che le loro pagine web si vedano identiche su qualunque computer, browser e OS.

Questo fenomeno deriva dal fatto che l’utente medio ha assistito alla nascita del web ed il web è stato venduto per anni come il volantino digitale dell’azienda: una semplice digitalizzazione di una brochure.

La caratteristica principale del volantino è che tutte le copie sono identiche tra loro e questa abitudine è stata erroneamente trasferita al web. Questa abitudine è dura a morire!

La (pessima) soluzione grafica

In principio era FrontPage e Dreamweaver e poi pian piano abbiamo assistito  (noi sviluppatori) alla crescita di una coscienza collettiva orientata alla qualità del codice ed alla sua semantica con lo scopo di valorizzare un contenuto di qualità.

Gli strumenti visuali (WYSIWYG) utilizzavano (e lo fanno tutt’ora!!!) tabelle e slices per comporre il risultato grafico di una pagina.
Quasi tutta la grafica risultante è basata su di un mosaico di immagini composte in una una struttura a tabelle annidiate.

Questa soluzione permette di ottenere un elevato grado di “uguaglianza” tra i vari supporti ma è legata a tecnologie vecchie e deprecate (le tabelle di layout) ed è destinata a morire perchè colossi dell’informazione come Google basano i risultati delle proprie ricerche anche sulla qualità intrinseca delle pagine indicizzate: la qualità del codice sorgente!

Moda e Tecnologia

Il web è fatto di contenuti impaginati ed erogati principalmente attraverso lo schermo di un computer o di un dispositivo mobile. In sintesi una pagina web può essere sia letta sia osservata come immagine.

L’immagine di una pagina web può essere percepita come bella o brutta in base al background culturale del singolo individuo ma anche in base alla moda del momento. Anzi, sempre più spesso sono le mode collettive ad influenzare il singolo background culturale anche nella fruizione di una semplice pagina web.

Le tecnologie messe a disposizione di noi sviluppatori web evolvono assieme alla moda e spesso rispondono ad esigenze stilistiche con maggior priorità rispetto alle esigenze funzionali. Un esempio eclatante è la direttiva border-radius introdotta con i CSS3.

Quasi sempre l’ultima tecnologia disponibile nasce per semplificare un certo compito (si pensi sempre ai bordi arrotondati) mentre quasi mai gli strumenti esistenti si adeguano alle nuove tecnologie (si pensi a Internet Explorer).

Il risultato è che lo sviluppatore si trova a dover scegliere tra:

• utilizzare l’ultima tecnologia disponibile a rinunciando alla compatibilità con sistemi obsoleti
• rinunciare all’aggiornamento tecnologico per favorire una compatibilità globale del proprio lavoro
• studiare soluzioni complesse per rendere retro-compatibili alcune (ma non tutte) le nuove tecnologie (si pensi a sIFR o Cufon)

Il Compromesso Vincente

Esiste tuttavia un approccio pragmatico che tiene in massima considerazione il contenuto che una pagina deve erogare (su questo non c’è compromesso!) e tenta di studiare soluzioni grafiche che possano sfruttare al massimo le nuove tecnologie ma risultare comunque accettabili in assenza delle stesse.

Questo compromesso prende il nome di “Design Progressivo” e “Design Adattivo” (in inglese “progressive enhancement web design” e “adaptive web design”).

Utilizzo il termine compromesso perchè entrambe queste tecniche di desing hanno risultati grafici differenti su browsers o supporti differenti.

Utilizzare queste tecniche significa comprendere che il web è uno strumento elastico e contestualizzato allo strumento che lo visualizza. Significa comprendere che il web non è la carta stampata!

Colori, layouts, effetti grafici e movimenti possono essere un’utile arricchimento della pagina quanto viene visualizzata su di un iMac 27″ e contemporaneamente risultare un pesante impedimento per chi tenta di accedere alla stessa pagina con un cellulare.

Web Design Progressivo

Il termine Design Progressivo identifica delle tecniche di sviluppo per cui un layout tecnologicamente semplice viene arricchito di funzionalità extra solo per i browsers che le supportano.

Il design di partenza si basa su tecnologie solide e ampiamente diffuse assicurando che un determinato layout è correttamente visualizzato sulla (quasi) totalità dei browsers/dispositivi in circolazione. Successivamente si applicano gruppi di regole avanzate le quali vengono lette solamente dai browsers che le supportano. Tali regole verranno ignorate da vecchi dinosauri quali IE6, IE7, IE8!

In passato si utilizzavano i commenti condizionali per IE, successivamente hanno preso il sopravvento i CSS Hacks (safe e non) mentre oggi possiamo contare su strumenti evoluti quali modernizr che ci permettono di scrivere fogli di stile simili a questo:

<style type="text/css">
/* Basic Layout Rules */
.box { margin:10px; padding:10px; background: #ddd; color: black; }

/* Advanced CSS3 Rules */
.boxshadow .box { box-shadow: 2px 2px 4px #666; }
</style>

Leggi l’approfondimento su Wikipedia (inglese) »

Web Design Adattivo

Il termine Design Adattivo identifica delle tecniche di sviluppo per cui un layout subisce delle trasformazioni in base alle caratteristiche del dispositivo che lo visualizza.

Questa pratica si basa sul concetto che chi visualizza una data pagina con un cellulare o un iPhone non ha interesse nel visualizzare una enorme, seppur magnifica, testata grafica del sito.

Il Web Design Adattivo è una materia molto complessa perchè ha a che fare con molti livelli di erogazione di una pagina web.

A livello CSS possiamo decidere di caricare o meno la testata del sito grazie ad una media query oppure possiamo utilizzare un set di icone ad alta risoluzione per lo schermo di un iPhone4.

A livello Javascript possiamo valutare di inserire i tasti avanti/indietro in uno slide-show per chi utilizza il mouse mentre per chi utilizza un iPad (touch screen) possiamo prevedere un comportamento a trascinamento (qui ci aiuta modernizr).

A livello Server possiamo valutare di ridimensionare le immagini a 800px per chi ha una connessione veloce e ridurle a 300px per chi ha una connessione lenta o un cellulare basandoci sugli header della richiesta e su dei pingback ajax (qui si va sul difficile).

L’ultima Sfida!

Considero abbastanza semplice da comprendere quanto esposto in questo articolo: la grafica su web ha caratteristiche diverse dalla grafica su carta.

Nel lavoro quotidiano mi trovo spesso a discutere di questi argomenti con colleghi designers e grafici e molto spesso mi accorgo che quando un creativo si mette davanti a Photoshop raramente tiene in considerazione le problematiche di implementazione e lo strumento (il web) cui è destinato il suo lavoro.

Per fortuna l’impatto che il SEO ha su di un progetto web è sempre più forte e Google sta facendo enormi sforzi per premiare la qualità costruttiva di una pagina web.

Sono sicuro che in un futuro abbastanza vicino le considerazioni qui esposte diverranno argomento comune tra tutti i miei colleghi!
E tu cosa ne pensi?

Segnala presso:

Un software (Photoshop, Fireworks) si occupa di convertire il tutto in una pagina html piena di tabelle annidiate le quali contengono pezzi di immagini (le slices), testi e celle vuote con immagini di sfondo elastiche (vi ricordate le “transparent.gif”?).

La modifica ai contenuti di questo tipo di pagine è realizzabile solamente attraverso il software WYSIWYG perchè il codice risulta quasi completamente illeggibile. Oltretutto capita molto spesso che la quantità di codice superi abbondantemente la quantità di contenuto e questo è un grosso danno per il ranking del sito web!

Vantaggi:

Il vantaggio di questa soluzione è insito nello sfruttamento massivo delle immagini: tutto ciò che è immagine rimane sicuramente uguale su qualsiasi browser o dispositivo. Al massimo può cambiare la dimensione!

Svantaggi:

• dimensioni: la pagina è molto pesante, ha difficoltà di caricamento su connessioni lente ed un pessimo impatto sulla banda hosting consumata e sul ranking nei motori di ricerca
• manutenzione: le richieste di modifica sono difficili e molto costose da applicare sia per quanto riguarda i contenuti e, peggio ancora, per quanto riguarda la struttura
• standard: questa tecnica è quanto di più distante ci sia dal concetto di pagina web semantica attorno cui ruotano tutti gli standard web attuali nonchè le direttive di usabilità ed accessibilità

Alternative:

L’alternativa più valida e sicura è la realizzazione di pagine web scrivendo il codice sorgente (e magari comprendendo ciò che si sta facendo!).
Solamente in questo modo il Web Master può evolvere ed avvicinarsi alla figura del Web Engineer.

Ho citato questi due termini “lavorativi” di proposito perchè non esiste organismo al mondo che possa darne una definizione reale ed assoluta dunque voglio esprimere anche la mia opinione:

Web Master: è una figura professionale risalente agli ultimi anni del secolo scorso. Dispone delle competenze tecniche sufficienti a pubblicare contenuti on-line.

Web Engineer: è una figura professionale sviluppatasi dal 2007 in poi. Dispone delle competenze del Web Master ma comprende le implicazioni semantiche durante la definizione di una pagina web.

Inoltre conosce e comprende il processo di costruzione di un’interfaccia grafica funzionale alla comunicazione, ha nozioni di SEO e SEM ed è in grado di predisporre semplici campagne di visibilità o di coordinare un team di specialisti esterno, ha nozioni di problem solving e di analisi.

Il Web Engineer ha la capacità di formulare una stima di lavoro su tempi e risorse necessarie alla risoluzione di una richiesta/problema. E’ capace di coordinare un gruppo di lavoro e formulare dei report verso il cliente. In linea di massima il Web Engineer ha una presenza professionale e deve essere percepito dal cliente come persona competente e su cui far affidamento: l’impressione personale del cliente è fondamentale!!!

Il Web Engineer ha una naturale tendenza all’aggiornamento e innovazione, legge articoli da diverse fonti on-line, frequenta community di colleghi e scrive egli stesso articoli su blog personali e non.

NOTA PERSONALE: nel momento in cui scrivo queste cose mi definisco un Web Developer che sta lavorando duro per diventare a tutti gli effetti Web Engineer!

Segnala presso:

Visualizzazione Errata:

ie8 rendering errato di fieldset con legend nascosto

Visualizzazione Corretta (work-around applicato):

IE8 visualizzazione di un fieldset con legend nascosto (workaround applicato)

Markup Originale:

xHTML:
-----------------
<fieldset>
    <legend>Legenda</legend>
    ....
</fieldset>
CSS:
-----------------
fieldset { border:6px solid #ddd; }
fieldset legend { display:none; }

Spiegazione Workaround:

La soluzione più semplice e cross-browser è inserire uno SPAN all’interno del tag LEGEND e quindi applicare la visibilità nulla a questo elemento:

xHTML:
-----------------
<fieldset>
    <legend><span>Legenda</span></legend>
    ....
</fieldset>
CSS:
-----------------
fieldset { border:6px solid #ddd; }
fieldset legend span { display:none; }

Segnala presso:

Le dimensioni della finestra sono dunque definite dall’utente finale che può fare un po’ quello che vuole: tutto schermo, finestrelle minuscole, ecc…

Solitamente la diatriba riguardante la scelta di implementare o meno un layout fluido si concentra sulla maggiore complessità di realizzazione, sulla libertà di design ed in generale sull’impatto a livello di costi.

Vorrei a questo punto spostare l’attenzione dal puro aspetto grafico e stilistico ai contenuti, protagonisti della nostra pagina web!

Righe di testo troppo lunghe!

Una grafica liquida abbinata ad uno degli ormai comuni schermi da 20″ ad altissima risoluzione può facilmente produrre delle righe di testo estremamente lunghe e di difficile lettura: Sullo schermo non possiamo farci aiutare dal dito indice!!!

Nella mia esperienza di web designer ho imparato che la lunghezza della riga influisce molto sull’usabilità dei contenuti della pagina.

Un’importante eccezione:

Spezzo comunque una lancia a favore dei layout fluidi: essi permettono l’ingrandimento del testo più o meno a piacere aiutando dunque chi, come me, sta lasciando 4 diottrie su ogni progetto!

In un layout a dimensione fissa l’ingrandimento del testo può facilmente provocare sovrapposizione di paragrafi e blocchi grafici con il pessimo risultato di rendere illeggibile la pagina stessa.

Segnala presso: