Simple backend UI enhancement proposition

[Jacques Le Roux]

After an exchange with Ian McNulty about UI clarification, I thought a bit for a solution (actually I did not thought a lot, the idea was there, clear, when I waked up ;o)

Ian is not the 1st to complain about backend complexity. Yes, my propostion is only about backend. Because IMO eCommerce and POS (and handheld now) are more there for demo and POC purposes. They are not intended to be used as is but are ready to be enhanced, proposing a way to go. They are meta-templates actually. On the other hand and that's why backend is mostly build with screen and form widgets : it does not need to be too sophisticated (that does not mean that you can't build sophisticated UI with widgets ;).

From my experience when it comes to backend, even big companies (I mean multinational corporations) are not inclined to put a lot money in. They will perhaps want some enhancements here an there but they do no want to re-create it all. This to said that we may try to ease its use even for them.

My proposition : some screens (for instance Catalog/Product, Catalog/Store, etc.) are always showing all the possible fields to use. We may add (and generalize everywhere possible) a way to hide (or show) not mandatory fields or maybe not important fields (because in most case showing only mandatory fields make no sense). For instance we may put 2 buttons near language set zone at top of screen : "show (or hide) required fields" or something like that. This is easy to achieve and will reassure users about the backend usability (ergonomy). We only have to create 2 set of fields for each screen. If a screen is not concerned the sets will be the same and the buttons will have no action, simple isn' it ?

What do you think ?

Jacques

[Anil Patel]

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.

Regards
Anil Patel




On 1/21/07, Jacques Le Roux <[hidden email]> wrote:

>
> After an exchange with Ian McNulty about UI clarification, I thought a bit
> for a solution (actually I did not thought a lot, the idea was there, clear,
> when I waked up ;o)
>
> Ian is not the 1st to complain about backend complexity. Yes, my
> propostion is only about backend. Because IMO eCommerce and POS (and
> handheld now) are more there for demo and POC purposes. They are not
> intended to be used as is but are ready to be enhanced, proposing a way to
> go. They are meta-templates actually. On the other hand and that's why
> backend is mostly build with screen and form widgets : it does not need to
> be too sophisticated (that does not mean that you can't build sophisticated
> UI with widgets ;).
>
> From my experience when it comes to backend, even big companies (I mean
> multinational corporations) are not inclined to put a lot money in. They
> will perhaps want some enhancements here an there but they do no want to
> re-create it all. This to said that we may try to ease its use even for
> them.
>
> My proposition : some screens (for instance Catalog/Product,
> Catalog/Store, etc.) are always showing all the possible fields to use. We
> may add (and generalize everywhere possible) a way to hide (or show) not
> mandatory fields or maybe not important fields (because in most case showing
> only mandatory fields make no sense). For instance we may put 2 buttons near
> language set zone at top of screen : "show (or hide) required fields" or
> something like that. This is easy to achieve and will reassure users about
> the backend usability (ergonomy). We only have to create 2 set of fields for
> each screen. If a screen is not concerned the sets will be the same and the
> buttons will have no action, simple isn' it ?
>
> What do you think ?
>
> Jacques
>
>

[David E Jones]

So, how do we decide which fields are required (mandatory) or not?

-David


On Jan 21, 2007, at 4:28 AM, Jacques Le Roux wrote:

> After an exchange with Ian McNulty about UI clarification, I  
> thought a bit for a solution (actually I did not thought a lot, the  
> idea was there, clear, when I waked up ;o)
>
> Ian is not the 1st to complain about backend complexity. Yes, my  
> propostion is only about backend. Because IMO eCommerce and POS  
> (and handheld now) are more there for demo and POC purposes. They  
> are not intended to be used as is but are ready to be enhanced,  
> proposing a way to go. They are meta-templates actually. On the  
> other hand and that's why backend is mostly build with screen and  
> form widgets : it does not need to be too sophisticated (that does  
> not mean that you can't build sophisticated UI with widgets ;).
>
> From my experience when it comes to backend, even big companies (I  
> mean multinational corporations) are not inclined to put a lot  
> money in. They will perhaps want some enhancements here an there  
> but they do no want to re-create it all. This to said that we may  
> try to ease its use even for them.
>
> My proposition : some screens (for instance Catalog/Product,  
> Catalog/Store, etc.) are always showing all the possible fields to  
> use. We may add (and generalize everywhere possible) a way to hide  
> (or show) not mandatory fields or maybe not important fields  
> (because in most case showing only mandatory fields make no sense).  
> For instance we may put 2 buttons near language set zone at top of  
> screen : "show (or hide) required fields" or something like that.  
> This is easy to achieve and will reassure users about the backend  
> usability (ergonomy). We only have to create 2 set of fields for  
> each screen. If a screen is not concerned the sets will be the same  
> and the buttons will have no action, simple isn' it ?
>
> What do you think ?
>
> Jacques

[David E Jones]

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

[Andrew Sykes]

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

[Jacques Le Roux]

Yes, that's most part of the work. I will think about it and elaborate more my proposition. Of course any help is welcome.
I guess we will have to make a consensus about which fields are preferably shown. I regret to have used "mandatory" or even
"required" as this has no sense as I previously wrote because then we will end with screens with only very few fields when other
fields
would be hidden. We have to make some fuzzy choices here...

BTW I made a 1st answer to Andrew Sykes in another post...

Jacques

PS:

>
> So, how do we decide which fields are required (mandatory) or not?
>
> -David
>
>
> On Jan 21, 2007, at 4:28 AM, Jacques Le Roux wrote:
>
> > After an exchange with Ian McNulty about UI clarification, I
> > thought a bit for a solution (actually I did not thought a lot, the
> > idea was there, clear, when I waked up ;o)
> >
> > Ian is not the 1st to complain about backend complexity. Yes, my
> > propostion is only about backend. Because IMO eCommerce and POS
> > (and handheld now) are more there for demo and POC purposes. They
> > are not intended to be used as is but are ready to be enhanced,
> > proposing a way to go. They are meta-templates actually. On the
> > other hand and that's why backend is mostly build with screen and
> > form widgets : it does not need to be too sophisticated (that does
> > not mean that you can't build sophisticated UI with widgets ;).
> >
> > From my experience when it comes to backend, even big companies (I
> > mean multinational corporations) are not inclined to put a lot
> > money in. They will perhaps want some enhancements here an there
> > but they do no want to re-create it all. This to said that we may
> > try to ease its use even for them.
> >
> > My proposition : some screens (for instance Catalog/Product,
> > Catalog/Store, etc.) are always showing all the possible fields to
> > use. We may add (and generalize everywhere possible) a way to hide
> > (or show) not mandatory fields or maybe not important fields
> > (because in most case showing only mandatory fields make no sense).
> > For instance we may put 2 buttons near language set zone at top of
> > screen : "show (or hide) required fields" or something like that.
> > This is easy to achieve and will reassure users about the backend
> > usability (ergonomy). We only have to create 2 set of fields for
> > each screen. If a screen is not concerned the sets will be the same
> > and the buttons will have no action, simple isn' it ?
> >
> > What do you think ?
> >
> > Jacques
>
>

[Jacques Le Roux]

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

[David E Jones]

Okay, now behind curtain #2...

The whole point of my question was to get you and others thinking.  
The policy on this was established years ago.

For OFBiz OOTB the point is to be as inclusive as possible. There is  
one reason for this: it is easier to know something is there and  
decide you don't want it and then to remove it than it is to not know  
that it exists and either try to find it or end up implementing it anew.

How do you decide which fields you want? It depends on the  
organization, and even more so on the role within the organization.

So, there is no one answer for all users of OFBiz. There isn't even  
an answer for everyone in a single organization (unless it is REALLY  
small).

This has been thought through over and over and the OFBiz framework  
was designed very specifically to handle this sort of thing. It is  
relatively easy to create user interfaces that are specific to  
certain roles within an organization, and that is what OFBiz  
customization or creation of derivative works is all about. That's  
the very definition of it.

I'm not sure where the best place is for this, but the Best Practices  
Guide seems like a good place to start, so there is now a new section  
there about Generic Versus Special Purpose :

http://docs.ofbiz.org/x/kwE

-David


On Jan 21, 2007, at 4:43 PM, Jacques Le Roux wrote:

> Yes, that's most part of the work. I will think about it and  
> elaborate more my proposition. Of course any help is welcome.
> I guess we will have to make a consensus about which fields are  
> preferably shown. I regret to have used "mandatory" or even
> "required" as this has no sense as I previously wrote because then  
> we will end with screens with only very few fields when other
> fields
> would be hidden. We have to make some fuzzy choices here...
>
> BTW I made a 1st answer to Andrew Sykes in another post...
>
> Jacques
>
> PS:
>
>
>>
>> So, how do we decide which fields are required (mandatory) or not?
>>
>> -David
>>
>>
>> On Jan 21, 2007, at 4:28 AM, Jacques Le Roux wrote:
>>
>>> After an exchange with Ian McNulty about UI clarification, I
>>> thought a bit for a solution (actually I did not thought a lot, the
>>> idea was there, clear, when I waked up ;o)
>>>
>>> Ian is not the 1st to complain about backend complexity. Yes, my
>>> propostion is only about backend. Because IMO eCommerce and POS
>>> (and handheld now) are more there for demo and POC purposes. They
>>> are not intended to be used as is but are ready to be enhanced,
>>> proposing a way to go. They are meta-templates actually. On the
>>> other hand and that's why backend is mostly build with screen and
>>> form widgets : it does not need to be too sophisticated (that does
>>> not mean that you can't build sophisticated UI with widgets ;).
>>>
>>> From my experience when it comes to backend, even big companies (I
>>> mean multinational corporations) are not inclined to put a lot
>>> money in. They will perhaps want some enhancements here an there
>>> but they do no want to re-create it all. This to said that we may
>>> try to ease its use even for them.
>>>
>>> My proposition : some screens (for instance Catalog/Product,
>>> Catalog/Store, etc.) are always showing all the possible fields to
>>> use. We may add (and generalize everywhere possible) a way to hide
>>> (or show) not mandatory fields or maybe not important fields
>>> (because in most case showing only mandatory fields make no sense).
>>> For instance we may put 2 buttons near language set zone at top of
>>> screen : "show (or hide) required fields" or something like that.
>>> This is easy to achieve and will reassure users about the backend
>>> usability (ergonomy). We only have to create 2 set of fields for
>>> each screen. If a screen is not concerned the sets will be the same
>>> and the buttons will have no action, simple isn' it ?
>>>
>>> What do you think ?
>>>
>>> Jacques
>>
>>
>

[Daniel Martínez-4]

Hello,

I am Daniel Martínez, I have created a company in Spain which main
business is as an ERP service provider. I like a lot ofbiz. I am now
using to develop a custom application for a customer and it will surely
become my main tool for the business.

This said, I agree completely with Andrew. I don't think the number of
fields in a screen affect directly the usability or ergonomy of ofbiz.
If it is a problem it is because the screen is not well organized and
this has other solutions (like the Tabs you comment)

As a general rule I think the screens should have all the fields defined
in the entity model. Of course there would be exceptions like deprecated
fields or not usable ones. I don't think ofbiz should target a canonical
representation of a product in an ERP (I don't think such model exists),
but to show the real potential of the ERP and its functionalities.

The criterion for choosing the fields "really needed for a demo" is IMO
very subjective. From my experience, what potential customers are
willing to see in a demo is something that work for their business and
so it should be the service provider role to make modifications to show
the customer that this tool will meet his expectations.

Thanks for a great ERP!!

--
Daniel Martínez

Jacques Le Roux escribió:

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

[jonwimp]

I agree with David here.

First off, how difficult is it to "customize" OFBiz and cut away some fields from the forms? If a
business only ever uses certain fields, what's the point of hiding the others away
programmatically? Why not just cut the front-end forms?

As I told my boss, many fields (in database) are not mandatory, so no harm cutting them out on
front-end forms. I believe (hope) that David and other committers have guided OFBiz-ERP
development in such a way that data structures remain as flexible as possible, allowing
customizers to slap on constraints themselves if they do want to use the non-mandatory fields. If
that is so, I don't see a problem in simply cutting of front-end form fields we don't need (let
the unused values be null in database).

Moreover, and this can be a big one, why would we want to burden the database with front-end
forms? I can see why we have to store images (company logos) in database, but not why we should
make OFBiz a flexible "design your entire storefront and ERP screens from ground-up" solution.
Server performance is major concern here.

Added complexity and reduced flexibility can also happen. Say you have certain flags (alright, not
full form definitions) in database that dictate whether certain fields are shown or not. Doesn't
that restrict my freedom to cut out some fields from front-end forms? I take one field out
unwittingly from front-end form, I'll possibly get a nullpointer error somewhere propagated from
database upwards.

At any rate, I don't see much ROI here. Seems more trouble than it's worth. Spend effort on
something else?

Just my 2 cents.

Jonathon

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
>

[Anil Patel]

If we have Form meta data in Database then we can enhance the screen
rendering system to read field visibility attribute from the database.
So lets say, userLogin.userId belongs to Casher User group. So when
rendering a ScreenA::FormX, System will look for visibility attributes of
fields on FormX as part of ScreenA for Casher userGroup.

I have seen PeopleSoft does this.

Regards
Anil Patel

On 1/21/07, David E. Jones <[hidden email]> 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
>
>
>
>

[David E Jones]

So, you're thinking of more of a permission system?

-David


On Jan 21, 2007, at 9:10 PM, Anil Patel wrote:

> If we have Form meta data in Database then we can enhance the screen
> rendering system to read field visibility attribute from the database.
> So lets say, userLogin.userId belongs to Casher User group. So when
> rendering a ScreenA::FormX, System will look for visibility  
> attributes of
> fields on FormX as part of ScreenA for Casher userGroup.
>
> I have seen PeopleSoft does this.
>
> Regards
> Anil Patel
>
> On 1/21/07, David E. Jones <[hidden email]> 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
>>
>>
>>
>>

[Anil Patel]

yes we can also say that. true.



On 1/21/07, David E. Jones <[hidden email]> wrote:

>
>
> So, you're thinking of more of a permission system?
>
> -David
>
>
> On Jan 21, 2007, at 9:10 PM, Anil Patel wrote:
>
> > If we have Form meta data in Database then we can enhance the screen
> > rendering system to read field visibility attribute from the database.
> > So lets say, userLogin.userId belongs to Casher User group. So when
> > rendering a ScreenA::FormX, System will look for visibility
> > attributes of
> > fields on FormX as part of ScreenA for Casher userGroup.
> >
> > I have seen PeopleSoft does this.
> >
> > Regards
> > Anil Patel
> >
> > On 1/21/07, David E. Jones <[hidden email]> 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
> >>
> >>
> >>
> >>
>
>
>
>

[jonwimp]

Why don't we reuse the existing permissions infrastructure (no new Form meta data in database),
and simply code the front-end to show/hide fields based on those permissions?

Jonathon

Anil Patel wrote:

> yes we can also say that. true.
>
>
>
> On 1/21/07, David E. Jones <[hidden email]> wrote:
>>
>>
>> So, you're thinking of more of a permission system?
>>
>> -David
>>
>>
>> On Jan 21, 2007, at 9:10 PM, Anil Patel wrote:
>>
>> > If we have Form meta data in Database then we can enhance the screen
>> > rendering system to read field visibility attribute from the database.
>> > So lets say, userLogin.userId belongs to Casher User group. So when
>> > rendering a ScreenA::FormX, System will look for visibility
>> > attributes of
>> > fields on FormX as part of ScreenA for Casher userGroup.
>> >
>> > I have seen PeopleSoft does this.
>> >
>> > Regards
>> > Anil Patel
>> >
>> > On 1/21/07, David E. Jones <[hidden email]> 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
>> >>
>> >>
>> >>
>> >>
>>
>>
>>
>>
>
>
> ------------------------------------------------------------------------
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.432 / Virus Database: 268.17.4/643 - Release Date: 1/21/2007 5:12 PM

[Guido Amarilla]

It is not necessary to completely hide some fields, we could use AJAX
visibility and some option to change it without a page reload. It
could be a good idea to fill the form´s default values on BEFORE form
load, and not only if the user didn´t fill a field after submitting
the form. Tab navigation and form sectorization is a great idea too
(much better with AJAX).

I am thinking of some kind of runtime templating for the visibility of
fields. It could be implemented in AJAX. For example you have the New
Product Creation form with lots of fields, and you could have a
dropdown to select the type of product and according to the selected
option you can hide some form fields that are not relevant (having the
"All Fields" option on top or bottom for advanced users). You could
load some default values in some fields and if the user wants, could
be changed.

I don´t know OFBiz so much yet but I think that something like this
could help "cleaning" the screens in some places.

It could be very useful for new users to have a help icon link next to
each field or for each form with a full explanation of each field and
examples.

Another important feature, is to visually mark wich are the mandatory
fields in a form. I think that there is a JIRA issue for that.

Guido Amarilla

2007/1/22, Jonathon -- Improov <[hidden email]>:

> Why don't we reuse the existing permissions infrastructure (no new Form meta data in database),
> and simply code the front-end to show/hide fields based on those permissions?
>
> Jonathon
>
> Anil Patel wrote:
> > yes we can also say that. true.
> >
> >
> >
> > On 1/21/07, David E. Jones <[hidden email]> wrote:
> >>
> >>
> >> So, you're thinking of more of a permission system?
> >>
> >> -David
> >>
> >>
> >> On Jan 21, 2007, at 9:10 PM, Anil Patel wrote:
> >>
> >> > If we have Form meta data in Database then we can enhance the screen
> >> > rendering system to read field visibility attribute from the database.
> >> > So lets say, userLogin.userId belongs to Casher User group. So when
> >> > rendering a ScreenA::FormX, System will look for visibility
> >> > attributes of
> >> > fields on FormX as part of ScreenA for Casher userGroup.
> >> >
> >> > I have seen PeopleSoft does this.
> >> >
> >> > Regards
> >> > Anil Patel
> >> >
> >> > On 1/21/07, David E. Jones <[hidden email]> 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
> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> >
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.5.432 / Virus Database: 268.17.4/643 - Release Date: 1/21/2007 5:12 PM
>
>

--
Guido Amarilla

[jonwimp]

Guido,

 > It is not necessary to completely hide some fields, we could use AJAX

Maybe we could incorporate Prototype (http://www.prototypejs.org/)? Build a convenient engine
around AJAX that the OFBiz framework can easily talk to?

 > I am thinking of some kind of runtime templating for the visibility of
 > fields. It could be implemented in AJAX. For example you have the New Product
 > Creation form with lots of fields, and you could have a dropdown to select
 > the type of product and according to the selected option you can hide some
 > form fields that are not relevant (having the "All Fields" option on top or
 > bottom for advanced users). You could load some default values in some fields
 > and if the user wants, could be changed.

The above is currently done without AJAX. See
facility/control/EditInventoryItem?inventoryItemId=9000&facilityId=WebStoreWarehouse with the demo
data for example. Changing the "InventoryItem Type ID" between Serialized and Non-Serialized will
show you different fields.

IMO, that's fine. We do have to be careful with AJAX. Doing it wrong can cause security problems,
database overload problems, etc.

 > It could be very useful for new users to have a help icon link next to
 > each field or for each form with a full explanation of each field and
 > examples.

THAT is what I've been pushing for too! Anyway, I'm also happy that the OFBiz community is
focusing more time on improving/debugging OFBiz (and neglecting docs aspect).

But your suggestion won't even see light of day, at least not until someone DOES do a proper
comprehensive doc of OFBiz (ERP aspect, not framework). As it is now, I often ask questions about
OFBiz-ERP that even veterans don't know how to answer offhand (what with 600,000++ lines of codes
and 700+ database tables!).

For example, I'd do a quick scan (don't ask how, long story) of OFBiz to find that lotId (for lot
control) has scaffolding in database but is not implemented on front-end forms. I would then ask a
question to community like "can anyone confirm that function is not yet completed, so I can do
it?". I used to ask questions like "Can anyone tell me if that function exists?", to which I get a
response to effect of "Would you like to pay somebody to train you to find that answer, or to do
that function for you?".

No, to be fair, it doesn't always happen that way. I believe it often happens because the
community really hasn't documented OFBiz-ERP enough to give me a quick answer.

Jonathon

Guido Amarilla wrote:

> It is not necessary to completely hide some fields, we could use AJAX
> visibility and some option to change it without a page reload. It
> could be a good idea to fill the form´s default values on BEFORE form
> load, and not only if the user didn´t fill a field after submitting
> the form. Tab navigation and form sectorization is a great idea too
> (much better with AJAX).
>
> I am thinking of some kind of runtime templating for the visibility of
> fields. It could be implemented in AJAX. For example you have the New
> Product Creation form with lots of fields, and you could have a
> dropdown to select the type of product and according to the selected
> option you can hide some form fields that are not relevant (having the
> "All Fields" option on top or bottom for advanced users). You could
> load some default values in some fields and if the user wants, could
> be changed.
>
> I don´t know OFBiz so much yet but I think that something like this
> could help "cleaning" the screens in some places.
>
> It could be very useful for new users to have a help icon link next to
> each field or for each form with a full explanation of each field and
> examples.
>
> Another important feature, is to visually mark wich are the mandatory
> fields in a form. I think that there is a JIRA issue for that.
>
> Guido Amarilla
>
> 2007/1/22, Jonathon -- Improov <[hidden email]>:
>> Why don't we reuse the existing permissions infrastructure (no new
>> Form meta data in database),
>> and simply code the front-end to show/hide fields based on those
>> permissions?
>>
>> Jonathon
>>
>> Anil Patel wrote:
>> > yes we can also say that. true.
>> >
>> >
>> >
>> > On 1/21/07, David E. Jones <[hidden email]> wrote:
>> >>
>> >>
>> >> So, you're thinking of more of a permission system?
>> >>
>> >> -David
>> >>
>> >>
>> >> On Jan 21, 2007, at 9:10 PM, Anil Patel wrote:
>> >>
>> >> > If we have Form meta data in Database then we can enhance the screen
>> >> > rendering system to read field visibility attribute from the
>> database.
>> >> > So lets say, userLogin.userId belongs to Casher User group. So when
>> >> > rendering a ScreenA::FormX, System will look for visibility
>> >> > attributes of
>> >> > fields on FormX as part of ScreenA for Casher userGroup.
>> >> >
>> >> > I have seen PeopleSoft does this.
>> >> >
>> >> > Regards
>> >> > Anil Patel
>> >> >
>> >> > On 1/21/07, David E. Jones <[hidden email]> 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
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> ------------------------------------------------------------------------
>> >
>> > No virus found in this incoming message.
>> > Checked by AVG Free Edition.
>> > Version: 7.5.432 / Virus Database: 268.17.4/643 - Release Date:
>> 1/21/2007 5:12 PM
>>
>>
>
>

[Tim Ruppert]

FYI - there are examples of use of dojo in OFBiz at the moment.  Check out the quick anonymous checkout process whenever you get a chance.  We have built a number of user interface enhancements using this package.  

You can also easily use hidden divs,etc with very simple javascript - to get around the need for dojo or prototype should it not be necessary.

Cheers,

Tim

--

Tim Ruppert

HotWax Media

http://www.hotwaxmedia.com

o:801.649.6594

f:801.649.6595

On Jan 22, 2007, at 12:03 AM, Jonathon -- Improov wrote:

Guido,

> It is not necessary to completely hide some fields, we could use AJAX

Maybe we could incorporate Prototype (http://www.prototypejs.org/)? Build a convenient engine around AJAX that the OFBiz framework can easily talk to?

> I am thinking of some kind of runtime templating for the visibility of

> fields. It could be implemented in AJAX. For example you have the New Product

> Creation form with lots of fields, and you could have a dropdown to select

> the type of product and according to the selected option you can hide some

> form fields that are not relevant (having the "All Fields" option on top or

> bottom for advanced users). You could load some default values in some fields

> and if the user wants, could be changed.

The above is currently done without AJAX. See facility/control/EditInventoryItem?inventoryItemId=9000&facilityId=WebStoreWarehouse with the demo data for example. Changing the "InventoryItem Type ID" between Serialized and Non-Serialized will show you different fields.

IMO, that's fine. We do have to be careful with AJAX. Doing it wrong can cause security problems, database overload problems, etc.

> It could be very useful for new users to have a help icon link next to

> each field or for each form with a full explanation of each field and

> examples.

THAT is what I've been pushing for too! Anyway, I'm also happy that the OFBiz community is focusing more time on improving/debugging OFBiz (and neglecting docs aspect).

But your suggestion won't even see light of day, at least not until someone DOES do a proper comprehensive doc of OFBiz (ERP aspect, not framework). As it is now, I often ask questions about OFBiz-ERP that even veterans don't know how to answer offhand (what with 600,000++ lines of codes and 700+ database tables!).

For example, I'd do a quick scan (don't ask how, long story) of OFBiz to find that lotId (for lot control) has scaffolding in database but is not implemented on front-end forms. I would then ask a question to community like "can anyone confirm that function is not yet completed, so I can do it?". I used to ask questions like "Can anyone tell me if that function exists?", to which I get a response to effect of "Would you like to pay somebody to train you to find that answer, or to do that function for you?".

No, to be fair, it doesn't always happen that way. I believe it often happens because the community really hasn't documented OFBiz-ERP enough to give me a quick answer.

Jonathon

Guido Amarilla wrote:

It is not necessary to completely hide some fields, we could use AJAX

visibility and some option to change it without a page reload. It

could be a good idea to fill the form´s default values on BEFORE form

load, and not only if the user didn´t fill a field after submitting

the form. Tab navigation and form sectorization is a great idea too

(much better with AJAX).

I am thinking of some kind of runtime templating for the visibility of

fields. It could be implemented in AJAX. For example you have the New

Product Creation form with lots of fields, and you could have a

dropdown to select the type of product and according to the selected

option you can hide some form fields that are not relevant (having the

"All Fields" option on top or bottom for advanced users). You could

load some default values in some fields and if the user wants, could

be changed.

I don´t know OFBiz so much yet but I think that something like this

could help "cleaning" the screens in some places.

It could be very useful for new users to have a help icon link next to

each field or for each form with a full explanation of each field and

examples.

Another important feature, is to visually mark wich are the mandatory

fields in a form. I think that there is a JIRA issue for that.

Guido Amarilla

2007/1/22, Jonathon -- Improov <[hidden email]>:

Why don't we reuse the existing permissions infrastructure (no new Form meta data in database),

and simply code the front-end to show/hide fields based on those permissions?

Jonathon

Anil Patel wrote:

> yes we can also say that. true.

>

>

>

> On 1/21/07, David E. Jones <[hidden email]> wrote:

>>

>>

>> So, you're thinking of more of a permission system?

>>

>> -David

>>

>>

>> On Jan 21, 2007, at 9:10 PM, Anil Patel wrote:

>>

>> > If we have Form meta data in Database then we can enhance the screen

>> > rendering system to read field visibility attribute from the database.

>> > So lets say, userLogin.userId belongs to Casher User group. So when

>> > rendering a ScreenA::FormX, System will look for visibility

>> > attributes of

>> > fields on FormX as part of ScreenA for Casher userGroup.

>> >

>> > I have seen PeopleSoft does this.

>> >

>> > Regards

>> > Anil Patel

>> >

>> > On 1/21/07, David E. Jones <[hidden email]> 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

>> >>

>> >>

>> >>

>> >>

>>

>>

>>

>>

>

>

> ------------------------------------------------------------------------

>

> No virus found in this incoming message.

> Checked by AVG Free Edition.

> Version: 7.5.432 / Virus Database: 268.17.4/643 - Release Date: 1/21/2007 5:12 PM

[David E Jones]

On Jan 22, 2007, at 12:03 AM, Jonathon -- Improov wrote:

> > It could be very useful for new users to have a help icon link  
> next to
> > each field or for each form with a full explanation of each field  
> and
> > examples.
>
> THAT is what I've been pushing for too! Anyway, I'm also happy that  
> the OFBiz community is focusing more time on improving/debugging  
> OFBiz (and neglecting docs aspect).
>
> But your suggestion won't even see light of day, at least not until  
> someone DOES do a proper comprehensive doc of OFBiz (ERP aspect,  
> not framework). As it is now, I often ask questions about OFBiz-ERP  
> that even veterans don't know how to answer offhand (what with  
> 600,000++ lines of codes and 700+ database tables!).

There is a lot of work to be done here, and lot left to do, but it  
_has_ already been started and there is a pretty good bit of  
information that mostly needs to be restructured but of course could  
also use some editing and fleshing out. Check out these links:

http://docs.ofbiz.org/x/Bw
http://docs.ofbiz.org/x/Y
http://docs.ofbiz.org/x/5gI

Once there are more fleshed out and structured it will be easy to add  
links to them in the applications.

-David

[Jacques Le Roux]

Ok, it seems that it's not the great idea that everybody was waiting for ;o)

Though we may keep 2 ideas from this thread :

Using tabs to hide unnecessary complexity and break overload of information in some screens. Is it desirable/possible to create a
tabs artifact in form widget ? Else I guess we have to use Ajax, but is that desirable in backend ?

Using tooltips to better explain non obvious fields. By real tooltips I mean using the html title attribute. This is already done
for explaining format of date fields for instance and IMO should be generalized for non obvious fields. It's easily done, don't
clutter the UI but can't be used for option tag (title attribute is accepted but browser do not render it).  Anyway in this case the
widgets take care of the problem by adding a plain text after the select field.

Jacques

----- Original Message -----
From: "David E. Jones" <[hidden email]>
To: <[hidden email]>
Cc: "Tom Anderson" <[hidden email]>; "Ian McNulty" <[hidden email]>
Sent: Monday, January 22, 2007 8:53 AM
Subject: Re: Simple backend UI enhancement proposition

>
> On Jan 22, 2007, at 12:03 AM, Jonathon -- Improov wrote:
>
> > > It could be very useful for new users to have a help icon link
> > next to
> > > each field or for each form with a full explanation of each field
> > and
> > > examples.
> >
> > THAT is what I've been pushing for too! Anyway, I'm also happy that
> > the OFBiz community is focusing more time on improving/debugging
> > OFBiz (and neglecting docs aspect).
> >
> > But your suggestion won't even see light of day, at least not until
> > someone DOES do a proper comprehensive doc of OFBiz (ERP aspect,
> > not framework). As it is now, I often ask questions about OFBiz-ERP
> > that even veterans don't know how to answer offhand (what with
> > 600,000++ lines of codes and 700+ database tables!).
>
> There is a lot of work to be done here, and lot left to do, but it
> _has_ already been started and there is a pretty good bit of
> information that mostly needs to be restructured but of course could
> also use some editing and fleshing out. Check out these links:
>
> http://docs.ofbiz.org/x/Bw
> http://docs.ofbiz.org/x/Y
> http://docs.ofbiz.org/x/5gI
>
> Once there are more fleshed out and structured it will be easy to add
> links to them in the applications.
>
> -David
>
>

[flj]

Hello.

Not in ofbiz, but in some Domino-backed web frontend we use tabs without  
Ajax and without any overload for the server. I don't rea''y know what I'm  
talking about, but I suppose it should be easy to add tabs in ofbiz based  
on a similar mechanism.

Just enclose what needs to be placed on one tab in a <div></div>, then add  
some simple JS and some hotspots which show/hide only one of the divs  
(i.e. tabs) at a time. This way, the rendering and the functionality  
associated to whatever other form elements are there is not affected, and  
you don't need Ajax to re-render/re-fill/re-compute/re-whatever fields on  
tab changes.

Tooltips: maybe use the browser's status bar?

br,

--
Florin Jurcovici
------------------
Why do psychics have to ask you for your name?

On Mon, 22 Jan 2007 13:41:50 +0200, Jacques Le Roux  
<[hidden email]> wrote:

> Ok, it seems that it's not the great idea that everybody was waiting for  
> ;o)
>
> Though we may keep 2 ideas from this thread :
>
> Using tabs to hide unnecessary complexity and break overload of  
> information in some screens. Is it desirable/possible to create a
> tabs artifact in form widget ? Else I guess we have to use Ajax, but is  
> that desirable in backend ?
>
> Using tooltips to better explain non obvious fields. By real tooltips I  
> mean using the html title attribute. This is already done
> for explaining format of date fields for instance and IMO should be  
> generalized for non obvious fields. It's easily done, don't
> clutter the UI but can't be used for option tag (title attribute is  
> accepted but browser do not render it).  Anyway in this case the
> widgets take care of the problem by adding a plain text after the select  
> field.
>
> Jacques
>
> ----- Original Message -----
> From: "David E. Jones" <[hidden email]>
> To: <[hidden email]>
> Cc: "Tom Anderson" <[hidden email]>; "Ian McNulty"  
> <[hidden email]>
> Sent: Monday, January 22, 2007 8:53 AM
> Subject: Re: Simple backend UI enhancement proposition
>
>
>>
>> On Jan 22, 2007, at 12:03 AM, Jonathon -- Improov wrote:
>>
>> > > It could be very useful for new users to have a help icon link
>> > next to
>> > > each field or for each form with a full explanation of each field
>> > and
>> > > examples.
>> >
>> > THAT is what I've been pushing for too! Anyway, I'm also happy that
>> > the OFBiz community is focusing more time on improving/debugging
>> > OFBiz (and neglecting docs aspect).
>> >
>> > But your suggestion won't even see light of day, at least not until
>> > someone DOES do a proper comprehensive doc of OFBiz (ERP aspect,
>> > not framework). As it is now, I often ask questions about OFBiz-ERP
>> > that even veterans don't know how to answer offhand (what with
>> > 600,000++ lines of codes and 700+ database tables!).
>>
>> There is a lot of work to be done here, and lot left to do, but it
>> _has_ already been started and there is a pretty good bit of
>> information that mostly needs to be restructured but of course could
>> also use some editing and fleshing out. Check out these links:
>>
>> http://docs.ofbiz.org/x/Bw
>> http://docs.ofbiz.org/x/Y
>> http://docs.ofbiz.org/x/5gI
>>
>> Once there are more fleshed out and structured it will be easy to add
>> links to them in the applications.
>>
>> -David
>>
>>
>