Author Archives: Google Devs

Polymer Summit Livestream 2016

Posted by Taylor Savage, Product Manager, Polymer

Welcome to the Polymer Summit livestream 2016. Today, we’ll kick off with a keynote about how the core Polymer team is thinking about the project’s past, present, and future. We’ll follow with a full day of sessions covering every aspect of building great web applications using Polymer, including a unique new Polymer experience, and thoughts from our partners. Tune into the livestream below to follow along. We look forward to engaging in the conversation with you at #PolymerSummit.


Blockly for iOS

Posted by Champika Fernando, Product Manager, Kids Coding

At Google I/O, we announced our ongoing investment in Blockly with the release of a native Android version. We also highlighted significant improvements to the performance of web Blockly, which enables better rendering performance on mobile devices. Now iOS developers will have access to an open-source developer preview of Blockly for iOS that supports building better experiences on mobile, including multi-touch and enhanced animations as new experimental features.

Today’s release supports our ongoing efforts to enable developers to create consistent, high-quality, beginner programming experiences - as block-based programming interfaces can make coding more accessible by removing syntax errors and supporting “tinkerability.” We believe that coding is more than just a set of technical skills; coding is a valuable tool for everyone, empowering users from around the globe to imagine, invent, and explore.

Blockly Turtle running on iOS

With Blockly for iOS, developers can add Blockly views and fragments directly into their iOS app. This will offer tighter integration and improved performance compared to using a WebView. In this developer preview, blocks are currently optimized for tablets, but ready to customize for any app.

In addition, if you already use Blockly we're releasing a major update to the tools for creating custom blocks and configuring Blockly for your app, check out the new Blockly Developer Tools. The new tools allow you to edit and maintain a library of custom blocks, quickly configure toolboxes, and export and import files to local storage.

Click here to learn more, and get started on Blockly for iOS today. And to share feedback and get news, we welcome you to join the Blockly mailing list. We look forward to seeing your future builds!

Announcing Google Code-in 2016 and Google Summer of Code 2017

Posted by Josh Simmons, Open Source Programs Office

One of the goals of the Open Source Programs Office is to encourage more people to contribute to open source software. One way we achieve that goal is through our student programs, Google Summer of Code (for university students) and Google Code-in (for pre-university students).

Over 15,000 students from more than 100 countries have worked with 23,000 mentors and contributed to 560+ open source projects.

This is why we’re excited to announce the next round of both of our student programs!

Google Code-in begins for students November 28, 2016

For the seventh consecutive year, Google Code-in will give students (ages 13-17) a chance to explore open source. Students will find opportunities to learn and get hands on experience with tasks from a range of categories. This structure allows students to stretch themselves as they take on increasingly more challenging tasks.

Getting started is easy: once the contest begins, simply choose an interesting task from our participating organizations’ lists and complete it. Mentors from the organizations are available to help online.

Google Code-in is for students asking questions like:

  • What is open source?
  • What kinds of stuff do open source projects do?
  • How can I write real code when all I’ve done is a little classroom work?
  • Can I contribute even if I’m not really a programmer?

With tasks in five different categories, there’s something to fit almost any student’s skills:

  • Code: writing or refactoring
  • Documentation/Training: creating/editing documents and helping others learn more
  • Outreach/research: community management, outreach/marketing, or studying problems and recommending solutions
  • Quality Assurance: testing and ensuring code is of high quality
  • User Interface: user experience research or user interface design and interaction

Google Summer of Code student applications open on March 20, 2017

Google Summer of Code (GSoC) provides university students from around the world with an opportunity to take their skills and hone them by contributing to open source projects during their summer break from university.

Students gain invaluable experience working with mentors on these open source software projects, earning a stipend upon successful completion of their project.

We’re proud to keep this tradition going: we’ll be opening student applications for Google Summer of Code 2017 on March 20, 2017. Applications for interested open source organizations open on January 19, 2017.

Students, it’s never too early to start preparing or thinking about your proposal. You can learn about the organizations that participated in Google Summer of Code 2016 and the projects students worked on. We also encourage you to explore other resources like the student and mentor manuals and frequently asked questions.

You can learn more on the program website.

Share the news with your friends and stay tuned, more details are coming soon!

Get Ready for the Polymer Summit 2016

Posted by Taylor Savage

The Polymer Summit is almost here! We’ll kick off live from Tobacco Dock, London at 10:00AM GMT this coming Monday, October 17th. To get the most out of the event, make sure to check out the speaker list and talk schedule on our site.

Can’t join us in person? Don’t worry, we’ve got you covered! You can tune into the summit live on www.polymer-project.org/summit. We will stream the keynote and all sessions over the course of the event. If you want us to send you a reminder to tune into the livestream, sign up here.

Subscribe to the Chrome Developers YouTube Channel to stay up to date as we’ll be publishing all of the talks from the event here.

We’re looking forward to seeing you in person or remotely on Tuesday. Don’t forget to join the social conversations at #PolymerSummit.

An open source font system for everyone

Posted by Xiangye Xiao and Bob Jung, Internationalization

A big challenge in sharing digital information around the world is “tofu”—the blank boxes that appear when a computer or website isn’t able to display text: ⯐. Tofu can create confusion, a breakdown in communication, and a poor user experience.

Five years ago we set out to address this problem via the Noto—aka “No more tofu”—font project. Today, Google’s open-source Noto font family provides a beautiful and consistent digital type for every symbol in the Unicode standard, covering more than 800 languages and 110,000 characters.

Caption: A few samples of the 110,000+ characters covered by Noto fonts.

The Noto project started as a necessity for Google’s Android and ChromeOS operating systems. When we began, we did not realize the enormity of the challenge. It required design and technical testing in hundreds of languages, and expertise from specialists in specific scripts. In Arabic, for example, each character has four glyphs (i.e., shapes a character can take) that change depending on the text that comes after it. In Indic languages, glyphs may be reordered or even split into two depending on the surrounding text.

The key to achieving this milestone has been partnering with experts in the field of type and font design, including Monotype, Adobe, and an amazing network of volunteer reviewers. Beyond “no more tofu” in the common languages used every day, Noto will be used to preserve the history and culture of rare languages through digitization. As new characters are introduced into the Unicode standard, Google will add these into the Noto font family.

Google has a deep commitment to openness and the accessibility and innovation that come with it. The full Noto font family, design source files, and the font building pipeline are available for free at the links below. In the spirit of sharing and communication across borders and cultures, please use and enjoy!

Noto fonts download: https://www.google.com/get/noto
Font building pipeline: https://github.com/googlei18n/fontmake.

Design is a Dialogue: Sharing Material Design to Japan and beyond

Posted by Matias Duarte, ‎VP, Material Design at Google

As a child I was surrounded by the commercial design and pop-cultural art of Japan. I played with Transformer robot toys, pumped quarters into Pac-Man and Donkey Kong, watched Star Blazers (Yamato) and Robotech (Macross) cartoons after school, and listened to mix-tapes on my Sony Walkman.

In art school, I became fascinated by the creative dialog of the late 1800s, where western artists drew inspiration from their peers in Asia. The flattening of perspective and embrace of the two-dimensional graphic qualities of the image were revolutionary at the time, and would lay the foundation for the great modernist movements of painting and design in the West.

These influences can be found in Material Design, our comprehensive system for visual, motion, and interaction design across all platforms and all devices. Material Design continues to evolve but, at its core, it relies on the foundations of good graphic and print design – clear typography, systematic layout, thoughtful application of scale, intentional use of color and white space, and foreground imagery. Working together these elements do far more than please the eye. They create hierarchy, meaning, and focus attention on content.

Yesterday, I was in Tokyo to host SPAN, our annual design event that engages the many ways design and technology shape our everyday lives. SPAN Tokyo provides us with an opportunity to honor the influence of Japanese art and culture on Material Design, as we highlight the most inspiring local designers and broader creative community. In anticipation of the event, we have translated our Material Design Guidelines into Japanese which we are please to announce are available for download starting today (material.google.com/jp). This document is a first step towards making Material Design a conversation that includes our Japanese friends. Furthermore, it is a symbol of our commitment to continuing this dialog of design throughout Asia.

With that in mind, we’ve organized SPAN Tokyo to feature a broad range of practitioners contributing to the contemporary visual cultural happening in Japan today—from art generated through machine learning and neural networks, to start-up culture, ikebana, type design, and much more. We’re honored to have been joined by this esteemed group of speakers, including London Design Museum director Deyan Sudjic, illustrator Mariya Suzuki, artist Keiichi Tanaami, and many more.

To recap yesterday's conference and stay up to date on future events, follow us on Twitter, Google+, Facebook, and sign up for the Google Design Newsletter.

The Native Way: Everything you Need to Know About Native Ads

Originally posted on Inside AdMob blog
Posted by Chris Jones, Social Team, AdMob.
Native is the next big thing in mobile advertising with spending on native ads expected to grow to $21 billion in 2018. This is a huge potential opportunity for app developers, but how can you use native ads to help boost your UX and monetize your app? Here’s a quick overview of what native advertising is, and how you can get started.

What’s Native?
Native advertisements match both the form and function of the user experience in which they’re placed. They also match the visual design of the app they live within. Native ads augment the user experience by providing value through relevant ads that flow within the context of surrounding app content. Put simply; native ads fit in.


Native advertising isn’t a new thing.
Since the golden days of wireless radio and daily newspapers, advertisers have looked for innovative ways to match up their brands and messages with the environment in which they’re served to consumers. In the digital advertising world, Google was one of the first “native” advertisers, developing search ads that directly matched the information on the search results page.

But today, consumers are everywhere.
And we’ve had to adapt; delivering higher quality content that can flex to different screens and sizes. For example, mobile-optimized websites now have big buttons and fonts and mobile apps let users scroll up and down or left and right, rather than having to click through to the pages they want to view. Native also understands that preserving that user experience is vital to successful advertising.

Our content has evolved, and our ads need to follow.
Nobody likes their app experience to be side-swiped by an obtrusive, ugly ad. Native advertising offers a simple solution: ads that fit the form and function of a developer’s content. We help you create ads that are beautiful and engaging, so consumers can maintain their good buzz.

Native ads are cohesive.
They never stand out like a sore thumb. They’re made to match the look and feel of the app, and are consistent with platform behavior, so that the viewer feels like the ad fits seamlessly with their content experience. In other words - they’re ads with UX in mind.

Get started - In 5 easy steps:
  1. Sign in to your AdMob account at https://apps.admob.com
  2. Click the Monetize tab/All apps/+ new ad unit/Native
  3. Choose from a variety of ad sizes,  templates and types 
  4. Customize them to fit within your app’s UI 
  5. Drop a few lines of code in your app to request your new native ads. Too easy!
For more on creating a native ad, check out our help center or head here.
Sign up for AdMob <Graphic>

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

Key Improvements for Your API Experience

Posted by Israel Shalom, Product Manager

Here at Google, we’re serving more than a hundred APIs to ensure that developers have the resources to build amazing experiences with them. We provide a reliable infrastructure and make it as simple as possible so developers can focus on building the future. With this in mind, we’re introducing a few improvements for the API experience: more flexible keys, a streamlined 'getting-started' experience, and easy monitoring.

Faster, more flexible key generation

Keys are a standard way for APIs to identify callers, and one of the very first steps in interacting with a Google API. Tens of thousands of keys are created every day for Google APIs, so we’re making this step simpler -- reducing the old multi-step process with a single click:

You no longer need to choose your platform and various other restrictions at the time of creation, but we still encourage scope managementas a best practice:

Streamlined getting started flow

We realize that many developers want to get straight to creation and don’t necessarily want to step into the console. We’ve just introduced an in-flow credential set up procedure directly embedded within the developer documentation:

Click the 'Get a Key' button, choose or create a project, and then let us take care of enabling the API and creating a key.

We are currently rolling this out for the Google Maps APIs and over the next few months we'll bring it to the rest of our documentation.

API Dashboard

We’re not just making it easier to get started, we’re simplifying the on-going usage experience, too. For developers who use one or more APIs frequently, we've built the new API Dashboard to easily view usage and quotas.

If you’ve enabled any APIs, the dashboard is front and center in the API Console. There you can view all the APIs you’re using along with usage, error and latency data:

Clicking on an API will jump to a detailed report, where you’ll see the traffic sliced by methods, credentials, versions and response code (available on select APIs):

We hope these new features make your API usage easier, and we can't wait to see what you’re going to build next!

Using BigQuery and Firebase Analytics to understand your mobile app

Originally posted on Google Cloud Platform Blog

At Google I/O this May, Firebase announced a new suite of products to help developers build mobile apps. Firebase Analytics, a part of the new Firebase platform, is a tool that automatically captures data on how people are using your iOS and Android app, and lets you define your own custom app events. When the data's captured, it’s available through a dashboard in the Firebase console. One of my favorite cloud integrations with the new Firebase platform is the ability to export raw data from Firebase Analytics to Google BigQuery for custom analysis. This custom analysis is particularly useful for aggregating data from the iOS and Android versions of your app, and accessing custom parameters passed in your Firebase Analytics events. Let’s take a look at what you can do with this powerful combination.

How does the BigQuery export work?


After linking your Firebase project to BigQuery, Firebase automatically exports a new table to an associated BigQuery dataset every day. If you have both iOS and Android versions of your app, Firebase exports the data for each platform into a separate dataset. Each table contains the user activity and demographic data automatically captured by Firebase Analytics, along with any custom events you’re capturing in your app. Thus, after exporting one week’s worth of data for a cross-platform app, your BigQuery project would contain two datasets, each with seven tables:


Diving into the data


The schema for every Firebase Analytics export table is the same, and we’ve created two datasets (one for iOS and one for Android) with sample user data for you to run the example queries below. The datasets are for a sample cross-platform iOS and Android gaming app. Each dataset contains seven tables  one week’s worth of analytics data.

The following query will return some basic user demographic and device data for one day of usage on the iOS version of our app:

SELECT
user_dim.app_info.app_instance_id,
user_dim.device_info.device_category,
user_dim.device_info.user_default_language,
user_dim.device_info.platform_version,
user_dim.device_info.device_model,
user_dim.geo_info.country,
user_dim.geo_info.city,
user_dim.app_info.app_version,
user_dim.app_info.app_store,
user_dim.app_info.app_platform
FROM
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]

Since the schema for every BigQuery table exported from Firebase Analytics is the same, you can run any of the queries in this post on your own Firebase Analytics data by replacing the dataset and table names with the ones for your project.

The schema has user data and event data. All user data is automatically captured by Firebase Analytics, and the event data is populated by any custom events you add to your app. Let’s take a look at the specific records for both user and event data.

User data


The user records contain a unique app instance ID for each user (user_dim.app_info.app_instance_id in the schema), along with data on their location, device and app version. In the Firebase console, there are separate dashboards for the app’s Android and iOS analytics. With BigQuery, we can run a query to find out where our users are accessing our app around the world across both platforms. The query below makes use of BigQuery’s union feature, which lets you use a comma as a UNION ALL operator. Since a row is created in our table for each bundle of events a user triggers, we use EXACT_COUNT_DISTINCT to make sure each user is only counted once:
SELECT
user_dim.geo_info.country as country,
EXACT_COUNT_DISTINCT( user_dim.app_info.app_instance_id ) as users
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601],
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]
GROUP BY
country
ORDER BY
users DESC

User data also includes a user_properties record, which includes attributes you define to describe different segments of your user base, like language preference or geographic location. Firebase Analytics captures some user properties by default, and you can create up to 25 of your own.

A user’s language preference is one of the default user properties. To see which languages our users speak across platforms, we can run the following query:

SELECT
user_dim.user_properties.value.value.string_value as language_code,
EXACT_COUNT_DISTINCT(user_dim.app_info.app_instance_id) as users,
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601],
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]
WHERE
user_dim.user_properties.key = "language"
GROUP BY
language_code
ORDER BY
users DESC

Event data


Firebase Analytics makes it easy to log custom events such as tracking item purchases or button clicks in your app. When you log an event, you pass an event name and up to 25 parameters to Firebase Analytics and it automatically tracks the number of times the event has occurred. The following query shows the number of times each event in our app has occurred on Android for a particular day:

SELECT 
event_dim.name,
COUNT(event_dim.name) as event_count
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601]
GROUP BY
event_dim.name
ORDER BY
event_count DESC

If you have another type of value associated with an event (like item prices), you can pass it through as an optional value parameter and filter by this value in BigQuery. In our sample tables, there is a spend_virtual_currency event. We can write the following query to see how much virtual currency players spend at one time:

SELECT 
event_dim.params.value.int_value as virtual_currency_amt,
COUNT(*) as num_times_spent
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601]
WHERE
event_dim.name = "spend_virtual_currency"
AND
event_dim.params.key = "value"
GROUP BY
1
ORDER BY
num_times_spent DESC

Building complex queries


What if we want to run a query across both platforms of our app over a specific date range? Since Firebase Analytics data is split into tables for each day, we can do this using BigQuery’s TABLE_DATE_RANGE function. This query returns a count of the cities users are coming from over a one week period:

SELECT
user_dim.geo_info.city,
COUNT(user_dim.geo_info.city) as city_count
FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
GROUP BY
user_dim.geo_info.city
ORDER BY
city_count DESC

We can also write a query to compare mobile vs. tablet usage across platforms over a one week period:

SELECT
user_dim.app_info.app_platform as appPlatform,
user_dim.device_info.device_category as deviceType,
COUNT(user_dim.device_info.device_category) AS device_type_count FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
GROUP BY
1,2
ORDER BY
device_type_count DESC

Getting a bit more complex, we can write a query to generate a report of unique user events across platforms over the past two weeks. Here we use PARTITION BY and EXACT_COUNT_DISTINCT to de-dupe our event report by users, making use of user properties and the user_dim.user_id field:

SELECT 
STRFTIME_UTC_USEC(eventTime,"%Y%m%d") as date,
appPlatform,
eventName,
COUNT(*) totalEvents,
EXACT_COUNT_DISTINCT(IF(userId IS NOT NULL, userId, fullVisitorid)) as users
FROM (
SELECT
fullVisitorid,
openTimestamp,
FORMAT_UTC_USEC(openTimestamp) firstOpenedTime,
userIdSet,
MAX(userIdSet) OVER(PARTITION BY fullVisitorid) userId,
appPlatform,
eventTimestamp,
FORMAT_UTC_USEC(eventTimestamp) as eventTime,
eventName
FROM FLATTEN(
(
SELECT
user_dim.app_info.app_instance_id as fullVisitorid,
user_dim.first_open_timestamp_micros as openTimestamp,
user_dim.user_properties.value.value.string_value,
IF(user_dim.user_properties.key = 'user_id',user_dim.user_properties.value.value.string_value, null) as userIdSet,
user_dim.app_info.app_platform as appPlatform,
event_dim.timestamp_micros as eventTimestamp,
event_dim.name AS eventName,
event_dim.params.key,
event_dim.params.value.string_value
FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
), user_dim.user_properties)
)
GROUP BY
date, appPlatform, eventName

If you have data in Google Analytics for the same app, it’s also possible to export your Google Analytics data to BigQuery and do a JOIN with your Firebase Analytics BigQuery tables.


Visualizing analytics data


Now that we’ve gathered new insights from our mobile app data using the raw BigQuery export, let’s visualize it using Google Data Studio. Data Studio can read directly from BigQuery tables, and we can even pass it a custom query like the ones above. Data Studio can generate many different types of charts depending on the structure of your data, including time series, bar charts, pie charts and geo maps.

For our first visualization, let’s create a bar chart to compare the device types from which users are accessing our app on each platform. We can paste the mobile vs. tablet query above directly into Data Studio to generate the following chart:
From this chart, it’s easy to see that iOS users are much more likely to access our game from a tablet. Getting a bit more complex, we can use the above event report query to create a bar chart comparing the number of events across platforms:
Check out this post for detailed instructions on connecting your BigQuery project to Data Studio.

What’s next?

If you’re new to Firebase, get started here. If you’re already building a mobile app on Firebase, check out this detailed guide on linking your Firebase project to BigQuery. For questions, take a look at the BigQuery reference docs and use the firebase-analytics and google-bigquery tags on Stack Overflow. And let me know if there are any particular topics you’d like me to cover in an upcoming post.

How to set up Ads on your AMP Pages

Posted by Arudea Mahartianto, Google AMP Specialist

From conception, the open source Accelerated Mobile Pages Project has had a clear goal --- to make the mobile web experience better and faster for users. This extends beyond content to creating a user-first approach to advertising as well.

To realize this vision, the AMP team created an advertising solution that follows four core principles:

  • Faster is better - There is no reason ads in AMP can’t be as fast as the AMP document itself.
  • Beautiful matters - Ensure ads in AMP are beautiful and relevant.
  • Security is a must - Require all creatives to utilize the HTTPS protocol.
  • We’re better together - AMP isn’t about supporting a single advertising entity, but an entire industry. Success requires broad industry participation.

Ads in AMP are delivered using the amp-ad component. Using this component you can configure your ads in a number of ways such as the width, length, layout mode and ad loading strategy. Different ad networks might allow even more options.

Here is an example of an DoubleClick responsive ad implementation in AMP:

<amp-ad
width="414"
height="457"
layout=”responsive”
type="doubleclick"
data-slot="/35096353/amptesting/image/flex">
</amp-ad>

The type attribute informs the amp-ad component which ad platform to use. In this case we want DoubleClick and therefore the type value is doubleclick. For above the fold responsive ad implementation please use layout="fixed-height" instead and limit the ad height so users will get a fast loading content-focused experience from the very start.

Any attributes starting with data- in amp-ad are ad platform-specific attributes, including the data-slot attribute in the snippet above. Each ad platform will have different attributes available to configure. For example, compare the above DoubleClick example with another AMP ad example that uses the Rubicon platform:

<amp-ad width=320 height=50
type="rubicon"
data-method="smartTag"
data-account="14062"
data-site="70608"
data-zone="335918"
data-size="43">
</amp-ad>

For more amp-ad implementation examples, please check out AMP By Example. You can also check out the amp-ad documentation for the complete list of supported ad networks and their configuration semantics.

The team is also developing newer, better ways to bring the benefits of AMP to the ads ecosystem with initiatives like AMP for Ads and AMP Ad Landing Pages. These solutions will enable advertisers to design creatives and ad landing pages that are more consistent with the AMP experience publishers are bringing to users. We believe this will bring us closer to the goal of making the entire mobile web experience faster and better for everybody.