David Frontini, Paolo Morandotti
Intrasoft S.p.A.
- Settore Ricerca e Sviluppo
v. Donatello, 30 - 20131 Milano
Tel. 02 706495.1 - Fax 02 70608119
E-mail david.frontini@intrasoft.it, pmo@intrasoft.it
Sommario
L'interfaccia utente ha subito, nel corso degli anni,
modifiche profonde che hanno cambiato anche il modo di concepire lo sviluppo
stesso delle applicazioni su qualunque piattaforma. Le richieste provenienti
dal mercato fanno pensare che l'evoluzione delle GUI sia lungi dall'essere
terminata. In particolare, la crescita delle applicazioni Intranet e l'affermazione
dell'ipertestualità hanno mostrato che nuovi tipi d'interfaccia
possono soddisfare le esigenze degli utenti quando la loro progettazione
è perfettamente integrata nel ciclo produttivo.
1. Introduzione
Negli ultimi anni l'interfaccia utente ha assunto un ruolo sempre più incisivo nello sviluppo di applicazioni, e si riscontra sempre più spesso, in particolare nelle piccole realtà produttive, che le analisi dei programmi sono limitate al disegno delle GUI. Questa pratica, che è sbagliata in assoluto, può causare problemi molto gravi quando applicata allo sviluppo di applicazioni Intranet. Come mostreremo nel seguito, l'impatto delle GUI nelle applicazioni di questo tipo è molto più profondo di quanto non sia nelle applicazioni desktop, e la sua analisi deve essere condotta in modo diverso da quello normalmente praticato.
L'evoluzione delle applicazioni accessibili attraverso Internet mostra che, verso la metà degli anni '90, esse erano di tipo "Information retrieval", con un'interfaccia molto scarna che permetteva solo l'inserimento dei parametri per la ricerca dei dati. Quest'interfaccia sopravvive oggi solo nei motori di ricerca ed in piccole applicazioni per siti Web. In seguito, grazie anche allo sviluppo del concetto d'Intranet, comparvero due tecnologie parallele, volte ad arricchire le interfacce visibili all'interno dei browser: ActiveX ed Applet Java. Nonostante le potenzialità da esse offerte, non hanno mai avuto il successo sperato, tanto che sono state di fatto sostituite da due nuove tecnologie, più vicine allo spirito originale dell'HTML: Dynamic HTML e XML.
Queste ultime, unite allo sviluppo di application server sempre più potenti e raffinati, hanno radicalmente modificato il modo di progettare le applicazioni Intranet. Nel seguito mostreremo come sia possibile, usando nel modo opportuno gli strumenti disponibili, creare GUI efficienti e funzionali sia in rapporto allo sviluppo delle applicazioni sia nei confronti dell'utente.
2. Cenni sulle tecnologie usate per le GUI
Prima di approfondire i temi centrali di questo lavoro, ci sembra utile riassumere gli aspetti fondamentali dei linguaggi e delle tecnologie usate per creare GUI all'interno di un browser.
2.1 HTML
HTML è tuttora il linguaggio per eccellenza del mondo Internet. Il suo pregio principale consiste nella standardizzazione che, se rigorosamente seguita dagli sviluppatori, ne permette la lettura da parte di tutti i browser attualmente disponibili. D'altra parte, l'HTML è statico, ed offre un basso numero di oggetti per la manipolazione dei dati; a causa di ciò, l'utente non ha a disposizione alcuni strumenti ai quali è abituato, come le toolbar, i menù standard o pop-up, eccetera. Inoltre, la mancanza di componenti legati ai campi del database implica che le tecniche di programmazione abituali degli ambienti RAD devono essere modificate, per fornire alle pagine basate sull'HTML la possibilità di mostrare i dati richiesti.
2.2 Java
Java è il linguaggio che maggiormente si è imposto all'attenzione del mondo Internet. Grazie alla possibilità di creare applet, esso è uno strumento privilegiato per superare le limitazioni storiche dell'HTML: dispone di una grande quantità di oggetti, ed essendo standardizzato potrebbe diventare un linguaggio veramente universale. A questo livello, tuttavia, è difficile realizzare una connessione ad un database in maniera efficiente ed indipendente dal browser; la velocità di esecuzione degli applet è un altro punto negativo tuttora insuperato.
2.3 ActiveX
La tecnologia ActiveX, proposta da Microsoft, è un tentativo in parte riuscito di avvicinare l'interfaccia del mondo Internet a quella dei programmi per Windows, allo scopo di rendere uniformi gli ambienti applicativi e di sfruttare il massimo possibile delle conoscenze acquisite dagli utenti. Inoltre può sfruttare una libreria di componenti (già esistenti o di facile implementazione) praticamente illimitata. Si tratta però di una tecnologia di proprietà privata, che dipende fortemente dal sistema operativo e dal browser. Non esiste una standardizzazione, per cui gli utenti sono vincolati alle decisioni del produttore.
2.4 DHTML e XML
L'esperienza ha mostrato che nessuna delle tecnologie
sopra descritte soddisfa pienamente le esigenze emerse con lo sviluppo
di Intranet; l'HTML, tuttavia, ha rappresentato una solida base su cui
sviluppare nuove soluzioni. Le strade seguite sono state due: da un lato
si è cercato di rendere dinamico l'HTML (DHTML), associandolo a
potenti linguaggi di scripting, permettendo la modifica dei contenuti e
della posizione dei componenti anche dopo la visualizzazione della pagina;
dall'altro, si è proposto un nuovo linguaggio (XML) per la separazione
del contenuto dalla formattazione. Purtroppo, DHTML è nato al di
fuori degli standard, ed è difficile conciliare le versioni proposte
dai due maggiori produttori di browser; questo fatto ne ha impedito fino
ad oggi la diffusione auspicata.
3. Caratteristiche delle GUI nelle applicazioni Intranet
L'interfaccia utente di un'applicazione Intranet possiede alcune caratteristiche che la differenziano fortemente da quelle, per esempio, dei programmi per PC. Tali caratteristiche, ed i loro effetti nella progettazione della GUI, sono elencate di seguito.
3.1 Eterogeneità delle esperienze degli utenti
Uno dei più importanti principi della progettazione delle GUI afferma che si devono conservare le conoscenze acquisite dagli utenti nel corso delle loro esperienze informatiche. Ciò ha portato alla creazione, per ciascuno dei principali sistemi operativi presenti sul mercato, di modelli per interfacce utente che, adottati dalle più diverse applicazioni, garantiscono una certa uniformità d'impiego. Tuttavia, le applicazioni Intranet si rivolgono ad utenti dei quali non sono note né le competenze informatiche, né i sistemi operativi che usano. In questo caso, è dunque impossibile sapere quali competenze conservare. L'introduzione di applet Java ed ActiveX ha cercato, come detto, di risolvere questo problema trasferendo nel mondo Internet gli stessi oggetti che gli utenti trovano quotidianamente sui propri computer, senza peraltro soddisfare pienamente il pubblico.
È quindi necessario cercare l'esperienza minima comune a tutti gli utenti potenziali, ed è facile rendersi conto che essa consiste nell'uso del browser e della conoscenza dell'ipertestualità. Una GUI per applicazioni Intranet dovrebbe quindi sfruttare le possibilità offerte dall'HTML per fornire all'utente le funzionalità di base, lasciando alle altre tecnologie il compito di svolgere attività specifiche, e in ogni modo secondarie, all'interno dell'interfaccia.
3.2 Garanzia di funzionalità
È spontaneo chiedersi se con gli oggetti messi a disposizione dall'HTML sia possibile riprodurre tutte le sofisticate funzionalità offerte, per esempio, dalle GUI dei programmi per PC. La risposta è negativa, ma riteniamo che sia sbagliato tentare di copiare questi modelli di GUI: è opinione molto diffusa che le GUI attuali presentino un eccesso di funzionalità rispetto a quelle realmente richieste dagli utenti. Le funzionalità di base, come la visione e la modifica dei dati, la creazione di statistiche e così via, possono essere garantite se si valorizza il ruolo dell'ipertestualità e si fornisce all'utente un ambiente di lavoro facile, intuitivo e simile a quello sperimentato quotidianamente con la navigazione in Internet.
In un precedente articolo [1], uno degli autori aveva mostrato che se un'applicazione per PC è creata riproducendo il meccanismo dell'ipertestualità ed abbandonando quasi completamente le metafore, gli utenti manifestano un grado di soddisfazione molto elevato e, pur in assenza di elementi tradizionali (quali toolbar, icone, eccetera), non ritengono diminuite le funzionalità a propria disposizione. Ciò suggerisce che l'ipertestualità, se usata in modo chiaro e coerente, sia in grado di soddisfare pienamente le esigenze degli utenti, indipendentemente dal contesto in cui essa è inserita.
3.3 Navigazione convenzionale e strutturale
In quest'ottica, la navigazione assume un ruolo essenziale nella progettazione della GUI. Fortunatamente, un'applicazione Intranet si presta molto bene ad essere strutturata secondo un modello ipermediale, come l'HDM [2]. Da questo modello, che usiamo spesso nello sviluppo delle nostre applicazioni, abbiamo ripreso i due concetti distinti di navigazione: convenzionale e strutturale.
Con la navigazione convenzionale l'utente può spostarsi tra i siti ed all'interno delle pagine di un sito, senza fare riferimento all'informazione offerta; con la navigazione strutturale, invece, egli costruisce un percorso attraverso i dati personalizzato sulle proprie esigenze, che ad un analista esterno apparirebbe del tutto casuale.
L'esistenza di queste due logiche di navigazione, normalmente assenti nelle applicazioni tradizionali, fornisce una potenza eccezionale alle applicazioni Intranet. Sicuramente, però, l'utente generico ha maggiore esperienza del primo tipo di navigazione che non del secondo: l'interfaccia utente, quindi, deve aiutarlo ad usare nel modo più naturale e proficuo anche la navigazione strutturale. Fondamentale, per questo visto sopra, è ancora una volta l'uso appropriato dell'ipertestualità, che della navigazione è sempre stato lo strumento principe.
3.4 Strumenti offerti dall'HTML e linguaggi di script
In base a quanto visto, l'HTML offre tutti gli strumenti necessari per creare GUI semplici da usare ma dalle caratteristiche innovative e potenti. Non bisogna però dimenticare che, se associato ad un linguaggio di scripting, come JavaScript, consente di ricreare quando necessario situazioni familiari agli utenti di tutti i sistemi operativi (per esempio la simulazione di toolbar, di finestre pop-up, eccetera).
Si tratta di funzionalità importanti ma, spesso, secondarie rispetto alle attese degli utenti; in base alla nostra esperienza, aiutano gli utenti meno esperti d'Internet ad accettare le nuove interfacce, ma in pochi casi sono state determinanti per il successo complessivo di un'applicazione.
4. Effetti delle GUI sullo sviluppo di un'applicazione
Un'interfaccia progettata male può decretare l'insuccesso di programmi altrimenti ben scritti, mentre una GUI accattivante può nascondere molte pecche. Quest'assioma, comunemente accettato nella programmazione tradizionale, perde validità quando si costruiscono applicazioni Intranet: la GUI, infatti, influenza fortemente tutta l'architettura del sistema, ed un errore nella sua analisi può condurre all'uso di tecnologie inadatte a raggiungere gli obiettivi prefissati, costringendo alla riscrittura dell'intera applicazione. Nel seguito esporremo alcuni punti critici individuati nella progettazione delle GUI.
4.1 Bilanciamento delle operazioni
Nel corso degli anni abbiamo assistito ad una continua variazione del bilanciamento delle responsabilità funzionali tra client e server, arrivando oggi, con il modello multi-tired, ad avere una distribuzione uniforme delle operazioni. Con l'adozione di questo modello, un'applicazione è divisa in moduli distinti, implementando separatamente l'interfaccia utente (o client), la logica di gestione (Buisness logic) e la logica del database. Questo modello può essere conservato anche per le applicazioni Intranet: i primi risultati in questo senso [3] si basano sulla misura delle responsabilità dal lato server e dal lato client. Il fatto che in questo caso specifico il client sia un browser, all'interno del quale è mostrata l'interfaccia dell'applicazione, spinge ad una separazione quasi totale del livello client dagli altri due.
La logica di gestione, normalmente, è implementata all'interno di un'applicazione residente sul server, sia essa di tipo CGI, estensione del Web server, o di altro genere. Tuttavia, esigenze di carico della rete spingono spesso ad eseguire sul client alcune operazioni, come i principali controlli di validità dei dati immessi, usando linguaggi di script. Quante più operazioni si delegano al client, tanto più si rischia di essere vincolati al tipo di browser e di rallentare l'elaborazione. Con un equilibrato bilanciamento delle operazioni, invece, l'interfaccia viene sollevata da molte responsabilità, e questo ne favorisce la funzionalità.
4.2 Universalità dell'interfaccia
Il fatto di operare all'interno di un browser obbliga l'interfaccia a rispettare alcuni vincoli, che talvolta sono invece trascurati. Il principale senza dubbio è quello di essere universale, intendendo con questo il fatto di essere visibile nello stesso modo in tutti i browser.
Condizione sufficiente per raggiungere questo risultato è l'impiego di un sottoinsieme dei tag dell'HTML standard che sia leggibile da tutti i browser in uso, ed il rifiuto di altre tecnologie. Di fatto, seguire questa indicazione porterebbe al rifiuto di strumenti molto utili: normalmente, quindi, si considerano significative solo le due versioni più recenti di Netscape Navigator e di Microsoft Internet Explorer, che secondo tutte le stime sono usati da una percentuale di utenti prossima al 100%. Un'interfaccia universale permette una manutenzione semplice, allunga in modo significativo la durata di vita dell'applicazione ed è realmente cross-platform.
4.3 Universalità degli script
Come detto nel paragrafo 4.1, spesso è utile aggiungere codice lato client, attraverso linguaggi di scripting. Anche questo codice subisce le regole viste per le interfacce: in particolare, deve operare su piatteforme differenti, all'interno di prodotti diversi dei quali non è nota a priori la versione. È molto importante, quindi, prepararsi ad operare in ciascuno di questi ambienti.
Il linguaggio più usato è JavaScript, perché attualmente è l'unico ad essere letto da tutti i browser; ne esistono però quattro versioni differenti, ed il dialetto implementato da Microsoft (JScript) differisce leggermente ma significativamente dal linguaggio standard. Le tecniche per operare su tutti i browser disponibili, molto sviluppate, si basano su due strategie principali:
1) La moltiplicazione del codice, con riconoscimento del browser, che permette di eseguire solo il codice specifico per ogni browser;
2) La scrittura del codice per un browser specifico, e quindi per una determinata gerarchia di oggetti, accompagnata da procedure che riproducono la suddetta gerarchia nel caso in cui il browser in cui sta girando il codice non sia quello previsto.
Rendere universale gli script collegati all'interfaccia
significa rendere più robuste le proprie applicazioni.
5. Usare un modello per progettare la GUI
Non è possibile raggiungere i risultati attesi senza l'uso di un valido modello che, individuati i fattori di rischio, indichi come orientare il progetto per evitare gli effetti di un errato bilanciamento delle operazioni. Abbiamo quindi elaborato un modello informale, denominato Intranet Application Model (IAM) [4], che usiamo comunemente per la nostra produzione.
5.1 IAM
IAM è basato sull'esperienza, e considera l'indipendenza delle applicazioni da alcuni fattori fondamentali (sistemi operativi, web server, browser e database) e l'aderenza delle tecnologie agli standard d'Internet. Quanto più elevate sono l'indipendenza e l'aderenza agli standard, tanto più valida è l'applicazione. Si può dire che in generale l'indipendenza dai fattori sopra indicati permette al maggior numero possibile di utenti l'accesso all'applicazione, mentre seguire gli standard favorisce la creazione di applicazioni aperte ed indifferenti alla rapida evoluzione delle tecnologie ed accessibili.
IAM è stato inserito all'interno del nostro ciclo di analisi, che si basa su OOTC dell'IBM [5], ed è già stato verificato in pratica, fornendo risultati ampiamente soddisfacenti. Riportiamo due esempi che a nostro avviso sono significativi del suo impatto sullo sviluppo di un progetto Intranet.
5.2 Un progetto condotto senza IAM
Un partner ci aveva chiesto di condurre lo sviluppo di un progetto da loro analizzato e destinato a terzi; si trattava di un'applicazione per la raccolta di ordini via Internet. Le scelte tecnologiche erano già state compiute: l'applicazione doveva essere sviluppata con tecnologia ASP ed ActiveX di Microsoft, per riprodurre una GUI quanto più possibile simile a quelle familiari agli utenti di Windows; il server Web sarebbe stato l'ultima versione di Microsoft IIS, sotto NT Server 4.0; il browser non poteva essere che Microsoft Internet Explorer 4.0, che avrebbe dovuto essere lanciato solo su sistemi operativi Windows a 32 bit. Il database scelto, infine, era di marca Oracle.
Si potrebbe pensare che una così rigorosa scelta delle tecnologie da impiegare nello sviluppo e nell'uso del prodotto (tecnologie, peraltro, la cui qualità non è messa in dubbio) avrebbe dovuto garantire il successo dell'operazione, ma non fu così: l'interfaccia che ci fu imposta, infatti, richiedeva il passaggio di un'enorme quantità di dati dal server al client. Applicando il modello IAM all'analisi che ci era stata fornita, mettemmo in guardia il committente sul fatto che i bassi livelli d'indipendenza e di aderenza agli standard rendevano il progetto a rischio, ma invano: ci fu richiesto di completare il progetto in base all'analisi originale.
Il risultato fu che le prestazioni dell'applicazione erano ottime in rete locale, ma inaccettabili attraverso Internet, con gli utenti che dovevano aspettare dai trenta ai novanta minuti per completare la prima operazione. Si trattava, in effetti, di un'applicazione client/server con interfaccia Web, impropriamente definita "applicazione Extranet", che ebbe una vita molto breve.
5.3 Un progetto condotto con IAM
Il secondo esempio riguarda un'applicazione di tipo gestionale da noi analizzata e prodotta, richiesta dall'utente finale. Il prodotto, che doveva sostituire una serie di applicazioni in uso presso il cliente, era destinato alla sua rete Intranet; la manutenzione futura avrebbe dovuto essere a carico del cliente stesso.
Quest'ultima richiesta, vista la specifica esperienza del cliente, ci ha spinti verso un'applicazione che richiede, sul server web, un sistema operativo Windows NT server. Non esistono altri vincoli: l'interfaccia in HTML 2.0, integrata da alcune funzioni implementate con JavaScript 1.0, garantisce la compatibilità con la quasi totalità dei browser attualmente in uso, senza imporre vincoli al sistema operativo dei client. Benché molto sofisticata, l'applicazione (realizzata con Borland Delphi) s'interfaccia al server web attraverso l'interfaccia CGI, ed è quindi sostanzialmente indipendente dal server scelto; usa tabelle di tipo dBase III, per compatibilità con i formati già usati dal cliente, ma può migrare verso altri database semplicemente cambiando pochi parametri.
Il risultato è stato un'applicazione dai livelli d'indipendenza molto elevati. Il cliente è rimasto soddisfatto dalle prestazioni e dalla semplicità di manutenzione, e sta vendendo a terzi l'accesso via Internet all'applicazione stessa.
6. Conclusioni
L'importanza dell'interfaccia utente, in ogni tipo di applicazione, è molto elevata; nel caso di applicazioni Intranet non si limita al lato estetico, ma ricade fortemente su tutto lo sviluppo delle applicazioni. Le tecnologie a disposizione per le GUI di applicazioni Intranet hanno subito evoluzioni notevoli, ma la tendenza più recente indica che l'HTML, nelle sue diverse versioni, conserva il favore degli utenti e degli sviluppatori. Esso rappresenta uno strumento dalle insospettabili capacità, che permette la creazione di GUI semplici da usare, conserva l'esperienza degli utenti, ed offre nuove e potenti funzionalità assenti nei programmi tradizionali, come la navigazione strutturata attraverso i dati, che possono soddisfare pienamente le esigenze degli utenti.
Per raggiungere i migliori risultati, è necessario bilanciare attentamente le operazioni sul client e sul server; inoltre è opportuno mantenersi quanto più possibile indipendenti dalle singole tecnologie ed attenersi agli standard usati in Internet. L'uso di un modello permette di orientare nel modo migliore l'analisi di un'applicazione. In particolare, IAM ha fornito ottimi riscontri ovunque sia stato impiegato.
Bibliografia
[1] Morandotti P., 1997, "L'influenza di Internet sulle GUI: l'ipertestualità sostituirà le metafore?", Atti del congresso AICA '97, pp.397-407
[2] Checchet M., 1996, "L'analisi di un ipermedia", BIT n. 180, Editoriale Jackson, pp.116-118
[3] Marcandalli R., 1998, Comunicazione al convegno JavaForum 1998, organizzato da CEGOS.
[4] Zeffiri S., F. Calì, P. Morandotti, 1998, "A practical approach to Intranet and Extranet Applicaitons", Atti del convegno WebNet '98, organizzato da AACE. Una parte del documento si trova in http://www.intrasoft.it/WebNet98/zeffiri.html
[5] OOTC, 1997, "Developing Object Oriented Software - An Experience-Based Approach", Prentice Hall PTR.