<- PW: l10n - Indice Generale - Copertina - SL - Intro ->

Il software libero e le buone interfacce utente

di Havoc Pennington
traduzione di Pietro Leone

Il software libero e l'interfaccia utente

Molte persone affermano che il software libero ha difficoltà nel creare delle buone interfacce utente. Recentemente Matthew Thomas ha inviato un bell'articolo su questo argomento, l'ho trovato sul sito di Joel. È stata una piacevole sorpresa trovare questo pezzo, perché delinea chiaramente che cosa sia andato storto in molti progetti, inclusi quelli riguardanti le vecchie versioni dei maggiori desktop Linux/UNIX.

A parte questa lista, vi sono un paio di punti-chiave riguardanti GNOME 2 che considero importanti, anche se non credo che molti "non addetti ai lavori" se ne siano ancora accorti.

• Accessibilità. L'enorme mole di lavoro che la Sun ha investito sulla facilità di accesso in GNOME 2 ci mantiene in corsa come possibile scelta da parte del governo degli Stati Uniti, e non solo. Senza questo sforzo sarebbe stata preclusa l'introduzione del software libero nelle varie amministrazioni statali. (Senza considerare che grazie a questo impegno GNOME 2 è utilizzabile anche da parte dei disabili!) Altrettanto importante è che sia Mozilla sia OpenOffice siano integrati in questa architettura dall'uso particolarmente facile. Molta gente non si rende conto dell'importanza del facile accesso agli strumenti, anche se ne conoscono l'esistenza.
• Utilizzabilità. GNOME 2 ha ancora molta strada da fare, ma, secondo me, ha cambiato la tendenza che Matthew Thomas (ed altri prima di lui) hanno impostato e, quindi, GNOME 2 è la prima versione di un desktop Linux/UNIX che abbia girato questa boa.

Ho intenzione di scrivere parecchio a proposito di questo secondo punto, ed il log del sito di mpt mi ha spinto ad andare avanti. Avete qui alcune mie elucubrazioni, senza alcun ordine; questo non ha l'intenzione di essere un testo rigidamente organizzato.

Che cosa rende un'interfaccia utente una buona interfaccia utente?

Non ho nessuna magica definizione di "buona interfaccia utente" (d'ora in poi GUI: graphic user interface); non sono un esperto in questo campo, ma sicuramente questo non vuole dire grafica carina e tonnellate di caratteristiche. In effetti, quando io penso ad una buona interfaccia, mi immagino il MacOS, quello classico: pulito, semplice, coerente e produttivo. Voi potete concentrarvi sul vostro lavoro o sul gioco preferito e non avrete la GUI fra i piedi. MacOS-X aggiunge anche la bella grafica, ma questa non è ciò che lo fà una buona interfaccia, è solo la parte che la rende bella.

Un altro elemento di una buona interfaccia è l'attenzione ai piccoli dettagli: buoni box di dialogo per gli errori, la possibilità di navigare nella GUI tramite la tastiera, riposizionamento dei contenuti quando cambiate dimensioni di una finestra, accessibilità e localizzazione. Gli utenti, normalmente, non sanno valutare questi aspetti, a meno che non siano degli esperti di interfacce grafiche o non siano dei programmatori di GUI.

Penso di avere un appunto di Cliff su come affrontare una buona interfaccia grafica. I veri progettisti di GUI probabilmente sorrideranno, ma, nonostante tutto, è un buon esempio.

Comunque, quando mi riferisco ad una buona interfaccia, quella rimane una vaga definizione di ciò che intendo.

Come mai il software libero può produrre delle buone GUI.

Date un'occhiata a questa lista (di mpt) delle ragioni per le quali il software libero è carente sotto questo punto di vista:

• non hanno abbastanza progettisti che si dedichino alla GUI
• troppe persone coinvolte nello sviluppo
• i designer non possono sottomettere correzioni al codice
• si limitano a copiare Microsoft ed Apple
• i volontari voglio fare solo cose "fighe"
• i volontari non si preoccupano dei dettagli noiosi
• i manutentori cedono ed aggiungono inutili programmi di preferenze piuttosto che porre fine alle "guerre di religione" per le caratteristiche del software
• tutti vogliono i propri quindici minuti di notorietà
• le "toppe" sono inserite durante il processo di sviluppo e non sono mai più rimosse

Non penso che tutti questi punti spieghino esaurientemente i motivi per cui le GUI del software libero sono tradizionalmente pessime. Ecco il motivo: produrre delle buone interfacce grafiche è difficile.

Lasciate che mi spieghi meglio. ;-)

Prendete tutti i precedenti punti e sostituite i termini "buona GUI" con "buon design del software". Notate che anche così tutti i punti hanno ancora un senso, e di sicuro avrete già sentito questi argomenti in precedenza. Ecco quelli che sarebbero ancora validi:

La gente dice che i buoni sviluppatori non lavorano per niente, che troppi programmatori rovinano il progetto del software, che il software libero non ha caratteristiche innovative, che nessuno porta avanti il noioso lavoro di correzione degli errori, che le "toppe" effettuate male ed in fretta rimarranno per sempre, ecc., ecc. (Mmm, è possibile che Bill Gates stia dicendo le stesse cose ultimamente).

Per quanto riguarda l'architettura del software, però, molti progetti liberi hanno risolto questi problemi. Gli strumenti utilizzati non sono niente di misterioso: una cultura fatta di forti personaggi che guidano i progetti ed insistono perché le cose siano fatte correttamente ha diffuso delle buone linee guida; si tiene traccia dei processi e dei bug; compagnie commerciali portano avanti i lavori più noiosi; si cercano buoni collaboratori e si ignorano quelli incompetenti.

Date un'occhiata al kernel GNU/Linux, ad Apache, a XFree86: tutti questi progetti di successo hanno dovuto confrontarsi con questi problemi nello sviluppo del codice e questo può essere fatto anche per le GUI.

Una buona interfaccia non è differente da un buon software: la qualità in un prodotto è raggiunta tramite un lungo processo, portato avanti da persone in gamba, che miri al miglioramento qualitativo.

Solo uno dei punti è esclusivo delle interfacce grafiche:

Anche se questo fatto ha indubbiamente una sua importanza, non penso che sia fondamentale, e per un buon motivo: non è sempre vero. Seth Nickell, il capo del gruppo dedicato alla GUI del progetto GNOME è famoso per mettere le mani nell'archivio CVS e cambiare le cose. La ragione è anche un'altra: guardando le mailing-list per la gestione dei bug, abbiamo molti sviluppatori che sono disposti a seguire le linee guida per le interfacce grafiche, fissarne i bug e che chiedono consigli al gruppo che si occupa dello sviluppo della GUI. Abbiamo infine i progettisti che lavorano per le ditte che contribuiscono allo sviluppo di GNOME, ed essi hanno, normalmente, la capacità di influire sul lavoro degli sviluppatori appartenenti alla loro stessa compagnia.

(È vero che i designer della GUI devono spendere più tempo per convincere gli altri a fare le cose perché così-devono-essere-fatte, ma questo è vero per chiunque sia coinvolto in un progetto open-source. Alcune persone hanno la personalità necessaria per fare questo, altri no.)

Se tutti questi punti si applicano anche allo sviluppo del software, e se i progetti del software libero sembrano produrre degli ottimi applicativi, come mai essi hanno quasi sempre generato delle pessime interfacce grafiche? Di nuovo, creare delle buone GUI è difficile; più in dettaglio:

• è difficile imparare come fare delle interfacce grafiche di qualità; questo è un campo in cui devono lavorare degli esperti, e normalmente la gente non ha neanche una conoscenza di base di questo argomento;
• la programmazione di una GUI è difficile da imparare. Rispondendo alle domande degli sviluppatori nuovi a GTK+, ho visto centinaia di persone attraversare i medesimi stadi: quello in cui si pensa di farsi da sé la GUI oppure quello in cui capiscono finalmente cosa significhi "event-driven";
• le interfacce grafiche danno molto lavoro, anche quando si sa bene come farle, ed anche se le compagnie hanno investito centinaia di milioni nel kernel Linux per farlo evolvere da semplice giocattolo a qualcosa che potesse interessare anche le aziende, solamente adesso hanno iniziato ad interessarsi all'interfaccia grafica;
• le GUI che vogliano essere competitive con Windows o MacOS-X richiedono una certa infrastruttura tecnica per essere sviluppate. La disponibilità di moderni pacchetti come GTK+2 o QT3 (piuttosto che Xt o Tk) è un grosso passo avanti, anche se abbiamo ancora molta strada da fare soprattutto a livello dei sistemi per le interfacce ^[1].

In breve, le nostre GUI facevano pena per la stessa ragione per cui faceva pena la versione 1.0 del kernel Linux: non erano ancora mature. La creazione di una buona interfaccia grafica si basa sulla creazione e sull'organizzazione efficiente di un gruppo abbastanza vasto e coordinato di programmatori per un lasso di tempo sufficientemente lungo.

Nel progetto GNOME, la mia sensazione è che stiamo effettivamente andando nella giusta direzione per creare una buona GUI. Ecco i motivi per i quali la penso così:

• abbiamo diversi buoni progettisti di interfacce grafiche e degli ottimi capi-gruppo. Penso che questo sia da attribuire in parte al fatto che Sun e Ximian stanno pagando il lavoro di questi programmatori, ed in parte grazie all'influenza della Eazel;
• gli sviluppatori hanno una comprensione di base delle interfacce grafiche e possono essere d'aiuto nel caso di domande riguardanti la GUI nelle mailing-list od in bugzilla;
• i programmatori hanno imparato a scrivere del codice efficiente per le GUI;
• la nostra cultura incoraggia lo sviluppo di buone interfacce grafiche e scoraggia le caratteristiche belle, ma inutili. Non importa quanto bene si possa programmare, gli sviluppatori di GNOME non saranno impressionati dal tuo lavoro se la GUI non è all'altezza.

I bug dell'interfaccia sono considerati come normali bug in bugzilla, vengono corretti, e coloro i quali non correggono gli errori della propria GUI sono considerati degli incompetenti. I bug della GUI sono come quelli presenti in qualunque altro software: qualcosa di cui doversi preoccupare.

Non si sta parlando di scienza missilistica, qui, è solo questione di creare una massa critica di persone che capisca quale sia la cosa giusta da fare e che abbia le risorse per andare avanti e per completare il lavoro.

Nell'ultimo anno, specialmente negli ultimi sei mesi, ho la sensazione che abbiamo finalmente girato la boa e posso dirvi ciò che serve per creare una GUI che possa essere competitiva con MacOS-X o WindowsXP. Abbiamo inoltre usato correttamente le risorse a nostra disposizione, e possiamo affermare di avere fatto dei sensibili progressi per alcuni degli aspetti più impegnativi. C'è, però, ancora una montagna di lavoro da fare.

[1] Il kernel ed il sistema operativo spesso non offrono le caratteristiche che si vorrebbero per creare una GUI che possa competere con MacOS-X o WindowsXP, e molti dei programmatori che lavorano a basso livello, anche i più famosi, non capiscono come debba essere fatta una buona interfaccia grafica o come scriverne una. Essi non possono, quindi, essere d'aiuto per migliorare la situazione. Ovviamente neanche io posso aiutare per il kernel, non sto assolutamente criticando nessuno, sto solo suggerendo che dovremmo avere più gente esperta in entrambi i campi oppure avere una maggiore comunicazione fra i due distinti gruppi di lavoro.

Le compagnie commerciali sono d'aiuto oppure no?

mpt afferma in una breve nota che sia Eazel che Ximian hanno danneggiato il progetto GNOME. Mentre queste sono delle aziende ad alto profilo dedicate a GNOME, i fornitori di sistemi operativi (RedHat, Sun, Hewlett-Packard, Mandrake, ecc.) sono anche grossi nomi del campo. Questo è il mio pensiero riguardo la faccenda, anche se voi potrete considerare il mio punto di vista di parte in quanto lavoro alla RedHat.

Ogni ingresso di sviluppatori commerciali ha un certo costo. Diverse volte abbiamo avuto un certo numero di sviluppatori a tempo pieno che si sono aggregati all'attuale gruppo di sviluppo. Come predetto da Fred Brooks, questo ha portato ad alcuni ritardi: per ogni nuovo team abbiamo dovuto formalizzare e migliorare il nostro processo di sviluppo ed imparare ad adattare il progetto a più partecipanti; inoltre i nuovi sviluppatori hanno bisogno di tempo per "prenderci la mano".

Si possono inoltre di sicuro criticare alcuni difetti di alcune GUI dovuti a realtà commerciali; Nautilus, per esempio, penso avrebbe dovuto essere maggiormente integrato nel desktop se non fosse stato il prodotto di punta della Eazel, ed è anche stata una sfortuna che la compagnia sia scomparsa prima che il progetto raggiungesse la fase di rifinitura. (GNOME 2 ha comunque in gran parte risolto entrambi i problemi) Allo stesso tempo la Eazel ha introdotto il concetto di facilità d'uso in GNOME, e la maggior parte del codice di Nautilus è ottimo. Tirando le somme, il risultato è positivo.

Secondo me il contributo a GNOME delle compagnie commerciali è stato cruciale per il nostro successo:

1. avere degli sviluppatori a tempo pieno è molto utile, rendono facile la possibilità apportare modifiche sostanziali ed aiutano nello svolgimento del lavoro più noioso;
2. il processo e l'infrastruttura che abbiamo sviluppato per gestire un gran numero di sviluppatori a tempo pieno che lavorino a GNOME ha provocato dei ritardi nel breve termine, ma si sta dimostrando fondamentale nel lungo periodo;
3. le compagnie produttrici delle distribuzioni hanno effettuato una quantità enorme di correzioni agli errori presenti;
4. abbiamo così dei progettisti professionisti per l'interfaccia utente e molti persone per le prove (vedere qui);
5. ci ha permesso di capire i problemi incontrati dagli utenti del "mondo reale"
.

Mentre potete certamente puntare il dito sugli errori causati da persone che lavorano per le aziende, non me la sento di condannare il misterioso lavoro fatto dalle società. Molto di esso è il tipo di lavoro necessario quando un progetto coinvolge non più cinque sole persone, ma trecento. I maggiori problemi sono quelli causati dalla gestione delle relazioni interpersonali, non di quelle interaziendali, e, dal punto di vista generale, GNOME è ora molto più armonico rispetto alla mailing-list del kernel di linux, oppure alle leggendarie battaglie che coinvolgono il Perl.

La GNOME Foundation è stata fondamentale nel trarre vantaggio dai contributi dati dal mondo commerciale, senza compromettere l'integrità del progetto. La fondazione ha chiaramente dato le redini in mano ai membri del progetto GNOME, ed io mi aspetto che il lavoro della maggior parte di queste persone resti su base volontaria.

Molti altri progetti, come il kernel di Linux ed Apache, sono riusciti a trarre enormi benefici dai contributi delle aziende, senza sacrificare particolari obiettivi tecnici. Questo, secondo me, sta accadendo anche a GNOME.

Il problema delle preferenze.

Il più abusato esempio del pessimo lavoro fatto dal software libero nel campo delle GUI è "troppi programmi di preferenze". Questa questione è il mio giocattolo preferito, ad un certo punto volevo addirittura programmare un intero window manager basandomi sulla premessa che gli attuali soffrano di un abuso di programmi di preferenze.

Una tipica applicazione appartenente al mondo del free software è configurabile in modo tale da avere tutte le possibili funzioni che siano mai state presenti in un programma equivalente su ogni altra piattaforma, oppure è configurabile in modo che sia l'unione di tutte le applicazioni che mai siano state viste su ogni altro sistema operativo (coff, Emacs, coff, coff).

Questo danneggia qualcuno? Sì, lo fà. Innanzitutto i programmi di preferenze hanno un costo. Alcuni di questi, ovviamente, hanno anche dei benefici e possono essere delle caratteristiche cruciali dell'interfaccia. Ogni cosa però ha un prezzo, e bisogna considerarne con attenzione il reale valore. Molti utenti e sviluppatori questo non lo capiscono. Avere troppi programmi di preferenze significa che non sarà facile la navigazione in essi. Uso X-Chat tutti i giorni e sono abbastanza abituato ad esso, ma ho dovuto inserirlo in questo paragrafo e sperare che il manutentore del progetto sia capace di fare il suo lavoro. Il programma ha così tante possibilità di configurazione che ha bisogno di un intero menù dedicato solamente a contenere le diverse voci delle preferenze. È possibile, inoltre, creare per il programma degli script in un linguaggio a vostra scelta. Nel caso volessi cambiare qualche cosa in X-Chat dovrei cercare per anni solo per trovare il bottone giusto.

Un numero eccessivo di programmi di preferenze possono danneggiare il processo di ricerca della qualità e di beta-testing. Come chiunque legga dozzine di mail riguardanti errori di programmazione ed occasionalmente ne ripari qualcuno vi può dire, è molto comune trovare errori che si presentano solo se sono abilitate determinate combinazioni di opzioni. Come sviluppatore posso dirvi che i programmi di preferenze aggiungono una certa complessità al codice, alcuni più di altri, ma anche software di preferenze molto semplici possono complicare parecchio le cose se ne avete duecento.

Per inciso: un maggior numero di programmi di preferenze significa meno caratteristiche realmente utili e più errori nel codice.

Troppe preferenze rendono l'integrazione e la creazione di una buona interfaccia difficoltosa.

Una delle più dure lezioni nella programmazione di una GUI è che la mancanza di flessibilità potrebbe essere la soluzione. Ai programmatori è insegnato di rendere le cose generiche e flessibili. Il problema è che più generica e flessibile è la GUI più simile diventa ad un linguaggio di programmazione, ed il Lisp non è una buona interfaccia utente.

L'obiettivo di un buon programma è di fare una cosa specifica e di farla bene.

Il problema è che ogni decisione riguardante la GUI dipende da un gran numero di altre scelte inerenti all'interfaccia utente. Un esempio molto semplice sono le scorciatoie via tastiera. Su UNIX/Linux è quasi impossibile avere una configurazione standard decente per la navigazione nel desktop, perché potrebbe entrare in conflitto con quella utilizzata da un'applicazione. In Windows, i tasti per la navigazione nell'interfaccia sono inseriti esplicitamente nel sorgente e nessun'altra applicazione può utilizzarli perché i programmi sanno quali combinazioni di tasti sono sicuramente già usate.

Se il vostro programma non ha idea di come sarà l'ambiente in cui girerà allora non potrà avere delle ragionevoli impostazioni standard; semplicemente così non potrà funzionare. Ad un certo punto l'esistenza di programmi di preferenze significa che ognuno può personalizzarsi il proprio ambiente di lavoro, mentre, idealmente, le personalizzazioni sono un optional ed il comportamento standard dovrebbe essere efficiente e razionale senza bisogno di interventi esterni. Sapere cosa deve essere definito esplicitamente e cosa no ha una grande importanza.

I programmi di preferenze distolgono la gente dalla riparazione dei bug. Una delle più "divertenti" funzioni di GNUEmacs è quella chiamata "menu-bar-enable-clipboard". Adesso che KDE è stato corretto Emacs è praticamente l'ultima applicazione X che insiste nell'avere il copia-incolla che non funziona adeguatamente (vedere qui), c'è, quindi questa funzione che praticamente significa "per favore, fai che il mio copia-incolla funzioni come dovrebbe". Perché questa è un'opzione? Io chiamo questo tipo di preferenze il bottone "aggiusta la mia applicazione", sarebbe sufficiente rimuovere il bug ed evitare queste toppe.

Le preferenze possono confondere molti utenti, prendiamo come esempio l'eccessivo numero di orologi esistenti (vedere qui). Un numero significativo di soggetti presi in esame erano talmente sorpresi di potere scegliere fra cinque diversi orologi da non capire come fare ad aggiungerne uno al pannello. Il costo di un numero eccessivo di preferenze è spesso sottostimato da noi tecnici.

La più semplice delle considerazioni: la finestra delle preferenze ha una dimensione limitata, potete vedere molte applicazioni di una certa complessità faticare a trovare un posto dove mettere tutte le cose. Mozilla ha moltissime funzioni di personalizzazione che non sono neanche presenti nella finestra delle preferenze.

Come scegliere, quindi, quali preferenze mantenere e quali no?

Nel sentire che i programmi di preferenze hanno un costo "occulto", alcuni si preoccupano che i programmatori stiano per eliminarle completamente oppure che questo stia succedendo alla loro funzione preferita o qualche cosa di simile.

Fate un passo indietro per un momento e ripensate al problema delle preferenze.

Per ogni programma vi sono, letteralmente, un numero pressoché infinito di possibili preferenze ed ognuna di esse ha un costo. Un programma con un numero infinito di preferenze è un programma fatto infinitamente male, ma, ovviamente, alcuni di queste sono effettivamente utili ed importanti. Il compito degli sviluppatori dell'interfaccia utente è di scegliere quelle realmente essenziali.

Una discussione sul tema "le preferenze sono cosa buona" oppure "le preferenze sono cosa cattiva" è assolutamente improduttiva. Non sarebbe tale solamente una discussione che tracciasse una linea di demarcazione tra quando l'esistenza di una preferenza è realmente importante e quando no; essa potrebbe avere un effettivo impatto sulle decisioni degli sviluppatori.

Tradizionalmente, la linea di demarcazione del software libero fra una preferenza che dovrebbe esistere ed una che non dovrebbe è: "una preferenza potrebbe esistere se qualcuno la implementasse o se qualcuno la richiedesse". Nessuno sta seriamente difendendo questa posizione, od almeno nessuno che sia anche il manutentore di un'applicazione e che abbia visto l'esiguo numero di richieste di caratteristiche realmente utili fatte dagli utenti in questo campo.

Così come oggi Linus respinge la maggior parte delle aggiunte suggerite per il kernel, anche se avrebbe accettato la maggior parte di esse all'epoca della versione 0.1, mano a mano che il free-software matura molte preferenze proposte saranno rifiutate.

Come viene effettuata questa scelta? È una questione di giudizio, normalmente si tratta di rispondere a domande come queste:

• Fate domande per capire cosa manca veramente alla persona che ha richiesto la preferenza. Quale problema od innefficienza l'ha spinta a chiedere la modifica?
• si può supporre di risolvere il problema a tutti gli utenti senza aggiungere una preferenza apposita? Se sì, fatelo, cercate di percepire l'immagine completa dell'interfaccia utente per rendere la cosa funzionante;
• il problema è realmente importante, oppure richiede agli utenti un secondo in più per fare una cosa che fanno mediamente una volta la settimana? Se si tratta di una cosa del genere allora la funzione richiesta costerà probabilmente di più di quanto vale anche se riuscirai a fare funzionare il tutto;
• un qualsiasi altro sistema operativo offre la medesima caratteristica? Io sono favorevole alle innovazioni, ma se nessun'altro lo sta facendo allora dovreste pensarci due volte per essere sicuri che non ci siano delle ragioni che li hanno spinti a fare diversamente. Se siete indecisi pensate al fatto che le attuali piattaforme più diffuse hanno subito molti test e studi per essere ciò che sono.

La cosa fondamentale è di porre dei limiti. Supponete di avere solo un certo numero di spazi per le preferenze; la preferenza in questione è vale uno di questi posti? Una volta utilizzato è difficile liberare nuovamente lo spazio occupato. Tenete bene a mente che tutto ha un costo, e domandatevi se la preferenza che state valutando al momento abbia un reale valore.

Resistere alle pressioni degli utenti.

Come manutentore di un programma free è veramente duro resistere alle pressanti e continue richieste di caratteristiche, molte delle quali riguardano le preferenze e vengono fornite persino del codice necessario alla modifica.

Leggendo quotidianamente su dozzine di bug di GNOME e di RedHat, vedo che è molto comune per gli utenti chiedere l'inserimento di nuove preferenze. Se un utente sta utilizzando il mio programma FooBar e pensa che il mio programma stia facendo qualche cosa di stupido, supponiamo cancellare tutte le sue e-mail, è molto comune che l'utente sottometta una nota che dica "dovrebbe esserci un'opzione per evitare che il programma si mangi tutte le mie mail" piuttosto di una che dica "quell'ammasso di spazzatura che è la tua applicazione si è mangiata le mie mail". La gente semplicemente pensa che FooBar sia stato progettato per cancellare la loro posta elettronica, e semplicemente chiedono che ci sia la possibilità di disabilitare questa funzione che non gradiscono.

Combattete la tentazione! Ammettete la verità con i vostri utenti, siete dei perdenti, FooBar fà pena e si è mangiato le loro e-mail. ;-) Questa "funzione" deve essere corretta, non resa opzionale.

Ho ricevuto proprio oggi una patch perché l'animazione dello shading della finestra di Metacity è brutta ed inoltre blocca il server X impedendo a tutte le applicazioni di aggiornarsi per tutta la durata dell'animazione. La correzione che ho ricevuto rende l'animazione opzionale, ma questa non è l'approccio corretto. Per quanto ne so il problema è che l'animazione è fatta male e quindi questa aggiunta alle preferenze non è altro che una toppa, non la soluzione.

Linus ha un buon commento su questi casi, l'ho trovato su LWN. L'argomento nella mailing-list del kernel in quel momento verteva sulla possibilità di eliminare alcune caratteristiche mal implementate dell'interfaccia IDE prima che fossero scritte dei rimpiazzi migliori. Linus dice:

Il fatto è che molte cose sono più facili da riparare dopo, soprattutto perché solo allora trovi persone abbastanza motivate da lavorarci sopra. Se si cercasse di porre rimedio al difetto prima che questo venga alla luce non si sarebbe potuto riparare mai niente di fondamentale, semplicemente perché i programmatori che possono riparare una cosa, normalmente, non possono ripararne un'altra.

Il problema più scocciante è che alcune volte devi causare un regresso per poter riparare le cose. In GNOME 2, per esempio, volevamo correggere l'applet "window list", sotto GNOME 1.4 doveva essere ridimensionata manualmente tramite le preferenze. Volevamo semplicemente che la cosa funzionasse a dovere, ma questo ha richiesto un po' di tempo e durante quel periodo abbiamo ricevuto parecchie proteste perché non risolvevamo il problema. Abbiamo anche ricevuto delle richieste che chiedevano che reintroducessimo nuovamente la modifica manuale delle dimensioni tramite preferenze. Questo però sarebbe stato un errore. (Adesso che l'applet funziona a dovere può avere senso addirittura aggiungere alle preferenze una voce "dimensione massima".)

E che dire degli utenti avanzati?

Come Joel fà notare gli utenti evoluti non vogliono un milione di preferenze inutili quando le cose dovrebbero funzionare bene da subito. In base alla mia esperienza l'annotazione è corretta.

Alcune volte vi possono essere delle buone ragioni per una sezione con le funzioni avanzate o qualche cosa del genere. Qualcosa di così elaborato come l'approccio a livelli usato in Nautilus 1 secondo me non ha per? senso: un tab dedicato alle funzioni evolute non dovrebbe essere usato come una panacea o come una scusa per delle scelte stupide a livello di design.

(Il menù "Desktop Preferences->Advanced" delle beta di GNOME 2 è proprio una toppa di questo tipo, dovuta al fatto che i nuovi pannelli di controllo non contengono ancora tutte le funzionalità di quelli vecchi. In seguito questo menù dovrà morire.)

Come mai questa fissazione con le preferenze?

Penso che se si fosse più abituati ad avere delle buone impostazioni di default funzionanti senza molti orpelli piuttosto che aggiungere semplicemente delle nuove preferenze, si andrebbe naturalmente verso un miglior disegno delle interfacce utente. I suggerimenti arrivano tramite bugzilla o le mailing-list oppure direttamente dagli utenti: se si riparassero le cose in un altro modo che aggiungendo delle preferenze si sarebbe obbligati a ragionare sulla migliore architettura della GUI e sul modo corretto di aggiustare i bug.

Fondamentalmente, usare le preferenze come toppa è alla radice di molti difetti delle interfacce utente. Per il software libero è un grande guadagno ed un notevole cambio di filosofia che il progetto GNOME abbia capito tutto ciò.

Ma come puoi dire che GNOME 2 sia bello, manca di <inserite la vostra funzione preferita qui>.

Sicuro, probabilmente manca quella funzione ;-) Mandate una mail ed aggiungete la parola chiave Utilizzabilità.

Sarei un fanatico se sostenessi che GNOME 2 è perfetto, ma penso che sotto molti punti di vista sia un chiaro cambio di rotta rispetto alla tradizionale filosofia delle GUI del software libero: tanti-bottoni-quanti-ce-ne-stanno, tante-voci-quante-ce-ne-stanno-nei-menù, metti-quante-più-funzioni-è-possibile ^[2].

Inoltre, quando sottomettete una mail su un bug, chiedete che sia corretto l'errore, non che sia aggiunta una voce nelle preferenze per disabilitarlo.

[2] Alcuni esempi: siamo passati da una gerarchia molto nidificata di 31 pannelli di controllo a forse dieci od undici (più uno sfortunato e vagabondo pannello "Advanced", ma è già nella lista delle future "vittime"). Confrontate le preferenze del Desk Guide della versione 1.4 con il nuovo "workspace switcher". All'interno di GNOME, date un'occhiata alla navigazione tramite tastiera, ce l'ha il pannello, le finestre di dialogo sono caricate tramite tasti mnemonici, Nautilus adesso usa dei widget controllabili tramite tastiera dove è possibile. Un'altra piccola modifica: la parola "applet" non appare più nell'interfaccia utente. Vi sono migliaia di piccoli cambiamenti da scoprire, provate a trovarli tutti. Se siete particolarmente temerari potete provare GNOME 2 usando Metacity come window manager, e se, mentre state "smanettando" con ogni più piccolo dettaglio della GUI, trovate qualche problema riportatelo su bugzilla.

<- PW: l10n - Indice Generale - Copertina - SL - Intro ->