Some thoughts on designing apps for standard browser AND native Electron-based "browser apps"

In case you missed it, monday.com has a native app for iOS and some “native” Electron-based apps for desktop computers.

For iOS (and probably Android), the user experience for app developers is simple. Apps are not supported, go to a desktop browser :cry:.

For the Electron-based apps, the behaviour is subtly different from actual real browsers.

2 important places where Electron-based different are:

  • There is no access to window.open, or rather it just fails
  • You cannot open links in new tabs, e.g. <a target="_blank" ... will fail silently, so be prepared.
    • Actually, as @kolaai points out in the comments, you can and should always be using openLinkInTab:
    monday.execute("openLinkInTab", { url: "https://google.com" });
    

If you build your app without these considerations, be prepared to have additional support requirements from you customers that may not be simply to troubleshoot quickly if you don’t ask the right questions.

If you are opening links with window.open in a desktop app, then perhaps you need to rethink this strategy for Electron-based apps and adapt.

What follows are a couple of approaches and when you might use them.

1. Hide elements that are not appropriate for Electron-based apps

An easy way to do this is to check for Electron and then hide content that’s not appropriate from the electron-based app.

An example of how to do this in Svelte (but you get the idea):

<script>
  const isElectron = window.navigator.userAgent.indexOf(' Electron/') !== -1;
</script>

<div>
  {#if !isElectron}
    <div>...</div>
  {/if}
</div>

This approach could lead to the following menu items…

On desktop browser:

On Electron-based app:

Screenshot 2024-04-02 at 08.39.40

2. Let things fail, gracefully

If your app contains OAuth with an external service, then you probably want the Electron-based app to see the “Sign in” button (which should open a new window)…

…but then display a message when window.open fails.

This message also allows for popup blockers, so is a double win.

Allowing the end-user to attempt to sign in on the Electron-based app lets them see where the authentication action should be, so that they can repeat it on a desktop browser.

This is a reinforcement pattern. Let them fail, but then let them try again elsewhere.

If the sign in button was missing from the Electron-based app, it would be more confusion, so we keep it in place.

In this case, our Svelte code would look similar to this:

<script>
	let popupBlocked = false;
	
	function onClick() {
		const popup = window.open(
			`/oauth2/authorize?sessionToken=${...}`,
			'myPopup',
			'popup=1,width=480,height=650'
		);

		if (!popup) {
			popupBlocked = true;
		}
	}
</script>

<button type="button" on:click={onClick}>
	Sign In
</button>

{#if popupBlocked}
	<div>
		<p>Sorry! You cannot sign in to Xxxx in this browser,/p>
		<p>Please allow popups, or sign in on a desktop browser and then reload this page.</p>
	</div>
{/if}

This is not an exhaustive list, but a starting point on developing for both browser and Electron-based apps.

:pray: Please share any similar findings as a comment.

Concerning opening links in a new tab, why not use the function that monday provides?

monday.execute("openLinkInTab", { url: "https://google.com" });
1 Like

@kolaai Ooh, excellent, I’d actually forgotten about that. :woman_facepalming:

Updated accordingly.

1 Like