Archivi tag: template

L’homepage del Guardian secondo chi l’ha fatta

Pubblicato il da

I weblog che seguo con più attenzione sono quelli che parlano di progetti e casi di studio reali, più che di teorie. Tra questi c’è il weblog di Nik Silver, che in qualche modo lavora al team di sviluppo dei siti del Guardian Unlimited.

In un intervento di Maggio Nik fornisce qualche elemento sulle strategie adottate nella progettazione dei template per la nuova homepage del Guardian.

Si parla di Velocity, di Css e di Domain Driven Design e la lettura è talmente interessante che a ogni rilettura emerge qualche nuova idea.

Non volevo però parlare di questo, ma di come sia sempre molto difficile trovare siti e weblog che trattino argomenti concreti. E’ molto più probabile avere a che fare con semplici esempi creati ad hoc il che, quando l’argomento è complesso, possono anche andare bene, ma che molto spesso forniscono un quadro troppo semplicistico.

A parte qualche intervento sul Guardian o sui siti della BBC e un manuale di qualche anno fa, Usability: The Site Speaks for Itself, non ho trovato molto altro, ma potrei aver cercato male.

In Italia, che mi risulti, non c’è proprio nessun tecnico o designer che si esponga a parlare dei propri progetti di un certo livello. Troppo fumo?

Guida di stile per il web: il design grafico

Pubblicato il da

Realizzare progetti web di una certa complessità – della durata di almeno un mese, e che siano seguiti da una fase di manutenzione dei contenuti più o menu lunga – richiede molto organizzazione, ma anche qualche standard.

Solitamente quando mi trovo coinvolto in questo tipo di progetti consiglio di stendere una serie di linee guida da seguire nello sviluppo del processo. Questa serie di linee guida le ho sempre chiamate guide di stile, anche se solitamente questo termine viene impiegato soprattutto per indicare le linee guida relative ai contenuti.

Sono principalmente due le fasi di un progetto web in cui è applicabile il concetto di guida di stile:

  • nella costruzione del layout della pagina e dei diversi elementi
  • nella organizzazione e stesura dei contenuti

Esploriamo qui il primo punto, lasciando il secondo a un successivo intervento.

Una guida di stile per la grafica di un sito dovrebbe essere un documento che si pone due obiettivi: servire come riferimento durante il processo di costruzione del layout delle pagine del sito, ma dovrebbe anche essere consegnato al cliente che si occupa di caricare in contenuti insieme alla guida di stile per i contenuti.

In questo modo chi si trova a dover realizzare nuove pagine nel corso della manutenzione del sito può, se gli è concessa questa possibilità, verificare se le nuove immagini, icone, foto, spalle, box che si appresta a costruire sono in linea con lo “spirito” del sito.

Ecco cosa dovrebbe contenere, sottoforma di testo e immagini, una guida di stile per il design grafico:

  • una rappresentazione dei diversi tipi di template del sito, motivando quando andrebbe usato uno e quando l’altro. Qui varebbe la pena sottolineare eventuali particolarità da prendere in considerazione quando la grafica verrà portata in Html e completata da codice lato server. Questo è utile perché chi si trova a lavorare con in template potrebbe sottovalutare l’impatto di lievi “personalizzazioni” alla grafica
  • l’elenco di tutte le icone usate nella grafica, con la spiegazione del loro utilizzo
  • qualche linea guida per la produzione di nuove immagini e loghi per i contenuti (dimensioni, posizione, in che formato salvarle, ecc.)
  • indicazioni sulla tipografica
  • indicazioni sui tipi di font e stile ai caratteri ammessi (sottolineato, colorato, ecc.)
  • suggerimenti sui diversi tipi di intestazione e link ammessi nel sito, con spiegazione, dovessero essere più d’uno, del loro impiego

Andrebbe quindi presentato un documento che contenga la grafica da usarsi all’interno del sito, arricchito però da qualche linea guida che permetta di capire da come partire da questa grafica per realizzare il codice.

Questo documento aiuta a non ritrovarsi nella frequente situazione per cui, dopo pochi mesi dalla messa online del sito, il designer grafico che l’ha creato vorrebbe non riconoscerne la paternità per colpa dei contenuti non in linea con quanto da lui progettato.

Ha senso imparare Ajax?

Pubblicato il da

Che in futuro la percentuale di applicazioni web di tipo Ajax (e Ria in generale) aumenti sempre più è un dato di fatto. Ma non è ancora chiaro chi, all’interno del team di sviluppo di un progetto web, debba imparare a masticare questa nuova architettura. Tutti? Solo chi si preoccupa della programmazione? Chi sviluppa i template? Il designer?

Chi progetta l’interfaccia

Uso qui impropriamente il termine “progettare l’interfaccia” intendendo in realtà molte specifiche professionalità, illustrate sapientemente da Jesse James Garrett nel diagramma “The Elements of User Experience“.

Chi rientra in questa categoria farebbe bene a capire come per l’utente cambia il modo di usare un sito che utilizzi Ajax. Perché le possibilità aumentano e l’interattività si avvicina a quella di un normale programma per computer. Per capire cosa intendo potete dare un’occhiata a quanto messo a disposizione da Yahoo!. Ma tutto questo pone anche dei problemi per quanto riguarda l’accessibilità e l’usabilità di Ajax.

Chi declina il template

La cosa più importante che deve fare chi si occupa del lavoro sporco, ovvero di convertire i template in codice Html e fogli di stile, è fare in modo che questi aderiscano il più possibile agli standard web. Non solo sulla carta, ma per davvero, come dico da due anni e passa.

Il fatto che Ajax impieghi massicciamente Javascript, realizzato solitamente da chi si occupa di produrre l’Html della pagina, potrebbe trarre in inganno. Si tratta infatti di un uso avanzato di Javascript, da lasciare a chi lavora lato server.

Chi scrive il codice lato server

Ecco, direte, quali sono i veri utilizzatori di Ajax, le persone che si infangano le mani tra codice Javascript e programmazione lato server…o no?

Certo, per capire come funziona Ajax suggerisco di creare da zero un piccolo esempio, ma è imprensabile sviluppare applicazioni complesse in questo modo.

Molto meglio votarsi a un framework che sollevi da questa responsabilità. Ma se possibile non un framework lato client, come ad esempio Prototype.

In futuro (neanche tanto lontano, basti pensare a quello che sta facendo, tra gli altri, Microsoft con Atlas), il supporto per Ajax sarà integrato direttamente all’interno dei framework di sviluppo lato server, tanto da renderne “invisibile” il funzionamento.

Attenzione però, perché trasparente fa rima con pericoloso. Dovrete prestare comunque attenzione a quello che fate; non dimenticatevi che siete sempre alle prese con un browser e – la maggior parte delle volte – con il protocollo Http.