Il software facile

Molto spesso nascono discussioni su quale sia il Software ideale.
Al seguente indirizzo trovate il documento in cui riassumo le mie posizioni in proposito

Il software ideale.

L'utente che deve risolvere un problema per prima cosa cerca un software facile.
Lo sanno bene le grosse aziende che sviluppano software, un pò meno gli sviluppatori indipendenti.
Il programma è un difficile gioco di contrappesi, tanto più un programma è potente tanto più e complesso, la completezza molto spesso va a scapito dell'intuitività.
Ma cos'è un 'software facile', se a ciascuno venisse chiesto uscirebbero numerose interpretazioni, ritengo che possano essere riportate a un assunto di questo tipo:

Il software facile è quello che fa ciò che mi aspetto, che segue i miei flussi operativi con la massima intuitività e semplicità, è affrontabile con il minimo dispendio di risorse in termini di apprendimento e studio delle modalità di utilizzo.

Da una considerazione di questo tipo nascono tutta una serie di assunti derivati.
Il programma facile non è necessariamente banale.
Il programma migliore per me può essere il peggiore per un altro.
Chi lavora in una maniera e usa un software che approccia il problema in modo opposto lo troverà comunque difficile.
Il programma giusto non è sempre quello più potente.
Il programma soddisferà l'utenza tanto sarà focalizzato verso le esigenze di tale utenza, il gruppo di destinatari del programma deve quindi essere il più possibile omogeneo.

Il target di utenza.

Chi viluppa il programma deve porsi come primo obiettivo il target di utenza.
Non bisogna presumere conoscenze che l'utente non ha ma devono essere presunte quelle che deve avere.
Un software può accontentare pienamente solamente utenti similari nei gusti, nel modo di lavorare, nella compentenza.
In definitiva chi progetta software che non sia su misura per un singolo, deve puntare ad un target d'utenza ben definito di cui deve adottare: flussi logici, terminologie, gerarchie di valori.
Un software ben progettato non accontenta tutti, ma tutti coloro che fanno parte del target a cui tale software è indirizzato.
Vi sono materie strutturalmente complesse, un software può aiutare nell'apprendimento di aspetti particolari del proprio mestiere ma non deve pretendere di insegnare il mestiere a chi dovrebbe conoscerlo.
Chi usa un programma si presume conosca la tastiera, come si apre un file, come si fa una stampa, in un programma di contabilità si deve presumere che l'utente sappia cos'è un mastro, un piano dei conti.
Documentare oltremodo le cose che l'utente deve per forza conoscere, rischia per essere controproducente per coloro che conoscendo la materia, puntano ai contenuti e per i quali tutto il resto fa parte degli 'orpelli'.
Soddisfare tutti è possibile tanto più quanto più il target è omogeneo.
Faccio un esempio. Se in un corso di 'introduzione all'informatica' indirizzato a 30 persone, abbiamo un gruppo con conoscenze omogenee (ad esempio sono tutti inesperti), il successo per il docente è avere 30 persone per i quali la difficoltà e il ritmo del corso sono stati ritenuti adeguati.
In un gruppo con 10 persone preparatissime, 10 con esperienza media, 10 totalmente inesperte, il massimo risultato auspicabile è avere 10 utenti per i quali il corso è stato troppo facile, 10 per i quali è stato adeguato e 10 per i quali è stato troppo difficile.
Vedo talvolta sviluppatori che nell'intento di inseguire le esigenze di un singolo, magari totalmente impreparato, fanno ricadere gli effetti negativi su tutti gli altri, lo sviluppatore deve sempre rapportare le sue scelte al target nel suo insieme (negli altri casi si procede allle personalizzazioni ad hoc).
Talvolta adirittura ci sono utenti con un modo di lavorare al di fuori dei normali flussi, in tal caso può uscire un programma che fa al caso del proprio cliente, ma che è assolutamente inadeguato per il resto della categoria.
Questo capita in particolare al momento della prima analisi, sta quindi nell'analista capire di chi 'fidarsi' nella strutturazione del futuro applicativo scegliendo con cura i propri interlocutori e studiando i 'casi analoghi' e relative soluzioni già approntate.
In questi casi a mio parere il migliore interlocutore è una persona che, lavorando nel settore da anni, conosca il proprio modo di lavorare e quello dei suoi colleghi, molto 'scafato' del mestiere possibilmente totalmente a digiuno di computer in modo da fare le cose nel modo migliore ma non costretto dal seguire flussi logici di un programma preesistente.
Non si può progettare la gestione di magazzino senza dare un occhiata a come lavora il magazziniere e le frequenti eccezioni che si trova a gestire al flusso ordinario delle attività.
Il programma può avere anche una funzione educativa o di indirizzo, in pratica un utente che da sempre lavora in modo scorretto può apprendere il giusto modo di lavorare, per lui comunque il programma sarà complesso non tanto in virtù della sua struttura quanto nel fatto che dovra cambiare le abitudini di una vita.
Questa situazione è molto frequente nelle aziende piccole che crescono o in aziende in cui l'informatizzazione entra per la prima volta, diventa la fine del 'un tanto a spanne'.
Ci sono anche gli utenti che comprano un programma nella speranza che questo gli insegni un mestiere, sono la croce dei 'call center', difficilmente riuscirete a soddisfarli.

La documentazione.

La documentazione è un importante strumento per gli esperti e i tecnici, spesso un alibi per l'utente di base.
Molti gestionali escono con documentazione carente se non addirittura inesistente.
In questi casi a ogni intoppo l'utente vi farà giustamente carico di questo limite e questo diventerà automaticamente anche l'alibi per le cose che lui dovrebbe sapere e che non sa.
L'utente di solito legge la documentazione solo quando si trova in difficoltà, chi scrive programmi deve tenerne conto e quindi deve esserci un indice per arrivare velocemente a leggere l'informazione ricercata.
In determinate situazioni però (vedi gestionali), vanno descritti i flussi operativi che difficilmente da programma si intuiscono, in tal caso si sopperisce con una apposita documentazione che deve essere letta per forza o una formazione a monte irrinunciabile.
Non è vero che tanto più un programma è documentato tanto più è semplice. Si possono ottenere 400 pagine di documentazione che nessuno leggerà mai o 200 avvisi a schermo con lo stesso risultato.
La documentazione ritengo vada focalizzata con scritte sullo schermo o altro unicamente nei passaggi 'atipici', inserita in modo che, una volta che l'utente ha imparato, non sia di peso.
Visto che viene spesso aperta sull'intoppo deve essere facile arrivare a leggere il giusto capitolo.

Installazione

La fase di installazione è di solito uno dei momenti critici di un software.
Il Web ha risolto totalmente il problema per tutte quelle applicazioni con natura 'on demand' ovvero che non devono necessariamente risiedere sul Pc dell'utente o per porzioni di applicazioni che non hanno questa necessità.
Stanno nascendo delle strutture che cercano di migliorare le cose da questo punto di vista ma la situazione è ancora ben lungi dall'essere risolta, al momento la semplificazione dell'installazione richiede quasi sempre l'allestimento di una struttura a monte.
In tutti gli altri casi le esigenze possono essere piuttosto diverse.
Il caso piu' semplice è quello degli applicativi che non fanno uso di risorse esterne, es. i vari tipi di programmi delegati ad operazioni di routine senza agganciare risorse particolari.
I problemi nascono invece da programmi che devono usare hardware in modo spinto (ad es. alcuni videogames), programmi che si appoggiano ad un runtime, programmi che si appoggiano ad un Database Server, programmi che interagiscono con il sistema agganciando ad esempio altre applicazioni, programmi in multiutenza o programmi scritti per un Web Server.
In tali casi l'utente si trova spesso disorientato e i problemi preliminari possono essere pesanti, occorre però sempre partire dal presupposto che tale operazione va fortunatamente eseguita 'raramente'.
Per i programmi non gestionali di solito deve installarseli per forza l'utente finale e quindi il tentativo è di tipo 'o la va o la spacca' con magari un supporto on line telefonico o l'intervento dello 'smanettone della porta accanto' per risolvere le situazioni particolari.
Per gli altri casi si va da una 'installazione da parte di un tecnico' alla installazione presidiata 'on line' a una installazione autonoma ma indirizzata 'a tecnici' o quasi.
In tali casi il programma deve possedere un setup di base e fornire tutta la documentazione a supporto ma indirizzata allo specifico target che in tal caso non è più l'utente finale.
In pratica nella documentazione di solito si evita di spiegare cos'e' un editor, come si apre un file, come si scompatta uno ZIP, per evitare di generare montagne di documentazione su argomenti che devono essere nel background di un tecnico informatico di basso livello o di un utente evoluto.
Se nella mia automobile si rompe il pomello della marcia sono in grado di aggiustarlo io, ma se mi si rompe lo spinterogeno devo andare dal meccanico, qualora io sia casualmente un appassionato di motori devo avere la documentazione a supporto che mi permetta di aggiustarmelo da solo.
Paradossalmente chi gestisce dei call'center d'assistenza tecnica sa che esistono situazioni paragonabili a quelle dell'utente inesperto che vuole aggiustare lo spinterogeno per telefono, fattibili in alcuni casi, impossibili o quasi in altri.
Peggio ancora l'utente che vuole aggiustarsi lo spinterogeno da solo ma pretende di avere gratuitamente al telefono uno che spieghi come si usa il cacciavite.
Il concetto è che fintantochè il target e' l'utente finale tutto deve essere assolutamente autonomo, la documentazione tecnica a corredo dell'installazione deve tenere conto di un target con un bagaglio tecnico adeguato.

I Wizards

Per risolvere i problemi di target disomogenei alcuni programmi risolvono con i Wizard (magari un solo wizard preliminare) customizzati per i vari livelli d'utenza.
E' questo il caso ad esempio dei programmi per masterizzare.
La masterizzazione è una operazione complessa, l'utente mediamente non conosce sigle tipo TAO, DAO, Joliet, Burn free e relativi concetti.
Certamente il programma deve cercare di spiegali un po ma non può certo diventare un trattato di informatica, ma dato che a molti utenti interessa solo copiare un CD o scriverlo, molti si limitano a sfruttare i Wizard e i Default proposti.
Purtroppo è impossibile avere un Wizard per ogni situazione per cui di solito ci troviamo a risolvere i due casi estremi, il tecnico e l'ingnorante, rimane scoperta la 'fascia intermedia' (spesso piuttosto popolata).
In molti casi un programma non può documentare tutto, prendete il caso di un Tabellone Elettronico, se per ciascuna funzione (es. calcolo matriciale, regressione lineare o altro) dovessero essere spiegati i concetti relativi, il risultato sarebbe un enciclopedia.

L'avviamento

Vi sono programmi che per loro natura sono estremamente vasti e utenti diversi anche omogenei come tipo di attività tendono ad usarne sì e no un 20% delle funzionalità.
In tali situazioni il programma spesso viene 'adattato' alle caratteristiche dei singoli in una fase preliminare o in corso d'opera, in modo da risultare più aderente alle necessità dei singoli.
Questo tipo di operazione introduce però una fase intermedia rispetto alla classica sequenza Setup-Avvio ovvero Setup-Avviamento-Avvio.
La fase di Avviamento diventa tanto più importante quanto più il programma è complesso e customizzabile, penso ad esempio ai vari gestionali, agli applicativi in multiutenza, a un programma paghe o a un programma di contabilità.
In queste situazioni l'avviamento assistito dall'installatore può essere una fase praticamente irrinunciabile.

L'estetica.

L'estetica non è un optional, rende amichevole l'approccio al programma, rende intuitive determinate funzioni.
Per l'utente finale l'interfaccia grafica oggi è, nella stragrande maggioranza dei casi, una esigenza irrinunciabile per motivi non solo estetici ma anche funzionali.
L'utente base è in grado di muoversi 'a tentativi',salta rapidamente da un punto all'altro dell'applicativo senza necessità di conoscere sequenze di tasti, lavora con oggetti che hanno un modo di operare similare anche con programmi differenti (ad esempio l'uso di una 'casella combinata' e' similare anche tra applicativi differenti).
C'e' pero' modo e modo di fare estetica, vedo spesso programmi con montagne di icone a cui è difficile accostare un significato senza andarci sopra o eseguirle.
I colori devono avere un significato funzionale, qui si può scrivere e qui no, questo è un allarme ecc.
Non voglio dire che teorizzo videate grige con campi disallineati, l'ordine migliora la leggibilità ma 'fantasmagorie di colori' disorientano e danno spesso un aspetto poco professionale.
Insomma al tecnico è delegato il compito di scrivere l'applicativo, per l'estetica è giusto che si faccia dare delle indicazioni da chi è formato su questo o ha semplicemente buon gusto, ma deve cercare di mantenere comunque il controllo sul significato funzionale corrispondente.

La funzionalità.

Se a una icona è difficile accostare un significato senza andarci sopra, è meglio metterci una scritta.
Troppi popup disorientano stessa cosa se si usano troppe finestre.
Finestre a pieno schermo disorientano sul percorso fatto per arrivare fino a quel punto, finestre più piccole se sono troppe possono generare sconcerto quanto i popup.
Le linguette aumentano di molto la capacità di ospitare campi di una finestra, ma non li presentano tutti contemporaneamente si perde in pratica il 'colpo d'occhio' (in certi programmi essenziale).
Se una conferma è stremamente insistente ed esce nel 99% dei casi perderà il suo significato in quanto l'utente svilupperà un automatismo, al momento giusto la premerà per sbaglio.
Le cose sempre usate devono avere maggiore evidenza e accessibilità, se un utente usa una funzione nel 90% della giornata questa non deve essere nascosta in un sottomenu di quarto livello.
L'uso delle 'tendine' è da preferirsi quando i dati solo tanti, quando sono pochi e non ci sono problemi di spazio meglio le liste l'utente deve sempre fare meno click possibli.
I default (valori predefiniti) devono esserci nei casi standard, non esserci in quelli in cui l'utente deve inserire un dato e magari si dimentica (es. una casella maschio/femmina con defaut a maschio).
Giustamente chi programma, punta da subito al corretto risutato funzionale tralasciando tutto il resto.
Meglio un ottimo programma con una pessima interfaccia che un pessimo programma con una ottima interfaccia (anche se la maggioranza degli utenti inesperti comprerà il secondo).
Quello che rimprovero a molti bravi programmatori è che una volta risolto il problema non si pongono nelle condizioni di renderelo facilmente fruibile.
E' questo il caso di molti programmi anche dell'Open Source dove per ogni tipo di problema esistono svariate soluzioni, alcune le scartate perchè non riuscite neppure ad installarle, altre le scartate per carenze funzionali, ma la gran parte vengono scartate per 'scomodità' o scarsa usabilità.
Oggi dopo anni finalmente queste esigenze incominciano ad essere prese in considerazione ed infatti oggi i programmi che stanno maggiormente diffondendosi in tale ambito, non sono sempre i più potenti ma i più usabili per il proprio target di utenza.