Posted by
Jacques Le Roux on
Jan 21, 2007; 11:46pm
URL: http://ofbiz.116.s1.nabble.com/Simple-backend-UI-enhancement-proposition-tp143920p143941.html
Andrew,
Yes, maybe. But do you think that OOTB in a screen like Catalog/Product following fields are really needed for a demo or a POC :
(this is the more efficient criterion I found for the moment; I found also that it's easier to define fields not to be shown by
default than fields to be shown)
Brand Name
OEM Party ID
Comments
Support Thru Date
Disc. When Inv. Not Avail
Requirement Method Enum Id
Require Inventory
Inventory Message
Rating Type Enum
Rating
Require Amount
Amount Uom Type Id
Product Height
Amount Uom Type Id
Product Width
Width Uom Id
Product Depth
Depth Uom Id
Weight
Weight Uom Id
Quantity Included
Quantity UomId
Pieces Included
I also forgot to say that we might use a property and set it by default to "show all fields". And if you have set to "no show all
fields" then a simple click on the top button and all the hidden fields appears on all screens. And yes, I'm more an more convinced
that it's a smart way to hide unnecessary concepts for 1st approach ! Moreover this is easy to do, ie does not need a lot of
reflexion and action and should not put regression in UI.
BTW do you think that the fields that appears for the moment on this screen for instance are a canonical representation of
"fields-that-must-appears-on-creation-of-a-product-in-an-ERP" ?
What defined this fields exactly ?
Why are they all put on a single screen ?
Why not using tabs on such a screen to hide unnecessary complexity and break this overload of information (BTW I'm convinced that
tabs in form widget would be a must to have) ?
Thanks for you interest !
Jacques
----- Original Message -----
From: "Andrew Sykes" <
[hidden email]>
To: <
[hidden email]>
Sent: Sunday, January 21, 2007 11:06 PM
Subject: Re: Simple backend UI enhancement proposition
> Jacques,
>
> On your suggestion, I think it would only make sense to make a subset of
> the features if there was clear market evidence of what the subset would
> be and who would benefit from it.
>
> As I don't think anything like this is currently available, I'm inclined
> to think that going in this direction would be somewhat arbitrary and
> speculative. It would also create an additional layer of complexity
> leading to additional confusion.
>
> What I'm saying here, is that I can imagine that this would be a benefit
> to any individual, with a clear market, but might be inappropriate OOTB.
>
> - Andrew
>
>
>
> On Sun, 2007-01-21 at 13:16 -0700, David E. Jones wrote:
> > On Jan 21, 2007, at 6:33 AM, Anil Patel wrote:
> >
> > > This is great, Can we do this, Save Screen and Form definition in
> > > Database
> > > (Sceeen and Form widget file will loaded into database.), Party Group
> > > Preferences set of Entities can be designed to store the
> > > information like
> > > which field should be visible/hidden for a Party Group..
> > > By doing this we can customize what user sees on the Screen.
> >
> > This sounds quite a bit different from what Jacques was proposing,
> > but if I understand right what you are proposing this is something
> > I'm happy to write long and loud against.
> >
> > What would we gain by putting these things into the database?
> >
> > What will we lose by putting these things into the database?
> >
> > I'm interested in your thoughts so I won't answer these quite yet,
> > though if you (or anyone) is interested in my answer this is
> > something I've written about in the past quite a bit and you'll find
> > stuff in the old mailing list archives. Still, I'd rather hear
> > other's opinions about it before I express my own, just to make sure
> > I don't miss anything that people might not want to say when I come
> > down hard on this. As I mentioned above, I have very strong opinions
> > about this and these are based on some very bad experiences.
> >
> > -David
> >
> --
> Kind Regards
> Andrew Sykes <
[hidden email]>
> Sykes Development Ltd
>
http://www.sykesdevelopment.com