|
> Yup, it's my opinion, and it's based on some experience. All users aren't > idiots, but many are. I have one guy who's terminal & profile need to be > reset every couple of weeks because he keeps messing up his password. He's > been with the company, using the same terminal and application, for five > years. I've designed user interfaces, both green screen and GUI, for over 20 years - I spent a good chunk of that at the largest AS/400 software company in the world. I'm an architect, and I've seen the gamut - from users who took the diskette out of "the little black envelope, but it sure was sealed tight!", to users who designed their own screen-scraping front ends to circumvent some of the weaknesses of the package. And I sympathize for the user who basically shouldn't be using a computer. At the same time, I will not code an architecture to pander to those who can't or won't learn the requirements of their job. For example, I won't remove security to help the guy who forgets his password. Instead, he will have to wait until someone has the time to fix his password, or he'll eventually get it right. Hardball? No. It's just that there's a difference between coding to try and remove culture shock and coding to the lowest common denominator. I have far too many good users to penalize them because of one who refuses to learn. > I don't code for it because it's extremely rare. The same can > hardly be said > for hitting a back button. Exactly the same can be said if you remove the back button, especially if you Javascript around ALT-leftarrow, which I'm pretty sure you can do. But even if you can't, ALT-leftarrow is NOT an accidental keystroke. Provide a default, non-destructive action and move on. You really need to lighten up on this issue. > I'm not one of those people who insist the browser won't work. I'm one of > those people who's scratching my head, trying to figure out if the > advantages outweigh the disadvantages. Lemme know when you're done scratching. I long ago decided the advantages of a completely platform-independent interface that required absolutely no additional workstation code and could access my systems from anywhere there was an Internet connection FAR outweighed any personal quirks I might have about not wanting to code around the back button. > But all of my applications have an F12=Previous. It's easy to > provide with a > stateful connection. From what I've read, and I certainly could be wrong > (I'm no HTML expert), the only way to emulate this would be to turn off > caching at the browser. That has disadvantages of it's own. > > If you know of a better way, please share it, or provide a URL where I can > get a headstart on doing my own homework. What the heck does F12=Previous have to do with any of the previous discussions? F12 is NOT a back button, unless you also have F13=Forward, wherein you go to whatever panel you just came from, with all your data filled in. And I am absolutely positive you don't have that. On the other hand, every one of MY revitalized applications enables every command key of the original applications with a simple button, so in effect I have a "Back" button (or more correctly, a "Previous" button), if the original application had a "Previous" command key. Caching at the browser? Stateful connections? Huh? At one client, I am currently using the browser as a complete green-screen replacement - it supports subfiles and field attributes, just like on your 5250 screen. At another client, I am using a completely stateless interface to transaction servers, but again taking advantage of HTML to emulate attributes such as field protection and error notification. The browser can be used for either stateful or stateless connections - it just requires a good UI architecture. Not only that, with my architecture, I can just as easily replace the browser with a Swing thick client to provide a more "solid" integrated feel, as opposed to the browser. And in THAT environment, I don't have to worry about somebody hitting ALT-leftarrow. Joe +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.