Web Design

Troppo presto per abbandonare IE6

Tempo di abbandonare il supporto a Internet Explorer 6 nella realizzazione di nuovi siti? La provocatoria proposta viene in uno degli ultimi post del nuovo Web Designer Wall, dallo stesso autore di N.Design Studio.

L’idea è che gli utenti che utilizzano IE6, quando inizieranno a visualizzare male i siti web, decideranno di cambiare e di liberarsi dal browser più odiato dai web designer. Ragionamento lineare, ma errato, perchè le cose non sono così semplici.

Parlando di numeri, secondo The Counter, gli utenti ad Agosto 2007 che utilizzano ancora IE6 sono ben il 50%. Cifra considerevole, che ci mostra come questo sia ancora il browser più utilizzato, nonostante l’uscita di Explorer 7 e la crescita di Firefox.

Cosa fare poi quando è il cliente ad utilizzare Explorer 6? Non è plausibile presentarsi suggerendogli di cambiare browser: dovrebbe essere sempre il web designer ad adattarsi alle esigenze altrui, non viceversa.

In sostanza abbandonando il supporto ad IE6 si rischiano numerosi problemi con tutti quegli utenti che non vogliono (o non sanno) aggiornarsi, i quali non esiteranno a dare la colpa a chi ha realizzato il sito.

E’ quindi troppo presto per abbandonare il supporto ad Explorer 6, ma una soluzione intelligente c’è. E’ possibile fornire a tutti i browser più moderni dei dettagli in più, soprattutto con l’uso di selettori dei CSS3, o dettagli grafici come l’ombra dei testi su Safari tramite la proprietà text-shadow. Con dei vantaggi visibili sarà più facile decretare una morte rapida per il browser di casa Microsoft.

So che molti vorrebbero poter agire diversamente, ma questo è sicuramente uno dei compromessi migliori. Se avete esperienze personali sull’utilizzo di Explorer 6 da parte di clienti, conoscenti, o se lo usate voi stessi e volete difenderlo, dite la vostra nei commenti.

Le novità sui conti di Italia.it

Italia.it logoLa vicenda del portale italia.it è stata ampiamente illustrata su questo sito e su numerosi altri blog della rete, ma da qualche tempo era caduta dietro un inevitabile silenzio, soprattutto per mancanza di novità a riguardo. C’è da dire che anche il governo ha fatto il possibile per evitare il dialogo, ma è di pochi giorni fa un nuovo aggiornamento sulla situazione.

E’ sempre scandaloitaliano a farsi avanti, stavolta facendo luce sull’aspetto economico di italia.it, con risposte ufficiali da parte di Lelio Alfonso, responsabile della comunicazione istituzionale del governo.

Quali sono le novità?

Gli stanziamenti globali per l’intero progetto ammontano a 58,1 milioni di euro, di cui 35,9 impegnati ad oggi. Restano 22,2 milioni di euro che devono essere ancora spesi. La vicenda quindi non finisce, anzi ci saranno altri sprechi, con cifre che nessun progetto di qualsiasi dimensione potrebbe giustificare.

Ma non è tutto, perchè dai conti emergono altre spese ad oggi sconosciute per 2 milioni di euro, per la promozione del portale.

Un’altra cifra poi ha attirato la mia attenzione: 1,237 milioni di euro per “spese appalto, studio di fattibilità ed altre incombenze preliminari”. Come riuscite a giustificare un milione speso per uno studio di fattibilità preliminare? Con una cifra del genere si potrebbe realizzare qualsiasi cosa, ma qui no.

Insomma lo scandalo continua, onore a scandaloitaliano che continua a fare luce sulla vicenda.

Vi rimando al post per i dettagli e per una descrizione accurata dei retroscena.

Risoluzione minima: addio 800×600?

In fase di realizzazione di un sito web, uno dei primi aspetti da considerare per quanto riguarda l’interfaccia è la risoluzione minima da supportare.

E’ ovviamente possibile creare un sito a larghezza fluida come TomStardust.com, ma si dovrà comunque decidere fino a che punto poter ridimensionare il layout. Se fino a qualche tempo fa era ancora logico supportare la risoluzione 800×600, dopo una valutazione del panorama italiano ed internazionale sento di poter dire che ormai il limite è stato superato. Le percentuali di visitatori con una tale risoluzione sono sempre meno, mentre aumentano gli schermi widescreen.

Se poi consideriamo alcuni tra i siti più popolari vediamo come il recente redesign di Punto Informatico sia per una larghezza minima di 1024 pixel, e anche in ambito non tecnologico ci si sia spinti su standard analoghi: il sito di Repubblica è da tempo creato su misura per i monitor a 1024×768, e anche una piattaforma di blogging come Splinder ha ridisegnato la propria homepage per la stessa risoluzione.

Il mio consiglio resta quello di realizzare layout fluidi che possano adattarsi allo schermo del visitatore, ma non sentitevi troppo in colpa se il vostro sito mostra delle barre di scorrimento ad 800×600. Certo, ci saranno ancora utenti con vecchi pc (su questo sito sono circa il 2% dei visitatori totali), ma a mio parere è ormai sufficiente garantire la leggibilità dei contenuti e la possibilità di navigare tra le pagine. Cosa ne pensate? Se conoscete siti che vanno contro questa tendenza citateli senza problemi.

HTML5 ed il futuro di internet

Dopo aver parlato di standard web e della contrapposizione tra W3C e WCAG Samurai, è indispensabile fare chiarezza anche sul futuro dell’HTML.

Da tempo è avviata una discussione sulla specifica migliore per internet, e la strada sembra dividersi su due possibilità: HTML5 e XHTML2.

Da un determinato punto di vista sembrerebbe più logico passare da XHTML 1.0 alla specifica 2.0, non è però detto che le cose seguano questa direzione, anzi. I produttori di browser sembrano preferire una nuova versione dell’HTML, e molte discussioni degli ultimi mesi indicano la stessa strada, tanto che il W3C è tornato sui suoi passi.

Per capire qualcosa di più sulla questione, consiglio a tutti gli interessati la lettura di un ottimo articolo di Maurizio Boscarol, commenti compresi. E’ una serie di domande e risposte che permette di comprendere meglio lo scenario futuro del web. Il post è stato creato a Maggio, ma viene aggiornato ogni tanto con nuovi elementi.

Stiamo parlando dello sviluppo di un linguaggio che occuperà molti dei prossimi anni, ma è fondamentale che si individui fin da ora la direzione giusta per non cadere in inutili perdite di tempo.

Se volete inoltrarvi nella disputa tra HTML5 e XHTML2, vi segnalo anche un articolo di HTML.it, traduzione di un ormai famoso intervento di David Andersson su Digital Web Magazine.

L’accessibilità tra W3C e WCAG Samurai

Più di un anno fa, Joe Clark aveva attaccato il W3C e le sue linee guida sull’accessibilità in un articolo ormai famoso di A List Apart. Era evidente che la situazione avrebbe portato a qualche clamorosa conseguenza, ed infatti di lì a poco sorse WCAG Samurai, un’iniziativa indipendente che si proponeva di scrivere delle proprie linee guida.

Dopo un lungo periodo di attesa, sono da poco state pubblicate le WCAG Samurai Errata, segnalate da Roger Johansson: delle indicazioni che vanno ad integrare e correggere le WCAG 1.0, pur usandole come base.

Si compongono di due parti: un’introduzione che spiega come interpretare il documento, e le linee guida vere e proprie. La differenza principale è la sinteticità: non c’è spazio per equivoci. Ecco alcuni punti principali:

  • Le tabelle per il layout sono proibite
  • I frames sono proibiti
  • Il codice delle pagine deve essere valido
  • Il codice delle pagine deve essere semanticamente valido
  • Gli attributi accesskey e tabindex sono proibiti

Davanti ad uno scenario del genere, cosa aspettarsi? E’ interessante vedere un sempre maggiore fermento verso le tematiche legate all’accessibilità della rete, ma ci sono anche dei rischi.

Se il movimento finisse per frammentarsi in una serie di indicazioni differenti tra loro, secondo voi cosa succederebbe? Probabilmente i produttori di browser si sentirebbero ancora più autorizzati a decidere autonomamente, cosa che la Microsoft ha cercato di fare per anni imponendo le proprie scelte come standard, grazie alle sue quote di mercato.

La speranza è che tra W3C e WCAG Samurai si riesca a definire uno standard unico, evitando di restare imbrigliati in burocrazie eccessive. Staremo a vedere cosa ci riserverà il futuro.

Il sito CSS Showcase tutto italiano: CSSGlance

CSSGlance LogoSu internet i siti realizzati con i CSS sono in costante aumento, ed a testimoniarlo sono le gallerie showcase che raccolgono i migliori lavori. Ne esistono molte, alcune più autorevoli di altre, ed una è nata da poco tempo: CSSGlance.

Ne parlo per un valido motivo: è un lavoro tutto italiano con alcuni spunti interessanti per emergere dalla massa.
I siti segnalati vengono classificati in base a diversi parametri:

  • media dei voti, visto che ogni entry può essere giudicata dai visitatori
  • piattaforma CMS, con una netta predominanza di WordPress sulle altre
  • colore principale
  • tipologia di contenuto, dai blog alle web agency
  • tipo di layout: fisso, liquido o elastico
  • menu di navigazione orizzontale o verticale
  • numero di colonne
  • rispetto degli standard
  • utility varie, come la presenza di una photogallery

Quello che mi ha colpito è la presenza di una sezione dedicata ad articoli sul web design, cosa che non è presente nella maggior parte degli showcase, che si accontentano esclusivamente di mostrare siti.

Penso che insistendo in questa direzione, cercando di innovare con funzionalità originali, CSSGlance possa ritagliarsi un buono spazio nel panorama delle gallerie CSS. C’è ancora del lavoro da fare, ma le premesse sono interessanti.

Cosa ne pensate? Se avete idee e suggerimenti i creatori di CSSGlance potrebbero benissimo considerarli, dite la vostra!

Estensioni Firefox: la Top 10 per il Web Design

Firefox si è rivelato uno dei migliori browser per lo sviluppo sul web, uno strumento indispensabile per ogni Web Designer al di là della sua diffusione presso i non professionisti.

In questo articolo voglio elencare le 10 estensioni di Firefox a cui non potrei mai rinunciare, che mi aiutano nel lavoro di tutti i giorni e che spero possano risultare utili a chi ancora non le conosce.

1. Web Developer

Aggiunge una toolbar con numerosi strumenti e funzionalità, dalla possibilità di disabilitare i CSS alla validazione della pagina corrente.

2. Firebug

Permette di fare il debug e modificare il contenuto di una pagina con pochi clic, monitorando CSS, HTML e Javascript in tempo reale. La considero un’estensione complementare a Web Developer, piuttosto che sostitutiva.

3. CSS Mate

Estensione fondamentale per fare test al volo sui CSS di una pagina, avendo un feedback immediato.

4. IE Tab

Per testare un sito è comodo avere degli strumenti che facilitino lo switch tra i vari browser. Questa estensione permette di visualizzare una pagina con il rendering engine di Internet Explorer dentro una tab di Firefox.

5. IE View Lite

Variante di IE Tab (vedi sopra), consente di aprire la pagina corrente in una finestra di Explorer tramite una voce nel menu contestuale.

6. OperaView

Estensione dal funzionamento analogo ad IE View, utile per aprire una pagina sul browser Opera.

7. HTML Validator

Aggiunge all’interno della finestra per la visualizzazione del codice alcune indicazioni utili sulla validazione della pagina. Segnala errori e warnings, con utili suggerimenti per correggerli.

8. MeasureIt

Semplice ma utilissimo tool che crea un righello con il quale misurare gli elementi di una pagina.

9. Screengrab!

Per catturare screenshot di una pagina salvando solo la porzione visibile o tutto il contenuto. Questa estensione è stata migliorata ed il salvataggio dei file immagine ora è molto più veloce.

10. SEO for Firefox

Aggiunge informazioni utili ai risultati della ricerca di Google: PageRank, età del dominio, numero di links, rank su Technorati ed Alexa e molto altro.

Trovate queste estensioni di Firefox anche nella pagina utility di TomStardust.com, insieme ad altre risorse. Se avete consigli sull’argomento o se pensate che nell’elenco manchi qualcosa di importante non esitate a dirlo nei commenti!

Quando AJAX non serve

Design Snack con Javascript disabilitatoIl mese scorso un sito a cui sono registrato ha subito un deciso restyling: si tratta di Design Snack.

E’ una community dove ognuno può segnalare un sito e farlo votare dagli altri utenti; più voti ottiene, più in alto sale in classifica, passando da semplice segnalazione a risorsa approvata ed infine “awarded”.

Appena ho visto l’homepage ho notato subito l’aggiunta di AJAX nella colonna destra, che permette di navigare tra le categorie. La funzione è comoda, peccato che con Javascript disabilitato ci si trovi davanti ad una pagina parzialmente vuota (vedi screenshot).

Qualcuno potrebbe pensare che sia impossibile trovare una soluzione accessibile ottenendo gli stessi risultati, ed invece non è così.

Un altro famoso sito risolve tutto con un semplice Javascript: Hicksdesign. Cliccando sui vari “recent works” è possibile cambiare al volo il contenuto visualizzato nella pagina, ma il bello è che tutto rimane accessibile. Se infatti provate a disabilitare Javascript, magari aiutandovi con la Web Developer Toolbar (per Firefox), vedrete comunque tutti i contenuti, raggiungibili tramite delle ancore.

Il web è ricco di esempi del genere. Non è detto che si debba per forza di cose utilizzare sempre l’ultima tecnologia disponibile: AJAX sicuramente ha grandi potenzialità, ma è sempre necessario prestare attenzione a tutte le conseguenze di una sua applicazione.

Se si possiede un’alternativa valida, accessibile e con meno problemi, è quella che va utilizzata!

Gallerie di immagini, adesso c’è anche Smoothbox

Una schermata di esempio con SmoothboxHo parlato più volte di Mootools e delle possibilità che offre soprattutto dopo l’uscita della versione 1.0. Mi sono accorto che si sta diffondendo sempre più, ed è recente una conversione di Thickbox proprio per questa libreria, con il nome Smoothbox.

Thickbox è un Javascript che consente la creazione di gallerie di immagini ed anteprime, ne avevo parlato in questo articolo. Utilizza jQuery, ma avere più possibilità a seconda del framework che si decide di usare sul proprio sito non è un male, anzi. Infatti metterne insieme più di uno non è raccomandabile per possibili problemi di compatibilità, ma soprattutto per il peso delle pagine.

Adesso quindi se volete usare un effetto per l’ingrandimento delle immagini o per creare delle gallerie, le scelte sono molteplici:

Scegliete la soluzione che preferite e che più si adatta alle vostre esigenze, la raccomandazione è di appoggiarsi sempre su una libreria Javascript ridotta all’essenziale per evitare caricamenti inutili ai visitatori.

Se avete altri script simili da segnalare non esitate a farmelo sapere tramite i commenti o il modulo contatti, le risorse sull’argomento sono infinite!

Aggiornamento: sono arrivate le prime segnalazioni interessanti, le integro nell’articolo soprattutto per facilitarne la lettura.

  • Simone raccomanda TripTracker, che consente la creazione di uno slideshow senza troppe difficoltà. Il Javascript pesa circa 30kb e per siti commerciali richiede l’acquisto di una licenza, ma per un sito personale è ottimo.
  • LeoB segnala lo script Slimbox, che è una conversione di Lightbox v2 sempre per la libreria Mootools in soli 7kb. Da provare!

Aggiornamento #2:

  • Ancora LeoB segnala Smoothgallery e Slideshow, due soluzioni alternative per gallerie di immagini con Mootools.
  • Pirolab invece segnala Clearbox, risorsa interessante anche se in ungherese.

Il codice valido non basta

Spesso chi realizza un sito ed inizia a prestare attenzione agli standard del W3C commette un errore comprensibile ma difficilmente giustificabile: cerca esclusivamente di validare il codice di una pagina. Questo è importante, ma non deve essere l’unica preoccupazione, e forse nemmeno la principale.

Mi è capitato di conoscere persone che una volta raggiunto l’obiettivo di realizzare una pagina valida XHTML 1.1 Strict si ritenevano soddisfatte. E’ un ottimo esercizio, questo nessuno può negarlo, ma va inteso come tale e non bisogna limitarsi solo a quello. L’accessibilità di un sito va ben oltre i controlli automatici.

Parlando anche di CMS, ce ne sono alcuni che generano codice valido e vengono fatti passare per accessibili, ma quando poi si va ad analizzare l’HTML ci si trova davanti una doctype magari di tipo 4.01 Transitional, con layout a tabelle.

Creare un sito e preoccuparsi esclusivamente della validazione automatica del codice rischia quindi di diventare controproducente, se poi i risultati sono simili a quelli citati sopra.

Nella maggior parte dei casi è molto più importante avere markup semantico, layout ben organizzato, oltre a nessun CSS e Javascript inline, separando sempre i contenuti dalla presentazione. Un sito accessibile è il risultato di un insieme di procedure e controlli, impossibile limitare il tutto ad una semplice validazione automatica.