← Back to team overview

openerp-expert-framework team mailing list archive

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

 

On 2012-12-06, at 15:43 , Valentin LAB wrote:
>> Shooting a bug when you encounter it, big dumps like this one are much
>> harder to trawl through and report progress status on. A short video
>> record is usually greatly appreciated for UI-based issues as — as noted
>> above — it may provide information about your baseline assumptions to
>> the triage teams, assumptions which they themselves may not usually
>> make.
> 
> Thank you for the quick answer. I don't mean to hurt anyone's feeling.

You haven't done any such thing as far as I can see.

> 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.

> it is perfectly normal to have a bunch of things to perfect here and there. I don't feel that launchpad bug reports are really adapted to report those bunch of pre-commit test result.

Sure, these issues should have been found and fixed during the merge
proposal[0], and the interaction model of the list view could have
rather easily been altered back then if it was unsatisfactory. However
they were not, and your messages are pretty much the first external
feedback I've seen since the new list edition was merged *back in July*.
I could have missed it of course, but I noticed your messages so…

As I said previously, it's hard to fix things which are not noticed
internally if nobody tells us about them, especially with things we've
have "internalized" and which we likely don't even notice anymore (such
as the dichotomy between "edition mode" and "creation mode" which gave
you so much grief).

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*.
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).

> I would be happy to give you more time with a live screencast (ie on teamviewer) with skype or hangout on a big tour on this widget flaws and bugs, because I couldn't put them all on the video nor the bug report... (if this proposition seats you, my email, skype name, and phone number are all in the signature of this mail.)

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

> 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.

> Try these simple tasks:
> - To create a new line with similar values than a previous line (this involves copy pasting values from the other line, and force you switch line...).
> - add a prefix to 5 cells in a row (in first column and next try with second column). (this involves displacement between lines).
> - Create lines with content coming from another application (involves switching out of the browser while editing a line).
> 
> Do not stick to only one given view. But check that it works when widget is included as a part of a form view... etc...
> 
> I would love to see a session of usability testing on this widget.
> 
> Anyway, thanks for reading and writing a potentialy great product !

[0] https://code.launchpad.net/~openerp-dev/openerp-web/trunk-editable-list-overlay-xmo/+merge/113431

Follow ups

References