Jacques: I'm not privy to the prior conversations that you've had with
Paul -- I'm very interested in any comments that anyone has. We welcome
open discussion and feedback.
A few words about what we are trying to accomplish, background,
philosophy, and more, probably too much ...
We've been using OFBiz for more than 5 years. We are a software
consulting company so our solutions are targeted for our clients. This
is a big difference than those looking to OFBiz for their corporate
solution (this plays a big part in our approach). Our team is 6
developers and 2 BA and 3 QA resources. This team is growing. We're
committed to the OFBiz project, have knowledge, have client
implementations, and we support these implementations. We really
appreciate the elegant entity model and service based approach. We
struggled with the out-of-the-box OFBiz UI and how our clients would
navigate and maintain data using this interface. We all understand the
purpose of the OOTB UI -- show everything that is available, because
no-one knows what is needed for any given client. Very complex for an
extensive ERP solution. My personal role is non-technical, I have a
technical programming background but do not code -- it's actually hugely
beneficial for us since I'm always looking out for our clients, their
experience and their requirements, and I have the luxury of not being in
the technical weeds where it can be tempting to suggest solutions for
technical purity or convenience.
We have a focus on eCommerce so we have a vision as to what should be
exposed, and how it should be exposed. This is the purpose of the
BigFish eCommerce and Admin Modules. We did not want to reinvent the
wheel each and every time ... we needed a real ootb solution where
clients can maintain their own product catalog, static pages, various
content, promotions etc.
We have been very careful not to change any baseline OFBiz code, and we
have minimal entity model changes (a simple generic system parameter
table and a xref reference so we can manage content by product store).
Another key concept is to never fight the baseline functionality, we
embrace it and and hook into the existing entity and service models and
simplify the user experience via our interfaces. Examples:
* Promotions
o the OFBiz UI is confusing and counter-intuitive, and offers
amazing flexibility
o our Promotion interface offers a much simpler way to enter and
manage Promotions, for an eCommerce client
o entering a Promo in the Admin Module can still be modified via
OFBiz OOTB, and vice versa
* Content
o a big part of our offering is the use of "content" throughout
o this allows us (and clients) to have control over just about
every piece of content on their eCommerce solution
o this could be primary links in the header (Sign In, My Account
etc.); standard repeating footer links (About Us, Privacy Policy
etc.); static pages; specific page content outside of the
product catalog and much more
o managing content is very easy for our clients ... pick the
content and modify it
o under the covers we take care of content - resources -
electronic text and tie it to a product store
o again, making the most of the great entity model and services
and re-purposing to give our clients a way to easily manage
their content
* Order workflow
o a BigFish eCommerce order is the same as any OFBiz order
o we have proven this many times -- we have a client for whom we
built an OFBiz based solution for their entire ERP needs
(essentially this was a large implementation that had custom UI
screens that suited their business needs, hooked into the OFBiz
services). Their eCommerce is solved with BigFish -- and orders
created in the BigFish eCommerce solution flow thru and are
fulfilled via their OFBiz ERP solution
o similarly, if OFBIZ OOTB was used to update an Order then
BigFish eCommerce "order history" would reflect this change
We also have many processes in place so that discovery and a majority of
the setup/configuration can take place using our BA's -- this seems to
work really well. One of the hardest parts is gathering requirements
from clients, documenting their requirements and managing expectations
and project scope creep. We really needed to move away from a technology
driven implementation approach -- I sometimes think that OFBiz gets
bogged down in the tech, which can make it an daunting proposition to
adopt the platform (when we first got involved with OFBiz, David Jones
warned us that it will take 6-12 months for us to fully understand the
entity model and service layer, he was right). We are trying to
introduce a different approach and using different resources from our
company to share the load of delivering a system, not just techs.
We are not looking to fork. We're not looking to replace OFBiz. We are
extending the great work that has been done so that an eCommerce focused
solution can be more easily implemented ... and maintained after
go-live. And maintained by non-technical business folks (our clients).
Is it perfect? Of course not. But I'm very proud of our efforts and as
we continue to work with new clients on their solutions, being able to
have a coherent, formal, singular approach is proving to me that it all
works. Would I like others to adopt BigFish? Absolutely. This is good
for us and OFBiz. But our primary goal is to our clients, and giving
them a world class eCommerce solution within 3-4 months is something
that we can now accomplish. (Tip of the hat to OFBiz and the dev
community for making this possible -- please don't ever think that we
are not appreciative for what you have put together -- BigFish is not
possible without OFBiz).
In some previous conversations (maybe a year plus ago) there have been
suggestions of having formal special purpose add-ons to OFBiz. There was
a basic concept of having a core OFBiz with many special purpose
solutions (eComm, advanced Accounting, Manufacturing etc.). We would
certainly welcome discussions in this area.
Quick word to Skip, Adrien, Sakthi and Ted: thanks for your comments.
Nick
On 7/30/2013 2:25 PM, Jacques Le Roux wrote:
Some users have had other experiences, it's why Paul posted this comment (we
exchanged on it).
Not everybody is able to separate the good from the less good. I can't
officially confirm which follows since it did not happen to me. But for
instance, if someone without much OFBiz knowledge picks BigFish for you.
Because it has a better looking, but finally it's not quite suited for the work
at hand. Then it can be a bad experience. This might also depends on versions
you use. I guess newer are better, but again, I can't confirm.
This already happened with previous forks. Note here that I don't know if we
can really call BigFish a fork. Since I never worked with it and it seems to
follow OFBiz, not the trunk though.
Without speaking about Opentaps, Neogia for instance got even itself in trouble
(and some projects which followed its 1st version) and had to change its
strategy.
With Neogia addons, it seems you have now the best of both worlds. Though I
never worked on a project with them, just tested simple cases.
My opinion: better working straight ahead from OFBiz (releases or trunk). And
maybe, as you said Skip, pick here and there good ideas, and even code (addons
seems safer), but no rely on external whole code (repositories or releases).
My 2cts so far
Jacques
----- Original Message -----
From: "Skip"<s...@thedevers.org>
To:<user@ofbiz.apache.org>
Sent: Tuesday, July 30, 2013 7:19 PM
Subject: RE: BigFish Promotions
I am loath to get involved in this, but I for one want to thank Nick and
company for their highly useful contributions which have been freely provided.
Thanks Nick
Skip
-----Original Message-----
From: Paul Piper [mailto:p...@ilscipio.com]
Sent: Tuesday, July 30, 2013 8:18 AM
To: user@ofbiz.apache.org
Subject: BigFish Promotions
Perhaps to not further derail from poor Vitthals post
(http://ofbiz.135035.n4.nabble.com/Formal-Discussion-td4643139.html):
I have no problem with people advertising their own work - in fact, up to a
certain degree it helps the community. However, I think that the constant
promotion of BigFish has crossed the mark quite a bit and has come to the
point where every new member is getting greeted by a bigfish welcoming
message.
I am not trying to bash anybody’s work here, but merely pointing out that
the implementation of Bigfish is far from complete. It isn’t a simple
labeling factor either – it simply isn’t done in full. When a product
doesn’t deliver what it is supposed to do, it is false advertisement.
Again, I have no problems with anybody promoting its own work, but I also
don’t want people thinking that Bigfish = OFBiz, when in fact it is far from
it. A quick search on nabble reveals that there have been 242 references
towards bigfish, the majority being promotional. Sorry, but that isn’t
“rarely responding with BigFish examples” in my eye. So perhaps this can be
limited somehow?
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/BigFish-Promotions-tp4643157.html
Sent from the OFBiz - User mailing list archive at Nabble.com.
