Re: Simple backend UI enhancement proposition

Posted by Daniel Martínez-4 on
URL: http://ofbiz.116.s1.nabble.com/Simple-backend-UI-enhancement-proposition-tp143920p143942.html

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