Some thougths about the admin interface refresh of eZ Publish

• Publié le 26 Novembre 2009 à 23:23
• 5 commentaires - 1 trackback

The big new feature of the roadmap of eZ Publish 4.3 is a new admin interface. The work on it has started with a requirements document and a prototype of a page (download it locally if you want to see it in your browser). jQuery is used in the prototype, I don't know if it's a definitive choice, but as I have already said on that topic, a choice of a framework is better than no real choice (even if jQuery is not my preferred JavaScript framework). I think that most of the big needs are already covered in the document but there are some small details that miss in the current admin interface that I would like to see in the future one :

• Labels of each field should be linked to their related input with the for attribute. That's a very small addition but I find it more than useful in web applications.
• The focused input should be highlighted with a different colour. This is another very small improvement which can greatly improve users experience.
• Buttons in the admin interface should be of a different colour depending on the action they trigger. For instance cancel buttons can be orange, publish buttons blue, remove buttons red, ... The main key here is to be consistent over all the interface.

The edit interface of each datatype should also be considered individually to provide the best interface. For instance, the edit template of a datetime attribute should provide a JavaScript calendar (like with the ezwebin package), the template of a time attribute a button to fill inputs field with the current time, the keyword datatype an autocomplete input (like with the ezkeywords_autocomplete extension), ... Beside an advanced edit interface for each attribute, the data entered in the edit form should also be checked with JavaScript (required or not, valid syntax, ...). In case of errors, fields that do not validate should be highlighted with a message until a new valid value is entered. Obviously, if JavaScript is disabled, a server side check should do the same thing. On this topic, there's also a very old feature request in the issue tracker about the ability to add an help text in the class definition that would be displayed under the edit interface of the attribute.

Finally, a great improvement would be to apply general rules on performances frontend. I think of packing and minifying CSS et JavaScript files (with ezjscore !), using CSS Sprites for design images and use optimized PNG files instead of GIF files. This would improve the user experience by speeding up response time and making the admin interface usable with a slow Internet line

13 jours avec Magento

• Publié le 28 Septembre 2009 à 22:47
• 10 commentaires - 0 trackback

Je travaille depuis très exactement 13 jours sur un projet Magento histoire de changer un peu d'eZ Publish. Bon, en réalité j'ai fait 2 jours de formation et 11 de développement plus une petite expérience d'optimisations côté système. C'est certes trop court pour en saisir toutes les subtilités techniques mais c'est largement suffisant pour y voir de très bonnes choses et de beaucoup moins bonnes.

Parmi les excellents points :

• la flexibilité et l'extensibilité : grâce à l'alliance du modèle EAV et à la possibilité de surcharger proprement presque tout le core.
• le système d'installation et mise à jour des modules qui résout pas mal de problèmes liés au développement collaboratif sur plusieurs plateformes différentes avec de multiples informations stockées en base de données
• l'ergonomie générale du backoffice mais ...

Dans les moins bons points :

• le backoffice est lent, vraiment très lent; il n'y a pas (encore) d'éditeur WYSIWYG vraiment intégré, l'accessibilité est loin d'être parfaite (j'aime naviguer dans les formulaires au clavier...), et si une requête AJAX n'aboutit pas pour cause d'expiration de la session, rien ne se passe, pas de message d'erreur, juste rien...
• Magento utilise directement PHP comme langage de template, je ne suis pas fan (je ne vais pas relancer le débat), en revanche quand je vois des templates comme price.phtml, j'ai mal à la tête rien qu'en pensant devoir le modifier un jour...
• la version Entreprise de Magento embarque à la fois Prototype/Scriptacoulous et jQuery, je semble être le seul que ça choque pourtant quand on connaît l'impact de quelques centaines de millisecondes de latence supplémentaire, l'optimisation du temps chargement devrait être encore plus prioritaire sur un outil de boutique en ligne.

Roadmap eZ Publish mise à jour

• Publié le 18 Juin 2009 à 19:35
• 10 commentaires - 0 trackback

Je viens de voir un peu par hasard via un post sur le forum que la roadmap d'eZ Publish a été mise à jour (le 12 juin apparemment) avec les nouveautés pour les deux prochaines versions majeures (4.2 et 4.3). Deux grosses tendances se dessinent dans cette roadmap : les performances (mode classique comme en cluster, ou avec un nouveau mode cluster mixant base de données et NFS qui est déjà dans le SVN) et les interfaces utilisateurs avec surtout un redesign de l'interface d'administration pour la version 4.3 prévue pour tout début 2010 !

Avec cette dernière nouveauté, Gandbox peut espérer rayer une partie de sa whishlist et demander autre chose pour Noël :p Personnellement, j'aimerais bien que ce soit l'occasion de choisir un framework JavaScript intégré à eZ Publish (YUI !) comme cela avait déjà été évoqué lors du dernier eZ Publish Community Day ; ce choix permettrait d'éviter que chaque extension embarque une partie du framework favori de son auteur et oblige à télécharger 500ko de javascript par page avec 3 extensions activées ! Dans le même esprit, l'application des Yahoo! Best Practices dans ce redesign permettrait d'améliorer un peu la réactivité du backoffice ce qui est un point clef de l'expérience utilisateur de ce type d'interface.

Étude du Planet eZ Publish.fr (2/3) : modules/vues et templates

• Publié le 27 Janvier 2009 à 16:59
• 1 commentaire - 0 trackback

Suite de la série de billets sur la réalisation du Planet eZ Publish.fr avec dans celui ci quelques notes sur les modules/vues spécifiques ainsi que sur la réalisation des templates.

I. Organisation et Import des articles
II. Modules/vues sur mesure et templates
III. Performances : caches et compagnie

Modules / vues sur mesure

Pour le moment, seuls deux vues spécifiques sont utilisées sur le site.

feed/planet

Cette vue sert à générer le flux RSS du Planet. Comme pour l'import RSS, le composant Feed des eZ Components est utilisé. L'intérêt principal par rapport à l'export RSS de base est la possibilité d'ajouter la balise dc:author avec le nom du site (l'objet parent dans le cas du Planet). Cette vue implémente également un système de cache sur le même principe que le cache de vue. Ce cache est vidé et est re-généré par le script d'import RSS alors que le cache de l'export RSS par défaut expire au bout d'un temps fixe.

planet/search

Cette vue reproduit la vue de recherche par défaut en forçant la recherche dans une sous-arborescence sans avoir besoin de passer le paramètre SubTreeArray. Contrairement à content/search, elle permet également l'utilisation des persistent variables comme sur content/view.

Templates et opérateur

Les templates pour ce site sont assez classiques et plutôt simples compte tenu de la charte graphique basique. Seule « astuce », chaque vue full fixe deux entrées dans les persistent variables ce qui permet de générer un titre et une description pertinents sans aucun fetch supplémentaire dans le pagelayout qui serait synonyme de requêtes SQL et/ou de cache supplémentaire à gérer (voir les dernières lignes du template planet.tpl et les premières du pagelayout.tpl par exemple).

Le seul opérateur spécifique est l'opérateur clean_rewrite_xhtml utilisé à la place de l'opérateur wash pour afficher les attributs Text block contenant le texte issu des flux RSS. Cet opérateur a plusieurs fonctions :

1. rendre valide le code XHTML avec le module PHP Tidy
2. réécrire les éventuels URLs relatives à site (images et liens)
3. supprimer toute trace de Javascript grâce à quelques expressions XPath.

Optimiser son site : limiter le nombre de requêtes HTTP

• Publié le 30 Août 2008 à 13:36
• 0 commentaire - 0 trackback

Limiter le nombre de requêtes HTTP est la première règle (la plus efficace) pour l'optimisation d'un site bien avant la configuration de l'entête d'expiration et la compression gzip des contenus textuels, mais il peut aussi s'agir de la plus complexe à mettre en place. Si il est assez simple de rassembler les feuilles de style CSS et les fichiers Javascript pour limiter le nombre de téléchargements, le cas des images est un peu plus complexe. On peut appliquer la technique dite des CSS Sprites sur les images utilisées pour la décoration via la propriété CSS background. Cette technique consiste à rassembler les images en un seul fichier et à jouer avec la position pour n'afficher que la zone voulue. En effet un navigateur mettra moins de temps à télécharger 1 fichier que 6 petits fichiers de taille totale équivalente et en plus le fichier réunissant les 6 premiers est généralement plus petit, double bénéfice donc. Au niveau montage, il faut par contre savoir qu'une dimension doit nécessairement être fixée ou au moins contrôlée (par exemple le texte contenu est toujours le même), il ne me semble pas possible de remplacer des images qui se répètent sur les axes X et Y à la fois.

J'ai donc expérimenté cela sur ce site dont le design est suffisamment simple. Le design utilise 8 images via la feuille de style, mais 2 restent un peu à part :

1. le logo RSS est un PNG 24 bit pour que les arrondis soit vraiment arrondis, il restera donc seul
2. l'image utilisée en fond des citations est assez large alors que toutes les autres le sont beaucoup moins ou sont répètées sur l'axe horizontale, elle reste intacte également.

Les 6 images restantes sont à l'origine des GIF, j'en ai profité pour les convertir en PNG pour comparer les tailles des différents agencements, ce qui donne le tableau récapitulatif suivant (les tailles sont en octets) :

Je suis très étonné par la taille du GIF rassemblant les 6 images d'origine. Pour le reste, le PNG est légèrement plus efficace presque partout et le CSS Sprites à base de PNG est 11% plus petit que les 6 GIF originaux (et presque autant avec les 6 PNG), j'ai aussi l'impression que l'affichage du site est un peu plus rapide avec ou sans cache navigateur. Il faut quand même noter que cette technique fait légèrement grossir la feuille de style mais comme celle-ci est compressée l'augmentation est plus que faible (1 octet !) et en m'y replongeant j'ai trouvé quelques optimisations qui ont largement compensées cet écart et je n'ai pas encore réellement minifié la feuille de style...

Finalement sur ce site rien de très compliqué, la mise en page est très simple, le plus dur étant d'ordonner correctement les images pour ne pas se retrouver avec une belle mosaïque. Pour voir un exemple un peu plus complexe, on peut étudier le montage du site Yahoo.fr par exemple même si il ne s'agit pas non plus de la page la plus complexe du monde...