Silverlight 4 alla ricerca del doppio-click perduto

E’ da qualche giorno che ho in testa questo post, e lo sto scrivendo nella mia testa, ponderando bene le parole ed i termini da utilizzare. Probabilmente martedì mattina è stata la mia peggior giornata lavorativa da un bel pezzo a questa parte, e vi posso assicurare che ce ne vuole.

Ritengo la mancanza del doppio-click in Silverlight 4 una vera e propria cazzata.

Gli esperti non me ne vogliano, ma dire che SL4 è un framework pensato per il Web e quindi il doppio-click è male, è semplicemente assurdo, vuol dire negare la realtà e vuol dire adeguarsi passivamente a ciò che ci è stato imposto, senza pensare con un po’ di creatività e senza un minimo stimolo a migliorare le cose per il futuro.

Silverlight 4 non è un framework pensato per il Web: SL4 è un framework per la realizzazione di applicazioni distribuite sul Web. Ne usufruite per la maggior parte all’interno del vostro browser, ma girano sul vostro PC e dal punto di vista tecnico sono più vicine ad un’applicazione desktop che ad altro. SL4 è anche il framework che usiamo/useremo in futuro per scrivere applicazioni su Windows Phone 7, e non è affatto detto che siano Web. Con SL4 posso scrivere videogiochi, software per la contabilità personale, per ricordarmi le medicine da prendere, per prendere appunti: applicazioni di qualsiasi tipo. E un’applicazione degna di questo nome deve poter permettere all’utente di interagire con il doppio-click. Punto.

Windows consente l’utilizzo del doppio-click: perchè una mia applicazione SL4 out of browser non dovrebbe permetterlo?

E poi, lasciate che vi dica una cosa: dire che sul Web non si dovrebbe usare il doppio-click a me sembra una regola di usability, e non una questione tecnica o simili. Una regola di usability non dovrebbe essere cablata nel framework che sto utilizzando. Altrimenti di questo passo non dovrebbe permettere di scrivere del testo verde su background verde. Non dovrebbe permettere di inserire più di 5000 elementi in una ListBox. Insomma, certe cose sono e devono essere a carico del developer, e non stupide limitazioni inserite nello strumento tecnologico che si sta utilizzando per il proprio lavoro. Un framework dovrebbe permettere ad un dev di raggiungere il suo scopo, nel bene e nel male: se la mia app è scritta bene e funziona bene, ne venderò 1.000.000 di copie, altrimenti nessuna. E sinceramente decidere di voler usare il doppio-click non mi sembra così male.

Seguendo questo ragionamento, non avrebbero dovuto inserire nemmeno l’evento MouseWheel: avete mai visto un sito Web che gestisce la rotellina del mouse? Se lo avete visto, non era un sito Web: era un’applicazione. Tutti i sw gestiscono la rotellina, per zoomare avanti e indietro. In giochi come Call Of Duty posso cambiare arma, con la rotellina. Posso scrivere app in SL4 che con la rotellina scorrono gli elementi di una ListBox, e poi su quest’ultima non posso gestire un banale e semplice doppio-click?

Lasciate che vi dica un’altra cosa: negli ultimi decenni (2 o 3, non esageriamo) è il modello di programmazione Web che pian piano si è concettualmente spostato verso il modello di programmazione Desktop. Probabilmente sono la persona meno indicata per dirvelo, ma dal punto di vista utente ho visto comparire sul Web modalità di interazione tipiche del desktop: finestre di dialogo modali, drag’n’drop, etc. etc. Anche per noi sviluppatori la cosa è fin troppo evidente: cosa sono le Web Forms se non la trasposizione sul Web delle Windows Forms? Anche nel loro comportamento, intendo dire, copiano in tutto e per tutto una tipica applicazione desktop. E’ giusto che sia così, perchè i due mondi si sono e si stanno avvicinando sempre di più, a volte toccandosi nel caso di Silverlight che – lo ripeto – è a tutti gli effetti un sw locale, che gira sul vostro PC e sfrutta le risorse locali del vostro PC.

Altra questione: ma Silverlight non doveva sin dalla prima release essere allineato al 100% con la sua controparte WPF? Ora, mi rendo conto che non è dal tutto possibile, perchè sono stupido ma non fino a questo punto. Però un conto sono limitazioni tecniche oggettive, un conto è aver stabilito a tavolino che un developer Silverlight non può gestire mai, in nessun caso, un semplice doppio-click. La cosa secondo me divertente è che in WPF posso farlo su qualsiasi controllo, anche dove dal punto di vista della usability sarebbe assurdo: perchè? Perchè è compito del developer fare ciò che è più giusto: nessuno si sognerebbe mai di fare doppio-click su un Button, semplicemente perchè con un Button non si interagisce così. E così via, gli esempi si sprecano.

E poi, teniamo presente che in WPF/Silverlight possono customizzare l’aspetto di ogni controllo. Posso far apparire un Button come una ListBox e viceversa. Posso customizzare ogni cosa. Microsoft mi dà una potenza ed una libertà mai avuta prima, e poi non mi permette per definizione la gestione del doppio-click. Cavolo, ce l’avevo in Visual Basic 4.0 quasi 20 anni fa!!

E non venitemi a dire che – sì, certo – puoi comunque gestirlo: basta contare il tempo in ms tra un click e l’altro. Stiamo scherzando? Con tre click posso creare un’applicazione con i RIA Services, e poi devo passare un giorno intero a gestire due eventi MouseDown contando il tempo per vedere quando e come si scatena un doppio-click. Avendo cura, sia chiaro, di confrontarlo con il tempo impostato nel sistema operativo, altrimenti…

E’ apparsa ieri una scritta in una slide nel’evento GroundZero di DotNetLombardia: “Let brighest developers builds business application”. Sul fatto che io sia un brightest developer è tutto da vedere, ma il focus è che noi developer di applicazioni finali dobbiamo preoccuparci di costruire le applicazioni per far guadagnare le nostre aziende, e non litigare per l’ennesima volta per trovare un workaround ad una evidenza mancanza dello strumento di sviluppo che si sta utilizzando.

La mia paura, tra l’altro, non è tanto ‘sto bendetto doppio-click (che è solo la goccia che ha fatto traboccare il vaso), ma è l’idea che qualcuno là a Redmond, o dove diavolo sta il palazzo dove si sviluppa il .NET Framework, decida a tavolino di togliere questo o quello in base a strane regole che fino al giorno prima non c’erano. Regole di usability, regole dettate dalla moda del momento, senza alcuna certezza che varranno così anche nel futuro.

Insomma, se qualcuno di voi ha voglia di tradurre in inglese questo mio post, lasci pure trasparire un po’ di rabbia e di frustrazione, perchè è esattamente quella che ho provato martedì mattina, e continuerò a provarla ancora per un po’.

Sapete qual’è l’ultima cosa davvero divertente? Non vedo l’ora di leggere le features di SL5, perchè non posso davvero credere che non venga presa in considerazione questa cosa.

Un Igor molto, molto deluso, e che ora può tornare a dormire un pochino.