Hello all, I didn't analyse too much to proposals and I'm not such a usability expert anyway. What I like in that process is that working the UI will force Tiny to fix the lack of genericity of their Openobject clients in ways that will benefit all usages. It's currently costly to extend OpenERP because you have to constantly trick the framework to work around its UI limitations such as: https://bugs.launchpad.net/openobject-client-web/+bug/500593 https://bugs.launchpad.net/openobject-client-web/+bug/497967 https://bugs.launchpad.net/openobject-addons/+bug/499120 https://blueprints.launchpad.net/openobject-server/+spec/dynamic-domain-on-selection-widget https://blueprints.launchpad.net/openobject-server/+spec/form-parent-field-update-on-change ... An in any case, there are tons of different ways to achieve a better usability than the current one anyway. In any case I hope Tiny will always favor generic changes rather than changes requiring to create yet new objects without fixing the lack of generiticy of the existing UI concepts. In that sense I welcome the new search view thing because indeed it has been a very simple change which will dramatically improves usability. Now, I totally agree with Ferdinand, the best way to deal with right side links would probably be the "favorite" stuff we discussed in that framework expert list: https://lists.launchpad.net/openerp-expert-framework/threads.html#00068 I also think it might be import Tiny listen to people that have a real OpenERP experience (the expert lists they asked to create) and can propose things that are good engineering compromises between the cost of change/development and the usability improvement rather than auto-proclaimed usability experts that have probably no ERP experience and might sell good proposals but which are totally disconnected from the development/maintainability cost which are the roots of open source projects. In that sense I consider very relevant the remark from Ferdinand: in small companies a few guys will do all tasks and it's important not bloating their user daily work, while larger companies will be totally seduced by an ERP that seems to please all department with some dedicated bullshit dashboard. Let me also just comment upon the "Google Gadget" stuff. I'm among the ones calling for DHTML gadget ability. Being Google or something else doesn't matter at all, iGoogle is just one illustration of that new post-portlet portal generation. What is needed is a way to serve OpenERP view into gadget portals such as iGoogle and also be able to embed iframe DHTML gadgets into OpenERP: https://blueprints.launchpad.net/openobject-client-web/+spec/embedd-custom-dhtml-gadgets https://blueprints.launchpad.net/openobject-client-web/+spec/serve-views-as-dhtml-gadget-or-atom Here is what everyone will be able to do when OpenERP will finally support dead simple iframes gadgets: http://www.youtube.com/watch?v=8EsFJu6p3P4 Of course, 95% of gadgets are not functional marketing stuff. But it's very important to be able to work with the 5% that are functional. Let's say you integrate OpenERP with Salesforce CRM, if Salesforce give you such a gadget for free, it would just so easy and efficient to embed them at some palce in your OpenERP rather than code Python connector just to make the current OpenObject UI happy (will cost 10x more, always require expensive integrator work etc...). If one want to create a product configurator without being limited by the incredible Openobject web client limitations such as: https://bugs.launchpad.net/openobject-client-web/+bug/500593 , it's important one can do it, in the server technology he wants (Python is not among the most popular languages unfortunately), that means client side integration, and DHTML gadgets are here the shortest path. Good to see so much ambition in the UI field anyway. Raphaël Valyi http://www.akretion.com On Tue, Dec 29, 2009 at 1:36 PM, Ferdinand @ ChriCar