This section deals with various options for deploying data-bearing and non-data bearing report/'dashboard' files assembled, refreshed and managed in Omniscope (both as IOK/IOM files and exportable HTML5/JavaScript interactive visualisations created in Omniscope). Omniscope has the full range of deployment options, enabling anyone to create and refresh a single IOK file that will address an unlimited range of recipients using all types of devices, from browser-only HTML5/JavaScript deployments to devices that do not support the Java free Viewer (like iPads, Android tablets & Chromebooks) to full Windows tablets that DO support the free Viewer, to Windows, Mac & Linux desktop/server machines etc.
IOK files [1]: Omniscope IOK files can be saved to shared folders, exchanged via email, or posted for download on intranet/extranet web pages. They can be accessed by others with the free Omniscope Viewer or a licensed edition installed, or using Java Web Start (below). Omniscope .IOM files are produced by Workgroup Editions of Omniscope and are the same as .IOK files, except that they can only be opened in activated Editions of Omniscope, not the free Viewer.
Omniscope Web Server HTML5/JavaScript (2.9+): Once you have fully-populated and configured an IOK file, you may choose to export interactive visualisation tabs via links that will display in any modern browser, including the browsers on devices that do not support the Java free Viewer, like iPads and Android tablets.
Web Integration [2]: Omniscope is a 'hybrid' desktop/web application, with internal browser windows (Web Views) and the ability to act as a universal web services local client. In web service client mode, Omniscope facilitates user interaction and input on the user desktop, then enables to user to submit their selections and input to configured remote web services. The HTML-formatted response from the remote server can be displayed in an adjacent Omniscope Web View or the users' default browsers. The response may also return other formats, including other Omniscope IOK files, HTML5/JavaScript visualisations and static images displayed 'on demand'.
[3]Omniscope Web Start [3]: The Omniscope Online option uses Java Web Start, standard Java technology for deploying Java applications temporarily over the web. Launched from a single link (known as a JNLP link) on your website or in an e-mail, Web Start allows an audience to use the Omniscope Viewer, without fully installing it, to open and explore your IOK files. Please note that Omniscope Online has some minor Web Start-imposed performance and feature limitations compared to the fully-installed Omniscope free Viewer.
Omniscope Custom JARs [4]: You may also choose to combine your IOK data/report/dashboard file with a free Viewer in a single Java JAR file, which almost any computer with Java installed will open. The combined files can be too large to email, since they include free Viewer installers, but they can be downloaded and synchronised via folder delivery/synch services such as DropBox, GDrive, Skydrive etc.
Publishing DataPlayer .SWFs (legacy): DataPlayers created and exported from Omniscope are stand-alone universally-accessible Flash .SWF files that contain all the data, visualisations and interactive query devices in a single file. DataPlayers greatly increase the ultimate reach of Omniscope-based reporting solutions as they can be posted and re-posted/overwritten to web pages just like any other SWF file, as easy as uploading a picture. They can also be embedded in common document files such as PowerPoint, Excel and Acrobat .PDF with full interactivity. Export options from the DataPlayer View of Omniscope include exporting the DataPlayer .SWF in an HTML wrapper for posting, or exporting as a standalone .SWF to overwrite the existing file of the same name already on the web server with a newer one containing refreshed data.
Applet Limitations [5]: This article provides more detail on why Java Web Start/custom JARs (and not Applets) provide the better results for no-installation deployments of Omniscope-based solutions.
Omniscope IOK files are the simplest and most effective way to deploy your data; more visual, interactive and re-usable than trying to share/deliver data in spreadsheet/and XLS files or closed, 'cul-de-sac' formats like browser-page tables, or static PDF or PPT files. Very compact (much smallerthan equivalent XLS/CSV files contining the same data) Omniscope IOK files can be saved to shared folders, exchanged via e-mail, or posted for download on intranet/extranet web pages. They can be accessed by others with the free Omniscope Viewer or using zero-footprint, temporoary Web Start install Omniscope Online [3].
Omniscope IOK* files:
*Note: Workgroup editions of Omniscope produce IOM files, rather than IOK files. The files are the same, except for the last point, i.e. IOM files cannot be opened in the free Omniscope Viewer.
At Visokio, we take compatibility seriously, since if you are publishing your reports in IOK format you need the confidence they will open showing the views as you configured them, regardless of which version of Omniscope your audience have.
This refers to the case where you have created an IOK file in an older version of Omniscope (such as 2.3) and are opening it in a more recent version (such as 2.5).
We provide 100% backwards compatibility. Files saved in earlier versions will open successfully in newer versions of Omniscope.
Furthermore, IOK files created by older versions of Omniscope are guaranteed to open exactly as saved in newer versions of Omniscope, with minor exceptions. For example, if you created an IOK file using Omniscope 2.3, and opened it in Omniscope 2.5, it would have the same configuration of views.
However, because Omniscope is not a document editing application but an interactive data visualisation environment, we cannot guarantee files saved in older versions will look exactly the same in newer versions. While we guarantee you will have the same configured data visualisations (for example, fields used for graph axis), buttons and toolbars may appear differently.
Additionally, Visokio may develop new views or ways of interacting with your data that replace older mechanisms. When this happens, Omniscope will provide the equivalent configuration of the new views. For example, if you created an IOK file using the Tree view in Omniscope 2.4 to show your family tree, when opened in 2.5, the same tree configuration would be shown but using the new Network view.
This refers to the case where you have created an IOK file in a newer version of Omniscope (such as 2.5) and are opening it in an older version (such as 2.3).
We provide 100% forwards compatibility, providing the IOK file does not utilise certain new features unavailable in the older version. Files saved in newer versions not using new functionality will open successfully in older versions of Omniscope.
If your file uses new functionality from the newer version of Omniscope, this will either cause the file to open with a safely downgraded experience in the older version, or cause the recipient to be prompted that they need to upgrade the software to open the file. For example, if your file uses the new Content view from Omniscope 2.5+, it will open in Omniscope 2.3 with an alternative view. But if your file uses a new file format option or security setting, such as the server time check introduced in 2.5, you will be unable to open this file in earlier versions, and will be prompted to upgrade to a given version.
You can tell what version of Omniscope is required to open an IOK file, below which you are not permitted to open the file, by visiting the About File dialog (File menu > About this file). This dialog also gives the reason for this restriction (for example, you have chosen to strongly compress your data, an option introduced to the Save dialog in Omniscope 2.3).
Most new functionality does not require the user to upgrade Omniscope, since a downgraded experience is provided. The following table lists features that were introduced that do require a minimum version of Omniscope:
| Feature | Minimum Omniscope version |
| Multi-report multi-table IOX projects (not downgradeable) | 3.0 |
| Comments in formulae | 2.5 |
| Server-checked time limits | 2.5 |
| Strong compression | 2.3 |
| IOM files | 2.3 |
| Everything else | 1.3 |
Omniscope files are not only more compact, interactive and visually communicative than other report data files (e.g. spreadsheet files and webpage tables), they also have many more potential layers of security options to prevent unauthorised access to, and potential re-use of, the data and images within your published files.
Most file security options are accessed from the File > Save or the File > Export > Data File {File Type = IOK} dialog, either as a specific Security dialogue (also available under File > File security) or on the far right side of the File > Save as dialogue under the Security section (with the exception of text field scrambling and random sampling options under the Data > Operations menu, and the 'walled gardens' security perimeter option implemented by issuance of special groups of activation keys.
Owner-locking is a change prevention and copy-prevention feature that prevents any changes to the file configuration and even cut-and-paste copying from Omniscope, as well as saving or exporting the data in any way. This is an 'all-or-nothing' setting, designed primarily to prevent recipients of your file from changing the configuration or extracting, modifying or plagiarising your data and Omniscope configuration. Only the Owner (i.e. the Omniscope installation license key that created or last refreshed the file) can be used to disable this setting. The Owner can continue to refresh, edit and save the file even with this setting enabled, but no other installation using another license key can. Effectively, a file opened on a different PC with this setting enabled will operate in free Viewer mode only; changing file configurations, un-hiding tabs or menu/sidebar elements etc. or extracting/copying data will not be permitted. This setting does not protect file B from being overwritten when opening file A, choosing File > Save as and saving over file B. In order to prevent overwrites, you should not only use write protection (see below) but also operating system-level options such as setting the file as Read only in the Windows Explorer file properties, especially for empty template files stored in a shared directory or on the server for refreshing.
This option is available from the right side of the File > Save As dialogue under the 'Other' headiing is a safeguard against accidentally saving changes to an important file, like an empty template file. When this option is selected, users will be warned if they try to save the file with changes or save another IOK file with the same name. As with Owner-locking (see above) this option does not fully-protect file B from being overwritten when opening file A, choosing File >Save as and saving over file B with the same name. To prevent this, you should use operating system-level options such as Read only settings in the Windows Explorer file properties. Omniscope's Write-protect option merely warns you if you inadvertently press Ctrl+S while an important file is open.
Less revealing versions of files for external distribution/sharing can quickly be generated automatically using operations available under Data > Operations {Scramble} and {Random Sample}. These options create a new version of the IOK file with specified text column values to be 'scrambled' such that the text values cannot be read, or with only a specified number or randomly-sampled rows preserved and the rest deleted for the saved copy of the new sampled file. These security features permit us to assist you with files containing confidential information, but also allows selective scrambling for out-sourcing of some aspects of workflow and data quality while maintaining some columns of data, e.g. names on the payroll, credit card numbers, etc. in un-scrambled format.
Tick 'password protect' and enter a password to protect the file. If you have already set a password, the Change option will let you change it. Note that if you do not add additional layers of security, anyone with the password can open the file and save a copy with a new password, or none at all. The batch output option also allows you to set personalised passwords on files so that each file recipient must use a separate individualised password.
All Omniscope Editions can apply time-limiting to files. This option should always be used to ensure that stale, un-refreshed copies of files are not used once distributed and potentially copied and saved in unexpected places. Ticking this option displays a settings dialog which enables you to specify the exact date/time the file will expire, whether or not an external online Internet time-check will be required (if so, the file will not work offline), an option to specify an "out-of-date please refresh" notice yet still allow access, and the message to display if recipients try to open a completely expired file.
Note: For time-limiting to be permanently enforceable, you must also tick "Owner-locking" (see above).
Server Editions can be used to add server-based authorisation/permissioning to files. Essentially, this uses the same login & password system used for web pages to control access to an IOK file. More on implementing this option is available from the KnowledgeBase article on implementing server-based permissioning [6].
Note: For web server-based file authentication to be permanently enforceable, you must also tick "Owner-locking" (see above)
Domain locking is a powerful and effective access-restriction and revenue protection feature. Omniscope .IOK/.IOM files are normally free-standing and easily transferred (by e-mail, posting/downloading from blogs and websites, etc.). Adding domain-locking to an .IOK/.IOM file imposes the restriction that the file must be opened directly from the originating (generally password-protected and secure) website. This option enables organisations to restrict access to current employees/subscribers with valid web credentials, and enables commercial data publishers to ensure that only current subscribers have access to their data, and that potentially stale, unrefreshed copies of files saved locally will not open. More information on using domain locking [7].
Note: For domain locking to be permanently enforceable, you must also tick "Owner-locking" (see above)
The option to designate a group of specific Omniscope installations able to create and share files only within the same licensing group is referred to as a 'walled garden'. Omniscope installations activated using license keys belonging to the same 'walled garden' group are able to exchange files, bit other Omniscopes, free Viewer or activated desktops, cannot open files created inside one or more (overlapping) walled garden groups. Files created by Omniscope installations within 'walled gardens' will open only in other Omniscope installations activated by keys from the same 'walled garden' list. An installation can belong to more than one 'walled garden group, which can overlap. Installations can belong to more than one 'walled garden', with different privileges in each 'walled garden'. Privileges for each installation can be set individually to Read-only or Read/Write/Create capabilities for both 'walled garden' and non-'walled-garden' .IOK/IOM files.
For more information on implementing Omniscope-based reporting in high-security settings, please contact us [8].
HTTP authentication is part of the Internet HTTP protocol and is a system for restricting access to any web resource (such as a page, set of pages or area, or (in the case of an Omniscope IOK file, any downloadable file). HTTP Authentication usually entails a pop-up prompt from the web server asking for for username and password, but should not be confused with a log-in page on a website where there is a username and password form displayed on the page itself.
HTTP URLs can be pre-encoded with the authentication information if needed, in the standard format:
"http://user:password@www.site.com/xyz"
...and if the credentials are incomplete or incorrect, the browser or application will prompt for username and password. Normally, HTTP authentication will be used in conjunction with HTTPS (encrypted HTTP) for added security, although this is not mandatory.
Omniscope supports options to use HTTP authentication to control access to data file in two ways; hosting and server permissioning [6], with the additional, tigher requirement imposed by domain-locking [7].
You can host your IOK files on your own web server securely using HTTP authentication. If the Omniscope IOK file is downloaded through the browser, the user will be prompted to enter their credentials before being able to download the Omniscope file. This standard facility is provided by the browser and the web server, not by Omniscope, although in the case that Omniscope's internal browser is used to access a URL directly, using for example File > Open > Open from web, Omniscope will prompt the user directly for the username and password required to obtain the file.
Of more interest is the ability of a downloaded Omniscope IOK file to be configured to refresh data from any online resource with HTTP authentication. For example, a locally saved IOK file containing a user's views and layouts can be configured to refresh-on-open from an HTTP-authenticated source, such as another IOK file or a CSV data file. On opening the local file, Omniscope requests a username and password and supplies these to the server. The server responds with the updated data, which may be personalised extracts tailored to that username. Omniscope then displays the updated data using the refreshed local IOK file's configured views and layout.
Even if the file has not been obtained by download for your own website...perhaps becasue it has been forwarded by e-mail, or folder synchronisation service like DropBox, GDrive etc. assuming you have Server Edition or higher, you can still configure your IOK file to use "server permissioning". Server permissioning (if configured) is a second check that Omniscope performs before allowing you to open, view and explore the file. This option is applied using the Save-as dialogue file security settings available in Server Editions or higher. To configure, you must supply an arbitrary HTTP/HTTPS URL which requires authentication. On attempting to open a server-permissioned IOK file, however obtained, on your local machine, Omniscope will still prompt the file possessor for the username and password for that URL, just as if the Omniscope IOK file were a web page on a remote server.
This allows you to restrict access to the IOK file according to the credentials required for any permissioned web server page you choose, and allows you to withdraw or change access rights to the IOK file even AFTER publishing your data. More detail on applying server-permissioing to control access to local Omnicope files is here [6].
The Domain-locking option enables commercial publishers and others to require that anyone trying to open their files must be logged in to their website, and ensures that stale copies of files cannot be saved locally and forwarded to others. Sensitive corporate data can be protected such that if users' web credentials are revoked via Active Directory/LDAP etc., they can no longer open or refresh any corporate Omniscope files they may still have copies of, because these files require http: authentication and are 'locked' to secure corporate domains. If an invalid user attempts to open a downloaded, forwarded, file-syched or otherwise locally-saved copy of a domain-locked file, Omniscope will not permit the file to open and will display an owner-configurable notice. More information on Domain locking [7]
Like password-protecting a file, Server permissioning and Domain locking options preventing unwanted users from opening a file, but depend on settings INSIDE the file, whereas HTTP Authetication on the web server does not. Therefore, once a secured Omniscope file has been successfully opened, a licensed Omniscope user can choose to save the file with internal security settings removed. To prevent this, you must also add the extra layer of security by applying 'Owner-locking' to the file. This file security setting is also available in the Save dialog in all Editions.
The Server Permissioning file security option in Omniscope allows you to save an IOK file with a URL pointing to a web server which will be used to authenticate users who try to open the Omniscope file, however they obtained it. This option can be used with Omniscope files saved to shared network folders accessible to a wider group, or to files shared via folder synchronisation services, like DropBox, or files downloaded from external web sites and perhaps forwarded.
Note: In general Omniscope files will work offline, but not if they require Server Permissioning authentication before openning
The example below describes how to set up basic Omniscope file authentication assuming the web server being used to authenticate against is running Apache. However, Server Permissioning will work with any other HTTP/HTTPS authentication server.
In your main website root directory create a new folder which can be named anything i.e. test. This new folder should be accessible from the web in the following format:
http://<domain name>/<folder name>
or
https://<domain name>/<folder name>
Where <domain name> should be replaced with the actual domain name e.g. 'www.visokio.com' and <folder name> with the name of the folder created above i.e. authentication. The final URL should look like http://www.visokio.com/authentication or https://www.visokio.com/authentication
Once the URL above is working, create an index.html/index.jsp/index.php relevant page which is just a welcome message e.g. "You have successfully logged in from Omniscope" in the folder created above. This page is shown to the user once they have successfully logged in through Omniscope and the file will then open.
The next step is to create HTTP authentication to determine which users are allowed to access to this location. First you need to create the password file with the usernames and passwords using Apache htpasswd.exe. For further information please refer to http://httpd.apache.org/docs/2.0/programs/htpasswd.html [9]
Once you have created the HTTP password file the next step is to create the .htaccess file. Create a new file called '.htaccess' in the folder created in Step 1. Open the file in Notepad and enter the authentication information please refer to Apache docs for further information [10]. For example:
AuthType Basic
AuthName "My test"
AuthUserFile "C:\Apache\htPasswdFile"
Require user test
Helpful information:
AuthType: The type of authentication
AuthName: This name is shown when asking for user credentials
AuthUserFile: Is the full path to the http password file.
Require user: This can be either 'valid-user' or certain user names from the htpasswd file. Please consult apache document for further information.
Start Omniscope open the file you wish to use this server permissioning on. Once open you can set this option by either going to File > File security > Server permissioning..., or from the Save dialog. You can also set server permissioning option from the Scheduler using the Secure File action. Once you click on the Server permissioning option enter the URL created in Step 1, save the file and test to verify that it works before deploying or sending to users.
Domain-locking is a powerful and effective file security and revenue protection feature. Whereas Omniscope IOK files are normally free-standing and easily transferred (by e-mail attachment, FTP posting/downloading from web portals/pages/blogs, via folder synchronisation services like GDrive & Dropbox, etc.), domain-locked Omniscope files have the additional restriction that they must be opened directly from one and only one originating website download, meaning that the user attempting to open the file must have a current, valid User ID and Password credentials for the originating website to which the IOK is 'domain-locked'.
The Domain-locking option enables commercial publishers and others to require that anyone trying to open their files must be logged in to their website, and ensures that stale copies of files cannot be saved locally and forwarded to others. Sensitive corporate data can be protected such that if users' web credentials are revoked via AD/LDAP etc., they can no longer open or refresh any corporate Omniscope files they may still have copies of, because these files require http: authentication and are 'locked' to secure corporate domains. If an invalid user attempts to open a downloaded, forwarded, file-syched or otherwise locally-saved copy of a domain-locked file, Omniscope will not permit this and displays this notice:
In order to domain-lock a particular file, please follow the steps listed below:
The domain restriction is a text string that specifies the top-level domain of the website you want to lock the file to. Do not enter the full web address; anything beyond just the domain will not work. For example, if you were to enter the domain "visokio.com", this would restrict the IOK file so it would only open from URLs such as:
"http://visokio.com/any/aaa/bbb/ccc/file.iok"
"http://www.visokio.com/any/path/to/file.iok"
"http://www2.visokio.com/file.iok"
If you were to enter "subdomain.visokio.com", this would restrict the .IOK/.IOM file so it would only open from URLs such as:
"http://subdomain.visokio.com/any/aaa/bbb/ccc/file.iok"
"http://www.subdomain.visokio.com/any/path/to/file.iok"
"http://www2.subdomain.visokio.com/file.iok"
If you create a link directly to the domain-locked .IOK/.IOM file, this will not work, because the user's web browser downloads the file to a temporary location before starting Omniscope and opening the local copy.
You can test that domain locking is working by starting Omniscope and choosing Open from the web from the Open file dialog, then pasting the full URL to the .IOK/.IOM file such as "http://visokio.com/any/aaa/bbb/ccc/file.iok".
To create a smoother experience for the user, it is best to create a Visokio .ILF file on the server which references the domain-locked IOK/IOM file as follows:
Here is a working example of domain-locking a file, testing the lock, than using an .ILF file link to provide access from HTML pages.
Note: this demo visokio.com domain hasn't been password protected. Your domain generally will be password-protected.
Bond Prices Demo file - domain-locked [12]
Testing the domain-locked locked-status:
http://www.visokio.com/files/Resources/OUGuide/453_FileSecurity/Bond_prices_domain_locked.iok [12]
Best practice is to link the user to the file via an Omniscope .ILF file constructed as described above:
Click here [13] to download the .ILF file pointing to the domain-locked file.
There are various options for building web-based reporting "dashboard" solutions combining Omniscope with your own web-based applications and infrsstructure. Please note that the options below are not mutually exclusive, they can all be used together to achieve seamless integration with existing web-based reporting and publishing systems.
HTML5/JavaScript interactive visualisations that display in web portals/pages, as will as mobile tablet devices that do not support Java such as iPads, Android tablets and Chromebooks.
Using the Omniscope outside browser [14] feature and automation options [15], personalised Omniscope .IOK files can be downloaded from intranet work group or extranet partner/customer web pages and used by anyone with an Omniscope free Viewer, just like other open document/file formats. In a few special instances, the web server must be configured for Omniscope .IOK files, as shown in the article on Web Server Configuration [16]. Omniscope files can be fully integrated with related 'dashboard' content displayed on web pages using links and the Web View.
External publishers of Omniscope files can encounter the situation where file recipients do not have install privileges for the Omniscope free Viewer. Although it is possible for Omniscope Server Edition publishers to embed Omniscope as a Java applet within a web browser, there are much more effective approaches than Applets for integrating with the web, for reasons discussed in the article on Applet Limitations [17].
The Java Web Start deploymnet option permits 'zero-footprint' or 'temporary install' client-side deployments of both the Omniscope free Viewer and .IOK data files using standard Java Web Start technology. Web Start deployment is intended to be a somewhat temporary solution, 'bridging' the time that recipients need to gain approvals to install the general-purpose free Viewer.
Limitations: due to restrictions imposed by Java, when running as a temporary, no-installation instance, deployed Web Start Viewers do not have access to Excel or PowerPoint, so only generic .csv and image screenshots can be exported if the Viewer is running from Web Start, rather than fully locally-installed free Viewers. For more on using Web Start, see the article on Web Start Issues. [18]
Omniscope can act as a universal local client for remotely hosted web services. Users interacting with Omniscope can send input to configured Web Services to provide remote functionality on request, based on data submitted from Omniscope. Omniscope permits the user to select/submit a single string input to (like a search phrase), or submit a column of selected references, or even submit a table of selected/input values (contact us for more details) for remote processing. The remote web service response pages can be viewed either in Omniscope's integrated Web View windows, or the users' default browser. For more information see the KnowledgeBase sections on Configuring Web Services [19] and Communicating with Web Services. [20]
Using an activated Omniscope and the DataPlayer View to create exportable Flash .SWF DataPlayers is the simplest option for displaying interactive, filterable data directly on the web. Although suitable for most 'dashboard'-style reporting, Flash files currently do not scale up to achieve the multi-million record counts, functionality and data handling capabilities of Omniscope. For more on how to publish DataPlayer .SWF files in web pages, see Publishing .SWFs [21].
Extension: .iok
MIME type: application/vnd.visokio.omniscope-iok
(or use the generic binary mime type application/octet-stream if this causes problems)
Omniscope Desktop and Server/Publisher Editions can still export legacy minimalist HTML display pages containing the DataPlayer .SWF files ready for display on the open Internet. DataPlayers produced by licensed copies of Omniscope can be displayed on any inter/intranet domain.
Note on managing images: Although DataPlayer .SWF files can incorporate images for use in Tile View, they will be fixed in size and often reduced resolution. The original, higher resolution images can also be displayed on the web in the DataPlayer Details View, but only if the entire folder containing the original, larger/higher resolution images is also uploaded to the web server in the same relative directory location as when the image set was originally specified in the .IOK configuration file from which the DataPlayer was exported.
Once you have configured an Omniscope DataPlayer .IOK project file, previewed the .SWF on your desktop and saved all your configuration settings in the .IOK data file, you are ready to export your DataPlayer SWF file set for display on the web. Just click the 'Save for Web' button on the Save Settings and SWF page. When you click 'Save for Web', the DataPlayer is exported within a web-ready file structure with a minimalist HTML display page in the top level of the directory structure.
Once DataPlayer/FeatureFinder Studio has finished exporting the web file set containing the DataPlayer, open the resulting HTML display page (bearing the name of the project, in the top directory of the file structure) with a standard HTML editor such as Adobe DreamWeaver or Microsoft FrontPage. You will see that the exported display page is minimalist, with only enough mark-up to display the DataPlayer .SWF in a browser. The minimalist page has none of the final HTML layout, scripting or content (with which you or your web master will want to surround the DataPlayer) for display on the web.
Suggestion: Good practice at this point is to make a copy of the top-level, minimalist HTML display page, change its name and put the copy into the same location alongside the original. From then on, only paste your own mark-up, scripting etc. into the re-named copy. This way, if you modify the DataPlayer and re-export its file set, the original minimalist display page is overwritten, not your own elaborated version. The underlying DataPlayer files referenced in your own version of the display page are all updated, and they are still referenced properly assuming their relative position in the directory structure has not changed.
When you are happy with the look of both the DataPlayer and your own HTML mark-up and scripting surrounding it, upload the entire file set and the original images folder (if any) to your web server (preserving the directory structure).
Warning: If you are using UNIX/LINUX web hosting, remember that all file names/references will be case-sensitive. Check all the references in the files produced by Omniscope against your own namings to make sure that upper and lower case is being used consistently in the file names and all references to the files.
Omniscope Online is an additional no-installation free Viewer deployment option which uses the standard features of Java Web Start, supported on almost all computers that have Java installed, which is almost all of them, except for mobile devices like iPads, Andriod tablets and Chromebooks.
Java Web Start is an optional way to deploy the free Viewer to users' machines using standard Java technology that allows anyone with Java (which is almost everyone) to temporarily install the free Viewer from a web link or page button and download an associated IOK file. Once downloaded, the Viewer is cached in the users' machines' local Java cache for re-use, but the accompanying IOK data file is not saved, and must be re-downloaded from the Publisher's web site on each use, ensuring fresh data and providing security against data forwarding/misuse.
Visokio supply an online Linkbuilder tool to help you configure Omniscope Web Start deployment options. The LinkBuilder tool is available on this page [3] of the KnowledgeBase. The first page is designed to accept your inputs for optional paramenters related to Omniscope Web Start deployments from your own web site:
Once you have specified all your optional inputs, press [Submit] to generate a second page with your links and and launch button code:
Copy these links and launch button code into your own website and you users will be able to download you files in a temporary (but locally cached) version of the free Viewer.
Desktop and Server Editions can all package IOK data files together with temporary Viewer installers as a single, standalone JAR file (with your own branding on the Viewer if you have Server). These exported custom JAR files will open on any device that has Java installed, which is almost all of them, except iPads, Android tablets, Chromebooks and Windows RT consumer devices). Users can download and double-click the single JAR file to view - no full local installation of the Viewer is necessary.
Custom JAR files can be too large to e-mail, but work very well with file/folder synchronisation delivery services like DropBox, GDrive etc. - no web site required!
 |
Applets were first introduced several years ago to provide little animations inside web pages, before the days of Flash. They are not architected for large applications and pose several problems, some insurmountable. (please scroll to the end for discussion of alternative deployment options).
Memory requirement in Omniscope is the result of a complex equation depending on upon data complexity, view configuration and use case. Omniscope was built to leverage the higher memory capacity of relatively modern PCs to provide a rich data navigation experience.
Applets are limited to 128mb of memory which, as a very rough guideline, may be enough to navigate smaller files with limited views. The only true way to find the applet memory limit for a particular type of data is to experiment with data size in terms of records and fields.
"Life-cycle" is the manner in which an application or applet is started, executes, and is stopped, then later restarted. Applets have a fundamentally different life-cycle from applications.
With an application, whether Web Start or installed, each time you open it it gets a clean start. Multiple instances of the application run independently. When you close it, it stops completely.
Instead applets are started and stopped by the container. The container is the combination of the web browser software and the Java plugin. Applet stopping and starting is triggered by navigating to/from a page or refreshing a page.
Unlike applications, applets don't get a clean start each time. Instead, stopping and restarting applets is done by the container using certain techniques which do not completely restart the application cleanly. These techniques are well documented as "inherently unsafe" and for larger applets result in unpredictable effects and instabilities.
The applet can get into a state which it will not recover from despite page refreshes, unless the browser is restarted. The only way to restart the browser is to close all browser windows before opening a new one which cannot be considered an acceptable solution.
Omniscope is very large by applet standards at roughly 10mb. With some stripping-down work this could be reduced, perhaps to 7mb. Regardless, it can take a minute or two to download on typical connections. This would be acceptable if the user was reliably informed of progress during this period, but applets do not do this effectively. The container typically shows a blank screen or box with no progress indication. Most users would give up waiting.
Recent versions of Java added the ability to show applet progress and to cache previously viewed applets, except the implementation was buggy. The progress went up to 100%, then carried on going with no predictable end, and the caching did not provide any improvement. This is an ongoing problem and an indication of a lack of motivation from Sun (who make Java) to support applets.
There are a wide range of environmental variations that create a complex set of permutations which need to be tested for and handled when deploying an applet. These are out of the applet developer's control and make providing a reliable applet extremely difficult:
Different browsers have different mechanisms for checking Java (and prompting for installation if necessary) with variable reliability. There are several ways of doing this check, none of which reliable, requiring complex cross-browser javascript checks. If Java is too old, on some browsers the applet just won't open, requiring a second applet just to check the version of Java. While not unsurmountable, these add up to additional complexities delivering a reliable applet.
Omniscope's user interface was designed for full-screen use. While it will scale down to small window sizes, more room is generally better. One of the philosophies behind Omniscope is to "show you the data"; an applet restricted to a panel within the web page may not have enough room to do this and will restrict ease of use.
When a user first opens a web page containing an applet, the web browser will often freeze for several seconds while Java is started. During this time the browser does not respond to interaction such as scrolling, clicking or navigating in other windows. This can appear concerning. Also, users expect web pages to respond within a few seconds. If a page takes more than 10, most will give up. Opening an applet page will often take longer than this to become responsive and several minutes to complete.
With an applet, the web browser and the Omniscope program are inextricably linked. If either has a problem, the other does too.
Either of these situations mean the user's session in both applications may be lost if there is a problem in the other.
To prevent rogue applets from causing damage, applets are unable to access files on a user's hard disk or communicate with other websites. This prevents the user from saving their work. It is excessive since the web browser allows users to save and upload files; logically the user should be able to authorise an applet to do the same.
Our recommended approach to distributing data over the web is publishing .IOK files to any number of readers/users with local installations of Omniscope (Free Edition or Professional). Those users with an activated Professional licenses will also be able to add/export data and analysis, and re-publish/re-distribute an enhanced .IOK file
This method is similar to the PDF document publishing model, where the ubiquitous Acrobat Reader must be installed. You can also compare this method to providing Excel XLS files for download.
A zero-footprint solution requires no software installation and no administrative capabilities to get started using the software. Java 1.4.2 or later is still required, although most users already have this. Deploying with Web Start is the preferred solution as it solves almost all of the problems above with applets.
Web Start is a technology which has been built into Java for the last few years. Instead of seeing an applet buried in a web page, the user clicks a link which launches the application in its own window, much like starting the application from the Start menu.
With Web Start, memory allocation is controlled by the publisher and there are no life-cycle problems. Security restrictions are more intelligent, allowing the user to open and save files, for example. The browser and Omniscope are isolated, so a problem in one won't affect the other.
In particular the user experience starting Omniscope deployed using Web Start is much improved over applets. Accurate progress is shown when the program is downloaded, which only happens on first visit, and the application opens much faster.
There are still some environmental variations of concern. With Java 1.3.1 onwards, Web Start was bundled and handled Java version checking automatically. In theory, if the user has Java 1.3 they will be prompted for auto-installation of a more recent version of Java before Omniscope will open. Unfortunately older versions of Web Start did not always handle this well, and many corporate systems administrators do not test for Web Start operation on deploying Java to their desktops - occasionally resulting in problems locating a suitable version of Java.
These minor problems make publishing to the installed application the preferred deployment/publishing method. However it is quite possible to do both by providing a link for the .IOK download, a link to download the software, and an alternative link to start via Web Start.
Links:
[1] http://kb.visokio.com/kb/iok-files
[2] http://kb.visokio.com/kb/web-integration
[3] http://kb.visokio.com/kb/webstart
[4] http://kb.visokio.com/kb/custom-jar
[5] http://kb.visokio.com/node/201
[6] http://kb.visokio.com/server-permissioning
[7] http://kb.visokio.com/domain-locking
[8] http://kb.visokio.com/contact
[9] http://httpd.apache.org/docs/2.0/programs/htpasswd.html
[10] http://httpd.apache.org/docs/1.3/howto/auth.html
[11] http://kb.visokio.com/files/Resources/OUGuide/453_FileSecurity/Bond_prices.iok
[12] http://kb.visokio.com/files/Resources/OUGuide/453_FileSecurity/Bond_prices_domain_locked.iok
[13] http://kb.visokio.com/files/Resources/OUGuide/453_FileSecurity/Bond_Prices.ilf
[14] http://kb.visokio.com/kb/outside-browser
[15] http://kb.visokio.com/kb/automation-options
[16] http://kb.visokio.com/kb/web-server-config
[17] http://kb.visokio.com/kb/problemwithapplets
[18] http://kb.visokio.com/kb/web-start-issues
[19] http://kb.visokio.com/web-services
[20] http://kb.visokio.com/kb/web-services
[21] http://kb.visokio.com/kb/publish-swf
[22] http://tc.visokio.com/webstart/
[23] http://java.com
[24] http://kb.visokio.com/issue-report
[25] http://kb.visokio.com/contact-form#support