Google Calendar and Google Drive for Atlassian HipChat
Guest post by Rich Manalang, Partner Engineering Lead at Atlassian. Posted by Wesley Chun, Developer Advocate, Google Apps.
Atlassian has been building collaboration software for over 14 years. With products that include JIRA, Confluence, Bitbucket, and HipChat, our organization has learned a lot about how teams work effectively.
HipChat launched the Connect API in November 2015, and since then we’ve continued to build upon our ecosystem of integrations and collaborations. A few months ago, our team looked at potential integrations that would be a perfect marriage with HipChat — and today, we’re excited to share the Google Calendar and Google Drive integration for HipChat.
Millions of people use Google’s products everyday, so we instantly knew this was the right opportunity. Many of HipChat’s customers are developers, and they told us that managing time and better access to files were two of the most important things in their day-to-day. Now with Google integrations available inside of HipChat, there’s no need to launch another browser tab or app.
By building Google Calendar directly into HipChat, we’re improving the signal-to-noise ratio on a daily basis. Before this integration, we all dealt with context-switching between apps and browser tabs. Now, customers can use HipChat to view and share various calendars, schedules and important dates in the right sidebar. Our customers spend their entire working day inside our HipChat app — unlike email, you don’t just fire it up and quit periodically. So naturally, having your calendar up-front is compelling. And what’s more, you can slice and dice which ones you see on a per-room basis. Say you’re a program manager — if you go into the Engineering HipChat “room,” you can see the Engineering and related calendars. Then, when you switch into the Marketing room, you may see different calendars depending on whom you’re collaborating with.
Having dual calendars front and center within HipChat is critical for staying on top of my work. I’m personally very excited about the Google Calendar integration because it’s one of the most important apps I use day-in and day-out. As a single parent with two kids busy at school, I need to know everything that's going on. My calendar is stacked, and I want to see it all at a glance. That urgency is similar when considering the most important documents in someone's daily workflow.
When we started working on the Google Drive integration, we wanted to focus on what was most important — accessibility, shareability, and ease of use.
There are many benefits to bringing third party integrations right into HipChat. The Google Drive integration allows teams to collaborate and work together while saving time and eliminating context switching. Being able to access documents, presentations, and files is critical whether a user is at the office or remote. It integrates nicely into the right side bar, enabling users to access, share to the room, and collaborate around important documents, presentations, and spreadsheets. We worked with third party developer Topdox, who was a tremendous partner in bringing this new feature into HipChat. We’re getting great feedback around the speed and simplicity of sharing files without ever having to leave the HipChat application.
Why would Google Developers be interested?
When we built these integrations, we wanted to give our users a nice balance between out-of-the-box usefulness but also ultimate flexibility in which calendars and accounts a user can view. To do that, we wanted one UI that can display multiple calendars from multiple Google accounts — similar to what most Calendar mobile apps do today, including Google’s own mobile Calendar app.
These new integrations were built entirely on top of Google’s API. Google’s Calendar API is a full featured API that gave us everything we needed to create a calendar experience fit for HipChat’s users. On top of that, the API was designed with efficiency in mind with push notifications for changes to resources and incremental syncing to improve performance and bandwidth use.
Building on top of Google APIs has allowed us to think of new ways to bring even tighter integrations with our products along with the myriad of add-ons built by Atlassian’s ecosystem. One idea under consideration is to link JIRA Software and Google Calendar so that all your JIRA issues are overlayed onto a Google Calendar. Then this calendar can be shared with the relevant HipChat room bringing it all together and enabling teams to get more done. We’d love to hear your feedback on this idea.
We think there are many opportunities to improve how teams work together by integrating with Google and Atlassian. You can find out more about Atlassian Connect on our developer’s site and the Google APIs on theirs.
Posted by Chris Han, Product Manager, Apps Developer Platform
For over 6 years, the Google Apps Marketplace has been the #1 destination for administrators and business users within Google Apps domains to find, discover and install third-party apps and integrations that extend what they can do with Google Apps.
We are happy to announce that over the next few weeks, we are opening up the Google Apps Marketplace to consumer end-users, and wanted to give you a heads up as well as some technical guidance should you wish to make any changes or tweaks to your app. Here is what you need to know if you are a technology partner or developer building for the Google Apps Marketplace:
First, this change only applies to apps which have opted in to “Enable Individual Install” on the Google Apps Marketplace SDK located in the Developer Console. Apps not enabled with individual install will not appear to consumers, nor will they be installable for them.
Second, as a general best practice, we recommend that you do not use a user’s email address as a unique identifier. Email addresses for both consumer and business accounts can be renamed or changed. Make sure to always use the Google Account ID. For more information on sign in and security, please read this.
If you have questions or have any feedback regarding this development, please let us know here. We look forward to exposing what you’ve built to our broader community.
Posted by Tom Holman, Product Manager, Google Sheets and Josh Danziger, Software Engineer, Google Sheets
At Google, we are always working to keep our users' information safe. As part of these ongoing efforts, we will begin requiring explicit authorization when third-party sites request access to Google Sheets content via the Google Visualization API or Google Query Language.
For many developers, this change will be transparent, but others may need to make changes in order to continue reading spreadsheet data. For more details on the technical changes required, please visit the Google Charts API Documentation. We will begin enforcing these requirements on September 14, 2016.
If you have any questions or concerns about this change, please follow up in the Google Docs forum or on Stack Overflow.
Calling all developers: try our developer preview today!
As you can see from above, Android add-ons offer a great opportunity to build innovative integrations and reach Docs and Sheets users around the world. They’re basically Android apps that connect with Google Apps Script projects on the server-side, allowing them to access and manipulate data from Google Docs or Sheets using standard Apps Script techniques. Check out our documentation which includes UI guidelines as well as sample code to get you started. We’ve also made it easy for you to publish your apps with the Apps Script editor.
Android add-ons are available today as a developer preview. We look forward to seeing what you build!
Posted by Hodie Meyers, Product Manager, Google Drive and Steve Bazyl, Developer Programs Engineer, Google Apps
Last year, we announced the deprecation of Google Drive web hosting for users and developers, and that the service will be shut down on August 31, 2016. We’d like to remind remaining users that websites hosted via googledrive.com/host/[id] will become unavailable from that date.
googledrive.com/host/[id]
For those who haven’t switched yet, please consider the following alternatives.
Posted by Brandon Jewett-Hall, Software Engineer, Gmail and Wesley Chun, Developer Advocate, Google Apps
If you've been pining for a way to update your users' email signatures with a different inspirational quote each day or enable "Out of Office" auto-replies when their calendars are marked as busy, then you're in luck. Today, we're extending the Gmail API with new endpoints for managing settings. These new endpoints cover the following features:
With this update, we're equipping developers with some new tools that have never been available in any previous Google API. These include the ability to:
Over time we'll continue to expand the API with additional settings features such as support for managing mailbox delegates, so stay tuned for more announcements.
Get started now
Most of the settings endpoints are available for any Google Apps or Gmail account, but a few sensitive operations, such as modifying send-as aliases or forwarding, are restricted to service accounts with domain-wide authority. See the reference docs for more details and to get started.
What about the existing Email Settings API in the Admin SDK?
This update to the Gmail API effectively replaces the older Email Settings API, so we're also announcing its deprecation today and will turn it down fully on July 7, 2017. We've put together a migration guide to assist clients in porting their existing integrations over to their newer counterparts in the Gmail API. If you have any issues, check out the gmail-api tag on StackOverflow.
We look forward to seeing what you build with these new features in the Gmail API!
Posted by Wesley Chun (@wescpy), Developer Advocate, Google Apps
At Google I/O 2016, we launched a new Google Sheets API—click here to watch the entire announcement. The updated API includes many new features that weren’t available in previous versions, including access to functionality found in the Sheets desktop and mobile user interfaces. My latest DevByte video shows developers how to get data into and out of a Google Sheet programmatically, walking through a simple script that reads rows out of a relational database and transferring the data to a brand new Google Sheet.
Let’s take a sneak peek of the code covered in the video. Assuming that SHEETS has been established as the API service endpoint, SHEET_ID is the ID of the Sheet to write to, and data is an array with all the database rows, this is the only call developers need to make to write that raw data into the Sheet:
SHEETS
SHEET_ID
data
SHEETS.spreadsheets().values().update(spreadsheetId=SHEET_ID, range='A1', body=data, valueInputOption='RAW').execute()
rows = SHEETS.spreadsheets().values().get(spreadsheetId=SHEET_ID, range='Sheet1').execute().get('values', []) for row in rows: print(row)
If you’re ready to get started, take a look at the Python or other quickstarts in a variety of languages before checking out the DevByte. If you want a deeper dive into the code covered in the video, check out the post at my Python blog. Once you get going with the API, one of the challenges developers face is in constructing the JSON payload to send in API calls—the common operations samples can really help you with this. Finally, if you’re ready to get going with a meatier example, check out our JavaScript codelab where you’ll write a sample Node.js app that manages customer orders for a toy company, the database of which is used in this DevByte, preparing you for the codelab.
We hope all these resources help developers create amazing applications and awesome tools with the new Google Sheets API! Please subscribe to our channel, give us your feedback below, and tell us what topics you would like to see in future episodes!
Google Forms has become a popular tool for polling colleagues or creating a pop quiz for students. Creating a few Forms manually may be manageable, but what if you needed to create hundreds or thousands? This is where Google Apps Script can help you scale, by giving you the ability to generate Google Forms programmatically. In this latest edition of the Launchpad Online developer video series, we focus on the JavaScript snippet below that shows you just how easy it is to automate the creation of Google Forms:
function createForm() { // create & name Form var item = "Speaker Information Form"; var form = FormApp.create(item) .setTitle(item); // single line text field item = "Name, Title, Organization"; form.addTextItem() .setTitle(item) .setRequired(true); // multi-line "text area" item = "Short biography (4-6 sentences)"; form.addParagraphTextItem() .setTitle(item) .setRequired(true); // radiobuttons item = "Handout format"; var choices = ["1-Pager", "Stapled", "Soft copy (PDF)", "none"]; form.addMultipleChoiceItem() .setTitle(item) .setChoiceValues(choices) .setRequired(true); // (multiple choice) checkboxes item = "Microphone preference (if any)"; choices = ["wireless/lapel", "handheld", "podium/stand"]; form.addCheckboxItem() .setTitle(item) .setChoiceValues(choices); }
If you’re ready to get started, you can find more information, including another intro code sample, in the Google Forms reference section of the Apps Script docs. In the video, I challenge viewers to enhance the code snippet above to read in “forms data” from an outside source such as a Google Sheet, Google Doc, or even an external database (accessible via Apps Script’s JDBC Service) to generate multiple Forms with. What are other things you can do with Forms?
One example is illustrated by this Google Docs add-on I created for users to auto-generate Google Forms from a formatted Google Doc. If you’re looking to do integration with a variety of Google services, check out this advanced Forms quickstart that uses Google Sheets, Docs, Calendar, and Gmail! Finally, Apps Script also powers add-ons for Google Forms. To learn how to write those, check out this Forms add-on quickstart.
We hope the DevByte and all these examples inspire you to create awesome tools with Google Forms, and taking the manual creation burden off your shoulders! If you’re new to the Launchpad Online developer series, we share technical content aimed at novice Google developers, as well as discuss the latest tools and features to help you build your app. Please subscribe to our channel, give us your feedback below, and tell us what topics you would like to see in future episodes!
Originally posted on Google for Work blog
Find these apps and many more (like AppSheet, GQueues, ZipBooks, Any.Do, Infogram, and LogoMix) in New & Notable. And if you’re a developer, learn more about how you can get your apps featured on Google Apps Marketplace here.
Originally posted on Google for Education blog
Posted by Ed Kupershlak, Google Classroom Software Engineer
Last year, we launched the Classroom API to make it easier for administrators to manage classes, and for developers to integrate their applications with Classroom. Since that time, hundreds of applications have integrated with Classroom to help teachers gamify their classes, improve students’ writing skills, build interactive presentations and more.
Do more with coursework in the Classroom API
Today, we’re introducing new coursework endpoints that allow developers to access assignments, grades and workflow. Learning tools can focus on creating great content and, in turn, use Classroom to manage the workflow for assignments created with this content. Gradebooks and reporting systems can now also sync grades with Classroom, eliminating the need for teachers to manually transfer grades.
Several partners have been helping to test the new functionality, including:
Access course Drive folders, groups and materials
In addition to the coursework endpoints, we’ve added new functionality to our existing course and roster API endpoints. Developers can now access course Drive folders, groups and materials. Applications can use this new functionality to store files in the same Drive folder as the rest of the resources in a class, or use course groups to manage file sharing permissions.
In the coming months, we’ll be adding more coursework management capabilities. When we do, we’ll post updates to the developer forum and issue tracker. We look forward to working together to make it even easier for teachers and students to use the tools they love with Classroom. Developers, please review the documentation, the FAQ, and ask questions on Stack Overflow. Also, don’t forget to let us know what you’re building using the #withClassroom hashtag on Twitter or G+. And teachers, check out this list of applications that work well with Classroom today.
Posted by Mike Procopio, Engineering Manager, Google Drive and Wesley Chun, Developer Advocate, Google Apps
WhatsApp is one of the most popular mobile apps in the world. Over a billion users send and receive over 42 billion messages, photos, and videos every day. It's fast, easy to use, and reliable.
But what happens when people lose their phone or otherwise upgrade to a new one? All those messages and memories would be gone. So we worked with WhatsApp to give their users the ability to back up their data to Google Drive and restore it when they setup WhatsApp on a new phone. With messages and media safely stored in your Drive, there’s no more worry about losing any of those memories.
One of the biggest challenges for an integration of this scope is scaling. How do you back up data for a billion users? Many things were done to ensure the feature works as intended and is unnoticeable by users. Our approach? First, we relied on a proven infrastructure that can handle this kind of volume—Google Drive. Next, we optimized what to back up and when to do the backups—the key was to upload only incremental changes rather than transmit identical files.
On the server side (backend), we focused on optimizing byte storage as well as the number of network calls between WhatsApp and Google. As far as deployment goes, we rolled out slowly over several months to minimize the size and impact of deployment.
If you have ever used WhatsApp, you know how it gets out of your way, and lets you get started quickly: no account creation, no passwords to manage, and no user IDs to remember or exchange. This sets a high bar for any integration with WhatsApp: for it to feel like a natural part of WhatsApp, it has to be as seamless, fast, and reliable as WhatsApp itself.
By using the Google Drive API, we were able to achieve this: no need to type in any usernames or passwords, just a few taps in the app, and WhatsApp starts backing up. The best part is that all the tools used in the integration are available to all developers. With the Google Drive API, seamless and scalable integrations are as easy to use for the user as they are for developers.
To learn more about how we did it and get all the details, check out the complete talk we gave together with WhatsApp at Google I/O 2016.
Are you ready to integrate your web and mobile apps with Google Drive? Get started today by checking out our intro video as well as the video demoing the newest API, then dig in with the developer docs found at developers.google.com/drive. We're excited to see what you build next with the Drive API—and we're ready to scale with you!
Posted by Tom Holman, Product Manager, Google Sheets
There was a time when office work used to be all about pushing physical paper. Computing and productivity tools have made things better, but workers still find themselves doing the same tasks over and over across the different apps they use: copying and pasting from a CRM app to a slide presentation, or manually exporting data from a project management app just to turn around and import it back into a spreadsheet. It’s the digital equivalent of pushing paper.
To make it easier to get the job done across multiple apps, without all the copy and paste, we’re announcing three new APIs and a new feature to help workers get to the data they need, when and where they need it.
Build seamless integrations with the new Sheets and Slides APIs
Our new APIs let developers connect their apps—and the data within them—more deeply with Google Sheets and Google Slides.
The new Sheets API gives developers programmatic access to powerful features in the Sheets web and mobile interfaces, including charts and pivot tables. For example, developers can use Sheets as part of a rich workflow that pushes data from their app into Sheets and allows users to collaborate on that data before the updated data is pulled back into the original app, removing altogether the need to copy and paste.
Teams at Anaplan, Asana, Sage, Salesforce, and SAP Anywhere are already building interesting integrations with the new Sheets API. Check out the video below to see an overview of what’s possible as well as several example integrations.
Partner integrations with the new Google Sheets API
The new Sheets API is available today. Find the developer documentation as well as a codelab to help you get started at developers.google.com/sheets.
Similar to the Sheets API, the new Slides API gives developers programmatic access to create and update presentations. For example, developers can use this API to push data and charts into Slides to create a polished report from source data in other application, ready to present.
Conga, ProsperWorks, SalesforceIQ and Trello are all building integrations with Slides using the new API. Several examples of what’s possible are in the video below.
Partner integrations with the new Google Slides API
The Slides API will be launching in the coming months, and these partner integrations will be available soon after. You can sign up for early access to the Slides API at developers.google.com/slides.
Keep your data in sync with the new Classroom API
For developers building tools and workflows for schools, the Classroom API has launched new coursework endpoints to help you build stronger integrations that keep your data in sync. Read the full announcement on the Google for Education blog, here.
Sync assignments & grades programmatically with the Google Classroom API
Say goodbye to stale data with linked charts
Finally, to make sure we can help keep all this data flowing seamlessly from app to app, users can now also embed linked charts from Sheets into Docs or Slides. The result? Once the underlying data in a spreadsheet changes, whether that change comes from an action taken in another app via the API or a collaborator, an updated chart in the corresponding presentation or document is just one click away.
Linked charts allow for easy updates in Docs & Slides
For more information, see how to add a chart to a document or to a presentation.
We can't wait to see what you build.
Posted by Sumit Chatterjee, Product Manager, Google Mobile Management and Wesley Chun, Developer Advocate, Google Apps
As security on mobile devices becomes increasingly important, we want to give Google Apps administrators the visibility to monitor key activities occurring on managed devices in their domain. With that in mind, today we are launching Mobile Audit for Google Apps Unlimited users, which audits activities on iOS and Android devices (using the native iOS Sync and Android Sync protocols) managed by Google Mobile Management. Examples of activities that are recorded include: operating system updates, device settings changes, and mobile application installs, updates and removals.
Google Apps Administrators can also go to the Reports page in the Admin console to see all the Mobile Audit events. Below is an example of what this page looks like querying one user’s activity, including newly registered devices:
As part of this launch, we are excited to make all Mobile Audit events available programmatically through the Admin SDK Reports API via Mobile Audit Activity Events. The Admin SDK is accessible through its REST API or Google Apps Script. With this new feature, administrators will be able to query all of the Mobile Audit information by user, by device, or by event, as well as verify that all of your deployed devices are running the latest security updates. You can even send this information to an asset management system to track all of your mobile inventory.
For example, if we wanted to download all of the newly registered devices, you could make a call like this to the API (via Google Apps Script):
AdminReports.Activities.list('all', 'mobile', { eventName: "DEVICE_REGISTER_UNREGISTER_EVENT", filters: "ACCOUNT_STATE==REGISTERED", maxResults: 1000 });
Once you have the response from the API, you could easily parse through that data, including device models, serial numbers, user email addresses, and any other relevant information to help you track your inventory.
A more critical use case that mobile administrators have been asking for is a way to take proactive actions on devices without requiring manual intervention. For example, a mobile administrator may want to automatically block a device when something suspicious is detected. This new feature enables admins to write simple apps that do just that.
Using the Mobile Audit Activity Events in the Reports API and the Mobile Devices component of the Directory API, administrators can create scheduled scripts to check for devices that are reporting suspicious activity, and then take actions on those devices.
The Apps Script snippet below returns results if there are any mobile audit events for suspicious activity:
var response = AdminReports.Activities.list('all', 'mobile', { eventName: "SUSPICIOUS_ACTIVITY_EVENT", maxResults: 1000 });
If there are results, the code below shows you how to retrieve the unique Google identifier for those devices, via the “RESOURCE_ID” parameter. Note that this snippet only assumes a single device reporting suspicious activity—you’ll need to tweak the code to support more than one.
var parameters = response.items[0].events[0].parameters; var resourceId; for (i = 0; i < parameters.length; i++) { if (parameters[i].name == ‘RESOURCE_ID’) { resourceId = parameters[i].value; break; } }
Now the Directory API can be invoked to block the device that corresponds with the above unique identifier using this Apps Script snippet:
AdminDirectory.Mobiledevices.action('my_customer', resourceId, { action: "block" });
We are really excited to see what uses you have for Mobile Audit in the Reports API. For more information and to get started, please see the Developer Guide, reference documentation, and the Help Center. (NOTE: Again, this feature is available only to our customers with users on the Google Apps Unlimited license.)
Posted by Vartika Agarwal, Technical Program Manager, Identity & Authentication, and Wesley Chun, Developer Advocate, Google
As we indicated several years ago, we are moving away from the OAuth 1.0 protocol in order to focus our support on the current OAuth standard, OAuth 2.0, which increases security and reduces complexity for developers. OAuth 1.0 (3LO)1 was shut down on April 20, 2015. During this final phase, we will be shutting down OAuth 1.0 (2LO) on October 20, 2016. The easiest way to migrate to the new standard is to use OAuth 2.0 service accounts with domain-wide delegation.
If the migration for applications using these deprecated protocols is not completed before the deadline, those applications will experience an outage in their ability to connect with Google, possibly including the ability to sign-in, until the migration to a supported protocol occurs. To avoid any interruptions in service for your end-users, it is critical that you work to migrate your application(s) prior to the shutdown date.
With this step, we continue to move away from legacy authentication/authorization protocols, focusing our support on modern open standards that enhance the security of Google accounts and that are generally easier for developers to integrate with. If you have any technical questions about migrating your application, please post them to Stack Overflow under the tag google-oauth.
1 3LO stands for 3-legged OAuth: there's an end-user that provides consent. In contrast, 2-legged (2LO) doesn’t involve an end-user and corresponds to enterprise authorization scenarios such as enforcing organization-wide policy control access.
Posted by Saurabh Gupta, Product Manager, Google Apps Script
There are two ways to send email in Apps Script: MailApp's sendEmail and GmailApp's sendEmail method. One of the differences between these two methods is that the MailApp’s sendEmail method doesn’t require the developer to be a Gmail user. For example, a Google Apps customer who doesn’t use Gmail, but uses Apps Script instead, can send emails through MailApp but not GmailApp.
Starting on September 13, 2016, users with free public Google Accounts (consumers) and Google Apps for Education and Google Apps Free edition users, will be required to have Gmail access to send messages through Apps Script’s Mail Service. Consumers can enable Gmail on their Google account after signing-in—note your Gmail will then become the primary address of your Google account. Administrators of Google Apps domains (Education and Free edition only) can use the Admin console to turn on Gmail for their domain.
This change does not require any updates to your code. You can continue to use MailApp as before; just make sure that you have signed up for Gmail. We realize that sometimes these changes are disruptive to our developers, but we can assure you that we put lot of care and deliberation into this process.
Posted by Ben Greve, Developer Support Specialist, Google Apps Script
So you’ve started to build an add-on. Congrats! You identified a problem, figured out a solution, and wrote some code to accomplish it like a pro. Now it’s time to focus on design, to make sure your audience understands what your add-on does and how to use it.
In this post, I will outline five simple design tips to help make your add-on a pleasure to use. Don’t worry if you’re not an artist – these are basic concepts that anyone can apply.
Crafting a guided workflow takes the guesswork (and stress) out of using an add-on. Your user should never wonder, ‘What am I supposed to do next?’ Actions, forms, text, and buttons should be designed to create a natural flow guiding the user from one step to the next.
This can be accomplished in a number of ways. Try presenting actions in a natural order: from left to right and from top to bottom (assuming LtR language; adjust as needed). You can indicate which button is the primary action by styling it using the blue .action class. You can guide the user’s behavior by limiting the actions available (sometimes referred to as ‘forcing function’). For example, actions/options with dependencies can be disabled or hidden until they should be used. Another option is to spread a workflow across several pages and require the user to complete a given page before they can proceed to the next.
Complex add-ons require effective communication. Simple add-ons do, too. Effective communication is necessary for your audience to understand what your add-on does and how they should use it.
Use accessible language that anyone can understand. Don’t use complex wording if more easily digestible terminology is available. Unless your target audience has been demanding a feature to “asynchronously call an RPC with dependent proto messages,” you should avoid using unnecessarily technical or jargony language.
Present information when and where it’s needed. Instructions should be displayed in the context which they will be used. Actions should be clearly labeled so that users will know exactly what they do. Provide enough information so the user understands what they are doing, why they are doing it, and where they are going.
Have you ever used an app where you click on a button and nothing happens? You sit there wondering: Did it work? Did it not work? Did anything happen at all? When building your add-on, don’t do this to your users. Make sure that all actions have clear and immediate feedback, so no one is never left wondering, “What just happened?”.
With this in mind, there is still room for graceful design. Feedback can be subtle - it doesn’t need to shout, ‘ACTION 1 COMPLETED’! Leverage nuanced changes, such as displaying a quick message in a toast or moving to the next step in the workflow.
What happens if an action takes a long time to complete? Someone clicks a button and waits… and waits… and waits. A good UI will account for this scenario, too. Try using a loading graphic (i.e. a spinner or a progress bar) and for longer loading times consider including a button to cancel.
People make mistakes. It’s sad but true, and unlikely to change any time soon. Keep your users safe from themselves and design actions to have minimal risk.
The ideal solution is to remove the risk entirely. Inserting a bunch of data into a spreadsheet? Consider creating a new sheet and insert the data there. When appropriate, configure actions to add rather than replace, minimizing potential damage to existing content.
There will be situations where avoiding risk entirely won’t be possible. In these cases, do the best you can to explicitly communicate the action’s effect so your user can make a well-informed decision. A preview or a warning of the impending changes will help ensure that the user is aware of what’s coming. And of course, provide a method to ‘undo’ when possible.
Each UI element in your add-on should serve a purpose; consider removing anything that doesn’t. For the best design, keep it focused on functionality and trim any excess.
Using a large range of styling can actually undermine the power of the design. When a website is covered with different colors, styles, and fonts, it makes it difficult for any styling to communicate a specific meaning. Design patterns that are overly complicated or inconsistent make it difficult for users to learn what’s important and what isn’t.
Instead, consider an app with only three text stylings: one large, one bold, and one plain. The large style is always (and only) used for headers/titles, the bold style is used for labels, and the plain style is normal body text. Any time a user sees one of these, they’ll know exactly what they are looking at. Less is more.
Too many brilliant add-ons and apps have failed due to simple design flaws that made them inaccessible to users. These five tips are intended to help you prevent those common mistakes and provide a foundation for a great user experience.
As you work on your next add-on, remember the five lessons here:
Finally: please make sure to include the necessary onOpen() and onInstall() functions (if you want the add-on to work), follow our UI Style Guide, and use the provided CSS Package.
Have any tips or tricks of your own? Leave a comment below and share your design insights with the rest of the Apps Script community!
Posted by Henry Wang, Associate Product Marketing Manager
Posted by Romain Vialard, a Google Developer Expert and developer of Yet Another Mail Merge, a Google Sheets add-on.
Google Apps Script makes it easy to create and publish add-ons for Google Sheets, Docs, and Forms. There are now hundreds of add-ons available and many are reaching hundreds of thousands of users. Google Analytics is one of the best tools to learn what keeps those users engaged and what should be improved to make an add-on more successful.
Add-ons run inside Google Sheets, Docs, and Forms where they can display content in dialogs or sidebars. These custom interfaces are served by the Apps Script HTML service, which offers client-side HTML, CSS, and JS with a few limitations.
Among those limitations, cookies aren’t persistent. The Google Analytics cookie will be recreated each time a user re-opens your dialog or sidebar, with a new client ID every time. So, Analytics will see each new session as if initiated by a new user, meaning the number of sessions and number of users should be very similar.
Fortunately, it’s possible to use localStorage to store the client ID — a better way to persist user information instead of cookies. After this change, your user metrics should be far more accurate.
Add-ons can also run via triggers, executing code at a recurring interval or when a user performs an action like opening a document or responding to a Google Form. In those cases, there’s no dialog or sidebar, so you should use the Google Analytics Measurement Protocol (see policies on the use of this service) to send user interaction data directly to Google Analytics servers via the UrlFetch service in Google Apps Script.
A Client ID is also required in that case, so I recommend using the Apps Script User properties service. Most examples on the web show how to generate a unique Client ID for every call to Analytics but this won’t give you an accurate user count.
You can also send the client ID generated on client side to the server so as to use the same client ID for both client and server calls to Analytics, but at this stage, it is best to rely on the optional User ID in Google Analytics. While the client ID represents a client / device, the User ID is unique to each user and can easily be used in add-ons as users are authenticated. You can generate a User ID on the server side, store it among the user properties, and reuse it for every call to Analytics (both on the client and the server side).
In add-ons, we usually rely on event tracking and not page views. It is possible to add different parameters on each event thanks to categories, actions, labels and value, but it’s also possible to add much more info by using custom dimensions & metrics.
For example, the Yet Another Mail Merge add-on is mostly used to send emails, and we have added many custom dimensions to better understand how it is used. For each new campaign (batch of emails sent), we record data linked to the user (e.g. free or paying customer, gmail.com or Google for Work / EDU user) and data linked to the campaign (e.g. email size, email tracking activated or not). You can then reuse those custom dimensions inside custom reports & dashboards.
Once you begin to leverage all that, you can get very insightful data. Until October 2015, Yet Another Mail Merge let you send up to 100 emails per day for free. But we’ve discovered with Analytics that most people sending more than 50 emails in one campaign were actually sending 100 emails - all the free quota they could get - but we failed to motivate them to switch to our paid plan.
As a result of this insight, we have reduced this free plan to 50 emails/day and at the same time introduced a referral program, letting users get more quota for free (they still don’t pay but they invite more users so it’s interesting for us). With this change, we have greatly improved our revenue and scaled user growth.
Or course, we also use Google Analytics to track the efficiency of our referral program.
To help you get started in giving you more insight into your add-ons, below are some relevant pages from our documentation on the tools described in this post. We hope this information will help your apps become more successful!:
Romain Vialard profile | website
Romain Vialard is a Google Developer Expert. After some years spent as a Google Apps consultant, he is now focused on products for Google Apps users, including add-ons such as Yet Another Mail Merge and Form Publisher.
Posted by Posted by Wesley Chun (@wescpy), Developer Advocate, Google Apps
Seasons greetings! In case you missed it last week, the Google Drive team announced the release of the next version of their API. Today, we dig deeper into details about the release with developers. In the latest edition of the Launchpad Online developer video series, you'll get everything you need to know about the new release (v3), as well as its relationship with the previous version (v2).
This jam-packed episode features an introduction to the new API, an interview with a Google Drive engineer about the API design and a code walkthrough of real source code you can use today (as with all my Launchpad Online episodes). This time, it's a command-line script that performs Google Drive file uploads and downloads, presented first in v2 followed by a how-to segment on migrating it step-by-step to v3. In addition, the uploading segment includes the option of converting to Google Apps formats while the download portion covers exporting to alternative formats such as PDF®.
To get started using the Drive API, check out the links to the official documentation above (v2 or v3) where you’ll also find quickstart samples in a variety of programming languages to the left. For a deeper dive into both Python code samples covered here, including v3 migration, start with the first of two related posts posted to my blog.
If you’re new to the Launchpad Online, we share technical content aimed at novice Google developers -current tools with a little bit of code to help you launch your next app. Please give us your feedback below and tell us what topics you would like to see in future episodes!
