Il 2004, sarà l’anno in cui abbandoneremo html?

Quale problema con html?
Attualmente, per il 95 per cento del web, html opera in maniera eccellente nel fornire contenuti agli utenti. Tuttavia, nel caso di applicazioni su larga scala a livello dell’intera impresa diffuse via web, spesso html semplicemente non fornisce quanto si aspettano gli utenti. Siamo stati chiamati a partecipare a numerosi interventi per la soluzione di casi in cui la ?vecchia? applicazione client/server era stata sostituita con una nuova basata sul web, solamente per trovare utenti frustrati che ci raccontavano come una transazione tipica richiedesse troppi click sul mouse, oppure come una navigazione su pagine multiple producesse perdite di dati premendo il tasto .

Sembra che il problema del ?click/refresh? html/browser non verrà risolto presto. Comunque, il tempo di risposta troppo lento rimane il problema maggiore associato alle applicazioni transazionali basate su Internet. Apprezzabili tentativi di risolvere questi problemi di usabilità e di performance sono stati effettuati da team di sviluppo fortemente impegnati; ma, alla fine dei conti, continuiamo a vedere un pesante insieme di codifica di tipo JavaScript, progetti in ritardo e utenti finali frustrati.

Dove serve qualcosa in più
Una fase di progettazione di una UI (User Interface) rappresenta il modo di descrivere nel dettaglio una soluzione di provata efficacia per un problema di progettazione conosciuto. Classifichiamo le fasi di progettazione delle UI in domini? di alto livello, nel senso di raggruppamento di modelli di operazioni analoghe, schemi di attività e vincoli di diffusione verso gli utenti.

La combinazione html/browser, risultata eccellente per l’area B2C (business to consumer), dimostra rapidamente i suoi limiti in domini più complessi come il B2E (business to employee) e B2B (business to business), nei quali si incrementano in maniera significativa la frequenza d’uso, la complessità e la scala dei fenomeni. Spesso questi domini contengono applicazioni a disposizione dei dipendenti dell’impresa, che debbono utilizzarle obbligatoriamente (Crm, Erp?).

Man mano che le imprese tentano di migliorare, utilizzando quanto hanno imparato dai sistemi esterni con cui si confrontano, si rendono conto che i tipi di utenti sono molto diversi tra loro e che i vincoli di diffusione delle applicazioni, come il supporto dei browser, non sono così ampi. Estendere la funzionalità dei browser per soddisfare le necessità di questi modelli di UI, spesso, richiede l’impiego di nuove tecnologie, standard di diffusione e test di usabilità, per garantire che i nuovi modelli risultino utili per migliorare l’esperienza degli utenti.

Applicazioni via Internet
L’alto costo per supportare soluzioni tick client?, seguite da molti tentativi di soluzioni thin client a impatto zero?, ha portato alla prossima generazione di UI rich client, a loro volta indicate come smart client?, ovvero client intelligenti. Questi smart client possono utilizzare un server web oppure le estensioni di un server, per caricare la quantità di codifica strettamente necessaria per ottimizzare l’attività dell’utente, con riferimento alla larghezza di banda della rete e ai vincoli architetturali dei sistemi.

Spesso, esiste un piccolo applet Java, oppure un software proprietario, che gestiscono le comunicazioni dal lato server per facilitare via xml o Java il comportamento dello smart client?. La flessibilità nel modo con il quale comunicano il client e il server risulta critica nel momento in cui si rendono operative applicazioni complesse al livello dell’intera impresa.

Come abbiamo avuto modo d’imparare durante l’era client/server, risulta critico separare i rispettivi livelli di presentazione, operativi e dei dati. Le soluzioni rich client, che forzano a inserire la logica operativa dell’impresa nel livello delle UI, risulteranno meno stabili e più di difficili da aggiornare, così come è avvenuto per le soluzioni html/JavaScript attivate negli ultimi anni.

La diffusione degli smart client può variare dai telefoni cellulari e Pda, fino all’implementazione di browser e ad applicazioni autonome. A causa del grande numero di utenti e di attività attualmente in uso all’interno delle grandi imprese, siamo convinti che una piattaforma solida per le applicazioni Internet dell’impresa dovrebbe supportare interamente anche i modelli degli utenti che si collegano occasionalmente, dato che questo tipo di modelli comuni di UI si sta diffondendo rapidamente.

Esempi di applicazioni rich client
La prossima generazione di applicazioni Internet sarà capace di molto di più di una semplice rappresentazione di pagine. Saranno in grado di eseguire calcoli complessi e gestire ogni tipo di elaborazione dei dati, oltre a spedire e ricevere dati in modalità asincrona, consentendo agli utenti collegati occasionalmente di attivare applicazioni in un ambiente mobile.

I problemi di presentazione delle informazioni, come la necessità di ridisegnare sezioni di uno schermo oppure la presentazione sullo schermo di visualizzazioni multiple simultanee saranno superati e tutto questo sarà disponibile indipendentemente dall’architettura di back end alla quale ci si colleghi.
Questo esempio illustra l’uso di un formulario di base sommario/dettaglio che, naturalmente, può essere realizzato in HTML. Tuttavia, il ritardo di refresh delle pagine associato con ogni click del mouse su di una tabella in un sistema transazionale con alti volumi di attività creerà un traffico di rete eccessivo, riducendo il tempo complessivo di risposta del sistema.

Utenti abituati ai tempi di risposta inferiori al secondo di applicazioni mainframe o client-server tradizionali, spesso dimenticheranno i dati nel momento in cui si muovono da una tabella all’altra, oppure semplicemente eviteranno di navigare verso altre tabelle per non subire ritardi frustranti.
Questo tipo di modelli visuali, quando siano implementati come applicazioni Internet dell’impresa, debbono consentire al team di sviluppo di affinare l’applicazione in modo da caricare rapidamente la prima tabella che debba essere visualizzata, caricando poi in maniera asincrona le tabelle secondarie in background, se necessario. In sintesi, un’applicazione Internet robusta dovrebbe consentire di minimizzare il carico di lavoro per la diffusione del client tenendo conto dei vincoli di piattaforma, di uso del modello e di larghezza di banda della rete.

Questo esempio illustra un buon uso di Flash per fornire un metodo ricco e interattivo per selezionare e visualizzare rapidamente la rappresentazione visiva della scelta, senza effettuare giri inutili sul server. Riteniamo che gli scenari di configurazione visiva siano uno dei migliori usi delle interfacce client Flash-rich.

Scelta della piattaforma
Siamo convinti che la scelta di una piattaforma client rich rappresenti una decisione strategica, simile a quella relative a J2EE, oppure .Net, sul server. A prima vista, alcuni team potrebbero pensare che stiano acquistando semplice librerie di software.

Tuttavia, per le applicazioni dell?intera impresa, gli elementi critici per un successo a lungo termine saranno costituiti da un ambiente elaborativo e da un’infrastruttura solida, che si integrino facilmente con le piattaforme middleware prescelte. Inoltre, se utilizzate un sistema ad alto volume di transazioni, avete bisogno di comprendere fino in fondo il modo per ottimizzare la vostra soluzione rich client, per definire al meglio la quantità di codifica da far girare sul client oppure sul server.

Al momento attuale, il campo di attività per le applicazioni Internet dell’impresa sembra avere due connotazioni distinte. La tabella seguente costituisce un sommario degli aspetti fondamentali da considerare per applicazioni transazionali Internet, ad alto volume di traffico.

Caratteristiche fondamentali da considerare per le piattaforme Internet dell’impresa

• Applicazione degli standard (XML,J2EE)
• Integrazione del database dal lato server
• Estensione degli oggetti server alla Gui (Graphic User Interface)
• Supporto delle operazioni off-line sul client
• Supporto di sessioni client strutturate e persistenti
• Supporto dell’attivazione automatica del client da parte del server
• Supporto degli approcci standard alla sicurezza (crittografia dei dati, certificazioni digitali, client protetti)
• Possibilità di adottare un modello di sviluppo meno complesso.