Best practices for building a Front plugin

Update:This is a guest post by Meetingbird Co-founder Paul Dornier. Front acquired Meetingbird in October 2018! Read more on the acquisition in Business Insider, and on the Front Blog. Now, you can access calendar functionality directly in Front with Front Calendar! Learn more in our Help Center.

At Meetingbird, we recently launched a free plugin for Front that allows users to manage their calendar from their inbox. With the plugin, users can add events to their calendar, insert potential meeting times into email replies, and access scheduling links, all without ever leaving Front. Great development flexibility, a strong API for interacting with email threads, and a passionate and growing customer base made Front a uniquely exciting platform to build upon. Along the way, we’ve learned a few best practices that I’ll share in this post.

1. Take advantage of the unique view dimensions

The default width of Front’s plugin sidebar is 300 pixels. Its height varies with the window height, although it generally exceeds 550 pixels. Given these dimensions, many of the tenets of good mobile app design apply to Front plugin design. For example, if your app provides multiple functions or has multiple views, consider using a tab bar or “full-screen” navigation.

If you elect to use a tab bar, be sure to break with the mobile convention and place your tab bar at the top instead of the bottom. Front’s most common actions are consistently found in the top of the app, so you risk confusing users by placing crucial navigation content in the bottom right corner of their Front window.

We elected to use full-screen navigation because the large view height allows us to list the actions that users can take along with some instructive text for each one.

With full-screen navigation, the plugin home screen provides a clear starting point for any task a user is looking to accomplish.

2. Use popups for complex views

One of the challenges we anticipated in building a Front plugin was incorporating some of the larger, more complex views of our web app into the small screen real estate of a plugin. In particular, it was clear that it wouldn’t be possible to replicate our wide calendar view within the plugin sidebar.

Fortunately, Front Plugins are simply web applications rendered within an iFrame, so methods like window.open are at your disposal. A single line of Javascript is all we need to open a popup to display wider content (notice that you can set the dimensions of the popup window):

var popup = window.open(’example.com/popup_content’, ’example’, ’height=600,width=1000’);

In the Meetingbird plugin, popups are used to allow a user to suggest potential meeting times.

Here, the plugin sidebar provides the starting point for the action, the popup allows the user to perform a task that wouldn’t be possible in the sidebar. A return to the sidebar allows the user to continue that task within the context of the email thread.

3. Use WebSockets to create a seamless login flow

For apps that require authentication, the initial login or signup flow is crucial. Users should be able to log in or sign up for your application without ever leaving Front. If your product uses simple username + password authentication, you won’t have any trouble replicating that in a plugin, but if your app uses third party authentication (Google, Office 365, Stripe, etc.), a more creative solution is required. You won’t be able to simply redirect users to the third party authentication page because providers refuse to render login pages within an iFrame for security reasons. A combination of WebSockets and popups provides a good workaround, as outlined by the following login flow:

1 If a user is not logged in, then login and signup buttons are displayed.

2 When the user clicks to log in or sign up:

• A unique identifier is created for the current plugin client

• The plugin subscribes to WebSocket updates with that identifier

• The third party authentication url is opened in a popup, and the identifier is included as a url parameter in the callback URL

3 After the user signs in via Google, Office 365, etc., the endpoint that handles the redirect URL broadcasts a “login confirmation” message to the client using the unique identifier and displays a login confirmation message to the user.

4 Upon receiving a login confirmation message, the plugin fetches the user’s account data. The user is now logged in.

This implementation is more complex than what you might implement in a standard web application, but the payoff is a truly seamless onboarding experience for users of your plugin.

4. Use “panel_visible” and WebSockets to keep data up to date

Front’s desktop app and offline reliability make it an application that users keep open for days or weeks at a time, so your plugin should perform well in the event that it isn’t manually refreshed often. Front’s Plugin API provides a helpful event listener called “panel_visible” that’s triggered when the visibility of your plugin changes (for example, when a user collapses or expands the plugin sidebar). This event provides a great opportunity to check if the plugin’s state is stale and to retrieve updated data if necessary:

Front.on(’panel_visible’, (visible) => { // If the plugin is now visible and user data is stale, fetch data if (visible && stale) { FetchUserData(); } });

For full real-time functionality, consider using WebSockets. Since plugins are web applications rendered in an iFrame, we had no issues using the WebSocket structure of our full web app in our plugin.

Final Thoughts

Design for a narrow space, make use of popups, get creative with third party authentication, and make sure your data stays up to date. Those are the top things to keep in mind when creating a Front plugin that delights users. We’re excited to see Front’s developer platform continue to grow.

This header image comes thanks to our friends at Proxyclick.