Brainstorming 2.0

Proliferano articoli, soluzioni, best practices e parole come accessibilità, non intrusività, semantica e chi più ne ha più ne metta.

Quello che vedo, personalmente, è un calderone dove tutto va bene ma niente è perfetto o per assurdo tutto è perfetto ma niente va bene, almeno per le reali esigenze di un sito, portale, applicativo, che appartiene all’esercito del Web 2.0 .

Poche ore fa, Ajaxian pubblica, quasi fosse una news degna di nota, come rendere non intrusivo un link… dove per non intrusivo si intende usare un framework JavaScript, non certo noto per la sua leggerezza per cambiare il comportamento di un link.

Ben fatto, bastavano 20 bytes ma poco importa poiché con una sola chiamata al framework la popup diventerà praticamente inevitabile.

Questo va in totale contrasto con accessibilità e usabilità, poiché non dovrebbe essere lo sviluppatore, salvo rari e particolari casi, a decidere per l’utente cosa un link debba fare.

Solo uno dei numerosi esempi di come rendere più complicata la navigazione a favore di effetti mirabolanti capaci spesso di innervosire il visitatore, di fargli perdere tempo o, peggio ancora, di disorientarlo.

Come sfruttare quindi JavaScript per migliorare di fatto la user experience?

Comincio io il brainstorming:

1. soprattutto se si utilizza Ajax, è un totale contro senso inviare eventi in linea per ogni elemento della pagina, esistono numerosi modi per aggiungere funzionalità tramite client senza spreco di banda per l’utente e per il server
2. dato che un link è per natura stessa … un link! … evitare di vincolarne il funzionamento quando possibile, poiché se non deve comportarsi come un link, il tag <a> perderebbe di significato
3. dato che la suddivisione dei compiti è fondamentale e in alcuni ambienti di sviluppo maniacale, che ognuno faccia la sua parte: il server non dovrebbe stabilire funzionalità client ma al massimo consigliare un comportamento; il client, nel caso di Ajax, non dovrebbe vincolare il server ma solo prendere e fornire informazioni nel miglior modo possibile; il css deve rappresentare il layout e non dovrebbe essere stravolto dal client o forzato dal server (hacks esclusi)… e via così, dando per assunto inopinabile che client non è uno solo, come server non significa solo il linguaggio usato.
   Il client è suddiviso in numerosi parti (CSS, XML, XSLT, XHTML, JavaScript… che comprende DOM e scripting) come il server è composto da linguaggi, databases, webservers, eccetera… basta con la convinzione che sul server tutto deve avere un posto mentre il client è un polverone di tecnologie, a ognuno il suo reale compito senza legarlo ai vari strati presenti prima del risultato finale
4. se il client, inteso come JavaScript o ActionScript, è vincolato in toto da un scambio dati continuo con il server, c’è qualcosa che non va… stiamo sviluppando Web 1.0 con la scusa di sfruttare Ajax perchè va di moda
5. dato che una pagina basata su CSS sarà ben definita in ogni sua parte, sfruttare al massimo selettori e classi, o coppie di più classi, per implementare funzionalità client aggiuntive
6. se il CSS è troppo pesante, c’è qualcosa che non va
7. se il client è troppo pesante, o troppo leggero, c’è comunque qualcosa che non va… non lo stiamo sfruttando a pieno o non lo stiamo sfruttando affatto oppure, per meglio dire, non ne stiamo capendo tutte le potenzialità, tanto valeva non utilizzarlo

La lista continua, vediamo cosa viene fuori dalle mie considerazioni con l’aggiunta dalle vostre?