"GlenB" <batchelg.removeit@[EMAIL PROTECTED]
> wrote in message
news:92FEj.23461$vr3.8968@[EMAIL PROTECTED]
> "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.
Again, if the user cannot handle multiple windows open, I can see a
problem.
But then that only applies to those of them over 50, no? Can you imagine
anyone of the Gen X/Y being bothered by multiple open windows?
Iae, there are other soluitions:
1- Tabs as you suggest.
2- Overlay the new window exactly over the old one. Now the user would
have
to explicitly move the top window in order to be bothered.
3- Mininize original browser screen and show new one; when new one
unloads,
it triggers a restore to old one
4- Get more flexible users.
>>
>> 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.
Please reread my paragraph. I find it hard to understand how opening a new
window WITHOUT closing the original one, can possibly lead to any
persistence problems which do not exist anyway. In other words, OPENING a
window cannot cause ADDITIONAL persistence problems.
If you're making a general statement about persistence being an issue with
browsers, of course, concur. Even so, that is not hard to handle.
Chandru
> 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
>>
>
>
|
