← Back to team overview

openerp-expert-framework team mailing list archive

Re: Web widget for Editable Tree views barely usable in trunk

 

At that pre-commit stage

There's no such thing as pre-commit, before commit changes are solely on
the developer's own machine which is probably the place least likely to
"find" (notice) UI issues. If it's not committed it can't be tested. I'm
guessing you're talking about pre-merge.

You are right, I'm using the now-incoherent term "pre-commit" for what you are referring for pre-merge. Although, AFAIK it seems the consecrated term (for historical reason) used to describe pre-merging/publishing to trunk.

OpenERP review process seems to me far from satisfying.

Side-note: in fact I see a clear example of the previously mentioned
"baseline assumptions" issue which made Jignesh's requests necessary:
your first issue notes values are lost when "click[ing] out of the
current field with the mouse". The first thing I thought when reading
that was clicking *outside the list*, which likely works, but it turns
out you were talking about clicking *on an other row within the table*.

Yup, I saw this also. Didn't mention because that's exactly what could cause a bad review: taking 1 min to try and at first fail, making the conclusion that the bug reporter is not clear enough (which is the case) and thinking that's all about the triaging bug job. This means to me that OpenERP don't give enough time to the bug triage team to make a better job. My list of bugs was not meant to be a classical bug report, but a big red flag to ask for a throughout review of this widget in its whole.

I feel that you could often get much more from our "imperfect" feedbacks, that triager have a strong tendency to tackle bug reports when they can, as if OpenERP had no time to spend reading a not perfect bug report, ignoring even the fact that there was a bug until it's perfectly reported. This is actually moving the complete burden of perfecting the bug report towards the reporter (which partly responsible for it, don't get me bad). The reporter will, in consequence, avoid reporting bugs the next time, thinking: if OpenERP spends less time reading my bug report than I've spent time writing it, and dismisses it so quickly or ask me to do their work, why should I bother ?

And this creates a false sense of making good software: If there are no perfect bug report, there are no bugs, so my software is good enough.

You state that I'm the only one reporting a bug on this widget ? Are you aware, when considering the actual state of the widget, that this is evidence that either: 1 - nobody has used it yet more than trivially (even the supposed reviewer), and/or 2 - your feedback process is flawed.

In the light of this case, knowing that OpenERP 7.0 is in beta phase (near releasing release candidate) can be frightening for the global application quality. I can't see any reason why it should be any better (no better review, small feedbacks).

This is also, probably, why Jignesh was not able to reproduce the issue
and asked for clarification (that and that he tried to reproduce on
an o2m widget, an other hidden assumption).

This bug occurs on o2m widget also, even if there are also a lot of other bugs around them. Please do not forget to play with big lists (more that one screen) of sequenceable items, and try to re-order in o2m widget.

I'll start working with the video you've done so far if you don't mind.

If you want a review pre-commit (/merge) ping me. I don't know why, but I am not very fond of the current review process that validated first this widget's functional behavior.

Finding bug in this is as easy as having to work with it.

Not *only*, it seems to also depend whether you're navigating the list
using the mouse or the keyboard, and probably on implicit
understandings/internal models (e.g. modal create/edit context). In some
cases it also depends on the exact configuration of the list.

Yep, and all these are more-or-less behaving strangely or bugged (cf the end of my mail). This is a very complicated widget. Navigation seems to have been provided thanks to arrows, tabulation, enter key, alt-tab, mouse clicks in / out different part of the screen (out of the list, other existing line, same line, same cell, other cell of line), Edit/Save mode, in a new line or editing a previously existing lines...

All of these seems to have been partly implemented and do not stand as a whole.

BTW, it seems sequenceable list do not get a correct sequence at creation (they all stay at 0), which seems to be a design choice that I don't understand (this was already the case since... the beginning). I may have missed something, but moving a line around re-sequence correctly all lines... so I do not understand why this is not done also at creation.

Can you explain me the position of the cursor when using "arrow down", or when is the whole content of a cell selected by default ? (using tab selects the text of the target cell by default iff it is not the first cell of the row ?!?, mouse click and arrow movements do not select content of the text). When do we exit edition mode ? (down arrow and tab won't, left arrow at the end of the cell will). When is the content of the line saved ? (moving to another cell of the same line seems to do so, as enter key...) Why do the down arrow move to the end of the cell content at first press, then if at the end of the cell content it goes down ? The new line created doesn't disappear when empty, and disappear in some cases (o2m widget, alt-tab out of browser) when filled !

There are obviously ergonomical design choices mixed with plain bugs here... are you trying to mimick a well known and proven table edition ergonomic model I would'nt be aware of ?.

--
Valentin LAB

tel:  +33 6 71 39 62 13
mail: valentin.lab@xxxxxxxxxxx


Follow ups

References