[OFBiz] Users - questions and suggestions

[davidnwelton]

Hi,

I've continued looking into ofbiz and what it might offer the
organization I'm working with.  I have some questions, and a few
comments/suggestions.

1) The whole thing looks very well thought out.  I'm attracted to it
because I like the idea of using (and perhaps collaborating with)
people who have been thinking about the sorts of problems that ofbiz
solves for some time, and appear to know their stuff.  Of most
interest is the order manager, picking/packing... "back office"
portions of the system.  It looks like ofbiz gives you the flexibility
to do all kinds of interesting things.

2) My boss had a look at the home page and the showcased clients, and
wasn't terribly impressed.  A lot of them seem pretty small.  In
another email I read while poking around the site mentioned
applications with "thousands of simultaneous users".  I'd suggest
fewer, more important examples, and then link to a big list of anyone
who's willing to be linked, to give a feel for the quantity of users.

3) Both the home page and the default look and feel are "busy",
especially combined with the many, many options and possibilities that
most of the applications present.  I think this could be in part
rectified by a bit of css work (go easy on the bold fonts), and
breaking the home page up some.  You're hit with an awful lot of text
at first, without a great deal of whitespace or images to break it up.
 This is fine for techies, but consider the PHB who will be involved
in any decision to use this system:-)

4) We have a number of products in the order of magnitude of a
million.  Anyone else doing anything that size?  A lot of the example
sites seem to be e-commerce sites with a limited number of products.

5) Because there are so many options, possibilities, and flexibility,
some of the screens in the various applications look a bit
bewildering.  I wonder if it's possible to "scale down", so that
someone who has to process orders, for instance, gets a nice, easy to
use screen with few, clear options?

Thankyou,
--
David N. Welton
 - http://www.dedasys.com/davidw/

Apache, Linux, Tcl Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Andrew Sykes]

David,

It's always nice to get some feedback like this, Si has been working
hard on making OFBiz more palatable to the movers and shakers, and I'm
sure he'll read your comments with interest.

We have some plans on the look and feel front, but bear in mind OFBiz is
growing rapidly, so it isn't high on the agenda at the moment.

David (E. Jones) and I were recently in contact with a large client who
was asking some of the same questions you are, one of the emails with a
lot of the info you're looking for is attached below. It doesn't answer
your specific question, but will give you a good idea of what to expect.

OFBiz has pretty good granular security control, so it is possible to
limit user access both at the application level and the
application/feature level. So you don't need to overwhelm users with a
sea of irrelevant features. See the ltdadmin user account for a very
simple example of this.

I hope this helps you a little.

Best of luck with it all.
Andrew Sykes
Sykes Development Ltd

********************************************************************
> Performance discussion for DB with around 20,000,000 users

That is a pretty good sized load, but it is certainly possible with  
OFBiz. In general OFBiz is built on well proved technologies  
including J2EE standards and modern database software. There are  
various ways to scale this sort of software and the production  
performance depends a lot on customisation and which features from  
OFBiz are used. In some cases optimisation to the software can make a  
big difference, but we have done quite a bit of profiling and  
optimisation to speed things up in the OFBiz framework.

Most tests of this nature are done by companies during final testing  
and a bit before production deployment. It is possible to make a  
rough estimate for feasibility purposes, but the only way to know is  
to take the final application and run it through real world tests on  
the target hardware.

So, in general yes OFBiz can handle this sort of load when deployed  
and managed properly. That kind of load generally requires a pretty  
good dedicated hardware load balancer and active management of both  
the application servers and the database(s). The good news is that  
the performance on OFBiz within certain parameters scales linearly.  
Where the linear scaling breaks down is when memory on the server  
runs out, which can happen with a lot of users on the system, but  
with proper pairing of servers in a large cluster it is easy to  
overcome.

Of course, 5,000 concurrent users doesn't mean a whole lot without  
knowing what kinds of things those users will be doing. But, as a  
rough and hopefully safe estimate you might consider something like:

5,000 users
~5 dynamic page hits per minute per user (fairly high estimate for  
pretty much any type of application)
= need to support roughly 25,000 page hits per minute, or just over  
400 page hits per second

While application performance can vary a lot a good rough estimate is  
1 page per second per 100Mhz of processor speed (on a typical Intel  
P4 processor, performance is similar but varies on other processors).  
So, for 400 pages per second you would need about 40Ghz of processor  
speed, and since this scales linearly very well that can be done with  
something like 7 dual processor servers, of course doing an 8 machine  
cluster would be more symmetric and easier to setup and manage, or  
4/8/whatever 1xCPU machines could be used. We usually plan for even  
more generous capacity, but with proper load testing you can cut it  
much closer. App server machines usually need a fair bit of memory,  
but can be run with minimal disks.

For the database server it depends a lot on the type of application  
again and how much is cached versus involving significant database  
transactions. Usually for ecommerce we use 25-50% of the processing  
power, and you want to make sure it has some good fast disks and  
plenty of memory.
********************************************************************

On Fri, 2005-11-25 at 11:45 +0100, David Welton wrote:

> Hi,
>
> I've continued looking into ofbiz and what it might offer the
> organization I'm working with.  I have some questions, and a few
> comments/suggestions.
>
> 1) The whole thing looks very well thought out.  I'm attracted to it
> because I like the idea of using (and perhaps collaborating with)
> people who have been thinking about the sorts of problems that ofbiz
> solves for some time, and appear to know their stuff.  Of most
> interest is the order manager, picking/packing... "back office"
> portions of the system.  It looks like ofbiz gives you the flexibility
> to do all kinds of interesting things.
>
> 2) My boss had a look at the home page and the showcased clients, and
> wasn't terribly impressed.  A lot of them seem pretty small.  In
> another email I read while poking around the site mentioned
> applications with "thousands of simultaneous users".  I'd suggest
> fewer, more important examples, and then link to a big list of anyone
> who's willing to be linked, to give a feel for the quantity of users.
>
> 3) Both the home page and the default look and feel are "busy",
> especially combined with the many, many options and possibilities that
> most of the applications present.  I think this could be in part
> rectified by a bit of css work (go easy on the bold fonts), and
> breaking the home page up some.  You're hit with an awful lot of text
> at first, without a great deal of whitespace or images to break it up.
>  This is fine for techies, but consider the PHB who will be involved
> in any decision to use this system:-)
>
> 4) We have a number of products in the order of magnitude of a
> million.  Anyone else doing anything that size?  A lot of the example
> sites seem to be e-commerce sites with a limited number of products.
>
> 5) Because there are so many options, possibilities, and flexibility,
> some of the screens in the various applications look a bit
> bewildering.  I wonder if it's possible to "scale down", so that
> someone who has to process orders, for instance, gets a nice, easy to
> use screen with few, clear options?
>
> Thankyou,
> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Apache, Linux, Tcl Consulting
>  - http://www.dedasys.com/
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

--
Andrew Sykes <[hidden email]>
Sykes Development Ltd

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[davidnwelton]

> It's always nice to get some feedback like this, Si has been working
> hard on making OFBiz more palatable to the movers and shakers, and I'm
> sure he'll read your comments with interest.

> We have some plans on the look and feel front, but bear in mind OFBiz is
> growing rapidly, so it isn't high on the agenda at the moment.

Part of it is probably just a graphical touch up by someone who is
good with that sort of thing.  That's not really a big deal, I think.

Of more concern is managing the complexity presented to users of the
system.  It's a tough problem, and perhaps one that is simply not
possible to deal with in a generic way.  A lot of google's
applications (gmail, for instance) are a good example of the direction
that good applications will go in, I think.  Gmail is easy enough my
mom can use it despite being new to computers, and yet it's not
limiting for me (it's the first web mail system that doesn't drive me
buggy, infact).

> David (E. Jones) and I were recently in contact with a large client who
> was asking some of the same questions you are, one of the emails with a
> lot of the info you're looking for is attached below. It doesn't answer
> your specific question, but will give you a good idea of what to expect.

Thanks!

> OFBiz has pretty good granular security control, so it is possible to
> limit user access both at the application level and the
> application/feature level. So you don't need to overwhelm users with a
> sea of irrelevant features. See the ltdadmin user account for a very
> simple example of this.

Cool.  I think all the pieces are probably there, it's just a matter
of how much time it takes to put them together.  The 'competition' in
my case is the internal system that's been put together a mix of
things that isn't pretty to look at but does work.

> I hope this helps you a little.

It's useful, yes, thanks for your prompt reply!

Our situation is most likely not a huge load of concurrent users
(although it's good to see that this scales linearly), as right now
we're doing tens of thousands of web site hits a day, but a huge
quantity of products for sale in the DB.  Luckily for now we don't
have to worry about stocking a very large portion of those physically.
 We'll probably keep the web front-end we have now as it works pretty
well for our products, and is mostly statically

One other question - ofbiz does have a community, and people using it
for their businesses.  So it's good design built on working code that
does something pretty complex.  Yet it doesn't strike me as being
visible in the open source world... I'd heard of compiere even though
it was a subject that didn't interest me prior to this job, but ofbiz
was something I discovered only when I went hunting for it.  Any
thoughts on that?

Thanks again,
--
David N. Welton
 - http://www.dedasys.com/davidw/

Apache, Linux, Tcl Consulting
 - http://www.dedasys.com/
 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Andrew Sykes]

David,

I haven't really looked at Compiere in any sort of detail to be able to
comment on it.

It is a bit of a pain that the type of clients that want to use OFBiz
don't necessarily want to shout about it. They both don't want the
competition to know too much about what they're doing, and they don't
necessarily want/need to expose their system to the public.

However I've heard stories from various people about pretty large scale
OFBiz deployments and we actually do a couple ourselves.

As for the scalability thing with regards to products, I would expect
this to work in much the same way as outlined for users.

Of course the best way to convince you is just to recommend that you
jump into the code and have a look!

I look forward to hearing how you get along with this.

Kind Regards
--
Andrew Sykes <[hidden email]>
Sykes Development Ltd

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Andrew Sykes]

In addition to my post yesterday.

I'm trying to sync about 10,000 entities at the moment. It seems that if
I try just 200ish everything is fine, but when I try all 10,000 I get
the error posted yesterday about the transaction being marked for
rollback.

Does anyone have any idea why this would be happening?

Thanks
--
Andrew Sykes <[hidden email]>
Sykes Development Ltd

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

Have you eliminated timeout and out of memory problems? Those are the  
2 most common with entity sync. Note that the tool was designed for  
sending data changes from one system to another, not for dumping an  
entire database or any single huge commit in a single shot. The  
problem is it has to pull all data into memory for each chunk, and  
send those chunks to the other system. Right now this is done based  
on time stamps for a reliable progress tracking mechanism so we can  
reliably keep track of what has and hasn't been sent over with a  
simple value. If you have a huge number of records going into a  
single commit this can cause a problem....

How big a number it can handle depends on your network speed, which  
remote service engine you are using (for example the RMI one is  
compressed and binary and MUCH faster than the HTTP one...), and what  
the timeouts and such are set to. You may need to increase a timeout  
somewhere. Memory problems are similar with various things affecting  
how many records you can handle in a single shot.

-David


On Nov 25, 2005, at 11:22 AM, Andrew Sykes wrote:

> In addition to my post yesterday.
>
> I'm trying to sync about 10,000 entities at the moment. It seems  
> that if
> I try just 200ish everything is fine, but when I try all 10,000 I get
> the error posted yesterday about the transaction being marked for
> rollback.
>
> Does anyone have any idea why this would be happening?
>
> Thanks
> --
> Andrew Sykes <[hidden email]>
> Sykes Development Ltd
>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Si Chen-2]

David,

These are some interesting topics you're bringing up.  Here are my thoughts:

1.  I agree that the application's interfaces could be better.  Please
feel free to give us your feedback and suggestions or send in patches
when you have them.

2.  Visibility is an issue as well.  This is something that I have
personally been working on, and hopefully we'll start to see beneficial
results from it over time.

In general, I feel that OFBiz is a more developer- than user-oriented
community in general, and most people work with it in isolation and go
off on their own.  This is actually too bad: the project doesn't get
enough visibility, and as a result, the developers who develop one-off
solutions with it are always stuck selling a "brand X" solution and
answering questions like "Is it stable?"  "Does anybody else use it?"  
"Who will support it?"  This is a classic case where everyone who
contributes could eventually benefit themselves.

So, one of the things that I thought would be nice is a place where
people can publicize the work that they are doing more easily, so they
can give themselves and the project more visibility.  I created a forum
a little while ago for doing this:
http://sourceforge.net/forum/forum.php?forum_id=507346

If you have other thoughts on how the project could increase its
visibility, I'd love to hear it.

Si

David Welton wrote:

>>It's always nice to get some feedback like this, Si has been working
>>hard on making OFBiz more palatable to the movers and shakers, and I'm
>>sure he'll read your comments with interest.
>>    
>>
>
>  
>
>>We have some plans on the look and feel front, but bear in mind OFBiz is
>>growing rapidly, so it isn't high on the agenda at the moment.
>>    
>>
>
>Part of it is probably just a graphical touch up by someone who is
>good with that sort of thing.  That's not really a big deal, I think.
>
>Of more concern is managing the complexity presented to users of the
>system.  It's a tough problem, and perhaps one that is simply not
>possible to deal with in a generic way.  A lot of google's
>applications (gmail, for instance) are a good example of the direction
>that good applications will go in, I think.  Gmail is easy enough my
>mom can use it despite being new to computers, and yet it's not
>limiting for me (it's the first web mail system that doesn't drive me
>buggy, infact).
>
>  
>
>>David (E. Jones) and I were recently in contact with a large client who
>>was asking some of the same questions you are, one of the emails with a
>>lot of the info you're looking for is attached below. It doesn't answer
>>your specific question, but will give you a good idea of what to expect.
>>    
>>
>
>Thanks!
>
>  
>
>>OFBiz has pretty good granular security control, so it is possible to
>>limit user access both at the application level and the
>>application/feature level. So you don't need to overwhelm users with a
>>sea of irrelevant features. See the ltdadmin user account for a very
>>simple example of this.
>>    
>>
>
>Cool.  I think all the pieces are probably there, it's just a matter
>of how much time it takes to put them together.  The 'competition' in
>my case is the internal system that's been put together a mix of
>things that isn't pretty to look at but does work.
>
>  
>
>>I hope this helps you a little.
>>    
>>
>
>It's useful, yes, thanks for your prompt reply!
>
>Our situation is most likely not a huge load of concurrent users
>(although it's good to see that this scales linearly), as right now
>we're doing tens of thousands of web site hits a day, but a huge
>quantity of products for sale in the DB.  Luckily for now we don't
>have to worry about stocking a very large portion of those physically.
> We'll probably keep the web front-end we have now as it works pretty
>well for our products, and is mostly statically
>
>One other question - ofbiz does have a community, and people using it
>for their businesses.  So it's good design built on working code that
>does something pretty complex.  Yet it doesn't strike me as being
>visible in the open source world... I'd heard of compiere even though
>it was a subject that didn't interest me prior to this job, but ofbiz
>was something I discovered only when I went hunting for it.  Any
>thoughts on that?
>
>Thanks again,
>--
>David N. Welton
> - http://www.dedasys.com/davidw/
>
>Apache, Linux, Tcl Consulting
> - http://www.dedasys.com/
>
>_______________________________________________
>Users mailing list
>[hidden email]
>http://lists.ofbiz.org/mailman/listinfo/users
>
>  
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Andrew Sykes]

David,

It looks like a timeout issue, (the system is saying the transaction is
marked for rollback) but I have increased all the timeouts in
EntitySyncContext from 7200 to 7200000 just to see what happened.

It seemed to make no difference at all.

As you can imagine, I've seen memory problems too, but I seem to have
managed to get around these.

I realise that the idea with the EntitySync stuff is to make small
incremental updates, but from time to time, there may be a need to dump
the whole lot across. This needs to be done fairly quietly i.e. I can't
expect the users involved to be manually shifting XML files around.

I've tried reducing the number per split by reducing the split time,
i.e. about 200 per cycle, but it falls over in much the same way
(transaction is marked for rollback).

I'd appreciate any further thoughts you have on this...

Kind Regards
--
Andrew Sykes <[hidden email]>
Sykes Development Ltd

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Adrian Crum]

David,

I am using OFBiz for the company I work for. Like you, I found the user
interface too complicated for most of the employees here, and it wasn't really
task-centric. That is by design by the way - the interface shipped with OFBiz is
(in my opinion) a generic presentation layer that is intended to expose all of
the framework's capabilities.

The approach we took here was to design our own user interface - built upon the
excellent framework that OFBiz supplies. The default UI was used as a guide to
design our own task-centric data entry screens. It took a little over six months
to come up with a strategy that is easily duplicated to generate new pages and
tasks.

Re: Compiere - that OS project had one attribute that turned me away: it is
database-centric. There is a lot of SQL built into the source code. That SQL may
not port to all databases. On the other hand, OFBiz is database AND operating
system agnostic - it will run on just about any database and operating system.
With that it mind - it also scales well. Do you need to support tens of
thousands of simultaneous users? No problem! You can run OFBiz on a mainframe,
or better yet, outsource it to a sophisticated hosting company.

-Adrian


David Welton wrote:

>>It's always nice to get some feedback like this, Si has been working
>>hard on making OFBiz more palatable to the movers and shakers, and I'm
>>sure he'll read your comments with interest.
>
>
>>We have some plans on the look and feel front, but bear in mind OFBiz is
>>growing rapidly, so it isn't high on the agenda at the moment.
>
>
> Part of it is probably just a graphical touch up by someone who is
> good with that sort of thing.  That's not really a big deal, I think.
>
> Of more concern is managing the complexity presented to users of the
> system.  It's a tough problem, and perhaps one that is simply not
> possible to deal with in a generic way.  A lot of google's
> applications (gmail, for instance) are a good example of the direction
> that good applications will go in, I think.  Gmail is easy enough my
> mom can use it despite being new to computers, and yet it's not
> limiting for me (it's the first web mail system that doesn't drive me
> buggy, infact).
>
>
>>David (E. Jones) and I were recently in contact with a large client who
>>was asking some of the same questions you are, one of the emails with a
>>lot of the info you're looking for is attached below. It doesn't answer
>>your specific question, but will give you a good idea of what to expect.
>
>
> Thanks!
>
>
>>OFBiz has pretty good granular security control, so it is possible to
>>limit user access both at the application level and the
>>application/feature level. So you don't need to overwhelm users with a
>>sea of irrelevant features. See the ltdadmin user account for a very
>>simple example of this.
>
>
> Cool.  I think all the pieces are probably there, it's just a matter
> of how much time it takes to put them together.  The 'competition' in
> my case is the internal system that's been put together a mix of
> things that isn't pretty to look at but does work.
>
>
>>I hope this helps you a little.
>
>
> It's useful, yes, thanks for your prompt reply!
>
> Our situation is most likely not a huge load of concurrent users
> (although it's good to see that this scales linearly), as right now
> we're doing tens of thousands of web site hits a day, but a huge
> quantity of products for sale in the DB.  Luckily for now we don't
> have to worry about stocking a very large portion of those physically.
>  We'll probably keep the web front-end we have now as it works pretty
> well for our products, and is mostly statically
>
> One other question - ofbiz does have a community, and people using it
> for their businesses.  So it's good design built on working code that
> does something pretty complex.  Yet it doesn't strike me as being
> visible in the open source world... I'd heard of compiere even though
> it was a subject that didn't interest me prior to this job, but ofbiz
> was something I discovered only when I went hunting for it.  Any
> thoughts on that?
>
> Thanks again,
> --
> David N. Welton
>  - http://www.dedasys.com/davidw/
>
> Apache, Linux, Tcl Consulting
>  - http://www.dedasys.com/
>  
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[Ian Gilbert]

This is our experience also.  We have adopted an incremental approach to
using this system based around requirements from the business as they
arise.  We have made some modifications to the management screens and have
a longstanding intention to modify the customer UI which is ongoing.  We
also originally looked carefully at Compiere but came to the same
conclusion as Adrian.

We found the object relational mapping that the entity engine gives us to
be a very useful and easy way of navigating the database which we found
more intuitive than working with the underlying RDBMS (Postgres in our
case) although we have had to do some custom reports which have required
db skills (fortunately something we have in abundance) but the headstart
that we got on development has been a major boon for us.

HTH

Very best wishes

Ian

On Sat, November 26, 2005 4:55 pm, Adrian Crum wrote:

> David,
>
>
> I am using OFBiz for the company I work for. Like you, I found the user
> interface too complicated for most of the employees here, and it wasn't
> really task-centric. That is by design by the way - the interface shipped
> with OFBiz is (in my opinion) a generic presentation layer that is
> intended to expose all of the framework's capabilities.
>
> The approach we took here was to design our own user interface - built
> upon the excellent framework that OFBiz supplies. The default UI was used
> as a guide to design our own task-centric data entry screens. It took a
> little over six months to come up with a strategy that is easily
> duplicated to generate new pages and tasks.
>
> Re: Compiere - that OS project had one attribute that turned me away: it
> is database-centric. There is a lot of SQL built into the source code.
> That SQL may
> not port to all databases. On the other hand, OFBiz is database AND
> operating system agnostic - it will run on just about any database and
> operating system. With that it mind - it also scales well. Do you need to
> support tens of thousands of simultaneous users? No problem! You can run
> OFBiz on a mainframe,
> or better yet, outsource it to a sophisticated hosting company.
>
> -Adrian
>
>
>
> David Welton wrote:
>
>>> It's always nice to get some feedback like this, Si has been working
>>> hard on making OFBiz more palatable to the movers and shakers, and I'm
>>>  sure he'll read your comments with interest.
>>
>>
>>> We have some plans on the look and feel front, but bear in mind OFBiz
>>> is growing rapidly, so it isn't high on the agenda at the moment.
>>
>>
>> Part of it is probably just a graphical touch up by someone who is
>> good with that sort of thing.  That's not really a big deal, I think.
>>
>> Of more concern is managing the complexity presented to users of the
>> system.  It's a tough problem, and perhaps one that is simply not
>> possible to deal with in a generic way.  A lot of google's applications
>> (gmail, for instance) are a good example of the direction
>> that good applications will go in, I think.  Gmail is easy enough my mom
>> can use it despite being new to computers, and yet it's not limiting for
>> me (it's the first web mail system that doesn't drive me buggy, infact).
>>
>>
>>
>>> David (E. Jones) and I were recently in contact with a large client
>>> who was asking some of the same questions you are, one of the emails
>>> with a lot of the info you're looking for is attached below. It
>>> doesn't answer your specific question, but will give you a good idea
>>> of what to expect.
>>
>>
>> Thanks!
>>
>>
>>
>>> OFBiz has pretty good granular security control, so it is possible to
>>>  limit user access both at the application level and the
>>> application/feature level. So you don't need to overwhelm users with
>>> a sea of irrelevant features. See the ltdadmin user account for a very
>>>  simple example of this.
>>
>>
>> Cool.  I think all the pieces are probably there, it's just a matter
>> of how much time it takes to put them together.  The 'competition' in my
>> case is the internal system that's been put together a mix of things
>> that isn't pretty to look at but does work.
>>
>>
>>> I hope this helps you a little.
>>>
>>
>>
>> It's useful, yes, thanks for your prompt reply!
>>
>>
>> Our situation is most likely not a huge load of concurrent users
>> (although it's good to see that this scales linearly), as right now
>> we're doing tens of thousands of web site hits a day, but a huge quantity
>> of products for sale in the DB.  Luckily for now we don't have to worry
>> about stocking a very large portion of those physically. We'll probably
>> keep the web front-end we have now as it works pretty well for our
>> products, and is mostly statically
>>
>> One other question - ofbiz does have a community, and people using it
>> for their businesses.  So it's good design built on working code that
>> does something pretty complex.  Yet it doesn't strike me as being
>> visible in the open source world... I'd heard of compiere even though it
>> was a subject that didn't interest me prior to this job, but ofbiz was
>> something I discovered only when I went hunting for it.  Any thoughts on
>> that?
>>
>> Thanks again,
>> --
>> David N. Welton
>> - http://www.dedasys.com/davidw/
>>
>>
>> Apache, Linux, Tcl Consulting
>> - http://www.dedasys.com/
>>
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users
>
>

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users

[David E. Jones]

Thanks for the comments Adrian, this is exactly where we are going  
with OFBiz right now. As I mentioned in a related email yesterday as  
the project grows and has a more complete horizontal basis it would  
be nice to add more of these task specific UIs, especially as we get  
more feedback about the specific things that people are developing.

-David


On Nov 26, 2005, at 9:55 AM, Adrian Crum wrote:

> David,
>
> I am using OFBiz for the company I work for. Like you, I found the  
> user interface too complicated for most of the employees here, and  
> it wasn't really task-centric. That is by design by the way - the  
> interface shipped with OFBiz is (in my opinion) a generic  
> presentation layer that is intended to expose all of the  
> framework's capabilities.
>
> The approach we took here was to design our own user interface -  
> built upon the excellent framework that OFBiz supplies. The default  
> UI was used as a guide to design our own task-centric data entry  
> screens. It took a little over six months to come up with a  
> strategy that is easily duplicated to generate new pages and tasks.
>
> Re: Compiere - that OS project had one attribute that turned me  
> away: it is database-centric. There is a lot of SQL built into the  
> source code. That SQL may not port to all databases. On the other  
> hand, OFBiz is database AND operating system agnostic - it will run  
> on just about any database and operating system. With that it mind  
> - it also scales well. Do you need to support tens of thousands of  
> simultaneous users? No problem! You can run OFBiz on a mainframe,  
> or better yet, outsource it to a sophisticated hosting company.
>
> -Adrian
>
>
> David Welton wrote:
>>> It's always nice to get some feedback like this, Si has been working
>>> hard on making OFBiz more palatable to the movers and shakers,  
>>> and I'm
>>> sure he'll read your comments with interest.
>>> We have some plans on the look and feel front, but bear in mind  
>>> OFBiz is
>>> growing rapidly, so it isn't high on the agenda at the moment.
>> Part of it is probably just a graphical touch up by someone who is
>> good with that sort of thing.  That's not really a big deal, I think.
>> Of more concern is managing the complexity presented to users of the
>> system.  It's a tough problem, and perhaps one that is simply not
>> possible to deal with in a generic way.  A lot of google's
>> applications (gmail, for instance) are a good example of the  
>> direction
>> that good applications will go in, I think.  Gmail is easy enough my
>> mom can use it despite being new to computers, and yet it's not
>> limiting for me (it's the first web mail system that doesn't drive me
>> buggy, infact).
>>> David (E. Jones) and I were recently in contact with a large  
>>> client who
>>> was asking some of the same questions you are, one of the emails  
>>> with a
>>> lot of the info you're looking for is attached below. It doesn't  
>>> answer
>>> your specific question, but will give you a good idea of what to  
>>> expect.
>> Thanks!
>>> OFBiz has pretty good granular security control, so it is  
>>> possible to
>>> limit user access both at the application level and the
>>> application/feature level. So you don't need to overwhelm users  
>>> with a
>>> sea of irrelevant features. See the ltdadmin user account for a very
>>> simple example of this.
>> Cool.  I think all the pieces are probably there, it's just a matter
>> of how much time it takes to put them together.  The 'competition' in
>> my case is the internal system that's been put together a mix of
>> things that isn't pretty to look at but does work.
>>> I hope this helps you a little.
>> It's useful, yes, thanks for your prompt reply!
>> Our situation is most likely not a huge load of concurrent users
>> (although it's good to see that this scales linearly), as right now
>> we're doing tens of thousands of web site hits a day, but a huge
>> quantity of products for sale in the DB.  Luckily for now we don't
>> have to worry about stocking a very large portion of those  
>> physically.
>>  We'll probably keep the web front-end we have now as it works pretty
>> well for our products, and is mostly statically
>> One other question - ofbiz does have a community, and people using it
>> for their businesses.  So it's good design built on working code that
>> does something pretty complex.  Yet it doesn't strike me as being
>> visible in the open source world... I'd heard of compiere even though
>> it was a subject that didn't interest me prior to this job, but ofbiz
>> was something I discovered only when I went hunting for it.  Any
>> thoughts on that?
>> Thanks again,
>> --
>> David N. Welton
>>  - http://www.dedasys.com/davidw/
>> Apache, Linux, Tcl Consulting
>>  - http://www.dedasys.com/
>>  _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.ofbiz.org/mailman/listinfo/users
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.ofbiz.org/mailman/listinfo/users

 
_______________________________________________
Users mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/users