You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ofbiz.apache.org by Jacques Le Roux <ja...@les7arts.com> on 2007/01/21 12:28:52 UTC
Simple backend UI enhancement proposition
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
Re: Simple backend UI enhancement proposition
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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
>>
>>
>
Re: Simple backend UI enhancement proposition
Posted by Jacques Le Roux <ja...@les7arts.com>.
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
>
>
Re: Simple backend UI enhancement proposition
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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
Re: Simple backend UI enhancement proposition
Posted by Jonathon -- Improov <jo...@improov.com>.
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
>
Re: ofbiz for fleet management?
Posted by Amine AZZI <ba...@gmail.com>.
Hello,
I have a customer seeking an application that tracks his expenses on his
automobile pool (rent, maint., fuel, spare, ...). I have no idea about fleet
management, but it sounds like my requirments. I hope so, it would save me
time.
Amine AZZI
Computer engineer.
Algiers, Algeria
2007/1/23, Florin Jurcovici <fl...@mail.dnttm.ro>:
>
> Hello.
>
> Let's see if the customer bites the bait. If he does, I'll get back at
> you. Main thing is, if this will get done, we don't have to start from
> scratch.
>
> br,
>
> --
> Florin Jurcovici
> ------------------
> Why do psychics have to ask you for your name?
>
> On Tue, 23 Jan 2007 06:52:32 +0200, Anil Patel <to...@gmail.com>
> wrote:
>
> > Florin,
> > We have developed component on top of Ofbiz for managing fleet. At this
> > time
> > we are not traking GPRS data but will sometime in future.
> > At this time we are using
> > 1) PO
> > 2) Parts Inventory management
> > 3) Asset Tracking
> > 4) Maintenance (Other wise called WorkOrders)
> > 5) Labor Time tracking
> > 6) Preventive Maintenance
> > 7) Fuel consumption monitering.
> > 8) Some Reports
> >
> > Tools specific to Fleet management are still not in Ofbiz component,
> > eventually we'll put everything in there. The AssetMaint component in
> > ofbiz
> > is good starting point. I can work with you to in enhancing this
> > component.
> >
> > Regards
> > Anil Patel
> >
> >
> > On 1/22/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
> >>
> >>
> >> Anil Patel is the man to talk to for this. Chances are he'll see
> >> these messages and may comment.
> >>
> >> I know he is doing a fleet management application, and some of it has
> >> even been contributed back to OFBiz. In order to make a more generic
> >> solution he has even written a generic piece for general asset
> >> management that has just gone back into OFBiz (in the new assetmaint
> >> component).
> >>
> >> This focuses on the part that I think you said you are looking for,
> >> namely "inventory, maintenance and accounting". I may have
> >> misunderstood that though. Whatever the case, that is the kind of
> >> stuff OFBiz is best suited for.
> >>
> >> I believe Anil was talking at one point about doing location tracking
> >> and I know there are some structures for that.
> >>
> >> So yeah, maybe this would work out well as a basis for what you need.
> >>
> >> -David
> >>
> >>
> >> On Jan 22, 2007, at 5:50 AM, Florin Jurcovici wrote:
> >>
> >> > Hello.
> >> >
> >> > A potential customer wants to replace everything he has (re.
> >> > software for managing his business). Among other things, he needs a
> >> > fleet management system. His cars all have a third-party fleet
> >> > management system over GPRS in working condition. However, this is
> >> > just to see where the cars travel, when they stop, when and how
> >> > much fuel they tank etc. The inventory, maintenance and accounting
> >> > part is not in this system. Is there anybody using ofbiz for this
> >> > part of a fleet management something already available or something
> >> > built on top of ofbiz? Any advice on something like this?
> >> >
> >> > br,
> >> >
> >> > --
> >> > Florin Jurcovici
> >> > ------------------
> >> > Why do psychics have to ask you for your name?
> >>
> >>
> >>
> >>
>
>
>
>
Re: ofbiz for fleet management?
Posted by Florin Jurcovici <fl...@mail.dnttm.ro>.
Hello.
Let's see if the customer bites the bait. If he does, I'll get back at
you. Main thing is, if this will get done, we don't have to start from
scratch.
br,
--
Florin Jurcovici
------------------
Why do psychics have to ask you for your name?
On Tue, 23 Jan 2007 06:52:32 +0200, Anil Patel <to...@gmail.com>
wrote:
> Florin,
> We have developed component on top of Ofbiz for managing fleet. At this
> time
> we are not traking GPRS data but will sometime in future.
> At this time we are using
> 1) PO
> 2) Parts Inventory management
> 3) Asset Tracking
> 4) Maintenance (Other wise called WorkOrders)
> 5) Labor Time tracking
> 6) Preventive Maintenance
> 7) Fuel consumption monitering.
> 8) Some Reports
>
> Tools specific to Fleet management are still not in Ofbiz component,
> eventually we'll put everything in there. The AssetMaint component in
> ofbiz
> is good starting point. I can work with you to in enhancing this
> component.
>
> Regards
> Anil Patel
>
>
> On 1/22/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
>>
>>
>> Anil Patel is the man to talk to for this. Chances are he'll see
>> these messages and may comment.
>>
>> I know he is doing a fleet management application, and some of it has
>> even been contributed back to OFBiz. In order to make a more generic
>> solution he has even written a generic piece for general asset
>> management that has just gone back into OFBiz (in the new assetmaint
>> component).
>>
>> This focuses on the part that I think you said you are looking for,
>> namely "inventory, maintenance and accounting". I may have
>> misunderstood that though. Whatever the case, that is the kind of
>> stuff OFBiz is best suited for.
>>
>> I believe Anil was talking at one point about doing location tracking
>> and I know there are some structures for that.
>>
>> So yeah, maybe this would work out well as a basis for what you need.
>>
>> -David
>>
>>
>> On Jan 22, 2007, at 5:50 AM, Florin Jurcovici wrote:
>>
>> > Hello.
>> >
>> > A potential customer wants to replace everything he has (re.
>> > software for managing his business). Among other things, he needs a
>> > fleet management system. His cars all have a third-party fleet
>> > management system over GPRS in working condition. However, this is
>> > just to see where the cars travel, when they stop, when and how
>> > much fuel they tank etc. The inventory, maintenance and accounting
>> > part is not in this system. Is there anybody using ofbiz for this
>> > part of a fleet management something already available or something
>> > built on top of ofbiz? Any advice on something like this?
>> >
>> > br,
>> >
>> > --
>> > Florin Jurcovici
>> > ------------------
>> > Why do psychics have to ask you for your name?
>>
>>
>>
>>
Re: ofbiz for fleet management?
Posted by Anil Patel <to...@gmail.com>.
Florin,
We have developed component on top of Ofbiz for managing fleet. At this time
we are not traking GPRS data but will sometime in future.
At this time we are using
1) PO
2) Parts Inventory management
3) Asset Tracking
4) Maintenance (Other wise called WorkOrders)
5) Labor Time tracking
6) Preventive Maintenance
7) Fuel consumption monitering.
8) Some Reports
Tools specific to Fleet management are still not in Ofbiz component,
eventually we'll put everything in there. The AssetMaint component in ofbiz
is good starting point. I can work with you to in enhancing this component.
Regards
Anil Patel
On 1/22/07, David E. Jones <jo...@hotwaxmedia.com> wrote:
>
>
> Anil Patel is the man to talk to for this. Chances are he'll see
> these messages and may comment.
>
> I know he is doing a fleet management application, and some of it has
> even been contributed back to OFBiz. In order to make a more generic
> solution he has even written a generic piece for general asset
> management that has just gone back into OFBiz (in the new assetmaint
> component).
>
> This focuses on the part that I think you said you are looking for,
> namely "inventory, maintenance and accounting". I may have
> misunderstood that though. Whatever the case, that is the kind of
> stuff OFBiz is best suited for.
>
> I believe Anil was talking at one point about doing location tracking
> and I know there are some structures for that.
>
> So yeah, maybe this would work out well as a basis for what you need.
>
> -David
>
>
> On Jan 22, 2007, at 5:50 AM, Florin Jurcovici wrote:
>
> > Hello.
> >
> > A potential customer wants to replace everything he has (re.
> > software for managing his business). Among other things, he needs a
> > fleet management system. His cars all have a third-party fleet
> > management system over GPRS in working condition. However, this is
> > just to see where the cars travel, when they stop, when and how
> > much fuel they tank etc. The inventory, maintenance and accounting
> > part is not in this system. Is there anybody using ofbiz for this
> > part of a fleet management something already available or something
> > built on top of ofbiz? Any advice on something like this?
> >
> > br,
> >
> > --
> > Florin Jurcovici
> > ------------------
> > Why do psychics have to ask you for your name?
>
>
>
>
Re: Simple backend UI enhancement proposition
Posted by Jacques Le Roux <ja...@les7arts.com>.
Thanks for tips Florin
Jacques
----- Original Message -----
From: "Florin Jurcovici" <fl...@mail.dnttm.ro>
To: <us...@ofbiz.apache.org>
Sent: Monday, January 22, 2007 1:20 PM
Subject: Re: Simple backend UI enhancement proposition
> 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
> <ja...@les7arts.com> 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" <jo...@hotwaxmedia.com>
> > To: <us...@ofbiz.apache.org>
> > Cc: "Tom Anderson" <to...@spaceagecontrol.com>; "Ian McNulty"
> > <ia...@mcnultymedia.co.uk>
> > 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
> >>
> >>
> >
>
>
Re: Simple backend UI enhancement proposition
Posted by Florin Jurcovici <fl...@mail.dnttm.ro>.
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
<ja...@les7arts.com> 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" <jo...@hotwaxmedia.com>
> To: <us...@ofbiz.apache.org>
> Cc: "Tom Anderson" <to...@spaceagecontrol.com>; "Ian McNulty"
> <ia...@mcnultymedia.co.uk>
> 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
>>
>>
>
Re: ofbiz for fleet management?
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
Anil Patel is the man to talk to for this. Chances are he'll see
these messages and may comment.
I know he is doing a fleet management application, and some of it has
even been contributed back to OFBiz. In order to make a more generic
solution he has even written a generic piece for general asset
management that has just gone back into OFBiz (in the new assetmaint
component).
This focuses on the part that I think you said you are looking for,
namely "inventory, maintenance and accounting". I may have
misunderstood that though. Whatever the case, that is the kind of
stuff OFBiz is best suited for.
I believe Anil was talking at one point about doing location tracking
and I know there are some structures for that.
So yeah, maybe this would work out well as a basis for what you need.
-David
On Jan 22, 2007, at 5:50 AM, Florin Jurcovici wrote:
> Hello.
>
> A potential customer wants to replace everything he has (re.
> software for managing his business). Among other things, he needs a
> fleet management system. His cars all have a third-party fleet
> management system over GPRS in working condition. However, this is
> just to see where the cars travel, when they stop, when and how
> much fuel they tank etc. The inventory, maintenance and accounting
> part is not in this system. Is there anybody using ofbiz for this
> part of a fleet management something already available or something
> built on top of ofbiz? Any advice on something like this?
>
> br,
>
> --
> Florin Jurcovici
> ------------------
> Why do psychics have to ask you for your name?
ofbiz for fleet management?
Posted by Florin Jurcovici <fl...@mail.dnttm.ro>.
Hello.
A potential customer wants to replace everything he has (re. software for
managing his business). Among other things, he needs a fleet management
system. His cars all have a third-party fleet management system over GPRS
in working condition. However, this is just to see where the cars travel,
when they stop, when and how much fuel they tank etc. The inventory,
maintenance and accounting part is not in this system. Is there anybody
using ofbiz for this part of a fleet management something already
available or something built on top of ofbiz? Any advice on something like
this?
br,
--
Florin Jurcovici
------------------
Why do psychics have to ask you for your name?
Re: Simple backend UI enhancement proposition
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <jo...@hotwaxmedia.com>
To: <us...@ofbiz.apache.org>
Cc: "Tom Anderson" <to...@spaceagecontrol.com>; "Ian McNulty" <ia...@mcnultymedia.co.uk>
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
>
>
Re: Simple backend UI enhancement proposition
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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
Re: Simple backend UI enhancement proposition
Posted by Tim Ruppert <ti...@hotwaxmedia.com>.
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 <jo...@improov.com>:
>>> 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 <jo...@hotwaxmedia.com> 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 <jo...@hotwaxmedia.com> 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
>>>
>>>
>
Re: Simple backend UI enhancement proposition
Posted by Jonathon -- Improov <jo...@improov.com>.
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 <jo...@improov.com>:
>> 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 <jo...@hotwaxmedia.com> 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 <jo...@hotwaxmedia.com> 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
>>
>>
>
>
Re: Simple backend UI enhancement proposition
Posted by Guido Amarilla <ga...@gmail.com>.
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 <jo...@improov.com>:
> 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 <jo...@hotwaxmedia.com> 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 <jo...@hotwaxmedia.com> 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
Re: Simple backend UI enhancement proposition
Posted by Jonathon -- Improov <jo...@improov.com>.
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 <jo...@hotwaxmedia.com> 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 <jo...@hotwaxmedia.com> 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
Re: Simple backend UI enhancement proposition
Posted by Anil Patel <to...@gmail.com>.
yes we can also say that. true.
On 1/21/07, David E. Jones <jo...@hotwaxmedia.com> 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 <jo...@hotwaxmedia.com> 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
> >>
> >>
> >>
> >>
>
>
>
>
Re: Simple backend UI enhancement proposition
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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 <jo...@hotwaxmedia.com> 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
>>
>>
>>
>>
Re: Simple backend UI enhancement proposition
Posted by Anil Patel <to...@gmail.com>.
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 <jo...@hotwaxmedia.com> 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
>
>
>
>
Re: Simple backend UI enhancement proposition
Posted by "David E. Jones" <jo...@hotwaxmedia.com>.
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
Re: Simple backend UI enhancement proposition
Posted by Daniel Martínez <da...@paradisosistemas.es>.
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" <an...@sykesdevelopment.com>
> To: <us...@ofbiz.apache.org>
> 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 <an...@sykesdevelopment.com>
>> Sykes Development Ltd
>> http://www.sykesdevelopment.com
>>
>
>
Re: Simple backend UI enhancement proposition
Posted by Jacques Le Roux <ja...@les7arts.com>.
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" <an...@sykesdevelopment.com>
To: <us...@ofbiz.apache.org>
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 <an...@sykesdevelopment.com>
> Sykes Development Ltd
> http://www.sykesdevelopment.com
Re: Simple backend UI enhancement proposition
Posted by Andrew Sykes <an...@sykesdevelopment.com>.
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 <an...@sykesdevelopment.com>
Sykes Development Ltd
http://www.sykesdevelopment.com
Re: Simple backend UI enhancement proposition
Posted by Anil Patel <to...@gmail.com>.
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 <ja...@les7arts.com> 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
>
>