When you are creating a Journey step, most of the times, it is just enough to select the target element graphically using the element picker. But sometimes, in order to make sure that the element is found, you need to fine-tune the element detection.
- the guidance does not appear on the screen although you see the target element on the screen so you need to soften the element detection criteria;
- the guidance appears on the screen bind to the element that you have not selected - so you need to harden the element detection criteria.
To adjust the detection criteria, open the "Detect element by" dialog by clicking on following icon:
From Newired 19.2, you can see the reliability of the element concerned inside the Selector precision bubble.
This will also help when you modify the parameters below, as the reliability will be updated according to the changes:
Please beware that the changes you define re immediately visible in the editor, but you need to press save in order for them to be applied.
Detect Element by
The target element is detected if all active filters are good enough to identify it. To improve it, you can select specific filters that are stable and trustworthy, and deselect the ones that might be constantly changing and therefore will not be reliable for the detection process. The score will dynamically increase/decrease as soon as you start tweaking the parameters.
The Element ID is usually the best reliable and robust criteria to search for an element.
When it is considered reliable, having only this criteria selected might be enough to find the element.
In the case the element ID is not reliable, its best to unselect it and use instead other filters to find the element. An example for this might be that on a site the ID's might be autogenerated, and this would make them change every time you load that page.
If only some specific element IDs are not reliable, you have the option to mark only those as not reliable so they are automatically ignored, from the site settings tab in the portal, as shown in the screenshot below.
This needs to be set up only once, to dramatically improve the effectiveness of your Selector.
Text filter is a good but weak filter. It detects the elements by the text you see on the screen. It is usually necessary to combine the filter with other filters to achieve reliable results.
Avoid using texts that might change over time, it's better to use something that will be most likely be always the same in your web-application.
In case your application has multiple languages, you can provide text filter translations so that every text will be found even with different application languages.
Depending on type of the element selected, you can filter by various attributes. The attributes that are usually reliable to be used as filters are automatically preselected.
If the guidance does not appear or appears in the wrong place, it often means you need to either uncheck some attributes, or check some additional attributes.
If you decide to strengthen a selection - please pay attention if the attributes such as “style”, “width”, and other graphic-related attributes are not dynamically derived from your screen size or environment, such as operating system or browser. In such case, the target element would not be detected properly in different environments.
From 19.2, concerning the element attributes, when an element has multiple classes, you can choose to rely just on specific ones. For more details on Class, please check this Article.
From 19.3, more technical settings are separated from the other and visible just if the Advanced toggle is enabled. These features are XPath and CSS Selector.
The XPath criteria is by default inactive because it is a quite fragile filter. Very often the element will not be detected well due to minor changes to the page structure. Activate it only if you understand the XPath standard and the impact the filter has on the detection algorithm.
What changes to the page do we speak about?
It can be the structure changes to the page because the content / data are structurally diverse. Example: Imagine an e-shop page where you have an additional panel for business customers. In such cases, if the page structure is dynamic, the XPath selector may not find the element.
Another example: it may happen that you still maintain / improve your web application. So the page structure is changing based on the improvements you are doing to the application. This is another common reason to be cautious about activating this filter.
Important: Even if you keep the matcher inactive, we still record the XPath criteria and we use it to narrow the scope in case the active matchers will find multiple elements on the current page. But inactive criteria are not a must-have criteria.
The CSS Selector is by default inactive because it is a quite fragile filter as well. Very often, the element will not be detected well after there are minor changes to the page structure.
Activate it only if you understand the CSS Selector standard and the impact the filter has on the algorithm detection.
Important: Even if you keep the matcher inactive, we still record the CSS criteria and we use it to narrow the scope in case the active matchers will find multiple elements on the current page. But inactive criteria are not a must-have criteria. From 19.2, you can edit the CSS selector in some situations. For more details on the editable CSS Selector, click here.
Check this Article if you want to learn more about the Reliability of Page Elements.