Application Development

[Q&A] Behind the scenes with Lucidchart: building new diagramming add-on in Google Slides

You might have seen that we recently announced new Google Slides add-ons. We worked closely with several technology partners to build these new add-on solutions to help speed up workflows. 

One partner, Lucidchart, worked closely with Google to create a new integration that brings added diagramming functionality to Slides. We sat down with Tim Winchester, engineering lead at Lucidchart, to learn more about how his team built the new Lucidchart add-on for Slides.

Tell us about the Google Slides add-on you built for Lucidchart. 

We built it as a sidebar add-on that allows users to insert diagrams directly into Google Slides from within Slides (instead of having to export diagrams from Lucidchart). You can also create a new Lucidchart diagram from within Slides, and simply select “Back to Slides” once you’re finished creating your diagram in the Lucidchart editor. You can modify an existing diagram by clicking “Edit” within Slides. This option will direct you to the Lucidchart editor so you can revise as needed. Once you’ve finished revising, or any time you know a diagram has been updated in Lucidchart, select the refresh button from the Lucidchart Diagrams sidebar.

Lucidchart%2B1nos9.PNG

What prompted you to create your add-on? 

Specifically, how did you envision your add-on would improve user experience? Lucidchart is a visual communication platform, but we know our users sometimes need to have their diagrams available in other places. One of the most popular uses for Lucidchart is in presentations, so an add-on for Slides was a natural fit.

Tell us about how you built your solution. 

Since we already had existing add-ons for Docs and Sheets, this project was less about building from scratch and more about adapting what we already had, then doing rewrites as needed. We started by abstracting app-specific functionality of our existing add-ons into a pluggable IntegratedApp interface. We then implemented the interface for Slides using the new SlidesApp API. Once we had reached feature parity, we created a few new additions, such as a “Refresh All Inserted Diagrams” button, which users could find more easily than a top bar menu entry.

Lucidchart%2B2f7z3.PNG

At the same time, the Lucidchart add-on was undergoing a major UI overhaul, which was the most challenging and time-intensive part of the project. Because we liked the results of the UI update in Slides, we refactored the add-on code to make it more generalizable, then ported it back to our Docs and Sheets add-ons.

Did anything surprise you during the build? 

As a security measure, the sidebar iframe can only render elements within its borders, so we couldn’t simply throw a into the center of the screen in client code. Instead, we had to fire an event that the Apps Script backend would handle to create a modal dialog, using printing scriptlets to add whatever data we needed into the dialog’s HTML. Thus, any JS object sent from the sidebar to a modal has to be serialized and deserialized in the process, which means that the sidebar cannot directly detect any events emitted by the modal.

Do you have any code snippets that you can share? 

Because we have multiple Google Apps Script add-ons that share lots of functionality, it was very useful to concentrate app-specific code and strings into a wrapper object (called IntegratedApp), which we then referenced elsewhere in the codebase instead of calling SlidesApp directly. So, in the click handler for the insert button, instead of writing this...
  SlidesApp.getActivePresentation()
    .getSelection()
    .getCurrentPage()
    .insertImage(image);

...we write this.

  IntegratedApp.insertImage(image);

And then we keep the app-specific implementation in our IntegratedApp object (abridged for clarity):

  var IntegratedApp = {
  // direct mapping to function
  createAddonMenu: SlidesApp.getUi().createAddonMenu.bind(SlidesApp.getUi()),
  // wrapper to create consistent behavior across apps
  insertImage: function(image) {
    return SlidesApp.getActivePresentation()
        .getSelection()
        .getCurrentPage()
        .insertImage(image);
  },
  // app-specific strings
  phrases: {
    docType: 'Slide',
    name: 'Google Slides',
    nameWithDocType: 'Google Slides Presentation'
  }
};

This technique allows us to keep the same UI code and business logic across apps; we only need to change the implementation of the IntegratedApp object. So in Sheets (for example), our IntegratedApp.insertImage() function becomes:

  insertImage: function(image) {
  var sheet = SpreadsheetApp.getActiveSheet();
  var cell = sheet.getActiveCell();
  sheet.insertImage(image, cell.getColumn(), cell.getRow());
}

What advice would you give other developers looking to build similar add-ons? 

If you are planning to develop multiple similar add-ons that mainly differ in the G Suite app with which they integrate, you should find this technique of reducing the overall code amount by isolating duplicative code immensely useful.

After completing the first add-on, creating another add-on for a new G Suite app is just a matter of updating a new copy of IntegratedApp to work with the new app; the rest of the codebase can be commonly shared. In our case, it means that the updated UI was easily added to our Docs and Sheets add-on after we completed the Slides add-on.

Learn more about how you can create your own Slides add-ons or choose from a number of publicly available APIs to customize your G Suite applications. If you’re interested in becoming a Google Cloud technology partner, you can also join our partnership program.