Hi all,
This is really a good thread and I see lots of good discussions. I liked inputs given by Taher to increase the adaptability of OFBiz. Recently I met few end users who are looking for Open Source ERP options, however they are not choosing Apache OFBiz. When I asked Why ? I got few answers which are inline with Taher's proposals. So my inputs on each of the items based on User's feedbacks. Branding: Many users start by searching on google. When they search "Open Source ERP" , they see OFBiz no where in 1st page of Google. I found it at 3rd page. Users see Openbravo, Odoo and other options. So definitely branding is an important thing. We need to improve SEO ranking of OFBiz . Success stories on various social media platforms etc. This will definitely help users to adapt OFBiz. UI redesign: I also agree with this point. I met many people who are using Odoo or ERPNext or Open Bravo. When I asked them why not OFBiz? They say that when thy tried demo version of OFBiz, they did not like the UI. They said its very old UI and they could not understand where to start with. And they concluded that there must be no community work going on and OFBiz project is now dead. These users I am talking about are not subscribed in dev mailing list or even on user mailing list. So they don't know what work is going on. So definitely UI is important thing to consider to increase the adaptability of project. Documentation: No doubt organised documentation always help in adoption of any project. Fully Restful: At the same time I like the idea by Scott that we should also work in making OFBiz fully Restful. Documenting APIs for service will help developers to adopt the project. I agree that it will not directly help end users to adopt the project. However if we document APIs in a good way and make them completely restful and work towards making OFBiz as Platform as a Service, it might also attract developers to make their own web or mobile apps on top of OFBiz. Which might create the buzz and eventually increase adoption in user community. Thanks -- Divesh Dutta. On Sun, Dec 4, 2016 at 12:25 AM, Taher Alkhateeb <slidingfilame...@gmail.com > wrote: > Well said Michael. I fully agree and I make room for others to pitch in :) > > On Sat, Dec 3, 2016 at 9:40 PM, Michael Brohl <michael.br...@ecomify.de> > wrote: > > > Hi Taher, > > > > I have the impression that we are not too far away from each other, we > > only have to share the resources for the different fields of action in a > > reasonable way. > > > > That makes me confident to be on a good way. > > > > It's extremely important to have a good amount of different opinions and > > experiences thrown in the ring to get a picture for the overall strategy > so > > I like to encourage the community members, active or staying in the > > background to speak up and let us hear their point of view to the further > > development of OFBiz. > > > > Every voice is appreciated. > > > > Best regards, > > > > Michael > > > > > > Am 03.12.16 um 06:55 schrieb Taher Alkhateeb: > > > > Hi Scott, > >> > >> Thank you for sharing your thoughts, it's always good to see things > from a > >> new perspective. > >> > >> If you look at my earlier post, you'll notice that we both agree that > the > >> points of strength in OFBiz are the domain model and business logic. It > is > >> also an excellent idea to incorporate RESTful calls into the framework > and > >> to refactor the services. All excellent suggestions. > >> > >> I think where we might differ a bit though is in the assumption that the > >> UI > >> is not that important. It would probably get the top priority position > for > >> me for the following reasons: > >> > >> - There are competing ERP systems out there that are gaining big market > >> shares because of the appeal of a refined user interface. > >> - The user interface gets more "end-users" to the community instead of > >> only > >> developers and consultants which greatly widens the community and > >> eco-system. This is the main driver for big adoption in my opinion and I > >> know people who adopted systems because of this very reason. > >> - Once these non-technical end-users download the system and like it, > they > >> shortly start contacting vendors for customization support. I live in a > >> very small country and yet one ERP system has two representative > companies > >> just because of the appeal of the user interface they have and people > >> really like their software even though it might be inferior in other > ways. > >> - In my experience, the user interface to a large degree drives the > >> design. > >> You said it yourself, some of the services are written in an ugly way to > >> work around the UI mess. The UI really makes it clear how things > _should_ > >> work on every level of the stack. It is also the communication gateway > >> between users and developers. > >> - I think we have a cultural problem in the community that focuses on > >> functionality over beauty. We overlook the massive importance of > beautiful > >> interfaces as an appeal for end-users and people who are thinking about > >> and > >> shortlisting products to use. > >> > >> You stated that you always prefer to drop down to FreeMarker templates > for > >> getting work done. This means our current widget system is not > sufficient > >> for your needs. But wait, does that mean we cannot improve it? Of course > >> we > >> can, that's the whole purpose of this discussion and you can provide > great > >> value with your experience in that area. > >> > >> I agree with you 100% that the current widget system does not work well > >> for > >> things like interactive UIs and single page applications. So let's > rewrite > >> that! Let's get a better DSL, let's use something other than form > widgets. > >> For example, one idea that comes to mind is to make the DSL go all the > way > >> down to detailed components and then compose them. We can enhance it to > be > >> RESTful and interactive, and I would really love to get input from you > on > >> some details. > >> > >> So to summarize, I think although the UI is a weakness point in OFBiz > but > >> we can and should change that. I know it's hard work, but I cannot think > >> of > >> a more powerful adoption impact than a simple beautiful modern interface > >> (mobile-first, RESTful, interactive, etc ...) > >> > >> Cheers, and sorry for the long blinding post :) > >> > >> Taher Alkhateeb > >> > >> On Sat, Dec 3, 2016 at 2:03 AM, Scott Gray < > scott.g...@hotwaxsystems.com> > >> wrote: > >> > >> I don't think it's really our UI that inhibits adoption. With any > >>> reasonably sized project there is going to be a large amount of UI > >>> customization where the front-end will be almost completely written > from > >>> scratch and the back-end at least partially so. This has been my > >>> experience at least over the past 9 years. > >>> > >>> It's also been my experience that form widgets don't play a large role > in > >>> this effort with most development being done using Freemarker. > >>> Increasingly common in the last few years there has been a desire to > use > >>> SPA frameworks such as AngularJS for the admin apps and smaller > front-end > >>> apps. > >>> > >>> It's my opinion that while a custom UI framework is a "nice to have", > it > >>> is > >>> by no means offers much of a selling point when you compare it to > things > >>> like the domain model and the extensive business logic supported in > >>> OFBiz. > >>> Telling non-OFBiz front-end developers that they must now use the > widget > >>> framework to build their AJAX intensive screens isn't much fun to be > >>> honest. > >>> > >>> A good majority of the data gathering logic is tightly coupled to the > >>> OOTB > >>> UI and isn't particularly re-usable. Writing a JSON-RPC or REST based > >>> API > >>> for custom screens is usually quite a bit of work because there isn't > any > >>> inherent support for it in the framework and you tend to just hack > >>> something together on the fly due to time/budget constraints. > >>> > >>> We have thousands of services in OFBiz with very little documentation > and > >>> often overlapping responsibilities. For example, cancelling an order, > >>> should I use "updateOrderHeader"? "changeOrderStatus"? Maybe > >>> "massCancelOrders"? Not to mention a large number of the services are > >>> intended to be ECAs only and not called directly, but there's generally > >>> no > >>> way of knowing that. Virtually every time you go to use a service you > >>> have > >>> to go and look at the implementation and see if it's actually going to > do > >>> what you expect it to and what the side-effects might be. > >>> > >>> And then even with these thousands of services, there's virtually no > >>> services for gathering and returning data. That's all done in the data > >>> prep for screens and isn't particularly re-usable and even if it were, > >>> how > >>> would you know without sifting through the implementation because > there's > >>> no documentation for these scripts. Sometimes it's a mix of a few > widget > >>> actions gathering data in different ways (XML lookups in the actions, > >>> service calls and groovy scripts). > >>> > >>> So while I see our web layer as a nice to have, I strongly believe > that > >>> were OFBiz needs the most enhancement is in the business logic API. > >>> > >>> Modern UI frameworks take a lot of the legwork out building a good UI > >>> these > >>> days, but we don't stand to benefit from any of that while we continue > to > >>> try and build our own solution that will never be any where near as > good. > >>> The strength of OFBiz is in the business logic and I think we do > >>> ourselves > >>> a disservice by considering our web framework to be the primary means > of > >>> accessing it. > >>> > >>> I'm increasingly leaning towards wanting to find a way to deeply > >>> incorporate RESTfulness deeply into our framework. Primarily because > of > >>> the API simplification it would entail. For example, instead of 10s if > >>> not > >>> 100s of services relating to creating/updating an order, you would > simply > >>> have get/put/post that works against a full order resource. We'd then > >>> use > >>> something similar to our ECAs and service engine to validate the > document > >>> and execute related operations against the modified resource. In this > >>> manner you'd reduce our main API down from thousands of services to > less > >>> than one hundred resource models. > >>> > >>> That's just an idea though, the main point here is that I think our UI > >>> matters less than providing a means for implementers to access the > >>> business > >>> logic using any means they deem necessary through a simple > comprehensive > >>> well-documented API. > >>> > >>> Regards > >>> Scott > >>> > >>> On 28/11/2016 23:08, "Sharan Foga" <sha...@apache.org> wrote: > >>> > >>> Hi Everyone > >>>> > >>>> One of the topics that came up during the brainstorming in Seville was > >>>> that the project desperately needs a clear strategy and roadmap. > >>>> > >>>> Benefits: > >>>> - A strategy will provide a clear path for people to follow > >>>> - A strategy will allow us to set goals / milestones and metrics about > >>>> progress > >>>> > >>>> In past maybe we have tried to do too much (tried to do it all at > once - > >>>> which is why we find it h ard to focus). > >>>> > >>>> - One suggestion was to set a maximum of 3 goals and then work only on > >>>> these. To define these goals we need to look at what is the most > >>>> > >>> important > >>> > >>>> thing that we want to achieve - and base them on that. > >>>> - Another suggestion was that the most important thing for the project > >>>> is > >>>> driving adoption. If this is true then what are the key blockers that > >>>> > >>> stop > >>> > >>>> user adoption of OFBiz? (the UI!) > >>>> - Suggestion to organise / setup teams from the community that focus > on > >>>> specific areas (e.g. workgroups) - this could really help progress > >>>> > >>>> So to get the discussion started: > >>>> > >>>> 1. Do people agree that the project needs to focus on driving > adoption? > >>>> 2. Do people think that the UI is one of the key things that stops > this > >>>> ? > >>>> (If, not then please include what do you think is) > >>>> 3. What goals could we set? > >>>> 4. Are people interested in working in workgroups, to focus on > specific > >>>> areas (or goals)? > >>>> > >>>> (I know there are some ideas/work around the UI going on, but I will > >>>> post > >>>> the Seville details and notes about that in separate discussion > thread.) > >>>> > >>>> Thanks > >>>> Sharan > >>>> > >>>> > >>>> > > > > >
