Re: GUIizing ... Was: Upgrade from RD

[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?'

> 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


> Joe <[EMAIL PROTECTED]> wrote in message
> news:<[EMAIL PROTECTED]>... 
>> Ross, assuming that the app is presently character based, I believe
>> that it's very difficult to leverage existing code and come up with
>> a gui app that validates correctly and that most users will like. 
>> Unless you're going all out with a total rewrite, decisions will
>> inevitably have to be made where to "cut corners".
>> 
>> Depending on how an app was designed and written, it may be
>> advantageous to implement individual screens at a time, or even
>> rewrite the app a module at a time to utilize a mouse/gui.  Perhaps
>> the screens that the CEO uses would be done first...
>> 
>> One of my current projects is to review an app and (a) fix any
>> inherent problems with it so it's bulletproof (i.e., validation),
>> and (b) determine how it can be presented to the user so they'll
>> _want_ to buy it (i.e., eye candy).  I also have a limited budget
>> to work with.  Everything is always a trade off.  If we want more
>> eye candy or mouse functionality, it'll cost more.  If we implement
>> the eye candy at the expense of validation, it's a gamble that
>> users won't perform the specific steps that we're not validating
>> that will generate bad data. 
>> 
>> Unless you've got carte blanche, the success of an app in the 
>> marketplace is the result of a good gamble.  Look at Microsoft.
>> 
>> Regards,
>> Joe
>> 
>> 
>> [EMAIL PROTECTED] (Ross Ferris) wrote in
>> news:[EMAIL PROTECTED]: 
>> 
>> > Joe,
>> > 
>> > If you are trying to leverage existing code, it could be
>> > difficult to "simulate" both an ascii terminal AND an block mode
>> > device without a significant investment in rework for the backend
>> > logic ... 
>> > 
>> > The problem could be "solved" from the client, middleware and/or
>> > server, but I'd look VERY CAREFULLY at what the user expectation
>> > REALLY is.
>> > 
>> > At the end of the day, you may even find that if you wanted to
>> > support both modes of operation, that you would have 2 (quite
>> > different under the skin) programs at the client end of the
>> > equation. 
>> > 
>> > Sure, there are a lot of web sites out there that operate this
>> > way, but this may be out of historical necessity rather than
>> > design ?. These same sites may happily include a script to ensure
>> > that mandatory fields on the current form have been entered
>> > before they submit data. 
>> > 
>> > In these days of increasing bandwidth, if you could offer an
>> > internet user the "convenience" of immediate feedback, why
>> > wouldn't you ? (I'm not REALLY interested in a specific answer
>> > here ? both points of view have merit).
>> > 
>> > As a USER, I know what I would prefer, not that I'm necessarily
>> > representative :-)
>> > 
>> > Joe <[EMAIL PROTECTED]> wrote in message
>> > news:<[EMAIL PROTECTED]>... 
>> >> Ideally, it would be a switch.  In a setup, a flag would be set
>> >> to either validate or not validate each field.  If it were a web
>> >> page, it could be a cookie or something.  This way each user
>> >> could "have it their way".
>> >> 
>> >> Regards,
>> >> Joe
>> >> 
>> >> 
>> >> "ron walenciak" <[EMAIL PROTECTED]> wrote in
>> >> news:3Dgxb.2704 [EMAIL PROTECTED]:
>> >> 
>> >> > I never said you didn't have to validate at the end, Joe... :)
>> >> > 
>> >> > The point of the discussion was whether you should also
>> >> > validate at 
>>  the
>> >> > entry is being made rather than only validating at the end (or
>> >> > at 
>>  least
>> >> > that's the way I thought it was going.)
>> >> > 
>> >> > Ron
>> >> > 
>> >> > "Joe" <[EMAIL PROTECTED]> wrote in message
>> >> > news:[EMAIL PROTECTED]
>> >> >> "ron walenciak" <[EMAIL PROTECTED]> wrote in
>> >> >> news:[EMAIL PROTECTED]:
>> >> >> > I agree with Chandru.... I hate it when you get to the
>> >> >> > bottom of 
>>  the
>> >> >> > screen, and the web app tells you you made a mistake
>> >> >> > somewhere 
>>  back
>> >> >> > there. It's like going back to the old days when you filled
>> >> >> > out 
>>  an
>> >> >> > entire screen and hit the one key to send your data; what a
>> >> >> > step backwards.
>> >> >>
>> >> >> If you allow a user to determine which field they'll input
>> >> >> and you don't validate every field on the page, you're in
>> >> >> deep doo-doo as 
>>  far
>> >> >> as data integrity goes.
>> >> >>
>> >> >> > Personally, I don't mind being stopped at any field where I
>> >> >> > make 
>>  a
>> >> >> > mistake (you entered NJ and now a zip code of 90210?) but I
>> >> >> > also want to be able to use the mouse to skip over the next
>> >> >> > 10 fields that have no bearing on what I'm entering or are
>> >> >> > optional... 
>> >> >> >
>> >> >> > Ron Walenciak
>> >> >>
>> >> >> So what happens when the user clicks on 'Submit' without
>> >> >> having 
>>  filled
>> >> >> in mandatory fields (i.e., the item-id)?  Uh-oh...
>> >> >>
>> >> >> As soon as you introduce a mouse, you're in the event-driven
>> >> >> world. If you don't have code to validate each field on
>> >> >> submission to 
>>  update,
>> >> >> faggeddaboudit.
>> >> >>
>> >> >> If you're using a mouse, the bottom line is that you need two
>>  levels
>> >> >> of validation - one at the field level and one at the "page"
>> >> >> level. 
>> >> >>
>> >> >> Regards,
>> >> >> Joe
>> >> > 
>> >> >
>> >
>