The main outstanding UI issues have to do with performance. On older hardware, with older browsers, JavaScript-based applications are just slow, and OmniHelp is no exception. We have done everything we can think of to move the compute burden from the display end to the authoring end, but still, for large documents (such as the 500-page User’s Guide for Mif2Go that we use as a test case), some operations can take long enough to annoy users. All we can see to do about this is to proceed with implementation of a C++-based viewer, per our original plans for this project. This will not, however, lead to instant results, and so we continue to look for ways to accelerate the JavaScript version of OmniHelp.
We are also studying ways to allow users to easily modify OmniHelp settings. At present, we are thinking in terms of a new button, Set, in the top navigation pane at the far right. Clicking Set would display a form in the main pane (temporarily replacing the displayed topic) that would contain checkboxes, text boxes, and lists that the user could modify, with the desired values stored in persistent cookies. (There’s no way to modify the JavaScript settings file from within the browser. Fortunately.) This could provide a convenient way to choose infotypes for display, and for specifying other projects to merge on the fly.