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 >>>> >>>> >>>> > >
