Up to Discussions in EGL Café

This Question is Possibly Answered

1 "correct" answer available (4 pts) 1 "helpful" answer available (2 pts)
5 Replies Last post: Nov 26, 2008 4:30 AM by AndySteele  
Click to view keithj's profile  
keithj
18 posts since
Jul 8, 2008

Nov 19, 2008 8:25 PM

Function Keys?


We're using EGL to migrate from mainframe "green screen" apps to browser-enabled java. And while one of the many benefits of that is the ability to interact with the application using such "modern" technology as a mouse <G>, it is still advantageous (because of the entrenched user-base) to retain as much keystroke compatibilty between the old and new as possible.

Towards that end, the "Keyboard Assist" feature has proven quite useful. However, one of our big issues now concerns the function keys. We've designed a number of screens where there are mouse buttons that can be clicked to duplicate the functionality of the existing mainframe apps -- which all make heavy use of F1-F12. Unfortunately, these keys are universally trapped by all mainstream browsers, and their browser functions seem to take precedence. In other words, if I assign "F5" to the "Click" action for a button in my form, when I run that form and press F5, the browser does not click the button, but rather refreshes the page (the default F5 action) instead.

I vaguely remember coding around this is java before. (I'm no expert ... just a couple of silly card games <G>). However, I didn't have the luxury of that time of using a tool that had such a nice interface for specifying function key actions. It seems to me that there should be some way within the tooling to make these commands take precedence. (Though I'd probably settle for how to insert the proper javascript to do so! <G>)

    • Keith Jefferson

Iscomp Systems


Click to view KrishnaGuda's profile  
KrishnaGuda
15 posts since
Jun 5, 2008
1. Nov 22, 2008 12:16 AM Up Image in response to: keithj
Re: Function Keys?

Keith, I have seen atleast two huge application migrations from Green Screens and understand that "Function Key" always has a compelling story to be adopted in the web browser world.

I think this practice is a "no-no" as you would have to do many hacks like what you have asked for.

Your page "state" logic will become as much complex. You would have probably just missed to give the Web 2.0 features to users.

Use "Tab order" efficiently and thats it. and please also don't have so many "button press" behaviors on the screen.

// Krishna

Click to view keithj's profile  
keithj
18 posts since
Jul 8, 2008
2. Nov 24, 2008 7:00 PM Up Image in response to: KrishnaGuda
Re: Function Keys?

Krishna,

Though I'm inclined to agree with you 100% (and have made that fact quite clear in many of our developer meetings) the fact remains that I am a lowly developer on this project. The decisions as to what features are included or discarded from the existing applications are made several levels above me. <G> In other words, the customer is going to get what they ask for ... irrespective of whether or not I think it's a good idea.

Think of it as one of those unfortunate instances where optimal program theory and practice don't match up perfectly with the real world. If this has never happened to you, consider yourself fortunate and brace yourself for disappointment in the future. It's certainly nothing new to me, I've been around long enough to have endured my share. <G>

-- Keith


Click to view AndySteele's profile  
AndySteele
274 posts since
Jun 10, 2008
3. Nov 25, 2008 9:15 AM Up Image in response to: keithj
Re: Function Keys?
Keith,

you can probably do something with the event handlers in Javascript. The following code will trap the F5 key and display an alert message. This should work OK in IE but maybe not in Firefox. You'll need to do a search to find out if anyone has done this in a cross-browser library. 

document.onkeydown = function(){
  // 116 is key code for F5
  if(window.event && window.event.keyCode == 116)  {
	alert('F5 key was pressed');
	return false; // Must return false or normal processing will continue
  }
}


You may also find problems with different keyboard layouts and things like that. You'll need to test this on all your target platforms and provide a way for this to degrade gracefully if you can't support it. It's important to read up on event handling on browsers so that you understand what's going on. For example, some of the events that you might want to work with may already be used in the JSF javascript added by the web design tools.

We obviously all agree that this is not a great idea, one useful argument against not doing this is to point out the W3C accessibility guidelines and legislation (Disability Discrimination Act - DDA - in the UK and Section 508 in the US). Whilst not necessarily explicit, these do assume that normal browser functions such as back button, refresh and so on are not overridden.

Andy
Click to view keithj's profile  
keithj
18 posts since
Jul 8, 2008
4. Nov 25, 2008 4:39 PM Up Image in response to: AndySteele
Re: Function Keys?

Thanks Andy,

I've been playing with something similar. If I do this inside of the "Quick Edit" for an input field, then it works as intended. Now I'm just trying to find a way to make it more global so that I don't have to duplicate the snippet all over the handler. It's messy to say the least. And even after implementing it, I'm still grumbling about it. <G>

The only silver lining that makes this even feasible is the fact that we have TOTAL control over the environment. In other words, no user will be able to use a browser unless we've installed it and none of these machines will use the browser for any purpose other than to run the EGL suite of programs for which they have credentials to access.

We're essentially replacing their current green screen terminals with severely locked down thin clients running Windows XP Embedded. The client boots into the browser and displays a logon screen. Once there it is impossible to escape to a desktop. Sort of like a locked down PC accessing a main frame environment where the Terminal Emulator has been replaced by the browser.

Interestingly enough, since we're targeting a Windows platform, I've been doing all of my testing inside of my hacked IE 6.0 installation on SuSE Linux. It never dawned on me that if I ran the page in Firefox or Netscape (still my Linux browser of choice) that things might be different.

And since my original post, I was reminded again why the keystrokes are so important. Out of a little less than 100 users, it's estimated that 70% of them never glance at the screen until they actually need to fill in a field. They don't know the menu commands by sight. They know keystroke combinations. If you were to force all of these people to use our beautiful mouse-driven screens, you'd seriously reduce productivity. That's what happens when a system stays in place for 20 years.

    • Keith
Click to view AndySteele's profile  
AndySteele
274 posts since
Jun 10, 2008
5. Nov 26, 2008 4:30 AM Up Image in response to: keithj
Re: Function Keys?
Keith,

the little sample I provided attaches the event handler at the document level, which would provide your global handling. This is what I meant by reading up on the event handling model, events such as a key press in a field will "bubble up" through various levels until some piece of code handles and possibly stops the event i.e. by returning false. You can take some action on the event and allow it to continue processing if you wish.

Another option to look at is using the onkeypress event at the FORM level if you want to stick to using the Quick Edit mode, that should work if you've only got one form per page and you're looking to handle form events. The event itself should tell you which control received the original keypress and you can do some processing on that.

One of the beauties of EGL and libraries such as JSF javascript (and the RUI tool) is that they take away most of the pain you have to go through in managing this concept of browser compatibility for javascript. It's an absolute minefield and adding CSS on top of that makes it even more of a pain. It looks like you may not have much choice but to navigate the minefield (unless someone else can come up with another idea). There are bound to be some articles in developerWorks that will help. You could also look into resources such as Unobtrusive Javascript.

The problem of using browsers for data entry type applications is reasonably well-known, it sounds like you've got the right environment, with locked down browsers and so on. This will help; although I'd still recommend looking into the W3C accessibility guidelines, some of the concepts they address, such as navigation within applications for people who can't use a mouse, are actually applicable if you substitute "can't use a mouse" with "don't want to use a mouse".

As a final thought, your current plan supports existing, trained users. By adopting the Windows type keyboard navigation semantics you're reducing the need for new users to be trained to navigate the application as they are quite likely to be familiar with the Windows way of doing things.

Andy

Actions

More Like This

Bottom Banner