In this scenario, great care was taken to provide a user interface that adheres to standard Windows® interface features. Fortunately, Internet Explorer makes advanced UI easy. Shortcut keys (accessKey attributes), ToolTips (title attributes, where available), and tab order (tabIndex attributes) were added to all forms. The application also keeps track of whether the form data has changed, and prompts the user when he or she navigates away from the page. For an example of how the BDG developers planned the use of these interface features, see the final specifications for application screens (any of the views).
In addition, a full menu bar, on-screen Help text, and improved master/detail record display make this application an improvement over the previous BDG scenarios.
Problem: We had originally defined "menu" tags with "name" as the primary display attribute. In addition to using the attribute value of "name" to display the menu headings, this value was used by server-side script (menu.asp) to locate a particular node. However, during the localization process, the attribute value of "name" was changed, breaking the script.
Solution: We added another attribute called l_name for each menu element. This attribute contains the localizable text to be displayed as main menu topics. It can be changed independently for each language as necessary without breaking the script.
Note You can see the same solution at work in the input validation routines. Rather than using the "name" attribute of the input fields, we defined a custom attribute (L_NAME) that could be used in error messages. So, if the form input is missing or is invalid, the name displayed in the error message is the same as that displayed in the user's browser.