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 :
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
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...
Via High Scalability, j'ai découvert cette présentation intitulée Real World Web: Performance & Scalability donnée lors de la MySQL conference 2008 par Ask Bjørn Hansen. Cette longue présentation (189 pages !) est une excellente compilation de la plupart des conseils que l'on peut trouver un peu partout pour améliorer les performances et l'extensibilité (au niveau de l'architecture) d'une application web par exemple à base de MySQL et du langage de votre choix (PHP, Perl, Ruby, ...)
On peut y trouver également quelques petites phrases assez amusantes du type (traduction libre) :
N'hésitez pas à dé-normaliser les données; [...] appelez cela des summary tables, votre DBA n'y prêtera même pas attention.
où encore une jolie manière d'expliquer les concepts de MVC et d'API
Model : parle le SQL
View : parle le HTML
Controller : parle le HTTP
API : fait des trucs
Bref, ce document mérite de s'y attarder quelques minutes :
