“Without standards, things don’t work right,” said Alex Danilo, a Googler working on the HTML5 specs, trying to help us all build a better web.
In 1999, the Mars Climate Orbiter mission failed because of a bug, where onboard software represented output in one standard of measurement, while a different software module needed data in a different format. Alex discusses many other examples of how the lack of industry standards can result in problems, such as early rail systems having different gauge widths in different states, impeding travel.
Alex works with the Web Platform Working Group, whose charter is to continue the development of the HTML language, improving client-side application development, including APIs and markup vocabularies.
He shares with us details of the upcoming HTML 5.1, a refinement of HTML 5, showing us the great validator tool that makes it easier for developers to ensure that their markup is meeting standards, and the test the web forward initiative to help uncover bugs and compatibility issues between browsers.
You can learn more about Google and Web development at the Web Fundamentals site.
Today we're launching Nearby on Android, a new surface for users to discover and interact with the things around them. This extends the Nearby APIs we launched last year, which make it easy to discover and communicate with other nearby devices and beacons. Earlier this year, we also started experimenting with Physical Web beacons in Chrome for Android. With Nearby, we’re taking this a step further.
Imagine pulling up a barcode scanner when you’re at the store, or discovering an audio tour while you’re exploring a museum–these are the sorts of experiences that Nearby can enable. To make this possible, we're allowing developers to associate their mobile app or a website with a beacon.
A number of developers have already been building compelling proximity-based experiences, using beacons and Nearby:
United Airlines works with Radius Networks to help users more easily watch free in-flight movies & TV in the app by installing the app before boarding.
CVSworks with Radius Networks to help in-store customers order their photos in minutes, and print at the kiosk
Airside’s Mobile Passport works with Bluvision to help airport travelers skip the US Customs line by pre-registering and submitting their declaration form online via their mobile phone.
Getting started is simple. First, get some Eddystone Beacons- you can order these from any one of our Eddystone-certified manufacturers. Android devices and and other BLE-equipped smart devices can also be configured to broadcast in the Eddystone Format.
Second, configure your beacon to point to your desired experience. This can be a mobile web page using the Physical Web, or you can link directly to an experience in your app. For users who don’t have your app, you can either provide a mobile web fallback or request a direct app install.
Nearby has started rolling out to users as part of the upcoming Google Play Services release and will work on Android devices running 4.4 (KitKat) and above. Check out our developer documentation to get started. To learn more about Nearby Notifications in Android, also check out our I/O 2016 session, starting at 17:10.
Posted by Rob Jagnow, Software Engineer, Google VR
At Daydream Labs, we pair engineers with designers to rapidly prototype virtual reality concepts, and we’ve already started to share our learnings with the VR community. This week, we focus on social. In many of our experiments, we’ve found that being in VR with others amplifies and improves experiences in VR, as long as you take a few things into account. Here’s what we’ve learned so far:
Simplicity can be powerful: Avatars (or the virtual representations of people in VR) can be simplified to just a floating head with googly eyes and still convey a surprising degree of emotion, intent, and number of social cues. Eyes give people a location to look to and speak towards, but they also increase face-to-face communication by making even basic avatars feel more human. When we combine this with hands and a spatially-located voice, it comes together to create a sense of shared presence.
Connecting the real and the virtual: Even when someone is alone in VR, you can make them feel connected. For example, you can continue to carry a conversation even if you’re not in VR with them. Your voice can serve as a subtle reminder that they’re spanning two spaces—the real and the virtual. This asymmetric experience can be a fun way to help ground party games where one player is in VR but other players aren’t, like with charades or Pictionary.
But when someone else joins that virtual world with them, we’ve seen time and time again that the real world melts away. For most multiplayer activities, this is ideal because it makes the experience incredibly engaging.
Join the party:When you first start a VR experience with others, it can be tough to know where to begin. After all, it’s easier to join a party than to start one! Create shared goals for multi-player experiences. When you give people something to play with together, it can help them break the ice, allow them to make friends, and have more fun in VR.
You think you know somebody: Lastly, people who know each other offline immediately notice stature or differences in a person’s height in VR. We can re-calibrate environments to play with height and scale values to build a VR world where everyone appears to be the same height. Or we can adjust display settings to make each person feel like they’re the tallest person in the room. Height is such a powerful social cue in the real world and we can tune these settings in VR to nudge people into having more friendly, prosocial interactions.
Posted by Uttam Kumar Tripathi, Global Lead, Developer Agency Program
Back in December 2015, we had shared our initial plans to offer a unique program to software development agencies working on mobile apps.
The Agency Program is an effort by Google’s Developer Relations team to work closely with development agencies around the world and help them build high quality user experiences. It includes providing agencies with personalized training through local events and hangouts, dedicated content, priority support from product and developer relations teams, and early access to upcoming developer products.
Over the past few months, the program drew a lot of interest from hundreds of Agencies and we have since successfully launched this program in a number of countries including India, UK, Russia, Indonesia, USA and Canada.
Having worked with various agencies for several months, the Agency Program has now launched certification for those partners that have undergone the required training and have demonstrated excellence in building Android applications using our platforms. The Agency Program hopes that doing so would make it easier for clients who’re looking to hire an agency to make an informed decision while also pushing the entire development agency ecosystem to improve.
The list of our first set of certified agencies Agencies is available here.
We do plan to review and add more agencies to this list over the year and also expand the program to other countries.
This year's Google I/O was an exciting time for Firebase. In addition to sharing the many innovations in our platform, we also hatched a time-traveling digital fish named Firebass.
Firebass is an Alternate Reality Game (ARG) that lives across a variety of static web pages. If you haven’t played it yet, you might want to stop reading now and go fishing. After you’ve caught the Firebass and passed the challenge, come back -- we’re going to talk about how we built Firebass.
How we began
We partnered with Instrument, a Portland-based digital creative agency, to help us to create an ARG. We chose ARG because this allowed us to utilize developers’ own software tools and ingenuity for game functionality.
Our primary objective behind Firebass was to make you laugh, while teaching you a little bit about the new version of Firebase. The payoff for us? We had a blast building it. The payoff for you? A chance to win a free ticket to I/O 2017.
To begin, we needed to establish a central character and theme. Through brainstorming and a bit of serendipity, Firebass was born. Firebass is the main character who has an instinctive desire to time-travel back through prior eras of the web. Through developing the story, we had the chance to revisit the old designs and technologies from the past that we all find memorable -- as you can imagine, this was really fun.
Getting started
We put together a functional prototype of the first puzzle to test with our own developers here at Google. This helped us gauge both the enjoyment level of the puzzle and their difficulty. Puzzle clues were created by thinking of various ways to obfuscate information that developers would be able to recognize and manipulate. Ideas included encoding information in binary, base64, hex, inside images, and other assets such as audio files.
The core goal with each of the puzzles was to make them both logical but not too difficult -- we wanted to make sure players stayed engaged. A bulk of the game’s content was stored in Firebase, which allowed us to prevent players from accessing certain game details too early via inspecting the source code. As an added bonus, this also allowed us to demonstrate a use-case for Firebase remote data storage.
Driving the game forward
One of our first challenges was to find a way to communicate a story through static web pages. Our solution was to create a fake command line interface that acted as an outlet for Firebass to interact with players.
In order to ground our time travel story further, we kept the location of Firebass consistent at https://probassfinders.foo/ but changed the design with each puzzle era.
Continuing the journey
After establishing the Pro Bass Finders site and fake terminal as the centerpieces of the game, we focused on flushing out the rest of the puzzle mechanics. Each puzzle began with the era-specific design of the Pro Bass Finders home page. We then concepted new puzzle pieces and designed additional pages to support them. An example of this was creating a fake email archive to hide additional clues.
Another clue was the QR code pieces in puzzle 2.
The QR codes demonstrate Firebase time-based read permissions and provide a way to keep players revisiting the site prior to reaching the end of puzzle 2. There were a total of three pieces of a QR code that each displayed at different times during the day. It was really fun and impressive to see all of the different ways players were able to come up with the correct answer. The full image translates to ‘Locating’, making the answer the letter ‘L’, but many players managed to solve this without needing to read the QR code. You're all smart cookies.
Final part of the Puzzle
Puzzle 3 encompassed our deep nostalgia for the early web, and we did our best to authentically represent the anti-design look and feel of the 90s.
In one of the clues, we demonstrated Firebase Storage by storing an audio file remotely. Solving this required players to reference Firebase documentation to finish writing the code to retrieve the file.
<!-- connect to Firebase Storage below --> <script> console.log('TODO: Complete connection to Firebase Storage'); var storageRef = firebase.app().storage().ref(); var file = storageRef.child('spectrogram.wav');
// TODO: Get download URL for file (https://developers.google.com/firebase/docs/storage/web/download-files) </script>
The finale
While the contest was still active, players who completed the game were given a URL to submit their information for a chance to win a ticket to Google I/O 2017. After the contest was closed, we simply changed the final success message to provide a URL directly to the Firebass Gift Shop, a treasure in and of itself. :)
Until next time
This was an unforgettable experience with a fervently positive reaction. When puzzle 3 unlocked, server traffic increased 30x! The community response in sharing photos, Slack channels, music, jokes, posts, etc. was incredible. And all because of one fish. We can’t wait to see all the swimmer winners next year at I/O 2017. Until then, try playing the game yourself at firebase.foo. Thank you, Firebass. Long may you swim.
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);
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!
Posted by Todd Kerpelman, Firebase Developer Advocate and Safa Alai, Remote Config Product Manager
Turning a great app into a successful business requires more than simply releasing your app and calling it a day. You need to quickly adapt to your user’s feedback, test out new features and deliver content that your users care about most.
This is what Firebase Remote Config is made for. By allowing you to change the look and feel of your app from the cloud, Firebase Remote Config enables you to stay responsive to your user’s needs. Firebase Remote Config also enables you to deliver different content to different users, so you can run experiments, gradually roll out features, and even deliver customized content based on how your users interact within your app.
Let's look at what you can accomplish when your wire up your app to work with Remote Config.
Update your app without updating your app
We've all had the experience of shipping an app and discovering soon afterwards that it was less than perfect. Maybe you had incorrect or confusing text that your users don't like. Maybe you made a level in your game too difficult, and players aren't able to progress past it. Or maybe it was something as simple as adding an animation that takes too long to complete.
Traditionally, you'd need to fix these kinds of mistakes by updating those values in your app's code, building and publishing a new version of your app, and then waiting for all your users to download the new version.
But if you've wired up your app for Remote Config in the Firebase platform, you can quickly and easily change those values directly in the cloud. Remote Config can download those new values the next time your user starts your app and address your users' needs, all without having to publish a new version of your app.
Deliver the Right Content to the Right People
Firebase Remote Config allows you to deliver different configurations to targeted groups of users by making use of conditions, which use targeting rules to deliver specific values for different users. For example, you can send down custom Remote Config data to your users in different countries. Or, you can send down different data sets separately to iOS and Android devices.
You can can also deliver different values based on audiences you've defined in Firebase Analytics for some more sophisticated targeting. So if you want to change the look of your in-app store just for players who have visited your store in the past, but haven't purchased anything yet, that's something you can do by creating Remote Config values just for that audience.
Run A/B Tests and Gradual Rollouts
Remote Config conditions also allow you to deliver different values to random sets of users. You can take advantage of this feature to run A/B tests or to gradually rollout new features.
If you are launching a new feature in your app but aren't sure if your audience is going to love it, you can hide it behind a flag in your code. Then, you can change the value of that flag using Remote Config to turn the feature on or off. By defining a "My New Feature Experiment" condition that is active for, say, 10% of the population, you can turn on this new feature for a small subset of your users, and make sure it's a great experience before you turn it on for the rest of your population.
Similarly, you can run A/B tests by supplying different values to different population groups. Want to see if people are more likely to complete a purchase if your in-app purchase button says, "Buy now" or "Checkout"? That's the kind of experiment you can easily run using A/B tests.
If you want to track the results of these A/B tests, you can do that today by setting a user property in Firebase Analytics based on your experiment. Then, you can filter any of your Firebase Analytics reports (like whether or not the user started the purchase process) by this property. Watch this space for news on upcoming improvements to A/B testing.
A Fabulous Improvement in Retention
Many of our early partners have already been using Firebase Remote config to test out changes within their app.
Fabulous, an app from Duke University's designed to help people adopt better lifestyle habits, wanted to experiment with their getting started flow to see which methods were most effective for getting their users up and running in their app. They not only A/B tested changes like images, text, and button labels, but they also A/B tested the entire onboarding process by using Remote Config to determine what dialogs people saw and in what order.
Thanks to their experiments with Remote Config, Fabulous was able to increase the number of people who completed their onboarding flow from 42% to 64%, and their one-day retention rate by 27%.
Research has shown that an average app loses the majority of their users in the first 3 days, so making these kinds of improvements to your app's onboarding process -- and confirming their effectiveness by conducting A/B tests -- can be crucial to ensuring the long-term success of your app.
Is Your App Wired Up?
When you use remote config Remote Config, you can supply all of your default values locally on the device, then only send down new values from the cloud where they differ from your defaults. This gives you the flexibility to wire up every value in your app to be potentially configurable through Remote Config, while keeping your network calls lightweight because you're only sending down changes. So feel free to take all your hard-coded strings, constants, and that AppConstants file you've got sitting around (it's okay, we all have one), and wire 'em up for Remote Config!
Firebase Remote Config is part of the Firebase platform and is available for free on both iOS and Android. If you want to find out more, please see our documentation and be sure to explore all the features of the Firebase SDK.
We wanted to build something cool for the new lobby in our New York City office, something that was big, could display a lot of interesting stuff, and (most importantly) was really fun to play and interact with. A giant screen would have been pretty easy, but touching a screen just isn’t that much fun. So we went with something a little different: six thousand light-up arcade buttons acting as interactive pixels, controlled through a web page.
Then we had a thought. Wouldn’t it be even more fun if all developers, coders, and makers could build their own display running apps they created for it?
AnyPixel.js is an open-source software and hardware library created here at Google, making it possible to use the web to create big, unusual, interactive displays out of all kinds of things. Anyone can take and hack the code and the schematics to create their own display at any scale or level of expertise.
Find out more about the project, or how to create your own at goo.gl/anypixel.
With the announced expansion of Firebase at Google I/O recently, we also introduced Firebase Cloud Messaging (FCM) and Firebase Notifications (FN). As a developer, there are lots of updates that you might be able to take advantage of.
Despite the switch to FCM, we’ll continue to support Google Cloud Messaging on Android, iOS and the Web because we know that you have applications using the previous SDKs to handle notifications. However, all new client side features will be added to FCM SDKs moving forward. As such, we strongly recommend that you upgrade to the FCM SDKs. You can learn more about them here.
FCM supports everything that you’ve come to know with Google Cloud Messaging including addressing single devices, groups of devices or topics.
The FCM SDK simplifies client development. For example, you no longer need to write your own registration or subscription retry logic. When it comes to your server (if you still want to use one), updates to the endpoints and protocol don’t incur breaking changes, so as to maintain backwards compatibility. The updated details are available in the FCM Server documentation.
We’re investing heavily in making Firebase our unified mobile platform. We’re also continuing to expand our messaging platform beyond Android, including iOS and the Web. Firebase is well known for it’s cross-platform capabilities, so FCM is a natural fit for the ongoing Firebase releases. If you want to learn how to migrate your current app from Google Cloud Messaging to FCM, we’ve provided guides here for Android and iOS.
We think that Google Cloud Messaging will be even more useful to you when integrated into Firebase, including the new Firebase Notifications console. With that you’ll be able to send messages to apps directly from the console -- without you needing to build a messaging server.
To upgrade from Google Cloud Messaging to FCM or to learn more, see our guides for Android and iOS apps.
Posted by Posted by Fabian Schlup, Software Engineer
Two weeks ago, over 7,000 developers descended upon Mountain View for this year’s Google I/O, with a takeaway that it’s truly an exciting time for Search. People come to Google billions of times per day to fulfill their daily information needs. We’re focused on creating features and tools that we believe will help users and publishers make the most of Search in today’s world. As Google continues to evolve and expand to new interfaces, such as the Google assistant and Google Home, we want to make it easy for publishers to integrate and grow with Google.
In case you didn’t have a chance to attend all our sessions, we put together a recap of all the Search happenings at I/O.
1: Introducing rich cards
We announced rich cards, a new Search result format building on rich snippets, that uses schema.org markup to display content in an even more engaging and visual format. Rich cards are available in English for recipes and movies and we’re excited to roll out for more content categories soon. To learn more, browse the new gallery with screenshots and code samples of each markup type or watch our rich cards devByte.
2: New Search Console reports
We want to make it easy for webmasters and developers to track and measure their performance in search results. We launched a new report in Search Console to help developers confirm that their rich card markup is valid. In the report we highlight “enhanceable cards,” which are cards that can benefit from marking up more fields. The new Search Appearance filter also makes it easy for webmasters to filter their traffic by AMP and rich cards.
3: Real-time indexing
Users are searching for more than recipes and movies: they’re often coming to Search to find fresh information about what’s happening right now. This insight kickstarted our efforts to use real-time indexing to connect users searching for real-time events with fresh content. Instead of waiting for content to be crawled and indexed, publishers will be able to use the Google Indexing API to trigger the indexing of their content in real time. It’s still in its early days, but we’re excited to launch a pilot later this summer.
3: Getting up to speed with Accelerated Mobile Pages
We provided an update on our use of AMP, an open source effort to speed up the mobile web. Google Search uses AMP to enable instant-loading content. Speed is important---over 40% of users abandon a page that takes more than three seconds to load. We announced that we’re bringing AMPed news carousels to the iOS and Android Google apps, as well as experimenting with combining AMP and rich cards. Stay tuned for more via our blog and github page.
In addition to the sessions, attendees could talk directly with Googlers at the Search & AMP sandbox.
5: A new and improved Structured Data Testing Tool
App streaming is a new way for Android users to try out games without having to download and install the app -- and it’s already available in Google Search. Check out the session to learn more.
8. Revamped documentation
We also revamped our developer documentation, organizing our docs around topical guides to make it easier to follow.
Thanks to all who came to I/O -- it’s always great to talk directly with developers and hear about experiences first-hand. And whether you came in person or tuned in from afar, let’s continue the conversation on the webmaster forum or during our office hours, hosted weekly via hangouts-on-air.
