openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxx/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@xxxxxxxxxxxxxxxxxxx/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)" <
borjals@xxxxxxxxx> 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
> borjals@xxxxxxxxx
>
> 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-ergonomy@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-ergonomy
> More help   : https://help.launchpad.net/ListHelp
>