Il secondo pro­blema nella sup­po­sta equi­va­lenza fra classi di oggetti e tabelle può essere logi­ca­mente col­le­gato al primo ma può anche essere pre­sente per conto pro­prio. Questo secondo errore con­si­ste nell’esporre i pun­ta­tori e le tabelle.

Il noc­ciolo del pro­blema è che,  per defi­ni­zione, i pun­ta­tori sono varia­bili, non valori e il modello rela­zio­nale non con­sente l’uso di varia­bili di tupla o di attributo.

Credo sia un errore minore rispetto al primo e soprat­tutto non molto rile­vante nella discus­sione sugli ORM. Infatti, nel momento stesso in cui creo un map­ping, mi muovo all’interno di un certo ambiente di pro­gram­ma­zione che, di nuovo per defi­ni­zione, non è relazionale.

Ascoltando que­sto pod­cast mi è venuto un attacco di nostal­gia pen­sando 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 man­canza, avendo cam­biato radi­cal­mente idea.

Oggi penso che gli ORM siano quasi sem­pre la solu­zione sba­gliata, se non per l’indipendenza dai vari dia­letti SQL.

Il pro­blema sta nella sup­po­sta equi­va­lenza fra classe e tabella. La tabella CLIENTE diventa la classe Cliente; le colonne diven­tano diven­tano attributi/ivars/properties/metodi della classe; ogni riga della tabella diventa un’istanza della classe. Semplice, no?

In effetti la ten­ta­zione è forte, ma credo sia un’idea sba­gliata e la ragione è quella defi­nita da Date come “The first great blun­der”. Nota sul link: l’ho messo per como­dità ma rac­co­mando di leg­gere il suo libro “An intro­duc­tion to data­base systems”.

Per molto tempo ho con­si­de­rato le obie­zioni di Date troppo for­mali, quasi cap­ziose, ma mi sba­gliavo. Credo che l’inte­grità con­cet­tuale così pun­ti­glio­sa­mente difesa sia una cosa impor­tante e che senza di essa le pre­messe per un buon design del soft­ware siano minate alle fondamenta.

Ho appena com­prato “Designing for the Web”, di Mark Boulton.

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

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

Da qual­che giorno sono ritor­nato al grado zero per pren­dere appunti sull’iPhone, ovvero, uso Notes. Devo dire che quest’applicazione è un pic­colo esem­pio di sem­pli­cità: tutti i default e le meta­fore sono quelle giu­ste; si lan­cia in un attimo; e non ha preferenze.

Mi sono tro­vato spesso a pen­sare a quanto siano diven­tate com­pli­cate le appli­ca­zioni per i com­pu­ter “clas­sici”. L’avere a dispo­si­zione una potenza com­pu­ta­zio­nale in costante aumento, unita al desi­de­rio di accon­ten­tare ogni richie­sta degli utenti ha por­tato le appli­ca­zioni ad avere miriadi di impo­sta­zioni. Tutte utili, molte dispensabili.

Ammetto di essere il primo a per­dere un sacco di tempo per per­fe­zio­nare tutte le pre­fe­renze pos­si­bili, ma con l’iPhone mi sono reso conto di quanto si possa sem­pli­fi­care e ridurre un’applicazione al suo noc­ciolo essen­ziale senza snaturarla.

Mi chiedo se a volte l’abbondanza di pre­fe­renze non nasconda una carenza di pro­get­ta­zione: “non sap­piamo esat­ta­mente cosa fare, beh, che decida l’utente!” 

Segnalo que­sto post di Jon HicksFontExplorer Pro.

I boz­zetti a mano sono fan­ta­stici e anche i det­ta­gli e i com­menti sui ai vet­to­riali non si pos­sono perdere. 

Segnalo da 24 Ways un arti­colo che, sfrut­tando la pos­si­bi­lità di spe­ci­fi­care più una distanza dal suo geni­tore per un ele­mento posi­zio­nato in modo asso­luto, rag­giunge uno degli obiet­tivi che riman­gono ancora (troppo) dif­fi­cili da rag­giun­gere con i CSS: colonne di altezza uguale alli­neate verticalmente.

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

Una delle appli­ca­zione tipi­che per oggetti come l’iPhone sono i vari pro­gram­mini per le note ecc. Io mi trovo bene con Evernote, che, anche su mac mi ha dato una mano per sem­pli­fi­care ulte­rior­mente la gestione dei docu­menti. Consigliato.

Tuttavia, non è di que­sto che voglio par­lare. O meglio, voglio par­lare della nuova inter­fac­cia di Evernote che è stata messa nell’ultima ver­sione e che trovo demenziale.

Questa è la vec­chia versione:

Screenshot della vec­chia versione

Semplice, no? La clas­sica inter­fac­cia da appli­ca­zione iPhone. Bene, que­sta invece è la nuova:

Screenshot della nuova versione

Ora, io non sono un esperto di GUI, tutt’altro, ma il tab dei sug­ge­ri­menti mi sem­bra pian­tato lì così, al primo posto che capi­tava; sem­bra un pro­to­tipo. Mah.

Piuttosto avrei tolto l’icona dei “Pending” che serve solo a dirti le note che sta sin­cro­niz­zando — fun­zione che può essere svolta benis­simo dall’icona dell’applicazione, tanto più in un ambiente che non con­sente pro­cessi in back­ground — e, se pro­prio era rite­nuto così impor­tante, avrei messo il clas­sico punto di domanda dell’aiuto in linea.

Qualche tempo fa avevo segna­lato uno stu­dio sull’efficacia nell’alternare il colore delle righe di una tabella.

Poiché si dà spesso per scon­tato che que­sta solu­zione sia migliore, c’è stata una certa sor­presa nel vedere che non c’erano dif­fe­renze significative.

Io mi ero per­messo di met­tere in dub­bio che la solu­zione testata fosse effet­ti­va­mente la più adatta. In ogni caso adesso abbiamo nuovi dati che sono forse un po’ più in linea con le aspettative.

Se vogliamo tro­vare il pelo nell’uovo, ho la sen­sa­zione che si voglia tro­vare il modo di dimo­strare che que­sta solu­zione ha un qual­che van­tag­gio. Di fatto i risul­tati non sono gran­ché migliori se tra­scu­riamo ’impatto estetico.

Aggiungo anche che forse il vero para­me­tro da misu­rare non sta nella pre­ci­sione della rispo­sta, ma nell’impegno che biso­gna met­terci; ad esem­pio misu­rando il tempo impie­gato a com­ple­tare un certo compito.

Cerchiamo astra­zioni, pos­si­bi­lità per sem­pli­fi­care, sin­te­tiz­zare e ridurre a prin­cípi primi ad ogni angolo. La ricerca dell’astrazione è tal­mente pre­sente che in Java, ad esem­pio, abstract è una parola chiave del lin­guag­gio e indica classi o metodi privi, in parte o com­ple­ta­mente, di imple­men­ta­zione: indi­cano che cosa ci si aspetta che fac­cia il codice senza dire nulla sul come; in astratto, appunto. Secondo alcuni un ter­mine più adatto è gene­ra­liz­za­zione ma sto diva­gando: il punto che voglio evi­den­ziare è l’atteggiamento di fondo nella programmazione.

Parte di que­sta ricerca è legata ai ter­mini. L’utilità dei pat­tern, ad esem­pio, sta anche nel tro­vare il nome adatto: “qui ho usato un visi­tor”, “i sin­gle­ton sono da evi­tare” e così via. E in molti libri sul design del soft­ware si enfa­tizza (troppo, secondo me) l’importanza della nome­cla­tura per i metodi e le classi. 

Non dob­biamo però dimen­ti­care che gli utenti spesso la vedono nel senso esat­ta­mente oppo­sto, usano il ter­mine più spe­ci­fico e più con­creto. Soprattutto a livello di inter­fac­cia, usano le parole che meglio descri­vono azioni e oggetti che hanno sott’occhio in quel momento. Certo, parte della dif­fi­coltà del design del soft­ware con­si­ste pro­prio nell’allineare le pro­prie astra­zioni con quelle dell’utente, ma non dob­biamo dimen­ti­care che sono solo que­ste ultime (le astra­zioni dell’utente) quelle che alla fin fine contano.

Prendiamo ad esem­pio Get Satisfaction. Si nota lo sforzo di usare una ter­mi­no­lo­gia il più pos­si­bile adatta all’utente: il form prin­ci­pale fa di tutto per non sem­brare tale e usa un approc­cio gra­duale per non sco­rag­giare gli utenti. 

All’inizio, quando ho comin­ciato a dare un’occhiata al sito qua e là, ho tro­vato i ter­mini e le frasi un po’ ridon­danti, ansiosi di essere friendly, ma la dire­zione è quella giusta.

Viceversa, mi ricordo di un pro­to­tipo di un’applicazione di qual­che tempo fa, in cui l’azione per creare dei record, qual­siasi record, era chia­mata, indi­stin­ta­mente, “Nuovo oggetto”. È un’astrazione? Certo, ed è quella del tipo giu­sto: l’azione è sem­pre la stessa ed è sem­pli­ce­mente appli­cata ad oggetti diversi; tut­ta­via, non è un’astrazione che dev’essere espo­sta all’utente.

Se si lavora in squa­dra e ci occu­piamo solo di una parte di un’applicazione tutta que­sta tirata non ha molta impor­tanza, ma se abbiamo a che fare con diverse parti, soprat­tutto se sono vicine all’interfaccia, la que­stione cam­bia e richiede un certo sforzo per adot­tare due atteg­gia­menti men­tali che vanno conciliati.

Leggendo que­sto arti­colo (in par­ti­co­lare il punto 10: Placating peo­ple with options) mi è tor­nato in mente un mio post di qual­che giorno fa, guarda caso.

Continuo a dubi­tare che i pro­getti open source pos­sano avere grandi qua­lità di usa­bi­lità: non si è mai visto un gruppo di per­sone, tutte con lo stesso potere deci­sio­nale, pro­durre un qual­che risul­tato artistico/estetico apprez­za­bile; a dispetto della giu­sta enfasi sul lavoro di squadra.