Le temps de chargement d’une application informatique est un point essentiel en terme d’usabilité. Il a un impact important sur l’expérience utilisateur, tellement important qu’il peut être le facteur décisif d’adhésion ou de rejet de l’application par les utilisateurs qui se font un avis en 2-3 secondes. On a tous des exemples douloureux en tête… ou pas d’ailleurs… et c’est bien ça le drame : ces applications passent aux oubliettes!
(Lire la suite…)

De base le toolkit GWT vient avec son framework d’échange : GWT-RPC. Aucun problème particulier dans son fonctionnement mais quelques limitations à la fois dans la configuration que l’on pourra qualifier d’un « peu lourde », ainsi que dans l’intégration avec un existant (typiquement un existant Spring).
(Lire la suite…)

Intégrer de multiples partenaires et applications et donner une vision unifiée et simple à l’utilisateur passe souvent et entre autre par la mise en place d’une brique de SSO.
Dans ce domaine, CAS (Central Authentication Service) fait très certainement partie des référents. Reste que lorsque l’on m’a demandé si l’intégration d’applications GWT avec CAS était réalisable facilement, j’étais bien incapable de répondre…
(Lire la suite…)

Cet article est le second d’une série de deux articles traitant de l’accessibilité du web et de ses enjeux. Nous nous attarderons ici à décrire les normes disponibles pour les RIA, les différents labels existants en Europe ainsi que les outils de validation permettant de confirmer l’accessibilité d’un site ou d’une application.

(Lire la suite…)

GWT 1.5 utilise le Java5…et alors? tout le monde est déjà au courant…
(Lire la suite…)

Cette partie complémente la précédente et propose une autre solution d’implémentation des applications web en mode déconnecté, une solution où connecté et déconnecté sont vus de manière transparente par l’utilisateur…
(Lire la suite…)

La précédente partie a présenté – vue d’avion – les principales problématiques des applications déconnectées et une des technologies d’implémentation : Google Gears.

Cette partie expliquera comment rendre  » offline  » une application GWT en respectant un premier pattern :  » déconnexion explicite « .

(Lire la suite…)

Nos bonnes vieilles applications Web déconnectées…du web…un nouvel enjeu?

Certainement car techniquement et dans un environnement Web – ie où l’application est exécutée dans le navigateur – et donc par définition connectée, c’est plutôt novateur. Peut être pas car les applications déconnectées existent déjà: souvent des applications VB interrogeant une base de données embarquée sur le poste client, la synchronisation des données (du serveur « central » vers le client et du client vers le serveur « central ») répondant à des mécanismes « maison » efficaces.

Cette série de trois articles montrera le développement d’une application Web GWT sur la plateforme Gears et explicitera – de ci et de là – les problématiques d’applications web déconnectées ainsi que les enjeux d’architectures associés:

• la première et présente partie présentera une solution ainsi que quelques problématiques liées à ce type d’architecture
• la seconde partie proposera une solution d’implémentation reposant sur un pattern de « déconnexion explicite ». L’utilisateur demande via une action explicite à passer en mode déconnecté ou offline
• la dernière partie proposera une solution d’implémentation reposant sur un pattern de « déconnexion implicite ». A l’inverse, dans ce cas, connecté et déconnecté sont presque vus à l’identique, du point de vue utilisateur…

(Lire la suite…)