Archive

WebSphere

Siamo alla fase di collaudo finale della nostra nuova applicazione TFC. Questa applicazione è composta da un server J2EE (su WebSphere Application Server) che si interfaccia ad una applicazione gestionale e da un client sconnesso scritto in WPF 4 destinato all’uso su Tablet PC di tipo slate. Una classica applicazione enterprise ma che usa uno strumento “nuovo" (nuovo se tralasciamo il fatto che i Tablet PC esistono da anni).

Una delle macchine papabili per il client è l’Acer Iconia Tab W500. Si tratta di uno slate basato su Windows 7 con un processore AMD, 2GB di RAM, un disco SSD da 32 GB e un touch screen capacitivo a 4 punti molto preciso. In effetti l’interazione è buona e l’uso delle applicazioni tradizionali è assolutamente accettabile (soprattutto se le applicazioni sono in grado di gestire i 120 DPI impostati del monitor). La macchina è anche discretamente veloce. Il peso è di circa 1 Kg. E’ veramente una buona macchina.

Come accennato l’applicazione client è basata su WPF su .NET 4. Con WPF siamo riusciti ad adattare molto bene l’interfaccia utente al touch. E’ evidente a prima vista che non si tratta della solita interfaccia Windows ma di una interfaccia appositamente pensata. In generale questa applicazione ha generato entusiamo tra i clienti ma anche internamente (tanto è vero che stanno nascendo nuove idee commerciali e tecniche).

Ovviamente con questa nostra applicazione WPF, l’Iconia si comporta meravigliosamente. L’applicazione quando è in primo piano si impossessa completamente dello schermo (ma si può sempre switchare su un’altra), gestisce completamente touch e gesture (touch, pan, pinch zoom, ecc.), utilizza icone, comandi e immagini a misura di dita. E lo sviluppo è stato assai più economico che utilizzare iPad. Vedere cosa si può fare utilizzando Windows 7 è notevole. 

Ora aspetto con fiducia che Microsoft faccia una interfaccia alternativa a Windows Explorer. Ma presto per favore.

Advertisements

Non è un segreto che la nostra azienda si occupi di portali da quando sono nati. E per portali intendiamo quelli di collaborazione e di integrazione applicativa dedicati alle intranet e alle extranet. Con un occhio privilegiato alle funzioni “sociali”.

Ultimamente ho notato un aumento preoccupante dei clienti che approcciano il problema come la creazione e messa in produzione di un applicativo (seguendo i soliti passi: analisi, realizzazione, test, ecc.). E cercando di pensare fin da prima a tutte le funzioni possibili necessarie.

A mio giudizio è un approccio enormemente sbagliato. Un portale è, secondo la definizione che uso io, una soluzione in perenne cambiamento la cui evoluzione spesso è legata direttamente alle esigenze degli utenti. Un portale deve fornire una infrastruttura di collaborazione e integrazione. L’approccio di creazione delle applicazioni deve essere evolutivo, fatto di cicli rapidi (agili?)  di sviluppo per “piccole” funzionalità. La parte di coordinamento di queste funzionalità fornita dal portale genera un grande valore aggiunto. Superata la fase iniziale di creazione si arriva ad una discontinuità: da quel punto in poi la crescita del sistema in termini di utilità diventa enorme. L’inserimento di aspetti “sociali” porta questa capacità di creazione in mano agli utenti aziendali. Di fatto rende assolutamente democratico (o forse darwiniano) il processo di creazione delle applicazioni.

La parte IT si deve occupare della governance di questa infrastruttura, dello sviluppo delle piccole funzionalità di tipo tecnico. Dovrebbe dare consigli e guidare gli utenti ma non dovrebbe costringerli. Un ciclo di sviluppo tradizionale allontana proprio quegli utenti che si vogliono coinvolgere. E il risultato sono portali di collaborazione che gli utenti non usano, che contengono informazioni antiche, che non vengono neppure visitati.

Ultimamente, quando affronto questi progetti con i clienti, cerco di far capire questi aspetti ma, a volte, non è affatto facile.  Quando ci riesco però ci sono delle belle soddisfazioni per me, per i clienti e per gli utenti.