Re: Simple backend UI enhancement proposition
Posted by David E Jones on Jan 22, 2007; 12:30am
URL: http://ofbiz.116.s1.nabble.com/Simple-backend-UI-enhancement-proposition-tp143920p143945.html
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
>>
>>
>
URL: http://ofbiz.116.s1.nabble.com/Simple-backend-UI-enhancement-proposition-tp143920p143945.html
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
>>
>>
>
smime.p7s (3K) | Free forum by Nabble | Edit this page |