ExtraView for this release is certified to support the following browsers.
These browsers are supported on the following platforms (where available) – Windows 8.1, 10.0, Apple Macintosh, and Linux. The exception is Apple Safari which is not supported on Microsoft Windows platforms.
All Apple iOS devices with version 12.0 or greater are supported. Android devices with version 9.0 or greater are supported, but not all manufacturer's devices have been tested.
The resolution of desktop monitors or screens on which users should use ExtraView should be a minimum of 1280 x 1024 pixels. While ExtraView will work at lower resolutions than this, users may have to scroll up, down and sideways more than they would like. The administrator can make decisions in the design phase that will affect this. For example, the settings in the style sheets that control the small, medium and large font sizes can be tailored, as can the number of columns and rows that appear on screen layouts. If the users are utilizing the Workspace feature, the recommendation is to use screens with as high a resolution as possible, to maximize the number of viewable panels. The recommendation is that administrators should design their layouts to fit within a resolution of 1280 x 1024 pixels.
Most browsers have cookies turned on as a default setting and this is what ExtraView expects. If cookies are not turned on, ExtraView will warn the user, and will not function until they are turned on.
When the administrator enables the behavior setting ALLOW_CHANGE_LOCALE_AT_SIGNON. In this case, a cookie retains the preferred locale setting for the user who signs on for a 30 day period. No other information is stored within the user's computer.
When the administrator enables the behavior settings ENABLE_TWO_FACTOR_ATH and ENABLE_DEVICE_VERIFICATION, and a user elects to remember their sign on details within a particular browser on a specific computer, a cookie is also set to rember this information.
JavaScript must be turned on within the client browser.
Users should never use the browser’s back button within ExtraView. They should only navigate by the buttons that are displayed on ExtraView’s menus. The reason is that ExtraView must maintain integrity of its information at all times. For example, if you press the button on ExtraView’s Add Issue screen to add a new record, then pressed the back button and pressed the add button again, you will have two records inserted. Similar problems occur if the user attempts to go back to a record he has edited, or to go back to a screen that was refreshed from the server during adding or editing an issue.
Similar to the Back button, the Refresh button within your browser should not be used. At the times that a Refresh is allowable, ExtraView will offer a Refresh button in its menu bar.
Many, but not all, pages displayed by ExtraView within your browser may be bookmarked, and shared with other users. Bookmarks are created by using the normal conventions appropriate to your browser. This is slightly different for each supported browser, but simply follow the appropriate steps from your browser manufacturer. For most commonly accessed screens you can copy the URL in the address bar of your browser, and paste the URL into emails or documents and share these with other users. Note that all security permissions are obeyed when you share a URL. If the receiving user does not have permission to a given feature, or to specific fields, they will not be able to use these features or view the fields, no matter the permissions of the sending user. When a user pastes a URL into the address bar of their browser, they are required to sign on if they are not already authenticated. The most common URLs that you may want to share are:
Note that individual administration screens cannot be bookmarked or shared.
ExtraView must work consistently with a single character set, in order that information entered within different browsers across an organization will be compatible, and can be stored on and retrieved from the ExtraView server in a consistent manner. This is less of a problem with languages based on the Roman alphabetic, but is an essential ingredient of correctly configuring a system where users use double-byte languages such as Japanese and Chinese. There is a behavior setting (see the following section) named HTTP_CHARSET that defines the character encoding for input from all browsers, for all users of the ExtraView instance. By default this is set to UTF-8, a character set that is universal and supports all languages. The recommendation is to have all users set their local browser character set to UTF-8. If this is to be changed, then it must be changed on the server and in every client browser.
Note: It is strongly recommended that HTTP_CHARSET is set to a value of UTF-8, and that all users only set their browser character set to UTF-8, so that characters will be displayed correctly and consistently.
