The Intellog Blog

A user recently asked us to compare Intellog’s Onramp search engine with other well-known search methods.   For example; they wanted to find information on "multiwell proration", for which they would normally use a general-purpose search engine such as Google®.  They wanted to know how these search results would compare to results from the source site’s embedded Search box and in turn, how they would compare to results from Intellog’s Onramp search.  Here are the results of our investigation;

Google® Search If you click the thumbnail to the left, you will see Google®’s results are surprisingly good, featuring content from Alberta’s Petroleum Registry and the ERCB.  But it also includes some information from the Texas Railroad Commission* website, which is not surprising, because there were no geographic criteria specified in the search.  In other words, Google® is providing a good, high-level overview of information available throughout the known universe.  But clearly, some refinement of the search criteria is going to be necessary to actually get to the page or two of information of specific interest.

ERCB Search Let’s assume  the knowledge gained from the Google® search above is used to determine that the ERCB website is the one which is of interest.  You go to that site, and input the "multiwell proration" search criteria into the Search box at the upper right.  If you click the thumbnail, you will see the results are much closer to the intended target.  In fact, the specific document containing the information — Directive 17 — is just the fourth hit down.  This is great, with just one, fairly significant drawback.  When you click on the link, it downloads a 243 page PDF.  It’s now up to you to go through that document to find your information.

Onramp Search  Finally, let’s assume you use Intellog’s Onramp search engine, and you input the same criteria as you did with the previous two methods.   The first hit is page 141 of Directive 17.  Not only has Onramp found the document for which you are looking, but it has also used PageIndex to rank the pages within that document in order of their relevance.  With a little luck, the specific information for which you are looking will be contained in first page you read.  Which means, of course, there were 242 pages you didn’t have to read…242 reasons why Onramp is a more efficient search!

It’s important to note that this comparison is in no way intended to disparage the first two search methodologies, but rather to highlight Onramp’s specific strengths; content which is tailored to the energy industry it is intended to serve, and secondly, the use of PageIndex to provide indexing of documents right down to the individual page level. 

Please feel free to provide comments below, or if you have your own case studies, don’t hesitate to provide some details so we can publish them in the future.

*The TRRC has responsibility for oil & gas development in the state of Texas.

Onramp is Intellog’s next generation search engine — like Google® and Yahoo®, Onramp makes finding information easy; enter a few search terms to identify the target of your search and the information meeting your criteria is displayed. But Onramp improves on the state-of-the-art in two important ways; it tailors the tools and content to specific industries, and Onramp is capable of indexing information right down to the individual page.

Initially focused on the energy industry, and in particular, petroleum production in the Western Sedimentary Basin, Intellog has indexed the full text of every ERCB Directive so you can find the specific page of interest, without having to read unrelated material.   In addition, Intellog has indexed the full text of the ERCB’s Well Licenses Issued (ST1), Drilling Activity (ST49), and Pipeline Approval & Disposition Daily List (ST96) reports for the past eight years — nearly 9000 documents and growing daily. And new content is being added all the time.

Onramp can also be seamlessly integrated into your corporate website, enabling its powerful search engine to enhance your site’s brand and capabilities. Your own documents can be indexed with Onramp, and set up for secure inhouse or public access.  Learn more…

Ready to hit the Onramp? Click here, or if you need more information or have any questions, please contact us.

Working through  the final round of testing the new beta release of Onramp on no less than five browsers (Safari, Firefox, Internet Explorer, Chrome and Opera), I came up against what appears to be an intractable saw-off between IE and Opera.  It relates to the way the content panel* is being controlled with a related CSS file.  Without going into all the gory details (they’ve be more than enough time for that later), I’ve found the multiple CSS files I have been using to this point were persistently getting tangled up.  A change in one precipitates unexpected consequences elsewhere, and similar difficulties. 

The primary cause of this problem related to the original vision for a series of ’snippet’ CSS files containing just the CSS relevant to a particular object on the page.  It seemed logical, at the time — the directory listing could be used to localize on a particular block of CSS.  However, the perceived advantage of this approach was outweighed by the negatives.  As a result, these files have been steadily merged together back together, and it’s now time to merge the last two remaining CSS files, Intellog.css and layout.css.  Henceforth, the pattern of CSS usage will be as follows;

[siteRoot]/css/Intellog.css  Contains all of the CSS which is shared by the entire suite of Intellog applications, whereas…

[siteRoot]/[appRoot]/css/[appRoot].css  contains the CSS which is relevant to a particular application. 

Using the Onramp application, for example, the formatting for the result table produced by outputSearchResult.php can be found in /Onramp/css/Onramp.css.  Pretty much everything else is in /css/Intellog.css, because it is common to all applications.

It’s anticipated other, third-party CSS files will be added in the future, and these should be placed in whichever directory is most relevant.  CSS relating to  Onramp application would go into /Onramp/css, whereas CSS relating to Roundabout would go into /Roundabout/css.  CSS relating to both applications would go into /css.

*This is the area of the user interface lying between the header and footer bar.

ApplicationConfiguration.xml has been described previously as the repository of all information related the configuration of the Intellog base application, as well as the configuration of Onramp and Roundabout.  Within those three files, lnk is the standardized element used to represent a logical link to other content.  It consists of one or more of the following elements (presented in alphabetical order).

• dsc  A brief description of the lnk, for internal, technical purposes.  The content of this element should not normally be exposed to the end user, as it likely contains technical jargon.
• helpXhtml  The help text which is associated with the lnk.  This element should contain valid XHTML as you would expect to find in between the <BODY> tags of a complete document.
• imageUrlTxt The URL of the image to be displayed instead of the lbl or screenLbl.
• javascriptTxt  The text of the JavaScript which will be executed when the lnk is clicked.  This element is mutually exclusive with txt, described below.
• lbl  The unique identification of the lnk.  This is a mandatory field, and will also serve as the onscreen representation of the lnk, in the absence of screenLbl, described below.  Camel case is recommended, and spaces and other punctuation are to be avoided.
• screenLbl  What is displayed on the screen to represent the lnk.  If this field is not populated, then lbl is used in its place.  Spaces and punctuation are acceptable.
• seq  The sequence of the <lnk> element when it appears within a collection of similar lnk elements, such as would be found in the breadCrumbWkflw.
• tipTxt  The text tip which is automatically displayed when the user hovers the mouse over the lnk.
• txt  The text of the hyperlink — in other words, what ends up associated with the href attribute for the finished link.  This element is mutually exclusive with javascriptTxt, described above.

Actually, it is more accurate to say lnk will be the standardized element in ApplicationDefinition.xml used to represent a link to other content.  In other words, this post documents the desired future state of this element.  There are currently a variety of inconsistencies in its use, as well as considerable overlap with the btn element.  This post serves as a reference which will govern the revision of existing code so it complies with the standard, as well as a guide for new code development.

Getting the drop-down menu button functionality working was based on a <table> element which implements the main menu, and additional <table> elements for each of the submenus.   This collection of tables are all associated with the bstp class.  The main menu can further be identified with the mainBstp class, whereas is of the submenus can be identified with the subBstp class.  This structure was then enriched though the  implementation of four types of events, described below, which are located in the Intellog.js JavaScript library; 

• onMouseOverMenuBtn(obj, menuLbl)  This function is called as the user moves the mouse over any menu button, regardless of whether it’s the main menu or the drop-down submenu.  It first sets the class of the triggering object (obj) to selectedBtn, changing the appearance of the button to the selected state, as governed by the Intellog.css CSS.  Then getObj(lbl) function is called, using menuLbl as the argument, which returns the <table> for the submenu object, or null if no such table exists.  This menu object is then positioned on the browser window down and to the right of obj.  The style of display is changed to block, from its default of none, making the submenu appear.  Finally, this function finds all of the submenus other than the one identified by menuLbl, and sets their display style to none, making them disappear.
• onMouseOutMenuBtn(obj)  When the user moves the mouse from outside the perimeter of a button, this function is called.  All it does is set the className to an empty string, which changes the buttons appearance back to its normal, unselected state, once again governed by the Intellog.css CSS.  It’s not necessary to hide a submenu associated with this button, because that is taken care of by onMouseOverMenuBtn described above.
• onMouseOverMenuHeaderTcm()  If the user moves the mouse from one menu button to another in a left-right motion, the onMouseOverMenuBtn looks after making the selected submenu appear, and the others disappear.  If, however, the user moves the mouse out the ‘top’ of the button, heading ‘north’ toward the top of the screen, onMouseOverMenuBtn never gets triggered.  To handle this one situation, a single <td> element,  identified as menuHeaderTcm, and spanning all of the buttons with the colspan attribute, triggers this function.  The function then finds all of the submenus and ensures they are all hidden.  The Intellog.css CSS ensures menuHeaderTcm is not visible, as its only role is to act as an an anchor for the logic implemented by this function.
• onMouseOutSubBstp(e, obj)  This function makes a submenu disappear when the user leaves the submenu’s perimeter.  Initially, it was thought this event could be triggered with the onmouseout event associated with the <table> element which implements the submenu.  However, onmouseout seems to fire whenever a user leaves any <td> in the table, in addition to leaving the <table> itself*.  Therefore, the implementation of the function is a hack; when it’s fired, the function climbs up through the ancestry of the triggering object. If it finds a <table> of the class subBstp in its lineage, it’s deduced the mouse is simply being moved from one <td> element of the submenu to another.  If, however, the ancestry terminates at either a <body> or <html> element without first having encountered <table> of class subBstp, it’s deduced the move was to the outside of the containing <table> element.  Fudgy, but it works.  Unfortunately, there are also some cross-browser issues which have to be solved with some nest try...catch blocks.

The naming standard for these functions is likely self-evident –  it consists of the event name, followed by the name of the object with which the event is associated, and as usual, object names are presented in camel case.  This more-or-less follows the pattern of verb followed by noun adopted for most logic objects.

Code Shavings  Turns out that the specification for XHTML specifies all markup is in lower case.  Henceforth, therefore, all references to XHTML mark up in this blog will appear in lower case, and more often than not, with the < (less than)  and > (greater than) characters surrounding them to make them stand out a little.  ♦  One thing to watch out for is spurious punctuation in a CSS file.  It seems like four out of five browsers cheerfully handle it, while the exception — Internet Explorer, of course — chokes on it.  For example, I had one stray, trailing apostrophe in one line in Intellog.css, and IE ignored everything after it!  ♦  The PHP function getMenuDiv was renamed to getMainBstp, which seems to be more in keeping the naming of related objects.

*It’s not clear whether this is buggy implementation, or my own profound lack of understanding of event bubbling.

Each Intellog application page contains at least one menu — the main one, located on the header bar — and quite possibly a second one on the footer bar, referred to in previous posts as the application action buttons (AAB).  The main menu is more-or-less constant across an entire application suite, whereas the AAB are specific to a particular page.

All menu definition information is stored /xml/ApplicationDefinition.xml.  The main menu definition is stored in the /ApplicationDefinition/bstp¹ element, and AAB definitions are stored in the /ApplicationDefinition/phpPg/applicationActionBstp element for each application page.  In turn, these elements contain one btn¹ element for each button on the menu, and each btn element contains at least some of the following;

• dsc – a description of the button for documentation purposes.  This most likely contains technical notes about the button, and it’s assumed text for this element never gets presented on an external user interface.  So let the expletives (and technical jargon) fly!
• javascriptTxt — the text of JavaScript to be invoked when the menu button is clicked.
• lbl — a unique-in-context² identification of the button.  This is a mandatory element, and by convention, the content ends with the suffix -btn.  For example; homeBtn, productBtn etc.   Camel case should also be used.
• lnk³ — the information about the hyperlink to be invoked when the menu button is clicked.  It contains the txt element, which contains the full text of the hyperlink.  Note: javascriptTxt and lnk are generally mutually exclusive — you either want to follow a link, or invoke some programmed logic, but not both.
• screenLbl — In the event lbl is not suitable for presentation to the user, screenLbl is presented in its place.  In the event screenLbl is not populated, the default is to present lbl.
• seq — an integer which determines the sequence of the button with the bstp element.  0 would be the left-most or top-most once the buttons are rendered onto the screen.
• tipTxt — the short description of the buttons functionality which will appear when the cursor is hovered over the button.

Once the menu is defined as described above, it then becomes a matter of using XSLT to extract the definition and turn into XHTML, absent any style information.  For the main menu, this is accomplished with menuDiv.xsl.  Style information is provided by a related CSS, which in all likelihood will be Intellog.css.  This is where all the brand-specific styling is being migrated.

¹bstp and btn are frequently-used, standard abbreviations for the terms button strip and button.

²That is, unique within the element in which it is contained.

³Currently, there is a slight difference between the main and the application-specific menu definitions with respect to this element.  In the case of the main menu, it’s as shown above, but in the case of the application action menu, it’s still implemented as linkTxt.  The latter will be migrated to the former over time.