Qualche giorno fa ho parlato di linee-guida per lo sviluppo del codice nel codice.
Ora vorrei soffermarmi su un piccolo aspetto, apparentemente lapalissiano, ma che in concreto temo non lo sia affatto: spiegare rapidamente all’utente come funziona il programma.
Perchè preferisco usare i comandi da terminale
Credo di non stupire nessuno nell’affermare che, a parità di funzionalità, fra un programma da terminale ed uno dotato di GUI, io propenda nettamente per usare il primo.
Questo perchè spesso le GUI non sono intuitive, spesso non sono coerenti, richiedono molti click perfino per le azioni più semplici e, non ultimo, non hanno quasi mai un equivalente immediato per l’”usage“, tipico dei programmi da terminale.
Un piccolo esempio: avete notato l’incremento di passi e finestre da aprire per poter vedere/cambiare un semplice IP nel passaggio da Windows XP a Vista/7?
Lo “usage“
Con “usage” intendo quella descrizione più o meno stringata che normalmente compare aggiungendo da terminale il flag “–help” (o corrispondente) al nome dell’eseguibile.
Un esempio di “usage“:
root@akkarin:~# df --help
Usage: df [OPTION]... [FILE]...
Show information about the file system on which each FILE resides,
or all file systems by default.
Mandatory arguments to long options are mandatory for short options too.
-a, --all include dummy file systems
-B, --block-size=SIZE use SIZE-byte blocks
-h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G)
-H, --si likewise, but use powers of 1000 not 1024
-i, --inodes list inode information instead of block usage
-k like --block-size=1K
-l, --local limit listing to local file systems
--no-sync do not invoke sync before getting usage info (default)
[...]
Deve essere una regola non scritta ma davvero non capisco perchè chi scrive GUI tende quasi sempre a volere includere anche manuali spettacolari, reclusi in finestre tanto sontuose da impiegare interminabili minuti ad aprirsi.
Inutile far notare che l’utente non la pensa allo stesso modo di uno sviluppatore e anzi, passatemi il termine, non “gliene può fregare di meno” di avere un manuale-libro iperparticolareggiato e “facilmente” raggiungibile, se poi deve attendere qualche minuto per la sua apertura ogni volta che gli serve un’informazione.
Non parliamo poi dell’eccesso di informazioni, che rendono praticamente impossibile la lettura e quindi il recupero/ritrovamento di quello che serve davvero.
Se un utente necessita di un’informazione, è assai probabile (eufemismo) che la desideri subito e non debba/voglia attendere minuti e minuti per ottenerla.
Detesto chi confonde accessibilità ed usabilità con gli orpelli.
Corollario: se devo aprire un manuale, significa che probabilmente ho una qualche richiesta particolare che non riesco a soddisfare immediatamente da solo, osservando il programma da utente.
Se poi la richiesta in questione è un semplice “come uso il programma?“, significa che o sono diventato scemo tutto d’un colpo o probabilmente il programma è così antiintuitivo da essere inusabile.
La domanda fondamentale è: quale delle due opzioni è davvero la più probabile?
Una misera proposta
Siccome non voglio parlare di aria fritta, ecco una mia miserrima proposta, che si riassume innanzitutto nel dividere fisicamente lo “usage” dei programmi (a mio modo di vedere, sempre obbligatorio: meglio ribadire l’ovvio e l’intuitivo, che non dirlo affatto) dalle relative informazioni addizionali, ossia i “manuali” veri e propri.
Fatto ciò è importante decidere come mostrarlo.
Vi parrà orrendo da dirsi, ma un bel pulsante con scritto “usage” con relativa MessageBox è già una soluzione decente (anche se personalmente detesto impiegare le MessageBox perchè, fra le altre cose, la loro comparsa tende a spaventare l’utente-medio).
Ovviamente la MessageBox riporterà uno stringato messaggio in cui si spiega all’utente come usare immediatamente quelle 4 funzioni basilari che normalmente rappresentano l’utilizzo tipico del programma.
Questa soluzione, raramente impiegata (sigh) tende a tranquillizzare l’utente, non lo stordisce con miriadi di informazioni superflue e gli consente di impratichirsi col programma. Per le richieste particolari – e solo allora – potrà consultare il manuale in un secondo momento.
… ed una alternativa
Se proprio l’aggiunta di un pulsante “Help”/”Usage” non vi piace (forse che deturpa le vostre scintillanti GUI?), potete creare un mini-manuale apposito, qualcosa di immediatamente accessibile all’utente, senza inutili fronzoli.
Mi riferisco a quelle sezioni/capitoletti, normalmente separate o poste all’inizio dei manuali, spesso indicate (talvolta erroneamente) come “per gli impazienti” o “getting started” e che fanno spesso la mia felicità. E non credo solo la mia.
Che ne pensate?
Ciau!
Ciao JP,
oggi essendo a fare il Cerbero per un esame ho un po’ di tempo e quindi riesco a postare il mio commento
Non sono molto d’accordo con quello che dici, tranne sul fatto che spesso le GUI sono *troppo complesse* e non *congruenti con se stesse*
.
Nota: non concordo con te non tanto per quello che dici, ma per la premessa (implicita) che fai: tu non stai parlando dell’utente medio; tu stai parlando dell’utente avanzato (spesso in qualche modo sviluppatore, anche solo di contenuti)… categoria di cui fai parte.
L’utente medio è la sig.ra che ha l’eta di tua madre (perché più giovane della mia) che ha dovuto imparare ad usare word per il lavoro; l’utente medio è mia cognata che visto che il programma della banca pretendo l’uso del maiuscolo, scrive in maiuscolo anche le email; l’utente medio è quello che ti contatta chiedendoti quale sito è meglio per prenotare la vacanza via internet, perché tanto tu lo sai, sei informatico; l’utente medio se non avesse le sontuose interfacce grafiche non saprebbe usare il computer (IMHO, naturalmente
P.S. piccola digressione sui manuali
manuali? quali manuali? chi li legge? gli “smanettoni” non leggono il manuale se non dopo la 5/6 volta che non riescono a fare una cosa immediatamente… e che non hanno trovato un walkthrought su internet che gli spieghi come farlo in 3 passi… gli utenti medi (a cui mi riferisco) non leggono i manuali… se devono farlo li senti dire “mica siamo informatici noi… certe cose non le capiamo”.
cheers
Ciao Eros.
Beh sì, io non ragiono certamente da utente-medio, però mi trovo abbastanza spesso nell’impossibilità di usare alcuni programmi oppure li uso “alla cieca“.
L’utente-medio, probabilmente, direbbe che il programma non va, smetterebbe di usarlo e, se possibile, contatterebbe l’assistenza “per farlo andare“.
Io invece, un po’ forse per una mera questione di orgoglio professionale, tendo comunque a dare un’occhiata a guide e manuali. Però, da utente come sono io stesso, preferirei non doverlo fare. Pigrizia? Sì, l’utente è pigro, io sono pigro. Quando devo aprire un manuale e il caricamento dura minuti e minuti, mi sento sfiduciato.
Io propongo qualcosa di leggero, qualcosa che non sfiduci l’utente nè lo faccia arrabbiare. Chiedo qualcosa di rapido, compatto, chiaro, qualcosa simile ad un “usage” anche per i programmi dotati di interfaccia grafica…
E’ esigere troppo, questo?
Ciao & grazie per essere passato.
Due discorsi:
1) le interfacce utente intuitive ed efficaci sono il risultato di uno studio accurato. l’umano interagisce con gli oggetti fin dalla nascita quindi sviluppa fior di regole che non possono essere ignorate improvvisamente. sicuramente un oggetto virtuale come l’interfaccia grafica e’ una cosa parecchio diversa da un oggetto reale ma anche essa ha delle regole che bisogna studiare e conoscere, altrimenti si manca il bersaglio.
2) mi vien da pensare che una interfaccia troppo complessa voglia fare troppe cose in un colpo solo. un po’ come le funzioni troppo lunghe o le condizioni logiche con troppi operatori booleani. un vecchio adagio, applicazioni piccole che facciano poche cose ma bene. che poi e’ anche piu’ facile verificarne la correttezza…
1) Giusta osservazione: ogni contesto ha le sue regole. Quello che però mi chiedo è se l’idea che sta alla base dell’”usage” non possa essere trasposta in modo grafico in qualche modo, rispettando le regole e l’intelligenza di chi usa qualcosa.
2) vero. Casualmente gli sviluppatori di GUI (e mi ci metto dentro, almeno in parte) tendono a non applicare la filososia KISS nè la sana regola del “una sola cosa e fatta bene” ma a risolvere in un colpo solo tutto. Sbaglio? La nascita e la diffusione del pattern Model-View-Controller penso sia legato alla difficoltà intrinseca di risolvere un problema (programma) e non mischiarlo con l’aspetto esteriore, ad esempio una GUI. Dopotutto, hai mai sentito parlare di un programma da terminale che implementi e segua il pattern MVC? Inoltre, come tutti sapranno bene, è spesso più facile e rapido risolvere un problema che trovare il modo migliore per mostrarne l’esito. Sbaglio?
Ciao e grazie per essere passato!
1) c’e’ usage e usage. a riga di comando ce ne sono alcuni inutili e altri del tutto inutilizzabili. c’e’ da dire che e’ facile fornire anche successivamente gli esempi per gli usi piu’ comuni. per le GUI invece, o la pensi giusta fin da subito oppure rifai tutto. poi ci sono le “pezze a fiori” tipo implementare il “?” in alto a destra, i tooltips e i manuali con tante belle immagini.
il fatto e’ che con gli strumenti per lo sviluppo di GUI e’ troppo facile inserire logiche applicative direttamente dentro la funzione chiamata dal tal bottone xy rendendo di fatto difficile estrarre e ricostruire il flusso. pero’ correggetemi se sbaglio, non sono un esperto di interfacce grafiche, cerco di starne il piu’ lontano possibile proprio per questi motivi (ma soprattutto perche’ gli utenti sono tutti degli scassa maroni senza pari).
2) non uso molto l’MVC anche se e’ un’applicazione di un concetto piu’ generale che io ritengo cardine in qualsiasi ambito della programmazione, cioe’ quello della modularizzazione e dell’interfacciamento tra i moduli. portato all’estremo si ritorna alla filosofia KISS (ma quante ne sai, jp!) applicata alle singole funzioni, le cui interfacce con il mondo esterno sono le signature.
l’argomento comunque e’ molto vasto, direi sterminato, e di sicuro non ho le competenze per continuare senza dire vaccate, ammesso che non abbia gia’ cominciato
1) se entriamo nel caso specifico, esistono “usage”, “manpage” e pagine “info” scritte in modo orripilante. Allo stesso tempo esistono GUI ben fatte e con varie forme di aiuto “inline” (come quelle che hai indicato) valide. Il problema è che, mi spiace dirlo, non c’è proprio proporzione. Si dà scontato che un comando da terminale “lissio” (niente ncurses & simili, per capirci), proprio per la mancanza di un’interfaccia grafica, debba avere uno “usage” per essere compreso ed utilizzato nel modo corretto. Al contrario un buon programma dotato di GUI dovrebbe essere così chiaro e intuitivo da costringere l’utente a ricorrere al manualone solo in caso di necessità. O sbaglio?
2) la cosa particolare è che il “pattern” MVC è relativamente anziano (’79) come classificazione ma, purtroppo, il suo utilizzo non è ancora così vasto. Non che un buon programmatore non lo “segua” in pratica da sempre (anche senza conoscerlo per nome) però, per quanto ho visto sin qui, sono davvero pochi a conoscerlo e applicarlo nel modo “corretto”. Anzi, diciamolo: se non fosse per i framework pensati e progettati con il pattern MVC in testa, molta gente continuerebbe a mischiare tutto bellamente per comodità, pigrizia, …
Quanto all’essere “esperti” o meno, non preoccuparti. Se dovessi ricevere un centesimo di euro per ogni idiozia che farfuglio, probabilmente sarei ricco sfondato.
PS: non avevo mai pensato allo scrivere programmi da terminale come un buon modo per difendersi dai clienti/utenti rompiscatole. Geniale!
1) c’e’ da dire che ci sono una manciata di modi per incastrare switch e parametri su una riga di comando, i piu’ gettonati sono implementati per mezzo di librerie per cui proprio per pigrizia il programmatore ricade in un pattern ben noto. il problema e’ per i tool piu’ potenti che sulla riga di comando ci infilano un po’ di tutto (penso a find, ffmpeg), a quelli che sono nati cosi’ (tipo dd) o ai mastodonti (subversion, git, mdadm e cosi’ via). diciamo che generalmente alla peggio ne fai un uso ridotto rispetto al potenziale che ti mettono a disposizione. e in ogni caso non dimentichiamo gli script e gli alias… Jp, che argomento hai tirato fuori… quindi se proprio proprio non ti piace l’interfaccia o la relativa documentazione, ti puoi scrivere facilmente degli adattotori che sembrano piu’ logici o comodi. e non aggiungo altro..
2) ma certo, l’MVC serve ai produttori dei tool di sviluppo & librerie per salvare gli sviluppatori da loro stessi e di conseguenza a salvare loro stessi dagli sviluppatori. visto che nessuno usa i patterns hanno capito che bisognava infilarli direttamente nelle librerie, altrimenti sarebbe stato solo l’inizio della fine. che poi qualcuno possa facilmente sostenere che i pattern siano difficili da usare e che e’ meglio che ci sia il supporto del linguaggio… vabbe’.. qui poi si cade nella solita trappola di jp’o'flamewar
..
assolutamente si, stai lontano da qualsias tipo di interfaccia utente e ti risparmierai infiniti vespai. fai sempre in modo che l’interfaccia sia lasciata a qualcun’altro. sai c’e’ un pattern, si chiama MVC….
))
1) Sì, ok, con i flag ci si può sbizzarrire, però non era il senso del mio post.
La mia era più una proposta per rendere più intellegibili ed usabili i programmi dotati di GUI.
2) Flamewar? Se è l’esito, non era certo mia intenzione. La mia era un riflessione certamente da utente&sviluppatore, non mi interessava lanciare accuse qui e là. Anzi, mi son tirato in mezzo anche io-medesimo, per cui al massimo è una flamewar-masochistica…
LOL per la frase finale.
Ciau! ^^