Hey Skip,
Nice discussion. :)
> 1. Backoffice personell are expensive.
I was thinking more in terms of IT department savings. The "create/maintain/deploy" human
activities can be quite a bit more expensive (IT consultants) than backoffice personnel, I would
think. Is that the case where you are?
Still, saving manpower is always good. AJAX (and Web 2.0) technology came in to correct the
pendulum swing, the swing from saving backoffice manpower (or end-users) to saving IT manpower.
Yes, usability and end-user experience did suffer when the IT folks tried to save on the
"create/maintain/deploy" side of things.
> It takes 20 seconds less on simple orders (Finalize with defaults) and 45
> seconds less with complicated ones using the Java app.
I had similar savings with AJAX. It's not so bad, really. After all, AJAX is done with javascript,
and javascript is done with...? C/C++ or something similarly tight. The parser and runtime is in
the browser itself! Now, where does Java stand in comparison? :)
I would imagine that your Java GUI app does trim and quick server calls (for quick
synchronization) to the server. That's what AJAX does too.
> I know I can achieve the same effect with ajax, but if I have to write these
> apps from scratch anyway, why not take advantage of the extra horsepower and
> compiled Java?
Because AJAX is still part of "server codes" (served up by server), so you can manage them
centrally. Java client codes (GUI mostly?) is separated from server codes (separately installed on
client). AJAX is coded as part of HTML pages served up by "server codes".
While a full Java app is fast enough for trigger-happy trigger-efficient backoffice personnel, it
might be too expensive a swing in the pendulum. Yes, end-users did suffer when we swung from
user-friendliness to IT savings. But should we now swing so vehemently back to user-friendliness
(with Java client app), and move so far away from IT savings?
> With Ofbiz code doing the grunt work, I can spend my time making the GUI
> fast, easy, and smart.
Actually, that business model does work. GUI is everything to customers or end-users. Some
customers will pay a lot just to have GUIs they like. However, most customers I know are
cost-conscious, and won't want to pay for a Porsche paint job if they can get a cheaper and still
effective GUI that works.
If your customer is willing to pay lots for future maintenance of Java GUI app, browser GUI
modules (OFBiz widgets and such), and OFBiz backend modules, then sure, have fun doing all that
maintenance.
Eg scenario: "Did you change the UI like I wanted?"... "Yes, I did"... "I see it only in the
browser GUI modules"... "I'll do it in the Java GUI module too, sorry I forgot"... "Make sure you
do the change exactly, I want the change to be precisely uniform and consistent".
> 2. "Also, the move forward is to "dumb down" the client terminals (cheap to
> deploy, scalable)."... Witness the move to Ajax backed Javascript as an
> example.
"Dumbing down" client terminals means we don't have to "teach" (install) those terminals too much.
The point is to be able to acquire any computer (new or old), and still be able to run the app and
hit the server, without having to "teach" or install much to those terminals.
AJAX is part of the browser. Browser adoption rates are driven by browser competition, not by our
own Java GUI development team. With browser adoption moving along healthily, we can do away with
our Java GUI development team (reassign).
> It takes almost no time to code a GUI with Netbeans.
In software development, the biggest headaches isn't about getting something coded. It's about
collaboration between IT teams, collaboration between software components (in your case, server
and client components). And the need for such collaboration is so strong, version control
mechanisms were born, and honed by now.
Take this DocBook example (since there was a recent mention of DocBooks somewhere). DocBook is
plain text format, and can be automatically converted into OpenDocument format (MS Word equivalent
in OpenOffice). OpenDocument format is binary. Suppose I write a huge book using OpenDocument
format, and I make some changes. I would have to send a new complete binary of the whole book to
my publisher. But with DocBook's plain text format, plus version control, I only need to send a
small diff to update (collaborate with) my publisher.
More than 10 years back, I remember a time when we used MS Word documents for functional specs.
Lots of protocols then for change management, under project management. For every change in the
specs documents, a "changelog" section needs to be carefully and painstakingly updated. In
reality, there were many "carefully and painstakingly" crafted errors in those "changelog"
sections. We're just humans. There was simply no way to do a "diff" for MS Word docs.
> No such tools currently exist (that I know of) for Ajax backed apps.
It may take some time for AJAX frameworks to compete and crystallize some standards. Or has that
already happened? Still, it isn't difficult to do AJAX. It's almost standard by now.
> 4. "In production, servers aren't hit all the time. There are peak periods,
> and there are lull periods." If the brains are on the user's desktop, there
> are no lull or peaks at any time (and no associated aggravation). Their
> work is never interrupted or slowed (assuming the database server is not
> overloaded.)
Even if you put the Java GUI app on the client terminals, you'll still need to handle peak periods
on the server codes. If you're already doing clustering and load-balancing on the server side, you
might as well do it there only, and gain the benefit of "easier control" (only a few servers,
platforms and setups you can control).
If you're thinking of executing business logic codes on the client terminals, you face the
additional risk of such codes running differently on different terminals. We never know. Sun SDK
could run a tad different on some setups. There'd be so many different setups or platforms to
cater for, the cost of maintenance could increase exponentially.
To fix that problem, you could mandate a uniform setup for all client terminals. So, if the top
boss wants a newfangled 128-bit computer, and still wants to run your Java GUI app, would you be
able to tell him "Sir, you gotta get with the program because Sun SDK won't run with 128-bit"? :)
Using only browsers as the client app, the responsibility to "cater for various platforms" falls
on the browser developers instead.
> 5. "Those folks writing the "offloading algorithms" won't know how fast/slow
> my computer is." Gads Jonathon, I couldnt agree more. I get aggravated
> daily waiting for Javascript intensive web pages to download. However, I am
> not running javascript, but blazingly fast compiled Java. If the user's
> machine doesnt have the guts, I wouldn't install Ofbiz on it. They can use a
> browser to access the same funcionality.
Then you'd have double the maintenance responsibility.
You not only have to maintain the server codes that servers up GUI via browser, you also have to
maintain the Java GUI app.
Finally, you may argue that javascript is just too difficult to handle (I hate it too). Browsers
might deal with javascript so differently (or even wrongly at times). You could consider mandating
that every dumb terminal installs a new browser (the winner then). The best browser out there will
be a cinch to install. There's ready support for the browser. Many great browsers are now free,
even opensource. Will your Java GUI app be able to compete with the polish that goes into browser
development and support?
Jonathon
[EMAIL PROTECTED] wrote:
Johathon
Hmmm, you've almost got me convinced to give this up. So convinced in fact
that I am gonna forward this email on to my current customer and get his
reaction. It's well thought out and you obviously spent a great deal of
time thinking about it and I thank you for it lavishly.
Still, I have these arguments in favor to offer:
1. Backoffice personell are expensive. Even saving them 10 minutes (that's
10 seconds a transaction or less) a day translates to $3000 a year even for
the lower paid ones, and this is per-person. I have timed myself using the
Ofbiz "Order Entry" screen to enter a two item sale and the desktop Java
based order entry application I am currently finishing. The results? It
takes 20 seconds less on simple orders (Finalize with defaults) and 45
seconds less with complicated ones using the Java app. And, all my code is
using the stock Ofbiz services to do the real work so it's fairly simple to
write. The difference in time is because I can change the control having
the input focus intelligently and I don't have to wait for brower repaints
between atomic operations. A fast operator can go as fast as they can type.
I know I can achieve the same effect with ajax, but if I have to write these
apps from scratch anyway, why not take advantage of the extra horsepower and
compiled Java? By the way, the nearly finished Java app is surprisingly
small. With Ofbiz code doing the grunt work, I can spend my time making the
GUI fast, easy, and smart.
2. "Also, the move forward is to "dumb down" the client terminals (cheap to
deploy, scalable)." I would partially disagree with this although it is
repeated a lot. This was certainly true a couple of years ago, but lately,
we are heading back in the other direction. Witness the move to Ajax backed
Javascript as an example. It takes almost no time to code a GUI with
Netbeans. No such tools currently exist (that I know of) for Ajax backed
apps. Also. go look at the sales stats for Dell and HP and you will see
that the majority of their sales are to business and it shows no signs of
slowing (although it is not increasing as fast as it was a few years ago).
3. "Even if the client terminals just happen to be blazing fast enough for
graphics-intensive work...". Graphics-intensive capability is more a factor
of the video card than the CPU. EVERY desktop I see with an A/R or A/P
person in the chair is capable of running Ofbiz, Word and Excel at the same
time. On my test box, I have Ofbiz running with Netbeans, Visual Studio,
Gaim, and Outlook and it's no smoker and joker.
4. "In production, servers aren't hit all the time. There are peak periods,
and there are lull periods." If the brains are on the user's desktop, there
are no lull or peaks at any time (and no associated aggravation). Their
work is never interrupted or slowed (assuming the database server is not
overloaded.)
5. "Those folks writing the "offloading algorithms" won't know how
fast/slow my computer is." Gads Jonathon, I couldnt agree more. I get
aggravated daily waiting for Javascript intensive web pages to download.
However, I am not running javascript, but blazingly fast compiled Java. If
the user's machine doesnt have the guts, I wouldn't install Ofbiz on it.
They can use a browser to access the same funcionality.
Hmmm, now I've almost convinced myself to carry on. :)
Cheers
Skip
-----Original Message-----
From: Jonathon -- Improov [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 03, 2007 7:43 PM
To: user@ofbiz.apache.org
Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
> You might be surprised by how expensive such a solution would be to
> create/maintain/deploy and how little it will help on server resources.
I have many clients wanting to move away from that distributed (client
codes) model to the
centralized (server codes) model. Yes, it is proving to be expensive. Kinda
"tried and tested" to
be expensive, actually.
"Create/maintain/deploy" are all human activities. Will be inordinately
expensive to create
artificial intelligence to do all that. In general (with our current
state-of-the-art of AI), it
is cheaper to simply upgrade the server hardware. Yes, computer hardware
speed improvement may be
slowing down now (used to be doubling every 1.5 years?). But there will
surely be something new
coming up (quantum computers, multi-state logic units, etc), unless we're
suddenly hit by an
epidemic that halves human intelligence every 1.5 years. (Or I infect all
you guys with my stupidity).
Also, the move forward is to "dumb down" the client terminals (cheap to
deploy, scalable). Even if
the client terminals just happen to be blazing fast enough for
graphics-intensive work, perhaps
those terminals' users' job scope is to do graphics-intensive work on a
regular basis? Putting a
part of OFBiz into those machines will compromise the efficiency of their
graphics-intensive work.
As for "You might be surprised", I'm ALWAYS surprised when it comes to doing
optimization work!
Optimization needs are very hard to calculate and predict by hand. Rather
than spend weeks using
complex maths and theories to predict (presume, rather) bottle-necks, it's
easier to spend a
couple of hours to do an actual measurement of computation speeds.
> You might also be surprised by how capable servers are of handling
> concurrent load, how different performance tends to be in a development
> versus production environment, and for certain things how easy it is to
> tune them once the slowest stuff has been identified.
In production, servers aren't hit all the time. There are peak periods, and
there are lull
periods. To handle such cases, clustering and load-balancing is the usual
practice. The diff
between clustering servers and using smart client terminals, both being
distributed models, is
this... it's easier to monitor and tune a few servers than to do so for
hundreds of client terminals.
Also, consider how irritating javascript is getting to be, those that try to
offload huge amounts
of servers' workloads into our personal computers. Those folks writing the
"offloading algorithms"
won't know how fast/slow my computer is, and could render my computer
completely useless by
overloading it.
But before going into clustering, it is often adequate to spot the
bottle-necks in a single
server, and optimize just those areas. That'll help the OFBiz framework and
help the OFBiz
community too.
For all the optimization smarts we have, I must say that I had
over-optimized before in my career.
In business, over-optimizing a system isn't "passing with flying colors",
but actually translates
into a loss. While it is great to "push the envelope", it'll help in thesis
writing more than in
business. Study the bottle-necks in production settings, and fix just those.
Still, please feel free to over-optimize the OFBiz framework! That's a
different scenario. Huge ROI.
Jonathon
David E Jones wrote:
You might be surprised by how expensive such a solution would be to
create/maintain/deploy and how little it will help on server resources.
You might also be surprised by how capable servers are of handling
concurrent load, how different performance tends to be in a development
versus production environment, and for certain things how easy it is to
tune them once the slowest stuff has been identified.
-David
On Oct 3, 2007, at 1:05 PM, [EMAIL PROTECTED] wrote:
David
This issue here to me asset utilization. In a typical mid-sized company,
there are dozens or hundreds of desktop computers that their user use
to do
their daily work. If the user is using a browser to access logic on
one of
Ofbiz servers, the desktop is under-utilized. By tying in a desktop
application to Ofbiz (i.e. running an entity engine on the desktop
tied to
the same database as the main ofbiz servers and running xml setups
identical
to the servers), that workload is performed on the users desktop and
not on
the main ofbiz servers thereby freeing the server for functionality that
REQUIRES browser based access.
This does not in any way supplant Ofbiz, it enhances it by
distributing the
workload and giving the clerical user a better amd more responsive
experience.
As some examples, my recent testing of the sales order functionality
shows
that it takes ~ 200 msecs to complete the "userLogin" service or 120
msecs
to complete "calculateProductPrice" (these numbers are from the ofbiz log
file on a fairly fast machine with lots of debug output). If this is all
done on the main ofbiz servers about 5 of the former and 10 of the
later can
be done simultaneously to maintain a reasonable lag time. If the load is
spread out among say 8 desktops and 2 browser accesses, everyone has a
really good experience.
The only drawback to this all is that if the server configuration
changes,
the desktops must be patched as well. In practice, that is not a big
issue.
So, it makes great sense to me to write desktop applications for common
backoffice functions.
I am currently working on a suite of such applications, hence my
interest in
BJs SWT based CRM.
Skip
-----Original Message-----
From: David E Jones [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 03, 2007 11:12 AM
To: user@ofbiz.apache.org
Subject: Re: CRM - Customer Relationship Management facilities in OFBiz
I'm not sure where this thread is leading or how it's related to
OFBiz...
In any case, there is CRM functionality in OFBiz. The first step
would be defining in a little more detail what you mean by "CRM"
since that means very different things in different companies. OFBiz
does offer a single view into customer interactions including web
site visits, phone/email/in-person/etc communications, requests,
quotes, orders, shipments, invoices, payments, balance accounts,
projects, calendar events, and many other things. You can also
classify parties for marketing and sales, and do things like
marketing campaigns including reference codes via email, snail mail,
whatever.
If you're looking for simple desktop contact management something
like ACT or even salesforce.com would be better. If you're looking
for enterprise CRM (especially a business or industry specific
incarnation of such) then OFBiz a great basis for the effort.
-David
On Oct 3, 2007, at 11:07 AM, [EMAIL PROTECTED] wrote:
I'd like to see the SWT code as it is. To heck with translating it
to use
web based widgets.
I gotta set up a web site soon to hold code like this.
Skip
-----Original Message-----
From: BJ Freeman [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 03, 2007 3:06 AM
To: user@ofbiz.apache.org
Subject: Re: CRM - Customer Relationship Management facilities in
OFBiz
basically yes.
the tool i used added some classes to better manage things.
http://www.elance.com/p/?
q=eolproviderprofile&view_person=BJFreeman&catid=10
182#tab=1
click on Java CRM
[EMAIL PROTECTED] sent the following on 10/2/2007 8:55 PM:
BJ
SWT as in Eclipse SWT?
Skip
-----Original Message-----
From: BJ Freeman [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 02, 2007 8:26 PM
To: user@ofbiz.apache.org
Subject: Re: CRM - Customer Relationship Management facilities in
OFBiz
there at least two efforts going that i know of.
the data model pretty much has all that you need.
Si's implementation does not totally integrate with the current data
storage. it is built on ofbiz but is supported under opentaps.
Mine is something I am bringing over from Java SWT and SQL db.
Once I figure out how to show the UI I want in widgets I will release
it. Currently for my clients I use a java sWT that connects to ofbiz.
It is built entirely within the current ofbiz datamodel.
as soon as I get some irons of the fire will focus on it more
Philip Laing sent the following on 10/2/2007 7:36 PM:
Thanks for your input relating my previous questions, I am
interested in
implementing some sort of Helpdesk/CRM system and I am interested
in what
facilities OFBiz already has
Thanks
Phil
