Newsgroup: it.lavoro.informatica
Titolo: Designed, engineered e overweight, low-probability events

Il tipo mette l'accento su un tema che mi ha interessa molto :
l'importanza del "designed" over l' "engineered".  Cioè
dell'importanza di come disegni l'interfaccia e come immagini
l'interazione dell'utente.
Ed anche dell' "overweight, low-probability events"  : errore comune
che prima della sua definizione non sapevo come chiamare. Spesso ti
ritrovi a fare un'applicazione che sarebbe tanto lineare e semplice,
ma per gestire il caso particolare, l'opzione diabolica pensata
dall'analista scrupoloso  ti ritrovi a complicare a dismisura il
software, e poi quando la vai a spiegare all'utente quello manco la
capisce .
PS: Si parla sempre di Nokia, ma è un caso.
When I arrived at Nokia, the folks down the road at NRC were very
proud of something they’d ginned up: an NFC-equipped, but otherwise
entirely conventional, vending machine. At last!, I thought, here’s a
concrete step toward the future of everyday transactions. And in what
was, from my perspective, the very best kind of context: that of an
interaction so banal and unremarkable that it undermined any
conceivable charge of utopian handwaving. Whatever frisson of futurism
you derive from the encounter quickly subsides beneath the threshold
of the ordinary, which — per all my gurus, from Don Norman to Jasper
Morrison and Naoto Fukasawa — is exactly as it should be.
Except that, as realized by Nokia, this is precisely what failed to
happen. I experienced, in fact, neither a frisson of elegant futurism
nor a blasé presentiment of everyday life at midcentury. I was given
an NFC phone, and told to tap it against the item I wanted from the
vending machine. This is what happened next: the vending machine
teeped, and the phone teeped, and six or seven seconds later a
notification popped up on its screen. It was an incoming text message,
which had been sent by the vending machine at the moment I tapped my
phone against it. I had to respond “Y” to this text to complete the
transaction. The experience was clumsy and joyless and not in any
conceivable way an improvement over pumping coins into the soda
machine just the way I did quarters into Defender at the age of
twelve.
It’s not that the NFC-based, phone-to-object interaction didn’t work.
--- Of course it did: it had been engineered perfectly. But what it
hadn’t been was designed.  -----
Those responsible for imagining the interaction apparently wanted to
protect users against the (edge case!) contingency of someone making
off with their phones and running up a huge vending-machine tab. They
failed to understand that, for low-value transactions like this, at
least, the touch gesture is a useful proxy for consent — and that if
someone’s got physical possession of my phone, I’m likely to have
bigger problems than whether or not they order a few cans of Coke with
it. A designer committed to the user and the quality of that user’s
experience gets this in a way only the rarest engineer seems to.
Designers are also, by training and predilection, inclined to design
for the usual, where engineers are taught a kind of rigor that compels
them to account for, and overweight, low-probability events.
http://speedbird.wordpress.com/2011/02/19/nokia-culture-will-out/

 l'interazione dell'utente.
IMHO il problema e' a monte, non a valle.
Ovvero il problema non e' come qualcosa viene progettato, ma dai
limiti di progetto imposti da marketing/commerciali/avvocati/ecc. ecc.
L'esempio dell'articolo e' IMHO lampante.
Sono sicuro che la prima cosa pensata dal progettista e' stata di fare
le cose semplici, poi il solito commerciale ha iniziato a cagarsi
sotto per eventi tipo appunto furto di telefonino e paranoie del tipo
"e se l'utente non e' davvero convinto di comprare ?" e ha richiesto
"accorgimenti" che alla fine hanno vanificato la bonta'
dell'applicazione.
O, se preferisci, il problema e' nell'idea che troppi, sempre "non
tecnici", hanno della tecnologia, ovvero un qualcosa che puo'
risolvere tutti i problemi, sopratutto quelli non tecnici.

 limiti di progetto imposti da marketing/commerciali/avvocati/ecc. ecc.
Si, può essere, ma il punto dove si trova il problema è marginale
rispetto al problema in se. Nel mio caso ne faccio addirittura un
limite personale, ovvero cerco sempre di tenere a bada il "tecnicone"
che è in me che vorrebbe gestire tutto in modo parametrico e
generalizzato per finire a gestire che cose che solo negli ultimi anni
ho imparato a dire.. ma chi se ne frega se quel caso non è coperto !
Un po' mi ha aiutato getting real con il paradigma della convenzione
al posto della configurazione ed un po' Apple con il suo bottone solo.
Ma è un argomento che nella progettazione è troppo troppo
sottovalutato, l'interazione e sopratutto l'esperienza utente.
Anche perché i vari libri a cui mi sono avvicinato sulla user
expirence ed usabilità ( sopratutto web) sono stati una vera e propria
delusione, puzzano troppo di fichettaggine 2.0, pochi dati, pochi
studi seri e tanti nomini trendy.

 it.
Non posso che confermare che questo è quello che succede qui
giornalmente.
-- 
Salvatore Iovene
http://www.iovene.com/
http://www.geekherocomic.com/

 dell'applicazione.
Mah, non saprei, secondo me l'esempio non è scelto bene: a me pare che
l'idea sia comunque una bischerata, anche se la ridisegni ;^)
Si parla pur sempre di una transazione, per quanto di piccolo importo,
e non la vedo sbagliata di prevedere comunque un qualche tipo di
conferma prima della conclusione: sono d'accordo che così com'e' stata
realizzata sia subottimale, ma non è che togliendola si ottiene un
prodotto più attraente.
bye!

 it.
Una decina di anni fa, forse di più, io usavo gli Akbil, oltre che per
portafoglio elettronico per pagare i biglietti per i vari servizi del
trasporto pubblico, anche per comprare le lattine di aranciata ad
Istanbul:
http://en.wikipedia.org/wiki/Akbil_(smart_ticket)
Appoggiavo il bottone nell'apposito lettore, click, e scendeva la
lattina.
--
ale
http://ale.riolo.co.uk

 capisce .
Nella mia esperienza il cliente certamente capisce poco e si scoccia
se fai un'analisi scrupolosa dei vari casi, anche estremi. Però quando
il caso particolare si verifica, e per tua sfortuna non l'hai gestito,
non è che vuole capire più di tanto... Protesta e basta.
Quindi l'abilità dell'analista e del progettista è pesare i "low-
probability events" in modo da gestire da subito quelli che in qualche
modo possono essere i più critici. Cioè, come sempre, l'abilità e
bravura sta nel trovare l'equilibrio migliore. Ecco perchè non tutti
sono bravi uguali a fare l'analista e/o il progettista, nè sono
intercambiabili persone con esperienza in problematiche molto diverse
dell'IT . Checchè se ne dica.

 >> Ed anche dell' "overweight, low-probability events"  : errore comune
 >> che prima della sua definizione non sapevo come chiamare. Spesso ti
 >> ritrovi a fare un'applicazione che sarebbe tanto lineare e semplice,
 >> ma per gestire il caso particolare, l'opzione diabolica pensata
 >> dall'analista scrupoloso  ti ritrovi a complicare a dismisura il
 >> software, e poi quando la vai a spiegare all'utente quello manco la
 >> capisce .
 i> Nella mia esperienza il cliente certamente capisce poco e si scoccia
 i> se fai un'analisi scrupolosa dei vari casi, anche estremi. Però
 i> quando il caso particolare si verifica, e per tua sfortuna non l'hai
 i> gestito, non è che vuole capire più di tanto... Protesta e basta.
 i> Quindi l'abilità dell'analista e del progettista è pesare i "low-
 i> probability events" in modo da gestire da subito quelli che in
 i> qualche modo possono essere i più critici. Cioè, come sempre,
 i> l'abilità e bravura sta nel trovare l'equilibrio migliore. Ecco
 i> perchè non tutti sono bravi uguali a fare l'analista e/o il
 i> progettista, nè sono intercambiabili persone con esperienza in
 i> problematiche molto diverse dell'IT . Checchè se ne dica.
Molto interessante.
Prima di tutto manterrei ben distaccato il concetto di casi critici da 
quelli ow.lpe in quanto è più un augurio che poi magari la realtà.
Nella mia esperienza noto che l'ow.lpe deriva non tanto da una forzatura 
voluta ma, una volta inquadrati gli eventi, dal continuare a considerarli 
paritari.

 sono bravi uguali a fare l'analista e/o il progettista, nè sono
Quello non e' fare il progettista e l'analista, e' cercare di
"indovinare" il "gusto quadratico medio" dell'utenza e non
spaventarla.
Vedi cosi' programmi con grafiche fichissime, tutto luci e colori e
una stabilita'/affidabilita' pari ad un banco di sabbie mobili.
C'ya
  STeve

 prodotto più attraente.
Devi sempre vedere l'ambiente in cui operi.
Stai comprando una lattina di coca, non una Ferrari.
C'ya
  STeve

 Stai comprando una lattina di coca, non una Ferrari.
Certo. Ma anche quando prendo un caffè da pochi centesimi alla
macchinetta, se invece esce solo acqua calda, lo devo pagare due volte
e mi incazzo lo stesso. Meno che se mi rubassero la Ferrari, ma mi
incazzo ;^)
Per cui sempre contestualizzando, se c'e' un'alternativa che mi pare
esposta a meno incazzature (una vending machine che non si inceppa, o
un sistema di acquisto meno prono ad errori) uso quella...
bye!

 sufficientemente a prova di inconvenienti. Che poi, ripeto, anche se
si però io la ricerca della conferma sicura la farei fisica e non
software, ovvero con un'aerea ben delimitata sulla macchina dove
appoggiare il telefono e magari con la necessità di tenerla 3-5
secondi accompagnando il tutto con una luce lampeggiante o che so io.
La soluzione SMS e pressione del tasto Y è invece un classico errore
di design al ribasso, usando quel che già c'è (sms) per una cosa
diversa, al limite potresti fare un pulsante da tenere premuto sul
telefono mentre paghi, ma non puoi complicare la cosa più di mettere
una monetina in una fessura.

 una monetina in una fessura.
concordo su tutto ;^)
bye!

 capisce .
La mia esperienza dice pero' che, se per sfortunata ipotesi non prevedi
il caso particolare, tempo mezz'ora l'utente sarà in grado di incappare
PROPRIO quel caso che non avevi previsto.
Non so se sia un corollario alla legge di Murphy. Se non lo è, pero',
dovrebbe esserlo.
-- 
Ciao!
Luca