Si dice sempre che i web designer non hanno mai il tempo di lavorare sul proprio sito ed effettivamente è proprio così. Tuttavia, anche se nelle ore del giorno sono tutt’ora impegnato a tempo pieno in un progetto che andrà online nelle prossime settimane (e che non vedo l’ora di svelare), ho deciso di investire buona parte dell’ultimo week-end e le ultime due sere proprio nel rinnovare il sito di Kultmedia. L’ultima versione del sito era datata febbraio 2011 e c’era quindi bisogno di una “rinfrescata” generale.

Sono quindi lieto di presentare il nuovo sito di Kultmedia.

So cosa alcuni di voi stanno pensando: è uguale a quello vecchio. A prima vista in effetti potrebbe sembrare così, anche perché ho deciso di mantenere la stessa impostazione che tutt’ora mi piace. Ma sotto la superficie le novità sono parecchie e, a mio avviso, interessanti.

Ecco alcune delle novità:

• Layout responsive
  Sono ormai due anni che si parla di responsive web e ho deciso di muovere anch’io i miei primi passi in questa direzione. D’altronde quale migliore cavia se non se stessi? In questo modo ho potuto eliminare la diversificazione che avevo fatto in precedenza tra versione mobile e versione desktop. Il layout è uno solo, ma si adatta magnificamente alla risoluzione, come vi descriverò meglio tra poco.
• Utilizzo di @font-face
  Uno dei miei obiettivi prima di partire con questo restyling era questo: usare il meno possibile le immagini. Sicuramente uno dei primi modi per raggiungere questo risultato è stato evitare di creare titoli o elementi di menu servendomi di immagini, come nel sito precedente. Normalmente mi servo di strumenti come Cufon o delle validissime Google Web Fonts Api ma questa volta ho deciso di appoggiarmi interamente alla proprietà @font-face introdotta con CSS3, senza dover rinunciare ai miei font preferiti.
• Animazioni CSS3
  Qualcosa era già presente nel sito vecchio, ma qui l’utilizzo è decisamente più rilevante. L’effetto mouse-over sugli elementi del portfolio è gestito unicamente da CSS3, non ho utilizzato jQuery come avrei normalmente fatto in questi casi. Anche le animazioni di fade-in delle immagini (come ad esempio quella nella sezione chi siamo) sono gestite in questo modo. Magari un giorno queste cose funzioneranno anche in Firefox, io non smetto mai di crederci! ;)
• Url “SEO friendly”
  Ho deciso di impostare gli URL in modo che siano più puliti, e di non mostrare l’estensione dei file caricati. La sezione servizi, ad esempio, ora si presenta con un URL di questo tipo: www.kultmedia.com/servizi
  Niente di esagerato, semplicemente un piccolo lavoro di mod_rewrite nella configurazione del server Apache.
• Utilizzo di immagini SVG
  Dato che i nuovi dispositivi utilizzati per la navigazione web hanno definizioni mai viste prima, ho cominciato a fare i miei primi esperimenti con grafica vettoriale sul web. In alcune zone del sito ho quindi utilizzato immagini vettoriali in formato SVG e mi sono servito di Canvg per il rendering e per il parsing delle stesse. 

L’aspetto su cui vale la pena approfondire ulteriormente è quello del responsive design. Per l’impostazione di base mi sono servito di un ottimo framework CSS chiamato Skeleton. I motivi per cui reputo ottimo questo framework è che, pur essendo molto semplice e leggero, ci permette di lavorare su una griglia già ottimizzata per un design di tipo responsive e inoltre si serve di una sintassi molto semplice e facile da ricordare.

Attraverso l’utilizzo delle Media Queries ho potuto ottimizzare il mio CSS in modo che alcuni elementi si comportino in modo differente a seconda della risoluzione. Un esempio pratico: dato che nell’iPad non esiste il concetto di mouse over (non essendoci un mouse) ho fatto in modo che quel tipo di effetto sugli elementi del portfolio sia presente solo nelle risoluzioni “desktop”. Basta rimpicciolire la finestra del browser per notare subito questo comportamento.

Per testare il lavoro, man mano che procedevo, mi sono servito di due interessanti strumenti:

• Windows resizer
  Estensione per Google Chrome scaricabile qui che permette di ridimensionare la finestra del browser alle risoluzioni che desideriamo. Sono inoltre già presenti dei preset con le risoluzioni più comuni.
• Responsinator
  Un tool online che ci permette di vedere come si comporta il nostro design alle risoluzioni dei dispositivi più comuni. Ecco ad esempio la mia pagina di test: Kultmedia su Responsinator.

Naturalmente ho anche effettuato dei test sui dispositivi “veri”, in particolare su iPhone e iPad.

Screenshot da iPhone:

Screenshot da iPad

Per concludere, un paio di dettagli aggiuntivi:

• Per quanto riguarda il CMS ho naturalmente utilizzato Kult CMS, il CMS cloud da me realizzato e lanciato al pubblico a fine 2011. Attraverso il CMS posso gestire interamente tutti i contenuti presenti nel sito e generare automaticamente i feed RSS del portfolio e delle news.
• La validazione dei campi nella pagina contatti è gestita con jQuery, che è tutt’ora il sistema che preferisco per questo genere di controlli. 

Spero che il nuovo sito vi piaccia, se volete darmi del feedback potete farlo attraverso il form dei contatti oppure via Twitter: @ilkose.

Un saluto e grazie per la vostra visita!

Chi come me si occupa di sviluppo web saprà per certo che qualsiasi progetto, per quanto semplice, è composto da un abbondante numero di compiti, o tasks per dirla all’inglese, che vanno completati per raggiungere il nostro obiettivo.

Suddividere un progetto in task è utile per diversi motivi: oltre ad aiutarci a non tralasciare niente, infatti, serve anche a ridurre lo stress derivante dalla visione del progetto nell’insieme, specialmente quando si è all’inizio. Il frazionamento in tanti task ci aiuta a concentrarci sul singolo aspetto su cui stiamo lavorando senza percepire il peso del progetto e allo stesso tempo procedere con sicurezza fino al completamento dello stesso. Penso che molti saranno d’accordo con me sul fatto che “depennare” un compito da una lista sia appagante da un punto di vista psicologico e può aiutarci a mantenere alta la motivazione perché ci fa percepire i progressi che stiamo facendo.

A proposito di “depennare”: per anni la mia to-do list è stata gestita nel modo più classico possibile: carta e penna o, per un breve periodo, una lavagna. Questa soluzione però non era granchè  e spesso mi è capitato addirittura di perdere alcuni appunti o comunque in generale di trovarmi sommerso dal disordine… Così ho deciso, un paio di anni fa, di passare ad una soluzione più professionale.

La mia prima scelta cade su Things, applicazione per MacOs prodotta dalla Cultured Code, una software house tedesca.

Il costo dell’applicazione per Mac non è proprio bassissimo, al momento costa € 39,99 (e se non ricordo male al tempo costava anche di più), però il prodotto è davvero ben fatto e le opinioni raccolte sono ottime, così decido di procedere. Things ha anche un’applicazione per iPhone (€ 7,99) e dopo qualche mese, era il 2010, esce anche l’applicazione per iPad (€ 15,99). Naturalmente ho scaricato anche queste app, anche se i prezzi erano decisamente alti rispetto allo standard. Per più di un anno gestisco il mio lavoro con Things e tutto sommato mi trovo bene. L’unica cosa che proprio non mi piace è che il sync tra i dispositivi (Mac, iPhone e iPad) si può fare solo via Wi-fi. Questo per me è un grosso limite perché non mi ricordavo mai di fare il sync e spesso mi sono ritrovato fuori dall’ufficio con i task non sincronizzati sui miei dispositivi mobile. Leggo però sul loro blog che stanno lavorando per un “sync over the air” e quindi decido di dargli fiducia e attendere che questa feature venga rilasciata.

Purtroppo però questo non succede, anche dopo diversi mesi. Per la cronaca, la prima volta che parlarono di questa funzionalità era a metà del 2010 e la public beta è stata rilasciata solo a Febbraio del 2012, quindi sostanzialmente ci sono stati quasi due anni di sviluppo e ancora non c’è stato un rilascio ufficiale. Le motivazioni di tutta questa attesa, fornite attraverso il blog, sembrano (a mio avviso, ma non solo) piuttosto assurde, soprattutto visto e considerato che loro una soluzione di sync la offrono già e si tratta solo di farla diventare cloud.

In tutto questo tempo la mia pazienza si esaurisce e così, a Luglio del 2011, decido di abbandonare definitivamente Things e passare a Wunderlist.

Wunderlist, neanche a farlo apposta, è sviluppato anch’esso da una software house tedesca, la 6Wunderkinder. La prima cosa che mi stupisce è il costo: il software è FREE su tutte le piattaforme (Mac, iPhone e iPad). Non male, considerando che per avere una situazione simile con Things avevo dovuto spendere circa € 65,00.

Inoltre l’applicazione sembra ben curata, sia nel design che nelle funzionalità e, a differenza di Things, esiste una web app, quindi è possibile consultare i task attraverso il browser. Le informazioni, essendo sincronizzate con un server web, sono aggiornate in real time su tutti i dispositivi. Pur non essendo sicuramente al livello di Things, che in quanto a cura dei dettagli resta secondo me imbattibile, decido che queste funzionalità per me valgono il cambio di software e così per diversi mesi porto a termine i miei task con Wunderlist.

Dopo alcuni mesi (Gennaio 2012) la 6Wunderkinder, la società berlinese che produce Wunderlist, annuncia un nuovo prodotto chiamato Wunderkit. Sostanzialmente si tratta di una versione “potenziata” di Wunderlist, tant’è che inizialmente trovo bizzarra la scelta di mantenere entrambi i prodotti. L’idea è però quella di rilasciare Wunderkit come servizio a pagamento, quindi da questo punto di vista la scelta potrebbe avere un senso.

Le differenze fondamentali sono le seguenti:

• Wunderkit è una app collaborativa. Non serve quindi solo a gestire i task di una singola persona ma è pensata per i team, con tanto di possibilità di assegnare i task ad altri componenti del nostro gruppo di lavoro, condividere con loro note, aggiornamenti di stato ecc.
• L’app presente molti aspetti social: è possibile seguire utenti, seguire dei workspaces (che possono essere pubblici o privati), commentare ecc.
• Essendo stato introdotto il concetto di workspaces (che possono essere intesi come i vari progetti) esiste un livello ulteriore di suddivisione dei task.
  Ad esempio nel progetto Sito Abc posso suddividere i miei task in varie categorie, as esempio layout, back-end, front-end e seo ottenendo quindi una maggiore organizzazione.

Dato che queste nuove funzionalità coincidono con alcune mie esigenze e che dispongo di un invito alla versione beta decido di provare Wunderkit. Purtroppo non c’è la possibilità di migrare i task da Wunderlist a Wunderkit (trattandosi di prodotti provenienti dalla stessa software house mi sarei aspettato una funzionalità di questo tipo) quindi faccio un lavoro manuale di re-inserimento dei task nel nuovo software.

Dopo l’entusiasmo iniziale comincio ad evidenziare alcuni problemi:

• L’applicazione per Mac non è una vera e propria app, ma quello in gergo si chiama wrapper, ovvero un “contenitore” della web app. Il che non sarebbe comunque male, se non fosse per i numerosi bug, e qui passo al punto 2.
• Ci sono davvero troppi bug. È vero, stiamo parlando di un software in versione BETA, ma a volte si verificano delle cose molto spiacevoli: workspaces che spariscono (fortunatamente solo temporaneamente), note che spariscono, necessità di riavviare l’app e addirittura l’impossibilità di avviare l’app. Spesso questi problemi sono dovuti a problemi del server e lo staff di 6Wunderkinder è molto reattivo nel rispondere e nel comunicare via Twitter eventuali malfunzionamenti. Rimane comunque il problema che a volte ci è sembrato di perdere irrimediabilmente i nostri task e questa non è mai una sensazione piacevole.
• Nonostante la cura nel design, a mio avviso c’è qualcosa di sbagliato proprio nel modo in cui è stata progettata l’interfaccia. In questo tipo di applicazioni la cosa più importante è il “focus” ovvero la possibilità di concentrarsi su un task in particolare e dimenticarsi di tutto il resto, eliminando quindi le distrazioni. L’interfaccia di Wunderkit invece non sembra focalizzata sui task ma sui vari aspetti social e più volte ho avuto la sensazione di non capire dove mi trovavo. Altre volte mi è capitato di scrivere un aggiornamento di stato pensando di scrivere un task. Inoltre la gestione dei contenuti pubblici e privati non è chiarissima e più di una volta mi è rimasto il dubbio su cosa fosse pubblico e cosa fosse privato.
• Pur esistendo una versione nativa per iPhone (davvero ottima) non esiste al momento una versione nativa per iPad.

Procedo comunque con Wunderkit, che nel frattempo annuncia, a metà Febbraio, che il prodotto sarà reso free per tutti, a differenza di quanto previsto in partenza.

Poi un giorno mi imbatto in questo ottimo articolo scritto da Ryan Carson, il fondatore e CEO di Treehouse. L’articolo fondamentalmente parla di come lui gestisce la propria giornata ed è una vera e propria fonte di ispirazione. Alcune cose sono per me assolutamente impensabili (ad esempio la sveglia alle 4:54 AM) mentre rimango molto incuriosito dal software da lui utilizzato per la gestione dei todos: Asana.

Dopo aver visitato il sito ufficiale www.asana.com scopro subito una cosa interessante: dietro ad Asana c’è Dustin Moskovitz che, come saprà chi conosce un po’ la storia di Facebook, (ma anche chi ha semplicemente visto il film “The social network”) è uno dei co-fondatori di Facebook, probabilmente il più influente da un punto di vista tecnico. Moskovitz non fa più parte del team di Facebook da alcuni anni e questa è la sua nuova creatura, uno strumento che ha l’obiettivo di semplificare il task management per i team.

Asana mi conquista subito. Anche in questo caso, come in Wunderkit, il punto centrale è la web app. La cosa però che balza subito all’occhio è come l’interfaccia, estremamente minimale, sia pensata in modo che i task siano al centro di tutto. La modalità di immissione dei task è la cosa che più mi piace: attraverso le combinazioni di tastiera (che sono riassunte anche nella parte bassa dell’interfaccia) è possibile fare tutto quello che ci serve, senza dover utilizzare il mouse. Sembrerà banale ma questo è un vantaggio enorme in termini di velocità di utilizzo. 

Ecco brevemente le altre funzionalità:

• Possibilità di contrassegnare un task come today, upcoming o later
• Possibilità di assegnare un task a se stessi oppure ad un compagno di team (ovvero un’altra persona che è stata inclusa nel progetto)
• Tags: questa è una delle funzionalità più interessanti. Possiamo creare dei tag personalizzati e poi assegnarli ai task. Il grosso vantaggio è che un singolo task può avere più tag. Inoltre i tag possono essere pubblici (quindi visti anche dai nostri compagni di team) oppure privati (visti soltanto da noi)
• Possibilità di modificare più task contemporaneamente. Questa è una funzionalità ottima che non ho mai trovato nei software provati in precedenza.
• Possibilità di ordinare i task in base a priorità.
• Schermata My Tasks:questo è esattamente quello che intendevo quando parlavo di focus. Qui vediamo solo i task che abbiamo contrassegnato come today o come upcoming. In questo modo non siamo costretti a visualizzare la valanga di task che ci aspettano e possiamo concentrarci sul lavoro che dobbiamo svolgere oggi.
• Email quotidiana riassuntiva dei task da svolgere oggi. Purtroppo non è possibile scegliere l’ora dell’invio della mail e la mail viene inviata per quella che è la mattina presto nella west coast americana, ma è già quasi pomeriggio per noi. È probabile comunque che questa funzionalità verrà introdotta in seguito.

Personalmente mi sento di raccomandare Asana, oltre che per i motivi sopra elencati, per questi motivi:

• Non ho riscontrato alcun malfunzionamento o bug, fin’ora tutto ha funzionato alla perfezione.
• Il team di sviluppo è molto veloce nel rilasciare nuove feature e ho potuto personalmente riscontrare l’introduzione di nuove funzionalità, che trattandosi di una web app sono comparse automaticamente.
• Citando una frase dal post di Ryan Carson: la società che sta dietro ad Asana ha recentemente ricevuto un finanziamento di circa 9 milioni di dollari. C’è da credere quindi che non si tratti di un servizio che potrebbe chiudere da un momento all’altro e questo dovrebbe darci un’ulteriore sicurezza nel riporre lì le nostre informazioni.

Concludo questo post con l’ottimo video di introduzione ad Asana, buona visione!

Alcuni giorni fa mi sono ritrovato, per un progetto sul quale sto lavorando, ad avere la seguente esigenza: assicurarmi che l’utente, utilizzatore di alcune funzionalità di una webapp, abbia Javascript abilitato.

Perchè un utente dovrebbe aver disabilitato Javascript?
Bella domanda. Effettivamente disabilitarlo non porta nessuna utilità, anzi, rende buona parte del web inutilizzabile. Insomma, non è come disabilitare Flash, lì ci sono diversi vantaggi (performance del browser tanto per dirne uno) ma qui sinceramente non ne vedo.
Detto questo, il fatto che sia poco sensato non significa che un utente non possa farlo. Disabilitare Javascript è una cosa che chiunque può fare e se il nostro sistema non prevede questa eventualità potrebbero esserci dei risultati inaspettati.

Come quasi sempre accade quando mi trovo di fronte a questi dilemmi, cerco sul web e vado a caccia di informazioni. Leggendo nei vari forum e siti specializzati vedo che gli approcci a questo tipo di problema sono i seguenti:

Utilizzare il tag noscript
Tutto quello che noi scriviamo all’interno di noscript viene mostrato solo agli utenti con Javascript disabilitato, gli altri non vedono nulla.

VANTAGGI
Nessun accorgimento particolare da parte nostra: il tag noscript è supportato praticamente da sempre in tutti i browser.

SVANTAGGI
Questa soluzione è ottima per chi vuole mostrare un avviso a chi non ha Javascript. Non va invece bene per chi vuole impedire a chi non ha Javascript di eseguire determinate azioni e visualizzare alcuni contenuti.

Rilevare il browser dell’utente con uno script server side
Rilevando il browser utilizzato possiamo capire se è un browser che supporta Javascript oppure no ed eseguiredel codice in base a questa informazione.

VANTAGGI
È una soluzione relativamente semplice da implementare.

SVANTAGGI
Questo risolve il nostro problema solo in parte: in questo modo possiamo infatti capire se la versione del browser supporta Javascript (quindi fondamentalmente se non è un browser obsoleto) ma non se Javascript è attivo.

Strutturare la nostra webapp in modo che Javascript non sia essenziale
Questa è sicuramente la soluzione migliore ed è quella suggerita dai “perfezionisti”. Se strutturiamola nostra webapp in modo che Javascript serva solo a migliorare la funzionalità ma non sia determinante, possiamo realizzare un prodotto solido e compatibile con tutti. Questa è ad esempio la soluzione che adotta Facebook: se provate ad entrare senza Javascript troverete molte cose diverse (una di quelle che salta all’occhio è il pulsante “invia” sui commenti, che di solito non c’è). Tuttavia la funzionalità globale è inattaccata. Insomma, è tutto meno bello, ma comunque funziona.

VANTAGGI
È la soluzione più sicura e possiamo utilizzare degli script lato server come “backup” nel caso gli script lato client (Javascript appunto) non funzionino.

SVANTAGGI
Non sempre è possibile: se la nostra webapp è fortemente incentrata su Javascript è probabilmente meglio impedire l’utilizzo a chi non ha Javascript piuttosto che fornire una funzionalità zoppicante. Inoltre questa soluzione richiede molto lavoro in più. Si pensi ad esempio ad uno script di validazione di un form: dovremmo fare in modo che ad ogni validazione effettuata con Javascript corrisponda anche una validazione fatta con PHP (o ASP ecc.) nel caso la validazione con Javascript non funzionasse.

La mia soluzione
Dopo aver analizzato le possibilità ho deciso di procedere con una soluzione differente realizzando un mio script. L’approccio dello script è il seguente:

• Utilizzare Javascript per creare qualcosa che sia rilevabile lato server
• Utilizzare PHP per verificare la presenza di questo elemento. Se non è presente significa che Javascript non è stato in grado di generarlo e quindi che presumibilmente è disabilitato

Dopo aver riflettuto su cosa potessi creare con Javascript che potesse essere rilevato lato server ho pensato a queste due soluzioni:

• Creare un cookie con Javascript e poi utilizzare PHP per verificarne la presenza.

• Modificare il valore di un campo hidden in un form e verificare con PHP se questo valore corrisponde.

Dato che nel mio caso specifico avrei fatto questa verifica dopo l’invio di un form, ho deciso di utilizzare la seconda soluzione.

Come funziona?
All’interno del form ho aggiunto un campo hidden in questo modo:

Ora ci serviremo di jQuery per modificare il valore di questo campo.

Prima di tutto includiamo jQuery:

Dopodichè utilizziamo jQuery per scrivere il valore “yes” all’interno del nostro campo hidden:

In questo modo avremo, nella pagina di destinazione del form, una variabile POST chiamata “jscheck” che conterrà il valore “yes” solo se Javascript è stato in grado di scrivere questo valore prima dell’invio.

A questo punto possiamo eseguire del codice diverso a seconda dei due casi (Javascript attivato e Javascript disattivato).

Ecco un esempio in PHP:

Per chi volesse vedere e scaricare una versione completa e funzionante dello script, ho creato una versione liberamente scaricabile chiamata Jscheck. Ecco i link utili:

• Live Demo
• Download dello script (Github)

Questo post si riallaccia ad un mio post di qualche mese fa, in cui spiegavo come ero riuscito ad inserire alcune stazioni radio italiane su iTunes e linkavo un ottimo sito che spiegava la procedura da seguire.

Quel sistema per me ha funzionato benissimo fino a ieri, poi stamattina improvvisamente la sorpresa: un messaggio di errore mi informava che non era possibile riprodurre il file e che quindi non potevo più ascoltare Radio Deejay all’interno di iTunes. Molto probabilmente il tutto è stato causato da un aggiornamento di Mac Os X Lion scaricato stanotte.

Ho deciso così di trovare un’altra soluzione e dopo un po’ di test vari sono riuscito a far funzionare di nuovo tutto. Di seguito descriverò la procedura che ho seguito, dato che molto probabilmente tornerà utile a qualcuno. A conti fatti credo che questi step siano anche più semplici di quelli da seguire col sistema “vecchio” e soprattutto questa volta non c’è nessun file da scaricare.

Cercherò di spiegare il tutto nel modo più semplice possibile, utilizzando anche con un po’ di screenshots.

Pronti? Si parte!

La prima cosa da fare è creare una nuova Playlist di iTunes.

In basso a sinistra nell’interfaccia di iTunes sono visualizzate tutte le Playlist già presenti.

Non dobbiamo fare altro che cliccare  sul pulsante “+” che serve appunto per creare una nuova Playlist. Dopo averla creata possiamo rinominarla a nostro piacimento, io l’ho chiamata Radio Deejay:

Adesso bisogna andare nell’elenco delle stazioni radio di iTunes, che è nella parte superiore della sidebar di sinistra. Clicchiamo su Radio e ci si aprirà un elenco di generi musicali che, a loro volta, contengono tutte le stazioni radio.

Scegliamo un genere musicale, apriamolo e scegliamo una stazione radio casuale. Sì, avete capito bene, potete sceglierne una qualsiasi e tra poco capirete perchè.

Io ho scelto di utilizzare JAZZRADIO.com che tra l’altro è una stazione niente male.

Ora viene la parte divertente: dopo aver scelto la stazione radio dobbiamo semplicemente trascinarla sopra alla playlist che abbiamo creato poco fa (nel mio caso la Playlist Radio Deejay). In questo modo abbiamo inserito questa stazione radio nella nostra Playlist.

Adesso torniamo a selezionare la nostra Playlist e dovremmo trovare al suo interno la stazione che abbiamo scelto. Facciamo tasto destro (o ctrl+click) sul nome della stazione e clicchiamo su Informazioni.

Al nostro click si aprirà una schermata simile alla seguente:

Qui dobbiamo cliccare su Modifica URL e otteremmo una schermata con dentro un lungo indirizzo web. Dobbiamo semplicemente copia/incollare al posto di quell’indirizzo il seguente:

http://mp3.kataweb.it:8000/RadioDeejay

Il risultato quindi deve essere questo:

Ora clicchiamo OK sia su questa finestra che su quella aperta in precedenza e facciamo Play sulla nostra stazione radio. Partirà Radio Deejay e automaticamente il nome della stazione radio si aggionerà.

Ora potete godervi nuovamente la vostra radio preferita su iTunes :)

Alcuni dettagli: questa procedura è stata testata con Mac Os X Lion 10.7.3 e iTunes 10.5.3. ma credo che funzioni senza problemi anche con altre versioni.

Se volete darmi del feedback su questa procedura potete farlo su Twitter, il mio username è @ilkose 

Diverso tempo fa un cliente mi ha chiesto di implementare, se possibile, la seguente funzionalità: mostrare gli ultimi feedback eBay ricevuti, in un box all’interno del proprio sito. Fino a quel momento era presente un link che rimandava alla pagina originale dei feedback su eBay, ma si voleva saltare questo step e mostrare direttamente i commenti. La cosa naturalmente doveva avvenire in modo automatico, niente copia/incolla per capirci.

Pensando che una cosa del genere fosse già prevista, vado alla ricerca di un widget o qualcosa del genere, più o meno come fanno Twitter o Facebook, tanto per citarne due. Scopro invece, con una certa sorpresa, che eBay non prevede nulla di tutto questo. Non solo non offre widgets per i feedback, ma non esiste neanche un feed RSS per estrarre queste informazioni in modo “pulito”.

Parte quindi la mia consueta ricerca per il web, per vedere se qualche sito o servizio esterno ha la soluzione che fa per me. Purtroppo però non trovo niente di interessante. Esistono diverse soluzioni per mostrare le inserzioni ma, a quanto pare, dei feedback non si è occupato nessuno. In realtà a dire la verità qualcuno se n’è occupato (loro) ma quello che viene mostrato è solo il numero di feedback, mentre a me serve la lista dei commenti.

Alla fine decido di fare da me e di sviluppare lo script in PHP. In qualche ora ottengo il risultato desiderato, metto online e la missione è compiuta.

Nei mesi successivi diverse persone mi chiedono come possono fare a ricreare qualcosa del genere. Mi rendo conto quindi che tutto sommato questa esigenza non era così strana e che in molti hanno bisogno di un box come quello. 

Da qui quindi la decisione di ottimizzare lo script in modo che sia personalizzabile e di rilasciarlo gratuitamente con licenza open source. A questo punto serve solo un nome: decido di chiamarlo Feedbackbox (sì lo so, non ho esagerato con la fantasia) e per condividere il codice sorgente decido di utilizzare l’ottimo GitHub.

Per chi volesse utilizzare Feedbackbox ecco i due link fondamentali:

• Live Demo
• Download (GitHub)

 <? 
 include "feedbackbox.php"; 
 feedbackbox("kultmedia", "10"); 
 ?> 

Nell’esempio riportato qua sopra kultmedia non è altro che lo username eBay, mentre 10 è il numero di commenti mostrati, che possiamo modificare a piacimento.

Lo script permette inoltre una completa personalizzazione dell’output, attraverso CSS.

Ecco le classi modificabili:

ul.feedbackboxlist  (elenco dei commenti)

ul.feedbackboxlist li (singolo commento)

ul.feedbackboxlist li a.username (nome utente / link)

ul.feedbackboxlist li span.text (testo del commento)

Nel file example.php incluso nello zip scaricabile da GitHub troverete comunque un esempio già funzionante che potrete prendere come riferimento.

Qualche giorno fa mi sono ritrovato di fronte alla seguente esigenza: cercare un mio tweet risalente ad agosto del 2011. Per la precisione si trattava di un tweet inviato di fronte alla sede di Twitter, nella splendida San Francisco. Recitava “Tweeting from Twitter”, una cosa molto inception ora che ci penso. “Facile”, ho pensato, “sono passati solo 4 mesi, lo troverò in un attimo”. 

Come sempre, la prima soluzione che adotto è quella ufficiale, in questo caso Twitter advanced search. Trovo però subito due ostacoli: 

• Nei vari parametri di ricerca non c’è modo di specificare un range di date
• Anche cercando per parole chiave, la ricerca sembra andare indietro solo di poche settimane, quindi non abbastanza per il mio obiettivo

Probabilmente questa, più che una falla, è una scelta fatta per limitare il carico sui loro server e posso capirne le motivazioni.

Decido quindi di trovare un’alternativa: le API di Twitter sono tra le più aperte in assoluto, quindi sono abbastanza fiducioso nel trovare un servizio che mi permetterá di raggiungere il mio scopo.

Dopo aver dato un’occhiata ai miei bookmarks su Pinboard mi viene in mente che in realtà avevo già fatto qualcosa del genere utilizzando il servizio Searchtweetsbydate. Peccato però che nel frattempo il servizio è stato chiuso e non trovo neanche spiegazioni sul motivo, dato che il dominio risulta del tutto abbandonato. Stessa identica sorte anche per Searchtastic.

Proseguo la ricerca e vedo che molti parlano di Topsy. Gli dò una possibilità ma vedo che la ricerca si comporta piuttosto male e trova dei Tweet con una logica che non ho ben capito ma che mi dà l’impressione di essere casuale.

Teoricamente a questo punto mi sarei dovuto arrendere, se non fosse che ormai è diventata una questione di principio e che non mi interessa neanche più tanto trovare quel tweet specifico (nel frattempo ho anche dimenticato perchè mi serviva…) ma capire com’è possibile che io non possa avere un archivio facilmente consultabile dei miei tweet. Sono miei d’altronde, per la maggior parte sono cose poco interessanti, ma sono i miei tweet… :)

La ricerca così continua e mi imbatto in due soluzioni a pagamento (o quasi):

Twistory

L’idea è interessante: sostanzialmente permette di effettuare un’integrazione tra i tweet e il proprio calendario. Attraverso questo servizio, quindi, un utente può avere i propri tweet all’interno di iCal (o simili) in modo ordinato. Non male, però la versione gratuita permette di andare indietro nel tempo solo di un mese. La versione a pagamento teoricamente non ha limiti (in realtà c’è un limite anche qui di 3200 tweet ma pare che questo sia imposto dalle API di Twitter).

Backup my tweets

Permette di archiviare i propri tweet per avere una consultazione più rapida e funzionale. Il servizio è a pagamento, ma il pagamento è barattabile con un tweet promozionale che viene inviato direttamente dal servizio dopo aver fatto il login via Twitter (attraverso OAuth).

Queste due opzioni sono piuttosto abbordabili (anche perchè i costi sono minimi), ma rimango dell’idea che per questo tipo di servizio ci deve essere una soluzione gratuita.

E così, analogamente a quanto successo quando dovevo realizzare il mio url shortener, decido di cercare una soluzione self-hosted e faccio una ricerca sul buon vecchio GitHub.

Qui mi imbatto in Tweet Nest, una app PHP che promette subito bene e con un ottimo sito di presentazione.

Scarico quindi la sorgente e installo sul mio server. L’installazione è molto semplice, gli step fondamentali sono i seguenti:

• Creare un database (nel mio caso MySql ma l’app supporta praticamente tutti i tipi di database)
• Uploadare i file via FTP
• Modificare i permessi di alcuni file in modo che abbiano l’accesso in scrittura
• Creare dei file htaccess che serviranno perchè possa funzionare il mod_rewrite e per la protezione di alcune cartelle
• Lanciare la pagina di setup che, passo dopo passo, ci porterá alla fine dell’installazione

Finita l’installazione rimane solo una cosa da fare: lanciare le pagine di aggiornamento che permettono all’app di sincronizzare i tweet e i dettagli dell’utente. Queste pagine sono, per motivi di sicurezza, protette da password (che abbiamo impostato in fase di installazione).

Questa sincronizzazione sarebbe da eseguire periodicamente e per ottenere questo risultato possiamo anche impostare un Crontab con una frequenza da noi stabilita, in modo da non doversi più preoccupare delle pagine di aggiornamento.

Il risultato è davvero ottimo: l’interfaccia è semplice e ben fatta, con qualche richiamo allo stile grafico di Twitter. Sulla colonna di destra è visualizzato l’archivio mensile e la ricerca ci permette di trovare i nostri tweet alla velocità della luce. Inoltre, volendo, è anche possibile personalizzare l’aspetto grafico nei minimi dettagli. Trattandosi di una soluzione self-hosted, tutte le informazioni sono memorizzate nel nostro database e questo è un vantaggio non indifferente.

In conclusione, ecco la pagina del mio archivio di tweets. Ho scelto di renderla pubblica ma volendo è anche possibile proteggerla da password, trattandosi di uno script interamente open source.

Dato che il titolo del post potrebbe lasciare spazio a strane interpretazioni, chiarisco subito: non sto pensando di mollare tutto per trasferirmi in un’isoletta nei Caraibi… :)

Parlo invece dell’omonima azienda italiana di Web Hosting, come penso si potesse dedurre, considerando il tipo di contenuti di questo blog.

Faccio anche un’altra premessa: questo post non ha intenti diffamatori, voglio solo raccontare una mia recente esperienza, che purtroppo è piuttosto negativa. Tutto quello che sto per raccontare è dimostrabile, lo dico nel caso qualche rappresentante dell’azienda dovesse passare da queste parti (anche se ne dubito) e fare il “permaloso”.

Bene, detto questo possiamo cominciare, anche perché avevo promesso di diventare più sintetico.

Partiamo dal 2003 (alla faccia della sintesi). Io ero un aspirante Web Designer e cominciavo a fare i primi esperimenti sul Web. Fino a quel momento, quando dovevo pubblicare qualcosa online, mi affidavo a quei servizi di hosting gratuito che ti permettevano di avere un po’ di spazio web in cambio di qualche banner pubblicitario. C’erano ad esempio Altervista, Digilander e altri di cui adesso non ricordo il nome.

Un giorno però arriva inevitabilmente il momento in cui ho bisogno di un dominio vero e di un hosting e così, basandomi sul “fattore popolarità”, mi ritrovo ad acquistare il primo dominio + hosting su Aruba.

A parte le procedure d’ordine un po’ complesse e a volte illogiche (come ad esempio l’illusione di poterti scegliere uno username e password personali, quando poi in realtà dovrai per sempre utilizzare un lunghissimo username numerico e una password impossibile da ricordare) il servizio non mi sembra male e quindi decido che quello sarà il mio hosting di riferimento.

Da quel giorno ho portato circa una trentina di miei clienti su Aruba. Non sono tantissimi, certo, però facendo un rapido calcolo sono circa € 1200 (facendo una media di 40 euro a servizio) che Aruba fattura annualmente grazie a me e al fatto che i miei clienti si sono affidati a me per la scelta dell’hosting. Tutto questo senza che io ci guadagnassi niente dato che Aruba non offre un programma di affiliazione per chi rivende i loro servizi.

In linea di massima tutto funzionava, più o meno bene, quindi il mio riferimento è rimasto invariato per diversi anni.

Col tempo però il mio livello di soddisfazione scendeva gradualmente. Un po’ perché aumentavano le mie esigenze (i progetti web su cui lavoravo cominciavano ad avere dei volumi di traffico grandi e io avevo bisogno di strutture tecniche differenti) e un po’ perché, secondo il mio modestissimo parere, il loro servizio col tempo è peggiorato in vari aspetti. Inutile che io vi ricordi degli outage recenti, di cui uno abbastanza clamoroso, in cui sono stati coinvolti migliaia di utenti.

Pian piano quindi ho cominciato a spostare un po’ di siti altrove e a registrare i nuovi domini e servizi presso altre società, di cui non farò il nome altrimenti questo post potrebbe sembrare promozionale (ma se proprio volete saperlo contattatemi in privato).

Ed è proprio mentre stavo facendo una di queste operazioni di spostamento che mi è capitata questa vicenda assurda che voglio condividere con voi.

Ecco lo scenario:

dominio .com (senza hosting) registrato presso Aruba e in stato Transfer Lock, da trasferire verso un altro provider italiano.

Faccio quindi il mio ordine sul nuovo provider il quale, giustamente, mi chiede l’Auth Code del dominio. Vado nel mio pannello di controllo su Aruba per effettuare lo sblocco e recuperare queste informazioni. Ma un messaggio di errore mi informa che l’operazione è impossibile e che devo contattare l’assistenza. Qui comincia il mio calvario… Dato che conosco già le risposte che si ottengono telefonicamente, passo direttamente all’apertura del seguente ticket:

01/12/2011 11:10

Buongiorno, ho la necessità di trasferire il dominio in oggetto verso un altro provider. Ho provato a seguire la procedura di sblocco attraverso l’apposito tool presente nel pannello di amministrazione ma ottengo un errore e mi viene detto di utilizzare l’assistenza. Vorrei quindi sapere come procedere per sbloccare il dominio e ottenere l’auth-code. Grazie e saluti.

Attendo qualche giorno ma nessuno mi degna di una risposta. Così ci riprovo, cercando di dosare il più possibile il tono polemico. In fondo sono passati “solo” 4 giorni:

05/12/2011 15:07

Giusto per capire, avete intenzione di rispondere prima o poi al ticket o avete intrapreso la strada dell’indifferenza?

Anche qui non succede assolutamente niente per diversi giorni e intanto io devo cercare di spiegare al mio cliente cosa sta succedendo. Finalmente dopo ben 11 giorni dall’apertura del ticket ricevo la seguente risposta:

12/12/2011 12:19

Gentile cliente,

abbiamo provveduto ad inviarle

L’Authorization Code come da lei richiesto.

rimaniamo a disposizione

Distinti saluti.

E contemporaneamente ricevo anche la seguente e-mail:

Gentile cliente,

come da Sua richiesta pervenuta in data 12/12/2011 riportiamo di

seguito l’Authorization Code necessario al trasferimento del dominio in oggetto

(segue l’auth code)

Sì avete letto bene, la mail parla di una richiesta pervenuta in data 12 dicembre. Peccato che la mia richiesta era stata fatta il 1 dicembre…

Alla fine sono finalmente riuscito ad avviare la procedura di trasferimento ma non si può certo dire che sia stata un’operazione indolore.

In conclusione il mio consiglio è il seguente:

andate altrove se potete, un fornitore di servizi internet con un supporto tecnico che impiega quasi due settimane per rispondere (tra l’altro per un problema causato da loro stessi, senza il quale non avrei avuto bisogno dell’assistenza) non è un fornitore serio, credo che su questo punto non si possa neanche discutere. Neanche il fatto di essere low cost è una scusa che regge, visto che ho trovato dei provider con costi molto simili e con un supporto tecnico impeccabile.

Sappiate però che anche andarsene non è facile, quello che mi è successo ne è la prova, quindi armatevi di pazienza. Quando sarete riusciti a portare il tutto da un’altra parte potrete finalmente tirare un sospiro di sollievo, come sto facendo io ora! :)

Quella che fino a settimana scorsa era solo una notizia non confermata (o un rumor per dirlo all’americana) è stata ufficializzata attraverso un post sul blog ufficiale: Facebook ha comprato Gowalla.

Per chi non lo conoscesse, Gowalla è un servizio location-based che fu lanciato nel 2009, quando ancora i servizi basati sulla propria posizione geografica non erano una cosa così scontata, anzi, erano un mondo quasi inesplorato. Curiosamente anche quello che sarebbe poi diventato il suo grande rivale, Foursquare, fu lanciato lo stesso giorno, in occasione del SXSW del 2009.

Da lì fu quindi chiaro a tutti che la sfida era aperta tra queste due società. Io personalmente ho fin da subito preferito Gowalla, credo principalmente per una questione di design. Ricordo di aver iniziato ad usare l’app di Gowalla nel novembre del 2009, quando ancora in Italia c’erano pochissimi utenti, tant’è che mi sono ritrovato ad essere il fondatore di alcuni spot di un certo rilievo, tra cui ad esempio il Forum Di Assago e Piazza Del Popolo a Roma.

Pian piano che i mesi passavano però diventava sempre più chiaro che la gara, in termini di numero di utenti, la stava vincendo Foursquare. Io, per quanto mi riguarda, non sono mai passato “alla concorrenza” (pur avendo un account) perchè ho sempre preferito l’approccio visivo e l’usabilità di Gowalla. Bastava guardare i loro stamp personalizzati (per i luoghi più importanti) per capire come il design per il team Gowalla fosse un elemento fondamentale nel loro prodotto.

A quanto pare però non bastava. Foursquare macinava sempre più utenti, giorno dopo giorno. Sinceramente non ho mai capito veramente perchè; qualcuno dice che sia perchè Gowalla è ad Austin, nel Texas, mentre Foursquare è nella city, la cara vecchia New York. Qualcuno dice che Gowalla aveva un nome che rendeva meno l’idea. Qualcuno dice che Ashton Kutcher ha fatto molta promozione gratuita (o forse no) a Foursquare. Qualcuno dice che Gowalla aveva un meccanismo meno chiaro, probabilmente per via delle items, funzionalità che poi è stata tolta con gran dispiacere di alcuni accaniti collezionisti virtuali.

Motivazioni a parte, Gowalla stava perdendo. Da qui una decisione un po’ burrascosa, presentata qualche mese fa: re-inventarsi completamente. Venne presentata una nuova versione di Gowalla che cercava di essere non più una semplice check-in application ma una Social Guide. I check-in vennero convertiti in stories, la condivisione sui social network divenne leggermente più macchinosa e l’applicazione (che inizialmente era anche un po’ buggosa) improvvisamente non mostrava più molte delle informazioni che piacevano tanto ai “Gowallers”. Io stesso a questo punto mi ritrovavo un po’ spiazzato. Nel frattempo Gowalla fu bersagliata di accuse di “aver rovinato tutto” da parte dei fedelissimi e non, tant’è che a un certo punto la loro bacheca su Facebook venne chiusa per non rendere pubblica quella sassaiola. Tanta gente se ne andava e ci teneva a farglielo sapere, quasi fosse stata vittima di un tradimento.

Visto questo scenario capisco come sia facile accettare, senza neanche pensarci più di tanto, una proposta di acquisizione. Dopo aver perso nel tentativo di lancio e di ri-lancio è abbastanza facile aggrapparsi alla prima cosa interessante che arriva. Se poi questa si chiama Facebook ed è il social network per eccellenza, dire di no è praticamente impossibile. Guardando la vicenda in quest’ottica mi è facile capire la gioia espressa pubblicamente dal team di Gowalla, che a breve si trasferirà fisicamente negli uffici di Facebook a Palo Alto e si metterà al lavoro sui servizi di localizzazione come Facebook Places e sulla nuova funzionalità Timeline.

Quelli che rimangono un po’ a bocca asciutta sono però gli utenti: tutte le acquisizioni fatte fin’ora da Facebook avevano come conseguenza immediata la chiusura del servizio e questo caso non è un’eccezione. Gowalla come lo conosciamo chiuderà i battenti verso fine Gennaio 2012 lasciando agli utenti una magra consolazione: ci sarà a quanto pare un modo per esportare la propria attività in modo che non vada persa. Per molti come me si tratta di due anni di viaggi, spostamenti ecc. che effettivamente sarebbe un peccato perdere. Non è chiaro al momento cosa si inventeranno a riguardo… Personalmente spero che, dato che a questo punto pare evidente che bisognerà cercare un’alternativa, verrà magari offerta la possibilità di importare tutto in un altro servizio. Naturalmente non sarà un cosa facile (gli spot differiscono a seconda del servizio) ma sarebbe sicuramente utile.

Quello che invece ho trovato abbastanza folle sono i vari commenti di persone che hanno detto “chiuderò subito il mio account per evitare che i miei dati vadano a Facebook”. Questo mi sembra abbastanza nonsense per diversi motivi:

• É stato ufficialmente dichiarato che Facebook non ha acquistato i dati da Gowalla.
• É abbastanza buffo cercare di tutelare la propria privacy quando si è iscritti ad un servizio dove sostanzialmente dici pubblicamente dove ti trovi e cosa stai facendo. Soprattutto considerando che gran parte degli utenti ha collegato il proprio account Gowalla a Facebook, autorizzando quindi lo scambio di queste informazioni.
• Credo che al giorno d’oggi sia abbastanza impossibile evitare che Facebook abbia i nostri dati, in un modo o nell’altro. Triste, forse, ma vero.

Cmq tornando alle alternative, credo che le possibilità più interessanti siano queste:

• Foursquare
• Path
• Google+ (che tra le altre cose permette anche di registrare la propria posizione)
• Facebook Places (che al momento non sembra granchè ma non è escluso che dopo questa acquisizione diventerà qualcosa di più interessante)

Staremo a vedere insomma!