Hello Aline, Borja and all: I agree with Borja and will emphasis a few things at the framework level that would improve usability. (luckily some of our concerns such as osv_memory that can be extended or dynamic domain on widget selection have been implemented already, see http://www.mail-archive.com/openerp-expert-framework@lists.launchpad.net/msg00188.html ):
OK, so here are for us simple things at the framework level (so should hurry up before the freeze) we already mentioned but that are still to be done to improve usability: 1 ) one2many widget management in web client like the GTK client without the need to create resources one by ones. Example: sale order interfaces + sale order lines Would save user clicks and avoid to have to delete a record if at the end there is no need to create it, specially important when working with configuration wizards. 2) symmetric of forms passing parent form fields, but for changing them this time: https://blueprints.launchpad.net/openobject-server/+spec/form-parent-field-update-on-change This is kind of not consistent: a widget can read its parent widget fields but can't change them back. existing example: currently when adding a sale order line, it reads the partner_id from the parent order widget. real example where this sucks: a product configurator such as product_variant_configurator (stable extra addons 5.0): imagine you want to configure a T-Shirt you'll sale, T-Shirt may vary in size (Large / Small) and color (Red / Blue / Green): in the configurator wizard you will have 2 lines in a one2many widget X to select a value for each variant dimension: - size: selection Large / Small - color: Red / Blue / Green The selection of those values will define a search domain for a product.product that match those options. That product._id field is carried by the parent widget Y of that one2many widget. Eventually, if all values are selected in one2many widget X, only one product.product is identified in Y and should be selected. But because currently OpenERP widget are not able to set back the value of a parent field, it's not possible to select the unique matching product once all variant axes are set up! So user need to click again on the parent product_id field in Y and hit tab and see that only one product matches. That's around 3 more clicks or even require you hit the keyboard again... I suggest that if in an on_change value, the server returns parent.field_name, then the field of the parent widget is changed appropriately. 3) option on many2one widget to allow one-click creation without the need to click through the search popup, could be really more user-friendly. I know this was the default behavior in TinyERP 4.X and has been removed to avoid creation of records by mistake. But in v6, that would be cool to have an option attribute to enable that behavior back in some specific forms we want. 4) currently in many2one widgets, if only one record exist, then the search button will auto-select it. So you'll have no chance to hit the new button inside the search popup of the many2one, so you can't create a new item here just because there is one and only one -> it sucks! 5) I believe one2many and many2many widget still do not trigger on_change events one removing an item. This would be required in some advanced user interfaces to behave properly: https://bugs.launchpad.net/openobject-client-web/+bug/341622 6) Confirmation dialog pattern: currently, you don't have in OpenERP the option to click to do an action, then the server answers you blabla are you sure? YES | NO So you would have the option to cancel or assume your action. This is a very commonly requested feature and very classical. Customer often want it and it sucks we have to explain them OpenObject doesn't allow that yet. 7) I believe it's still not possible in a many2one view, to select the view that would popup in the search list view or from record creation/visualization view. Currently we should code for this and override fields_view get and use the context, but I think it would be better to support this natively and declaratively using an attribute parameter. (we do that hack in the fleet_maintenance module for instance). 8) In one2many and many2many widgets, a cool thing is that we can control how the list will appear by specifying a specific list view. A cool one2many widget option would be a list representation of it with only the selected record. That would allow to control the way the many2one record is displayed. Typical example we had (in the stock_rma module): we want to display the selected picking on an RMA CRM incident, but we also want to display the picking state. Currently we have to define a computed field on the RMA object for this and this is not very nicely displayed. It would be much better if would could have an option attribute in the many2one widget to display it with a custom list view. 9) we still lack straightforward navigation from sale order to related pickings and invoices (Please read that thread: http://www.mail-archive.com/openerp-expert-framework@lists.launchpad.net/msg00064.html ): currently you can see most of the picking/invoice information in tabs of the sale order (order line history tabs). But those links require clicks, don't offer an overview and most importantly don't enable jumping to the invoice or picking in simple click. Adding links on the right side menu of the sale order is good, but in a way they are redundant with the info in those history tabs, no? What would be a more unified presentation? Also, as default right side menus, we may want to display all those from related objects present in the current view, so that would include them; not sure... Ferdinand suggested we have a "favorite" feature that would enable user to drag'n'drop easily the linked resources they would like to track on each resource. As a workaround, in v5, I made the sale_invoices_link and sale_packings_link modules in trunk-addons-community Still a better built-in solution would be welcome. 10) Finally I think it's important to make sure the OpenERP clients can easily display third party DHTML widgets in place of OpenERP widgets (like iGoogle or Netvibes portals). I think we could reuse the url widget for that. Indeed, currently it would be hard to have a clean cross platform implementation of a webkit DHTML widget on thye GTK client (and in any case it's not done), that means that probably only the web client would support it. My idea was we add an extra "height parameter on the url widget: in the GTK client, an iframe widget would degrade to the URL of the iframe (that would require to view the widget outside in a browser but would work) while in the web-client, we could display the iframe with the width of the URL field and the specified height. Thus if an URL is actually a third party DHTML widget, we just need to specify the height to display it. Not that I have a working prototype of this on V6. If OpenERP S.A. agrees with the idea, then I can propose a merge. Please log progress/comments about this feature here: https://blueprints.launchpad.net/openobject-client-web/+spec/embedd-custom-dhtml-gadgets Notice that the more native OpenERP widgets are limited (see previous points) the more that last feature is required. Thus we could implement advanced interactive widgets using for instance OOOR or any language framework we want and also play nice with the rest of the world (example: carrier tracking widget, social widget etc...). Raphaël Valyi Founder and ERP Consultant +55 21 3010 9965 http://www.akretion.com <http://www.akretion.com.br/> On Wed, Jul 14, 2010 at 1:35 PM, "Borja López Soilán (Pexego)" < borj...@pexego.es> wrote: > > The guide looks great, good job! :D > > Now, I think you should take a look at the "unified layout of forms" discussions that took place on April on the Accounting Experts mailing list, and maybe add some of the ideas discussed there to the guide: > > Similar documents should have similar interface: > > If document A has a field F, and document B has also an F field, that field should be on the same place on the form (being inside the a notebook page with the same title on both, being at the top/right/left/bottom on both, having the same colspan, using the same name/translation...) unless there is a good reason not to do so. > > This makes the interface easier to learn: Once you master the sales form, you should be like a fish in the water with the purchases form (on the 5.0 this is not true). > > Long names / address fields should have colspan 4, or be at least longer than normal fields, so the user can read the full address/name easily on small screens. > > Functionality should be consistent between similar documents: > > For example sale orders have "payment terms" (so the user can preset the payment terms that should be used when invoicing); purchase orders do not*, why?: To me this is not only a functionality problem but also an usability problem: The user would expect to be able to preset the payment terms on the purchases just as he does on the sales, he will be disappointed when he notices that there is not such option. > (* we just added a "purchase_payment" module to the extra-addons that adds payment info to purchase orders; but I think that the sale&purchase modules should be consistent in basic functionality). > > Aline Preillon wrote: > > Hello, > > I have published one guide line on my blog ( http://useability-openerp.blogspot.com/2010/07/guide-lines.html). In next weeks, I will publish many guide lines. > > The current goal of the usability team is simplify the use of the software. Therefore, we are interested in your ideas regarding this goal. > > Thanks, > > Aline Preillon > > > -- > Borja López Soilán > borj...@pexego.es > > Pexego Sistemas Informáticos S.L. > Avenida de Magoi 66 - 27002 Lugo (España) > Tel./Fax 982801517 > http://www.pexego.es > > > AVISO LEGAL - CLÁUSULA DE PRIVACIDAD > Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si no es usted el destinatario indicado, queda informado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. > > _______________________________________________ > Mailing list: https://launchpad.net/~openerp-expert-ergonomy > Post to : openerp-expert-ergon...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openerp-expert-ergonomy > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : openerp-expert-framework@lists.launchpad.net Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp