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 <[email protected]> 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" <[email protected]> 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 > > > > >
