This section deals with various options for deploying Visokio application files, Omniscope .IOK/.IOM files and DataPlayer Flash .SWF files created by DataPlayer Studio/FeatureFinder Web. Omniscope .IOK files can be opened by anyone with a free Viewer installed. Omniscope .IOM files can be opened only by activated Omniscope installations, i.e. Omniscope Standard or better. Omniscope Web Start files (available soon) can be opened even on desktops with no installation privileges.
Omniscope .IOK/.IOM files, Omniscope Web Start (zero-footprint temporary install) and universally-accessible Flash DataPlayer .SWF files embedded in web pages and documents provide a wide range range of options for publishing data sets interactively, both internally and externally.
Omniscope DataPlayer & Enterprise Editions export web-ready file structures (with minimalist HTML display page) 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. DataPlayers produced by FeatureFinder Web will display on nominated domains/sub-domains only.
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.
Extension: .iok
MIME type: application/vnd.visokio.omniscope-iok (or use the generic binary mime type application/octet-stream if this causes problems)
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.
Omniscope Online is an additional Omniscope Viewer deployment option for versions 2.4 and beyond of Omniscope, requiring no installation.
Back to Deployment Options
Note: Running Omniscope as an executable JAR file is not fully supported and some features, such as the Web view, will not be present.
This section assumes understanding of system administration via a command line or terminal window. Information you type in yourself will be shown like this.
Once you have done this successfully once, you may wish to create a shortcut or script which encapsulates Step 5 for future use.
Back to Deployment Options