- Publié le 23 Mars 2010 à 14:29
About a month ago, I created a new project called admin2++ on projects.ez.no. As written in the project page, the purpose of this project is to go further in the administration interface refresh both on the frontend performance and on the features for users to achieve what I wrote last november on the admin interface refresh of eZ Publish. On the frontend performance side, changes are quite hidden but are there, so it's time to do some advertising :-) In fact, it's more or less an application of my talk in Geneva on frontend performance with eZ Publish.
Current enhancements on frontend performance
The admin2++ extension provides the following enhancements to eZ Publish admin2 interface :
- the twenties background images have been incorporated into three sprites images to decrease the number of HTTP requests. This also decreases the total background images size from about 30Kb to 6Kb.
- PNG Content class icons and PNG admin2 design images have been optimized. Here again the total size of icons and images is decreased from about 200Kb to 147Kb.
- the admin2++ extension provides parts of Apache2 config files to enable GZip compression and set a far future Expires header where possible
- I also replaced the code using YUI3 (drag'n drop of sub-items when sorting with priority) or YUI2 (Date picker) JavaScript frameworks by a code based on jQuery and jQueryUI as jQuery is used for most features of admin2 and jQueryUI is used for others features provided by the extension. This avoids loading three JavaScript frameworks.
- Most of the JavaScript code executed in page has been deferred to DOM ready event instead of DOM load.
- The login page preloads the most used images and all the JavaScript files needed by the admin interface. I tried to configure eZ Publish/eZJSCore so that the JavaScript pack file generated by eZJSCore operators is the same on all pages. The browser downloads the JavaScript on the login page and then it always uses its cache on others pages. I'm happy to see that a part of this has been ported in the eZ Publish trunk :-)
What is missing, future developments ?
I wanted to override ezdesign and ezimage operators to automatically add the last modification date of a ressource in file URI so a far future header can be set on all design ressources without any browser cache issue. Unfortunately, overriding template operators is not possible for the moment. Currently, the expires is set to only seven days in expires.conf provided in the extension for most design ressources.
In addition, a lot of others small improvements would be possible like minifying inline JavaScript code or part of the HTML itself, ... and as usual, it lacks some documentation on how to set it up.
- Publié le 26 Novembre 2009 à 23:23
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
- Publié le 29 Septembre 2009 à 00:47
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.
- Publié le 18 Juin 2009 à 21:35
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.
- Publié le 27 Janvier 2009 à 17:59
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 :
- rendre valide le code XHTML avec le module PHP Tidy
- réécrire les éventuels URLs relatives à site (images et liens)
- supprimer toute trace de Javascript grâce à quelques expressions XPath.
