Written by Jiri Walek, Gianluca Ippolito, Natalia Kawana
We’re always and constantly committed to our vision: to reduce the gap between people and the digital world. And to do so, we always implement improvements and novelties to our solutions!
Let’s now check what we’ve prepared for you in our newest release!
We have a new type of a step that you can place into Journeys. Introducing: Panel steps!
Panel steps are intended to give additional information about a specific page or process, without totally blocking the page (and therefore additional interactions) for the end users.
We have also renamed our other building blocks, lets review them together:
So now we have 3 of these powerful blocks to create even more adaptable Journeys and achieve the most tailored experience for your end-users.
Essentially, Panels are similar to dialog steps, as they do not connect to any element on the screen, but unlike dialogs, they don’t block users from interacting with the target application. The very typical use case is that you create a panel that tells the user what to do on a current screen, and users spend a couple of minutes processing these instructions, without being guided with more detailed instructions.
Example: I need to guide a tele-sales rep to go to CRM system and track a phone call
You can place Panels in any of the corners of your screen. To change its position, just drag&drop the panel to one of the quadrants.
A highlight of the area will indicate where the panel will move once you release it, as shown below:
You can set the panel size to one of the predefined sizes using the “Step Editor”, but we expect you need more granular controls. From 20.2, you can simply grab the border of the step and make it bigger/smaller by dragging it, giving it the size you wish.
When it comes to web applications, you need to handle URLs. The URL, colloquially termed a web address, is a reference to a web page that specifies its location on the internet or on a computer network.
For Digital Adoption Solutions, it is important to bring flexibility to support several scenarios:
If you toggle the “Relative URL” mode, all the navigation and checks that Newired is doing will be strictly skipping the actual domain.
To use the Relative URLs go to Newired Portal > Site > Settings > Site Settings:
Limitation:
Supposing you do not want to use the relative URLs (from the reason above), but you still want to deploy the Newired overlay on other URLs (i.e. a different URL compared to what you used in editor), you can now provide mapping information, i.e. to map the URLs used in editor to URLs used by Runtime.
In other words: you can use a different deployment snippet for your production target application and for the staging target application, where each snippet will tell Newired what the base URL is.
In case you do not know upfront the actual URLs (i.e. domains) where your application is running, this makes the deployment process a bit more complicated in case you use browser extensions as your deployment method.
By default, Newired Browser Extension will load the Newired overlay on the URLs that are defined on the Site Settings page – i.e. on the URLs you specify upfront.
Example: You want to load the Newired overlay any time a user opens a url that contains “.myapp.”. It loads the overlay if you open demo.myapp.com, or try.myapp.com, or customerx.myapp.com
In such case, you can enter such rule on the Extension Settings page:
As one of the most requested usability improvements, we have implemented this simple but useful news: you now do not need to login to Newired Editor every time you start it. It just remembers you …
In highly secure environments, you can disable this feature in case it does not meet your security standards.
Speaking about security standards: from now on, you can also define your Newired password complexity requirements, such as requesting a password with numbers, uppercase letters, special characters, etc.
Our Customer Success Manager will be happy to show them to you on a one-to-one session! Please book it here: