Undolog.com

Per realizzare delle Tabstrip davvero accattivanti esiste una tecnica particolarmente indicata che consente di mediare tra difficoltà grafiche e codice Javascript. Vediamo prima di tutto come costruire un templete in Photoshop per le nostre Tabstrip:

Costruita un tabstrip simile a quella mostrata qui sopra in figura, usiamo il tool per la selezione delle area di taglio per generare la forma che avrà la nostra tabella HTML. L’uso della tabella, in questo caso, è particolarmente indicato – come vedremo, in quanto semplifica sia il design che il codice Javascript. Ritagliamo dunque la nostra Tabstrip nel modo seguente:

Nel nostro file Photoshop dobbiamo considerare tutte le combinazioni delle schede (tab). Abbiamo quindi la scheda iniziale selezionata (taglio 3), i punti intermedi (taglio 5 e taglio 7) e la scheda finale non selezionata (taglio 9) con – eventuale – bordo di rifinitura (taglio 10 – opzionale a seconda del design). Bastano poi 3 combinazioni per risolvere tutti i casi visivi. Come mostrato qui sotto:

Graficamente parlando potete disporre le schede anche in sovrapposizione e sfalsate, come mostrato qui sotto:

Questione di gusto e di necessità… tornando all’immagine completa, con le tre strisce Tabstrip per le combinazioni, le ultime due servono per risolvere i casi limite; tagliatele come mostrato qui sotto:

Il taglio 17 e il taglio 23 risolvono i due casi limite: prima tab non selezionata, ultima selezionata. Il taglio 19 è l’opposto del taglio 5 e del taglio 7, visti in precedenza. L’immagine completa che otteniamo e che possiamo salvare per futuri cambiamenti di design è la seguente:

Per non confonderci quando affronteremo la parte Javascript, il nome dei tagli è il seguente:

• taglio 3 = tabLeftFirstOn
• taglio 4 = tabStripeOn
• taglio 5 = tabMiddleOnOff
• taglio 6 = tabStripeOff
• taglio 7 = tabMiddleOffOff
• taglio 9 = tabRightLastOff
• taglio 10 = topBg
• taglio 17 = tabLeftFirstOff
• taglio 19 = tabMiddleOffOn
• taglio 23 = tabRightLastOn

Per realizzare tutto ciò ci serve adesso un codice HTML, un codice CSS e un codice Javascript come gestore dei click sulle schede tab. Il codice HTML è banale ma articolato. Quindi propongo una classe PHP in grado di generarlo ogni volta che ci serve. In sostanza si tratta di creare una tabella HTML racchiusa in determinati DIV con ID particolari che ci serviranno poi per l’esecuzione del codice Javascript e per racchiudere il design tramite i CSS. Il codice HTML generato – tanto per farsi un’idea – di un Tabstrip con quattro schede è il seguente:

Il codice PHP che genera questo HTML è il seguente:

Per usare la classe basta questo frammento:

Definiamo ora gli stili:

Il codice Javascript è assai blando, scritto in un’epoca lontata quando Prototype.js non esisteva. Inoltre nell’esempio qui sotto faccio uso di una libreria di effetti (non esisteva nemmeno Scriptaculous) ancora valida, quindi la riga che usa la transizione Opacity la potete sostituire con quello che volete:

In pratica le righe dalla 36 alle 46 possono essere sostituite con quello che volete, anche un display=”none”. Il codice è antiquato, almeno rispetto le nuove tecniche di Javascript non intrusivo (oggi lo scriverei in modo diverso). Tuttavia la parte che rimane interessante ed attuale e la configurazione della tabella HTML che gestisce i Tabstrip. Essa permette una resa grafica di alto livello, a differenza di alcuni altri metodi che – in sostanza – trattano le schede Tab come semplici DIV uno accanto all’altro.
Un modo ancora migliore sarebbe quello di sfruttare lo z-index (ordine di visualizzazione) presente negli stili CSS, così da gestire la sovrapposizione di elementi grafici. Purtroppo, ad oggi, è una tecnica assai difficile da implementare a causa delle differenze tra i browser che la rendono di fatto instabile, salvo rare circostanze.
Presto ne farò una versione più moderna… se avete dubbi o domande sono qui!

Continua...

Dopo aver sistemato la grafica di Undolog e aver apportato gli ultimi ritocchi ad alcuni titoli (vedi sidebar), mi sono divertito ad usare l’accoppiata Prototype.js e Scriptaculous, in modalità non intrusiva (Unobtrusive)! Ecco un video (ma lo potete provare di persona qui a destra ) con la simpatica funzione che ho aggiunto alla sidebar di Undolog, che oltre a renderla più gradevole spero la renda anche più funzionale!

Il codice che ho utilizzato è davvero semplice:

Inoltre notate che la prima volta che viene caricata la Home Page di Undolog viene automaticamente chiuso il pannello delle Categorie – identificato dall’id tit_category:

I titoli sulla sidebar sono definiti, quindi, in questo modo:

Tramite la classe dropdown vengono identificati i titoli H2 da rendere dinamici, grazie alla funzione doppio-dollaro ($$) di Prototype.js – di cui abbiamo già parlato…

Continua...

Se nel 1979 il celebre brano dei Buggles cantava ”Video killed the radio star”, oggi è il caso di riproporlo modificando i soggetti: Video -> Internet/Net TV e radio -> TV/la televisione come la conosciamo! Il vantaggio di poter trasmettere in diretta e applicare tutte le formule della trasmissione non lineare fanno della Net TV un elemento essenziale ed insostituibile nel panorama informativo fornito da Internet. Il fenomeno è già esploso e la sua avanzata è ormai inesorabile. In Italia, come spesso accade, la lentezza e la poca lungimiranza rendono difficile apprezzare quello che sarà il futuro prossimo della TV. Tuttavia se ne parla e questo è già un inizio. Grazie ai Blog oggi è possibile informare più rapidamente rispetto a qualche tempo fa.
Oltre ai contenuti generati dagli utenti il passo successivo è quello di fornire format, la killer application che probabilmente - almeno nel panorama italiano – ancora stenta a decollare. Joost promette la serie C.S.I., dopo aver attivato un canale sul calcio in italiano (gli italiani si prendono solo con il calcio?), ma ciò non basta evidentemente. Ci deve essere un vero e proprio trasferimento dei contenuti attualmente disponibili sui canali tradizionali, DTT compreso, in modo da far decollare la Net TV come merita; telegionali, serial, film (vedi “I pirati di Silicon Valley” – peccato solo in inglese). Le beta dovrebbero terminare a breve, Babelgum compreso, quindi vediamo cosa accaddrà con i motori accesi e usciti fuori dal garage!

Continua...

Perchè passare ad Apollo per visualizzare HTML e contenuto dinamico quando un browser già lo permette? Perchè usare Joost per vedere la Net TV quando un browser già lo permette?

Perchè chi produce browser non ha inserito due semplici funzioni al loro interno:

• Finestre Windowless
• P2P Object

Finestre Windowless

Questa semplice caratteristica permetterebbe di sfruttare al meglio la connessione HTTP e di rendere davvero utili i browser. Poter aprire finestre (popup nella pratica) con il solo titolo e senza bordi, casomai in trasparenza, aumenterebbe la produzione di Widget da sfruttare con i normali browser, al pari di quello che fa oggi Apollo. Con uno studio attento sulla sicurezza (in quanto penso sia oggi l’unico motivo di questo limite) si aprirebbero scenari davvero interessanti.

P2P Object

Come tutti sappiamo oramai tutti i browser supportono l’oggetto XMLHttpRequest, che ha dato vita ad una quantità sconfinata delle cosiddette applicazioni Ajax. Questo oggetto, utilizzabile tramite Javascript, è in grado di fornire un canale HTTP – parallelo - gestibile tramite script client, sia per l’ìinvio che per la ricezione dati.
Primo o poi, come anticipato in vari altri Blog, Adobe inserirà un P2P all’interno di Flash. Perchè non fare la stessa cosa nei Browser? Un oggetto di questo tipo unito a funzionalità Windowless permetterebbe di creare applicazioni simil-Joost senza installare nulla sulla propria macchina, garantendo una cross-compatibilità degna di Internet, aumentando quindi anche l’efficienza della produzione (ad oggi Joost è sviluppato per ogni singolo sistema operativo, cosa assai gravosa – sia in termini economici che temporali – infatti le beta si susseguono…).

Insomma finestre con RSS FEED testo, audio e video da posizionare dove vogliamo sul nostro desktop, in vero standard W3C. Apertura si canali TCP direttamente da Javascript, con possibilità di scambio dati sconfinate. Evidentemente la volontà è poca e la “criminalità” è alta; hackers, Spam e Phishing sono in agguato e mosse di questo tipo terrorizzano un po’ tutti…

Continua...

Premetto che stiamo parlando di WordPress 2.0.6. Se cercate di impostare le categorie in modalità “combo” – dropdown – occhio alle indicazioni proposte sul sito di WordPress. Quando si realizza una FORM HTML con un bottone SUBMIT bisogna stare attenti a non impostare il nome del TAG INPUT proprio a “submit”, pena mandare in rovina tutto appena si cerca di submittare la FORM via Javascript.

Sul sito di WordPress viene proposto il seguente codice:

Notate che il bottone di invio ha l’attributo name impostato a “submit”. Se cercate di esguire una codice Javascript tipo questo:

L’interprete va in confusione in quanto non distingue il metodo submit() dall’elemento “submit” che è invece un bottone! La soluzione è semplice: chiamate il bottone come vi pare ma non “submit”!

Il codice che ho usato per visualizzare le categorie in dropdown mode io è il seguente:

Ho dovuto anche modificare il Kernel di WordPress (cosa che non andrebbe fatta…). Nel file “template-functions-category.php” ho modificato la funzione dropdown_cats() quando prepara il TAG SELECT ho aggiunto:

Ecco il pezzo di codice da rintracciare:

Una cosa che la funzione non fa è impostare il combo sulla categoria scelta quando viene ricaricata la pagina… appena ho tempo lo guardo meglio.

Come nota a tutto ciò, per esigenze di completezza, sottolineo che bisognava agire con un codice non intrusivo (Unobtrusive) invece di inserire l’onchange direttamente nella costruzione del combo. Inoltre le categorie visualizzate con il combo non sono accessibili per i browser con Javascript disabilitato. Tuttavia questo lo si può risolvere utilizzando il TAG NOSCRIPT nella sidebar e visualizzare le categorie come lista di link – modalità di default di WordPress – aggiustamenti che farò a breve .

Continua...

L’inserimento di oggetti (in particolare Flash Objects) all’interno delle pagine Web è diventato ultimamente un’attività spesso stressante. In altri Post abbiamo già affrontato l’argomento di come rilevare Flash ed inserirlo nelle pagine in modo appropriato. Dato che abbiamo parlato di tecniche Unobtrusive, vi segnalo due noti script in grado di rilevare (ed eventualmente installare) ed inserire oggetti Flash in una pagina, in modo assai afficiente e poco intrusivo: SWFObject e UFO.
Entrambi gli script offrono in sostanza le stesse caratteristiche e un funzionamento identico. L’approccio è quello che sostituire tramite Javascript un determinato TAG con il contenuto Flash. Come sappiamo questo procedimento elimina il problema dell’attivazione dell’oggetto Flash imposto da Internet Explorer, tuttavia implica che Javascript sia attivato sul target-browser.
Entrambi gli script non fanno uso di librerie esterne, come Prototype.js ad esempio. La differenza più importante tra i due è che SWFObject va chiamato quando il TAG da sostituire è già stato caricato nella pagina, modalità non propriamente Unobtrusive. Ecco uno stralcio di codice che mostra la sequenza di chiamata:

UFO, invece, permette un’approccio decisamente più in linea con i classici script Unobtrusive. La sostituzione del TAG avviene in modalità trasparente, senza abbligare sequenze di caricamento, come mostrato nell’esempio qui sotto:

Nel codice sorgente dello script di UFO, infatti, si nota immediatamente l’uso – più appropriato – di un evento che attente il caricamento completo della pagina prima di eseguire la sostituizione; approccio quindi estremamente più consono a script non intrusivi.

Continua...

Tra le varie librerie  – o insieme di librerie (veri e propri framework), dedicate ad Ajax, estensione dell’interfaccia HTML e Web2.0 che mi è capitato di vedere, Ext è sicuramente degno di nota. Il sito Web e la documentazione sono ben fatti e organizzati, inoltre i demo online sono da non perdere. L’interfaccia grafica, la compatibilità con Prototype e Scriptaculous e l’impletazione dei Yahoo Utils, ne fanno un sistema quantomeno interessante! Attenzione però alla licenza! Nonostante si presenti come open source e gratuito, per usi personali, richiede un pagamento per potenziarne l’uso e l’assistenza. Quest’ultima, infatti, non è mai da sottovalutare in framework di una certa complessità.

Per la documentazione e i demo clicca qui.

In particolare cito questo sistema, che sto ancora analizzando in dettaglio, in quanto è stato utilizzato per creare Fresh Feed Reader, una delle applicazioni di esempio fornite con la versione Alpha di Adobe Apollo (vedi Adobe Apollo Alpha Release). Fresh, quindi, è un duplice esempio dell’uso di Apollo, che dimostra le sue capacità di sfruttare HTML e Javascript al massimo. Fresh, infatti, non è un’applicazione Apollo pura, ma usa il framework Ext- e quindi Javascript e HTML – all’interno del motore Apollo! Fantastico!!

Continua...

Ecco un nuovo ed interessante tool per la compressione e l’oscuramento di codice Javascript (vedi anche Reverse Engineering: i compressori di codice).
Sul sito Web di Dean Edwards è possibile scaricare anche il codice sorgente Javascript di questo compressor. Inoltre l’autore ha reso disponibili le versioni server per Microsoft .NET Framework versione 1.1, Perl, WHS e PHP5.

Online è disponibile una versione funzionante da provare subito, meno complessa - a dire il vero - di quelle che avevo presentato tempo fa. Permette, infatti, di comprimere il codice con due sole scelte: il Base62 encode, che oscura il codice e il Shrink variables, l’ottimizzatore di variabili.
Rispetto alla precedente versione sono stati risolti alcuni bachi che, in situazioni di hack estremi (e davvero interessanti) come:

non rispettavano l’output generato. Ora sono correttamente supportati sia i conditional comments di Microsoft, sia gli  operatori +/- in condizioni come:

Come sottolineato nella pagina di Help, tuttavia:

Packed scripts should successfully unpack on all browsers that support JavaScript. Only basic JavaScript functionality is used to decode the packed script.

Some browsers may not support the packer itself. The web interface requires DOM support. Legacy browsers will display a disabled interface.

Quindi massima attenzione all’utenza finale e al tipo di browser da supportare… come sempre del resto!

Continua...

In questo Post vorrei analizzare l’uso di script unobtrusive dal punto di vista del Web Designer. Normalmente, infatti, uno script non intrusivo è tale nei confronti del navigatore finale!
Ma può esserlo anche per il Web Designer?

Unobtrusive Javascript dal punto di vista del Web Designer

Mettendoci nei panni di un Web Designer potremmo identificare due categorie di unobtrusive Javascript: true unobtrusive Javascript e pseudo unobtrusive Javascript.

Entrambe le categorie, tuttavia, non sono completamente non intrusive (sempre dal punto di vista del Web Designer). Un reale e completo unobtrusive Javascript non dovrebbe richiedere nessun intervento nella pagina Web, ma questo è – per ora – sostanzialmente impossibile. L’operazione minima richiesta durante l’installazione di uno script è comunque l’inserimento dell’inclusione dello script stesso! Viene dunque ammessa tale operazione che – effettivamente – non costringe il Web Designer ad apportare modifiche straordinarie alla struttura della pagina. Il semplice posizionamento dell’inclusione dello script all’interno del Tag head può essere quindi considerato non intrusivo.

Il true unobtrusive Javascript

Gli script di questo tipo sono quelli che richiedono la sola inclusione dello script unobtrusive e non ;pretendono nessun’altra operazione! Script di questo tipo sono, ad esempio (il solito e citatissimo), Snap. Una volta inserito il codice di inclusione il Web Designer non deve svolgere nessuna operazione ulteriore, in quanto lo script di Snap opera su Tag standard.

Gli pseudo unobtrusive Javascript

Questi si differenziano dai precedenti in quanto richiedono una taggatura ulteriore per funzionare correttamente. Esempi di questo tipo sono i Control.Tabs di Ryan Johnson o la libreria per gli slideshow Lightbox JS. Quest’ultima soluzione, ad esempio, richiede l’inserimento nel Tag A dell’attributo rel per identificare i link che devono essere modificati. Lightbox JS, in particolare, richiede addirittura la presenza esplicita sia di Prototype che di Scriptaculous. Come indicato sul sito di Lightbox JS, l’inclusione dello script deve essere di questo tipo:

I link che puntano ad un’immmagine che si vuole visualizzare con il sistema Lightbox JS devono essere scritti in questo modo:

Inoltre per identificare un gruppo di immagini, per aggiungere la capacità di scorrere avanti e indietro le immagini, i Tag A devono essere impostati nel modo seguente:

La necessità di tali costrizioni risulta evidente; non esiste un modo semplice per distinguere un elemento link (Tag A) da un altro. In particolare non è possibile capire quale elemento il Web Designer vuole visualizzare in un modo o in un altro. Dev’essere necessariamente il Web Designer ad indicare in qualche modo i Tag e i loro comportamenti. Sono quindi richieste – intrusive – del tutto comprensibili, che non sminuiscono affatto l’utilità e le potenzialità di questi script. Comportano solo un dettaglio maggiore e qualche riga di codice in più al Web Designer.

È interessante, comunque, il doppio aspetto dell’unobtrusive Javascript, analizzato sia dal punto di vista dell’utente finale sia dal punto di vista Web Designer.

Continua...

Visto che ne abbiamo parlato bene nei Post precedenti, è giunto il momento di parlarne male (scherzo), o quantomeno di evidenziare alcuni difetti della tecnica di unobtrusive Javascript.
Se il codice unobtrusive Javascript viene eseguito quando la pagina è completamente caricata, ne deriva che maggiore sarà la quantità di dati (HTML) che forma la nostra pagina e maggiore sarà il tempo di attesa prima che il nostro codice venga eseguito.

Tutto ciò può tradursi in ritardi di esecuzione con un conseguente e fastidioso effetto di sfarfallio se si opera su elementi visivi della pagina. Prendiamo ad esempio il codice usato da Ryan Johnson per creare degli oggetti TabStrip. Se guardate attentamente il demo online vi accorgerete che per un secondo circa, al caricamento della pagina, si vede chiaramente un layout standard sostituito subito dopo da oggetti TabStrip. Ricaricando nuovamente la pagina, grazie alla cache del browser, il problema tende a diminuire (provate a pulire tutta la cache del browser per verificare i tempi).

Tutto questo ci deve far riflettere sui limiti di questa tecnica. Lo stesso Snap soffre esattamente dello stesso rallentamento, soprattutto in pagine spesso estremamente alte come quella di undolog.com. Caricando la home page di questo Blog risultà evidente che Snap viene eseguito qualche secondo dopo, ovvero quando la pagina è completamente caricata.

Per definizione dell’unobtrusive Javascript questo problema è difficilmente risolvibile a livello generale. Tuttavia nello sviluppo di un sito proprietario si possono prendere alcuni accorgimenti tesi a eliminare o ridurre tali difetti. Un modo abbastanza semplice è quello di creare una sorta di preload, elemento diffuso in ambiente Adobe Flash. Si può quindi impostare il Tag body – che contiene tutti gli elementi della pagina – in modo che risulti invisibile, lasciando al codice Javascript il compito di renderlo visibile quando ha terminato le – eventuali – modifiche al DOM:

Il codice unobtrusive Javascript, al termine delle sue operazioni:

Soluzione, tuttavia, banale e non sempre applicabile. Inoltre, anche se abbiamo in qualche modo risolto il problema del primo caricameno, navigare in un tal modo a lungo andare potrebbe davvero risultare fastidioso per i navigatori. Non essere intrusivi, quindi, ha un prezzo da pagare. Anche operando a livello di oggetto, per esempio impostando solo gli elementi interessanti in modalità nascosta, il fatto che il codice parta alla fine del caricamento dell’intera pagina porta inevitabilmente con sè le stesse identiche problematiche.

Continua...