Change Launch External Website messaging

[paula.clark]

Hi,

Is there a way to change what the messaging says when the user clicks on a button that Lanches an external URL or phone number?

[stevesanerd]

Are you talking about the sub symbol buttons in zapworks?

Steve

[connell]

Hi @paula.clark!

Do you mean during a WebAR experience? If so there currently isn’t a way but we’d love to hear the sort of things you might want to say in this dialog

Cheers,
Connell

[paula.clark]

@connell Yes in WebAR when you redirect to a URL or phone number, this message pops up:

I have it going to a USSD code and some devices ask what program you want to open with. Was thinking it could rather say something about it dailing a number or something else that would make the user realise to open a keypad and not a browser.

[ashlee.lfw]

Hi, is there currently a solution to this? Would love to be able to change ‘Launch External Website’ to custom text such as ‘Add Event to Calendar’ etc.

[nadia]

A year later, still wondering the same thing. @paula.clark @ashlee.lfw did you manage it?

[howiemnet]

This is an interesting problem. I can understand the logic behind requesting confirmation from the user before jumping to another website, but I don’t think it’s necessary. It feels old fashioned and a little overprotective.

From my [client’s] point of view, it’s additional friction that we just don’t want: if a user has tapped on our call to action button - “Buy now!” - we just want them to be taken to the URL without any additional confirmation, in the same way they would if they clicked a button on an ordinary web page.

The OSes, Android and Safari, have their own safeguards to ensure a clicked link, a jump to a URL (which could be a mailto: or a phone: link too), won’t perform a dangerous action.

I suspect that at some point there may have been concern that “the user is on a Zap branded experience, so we need to be clear they’re leaving our domain, and what follows is out of our [Zap’s] control” - hence this confirmation box. It’s a Zap policy rather than something required by the OS, though.

It does feel overprotective and unnecessary. I’d vote to make this confirmation dialog an option we can switch off. WebAR is web. WebAR links should act like any other web link a user may encounter.

There are good reasons a Zap developer may want to seek confirmation before leaving the AR experience – make sure it wasn’t an inadvertent tap – but that should be up to the individual developer.

Ideally, then:

• confirmation dialog should be an option
• if the confirmation dialog is enabled, we should be able to customise the text

just my 2 cents ¯\(ツ)/¯

[howiemnet]

Need to bump this. That “Open external link” confirmation dialog is an unnecessary point of friction and needs to be removed, or at the very least, made an option.

It breaks our AR experience (we’re syncing stuff to audio, and if you tap a link but then cancel, the audio sync gets broken. I may be able to work round it, but that’s not the point).

It’s something other apps / web experiences don’t do. It looks wrong, and it’s overprotective to the point of being annoying. It’s likely to have an impact on our conversion rates - not because we’re tricking people into going to a page they wouldn’t want to visit (after all, they can hit “Back” in their browser if they want) - but because it presents the user with an unnecessary question they have to think about.

Mostly it just seems nanny-ish.

But also it’s an ugly and uninformative dialog.

Please remove it - or give us the option to turn it off.

(rant over) ; )

[George]

Hey Howard!

Some great points there indeed. Let me chat to the team and see if there’s a technical reason behind why we have this modal appear.

I’ll also see if it’s feasible to have the option to remove it.

I’ll note the response on this thread.

George

[marks]

I know the reason the modal exists, although it’s a bit technical, so bear with me. Behind the scenes, Zappar must use the available web apis to do anything. Specifically, to open a new tab/window it likely uses window.open.

So what? The thing is, to use window.open, it requires a user gesture. For example, a click. If there is no click, window.open is blocked.

Now you might be thinking, “but I use launchURL after the user taps on a button!”. Right. The problem is, the click that you use in Zappar does not reach the DOM where the application resides. Your code in Zapworks Studio resides in a sandboxed iframe, and you can’t communicate with the parent. I know, because I’ve tried. This is very likely for security reasons. For the DOM, the click never happened.

Since your click never reaches the DOM directly, Zappar implemented the modal, that actually communicates with the DOM for the sole purpose of opening a new tab.

So long as the app resides in a sandboxed iframe for isolation and security, to disallow users to potentially do nasty stuff, and also to constrain the user to only use Zapworks’ api, the modal is necessary.

Ideally, Zappar could at least relax some restrictions on the sandbox. Using allow-top-navigation, or allow-popups. With this you’d be able to open a URL without the modal, by talking with the DOM directly. Not sure about the security implications though.

Then you’d be able to have code like this in Studio:

declare const document; //document and window exists but Zapworks thinks not, so the declare const is necessary
declare const window;

symbol.nodes.Plane.on("pointerdown", (e) => {//call on pointerdown so the click reaches the document on pointerup
	document.documentElement.addEventListener('pointerup', function () {
        window.open("www.google.com");
    }, { once: true });
});

[howiemnet]

Thanks for that @marks — that’s fascinating. Explains the background really well.

It does still leave us with the top level problem of how to deal with it.

I suppose the first step is to identify what the potential security issues could be. The sandbox disallowing users from potentially doing nasty stuff - what kind of nasty stuff would actually be possible? The pipeline from authoring tool to delivery is pretty tightly controlled by Zap. Can you think of any examples of things the sandbox is protecting visitors from?

@George - if you can ask your devs to look into this, that’d be super. The thing I need to be able to handle is the argument that “other websites / online 3D experiences don’t seem to need this, so why have you chosen an AR system that does?”. I’ve done a fair bit of work getting to know Zap’s solution, so I really don’t want to have to throw all that learning away — but it’s hard for me to argue with the business-needs / friction / conversion rate stuff, as ultimately that’s what keeps me fed.

[marks]

I suppose the first step is to identify what the potential security issues could be. The sandbox disallowing users from potentially doing nasty stuff - what kind of nasty stuff would actually be possible? The pipeline from authoring tool to delivery is pretty tightly controlled by Zap. Can you think of any examples of things the sandbox is protecting visitors from?

I don’t actually know of potential security issues. I do know that the sandbox exists for this reason, and also isolation. It could be that Zappar just wants the sandbox for the isolation aspect. They might not want us to have access to the web apis ourselves, and only let Studio handle it.

They have UniversalAR if what Studio offers isn’t enough. You can do what you want using UAR. Although I do understand your point of view of having to forget about Zapworks Studio and having to learn UAR + another framework. This happened to me very recently. If I had access to the web apis myself, I wouldn’t have needed to move to UAR. In the end, it could be their goal to deprecate Studio in the long term and only support UAR for its flexibility. In this case, allowing more flexibility for Studio wouldn’t make sense. But I hope I’m wrong since I love Studio and find it much easier to work with.

[howiemnet]

Yep. It could be that the sandbox is there to protect the browser from issues with Zap itself. I’ve managed to get multiple image-tracking to work, but it’s … a little memory-leaky — probably my fault, this ain’t my usual department — but I can certainly crash my phone with ease. Zap have that tricky balance to maintain of giving us enough power to satisfy us while also limiting the fallout when an idiot (me) is allowed to play with it.

Right now we’re just testing the waters with AR, so we have that other tricky balance of trying to invest just enough time/effort into this first project to give us a genuine feel for its potential business case, without just doing something half-arsed and not really giving AR a genuine chance.

I do see PlayCanvas as a next step after Zap Studio, though; means I can carry on using Zap’s tracking, which seems to be pretty good, but it’ll relieve some of the irritations with the Studio as an IDE. Because it’s a pretty crazy IDE. So many peculiar quirks and weirdnesses, so many holes; but at the same time, its lowered the barrier to entry to a level I’ve been able to accomplish way more than I would have done without it.

Have to be careful that while moaning I don’t give the impression that I’m not blown away with what Zap have accomplished with WebAR and Studio. I am. Tbh that’s the reason I moan - if Zap was awful there’d be no point

[marks]

I do see PlayCanvas as a next step after Zap Studio, though; means I can carry on using Zap’s tracking, which seems to be pretty good, but it’ll relieve some of the irritations with the Studio as an IDE. Because it’s a pretty crazy IDE. So many peculiar quirks and weirdnesses, so many holes; but at the same time, its lowered the barrier to entry to a level I’ve been able to accomplish way more than I would have done without it.

Yep learning PlayCanvas at the moment. It’s a great IDE. It’s basically Unity for the Web. Once it has timeline support, bezier curves, and constraints, I think it will be on par with Zapworks Studio and be a worthy replacement. Unity technically is a great replacement for Studio in terms of functionality, but I don’t use it because my clients won’t allow it. It’s too heavy, takes too long to load and lags on older phones, and consumes too much memory.

PlayCanvas offers almost all of the flexibility Studio offers with none of the constraints.

[connell]

Hi both!

Thanks for your excellent analysis @marks and great discussion @howiemnet .

You’re right that we need a user gesture event in order to use window.open - without that the browsers block the request to open a new tab unfortunately. It’s not quite due to the sandbox however - the reason is that when the user taps on the 3D view (where we render the content) the events are placed in a queue that’s handled during our render loop. This is relatively standard practice for a 3D engine, but obviously not for the web. It means that when the taps are eventually processed, we’re no longer in a ‘user gesture event’ and so any actions we take that require one would fail at this point. Hence the popup .

That said we have two potential ways forward:

• We have an experimental new API for a ‘web frame’. It lets you open up a web page in an iframe, keeping the user on the AR site, and provides an X button for the user to use to return to the AR experience. I believe it’s available at the lite branded site and beta.zappar.app for the moment. You can use it in an experience like this:

(Z.device as any).launchWebFrame("https://[site]", res => {
	console.log("The user has closed the frame");
});

• We could look at providing an option that bypasses the popup but navigates the whole page to the URL (rather than opening in a new tab). I don’t think we have this at the moment but it’s defintiely plausible to implement.

Let me know your thoughts!

[howiemnet]

That pop-up web-frame is intriguing. Interestingly, I’d had it left open for a while just now; just a few minutes, and then hit the “x” to close it, and the browser asked for camera access again (!) (iOS 15.2b3). I’ll test it with our ticketing platform, though realistically once a user has decided to express an interest and tap through, we don’t really want to leave them with the AR experience running in the background.

Hmmm. I wonder what happens if that URL contains a redirect.

The second option you mention, though, that’s really the thing we need. Just a way to take the visitor to our tickets site. No need for it to be a new tab; the AR experience needs to act as much like a normal webpage - you click a link and it just takes you to the place. Don’t want to litter the visitor’s browser with extra tabs.

Thanks for looking at this, @connell - ultimately providing the best visitor experience is key to success; we obviously don’t want to arbitrarily try and bypass the things Zap and the browser do to protect the user. I for one am extremely grateful that my browser stops sites popping up extra tabs or windows willy-nilly

If there is a way to bypass the popup and direct the browser straight to a URL, in that same tab the AR experience was in, that’d be grand. Perfect UX.

---

Tbh - and kinda thinking out loud here - even a “tap anywhere on the frame to go to a URL” approach would work for us; we need zero user input/interactivity beyond some way for them to say they’re interested in our offering. So if there could be a way to set an option in our AR project - 'full screen override, treat any tap anywhere as a web link" - as long as we can script the destination URL (which in our case we derive from the queryString).

It may seem like a sledgehammer approach, but if it bypasses the technical difficulties, it’d solve the problem, at least for us. And it needn’t present as an unexpected behaviour to the visitor if we state it - “Tap anywhere to buy tickets!”. Bottom line is it’s our name/brand on the screen, not yours - so it’d be in our interest to make sure the user’s experience was a positive one. Everyone wins!

[howiemnet]

Gosh, I’ve just re-read what you said - without the user gesture event, the browser blocks new tabs from opening. I hadn’t even noticed that that was what was happening.

We don’t need nor want a new tab - we want the experience to end, and to take the visitor to the next thing. Don’t want to litter the browser. They can always click “back” if they want to - the more the AR experience acts like any other well-behaved webpage - albeit 3D and shiny - the better.

I can understand some AR experiences wanting to let you pop a new tab up for things, with the idea that you’d return to the experience later, but I’d be willing to bet they’re in the minority: surely most AR experiences are considered finished/complete once they send you off to another webpage.

Maybe we should have a vote. All in favour of defaulting to using the same tab for AR links?

<-- there’s mine ; )

[marks]

@connell

We have an experimental new API for a ‘web frame’.

I like this, very cool.

We could look at providing an option that bypasses the popup but navigates the whole page to the URL (rather than opening in a new tab). I don’t think we have this at the moment but it’s defintiely plausible to implement.

Another good option. But I never had a client ask me this. They always want a new tab, not to exit the ar experience to open another page.

It’s not quite due to the sandbox however - the reason is that when the user taps on the 3D view (where we render the content) the events are placed in a queue that’s handled during our render loop.

Interesting to know. However the sandbox does prevent me from doing stuff that I’d be able to normally.

I use the kind of code below to communicate Unity with a WebGL plugin. I can’t do the same with Zapworks Studio because I get an iframe sandbox error. Do you think you could lift some restrictions on the sandbox to allow the programmers to access the underlying web apis? With this I’d be able to access the gyroscope, accelerometer, etc. It’d give a bit more power to us.

declare const document; //document and window exists but Zapworks thinks not, so the declare const is necessary
declare const window;

symbol.nodes.Plane.on("pointerdown", (e) => {//call on pointerdown so the click reaches the document on pointerup
	document.documentElement.addEventListener('pointerup', function () {
        window.open("www.google.com");
    }, { once: true });
});

[stevesanerd]

WOW!! Love this @connell
So testing the code on beta.zappar.app with Zappar.com as the site I get a error of www.zappar.ceom refused to connect.
I know it’s experimental but I would love to play more with it. I have big plans for it!!

Steve

[howiemnet]

Another good option. But I never had a client ask me this. They always want a new tab, not to exit the ar experience to open another page.

Ahh. It’s going to be use-case dependent, of course. (Look at me, only thinking about my needs… ) So the best option would probably be to keep launchURL() defaulting to current behaviour, but add an option to bypass the modal dialog and re-use the current tab for those AR experiences it makes sense for.

@stevesanerd - the popup iframe worked perfectly here, loading the target site in a closeable frame over the top of the AR thing - I wonder what went wrong. It’s not what we need for our experience right now, but I can see it being a really valuable feature.