(Fissati  prima che spariscano dalla mia mente)

1. non è detto che un eBook si possa prestare
2. non è detto che si possa rivendere
3. non è garantito che sopravviva ad un cambio di lettore
4. è tecnicamente  soggetto al lock-in del produttore (vuoi passare da l lettore Amstrad al lettore Telefunken? Oh, mi dispiace, dovrai ricomprarti tutta la tua biblioteca…)
5. è possibile (ed è già successo) che chi te lo ha venduto te lo cancelli da remoto per sue ragioni

Non tutti gli eBook soffrono necessariamente di queste limitazioni, alcune di esse sono superabili o non ci sono in alcuni casi (occorre dirlo, un ebook è pirata non soffre della metà di questi problemi).

Ma il punto focale e innegabile è che  un libro tradizionale è uno strumento auto-contenuto, basta a sé stesso, mentre un eBook è pur sempre indissolubilmente legato al contesto tecnologico in cui si trova.

Se trovi un libro fra 100 anni lo leggi, se trovi un eBook resta inaccessibile senza la tecnologia di contorno.

Stavo curiosando sui layout di alcuni form quando per caso mi sono imbattuto in una soluzione semplice ed efficace per ottenere dei form incolonnati in maniera pulita con due soli tocchi di css e zero tabelle: Continua »

Tempo fa avevo fatto un programmino (su richiesta di una celebre tenutaria di blog) che faceva una cosa semplicissima: prendeva un testo contenente alcune mail e le estraeva.

Al tempo avevo un interesse per la piattaforma .NET e C#, per cui l’avevo programmato in quel linguaggio. Però questo hai i suoi svantaggi, uno dei quali è che se non puoi installare i framework (per esempio non sei amministratore della macchina) il programmino non funziona.

Allora ho deciso di rifarlo in puro html-css-javascript. Una specie di Cloud computing.

[Scaricalo/usalo]

Alcune soluzioni tecniche (degne di nota e poco note ai più): Continua »

Una microlezione di usabilità: due comandi vicini sono spesso confondibili, quindi cosa non si deve mai fare?

1. mettere vicini due comandi dal significato simile ma non identico porta facilmente alla confusione tra i due
2. mettere vicino a un comando molto usato e dagli effetti innocui (qualcosa che provoca un effetti minimo o facilmente annullabile) vicino a un comando dagli effetti potenzialmente distruttivi e magari non annullabili è un grosso errore

Potete vedere un mix di questi due errori in bit.ly, che ha una funzione per condividere direttamente i link accorciati sui social network più diffusi.

Mettiamo che  tu vuoi condividere un link solo su Twitter, quello che devi fare è staccare temporaneamente lo Sharing on di Facebook. Invece il remove provoca la rimozione totale dell’applicazione.

Qui ci sono entrambi gli errori, il primo è che i due comandi possono essere confusi da un utente distratto e di fretta (remove == rimuovi la condivisione su Facebook per questo post).

Il secondo è che il comando remove è vicino a un comando usato spesso (almeno da me) e soprattutto che è un comando altamente distruttivo. Su questo punto pesano due fatti oggettivi:

1. non ha un annulla, una volta cliccato bisogna reinstallare il componente
2. cosa più grave: non ha una conferma, clicchi e sei fuori senza una seconda possibilità di riflessione

Bitly è salvato in corner dal fatto che l’installazione del componente è talmente veloce da non provocare un danno apprezzabile, tuttavia è un bell’errore di usabilità.

Questa è la seconda parte non voluta del post sul box model del blog.

La seconda parte è stata aggiunta in seguito ad un lievissimo problema con l’ultima versione del box model che avevo pensato. Per la storia completa vedete il vecchio post. Continua »

EDIT: Bug, ho dovuto revertare perché dopo aver aggiustato tutto ho rotto un’altra cosa. Bello HTML, quasi quasi lo odio… Viva le tabelle!
alla fine ho sistemato tutto, ma si è reso necessario un add-on a questo post.

Il box model è la modalità di formattazione definita dalla combinazione di HTML e fogli di stile (CSS). Per i non addetti, potrei riassumerlo in italiano corrente come la regola base da conoscere per lavorare con HTML e CSS. I non addetti ai lavori possono uscire da questo articolo, è lungo, palloso e non fa per voi.

Non voglio entrare in tecnicame che non sono nemmeno sicuro di conoscere così bene, voglio solo fare un esempio di box model vero (questo blog) e dei problemi che questo si porta dietro. Tenete conto che la lunghezza del post è direttamente proporzionale al casino che mi ci è voluto per sistemarlo, il che da l’idea di quanto possa essere problematico un layout web. Continua »

Ricetta per migrare un forum.

Nota iniziale: per la verità la soluzione più semplice è migrarlo sul posto, tuttavia se il vostro provider vi mette a disposizione 200MB di spazio mySQL questo è impossibile, difatti dopo la migrazione ci sono sia il DB vecchio che quello nuovo e la somma dei due oltrepassa lo spazio disponibile.

Procuratevi un forum ben avviato su phpBB2,  con circa 140 MB di dati in un server mySQL.
Vi servirà poi un server locale con webserver, PHP5 e un database mysql possibilmente recente. Continua »

L’altro giorno pensavo che mi sarebbe stato utile un input box che permettesse di inserire una lista di elementi, più o meno come quello che usa facebook per i destinatari dei messaggi privati:

All’inizio pensavo sarebbe stato un macello immane programmare una cosa del genere, ma ho avuto un’illuminazione  improvvisa che mi ha fatto capire come in realtà sia discretamente facile.

Non capivo come facesse FB a fare una input box  che contenesse elementi complessi. La risposta è semplice: la casella A: non è un input box ma un div mascherato da input box, invece la casella Oggetto: è una vera input box.
Per ottenere l’effetto è sufficiente settare bordi e dimensioni in modo che siano uguali per i due tipi di elementi, così da farli diventare indistinguibili.

L’unico mistero rimanente è come far si che la finta input box  mantenga la possibilità di accettare testo in ingresso. La risposta è abbastanza facile: l’ultimo elemento all’interno del div è una vera input box, fatta “scomparire alla vista” togliendogli i bordi.
Detta così sembra complicata, ma  basta dare un occhiata allo schema per capire che in realtà è molto semplice:

La textbox finale c’è ma non si vede, perché non ha i bordi. Ho fatto un concept-proof in poco meno di un’ora.

Vi racconto la storia di un piccolo pezzo di codice javascript, che funzionava felice su tutti i browser del mondo creato.

Purtroppo arrivò il brutto IE, che invece lo gradiva su una pagina mentre su un’altra, identico, non gli andava  proprio giù.

Il codice potrebbe essere, più o meno, questo:

<script type="text/javascript">
<!--
function print_something(prefix){
	// assegno keywords
	keywords = "!";

	// scrivo le keywords
	document.write( prefix + keywords );

}

// chiedo la stampa
print_something("world");

// -->
</script>

Ora, perchè un codice del genere ad IE piace moltissimo in questo file e non funziona del tutto in quest’altro?

Non vi farò giocare alle 10 differenze, nel secondo file ci sono i meta tag nell’header ed IE decide di instanziare un oggetto keywords per accedervi. Quindi non si può riutilizzare la parola keywords come variabile nella funzione perchè IE l’ha già istanziata e ogni operazione porta ad un errore.

Da notare che questo simpatico comportamento  avviene solo all’interno di funzioni (all’esterno keywords risulta undefined) e solo se keywords non è dichiarata propriamente (cioè dichiarando var keywords = “!”; il codice funziona perfettamente).
Chiaramente IE non ritorna un messaggio di errore coerente, tipo questa variabile è già dichiarata,  ma si lamenta su operazioni non valide o proprietà inesistenti.

Cosa si impara da questa esperienza?

1. dichiarare propriamente le variabili con var nomevar = valore; non è una perdita di tempo inutile
2. dare dei nomi troppo comuni alle variabili non è una buona idea
3. i bug più sono stupidi più sono difficili da trovare
4. ie sucks.  Ma in fondo questa non è un novità