Il secondo problema nella supposta equivalenza fra classi di oggetti e tabelle può essere logicamente collegato al primo ma può anche essere pre­sente per conto proprio. Questo secondo errore consiste nell’esporre i puntatori e le tabelle.

Il nocciolo del problema è che,  per definizione, i puntatori sono variabili, non valori e il modello relazionale non consente l’uso di variabili di tupla o di attributo.

Credo sia un errore minore rispetto al primo e soprattutto non molto rilevante nella discus­sione sugli ORM. Infatti, nel momento stesso in cui creo un mapping, mi muovo all’interno di un certo ambiente di programmazione che, di nuovo per definizione, non è relazionale.

Ascoltando questo podcast mi è venuto un attacco di nostalgia pensando a quanto tempo ho pas­sato a usare l’EOF, a quanto ne ho tes­suto le lodi e a quanto poco ne senta adesso la mancanza, avendo cambiato radicalmente idea.

Oggi penso che gli ORM siano quasi sempre la soluzione sbagliata, se non per l’indipendenza dai vari dialetti SQL.

Il problema sta nella supposta equivalenza fra classe e tabella. La tabella CLIENTE diventa la classe Cliente; le colonne diventano diventano attributi/ivars/properties/metodi della classe; ogni riga della tabella diventa un’istanza della classe. Semplice, no?

In effetti la tentazione è forte, ma credo sia un’idea sbagliata e la ragione è quella definita da Date come “The first great blunder”. Nota sul link: l’ho messo per comodità ma raccomando di leggere il suo libro “An introduction to database systems”.

Per molto tempo ho considerato le obiezioni di Date troppo formali, quasi capziose, ma mi sbagliavo. Credo che l’integrità concettuale così puntigliosamente difesa sia una cosa importante e che senza di essa le pre­messe per un buon design del software siano minate alle fondamenta.

Ho appena comprato “Designing for the Web”, di Mark Boulton.

Gli ho dato una scorsa veloce e posso già dire che se avete qualche euro da spendere per un libro (in pdf) non ve ne pentirete.

E in autunno uscirà “Designing Grid System for the Web”!

Da qualche giorno sono ritornato al grado zero per prendere appunti sull’iPhone, ovvero, uso Notes. Devo dire che quest’applicazione è un piccolo esempio di semplicità: tutti i default e le metafore sono quelle giuste; si lancia in un attimo; e non ha preferenze.

Mi sono trovato spesso a pensare a quanto siano diventate complicate le applicazioni per i computer “clas­sici”. L’avere a disposizione una potenza computazionale in costante aumento, unita al desiderio di accontentare ogni richiesta degli utenti ha portato le applicazioni ad avere miriadi di impostazioni. Tutte utili, molte dispensabili.

Ammetto di essere il primo a perdere un sacco di tempo per perfezionare tutte le pre­ferenze pos­sibili, ma con l’iPhone mi sono reso conto di quanto si possa semplificare e ridurre un’applicazione al suo nocciolo essenziale senza snaturarla.

Mi chiedo se a volte l’abbondanza di pre­ferenze non nasconda una carenza di progettazione: “non sappiamo esattamente cosa fare, beh, che decida l’utente!” 

Segnalo questo post di Jon HicksFontExplorer Pro.

I bozzetti a mano sono fantastici e anche i dettagli e i commenti sui ai vettoriali non si pos­sono perdere. 

Segnalo da 24 Ways un articolo che, sfruttando la pos­sibilità di specificare più una distanza dal suo genitore per un elemento posizionato in modo assoluto, raggiunge uno degli obiettivi che rimangono ancora (troppo) difficili da raggiungere con i CSS: colonne di altezza uguale allineate verticalmente.

L’articolo non dice molto di nuovo rispetto a quello di A List Apart ma credo sia comunque utile segnalarlo.

Una delle applicazione tipiche per oggetti come l’iPhone sono i vari programmini per le note ecc. Io mi trovo bene con Evernote, che, anche su mac mi ha dato una mano per semplificare ulteriormente la gestione dei documenti. Consigliato.

Tuttavia, non è di questo che voglio parlare. O meglio, voglio parlare della nuova interfaccia di Evernote che è stata messa nell’ultima versione e che trovo demenziale.

Questa è la vecchia versione:

Screenshot della vecchia versione

Semplice, no? La clas­sica interfaccia da applicazione iPhone. Bene, questa invece è la nuova:

Screenshot della nuova versione

Ora, io non sono un esperto di GUI, tutt’altro, ma il tab dei suggerimenti mi sembra piantato lì così, al primo posto che capitava; sembra un prototipo. Mah.

Piuttosto avrei tolto l’icona dei “Pending” che serve solo a dirti le note che sta sincronizzando — funzione che può essere svolta benis­simo dall’icona dell’applicazione, tanto più in un ambiente che non consente processi in background — e, se proprio era ritenuto così importante, avrei messo il clas­sico punto di domanda dell’aiuto in linea.

Qualche tempo fa avevo segnalato uno studio sull’efficacia nell’alternare il colore delle righe di una tabella.

Poiché si dà spesso per scontato che questa soluzione sia migliore, c’è stata una certa sorpresa nel vedere che non c’erano differenze significative.

Io mi ero permesso di mettere in dubbio che la soluzione testata fosse effettivamente la più adatta. In ogni caso adesso abbiamo nuovi dati che sono forse un po’ più in linea con le aspettative.

Se vogliamo trovare il pelo nell’uovo, ho la sensazione che si voglia trovare il modo di dimostrare che questa soluzione ha un qualche vantaggio. Di fatto i risultati non sono granché migliori se trascuriamo ’impatto estetico.

Aggiungo anche che forse il vero para­metro da misurare non sta nella pre­cisione della risposta, ma nell’impegno che bisogna metterci; ad esempio misurando il tempo impiegato a completare un certo compito.

Cerchiamo astrazioni, pos­sibilità per semplificare, sintetizzare e ridurre a princípi primi ad ogni angolo. La ricerca dell’astrazione è talmente pre­sente che in Java, ad esempio, abstract è una parola chiave del linguaggio e indica classi o metodi privi, in parte o completamente, di implementazione: indicano che cosa ci si aspetta che faccia il codice senza dire nulla sul come; in astratto, appunto. Secondo alcuni un termine più adatto è generalizzazione ma sto divagando: il punto che voglio evidenziare è l’atteggiamento di fondo nella programmazione.

Parte di questa ricerca è legata ai termini. L’utilità dei pattern, ad esempio, sta anche nel trovare il nome adatto: “qui ho usato un visitor”, “i singleton sono da evitare” e così via. E in molti libri sul design del software si enfatizza (troppo, secondo me) l’importanza della nomeclatura per i metodi e le classi. 

Non dobbiamo però dimenticare che gli utenti spesso la vedono nel senso esattamente opposto, usano il termine più specifico e più concreto. Soprattutto a livello di interfaccia, usano le parole che meglio descrivono azioni e oggetti che hanno sott’occhio in quel momento. Certo, parte della difficoltà del design del software consiste proprio nell’allineare le proprie astrazioni con quelle dell’utente, ma non dobbiamo dimenticare che sono solo queste ultime (le astrazioni dell’utente) quelle che alla fin fine contano.

Prendiamo ad esempio Get Satisfaction. Si nota lo sforzo di usare una terminologia il più pos­sibile adatta all’utente: il form principale fa di tutto per non sembrare tale e usa un approccio graduale per non scoraggiare gli utenti. 

All’inizio, quando ho cominciato a dare un’occhiata al sito qua e là, ho trovato i termini e le frasi un po’ ridondanti, ansiosi di essere friendly, ma la direzione è quella giusta.

Viceversa, mi ricordo di un prototipo di un’applicazione di qualche tempo fa, in cui l’azione per creare dei record, qualsiasi record, era chiamata, indistintamente, “Nuovo oggetto”. È un’astrazione? Certo, ed è quella del tipo giusto: l’azione è sempre la stessa ed è semplicemente applicata ad oggetti diversi; tuttavia, non è un’astrazione che dev’essere esposta all’utente.

Se si lavora in squadra e ci occupiamo solo di una parte di un’applicazione tutta questa tirata non ha molta importanza, ma se abbiamo a che fare con diverse parti, soprattutto se sono vicine all’interfaccia, la questione cambia e richiede un certo sforzo per adottare due atteggiamenti mentali che vanno conciliati.

Leggendo questo articolo (in particolare il punto 10: Placating people with options) mi è tornato in mente un mio post di qualche giorno fa, guarda caso.

Continuo a dubitare che i progetti open source pos­sano avere grandi qualità di usabilità: non si è mai visto un gruppo di persone, tutte con lo stesso potere decisionale, produrre un qualche risultato artistico/estetico apprezzabile; a dispetto della giusta enfasi sul lavoro di squadra.