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.
That very nicely sums up the fields where we really can achieve to make 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.
+1This 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" <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
smime.p7s
Description: S/MIME Cryptographic Signature
