Crea sito

Insel der Engel'

Il mio piccolo pezzo di Paradiso

 
Tag: Webmastering

Best of Week (+/-) #5

E finalmente anche questa sessione di esami è finita. Spero ora di riuscire a scrivere un po’ di più sul blog, ma da una rapida occhiata alla mia “agenda”mi sa che è solo una mia illusione. 🙁

Kabu - I 10 Comandamenti #3

Kabu - I 10 Comandamenti #3

Ecco la playlist della settimana:

Alla prossima. Enjoy 😉

Gli usi più creativi di jQuery ?

Oggi spezzo un po’ la monotonia di questo blog per tornare a parlare (era ora!) un po’ di web mastering e web design.

L’occasione mi si è presentata nel mentre selezionavo le risorse da inserire nel prossimo Best of Week e mi sono imbattuto in un articolo, apparso sul celebre portale NetTuts, a prima vista davvero interessante per chiunque si stia cimentando con jQuery e sviluppo web in generale: The 20 Most Practical and Creative Uses of jQuery.

Già il solo titolo, unito alla testata che lo ha pubblicato, dovrebbe essere una garanzia più che sufficiente non solo di utilità pratica ma anche di elevata qualità. Eppure, un po’ per scrupolo, un po’ perchè anche a me la cosa interessava parecchio, ho deciso di andare oltre la semplice lettura e tastare con mano tutti gli esempi riportati. E posso anticiparvi sin da ora che quell’articolo non finirà nella mia rubrica.

Mentre ad una prima lettura sembrerebbe infatti che le implementazioni effettuate dai vari autori siano la cosa più straordinaria del mondo, il discorso cambia decisamente quando si vanno ad aprire i vari esempi.

Non voglio qui puntare il dito contro questo o quello script/sviluppatore, pertanto cercherò di limitarmi ad una anlisi globale sugli aspetti più deludenti riscontrati.

Innanzitutto mi ha lasciato davvero molto perplesso notare come il fattore accessibilità sia stato totalmente ignorato non soltanto da alcuni sviluppatori, ma anche dall’autore dell’articolo.

Personalmente parto infatti da un presupposto imprescindibile secondo cui, se la resa finale non può essere cross-browser o cross-platform, bisognerebbe almeno garantire la piena fruizione dei contenuti anche sui browser non compatibili o con javascript disabilitato. Aspetto che invece non sembra essere stato preso in considerazione da alcuni sviluppatori (pochi per fortuna).

Restando sempre in tema accessibilità mi è parso poi davvero ridicolo riscontrare fra i siti in lista un Portfolio (o landing page) che supera addirittura i 5 MB (senza contare le infinite richieste http) per la sola (e strimizita) home page! Francamente, dopo aver atteso il caricamento di un mostro del genere, mi sarei quantomeno aspettato che non ci sarebbero più stati tempi di attesa nel passare da una sezione all’altra… Ovviamente mi sbagliavo ed anche tecniche base come il semplice preload o gli sprites vanno evidentemente al di là dell’immaginario comune.

Certo che se fosse finito tutto qui mi sarei comunque potuto ritenere fortunato. Ed invece è proprio la domanda che segue che mi ha portato a scrivere questo post:

Ma era davvero necessario ricorrere a jQuery (e JavaScript in generale) per ottenere quegli effetti?

Incredibile ma vero la risposta, in molti casi, è no. 😮

Per replicare alcuni degli effetti presentati sarebbe infatti bastato l’uso dei ben più semplici e compatibili CSS, eventualmente combinati con qualche sano hack.

Ora, ben vengano sperimentazioni e dimostrazioni pratiche delle proprie abilià o delle possibilità di un framework JS, ma nel momento in cui queste abbandonano lo status di esempio per approdare nel mondo reale credo bisognerebbe essere un po’ più critici. Specie poi nel caso specifico di jQuery che non è certo noto come il più parsimonioso di risorse (anche se con la prossima versione le cose porebbero cambiare).

Infine, e parzialmente correlato al punto precedente, lascia un po’ perplessi anche un’altra cosa. Molte delle risorse segnalate non hanno in realtà quasi nessun “sex-appeal” . Cosa che dovrebbe fare un attimo riflettere per un articolo che titola come “I 20 usi più pratici e creativi di jQuery”.

Ma ad ogni modo qui si va sul campo dei gusti personali e non è quindi possibile dare giudizi assoluti.

Chiudo quindi questo mio secondo articolo-polemica (o terzo ? 😕 ) nel mondo del web design lasciando a voi il compito di giudicare. E se volete fatemi avere i vostri pareri. 😉

PS
Preciso comunque che non tutto è da buttare e, anzi, molte cose sono interessanti. Solo sarebbe stato necessario maggior criterio durante la stesura dell’articolo.

Safari 3.1: la soluzione che molti webmaster aspettavano

Non essendo (ancora) un mac user non ho mai seguito molto lo sviluppo di Safari e WebKit, il suo core-engine.

Safari LogoCome molti di voi sapranno tuttavia qualche tempo fa Apple ha deciso di portare il suo innovativo web-browser sulla piattaforma di zio Bill e da allora le cose sono cambiate, ritrovandomi adesso a seguire una decina di feed in più per restare aggiornato sull’argomento.

E proprio oggi aprendo il mio Google Reader trovo tra questi ultimi feed una notizia che mi ha davvero interessato, sia come pseudo-esperto/amante di browser (no, non sono malato 🙄 ) sia, soprattutto, come webmaster dal momento che aspettavo questa feature da anni.

La notizia a cui mi riferisco è il supporto (finalmente!) al download dei font usati nelle pagine che visitiamo, qualora questi non siano disponibili sul nostro sistema.

Sino ad oggi infatti in questi casi il comportamento standard di tutti i browser sarebbe stato di sostituirli con font simili (con risultati spesso piuttosto lontani dall’originale) o, peggio ancora, con quelli di default.

Sembrerà una cavolata ma in realtà la cosa ha sempre rappresentato un problema di non poco conto per tutti i webmaster, specie se alle prime armi, che realizzato il layout dei propri sogni scoprono come questo renda in modo orribile sul PC dell’amico (naturalmente il problema dei font è solo uno dei tanti sotto questo aspetto).

L’unica soluzione, ormai ampiamente collaudata nel corso degli anni, è stata quella di ricorrere all’uso di limitati set di caratteri standard che, nella migliore delle ipotesi (e non sempre questo è vero), tutti gli utenti della rete dovrebbero avere installati sul proprio sistema.

Naturalmente questo palliativo, viste le infinite possibilità che i grafici (o tipografi? 😕 ) di oggi ci mettono a disposizione, non mi ha mai soddisfatto molto, appiattendo di fatto molte idee originali in nome della compatibilità. Del resto anche il “workaround” di ricorrere all’uso di immagini non è applicabile che a limitate sezioni della pagina come l’header o poco altro, mentre quello di realizzare tutto in flash (che permette di incorporare i font nel file) non è certo una soluzione valida.

Finalmente comunque questo problema ha trovato una soluzione piuttosto semplice, ma al tempo stesso efficace, grazie al lavoro svolto dagli sviluppatori di WebKit.

Inspector Fonts

Resta tuttavia il dubbio sulla reale utilità della cosa qualora anche i concorrenti non adottino lo stesso comportamento. Sviluppare un sito per un solo browser non è infatti la scelta migliore, specie se questo non ha i numeri di IE o FF, e non credo che saranno in molti i webmaster che rischieranno una mossa del genere.

Sperando che Microsoft, Mozilla ed Opera si pronuncino presto sulla faccenda non ci resta che attendere fiduciosi.

Discorso font a parte comunque, altre novità accompagneranno il debutto di Safari 3.1.

Tra le più importanti, il supporto allargato ad HTML5, l’ultima versione dello standard, già adottato anche da Opera 9.5 e Firefox 3, che includerà fra le altre anche tag per il supporto nativo agli elementi audio e video, e le nuove capacità CSS Transform e CSS Animations, caratteristiche davvero interessanti nelle mani di sviluppatori esperti.

E come sempre ecco una lista di fonti ed approfondimenti vari.

Links:

WebKit Blog: Web Inspector Update
WebKit Blog: CSS Animation
TheAppleLounge: Mac OSX 10.5.2: seed 9C31 con Safari 3.1
Apple Blog: Safari 3.1: supporto ai font web scaricabili e molto altro
MelaMorsicata: In arrivo Safari 3.1
Just Browsing: Apple Edges Towards RIA Viability

Opera per gli sviluppatori Web?

Solo una settimana fa scrivevo per OperaZone dell’interessante intervista rilasciata da Jan Standahl, direttore dell’ Opera product management e del developer relations team, e Chris Mills, Opera developer relationship manager, a Digital Web Magazine, in cui i due spiegavano i vantaggi che qualsiasi sviluppatore web avrebbe ottenuto usando Opera.

WorldE sinceramente ho trovato le motivazioni addotte da Jan e Chris estremamente convincenti e assolutamente veritiere (al contrario di quanto mi è capitato spesso di leggere in altri contesti in cui tutto si basa su pura fuffa). La presenza, ad esempio, della stessa architettura su dispositivi fissi e mobili (ovvero quanto avverrà definitivamente con Opera 9.5) è senza dubbio (o, meglio, dovrebbe esserlo) uno dei motivi più validi per uno sviluppatore web così come l’assoluta aderenza a standard Web certificati dal W3C.

Tuttavia giusto qualche giorno fa mi son trovato io stesso, durante lo sviluppo di Engelium’s Wall, nella situazione di dover scegliere quale browser usare per il suo debug ed i vari test su strada. E, ahimè, la scelta è ricaduta ancora una volta su Firefox.

Eppure ormai le soluzioni web-dev per Opera non mancano di certo. La Developer Console sviluppata qualche tempo fa non ha molto da invidiare a quanto ha da offrire Firebug, così come il Terminale degli errori che ritengo esattamente alla pari nei due browser. Ed anche per quel che riguarda la Web Developer Toolbar di Firefox esistono validissime alternative usando menu e/o toolbar ad hoc (ZDYX’s menu tanto per dirne uno).

Perchè allora questa scelta decisamente insolita da parte mia? Semplicemente una parola: comodità.

HTML ValidatorDi che comodità sto parlando? Del poter ad esempio vedere se la pagina che sto sviluppando è aderente agli standard W3C semplicemnte buttando un’occhio alle iconcine di Firebug, HTML Validator (che preferisco di gran lunga a Firebug) o, infine, a quelle della Web Developer Toolbar (che distinguono addirittura tra (x)HTML, CSS e Javascript).

Obiezione: ma anche Opera supporta (e di default) la validazione dei sorgenti tramite una comoda voce di menu o shortcuts da tastiera (Ctrl+Alt+V).

Vero, ma per farlo bisogna innanzitutto agire manualmente a differenza di quanto avviene in FF, e poi il tutto passa comunque per il servizio di validazione on-line offerto dal W3C (i cui server fra l’altro risultano spesso dei veri bradipi nello gestire le richieste ricevute).

Si tratta insomma di una piccolezza a prima vista di importanza nulla, ma che è stata capace di spingermi all’uso di Firefox anzichè di Opera. Dove voglio arrivare? Semplicemente vorrei che ad Oslo capissero che basta un niente per scegliere un applicativo e non un altro. Una cosa che troppo spesso invece hanno deciso di ignorare.

Comunque, come si legge nell’intervista, presto Opera rilascerà i suoi nuovi strumenti per Webmasters (ricordo che l’attuale Developer Console in javascript è solo un palliativo temporaneo) che dovrebbero colmare definitivamente il divario fra i due browser. Con la speranza che anche queste “frivolezze” non passino più inosservate.

Aggiornamento:
Lo stesso argomento è stato trattato proprio ieri da Daniel Goldman su OperaWatch. la discussione (e tutti i commenti che la seguono) sono piuttosto interessanti. Sicuramente merita una lettura 😉 .