- 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 07 Novembre 2009 à 17:19
Je viens de migrer le Planet eZ Publish.fr vers eZ Publish 4.2. Probablement l'une des mises à jour eZ Publish les plus simples et les plus rapides (moins de 2 heures) que j'ai faite. Il faut dire que la procédure de mise à jour de la version 4.1 à la version 4.2 est plutôt plus simple que d'habitude et en plus le site est très simple, il n'utilise aucune des fonctionnalités dont le comportement a changé entre les versions 4.1 et 4.2 et finalement peu de fonctionnalités avancées.
Au passage, les nouveautés de la version 4.2 sont nombreuses mais l'amélioration des performances après un vidage complet des caches devrait ravir les développeurs au quotidien :-), en tout cas j'ai bien vu la différence pendant la migration.
- 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.
