[DISCUSSION] Defining an OFBiz Project Strategy
Locked
12
12
Re: [DISCUSSION] Defining an OFBiz Project Strategy
 
|
Re: [DISCUSSION] Defining an OFBiz Project Strategy
|
|
Re: [DISCUSSION] Defining an OFBiz Project Strategy
|
|
Re: [DISCUSSION] Defining an OFBiz Project Strategy
|
|
Re: [DISCUSSION] Defining an OFBiz Project Strategy
|
Re: [DISCUSSION] Defining an OFBiz Project Strategy
|
|
Re: [DISCUSSION] Defining an OFBiz Project Strategy
|
|
In reply to this post by Scott Gray-3
Hi Scott,
thank you very much for sharing this. I procrastinated my answer to this thread for a while because there is so much to discuss regarding a project strategy for OFBiz. You share my sentiments for most of the points mentioned so let me chime in and add my points of view inline. To put this in context: my background with OFBiz is about 14 years of customer projects, mostly eCommerce-, catalog-, portal and integration projects from 50 up to over 500 person days. They are mostly midsize to larger companies who often have their own ERP system like SAP which needs to be integrated with OFBiz. Am 03.12.16 um 00:03 schrieb Scott Gray: > 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. I completely agree. Having a more modern UI with better usability would be very helpful in the early sales phase though because it is the first impression someone gets from OFBiz when he sees it for the first time(s). In this phase it would also be nice to have the choice between the full blown backend showing all OFBiz has to offer and a slim version (just to show that it's possible). That's what others already mentioned in their plans for UI refactoring. Customer requirements are so diverse that we cannot achieve to build THE UI solution for every functionality or process, even if we spent a huge amount of conceptional work with specialists for the different business domains. So I think we can only deliver example implementations. In my experience, this is something a customer understand very good if it is explained accordingly. > 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. Agree for the form widgets. What's extremely helpful is the screen mechanism and the possibility to have hierarchical and reusable screens, especially in multi site projects. > > It's my opinion that while a custom UI framework is a "nice to have", it is I would rate it a bit more than nice to have but also think that we should invest a reasonable, well balanced amount of efforts in the UI in relation to the following points. > 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. OFBiz more understandable and better connectable (also with different UI solutions). Integration is an important part in larger sized projects as well. It will also help connecting mobile apps which is a requirement getting more and more important. In this course we also have to refactor some huge, messy code like in the order and shopping cart classes. > 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. This is another huge undertaking but I think it definetely should be considered with the overall strategy. I think we should add this to the strategy in https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Apachecon+Brainstorming+Session+:+16th+November+2016 . Thanks again and regards, Michael > > Regards > Scott > > On 28/11/2016 23:08, "Sharan Foga" <[hidden email]> 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 >> >> |
smime.p7s (5K)
Re: [DISCUSSION] Defining an OFBiz Project Strategy
|
|
In reply to this post by taher
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 <[hidden email]> > 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" <[hidden email]> 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 >>> >>> |
Re: [DISCUSSION] Defining an OFBiz Project Strategy
|
|
Re: [DISCUSSION] Defining an OFBiz Project Strategy
|
|
| Free forum by Nabble | Edit this page |