5

I am new to google products. I'm planning to start add on kind of stuff with in gmail. Is it better to go with Add on or chrome Gmail Extension similar to Add on? If it is add-on, can't we launch custom url directly in side Add-on? Is this in product pipeline? At present, we need to build entire UI for Add-on. I think, this is very difficult to maintain google custom UI.

Anil Reddy Ramini
  • 123
  • 1
  • 9

1 Answers1

11

It depends on your requirements, here are a few approaches:

  • Gmail Add-ons
  • InboxSDK
  • Gmail API

Gmail Add-ons

Allows you to:

  • Display additional information for the user in the Gmail UI.
  • Connect to non-Google services, to retrieve information or take other actions.
  • Provide an interactive interface to allow the user to control the add-on or send information to another service.
  • Use other built-in Apps Script services such as CalendarApp to retrieve information.

So you can access the logged-in user's data & easily make use of a user interface. These add-ons are made in Google App Script scripts and are compatible with the mobile Gmail app versions.

I listed some pro arguments above, now some (subjective) con's.

  • You are bound to their layout system, although you might be able to change colors etc.
  • For your add-on to activate, you must first open a message or compose view.
  • I think you cannot make use of JavaScript libraries/frameworks.

If the con's I mentioned are not applicable to your requirements, Gmail Add-ons is the better approach.

Read more here

InboxSDK

Allows you to create a (Chrome) extension that lets you:

  • Insert your own UI into Gmail or Inbox.
  • Interact with simple high level classes like ComposeView. You call straightforward methods (like adding buttons or getting the subject) on the class and the SDK abstracts the entire DOM away from you.
  • Use the tools needed to feel like a native part of Gmail and Inbox.
  • Register your extension as Gmail UI sidebar app.

In short, you can add elements, functionality etc. to your Gmail or Inbox UI and interact with its components. Its way more flexible in terms of lay-out, using JavaScript libraries/frameworks but the learning curve is slightly steeper. Also, your app/extension can run on every view, not only after opening a message or compose view.

Now some (subjective) con's:

  • Since it is mainly designed for interacting with the UI, the data you can access is limited. You can retrieve some thread, user or message ID's but that is where it stops.
  • It is harder to lay-out or style your extension of Gmail's standard apps like "Tasks", "Keep", ... When you are not working directly in Gmail's or Inbox's UI. When for example, you make a sidebar app.

The limited data access is a major issue for me but can be solved by using the Gmail API. Gmail Add-ons have sufficient access to the user's data.

Read more here

Gmail API

The information below is directly pasted from their guides section:

The Gmail API gives you flexible, RESTful access to the user's inbox, with a natural interface to Threads, Messages, Labels, Drafts, History, and. Settings.

  • Read messages from Gmail
  • Send email messages
  • Modify the labels applied to messages and threads
  • Search for specific messages and threads
  • Create filters to automatically label, forward, or archive messages

Typical use cases (also from docs):

  • Read-only mail extraction, indexing, and backup.
  • Label management (add/remove labels).
  • Automated or programmatic message sending.
  • Migrating email accounts from other providers.
  • Set standardized email signatures for users in a domain.

You can make use of this in custom applications and (Chrome) extensions but this does not cover any UI related functionality. Also, there is no need to use this when making a Gmail Add-on since it is already integrated.

Read more here

Conclusion

To answer your questions, go with the first option. It allows interaction with third party API's or your own custom API, it is compatible with the mobile app versions and UI building blocks are provided. I strongly recommend to check out Clasp for developing, maintaining, synchronizing your Google App Scripts and more!

Auguste Van Nieuwenhuyzen
  • 153
  • 6
  • Thanks Auguste Van Nieuwenhuyzen. Basically our product is kind of frame work in CRM. Our implementors need to have their changes in their applications. If we choose Gmail Addon, they need to build their UI using cards feature. It is very difficult to for them to implement. They might be reluctant to take. Our product is not scalable then. For option 2, with out inboxsdk, can we build plain custom chrome extension for gmail using Gmail APIS? Is InboxSDK google owned? or a third party licneced api? – Anil Reddy Ramini Jan 31 '19 at 14:33
  • InboxSDK is maintained by a third party but got Google's attention before they came with their own Gmail Add-ons. You can build a custom Chrome extension with the Gmail API alone, leveraging user data, mails, ... Only when you need to interact with or manipulate the Gmail's interface @ (https://mail.google.com/) you should consider the InboxSDK or Gmail Add-ons approach. If you just want to add or modify some data, use the Gmail API. – Auguste Van Nieuwenhuyzen Jan 31 '19 at 19:16
  • Can't we interact or manipulate Gmail's interface with custom chrome extension? Is n't it possible? – Anil Reddy Ramini Feb 01 '19 at 07:10
  • Like I said, you can do that and if you are planning to, use InboxSDK. – Auguste Van Nieuwenhuyzen Feb 01 '19 at 10:37
  • 1
    If InboxSDK stops their services in future, then it might be problem rite? Bcoz registered "appid" should be used to run InboxSDK library. If they dissolve this framework by any reason, it will be problem for us. – Anil Reddy Ramini Feb 01 '19 at 10:52
  • Right, you can always make a Chrome extension that injects your script into a webpage, see this: https://www.rubberduck.io/blog/browser-extensions-react/ Please, edit your question to state all your requirements & concerns! – Auguste Van Nieuwenhuyzen Feb 01 '19 at 12:38
  • I updated my answer, I recommend to checkout Clasp for local development & maintainability! – Auguste Van Nieuwenhuyzen Feb 13 '19 at 10:44
  • Something else to consider about InboxSDK and Chrome Extensions: it uses remote code to respond to Gmail's almost daily updates. The Chrome Web Store frowns on remote code and they must approve each version of your Chrome Extension before it will be available for your users. While InboxSDK is supposedly whitelisted by Google, the review team often makes mistakes, so expect delays and rejections, especially on version bumps (they are reviewed more closely than new Chrome extensions). – Jack Steam Jul 24 '20 at 20:36