Re: GUIizing ... Was: Upgrade from RD

Joe <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>...
> [EMAIL PROTECTED] (Ross Ferris) wrote in
> news:[EMAIL PROTECTED]: 
> > Joe,
> > If you are after the best BFB (bang for bucks) rating, then why not
> > leave the data entry screens alone in the first instance, and just
> > have GUI versions of the enquiries .... THESE are the screens that
> > the CEO will use, and by not (necessarily) having to worry about
> > validation rules, they are simple .... and these are probably the
> > same applications that would be "useful" if they were available via
> > the web.
> 
> True.  But there are instances where you might want to validate even on 
> the CEO's inquiries.  If he/she inadvertently keys an ending date that's 
> before the beginning date on a file select, chances are they'd be 
> annoyed that the app went and did the select with the bogus date range 
> and returned 'No items present'.  The first thing they'd say is "Why 
> didn't the program tell me the dates were wrong before it wasted my 
> valuable time?"  So, we're back to 'when do we validate?'

"Basic" validations like this should be performed on the client ...
with our Visage product you would simply say that the minimum value
for the "end date" was the start date, and the maximum value for the
"start date" was the end date.

Likewise if there are codes that needed to be entered (eg: valid
customer codes) you would obviously validate these, and yes, this
would be done on the server (by default Visage would validate "on the
spot", but if you REALLY wanted to, you could have the validation
performed all at once at the end (now THAT is a PITA as far as I'm
concerned)

I was looking more at avoiding some of the "tricky" business rules
that tend to be embedded in the data/transaction entry side of the
equation, rather than the enquiry/inquiry/reporting functions out the
back ...

> 
> > There is a continuum of how hard (or easy) it is going to be to
> > convert a given app ? if it was designed with a tool, then you are
> > streets ahead of a hand coded app (generally);
> 
> I'm not sure I'd make that assumption.  I think it all gets back to 
> original design.  Some tools are a real PITA to work with, to the point 
> of having to do things for the sake of the tool and not the app.
> 
> > If the tool (or
> > manual standards) enforced modular code, then that is another plus ?
> > if you have spaghetti, then a total rewrite is probably in order
> > anyway to get rid of the skeletons !
> 
> I'd think that a majority of existing apps (especially legacy apps) are 
> spaghetti.  After all, it's the nature of Pick to make it easy to 
> write/maintain apps that work with spaghetti code.  And, as you say, a 
> total rewrite is in order with these apps.  But getting back to the BFB, 
> is it worth it?
> 
> > As you know, there is no "silver bullet" that will do the work for
> > you automatically
> > 
> > Good Luck
> 
> Ah, yes.  IMO, it simply doesn't pay to rewrite a working app just to 
> gui-ize it.  Unless you've got customers lining up at the door, the 
> return just isn't there.
> 
> Regards,
> Joe
> 
> 

The converse axiom also may apply of course - otential customers will
not form a queue UNLESS you have a GUI .... the whole exercise is very
"catch 22", but if you think you will still be selling a CUI product
in 5 years, ask yourself (honestly, with full regard to market
expectations) if sales would be easier, or harder, with a GUI - and
would you expect more, or less sales !?!?

I no longer stand on the fence (I did that for far too many years ....
now THAT is a REAL PITA!!!). All other things being equal, I believe
it will be easier for us to sell a GUI version of our product than a
CUI version.

Our users have been "mixed" on the subject, and yet some of the
strongest supporters of CUI in our user base (who purchased our
applications because they WERE character based) are now the loudest
voices for GUI now that they have seen it ..... maybe we shouldn't
have used "modern" techniques, and kept a WFW 3.11 GUI standard ? but
alas, when we developed Visage we were trying to get the best of both
worlds :-)