Re: RFC: Component Goals and Direction

[David E Jones]

> ------- Original Message -------
> From: Chris Howe <[hidden email]>
> To: [hidden email]
> Sent: 3/17/07, 1:08:02 PM
> Subject: Re: RFC: Component Goals and Direction
>
> My abstract take on the topic...
>
> My take on this topic was for the longest time very similar to Jacopo's
> answer.  However, as I've personally moved further and further down the
> learning curve and witnessed OFBiz mature month to month, my take on
> this has changed slightly.  My take has changed even more so in light
> of the great work Adrian has done to enhance the widgets and the
> relatively recent addition of the <include> element in the site-confs.
> These improvements make customization so much easier that it pushes
> OFBiz applications in my mind as examples as opposed to solutions which
> is much better for the community.
>
> Given the following caveats, which I believe are pretty solid as we've
> seen quite a bit of disappointment from those who have come and gone
> from the community when these are not understood amply.  If these
> caveats aren't correct then obviously my line of abstract thinking
> isn't either.
>
> 1) The application components are to be generic representations of
> common business practices
> 2) There are very few companies that will be able to use OFBiz
> applications OOTB regardless of the amount effort put into the
> applications

The ootb ofbiz applications are meant to be used as-is, and many people are using them this way.

The ones in the applications directory are, however, NOT meant to the most efficient flow or set of fields for a certain company or type of company. They are meant to be generic and usable in any circumstances supported by ofbiz. If you want something more streamlined, then customization for a specific company or type of company is necessary.

> 3) Every company has too many specific needs to rely on a cookie cutter
> approach to handle their business on the whole.

Not necessarily. It would depend on how streamlined they need it to be.

> 4) OFBiz should not be used in a mission critical environment without
> ample needs analysis

This very true, but it is important to remember that this isn't unique to ofbiz. To a certain degree iti is even true of small applications like quickbooks.

 

> The application components should ideally convey the following
> information in order of importance.
> 1) A robust data model that can maintain the majority (if not all) of
> data regarding the particular business concept and their relationships
> to other business concepts.
> 2) An array of services that can maintain a majority of the business
> processes for that business concept.
> 3) Stability
> 4) Security
> 5) Scalability

These last three are important for everything... Not sure why they fit in with the rest of stuff in the list...

> Those 5 are appropriate goals for the core components because they do
> not necessitate thinking of a particular user.  The last three on the
> list are likely the first three on a list for the framework. (that
> covers Stable and Universal on Jacopo's list)
>
> Easy to customize comes from adhering more to the following concepts
> 1) M-V-C model
> 2) Semantic Markup
> 3) Greater use of Widgets
> 4) Separation of templates so that each does one thing, and one thing
> well
>
> OFBiz does well here, but there's always room for improvement.
>
> I consider user-friendliness to be the last thought with regard to the
> base applications, but at the top of the list for the specialized apps.

This is a bit of a dangerous guideline too... These applications should DEFINITELY be user friendly, but keep in miNd that they are generic and so a very important part of user friendliness can NOT be put in them. But yes, we should do everything else we can to make them easy to use.

>   If user-friendliness interferes at all with demonstrating business
> concepts or business processes, it shouldn't be added to the base
> applications regardless of the amount of benefit it may show. The
> reason for this is simply the concept of user-friendly predicates that
> you have a user in mind.  There is certainly benefit in
> user-friendliness but that's best demonstrated in specialized apps.

I think most of this is correct, but perhaps the distinctions above will help clarify how and why.

-David

>
> Thanks for the feedback!
>
> ,Chris
> --- Chris Howe <[hidden email]> wrote:
>
> > Hey All,
> >
> > There has been some light discussion in
> > https://issues.apache.org/jira/browse/OFBIZ-822 on how the
> > application
> > components are maintained, their goals, and their direction. I'd like
> > to get some feedback as to how the larger community feels on these
> > topics.
> >
> >
>
>

[cjhowe]

--- "David E. Jones" <[hidden email]> wrote:

>
> > ------- Original Message -------
> > From: Chris Howe <[hidden email]>
> > To: [hidden email]
> > Sent: 3/17/07, 1:08:02 PM
> > Subject: Re: RFC: Component Goals and Direction
> >
> > My abstract take on the topic...
> >
> > My take on this topic was for the longest time very similar to
> Jacopo's
> > answer.  However, as I've personally moved further and further down
> the
> > learning curve and witnessed OFBiz mature month to month, my take
> on
> > this has changed slightly.  My take has changed even more so in
> light
> > of the great work Adrian has done to enhance the widgets and the
> > relatively recent addition of the <include> element in the
> site-confs.
> > These improvements make customization so much easier that it pushes
> > OFBiz applications in my mind as examples as opposed to solutions
> which
> > is much better for the community.
> >
> > Given the following caveats, which I believe are pretty solid as
> we've
> > seen quite a bit of disappointment from those who have come and
> gone
> > from the community when these are not understood amply.  If these
> > caveats aren't correct then obviously my line of abstract thinking
> > isn't either.
> >
> > 1) The application components are to be generic representations of
> > common business practices
> > 2) There are very few companies that will be able to use OFBiz
> > applications OOTB regardless of the amount effort put into the
> > applications
>
> The ootb ofbiz applications are meant to be used as-is, and many
> people are using them this way.
>
> The ones in the applications directory are, however, NOT meant to the
> most efficient flow or set of fields for a certain company or type of
> company. They are meant to be generic and usable in any circumstances
> supported by ofbiz. If you want something more streamlined, then
> customization for a specific company or type of company is necessary.
>
> > 3) Every company has too many specific needs to rely on a cookie
> cutter
> > approach to handle their business on the whole.
>
> Not necessarily. It would depend on how streamlined they need it to
> be.
>
> > 4) OFBiz should not be used in a mission critical environment
> without
> > ample needs analysis
>
> This very true, but it is important to remember that this isn't
> unique to ofbiz. To a certain degree iti is even true of small
> applications like quickbooks.
>

The caveats were listed for a point of reference.  I'm not sure whether
you're disagreeing with the caveats or simply making caveats to the
caveats :-)  .  I think without those foundational ideas there's a
large risk of having a lot of effort being put into to making the
/applications more user friendly, but not necessarily making OFBiz
friendlier to more users.

>  
> > The application components should ideally convey the following
> > information in order of importance.
> > 1) A robust data model that can maintain the majority (if not all)
> of
> > data regarding the particular business concept and their
> relationships
> > to other business concepts.
> > 2) An array of services that can maintain a majority of the
> business
> > processes for that business concept.
> > 3) Stability
> > 4) Security
> > 5) Scalability
>
> These last three are important for everything... Not sure why they
> fit in with the rest of stuff in the list...
>

My point of emphasis for this list is for the /application components
to be conveying this impression.  These five points are what should be
demonstrated when evaluating
http://localhost:8080/some_webapp_from_applications_directory rather
than conveying the impression of how easy it will be  a user to do
their work.

> > Those 5 are appropriate goals for the core components because they
> do
> > not necessitate thinking of a particular user.  The last three on
> the
> > list are likely the first three on a list for the framework. (that
> > covers Stable and Universal on Jacopo's list)
> >
> > Easy to customize comes from adhering more to the following
> concepts
> > 1) M-V-C model
> > 2) Semantic Markup
> > 3) Greater use of Widgets
> > 4) Separation of templates so that each does one thing, and one
> thing
> > well
> >
> > OFBiz does well here, but there's always room for improvement.
> >
> > I consider user-friendliness to be the last thought with regard to
> the
> > base applications, but at the top of the list for the specialized
> apps.
>
> This is a bit of a dangerous guideline too... These applications
> should DEFINITELY be user friendly, but keep in miNd that they are
> generic and so a very important part of user friendliness can NOT be
> put in them. But yes, we should do everything else we can to make
> them easy to use.
>

If you're creating a generic process,  by definition, you don't have a
user in mind.  I'm not sure how successful one can ever hope to be in
making something "user friendly" without knowing anything about the
particular user.

I think if a modified version of the 5 point guideline above is made
the goal of the /application webapps, we'll naturally fall into more
modular components which will allow people in the community to flex
their creative talents and create more elaborate and user friendly
implementations for the /specialized folder.  As it is now, you see one
type of implementation and therefore stunt your creative muscles into
creating similar solutions that don't stray too far from the model
given.

> >   If user-friendliness interferes at all with demonstrating
> business
> > concepts or business processes, it shouldn't be added to the base
> > applications regardless of the amount of benefit it may show. The
> > reason for this is simply the concept of user-friendly predicates
> that
> > you have a user in mind.  There is certainly benefit in
> > user-friendliness but that's best demonstrated in specialized apps.
>
> I think most of this is correct, but perhaps the distinctions above
> will help clarify how and why.
>
> -David
>
> >
> > Thanks for the feedback!
> >
> > ,Chris
> > --- Chris Howe <[hidden email]> wrote:
> >
> > > Hey All,
> > >
> > > There has been some light discussion in
> > > https://issues.apache.org/jira/browse/OFBIZ-822 on how the
> > > application
> > > components are maintained, their goals, and their direction. I'd
> like
> > > to get some feedback as to how the larger community feels on
> these
> > > topics.
> > >
> > >
> >
> >
>