Originally posed Google Apps Developers Blog
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.
Published by Mike Pegg, Head of Developer Marketing
One day in June of 2006 a very special thing happened. For the first time ever, we invited a handful of developers to spend the day with us at Google celebrating what they had achieved with our Maps APIs. Our engineering team came all the way from the Sydney office to help answer questions from developers, and help them learn new ways to solve problems in the apps they were building.
What a difference a decade makes. We’re absolutely amazed with all that developers from around the world have created and changed since that day in 2006. We’ve enjoyed this journey with you, and as developers ourselves we continue to be excited by the challenges that lie ahead.
It was this thinking that drove us to bring I/O back to where it all started 10 years ago and to continue celebrating this developer journey we’re on together. We’re really excited for I/O 2016 and we hope this year’s festival, happening May 18-20 at Shoreline Amphitheatre, is just as special as that first gathering at Google back in 2006.
We know a lot has changed over the years and the opportunities (and challenges) are even greater today than they were back then. We’re gearing up for an I/O festival that will celebrate your accomplishments, answer your burning technical questions, and hopefully help make your life as a developer a little bit easier. We hope you can join us! Applications for attendance opened today and will remain open until 3/10, 5PM PST. And in the meantime, share your #love4dev back with us.
Posted by Chris Dolan, Software Engineer on the Google Cast Server Infrastructure Team
As a Google Cast developer, you may be wondering how many devices access your application, how many sessions those devices initiate, and how long those sessions play media. Until now, you needed to implement your own instrumentation to get this information. Not anymore! Today, we’re excited to announce that we’re making all this data available right from the Google Cast Developer Console.
To check it out, log on as usual to the developer console with your developer account. In the ‘Application’ table, click on the ‘View’ link in the new ‘Statistics’ column for your application
The analytics page contains a tab for each metric, an interactive graph of the metric’s values over time, and tables containing the most recent day’s data. The devices tab shows the number of Cast devices that have launched your application, the sessions tab shows the number of Cast sessions of your application, and the average playback tab shows the average length of media playback time per session for your *application.
Each tab’s data can be viewed in total, by country, or by sender platform. To see data for a particular country or platform, simply click the appropriate row in the table. Each tab’s data is available on a per-day basis, as well as in seven, fourteen, and twenty-eight day rolling totals. To change the aggregation range, select the desired range from the range picker at the top right.
We hope these analytics give you insight into how your Google Cast applications are being used and enable you to see the impact of your improvements. To learn more, see the developer documentation.
Posted by Laurence Moroney, Developer Advocate
Coffee with a Googler catches up with Adam Dawes, leader of Google’s Federated Identity team. His team builds seamless identity experiences for users. He tells us about Google Sign-In, and the simplifications to the APIs, focusing on decoupling from the Google+ sign-in to make the user experience more streamlined.
The landscape for users has changed over the last few years, and the user’s expectation of information that they provide for signing in is very different now. Adam shares about how his team have been engineering sign in APIs to meet these needs.
Adam demonstrates the new APIs using the runkeeper app as an example, and how it avoids ‘cognitive overload.’
We learn about OpenID connect, to make it super simple to use the authentication APIs with your own backend servers. It’s a much simpler experience, so that if all you want to do is sign the user in, without social, we made it simpler for you to do so.
One question we’ve had extensively is with using iOS apps with Google Sign-In. Adam shares how Google Sign-In uses the new Safari View Controller in iOS 9 to ensure that the API will work well on iOS.
To learn more about all these offerings, visit developers.google.com/identity.
Originally posted on Google Apps Developers Blog
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!
Google Cloud Messaging (GCM) is an infrastructure that allows you to do simple and reliable messaging to distribute your messages to and across many devices.
Every day, GCM delivers over 150 Billion messages to devices on various platforms including Android Devices, iOS Devices and Web Browsers. It has a number of different techniques for sending messages:
Single devices. Each device has a unique registration token. If you want to reach that device -- for example using GCM to build a 1:1 chat application, you can do so, addressing it via that token.
Device Groups allow you to bundle devices together into a group. For example, one of your users might have multiple devices -- including the very common scenario of having both a phone and a tablet. Using Device Groups in GCM, you can send a message to all of her devices, and if you desire, you can implement your app so that dismissing on one dismisses on all.
Topics allow you to create interest groups for your users. Once they subscribe to a topic, you can send messages to that topic, and your users will receive them. There’s no subscription limit to these, so you don’t have to worry about how many users subscribe to your topics! Some great scenarios of topics being used to improve user experience can be found in this blog post.
When it comes to reliability of messages, an internal study at Google found that the majority of notification messages (95th percentile) are delivered within 250ms to connected devices. Connectivity is impacted by many factors -- including carriers, routers and local connectivity. Indeed, in some locales it is common for people to disable mobile data for large parts of the day in order to save on bandwidth costs. In this scenario, users will still receive their notifications once they re-activate their data connection.
We’ve provided a number of resources to help you to build apps using GCM. Check out this talk where you are taken step by step through building an Android app and an associated server in PHP. There’s also an open source ‘GCM Playground’ on GitHub here, which provides a sample server implementation that runs on the Google Cloud Platform!
If you want to reach iOS users, today we’re adding an API that will help you to migrate your existing infrastructure to send notifications to iOS device, with no client code changes required. With the new batch Import API you can import the APNs device tokens that you collected from your iOS audience into GCM, and immediately start sending notifications through GCM. After you import the APNs device tokens, you can also use the InstanceID API to transparently subscribe users to GCM topics, achieving efficient fan-out of notifications based on interest groups, once again with no changes required on client code.
We’re continuing to build and innovate on this platform -- stay tuned for lots of cool new features coming soon!
You can learn more about Google Cloud Messaging on the Developers site here, including quickstarts for Android and iOS!
Posted by Larry Yang, Senior Product Manager, Project Tango
Ever been lost indoors? Us too. All the time. We brought Project Tango to Mobile World Congress, and instead of just talking about augmented reality and indoor navigation, we let attendees experience these technologies for themselves... in a museum.
Most of us love museums, but they can be difficult to navigate. It can be hard to find the location of a painting, the story of the sculpture—and equally hard to tell your friends where you are. With Project Tango, the way we experience museums can completely change by making it easier to find what (and who) you’re seeking as well as showing you the story behind the art.
To demonstrate this, we invited conference attendees into the Museu Nacional d'Art de Catalunya, carrying Project Tango developer kits loaded with GuidiGO, a museum tour app, and Glympse, a location-sharing app.
With GuidiGO, attendees could view the museum’s floor plan and follow blue dots on their screens to navigate to specific pieces of art — all without relying on Wi-Fi, GPS or beacons. They could also learn more about the art by simply holding the tablet up to each work and tapping virtual tags to reveal additional information. If people lost track of their friends during their visit, they could easily share their indoor location with their friends with the Glympse app.
We loved seeing these creative applications of Project Tango and can’t wait for people to get their hands on them with the launch of Lenovo’s consumer-ready Project Tango smartphone this summer. To make your own Project Tango app, take a look at our developer documentation and stay tuned for more Project Tango news and applications.
Coffee with a Googler catches up with Steven Soneff, Product Manager for the Google Identity Platform to talk about Smart Lock for Passwords. If you’re not familiar with it, this is a terrific technology that takes the hassle out of signing in across devices to your favorite apps and websites. Smart Lock can save passwords to your Google account, and then help you use your passwords securely and conveniently on the websites you use in Chrome and the apps you use in your Android devices.
Steven demonstrates use of Smart Lock with Netflix, where at home he may sign in with the browser on his desktop, but over coffee he signs in using his smartphone. We discuss the great blog post that Steven wrote about Smart Lock, showing how it works, and how you can code your Android applications to use it. To learn more about the Google Identity Platform, check out the developers site here.
Originally posted on Android Developers Blog
Posted by Roy Glasberg Global Lead, Launchpad Program & Accelerator
Last month, 24 promising startups from India, Indonesia, and Brazil came to Silicon Valley to participate in Google’s Launchpad Accelerator, a new program that provides late-stage startups (mobile apps) with mentoring and resources to successfully scale in their local economies.
During the intensive two-week Accelerator kickoff in our Mountain View headquarters, Google engineers from 11 product areas, as well as experts from other companies, were on hand to provide startups with mentorship on how to scale and monetize their apps, and ultimately, build successful businesses. Now back in their home countries, the teams will continue developing their products with the support of up to $50,000 in equity-free funding, six more months of ongoing mentorship, and a breadth of developer tools from the Launchpad Accelerator program.
So far, many startup participants have already seen an immediate impact. Two weeks after attending the kickoff event, Brazilian mobile game developer UpBeat Games was featured on Google Play and saw a 1,000% increase in app installations in Asia, as well as a 200% overall increase in active users, by leveraging analytics to better understand their users.
According to UpBeat Games founder Vinicius Heimbeck, “By working one-on-one with the mentors, we learned that we needed to be a data-driven company. We now have the right analytics tools to measure the results of our efforts and to learn from them to optimize the user experience. This all directly impacted our huge success once we were featured on Google Play.”
eFishery, an Indonesian startup that produces smart automated fish feeders, turned its focus on scaling since attending Launchpad Accelerator. “The mentors gave us great insight about how to build a scalable product and how to engage billions of users,” said co-founder and CEO Gibran Chuzaefah Amsi El Farizy. “We received both technical and practical advice on our business, from building back-end technology to embracing failure with the right mindset.”
Apply now for Launchpad Accelerator We are also excited to announce the second class for Launchpad Accelerator which will begin in June 2016.
If you are a startup from India, Indonesia, Brazil, or Mexico (a new addition!) and are interested in participating in the next wave, we encourage you to apply here by March 31. We expect to continue adding more countries to the program in the future, so be on the lookout!
Coffee with a Googler caught up with David East to talk about Firebase and what’s been happening over the last few months with this platform. In this interview, David tells Laurence Moroney all about what he calls ‘The Holy Grail of Development’ -- a platform that makes building mobile backends really easy and quick.
David also talks about how Google has invested a lot of resources into Firebase to make it even better and more useful, such as providing tools for Unity3d developers to take advantage of the real time database features.
Elsewhere, David walks through the steps on how to get started with Firebase to power your app’s backend, including data storage, user authentication, static hosting and more at Firebase.com.
