Gumroad è una startup che in pochi passi si propone di risolvere il problema:

• Ti registri su gumroad.com
• Inserisci il nome del prodotto che vuoi vendere ed un link
• Fissi il prezzo
• Diffondi il link di acquisto

Se tutto va come previsto, ogni mese Gumroad pagherà via Paypal, trattenendo una commissione (pari al 5% + 0.30$ per ogni acquisto).

La procedura di acquisto

Gumroad sembra una buona soluzione per vendere prodotti senza doversi preoccupare dell’esperienza di acquisto dell’utente. La procedura infatti è semplicissima:

1. pagina di acquisto

2. inserimento dati della carta di credito

E i difetti?

Il problema principale è uno: Gumroad non offre nessuna protezione o garanzia sul link di acquisto del prodotto. Niente vieta ad un utente di comprare e poi condividere il link con amici e parenti.

Parlando di beni digitali, in ogni caso il problema resterebbe anche se il link fosse dinamico. Nessuno potrebbe impedire ad un acquirente di condividere tramite altri mezzi il bene appena acquistato.

Io valuterò seriamente l’uso di questo servizio: vendere foto, temi WordPress, script o elementi grafici non è mai stato così facile, e la commissione è decisamente inferiore a quella di altri servizi come ThemeForest. Certo, qui non esiste un network all’interno del quale farsi conoscere, ma sono due servizi differenti per esigenze diverse. Avere una nuova possibilità a disposizione è sempre positivo, considerando che è la creazione di un 19enne: Sahil Lavingia.

Uno degli scopi del sondaggio era capire come fosse interpretata la disciplina: viene usata semplicemente come un nuovo termine per farsi interessanti agli occhi dei clienti o ha davvero un’utilità pratica?

Tenendo presente che il campione esaminato è piuttosto ristretto (81 persone), le risposte sono comunque interessanti.

Il primo dato riguarda i partecipanti: sicuramente ha influito l’argomento del questionario, perché il 40% ha dichiarato di essere un User Experience Designer, in numero maggiore rispetto a Web Designer, Project Manager e Information Architect. Ho qualche dubbio che questi numeri si avvicinino alla realtà: la mia impressione è che il target interessato a rispondere sia troppo lontano dalla media italiana.

Un altro punto molto interessante riguarda la risposta alla domanda “Cosa pensi della User Experience?”, filtrando i risultati tra UX Designer, Project Manager e il resto degli intervistati. Praticamente tutti ritengono la materia importante, ma:

• gli UX Designer sono molto meno propensi a definire la User Experience “fuffa”
• i PM pur considerando l’argomento importante, definiscono il nome inconsistente con numeri ben sopra la media dei designer.

In sintesi questa è l’analisi che viene fatta:

La UX è un nome che a molti (in particolare molti Project Manager, ma non solo) ritengono fuffoso, ma tutti riconoscono che è un “ombrello” che si occupa di attività importanti o molto importanti. In Italia pare tuttavia esserci (per quel che può testimoniare il nostro piccolo campione) un ventaglio di esperienze non positivo con i professionisti che operano in questo settore: vengono giudicati poco credibili o poco professionali.

Non perché non ci sia rigore scientifico dietro i metodi (viene giudicato poco importante: e questo mi sembra un segno di maturità del settore), ma perché applicati male o da professionisti giudicati poco competenti.

Se non l’avete già fatto vi consiglio di leggere tutto l’articolo, merita attenzione. Sarebbe interessante organizzare prossimamente un altro questionario simile cercando di allargare il campione, sullo stile dei sondaggi annuali di A List Apart.

Queste indicazioni hanno un obiettivo ben preciso, dichiarato nel testo di presentazione:

[...] suggerire alle PA criteri e strumenti per la riduzione dei siti web pubblici obsoleti e per il miglioramento di quelli attivi, in termini di principi generali, modalità di gestione e aggiornamento, contenuti minimi. A tal fine, le Linee guida sono finalizzate a delineare gli aspetti fondamentali del processo di sviluppo progressivo dei servizi online e di offerta di informazioni di qualità rivolte al cittadino, che deve contraddistinguere ogni pubblica amministrazione.

Sono stupito (ma forse non troppo) nel vedere che purtroppo le novità e le differenze rispetto alle linee guida del 2010 sono state pubblicate in un’immagine .jpg, deformata ma soprattutto inaccessibile. Se nemmeno in questo ambito vengono rispettati i minimi requisiti, non mi sorprende che ancora oggi buona parte della rete sia preclusa ad una buona fascia di utenti.

L’invito è sempre lo stesso: preoccupatevi delle normative, ma pensate all’accessibilità reale dei siti che realizzate, e soprattutto considerate l’applicazione di certe buone norme nel lavoro di tutti i giorni, non solo lavorando nell’ambito della PA.

Una di queste situazioni è stata descritta pochi giorni fa su 456 Berea Street, e riguarda le liste HTML: i classici tag <ol> e <ul>. Quando l’aspetto della lista viene nascosto tramite fogli di stile, molti screen reader non la annunciano come tale, anche se il codice HTML dice il contrario.

Questo si verifica utilizzando gli attributi CSS:

list-style-type: none

oppure

list-style: none

In questi casi NVDA su Firefox, Orca e VoiceOver non dichiareranno la presenza di una lista. Non è un problema gravissimo, ma questo comportamento peggiora l’esperienza di navigazione degli utenti che usano uno screen reader. Non saranno infatti in grado di capire quando inizia o finisce un elemento.

Una informazione del genere ovviamente va valutata a seconda delle situazioni e del target di utenti: nessuno vi impedisce di usare list-style: none, ma se lavorate su un sito dove tenete all’accessibilità, considerate l’ipotesi di mostrare le liste come tali, senza ricorrere a immagini in background per i puntatori o stratagemmi simili.

Se vi interessa approfondire l’argomento screen reader e volete testare il vostro sito, trovate altre informazioni utili in questo post: Uno screen reader per i test.

Responsive Web Design è l’ultimo libro pubblicato da A Book Apart, la società gestita dall’onnipresente Jeffrey Zeldman. Nei mesi scorsi ho avuto modo di leggere le pubblicazioni dedicate a HTML5 e CSS3, ma questo è stato il primo testo che mi ha convinto veramente a scrivere una recensione.

Le pubblicazioni precedenti sono un pratico riassunto per chi vuole iniziare a lavorare con le ultime tecnologie nell’ambito del web design, ma questo testo offre qualcosa di più.

Qual è l’argomento del libro?

La spiegazione di tutte le tecniche necessarie alla realizzazione di siti web multipiattaforma, dal desktop al mobile passando per i tablet, senza per forza ricorrere a pagine con markup differente. Se in passato un sito web poteva essere inteso come un’entità tutto sommato ben definita e relativa ad un unico contesto (lo schermo del pc), adesso questo concetto non esiste più: i contenuti vengono visualizzati sui dispositivi più vari, dall’iPad agli smartphone di ultima generazione, che hanno risoluzioni variabili e caratteristiche diverse tra loro. I siti a larghezza fissa iniziano a diventare obsoleti, e a seconda del contesto e del proprio target potrebbe valere la pena progettare siti web che si adattano all’utente, mantenendo il pieno supporto ai browser più datati.

La prima cosa che si nota leggendo questo libro è un approccio molto pratico alla soluzione dei problemi da parte dell’autore, Ethan Marcotte. Se questo può non piacere ad alcuni, per tutti coloro che amano sperimentare e sporcarsi le mani con il codice Responsive Web Design è il testo perfetto. Solo la teoria essenziale, pochi concetti espressi in maniera molto chiara, e molti esempi con il codice in evidenza pronto per essere testato.

Contenuti

Responsive Web Design è suddiviso nei seguenti capitoli:

1. Our Responsive Web
2. The Flexible Grid
3. Flexible Images (estratto in inglese – estratto in italiano)
4. Media Queries
5. Becoming Responsive

Potete leggere un estratto dal terzo capitolo su A List Apart o su Italian A List Apart.

Il libro è in vendita sia in versione cartacea che digitale sul sito di A Book Apart. Se siete interessati all’argomento, volete sapere come utilizzare al meglio le media queries dei CSS3 e vi piacerebbe sapere cosa si intende quando si parla di approccio mobile first, Responsive Web Design fa al caso vostro.

Leggerlo mi ha dato molte idee, e probabilmente nei miei prossimi lavori e nella futura versione di tomstardust.com metterò in pratica molti dei suggerimenti letti.

Infatti se all’interno di un CSS ci sono delle regole contrassegnate con !important e questi valori devono essere modificati su dei nuovi elementi, non ci sono molte soluzioni. Le principali sono due:

• stravolgere il foglio di stile
• entrare in un circolo vizioso aggiungendo nuove regole con !important.

Basta capire questo per rendersi conto di come sia sempre meglio evitarne l’uso. Mi era capitato anche in passato di sfiorare l’argomento parlando degli standard del sito della BBC, dove era appunto proibito agli sviluppatori di utilizzare questa regola.

Ma quali sono le alternative? Prima di tutto pensare fin da subito a come dovrà essere organizzato il foglio di stile. Scrivere regole generiche non aiuta e molto spesso è il motivo per cui si viene tentati dall’utilizzo di !important.

Un link ad esempio avrà una sua definizione generica all’inizio del CSS:

a {...}

Ma unire a questo qualcosa come

#content a {...}

…sarà fonte di problemi dopo poco tempo, perché è una definizione troppo generica per non richiedere nuovi interventi. Per evitarlo, la cosa migliore è appoggiarsi sempre a selettori ben specifici, a seconda dell’area del sito.

In un blog potrebbero esserci ad esempio vari div contenitori all’interno dei post, con cui differenziare lo stile dei link:

#content .post_header a {...}
#content .post a {...}

O sulla sidebar invece di un generico

#sidebar a {...}

potrebbero essere definite delle aree precise come sui temi WordPress:

.widget a {...}

Eccezioni

Uno dei rari casi in cui l’uso di !important può avere senso è quando sono presenti elementi specifici che devono apparire uguali in qualsiasi punto del sito. Non sto parlando di bottoni e riquadri (che potrebbero sempre avere delle varianti), ma ad esempio di indicazioni di stato come i messaggi di errore.

Contrassegnare una classe .error nel seguente modo potrebbe essere l’unica ragione per tollerarne l’uso:

.error {color: #f00 !important;}

Se volete leggere anche un’opinione autorevole a riguardo, vi consiglio di dare un’occhiata al post When using !important is the right choice su CSS Tricks, e di leggere attentamente il commento di Jonathan Snook in risposta agli esempi citati dall’autore.

Il primo è usare l’attributo “for” sulla label, con un valore corrispondente all’id dell’elemento associato:

<label for="email">email:</label>
<input type="text" id="email" />

Il secondo è inserire il campo del form all’interno della label:

<label>email: <input type="text" /></label>

Personalmente preferisco il primo metodo, ma il secondo è comunque valido e riconosciuto come corretto.

Label nascoste

Un metodo molto diffuso ultimamente è quello di non visualizzare la label, inserendo un placeholder all’interno del campo, o usando JavaScript per nascondere al clic un valore che fa da segnaposto, come il classico “inserisci qui la tua email”.

Questa tecnica può essere tranquillamente utilizzata, ma non autorizza ad eliminare l’etichetta associata. La label deve essere sempre presente, anche se invisibile.

HTML5 e le label

Parlando di HTML5, il discorso è più o meno analogo. C’è un interessante articolo di Steve Faulkner sull’argomento con alcuni test pratici: HTML5 accessibility chops – form control labeling.

Dai risultati si nota come il metodo più sicuro per far riconoscere una label al browser (o a una tecnologia assistiva come uno screen reader) sia sempre l’attributo for abbinato ad un id.

Un altro metodo efficace è l’utilizzo dell’attributo aria-labelledby, che viene riconosciuto come valido:

<label id="email">email</label>
<input type="text" aria-labelledby="email">

Inserire il campo input all’interno di una label non è un metodo pienamente supportato, quindi con HTML5 è meglio evitarlo, almeno per ora.

Creare un form accessibile non è complicato, seguendo queste poche indicazioni avete tutti gli elementi per utilizzare correttamente le label. La cosa importante è ricordarsi di avere sempre un minimo di attenzione ai dettagli. Basta veramente poco per rendere un form accessibile, con qualsiasi specifica.

Da qualche giorno fa parlare di sè Iubenda, un nuovo servizio tutto italiano che permetterà a chiunque abbia un sito web di generare una informativa sulla privacy. La beta privata partirà il 1° luglio, ma l’idea è veramente interessante soprattutto perché al momento non esistono concorrenti; la condizione ideale per partire con un vantaggio non da poco.

Al momento è possibile iscriversi in attesa di ricevere un invito.

Come funziona il servizio?

Iubenda è un’applicazione web con un obiettivo chiaro: colmare una lacuna che riguarda la maggioranza dei siti (italiani e non). Per creare la propria privacy policy sarà sufficiente superare tre passi:

1. selezionare i servizi utilizzati (es. Adsense, Google Analytics…)
2. inserire i dati relativi al titolare
3. aggiungere al sito il codice necessario

La procedura non poteva essere più semplice: vedremo all’apertura se il servizio sarà effettivamente usabile ed immediato come si presenta. Al momento non resta che fare un in bocca al lupo al team di sviluppo, visto che idee come questa meritano di crescere, soprattutto se nate in Italia.

Classifica per l’accesso alla beta

Mi ha colpito subito il sistema che è stato ideato per aiutare il passaparola. Ogni iscritto a Iubenda infatti conosce in tempo reale la propria posizione in una classifica generale di tutti gli utenti registrati, ed il 1° luglio solo i primi 30 potranno accedere al servizio in anteprima. Per guardagnare posizioni in classifica è necessario portare altri iscritti, e parlare del servizio su Facebook e Twitter.

Un meccanismo del genere ha sicuramente richiesto ore aggiuntive di sviluppo, ma gli sforzi sono stati ampiamente ripagati. Basta fare una ricerca su Twitter per rendersi conto di come il passaparola si stia facendo strada.

Una strategia di marketing simile non è da sottovalutare: per il vostro prossimo progetto potrebbe valere la pena pensare a qualcosa del genere.

Per approfondire

Su Ninja Marketing è stata pubblicata un’intervista ad Andrea Giannangelo, il fondatore di Iubenda. Se volete sapere come è nata questa startup vi consiglio di leggerla.

Potete iscrivervi subito a Iubenda a questo indirizzo.

[Foto di 3desc - Fotolia.com]

E’ stata rilasciata la versione beta 2 di WordPress 3.2, con alcune importanti novità. In attesa dell’uscita della release definitiva è stata inviata una comunicazione agli sviluppatori con l’invito a fare dei test: ci saranno infatti alcuni cambiamenti rilevanti, ed è bene che siano noti a tutti coloro che usano WordPress soprattutto in ambito lavorativo.

Requisiti minimi: PHP 5.2.4 e MySQL 5.0.15

Il primo fattore da considerare è il cambiamento dei requisiti minimi per l’installazione di WordPress. Dalla versione 3.2 in poi sarà necessario avere installati sul server PHP 5.2.4 e MySQL 5.0.15.

Questo potrebbe causare problemi con alcuni servizi hosting che utilizzano ancora la versione 4 di PHP: non è un caso così raro come si potrebbe pensare. Al momento di aggiornare a WordPress 3.2 ricordatevi di controllare la configurazione del vostro hosting in modo da evitare sorprese.

Aggiornamento a jQuery 1.6.1

Un’altra novità rilevante è l’aggiornamento della versione di jQuery inclusa in WordPress. Si passa da jQuery 1.4.4 alla 1.6.1, con un salto di ben due major release.

Tra le novità più importanti, la versione 1.5.0 e le successive non consentono più l’utilizzo di selettori del tipo [property=value], ma è necessario utilizzare la forma [property="value"].

Inoltre nel passaggio a jQuery 1.6.0 e versioni successive il metodo .attr() è stato sostituito da .prop(): in alcuni casi sarà quindi necessario modificare il codice, ed alcuni plugin potrebbero dare degli errori se non aggiornati di conseguenza.

Chi interessano queste novità?

Se siete tentati di sorvolare su queste novità, potreste avere delle brutte sorprese al momento dell’aggiornamento a WordPress 3.2, quando uscirà la versione finale. Ovviamente i diretti interessati a questo cambiamento sono gli sviluppatori di plugin e temi, ma anche se non siete dei programmatori e state semplicemente utilizzando WordPress per i vostri progetti, vi raccomando di provare ad installare in locale la beta 2 e controllare che tutto funzioni.

Per effettuare dei test sui vostri siti di sviluppo potete scaricare la versione beta 2 di WordPress 3.2 a questo indirizzo.

Esistono vari modi di ridimensionare il testo di una pagina web tramite CSS: in pixel, em e in percentuale.

Tramite un post di Jonathan Snook ho scoperto l’esistenza di una nuova unità di misura introdotta con i CSS3, chiamata rem. Questa unità si comporta in maniera molto simile a em, senza ereditarne i punti deboli.

Font-size con em

Prima di parlare delle novità mi sembra giusto riprendere in mano la tecnica che potrebbe essere sostituita.

Utilizzare l’unità di misura em permette già ora di superare un problema di tutte le versioni di Internet Explorer (compresa la 9): l’impossibilità di ridimensionare il testo quando il font-size è espresso in px. Con em questo inconveniente non esiste, basta usare una formula di questo tipo:

body { font-size:62.5%; }
h1 { font-size: 2em; } /* =20px */
p  { font-size: 1.4em; } /* =14px solo se non all'interno di una lista */
li { font-size: 1.4em; } /* =14px solo sul primo livello */

Il problema però è che em è un’unità di misura relativa all’elemento contenitore. Se nella pagina appare un paragrafo all’interno di un elemento li oppure ci sono due o più liste annidate, gli elementi interni aumentano progressivamente di dimensione. Una lista contenuta in un’altra lista in questo caso non sarebbe più 14px ma 20px. Aumentando di un altro livello la dimensione del testo diventerebbe 27px.

Il problema può essere evitato dichiarando per ogni livello il font-size originale, ma è un metodo scomodo e poco mantenibile.

Font-size con rem

L’unità di misura rem si comporta come em, ma fa riferimento all’elemento alla radice del documento. Rem infatti è la sigla per “root em”.

La nuova formula diventa:

html { font-size:62.5%; }
h1 { font-size: 2rem; } /* =20px */
p  { font-size: 1.4rem; } /* =14px */
li { font-size: 1.4rem; } /* =14px */

In questo modo tutti i problemi sono risolti, non esistono differenze sugli elementi annidati e il testo può essere ridimensionato senza problemi anche su IE.

Rem e il supporto dei browser

Il supporto di questa unità di misura è migliore di quanto pensassi: viene riconosciuta da tutte le ultime versioni dei browser, escluso Opera. Per non avere problemi su questo browser e garantire il supporto anche alle versioni precedenti di IE è sufficiente indicare un fallback nei CSS:

html { font-size:62.5%; }
h1 { font-size: 20px; font-size: 2rem; } /* =20px */
p  { font-size: 14px; font-size: 1.4rem; } /* =14px */
li { font-size: 14px; font-size: 1.4rem; } /* =14px */

Cosa ne pensate? Io inizierò a sperimentare questa tecnica nei miei prossimi progetti, e se non emergeranno particolari problemi penso proprio che potrebbe diventare uno standard. E’ più immediato utilizzare px come unità di misura, ma se tenete all’accessibilità dei vostri lavori basta veramente poco per fare la differenza.

[Foto di Paul Pirosca - Fotolia.com]