Thanks for your input Jonathan. That is exactly what I was looking for and the only reason I posted this to the dev mailing list. I just wanted to get the opinion of other developers about how well the ecommerce UI was designed/coded. These guys tried to talk us out of using ofbiz from the beginning, steering us in the direction of other solutions that don't even come close to offering the functionality of ofbiz. Now they are basically telling me that it is so poorly coded that they will need to increase the price to double the original quoted price. I am very happy with ofbiz and all it has to offer and wouldn't even begin to think about using anything else. I think the problem is lack of experience on their part, so the job is taking them much longer than they expected. Thanks again.
On 2/26/07, Jonathon -- Improov <[EMAIL PROTECTED]> wrote:
Eric, Since they're talking about the UI, then they are somewhat correct. Some of the UI use Freemarker, some use form widgets. Also, there's a great deal of refactoring going on at the moment for UI (by Adrian Crumm). One of the problems with CSS styles usage, just to name one UI problem, is that styles don't describe the content but the UI attributes instead. In general, the UI isn't as cleanly coded as it should be. But then again, large variety of coding constructs in the UI are to be expected, and are less crippling than similar mess in the backend modules. Developers generally place less emphasis on UI than backend, since UIs are really much easier to correct in comparison. If they're using Freemarker to customize your UIs, then they shouldn't have any problems at all. If they're using OFBiz-specific form widgets, they should buy the comprehensive docs at http://www.undersunconsulting.com/ecommerce/control/main , unless they can take apart the OFBiz framework themselves (it's open source). I don't know about $2500 pricetag for doing up the UI alone. At double that price, you could have a whole new OFBiz tailored for your organization (without data migration from legacy systems). Look for competent and agile "hack and slash" developers, not the "we gotta follow protocols before things get done" types. > but I think doubling the price right around the time that the project should > be completed is not good business. Oh. Your developers should've fully assessed OFBiz in the early stages. This tells me one of many possible things: your contractor may not be very IT-savvy, and couldn't assess OFBiz himself/herself nor afford a capital outlay to hire a team to do the assessment before he/she took the project from you. > using XHTML and CSS for layout I didn't see this. Well, I must say your developers do have a point. Why do you need it all in strict XHTML? Why not get things working first, then have your in-house team gradually correct the UI to be XHTML-compliant over time? Lastly, we need to understand that OFBiz is open source. We didn't pay anything to use it (unless you bought the docs!), so we really couldn't fault OFBiz for being "oh-so-imperfect". I know, the initial knee-jerk reaction is to ask: "Why'd they represent it as thus?". Call it bad or inaccurate or back-firing marketing if you want, but OFBiz is a solid platform to work with, and it's free. Jonathon Eric Crawford wrote: > Thanks for the comments David. I am mostly trying to determine if > these guys are just blaming their lack of productivity on the current > design assuming that I will take their word for it, or if they are > making accurate statements. I am getting the impression that they are > in over their heads and they want to make excuses, using the current > code as a reason for their case. They quoted us $2500 originally to > design and implement the changes into the ofbiz ecommerce app. This > price seemed lower than I expected originally, but they are now > doubling the price after digging into the code. I am all for paying > someone a fair price for their time and effort, but I think doubling > the price right around the time that the project should be completed > is not good business. > > On 2/26/07, David E. Jones <[EMAIL PROTECTED]> wrote: >> >> On Feb 26, 2007, at 11:00 AM, Eric Crawford wrote: >> >> > We recently hired someone to design our "look and feel" for our ofbiz >> > based ecommerce site. They were hired to design the ecommerce site >> > using XHTML and CSS for layout, complying with web standards and >> > integrate the changes into the OOTB ofbiz ecommerce code. I am hoping >> > that someone can tell me if they feel that these are fair arguments >> > for increasing the originally quoted price, as the original price was >> > quoted with no knowledge of ofbiz or the technologies used on their >> > part. Following are some comments that they made about the >> > design/coding of the out of the box ofbiz ecommerce user interface: >> > >> > * coding is a lot messier than the documents claim >> > * every component has a variable from headline image to tagline >> > comments and some variables code for a line and some code for 30 lines >> > * chaotic coding mess and the time and effort involved trying to clean >> > up OFBiz in an XHTML and Variable standpoint >> > >> > Unfortunately, my experience is in the development of back-end systems >> > and therefore, I am not very familiar with programming for web-based >> > front ends so I feel like I could use the opinions of the community to >> > help me determine whether or not these are fair statements. >> > >> > Any feedback is appreciated, >> > Eric >> >> I'm not totally sure I understand your questions, so I'll restate >> them and then give my answer. >> >> 1. Are the standard OFBiz ecommerce templates complicated because of >> the feature richness of the pachage? Yes. >> >> 2. Is it a good idea to quote a price for work that you don't >> understand well and have never done before? No. >> >> 3. Is coding public facing applications different than internal >> applications, ie do the patterns and requirements differ? Yes. >> >> 4. Do you have to use all of the variables and every OOTB template in >> your final design? No, and generally people do not. >> >> -David >> >> >> > >
