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:

• OpenEd, which provides a library of open education resources for K-12 teachers
• Tynker, a creative computing platform for teaching students to code
• GeoGebra, a visual mathematics platform that allows students and teachers to author interactive mathematics content

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.

Scaling for a billion users

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.

WhatsApp & Google Drive, a seamless integration

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:

Mobile Audit report and alert creation for a single user in the Admin console

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)¹ 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.

---

¹ 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.

Create a clear workflow for the user to follow. PandaDoc by PandaDoc

1. Guide the User

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.

Communicate each step so the user is never lost. Remove Duplicates by AbleBits

2. Communicate Effectively

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.

Inform the user of the results of their actions. VisualCV Resume Builder by VisualCV

3. Provide Feedback

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.

Protect the user and include safety measures.

4. Keep The User Safe

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.

Design around core functionality. Easy Accents by Daniel Baker

5. Keep It Simple

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.

Closing Comments

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:

1. Guide the user
2. Communicate effectively
3. Provide feedback
4. Keep the user safe
5. Keep it simple

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!