Expelliarmus
GRAVITY has been developed to reduce enterprise learning costs and lower the impact of application updates. To ensure this GRAVITY detects if learning content and application are not in sync. If this is detected, a notification is automatically sent to the application owner. The owner can then update the learning content to reflect the updated application. This ensures that the learning content and documentation is always up-to-date.
Technically this is achieved by analyzing the DOM tree of a web application. With more complex applications simple, static comparison of the DOM tree are not sufficient. To ensure best results, we have developed an algorithm which uses various elements to track and monitor the DOM tree of a web application.
Our "discovery" algorithm has five steps to detect changes:
- Exact selector match (example: #container > table.main > tr:eq(2) > td.first:eq(1) > div.name:contains('New')). This approach gives us 100% accuracy in defining the element, but is vulnerable to any kind of changes in content and DOM structure. Works fine in most cases, but is not suitable for elements, that differ with each user.
- Selector without element's text information (example: #container > table.main > tr:eq(2) > td.first:eq(1) > div.name). Gives high accuracy of selection and can handle localization, but is still vulnurable to DOM structure changes. It also can give false-Positive in case elements order changes, eg. items being reordered in a menu.
- Selector without the element with defined ID or BODY element (example: table.main > tr:eq(2) > td.first:eq(1) > div.name:contains('New')). Gives high accuracy of selection and can handle situations, when the ID of the element is changed, but the DOM structure inside is the same. Can give false-positives on the sites with the same DOM blocks structure.
- Selector without indexes (example: #container > table.main > tr > td.first > div.name:contains('New')). Gives medium accuracy. Can handle situations, when the order or number of the elements inside the DOM is changed, but the elements themselves are still there. Can give false-positives on similar DOM structure.
- EXPERIMENTAL Cutting the selector from the left side (example: tr:eq(2) > td.first:eq(1) > div.name:contains('New')). Gives low accuracy. Can handle most DOM changes, but has the risk of false-positives increasing with each step of cutting.
Aparecium - no hotspot is ever hidden!
Hotspots never disappear. If they cannot be assigned to an element, our "hotspot collector" reclaims and displays those hotspots. In moste cases we can automatically rebind a hotspot to an application, this table lays out (in DOM mode) where this is the case:
Case | Can we rebind the content |
---|---|
DOM element class name changed | No, element.className is our primary handle, if it changes, we can never find the element again (see div.name above) |
DOM element's parent class name changed | Yes |
Text of a button changed from "New" to "Create" | Yes (see finding step 2) |
Position of a button changed inside his parent container | No, not yet, it may come with step 5 soon. |
Position of a button has changed abroad his parent container | Yes (see finding step 3) |
Text and class name of a button changed | Still no, element.className is vital |
Position in a list of links changed | Yes (see step 4) |
If hotspot elements cannot be easily assigned to an application, GRAVITY users can always fall back to our Hotspot Grid. This allows to layout hotspots independently of the DOM model.