openerp-expert-framework team mailing list archive
-
openerp-expert-framework team
-
Mailing list archive
-
Message #01052
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