conundrum

Il mio nome viene invocato invano a riguardo della querelle scatenata da un certo finlandese, e che ha scatenato un mezzo putiferio in giro per blog, slashdot e compagnia cantante e ballante.

Comincio col rispondere a Ikitt: è Torvalds, sicuro come l’oro; perché è il suo stile, e dice cose che ripete da tempo.

Mettendomi le Mutande di Ermellino Delle Grandi Occasioni (© Luigi Rosa), il qualità di maintainer di un paio di pezzi di GNOME, posso affermare che la mail di Linus non sposta di un epsilon la balance of power: è come se avesse detto che EMACS fa schifo e che tutti dovrebbero usare Vi; ovvero: le guerre di religione c’erano prima, ci sono ora e ci saranno in futuro. Personalmente, ritengo che un progetto che o si ama o si odia (e che, quindi, sviluppa intorno a se una valanga di commenti estremamente polarizzati) sia molto meglio di un progetto a cui nessuno si appassiona.

Tolte le mutande di ermellino (che prudono), posso dire che Linus ha ragione e contemporaneamente ha torto:

• negli ultimi due anni, le HIG sono state prese come il vangelo, o usate come grimaldello per avere ragione (diceva Bryan Clark che alcuni gli citavano interi brani a giustificazione delle loro posizioni, senza sapere che lui è stato uno degli autori);
• le HIG sono un po’ come il Codice dei Pirati: delle guide lines, non qualcosa da prendere alla lettera; e, soprattutto, non sono “un algoritmo di design”: le HIG intervengono a design ultimato, per conferire un look and feel condiviso; ad esempio, non diranno mai quali e quante opzioni mettere in una finestra di dialogo - bensì diranno, tra le altre cose, quanti pixel dovranno essere distanziate le opzioni tra loro;
• GNOME ha subito una riscrittura parziale tra la release 1.4 e la release 2.0; a dire il vero, stiamo ancora buttando via della roba scritta con il culo^W^Wmale che risale a quell’epoca - vedi il Dizionario, che sto riscrivendo da almeno un paio di mesi e che dovrebbe essere nella prossima release, la 2.14; nella riscrittura, molte cose sono state eliminate perché indiscutibilmente stupide o decisamente rotte; si raggiunse uno stato minimo funzionante da cui partire. Attivo la modalità “vecchio scorreggione” per un semplice aneddoto che dovrebbe spiegare cosa quale fu l’accoglienza a questa operazione necessaria e faticosa. Quando uscì la release 2.0 i pannelli non supportavano più uno stato “traslucido” come nella 1.4; ci furono stracciamenti di vesti, urla allo scandalo: “come faremo senza più pannelli traslucidi!” - come se, effettivamente, fosse una cosa fondamentale per cui rallentare una release già in ritardo; ricordo benissimo che dissi su it.comp.os.linux.iniziare: “il codice del pannello è stato riscritto da capo, e la parte che lo rende traslucido non è ancora stata implementata”. Ovviamente, nella release successiva, a codice stabile, la feature venne re-implementata;
• la riscrittura di cui sopra ha eliminato molte feature, e mano a mano altre sono state di eliminate; non di meno, un semplice giretto all’interno di GConf ($ grep -r "<entry " $HOME/.gconf | wc -l) mi dice che ci sono 1040 opzioni impostate - e Cthulhu solo sa quante impostabili e in quanti modi (alcuni sono settaggi booleani, ma altri sono stringhe, interi, in virgola mobile, liste e perfino coppie). Non è una buona metrica, ma dovrebbe dare un’idea.
• nessuno ha ancora infilato GNOME in una ROM; men che meno, nessuna distribuzione installa GNOME in una locazione read-only: se ti senti limitato da GNOME, prego - ci sono altri DE; personalmente, adoro ION. Di contro, però, se qualcuno vuole sviluppare GNOME, si potrebbe anche evitare di definire i core developer dei fucking idiots; checché ne dica Linus Torvalds, the majority of users wants a simple print dialog non è una stronzata: è, purtroppo, l’amara verità. Gli utonti sono la maggioranza, sono intorno a noi, e per farli scomparire non servirà niente di meno di un’asteroide delle dimensioni di quello che ha estinto i dinosauri. E gli utonti, se potessero, vorrebbero un bel pulsantone con su scritto: “Stampa e non rompermi il cazzo”. È anche vero, però, che non bisogna rimuovere funzionalità, e nemmeno metterla dietro quella patetica non-decisione che è la “modalità esperto”: è dimostrabile come dopo dieci minuti di utilizzo, tutti gli utonti tenteranno di usare la modalità esperto nel vano tentativo di applicare una qualche forma di ingegneria sociale sulla macchina, nella convinzione che se viene trattata da “un esperto”, questa funzionerà meglio e prima - ovvero, leggerà cosa fare nel cervello degli utonti. “Nascondere” le impostazioni per esperti significa fare in modo che non si vedano mai a meno che non decida l’esperto di vederle; come fare è la parte interessante del lavoro di noi sviluppatori, ed è l’oggetto degli studi di usabilità.
• se qualcosa non funziona, è inutile mettersi a piangere, sbattere i piedi per terra, inviare flame o girarci intorno; se qualcosa non funziona, scrivete cosa qui; se ci aggiungete una patch, sarete perfino baciati sulla fronte dal maintainer;
• infine: se ogni volta in cui viene rimossa una feature gli utenti pensano che ci sia stato uno studio di usabilità (per quanto sbagliato) dietro, allora vuol dire che abbiamo colto nel segno, e che servono studi di usabilità; è anche vero che questo tendenzialmente non avviene: se si sacrifica una feature è perché: 1. era troppo oneroso scriverla; 2. era troppo oneroso mantenerla; 3. il maintainer c’aveva le palle girate e non voleva più vedere quella chiave GConf in giro per il suo codice. Il che non significa che quella feature sparisca: se la volete, rompete i coglioni al maintainer e fatevi spiegare perché è stata tolta e come fare per rimetterla. Se vi andrà bene, il maintainer vi risponderà è stata tolta perché nessuno l’ha portata alla nuova versione. Certo, non chiedete di rimettere la visualizzazione dei documenti all’interno di Nautilus, perché altrimenti vi pigliate anche dal sottoscritto un sonoro “vaffanculo”.

[gnome]
[gnome+usability]