On that note: when we discussed UI in 2004, the widgets were implemented. how I took care of it, was to use a commercial Swt application that created a xml. then I wrote a xlst that converted it to widgets.
Jonathon -- Improov sent the following on 9/16/2007 5:25 AM: > I have the same experience/difficulty trying to sell OFBiz. I've had to > either re-package OFBiz quite a bit, or I sell our expertise related to > OFBiz (we show them how fast we get a job done). > > Jonathon > > Cameron Smith wrote: >> Skip, your criterion f is certainly a valid criterion for choosing a >> technology to incorporate into the OFBiz core. It is not a valid >> criteria for a commercial company like mine, in a competitive market, >> which lives only if it satisfies its customers, in a cost-effective >> way. That is why it did not feature in my analysis. >> Note that I am not making a moral judgement here, simply a practical one. >> >> Another related point which may be of interest, is that all successful >> ERP systems (in terms of installed client base) have a significant >> cost component related to customer-specific configurations, >> parametrizations and new development. The market leader, SAP, has a >> business model based on this. And as far as I can glean, many OFBiz >> stalwarts like David and Jacques, also make a living at least >> partially from this. This is not bad, it is inherent in the >> complexity of the organizational and financial interactions which an >> ERP automates and helps to manage. If you try and ignore these by >> "just using whatever is free OOTB", you risk putting in place a system >> which is either unusable or (worse), leads to wrong decisions by the >> client firm. For instance stocking levels, missing invoices, >> duplicated accounting entries. If you have ever had to deal with >> issues like this in any capacity, you will know what a nightmare they >> are. >> >> In this context, I agree with your argument about the importance of >> usability, but I would put it second. In first place I would put the >> consistency of the Data Model and the processes which operate on it. >> OFBiz is enormously flexible in this regard - but that flexibility can >> be dangerous if you do not apply it correctly (particularly in the >> attribution of business semantics to Type and Status table values). >> This is one of the reasons why "OFBiz plus" systems, focussed on >> certain more specific target markets, like Neogia and Opentaps (and >> many others, including my company's) exist. I actually do not bemoan >> their existence, I think they are a sign of the fundamental quality of >> the core OFBiz code frameworks and data model. >> >> Finally, I would like to point out that my point of view is obviously >> interested by the nature of my client market: SMEs in a developing >> country. Bear in mind that the average Medium-sized enterprise in >> Mozambique, has a gross turnover smaller than the average "Small" >> enterprise in the USA. Although in terms of personnel it may have >> more! The in-house IT capacity is not even in the same ballpark as >> that of even a small US or UK manufacturing firm, for instance. >> However the desire to automate and rationalize business processes is >> equally strong. >> >> Our experience when we tried initially to sell "pure" OFBiz (that is, >> no code changes, only market specific parametrizations) to >> Medium-scale clients here, is that they rejected it as too >> overwhelmingly complex. We therefore developed our own custom >> frontend and business rules, built on top of OFBiz and specialized for >> the market and legal context here, and this has worked. ZK was, in >> our analysis, the cheapest way to actually turn the market-specific >> frontend design into running code. >> I do feel that in what you say, there is an implicit, or perhaps >> subconscious, moral judgement that anything which is not completely >> free for anyone to use in commercial work, is bad. You are welcome to >> make that judgement, but you should consider the whole context. >> >> And certainly, we have built up a lot of expertise and improvements >> which could be contributed back to OFBiz, especially in the area of >> multi-company accounting. At the moment we have not prioritized this >> giving back, partly because the initial feedback we received from the >> community was fairly disinterested, and partly because we lack the >> technical resources to spare on regression testing everything we put >> back, against OOTB OFBiz. >> >> However, I certainly think that every time an OFBiz-based system like >> ours (or like Neogia, Opentaps, or your own company's system) is >> installed in a client firm - instead of Navision or whatever - and >> actually helps their business run better - then this can only be good >> for OFBiz. >> >> Anyway, just my 2 pence (well, actually more like 10 pence ;-) >> cameron >> >> ----- Original Message ---- >> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> >> To: [email protected]; Cameron Smith <[EMAIL PROTECTED]> >> Sent: Sunday, 16 September, 2007 1:16:43 AM >> Subject: RE: Rich client: licensing and other features >> >> Cameron >> >> "In term of the best value-for-money option, my (and my company's) >> money is >> on ZK. We bought commercial licenses, because our programmers receive >> salaries, and every hour they spend reinventing the wheel instead of >> using >> someone else's wheel, however fun it may be, is an additional cost." >> >> >> Well said and very true. However, there is no chance of integrating >> ZK with >> Ofbiz because of the licensing. There is a chance of doing it with >> OpenLazlo. Ofbiz is an open source project and all benefit from the >> collective work of the contributors. In addition, there are several >> forks >> which add to this work (Opentaps and Noegia (spelling?). On these >> collective versions are built many real live implementations. >> >> If we look at the usefulness, additions to Ofbiz benefit everyone. >> Additions to Opentaps and Noegia benefit their users but not all Ofbiz >> users. Changes to individual implementations benenit the implementations >> alone. >> >> ZK can only ever fit in the last catagory. >> >> It is my view that usability by the end user should be the most important >> consideration in an project. For this reason, a rich UI is highly >> desirable >> (maybe even manditory in some cases). It certainly is manditory in >> the ones >> I currently serve. I have therefore been evaluating the alternatives and >> have carefully read the two missives you wrote in the Ofbiz wiki and >> TheServerSide.com. In the later case, you rated the various >> technologies . >> In your abcde list of criteria, I think you missed one, and that being >> >> f. The number of users likely to benefit from it's adoption. >> >> If that list was re-evaluated today including my f, Openlazlo would >> win with >> a 5 vs. 4.5. >> >> Having said that, I personally like ZK better (with only a cursory >> look at >> both). But, for the communities sake, I may choose Openlazlo instead (or >> might use the existing Dojo). >> >> Skip >> >> >> >> >> >> >> ___________________________________________________________ Want >> ideas for reducing your carbon footprint? Visit Yahoo! For Good >> http://uk.promotions.yahoo.com/forgood/environment.html >> >> > > > >
