Hi Nick, Inline...
----- Original Message ----- From: "Nick Rosser" <[email protected]> To: <[email protected]> Sent: Wednesday, July 31, 2013 6:30 PM Subject: Re: BigFish Promotions > 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). Yes, it might help to explain this for your potential users Maybe you did already. You can't be accounted for others decisions, just help them to do the best choice. >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. I guess in the case I was reported the confusion came from there. They picked BF because they liked the backend layout more than OFBiz OOTB (not difficult ;o) Then they found it did not fit as much as they thought and were caught by things underneath I must say it was also a version from 2 years ago and stayed with it. So they crossed some bugs, misfits, 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). I was not involved, and never used BF yet. So I can say much about that. I vaguely remember rants about how things were done underneath the UI and issue with js code > 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: Actually it was things used underneath to accomplish which finally turned to be issues for them. > * Promotions > o the OFBiz UI is confusing and counter-intuitive, and offers > amazing flexibility Yes, I must say, coming from a Windows UI world then, I was also surprised by that when I 1st crossed OFBiz (er, almost 9 years ago) And as you say, I initially did not understand how it was flexible. For instance having graphs (open) instead of trees (closed) in product data structures (catalogs, categories, products) and relation with other parts (stores, facility, etc.) As you explained above this has mostly roots in the demo aspect of it. Another reason is it was build w/o any funding but contributions from clients and *efforts from committers*, hence its disparity. > o our Promotion interface offers a much simpler way to enter and > manage Promotions, for an eCommerce client Ha, I must have a look at what you did :). I did not create the initial UI, only adapted it with Ajax 3 years ago. Not only to make it a better UX but also to close cases (all data came and get to the DB) > 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 This sounds like nice improvements. BTW did you never thought about contributing your improvements? Why keeping all apart? Too difficult to merge? This is the kind of questions users should ask themselves. > * 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 Again sounds nice, but then again why not contributing an alternative to ecommerce to OFBiz? Since anyway you have an ASL2 license (good choice ;o) > 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. You might be interested by David's work on that http://www.dejc.com/HEMP.html >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). After all, he conceived it so he knows what he talks about :D Yes, we now know "all" OFBiz is essentially a (very flexible though) framework, applications are only (often useful) sugar. >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). To summarize: I think at some point you will need to draw a line between your potential clients (your target) and all the possible OFBiz clients. I believe for most of them it's already possible to make the choice. But it seems experience shows not all clients have the possibility to discern this from themselves at "1st glance" Better keep everybody on your side... > 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. We are now ready for that. We decided that releases will not contain specialpurpose components (apart ecommerce for now) but trunk will still have them ready for users to check them out. I will for instance soon commit a new solr component... Jacques > 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"<[email protected]> >> To:<[email protected]> >> 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:[email protected]] >>> Sent: Tuesday, July 30, 2013 8:18 AM >>> To: [email protected] >>> 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. >>> >>> >
