Hi Ean, I am absolutely 100% in agreement that the user experience is a big barrier to entry for OFBiz. I am comfortable with Javascript being part of the primary user interface, provided there is architectural provision for alternatives.
I do not think that a limited "beginner" mode is the answer. See the thread at http://ofbiz.135035.n4.nabble.com/hiding-functionality-in-ofbiz-td3473417.html for some discussion on this. Cheers Paul Foxworthy Ean Schuessler wrote > I would like to see a deep refactoring of the UI. Ideally, it should be > separated into two distinct components, a view renderer and a series of > authenticated services that support it. It is about time for us to step > into the modern world where the UI is an application, written in > Javascript, that communicates with the application using JSON or XML RPC > calls. If rendering for javascriptless clients is really still a priority > then we might want to look at using rhino or nashorn in the server to do > the same rendering there but, fundamentally, move to a javascript based > view rendering solution. The interactivity and fluidity of a properly AJAX > based interface is part of what makes us look so dated compared to > solutions like OpenERP. > > > We also need to completely reconsider the UI experience. The interface is > overwhelming to new users. If we could have a role based method for hiding > controls then we could have a "beginner" user mode that greatly simplified > core screens. A basic drop-ship ecommerce user doesn't need to see billing > accounts, facilities and a lot of the other complexity on the product > screens. Our order entry process is also rather clunky, even in comparison > to older systems like SQL-Ledger. > > > ----- "Jacopo Cappellato" wrote: >> Hi all, >> this is just intended to brainstorm some ideas for the future OFBiz >> (let's say for the 14.04 branch) and to get the community feedback... I >> don't have concrete plans at the moment for most of them >> Some of the ideas below are intended to renew some core parts of the >> OFBiz Framework, replacing custom code (some of getting old) with Open >> Source alternatives; some of them are just cleanups. >> * Replace the OFBiz TX Manager and the Database Connection Pool (Geronimo >> TX and DBCP, well... they actually can stay as optional components) with: >> http://www.atomikos.com/Main/TransactionsEssentials >> (see initial work on https://issues.apache.org/jira/browse/OFBIZ-5129 ) >> * Refactor the OFBiz Security (authentication/authorization/cryptography) >> with (a session I attended during ApacheCon@Portland inspired me for >> this): >> http://shiro.apache.org >> * Replace Javolution (this has been already discussed in the past) >> * Replace the OFBiz cache system with: >> http://ehcache.org >> * Replace the OFBiz job scheduler with: >> http://quartz-scheduler.org >> * Reorganize the screen data preparation Groovy scripts into bigger files >> with methods (they are now individual files); for example, instead of >> having: >> applications/product/webapp/catalog/WEB-INF/actions/product/EditProductAssoc.groovy >> >> applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContent.groovy >> >> applications/product/webapp/catalog/WEB-INF/actions/product/EditProductContentContent.groovy >> >> applications/product/webapp/catalog/WEB-INF/actions/product/EditProductFeatures.groovy >> >> ... >> we could have one file: >> applications/product/webapp/catalog/WEB-INF/actions/EditProduct.groovy >> with methods: >> editProductAssoc, editProductContent, editProductContentContent, >> editProductFeatures... >> (note: this switch is possible since the enhancements we did one year >> ago); this could make our code more readable and organized without >> loosing the ability to override individual scripts from hot-deploy >> components; in the process, we could also review the scripts and clean >> them or improve (some of them are pretty old) >> * (in the process) we could also refactor the code of the Groovy scripts >> to use the (now experimental and to be tested/expanded) DSL methods we >> implemented one year ago >> Kind regards, >> Jacopo > > -- > Ean Schuessler, CTO > ean@ > > 214-720-0700 x 315 > Brainfood, Inc. > http://www.brainfood.com ----- -- Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- View this message in context: http://ofbiz.135035.n4.nabble.com/Some-ideas-for-the-future-of-the-OFBiz-tp4639965p4640057.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
