HTML Challenges  Click on any item to view... Contents + Introduction + Concepts Product Positioning Comparison Matrix ScreenSurfing vs. ScreenScraping HTML Challenges HTML Advantages HTML and/or Java? + Operations + Customization + SurferScript Guide Delivering screen-based applications to standard web browsers using standard HTML is essential. Any other means of delivery reduces platform and network independence as well as introducing access-inhibiting installation and support requirements. HTML delivery comes with challenges, however. The user interface of HTML and network interface of the HyperText Transfer Protocol (HTTP) impose restrictions on how the protocol of the screen and keyboard of a typical terminal device can be delivered. Screen refresh synchronization The first of these challenges is based on a key difference between a browser-connected user and a terminal-connected user. With a real terminal or PC-based emulation package, outbound data from the host application can arrive in any number of information packets. A host application may send a block of screen data in a single transmission, then pause and send another block. In a standard terminal environment this is not a problem, because the communications link between the terminal device and the host is persistant. In an HTTP browser environment, however, the link between Screensurfer and the browser lasts for only a single interaction "in" and "out". This means that Screensurfer must anticipate when all writes are complete before sending the next page to the browser. SNA, TN3270 and TN5250 protocols implement a form of "bracketing" to try and assist client-side software and devices in identifying the start and end of a screen refresh (regardless of the number of buffers or information packets). However, in many situations, particularly logon and application selection sequences, in addition to multiple information packets there are multiple brackets. In the TN5250 environment however, this situation is not as common as in the 3270 environment due to a more structured approach to managing the client-to-host interaction. Host Settletime and expected writes Screensurfer addresses the synchronization challenge with two user-customizable settings which enable the developer to anticipate a "problem refresh" and tune the current session to address the specific nature of that refresh. Settletime is a setting that defines how long Screensurfer will wait following each information packet prior to collecting the current screen data and sending out to the browser as an HTML page. HostWritesExpected is another setting which may be temporarily overridden from the default of 1. This sets the number of expected "brackets" that will occur in the next screen refresh, and is particularly useful when application selection screens or logon screens are involved, where multiple brackets are common. For detailed information on adjusting both of these options, refer to the Special Screen Variables in the SurferScript Reference. TEREADYWHEN, EXPECTING AND TEFIND In addition to the two special variables described above, there are a number of other tags specifically designed to manage difficult screen transitions. TEREADYWHEN is a new tag in version 1.3E that provides a pre-transition capability, simplifying logon sequences and other typical situations. A list of screen recognition criteria can be providing covering all possible results, so that the next screen transition won't complete until one of the possible screens is completely written. EXPECTING is an optional clause of the TEACTION ENTER tag, allowing the developer to force a wait inside the TEACTION tag for the identified screen. TEFIND may be used at any time to search for text on the active screen. An optional timeout attribute may be used to cause the TEFIND tag to wait until the text is found. SSCheck Java Class The SSCheck.class file is a small Java applet provided when Screensurfer is installed. It is provided as "training wheels" for new users, and will provide very reliable screen transitions. It does this by "polling" the loading Screensurfer at ever-increasing periods until finally stopping at around 8 seconds. What it checks is if the host screen has been updated unexpectedly by the mainframe. If so, it refreshes the current display. Session and state maintenance Another challenge in the HTML/HTTP environment is the maintenance of a user's session as well as any "state" data associated with that session (state data is data which is associated with a session between a user and a web server--it must be unique to the user and not confused with data from other users currently interacting with the server). Since HTTP interactions are a single "in" and "out," each new request from a user carries with it no underlying identification such as "I'm user 15 and I'm connected to host session 22". Screensurfer solves this problem by generating a unique Session Key each time a user performs an initial connection to a host session. All HTML pages sent to the user include the session key as part of any response requests that may be encoded in the HTML, such as an entry form or a menu link. Each request from a user will then be inspected by Screensurfer for the session key, which contains both the host screen session identifier as well as an "authentication string" which is guaranteed to be unique across all the sessions and all the users. This assures that each user only sees his or her session, and that a capricious user cannot simply "fiddle" a URL and "take-over" another user's session. Help! I got lost... With browsers, it is easy to "wander off" and find oneself unable to "back-up" to where you were. If a user has been connected to a Screensurfer session, this isn't a problem. All that is needed is a bookmark containing a simple "connect" request to the Screensurfer web server address. A cookie stored in the user's browser is used for all connect requests and passes the user's active session key. If the user's session is still active, he or she will be reconnected; if the session has timed-out a new session will be started and the logon or first screen will be presented. What about the back button? One of the great advantages of the HTML browser environment is the ability to "back-up" and review a prior page, without having to navigate to that point using a providing link. This is particularly useful for many business applications, where information previously viewed is "all part" of the current process or query. Screensurfer by default enables the user to back-up and review prior pages, as no "tricks" with the browser's cache are implemented by Screensurfer; caching is fully supported as is the back-button. Implementing back-up and submit Screensurfer even makes it easy for developers to enable users to use the back button and resubmit a prior page. Normally, this will present the user with an informative message like "sorry, the screen you submitted is no longer displayed; the current screen is:" followed by the current screen. By implementing screen recognition (using the <TESECTION WHEN> attribute) and navigation (using the <TESECTION PATHTO> attribute), a developer can provide Screensurfer with the minimal information needed for Screensurfer to resynchronize the host session with the browser page being submitted. This can be particularly useful for certain kinds of iterative tasks, such as reviewing the orders for a particular customer. The keyboard doesn't work! This is the biggest complaint you will hear from any experienced user who is used to pressing a PF (program function) key or the enter key to advance to the next screen. Browsers and HTML forms don't support the keyboard quite like the way that terminals and PC emulators do. This situation is getting better with the introduction of new JavaScript event handlers, but the level of support in general for function keys is still not adequate for implementing full keyboard compatibility. With Screensurfer Version 2, the SSKeys ActiveX control is now provided with the install program, along with SurferScript in the Personal.stml file to enable users to select use of SSKeys. SSKeys enables re-mapping of the PC keyboard to simulate any of the 3270 function/AID keys. For those wishing to stay with a 100% HTML user interface, the best way to address this situation is to use Screensurfer's quick enhancement capabilities (the DevCenter Field Level template generation is ideal for this) to provide the user with easily selected hypertext links or buttons which provide both informative text (such as "Page Up") as well as a single click with the mouse to perform the function. The columns don't line-up! Many screens implement columns with headings on the top. For display-only, this works fine in HTML, but if there are any entry fields in any of the rows, the data to the right of the entry fields gets "pushed" to the right. This causes a mis-alignment of the data to the right of the entry fields with the column headings. Screensurfer Version 2 introduced the concept of HiFi HTML entry fields-- these are currently only available in browsers with CSS (Cascading Style Sheets) for setting the width and height of entry fields using the Style="width:x;height;y" attribute. At present, IE4 and IE5 from Microsoft both work with HiFi HTML entry fields, and the Personal.STML file distributed starting with Screensurfer V2.0 supports user configuration of both font size and the necessary factors for achieving perfectly aligned columns in a mixed entry/display screen.