Secondo il Director of Research dell’azienda, oggi il lavoro di webmaster, webdesigner e soprattutto SEO dovrebbe concentrarsi maggiormente su altri aspetti, anziché tendere i propri sforzi al conseguimento di un alto PageRank.

A quanto pare BigG considera ormai la tanto celebre barra bianca e verde rappresentativa di un’epoca ormai lasciata alle spalle. Dopo la rimozione dai Google Webmaster Tool, si attende ora che l’indicatore del PageRank scompaia anche dalle prossime release della Google Toolbar, magari per fare spazio a nuovi parametri con i quali i professionisti del Web dovranno vedersela negli anni a venire.

*C@rlo*

Personalmente ho avuto il piacere di conoscere attraverso l’Istituto Chiossone alcune persone cieche, ipovedenti, le quali mi hanno fatto provare cosa significa navigare un sito  con il monitor spento ascoltando solo la voce della sintesi vocale, mi hanno mostrato la tastiera braille, un’invenzione incredibile secondo me. Io sono rimasta davvero stupefatta dalle loro abilità, la velocità con cui navigano, l’entusiasmo e la positività che hanno nonostante gli ostacoli che devono superare.

Dal libro di Michele Diodati  ho molto riflettuto leggendo l’introduzione scritta da una persona sordocieca, per me è difficile anche solo pensare che una persona possa non sentire e non vedere.. bene non solo queste persone esistono ma navigano tutti i giorni come noi, utilizzando solo il tatto per comunicare e penso che basterebbe immedesimarsi solo un secondo per capire quanto può essere importante l’accessibilità,  a volte basta un accorgimento minimo per facilitare molto la vita di qualcun altro.

Vale

Si tratta cioè di una parte in cui vengono monitorati alcuni eventi sul nostro sito web, come ad esempio:

• il download di un file (es. PDF)
• l’interazione con applicazioni dinamiche, Ajax, ecc.
• l’interazione con oggetti Flash, video e altri media Adobe

Prima infatti questo si poteva fare ma si andavano a creare delle “Pageview” virtuali, che si aggiungevano a quelle reali, andando a creare confusione all’interno dei vari report della sezione “Contenuto”.
Ora invece in questo modo si tracciano solo gli eventi reali, che verranno raggruppati nella nuova parte a loro dedicata.

I metodi per fare in modo che i suddetti eventi vengano correttamente monitorati sono diversi (e verranno indicati nei futuri post); al momento ci tengo a segnalare questo (in inglese):
How to send Events to Google Analytics

*Carlo*

L’articolo su AlistApart permette di conoscere tutti gli utilizzi di questa ottima tecnica: http://www.alistapart.com/articles/sprites/
C’è chi la definisce come una tecnica misteriosa riportando molti esempi di siti che la utilizzano: http://www.smashingmagazine.com/2009/04/27/the-mystery-of-css-sprites-techniques-tools-and-tutorials/

Anche il LAU – Laboratorio di Accessibilità e Usabilità ne parla con un utile articolo in italiano con le istruzioni per implementare la tecnica.
In tutti gli articoli viene consigliato l’utilizzo di CSS Sprites Generator, se ne trovano di diversi tipi in rete e in pratica fanno tutto il “lavoro sporco” per noi, restituendoci le immagini già composte con le posizioni corrette. 
L’unico neo  riguarda l’accessibilità, in quanto non è possibile utilizzare testo alternativo (tag alt) sulle immagini, inoltre se usiamo questa tecnica per visualizzare loghi e parti grafiche rilevanti del sito, dobbiamo sapere che non ci sarà possibilità di stamparle.

Vale

Precedentemente avevo pubblicato un post riguardo BrowserShots che genera screenshot di una pagina web in più di 80 versioni dei più diffusi Browser su Windows, Linux, BSD e Mac, servizio sicuramente molto utile, ma BrowserLab offre di più; la sua principale caratteristica oltre alla velocità nel visualizzare gli screenshot è sicuramente la vista onion skin, che consente di visualizzare gli screenshot sovrapposti dei diversi browser.

Lato server, BrowserLab utilizza la tecnologia di virtualizzazione, lato client utilizza invece Flash Player 10: la tecnologia Flash viene impiegata per  visualizzare, all’interno di una finestra suddivisa in due parti, il risultato del rendering di una pagina web eseguito su due differenti browser. Le due sotto finestre possono essere affiancate o sovrapposte per consentire di confrontare al meglio le eventuali differenze tra un browser e l’altro.

Adobe browserLab

Peccato che il servizio è destinato a diventare a pagamento, mentre per i primi 5000 iscritti Il tool resterà gratuito fino alla fine del programma di testing pubblico.

Personalmente mi domando: se la strada è quella dell’adesione dei vari browser agli standard, perché continuano a rilasciare tools per testare il proprio sito? La strada è veramente quella? Spero vivamente di si, ritengo assolutamente sbagliata e anti produttiva quest’ossessione maniacale della perfezione al pixel.

Bene

Ecco perché Google ha deciso di ristrutturare Strumenti per i Webmaster da zero, con una suite di funzioni organizzata in modo logico, oltre a un’interfaccia più pulita e veloce. Questo risultato è stato ottenuto parlando con i webmaster e conducendo studi sugli utenti.

Il risultato è una navigazione più semplice e intuitiva. Le funzioni ora sono raggruppate in tre categorie:

• Configurazione sito (dove si possono fornire a Google informazioni sul proprio sito)
• Il tuo sito sul Web (dove si possono visualizzare i dati di Google relativi al proprio sito)
• Diagnostica (dove si possono ottenere rapporti su eventuali problemi riscontrati nella scansione del proprio sito)

Il loro obiettivo era semplificare l’individuazione di statistiche e dati, rimuovendo nello stesso tempo le pagine e le funzioni ridondanti (come le Statistiche indice) che ingombravano l’interfaccia e riproducevano informazioni disponibili altrove.

A una prima fugace occhiata direi che lo scopo è stato raggiunto.

*Carlo*

Esistono già aziende che hanno iniziato a sviluppare usando la in preview: scorrendo l’elenco degli esempi non possiamo fare a meno di notare Concentrateme di Juice Analytics oppure MailChimp.
Google ha dato loro un accesso privilegiato in modo da uscire da subito con alcuni strumenti pronti e funzionanti, che possono motivare ulteriormente altri sviluppatori a gettarsi nella mischia.

Ad esempio, si può ipotizzare l’arrivo di CMS in grado di proporre automaticamente in prima pagina i contenuti più letti, oppure di comporre al volo una pagina con i contenuti più visitati da una determinata keyword se l’utente arriva con la medesima keyword.

Non essendoci quasi limite alla fantasia, una volta che si possono avere i dati a disposizione, fuoco alle micce!

*Carlo*

Il sito in perfetto stile web 2.0 permette di interagire inserendo i propri consigli, taggarli con parole chiave  e suggerire tutorial o esempi relativi al consiglio proposto.
Inoltre il sito propone anche una suddivisione di tutti gli accorgimenti inseriti in tre livelli di apprendimento: beginner, intermediate e advanced e un sistema di votazione per decretare i consigli più votati.

Mi sembra una proposta originale e interessante per raccogliere idee, condividerle tra gli utenti e creare una guida utile e facile da consultare.  Speriamo che il servizio abbia successo e continui ad arricchirsi e magari ad aggiungere qualche altra features interessante in stile web 2.0.

Vale

*Carlo*

Un bravo sviluppatore web sa che Firebug è un estesione per Firefox che rente molto facile il debug delle nostre pagine web e ti permette di ottimizzare i tempi per fare delle modifiche evitando ogni volta di andare ad aprire direttamente il codice sorgente.

Non tutti sanno però che esiste una versione semplificata del mitico Firebug chiamata Firebug Lite, utilizzabile su browser come Internet Explorer, Opera e Apple Safari.

Firebug lite

Per poterlo utilizzare ci sono 2 modi: come chiamata Bookmark o come libreria Offline.

In modalità Bookmark bisogna aggiungere il seguente link nei preferiti:

javascript:var firebug=document.createElement(’script’);firebug.setAttribute(’src’,'http://getfirebug.com/releases/lite/1.2/firebug-lite-compressed.js’);document.body.appendChild(firebug);(function(){if(window.firebug.version){firebug.init();}else{setTimeout(arguments.callee);}})();void(firebug);

Sarà possibile attivare Firebug Lite su qualsiasi sito Web e da qualsiasi browser. Questa è forse l’opzione più interessante, nonostante le funzioni siano davvero limitate.

In modalità Offline se stiamo sviluppando noi un sito Web, è possibile scaricare un pacchetto Javascript ed installarlo sul nostro Web! In questo modo possiamo usare Firebug Lite anche senza una connessione Internet ed in locale.

Sebbene non sia possibile editare il CSS degli elementi selezionati, Firebug Lite fornisce un meccanismo per editare il CSS. E’ una cosa simile a una console CSS da dove scrivete il vostro codice CSS e ne visualizzate il risultato.

Sul sito ufficiale sono descritte piccole modifiche che si possono apportare a Firebug Lite, chi ne fosse interessato può consultarlo al seguente indirizzo http://getfirebug.com/lite.html.

Bene

Opinione di Google su un sito web e diagnosi dei potenziali problemi
La prima cosa da fare per aumentare la visibilità di un sito su Google è ottenere ulteriori informazioni su come i loro programmi automatizzati (robot) eseguono la scansione e l’indicizzazione del sito.

• Informazioni sulla scansione: si può verificare l’accesso al sito e vedere l’ultima visita di Googlebot. Si possono anche visualizzare gli URL per i quali si sono riscontrate difficoltà di scansione e il motivo della mancata scansione. In questo modo, si possono correggere gli eventuali problemi evitando a Google di dover indicizzare tutte le pagine.
• Convalida del file Robots.txt: si può verificare se ci sono problemi con il file e testare le modifiche al file stesso prima di modificarlo sul server dove è ospitato.
• Contenuto del sito web: si possono visualizzare i contenuti principali del sito e le parole utilizzate da altri siti nei link che vi rimandano.

Scoprire qual è il rendimento del sito
La seconda fase consiste nell’ottenere informazioni su ciò che indirizza il traffico al sito.

• Query principali: si possono trovare le query principali che indirizzano il traffico al sito e la sua posizione nei risultati di ricerca principali. Ciò consente di conoscere l’opinione degli utenti sul sito.
• Informazioni sull’indicizzazione: si può scoprire come viene indicizzato il sito e quali pagine vengono incluse nell’indice. Se nel sito si riscontrassero violazioni, gli strumenti offrono la possibilità di correggere i problemi e di inviare una richiesta di reinserimento del sito.

Condivisione con Google dei dati sul sito
Poiché nessuno conosce il sito meglio del suo webmaster, si possono anche condividere queste informazioni con Google e migliorare l’attitudine del sito alla scansione.

• Invia un file Sitemap: si possono comunicare tutti i dati relativi alle pagine del sito inviando un file Sitemap (in formato xml); si possono indicare quali sono le pagine più importanti e con quale frequenza vengono modificate.
• Specifica il dominio preferito: si può comunicare l’URL da utilizzare durante l’indicizzazione del sito; Google farà il possibile per indicizzare la versione preferita.

*Carlo*

Per  comprenderle meglio linko qualche post interessante dai blog che hanno contribuito a divulgarle e che ogni giorno si impegnano per far si che l’accessibilità in Italia non sia solo teoria:

Marco Bertoni nel suo blog  Semplicemente.org, riassumendo ci fornisce una versione chiara delle dodici linee guida e dei principi alla base delle WCAG2.0.  (secondo me da stampare e conservare)

Da Webaccessibile.org troviamo la prima bozza integrale di traduzione delle WCAG2.0. in italiano, uscita recentemente.

E infine dal blog di Roberto Scano, un’ interessante interpretazione delle linee guida,  portate in musica offrendoci addirittura la canzone ufficiale in versione rap delle WCAG2.0., un modo alternativo per farle conoscere  e per far capire quante persone si impegnano affinchè ci sia diffusione sempre più consapevole dell’esigenza di  una cultura dell’accessibilità.

Vale

Dati statistici riportano un sostanziale calo dell’utilizzo di IE6 da parte degli utenti nell’ultimo anno,  viene quindi naturale chiedersi quale sia la strategia migliore per farlo uscire di scena nella maniera più indolore possibile.

Molti siti norvegesi hanno deciso di non supportare più questo browser, così come un buon numero di sviluppatori avevano dichiarato che nel 2009 avrebbero abbandonato IE6 creando anche gruppi sui social network come “Liberiamoci da Internet Explorer 6” su Facebook.

Le soluzioni sono molte, dalle proposte meno invasive  come una box /warning , prima dei contenuti,  che consiglia all’utente  di aggiornarsi per godere di tutte le funzionalità più avanzate del sito, alle proposte più estreme, come quella di non passare più fogli di stile a IE6, limitando l’esperienza utente a chi non vuole aggiornare il browser, ai soli contenuti testuali .

Io credo che la giusta soluzione stia nel mezzo, è vero che l’utente dovrebbe essere invitato con risolutezza ad aggiornarsi ma bisogna considerare anche le esigenze di molte aziende che non si aggiornano con facilità.
Sono curiosa di sapere cosa succederà e voi cosa ne pensate?

Vale

Il problema della compatibilità con i browser, infatti, riguarda tutti i siti Internet e nasce quando una pagina web o qualsiasi altra risorsa condivisa in rete viene sviluppata senza tener conto delle funzionalità presenti nei diversi browser, nelle diverse versioni degli stessi e nelle diverse piattaforme che li supportano.

Bisogna cercare di  adottare determinati accorgimenti in termini di linguaggi di markup (XML, XHTML, HTML ecc), fogli di stile (CSS, XSLT ecc), scripting lato client (javascript/ajax o altri) o eventuali altri formati di uso frequente sul web (Flash, Java), al fine di permettere all’utente che naviga di visualizzare e fruire i contenuti senza differenze dipendenti dal browser che utilizza.

Io la vedo come una ricerca, una ricerca del codice perfetto; a volte si rischia così di trasformarla in un’odissea, in una ricerca estenuante di trucchi e soluzioni alla miriade di bug che affliggono i browser presenti nel mercato.

Ma come fare a testare il nostro sito web su tutti i browser esistenti nel mercato?
Bè , esistono svariati programmi che ti permettono di testare il sito web, ma quello che mi ha colpito di più girando in rete è stato Browsershots.

Browsershot è un servizio web, gratuito, che permette di visualizzare un sito in 50 web browser diversi, di tutti e 4 i maggiori sistemi operativi (Linux, Windows, Mac OS X, BSD).
Basta inserire l’url del nostro sito web nell’apposito spazio , selezionare i browser con cui fare il controllo, addirittura puoi decidere di selezionare le dimensioni dello schermo, la profondità di colore, selezionare se sono presenti script  java e se è presente un animazione flash.

Avremo davanti a noi una serie di thumbnails: una per ogni browser scelto.
Se clicchiamo la thumbnail, ingrandiremo lo screenshot e otterremo informazioni  sul computer, sul browser, e sul rendering in generale. Cliccando invece sullo screenshot avremo l’immagine a grandezza massima.

Peccato che il confronto avvenga solo con degli screeshot e non si possa navigare all’interno dei vari  browser, ma chissà che in un futuro non venga sviluppato un modo semplice e veloce per testare i nostri siti web interagendo con i vari browser.

Quanto dovremmo ancora soffrire per raggiungere il codice perfetto?
Bene

scarica la mappa mentale per Google Analytics

*Carlo*

Si tratta di un foglio di stile di base in grado di annullare tutte le proprietà CSS attribuite di default dai browser (dimensioni, peso, tipo, margini, padding, ecc..).

Interessante l’evoluzione del CSS nelle diverse versioni e soprattutto da non perdere la logica dietro le varie scelte implementative, ben illustrata dal guru.

Molti preferiscono usare un CSS di base magari che includa anche un ritmo verticale, in grado di fornire già un solido punto di partenza.

Io personalmente utilizzo con soddisfazione la tecnica di Meyer e voi? quale approccio di sviluppo preferite?

*Carlo*