"Chandru Murthi" <cmurth_xyz@[EMAIL PROTECTED]
> wrote in message
news:cgAEj.7724$rR1.1778@[EMAIL PROTECTED]
> Have no idea why you think a GUI, in and of itself, is in any way
limiting
> in your scenario. If you want to open a master file input routine, I
would
> think it's much easier in, say, (the dreaded) browser interface since
you
> merely have to open another browser session, "do your business in the
> master file," and continue in the other (untouched) session.
I love playing devil's advocate. I still think it's more limiting to
have
to manage several different windows in order to do something like
drill-down
maintenance. In a browser scenario, you may have 3 or 4 different windows
open in order to achieve what would happen in a sequential, multiple
screen
process. The overall steps are the same. You need to go into X screens and
edit information. I just think that it's less headache to be able to do it
all from a single window. If you want to bring Windows tab controls or
tool
bar controlled MDI into the picture then I agree with what you say.
>
> Persistence has absolutely nothing to do with it...unless you're
> suggesting that opening the second session somehow loses the first.
> Without closing the original browser window, you'd have to work hard to
> make this happen.
>
That totally depends on who's writing the framework. If you're building
the tool yourself, then state persistence is very im****tant to consider.
If
someone else has already written it with persistence in mind, then it's
not
something the developer has to consider when writing the applications.
I've
written several web-based tools in-house and have encountered many
problems
that many of the RAD systems have solved over the years. I can't say much
about .NET since I haven't developed with it at this point.
GlenB
> Chandru
> "GlenB" <batchelg@[EMAIL PROTECTED]
> wrote in message
> news:fd6ea669-2bfc-4ab1-a379-398df69cfe1b@[EMAIL PROTECTED]
> On Mar 14, 10:06 am, sh <sham...@[EMAIL PROTECTED]
> wrote:
>> Has anyone succeeded in getting their management to move from their
>> tried and true green screen PickBASIC application to a more modern
>> interface/software structure? What economic benefits can you propose?
>> After all, doing so would mean rewriting and/or subroutining (? Hello
>> Websters Dictionary) the whole application. (Has anyone done it
>> piecemeal?)
>>
>> Our green screen application might not be pretty, but it's terrific.
>> From the end-user's perspective it's quite efficient heads-down (even
>> if a little ***bersome at times because you can't pop up windows at
>> will). From managements perspective it's great - it runs the business
>> well and it's cost-effective to run and develop. And we are constantly
>> adding enhancements to it - to make life easier for the end-user, as
>> well as to improve the business bottom line. And, yes, we have
developed
>> interfaces to Windows applications - Word, Excel, UPS Word****p, etc. So
>> there really seems to me to be little economic justification for moving
>> from green screen, PickBASIC to anything more modern.
>>
>> Is that true? Are there significant benefits to a revamping? Does
anyone
>> have real life experience in this area? Are there really sufficient
>> cost-savings to warrant the huge expenditure? Can VB.NET, DesignBais,
>> whatever, really be cost-justified?
>>
>> (I'm not talking about moving from MV. We'll stick with that. I'm
merely
>> talking about the software interfacing to the data. And I'm also not
>> talking about a package being sold by a VAR, where saleability is a top
>> priority. I'm talking about a home-grown package running a business.)
>>
>> Sholom
>
> The only time it's justifiable, in my opinion, is when screen real
> estate runs out. If a user is constantly switching between several
> screens to see all the info they need then perhaps a new screen which
> combines the relelvent info is required. When that combined screen
> runs out of screen space, then (and only then) I would consider it
> time for a GUI tool. I find GUI interfaces to be problematic from the
> view of linked validation and correction. What I mean by that is:
>
> 1) Screen A needs field 1 to be entered
> 2) I go to enter field 1 and it's a linked input, which pulls codes
> from a master file
> 3) I don't see an option for the value I need, so I hit a function key
> to call into the master file screen(up a stack level)
> 4) I do my business in the master file, save the new code and I pop
> right back into the code selector(down a stack level) on my previous
> screen
> 5) I pick the new value from the selector and finish the screen entry
>
> Consider a remote validation method where you call one non-
> interactive subroutine per field validation. How do steps1-5 fit in
> that method of validation? You will need either:
>
> 1) a pop-up window option to pull up a GUI version of that master
> file. The selector also needs to be able to reload the codes on its
> own, without losing any unstored info.
> 2) a tem****ary save function that holds your entry data in the
> background so that you can go into another area of the GUI tool, enter
> the new code, and then return back the entry screen you were at.
>
> No matter how persistant-state you make your GUI tool, there will
> always be limitations on process design when moving from character
> screen to GUI.
>
> GlenB
>
|
