Posted:
Cross-posted from the Google Apps Developers Blog

Back in 2011, we launched Calendar APIv3, which offers developers several improvements over older versions of the API, including better support for recurring events and lightweight resource representation in JSON. At that same time, we also announced that the older versions of the API – v1 and v2 – would be entering a three-year deprecation period in order to give developers time to migrate to the new version. Those three years are coming to an end, and on November 17, the v1 and v2 endpoints will be shut down. If you haven’t already done so, you should migrate your application now to APIv3 so that it continues to work after that date (and to start taking advantage of all that the new API offers!).

For additional resources, check out our Migration and Getting started guides. And if you have questions or issues, please reach out to us on StackOverflow.com, using tag #google-calendar.

By Lucia Fedorova, Calendar API Team

Lucia Fedorova is a Tech Lead of the Google Calendar API team. The team focuses on providing a great experience to Google Calendar developers and enabling new and exciting integrations.

Posted by Louis Gray, Googler

Posted:
By Christian Robertson, Android Visual Designer

Along with the Material Design guidelines we released a new version of the Roboto type family. A lot of things have changed as we tuned the font to work across more screen sizes and conditions, from watches to desktops, televisions to cars. It still keeps much of its character that made it successful for both phones and tablets, but almost every glyph has been tweaked and updated in some way.

We see Roboto as an evolving type family and plan to continue to change and update it as the system evolves. It used to be that a type family was designed once and then used without change for many years. Sometimes an updated version was released with a new name, sometimes by appending a "Neue" or "New". The old model for releasing metal typefaces doesn't make sense for an operating system that is constantly improving. As the system evolves over time, the type should evolve along with it.

The easiest way to identify the new version is to look for the R and K. They were some of the rowdier glyphs from version one and have been completely redrawn. Also check for the dots on the letter i or in the punctuation. We have rounded them out to make the types a little more friendly when you look at them closely. We also rounded out the sides of the upper case characters like O and C which makes the font feel less condensed even though it still has a high character count per line.

Some of the most significant changes are in the rhythm and spacing, especially for the caps. This isn't apparent as you look at individual glyphs, but makes for a better texture on the screen. Some of the more subtle fixes were to balance the weights between the caps and lowercase characters (the caps are slightly heavier in this version) and better correction for the distortions that occur in the obliqued italic characters.

Ultimately the purpose of a typeface is to serve the content and help people to understand it. We think that the new updates to Roboto along with the new Material Design guidelines will help it do more of just that.

Posted by Louis Gray, Googler

Posted:
By Xiangye Xiao, Stuart Gill, and Jungshik Shin,
Google Text and Font Team, Internationalization Engineering


Chinese, Japanese and Korean (CJK) readers represent approximately one quarter of the world’s population. Google’s mission is to organize the world’s information and make it universally accessible to all users no matter what language they use. To that end, Google, in cooperation with our partner Adobe, has released a free, high-quality Pan-CJK font family: Noto Sans CJK. These fonts are intended to provide a richer and more beautiful reading experience to the East Asian community in many OSes and software applications.


Noto Sans CJK comprehensively covers Simplified Chinese, Traditional Chinese, Japanese, and Korean in a unified font family and yet conveys the expected aesthetic preferences of each language. Noto Sans CJK is a sans serif typeface designed as an intermediate style between the modern and traditional. It is intended to be a multi-purpose digital font for user interface designs, digital content, reading on laptops, mobile devices, and electronic books. Noto Sans CJK is provided in seven weights: Thin, Light, DemiLight, Regular, Medium, Bold, and Black.


Fully supporting CJK requires tens of thousands of characters—these languages share the majority of ideographic characters, but there are also characters that are unique to only one language or to a subset of the languages. One of the primary design goals of Noto Sans CJK is that each script should retain its own distinctive look, which follows regional conventions, while remaining harmonious with the others.

Chinese ideographic characters are not only used by Simplified and Traditional Chinese, where they are called hanzi, but also by Japanese (kanji) and Korean (hanja). Although all originated from ancient Chinese forms, in each region and language they evolved independently. As a result, the same character can vary in shape across the different languages. For example, the image below shows variants of the same character (骨 - bone) designed for Simplified Chinese, Traditional Chinese, Japanese, and Korean. Look at how the inner top part and inner bottom part are different. Noto Sans CJK is designed to take these variations into account. In addition to ideographic characters, Noto Sans CJK also supports Japanese kana and Korean Hangeul—both contemporary and archaic.


Google and Adobe partnered to develop this free high-quality Pan-CJK typeface. Google will release it as Noto Sans CJK as part of Google's Noto font family. Adobe will release it as Source Han Sans as a part of Adobe's Source family. Adobe holds the copyright to the typeface design, and the fonts are released under the Apache License, version 2.0 which makes them freely available to all without restriction.

About this partnership: Google contributed significant input into project direction, helped to define requirements, provided in-country testing resources and expertise, and provided funding that made this project possible. Adobe brought strong design and technical prowess to the table, along with proven in-country type design experience, massive coordination, and automation. In addition, three leading East Asian type foundries were also brought in to design and draw a bulk of the glyphs—Changzhou SinoType Technology, Iwata Corporation, and Sandoll Communication—due to the sheer size of the project and their local expertise.

Building Noto Sans CJK font is a major step towards our mission to make the reading experience beautiful for all users on all devices. Noto Sans CJK is the newest member of the Noto font family, which aims to support all languages in the world. The entire Noto font family, including Noto Sans CJK, is free and open. Visit the Noto homepage to download Noto Sans CJK and other Noto fonts.

Xiangye Xiao is a Product Manager at Google Inc. where she works on fonts and text input.
Stuart Gill is the Tech Lead and Manager of Google’s Text and Font team.

Jungshik Shin is the Noto visionary and is a Software Engineer in Google’s Internationalization Engineering team working on Text and Fonts as well as on Chrome.


Posted by Louis Gray, Googler

Posted:
Author Picture By Nadya Direkova, Staff Designer and Design Evangelist at Google[x]

At Google and throughout the industry, we all agree that two things matter: design and speed. But how can we do great design quickly? For our teams, one of our most important tools is the design sprint.

While a typical product design process takes months or years, a design sprint compresses this into a week or less. The design sprint combines key design and research methods and focuses on a single challenge or multiple challenges in parallel. It brings all the stakeholders—designers, developers, product managers, and other decision makers—into one place to work together on a short deadline. It often leads to insights and solutions more quickly than anyone thought possible. At Google, we've been using design sprints for over four years, from external projects like Ads, Glass and Project Loon to our internal tools.

One team has even run a huge sprint with 175 participants in 23 teams. How did that feel? As Cordell Ratzlaff, User Experience Director for Ads & Commerce, says: “When you participate in a sprint, you either win or you learn.” Our latest Google Design Minutes short tells this story:

Design sprints at scale: Cordell Ratzlaff and team on the importance of constraints

We’re really excited about sharing our design sprint methods more broadly. Design sprints were an important theme in the “Design, Develop, Distribute” message at Google I/O 2014, where developers got a chance to learn about and experience short sprints in person.

The design sprint: from Google Ventures to Google[x]; Daniel Burka, Jake Knapp, Nadya Direkova share insights with developers at Google I/O 2014

However, this was just a first glimpse; over the summer, we’ll be hosting design sprints for select developers in the Bay Area, helping developers design for platforms like Glass and Android Wear or build with the material design approach. To get updates when these limited-seating events become available, sign up here.

No matter what your challenge and design process, design sprints can help you reduce the time it takes to create great ideas. So make great things, and make them quickly!

Posted:
By Sarah Maddox, Google Developer Relations team

People love to know what's happening in their area of expertise around the world. What better way to show it, than on a map? Tech Comm on a Map puts technical communication tidbits onto an interactive map, together with the data and functionality provided by Google Maps.


I'm a technical writer at Google. In this post I share a project that uses the new Data layer in the Google Maps JavaScript API, with a Google Sheets spreadsheet as a data source and a location search provided by Google Places Autocomplete.

Although this project is about technical communication, you can easily adapt it for other special interest groups too. The code is on GitHub.

The map in action 

Visit Tech Comm on a Map to see it in action. Here's a screenshot:


The colored circles indicate the location of technical communication conferences, societies, groups and businesses. The 'other' category is for bits and pieces that don't fit into any of the categories. You can select and deselect the checkboxes at top left of the map, to choose the item types you're interested in.

When you hover over a circle, an info window pops up with information about the item you chose. If you click a circle, the map zooms in so that you can see where the event or group is located. You can also search for a specific location, to see what's happening there.

Let's look at the building blocks of Tech Comm on a Map.
Getting hold of a map

I'm using the Google Maps JavaScript API to display and interact with a map.

Where does the data come from?

When planning this project, I decided I want technical communicators to be able to add data (conferences, groups, businesses, and so on) themselves, and the data must be immediately visible on the map.

I needed a data entry and storage tool that provided a data entry UI, user management and authorization, so that I didn't have to code all that myself. In addition, contributors shouldn't need to learn a new UI or a new syntax in order to add data items to the map. I needed a data entry mechanism that is familiar to most people - a spreadsheet, for example.

In an episode of Google Maps Developer Shortcuts, Paul Saxman shows how to pull data from Google Drive into your JavaScript app. That's just what I needed. Here's how it works.

The data for Tech Comm on a Map is in a Google Sheets spreadsheet. It looks something like this:


Also in the spreadsheet is a Google Apps Script that outputs the data in JSON format:

var SPREADSHEET_ID = '[MY-SPREADSHEET-ID]';
var SHEET_NAME = 'Data';
function doGet(request) {
 var callback = request.parameters.jsonp;
 var range = SpreadsheetApp
     .openById(SPREADSHEET_ID)
     .getSheetByName(SHEET_NAME)
     .getDataRange();
 var json = callback + '(' +
     Utilities.jsonStringify(range.getValues()) + ')';
 
 return ContentService
     .createTextOutput(json)
     .setMimeType(ContentService.MimeType.JAVASCRIPT);
}


Follow these steps to add the script to the spreadsheet and make it available as a web service:
  1. In Google Sheets, choose 'Tools' > 'Script Editor'.
  2. Add a new script as a blank project.
  3. Insert the above code.
  4. Choose 'File' > 'Manage Versions', and name the latest version of the script.
  5. Choose 'Publish' >  'Deploy as web app'. Make it executable by 'anyone, even anonymous'. Note: This means anyone will be able to access the data in this spreadsheet via a script.
  6. Choose 'Deploy'.
  7. Copy the URL of the web service. You'll need to paste it into the JavaScript on your web page.

In your JavaScript, define a variable to contain the URL of the Google Apps script, and add the JSONP callback parameter:

var DATA_SERVICE_URL =
  "https://script.google.com/macros/s/[MY-SCRIPT-ID]/exec?jsonp=?";

Then use jQuery's Ajax function to fetch and process the rows of data from the spreadsheet. Each row contains the information for an item: type, item name, description, website, start and end dates, address, latitude and longitude.

$.ajax({
 url: DATA_SERVICE_URL,
 dataType: 'jsonp',
 success: function(data) {
   // Get the spreadsheet rows one by one.
   // First row contains headings, so start the index at 1 not 0.
   for (var i = 1; i < data.length; i++) {
     map.data.add({
       properties: {
         type: data[i][0],
         name: data[i][1],
         description: data[i][2],
         website: data[i][3],
         startdate: data[i][4],
         enddate: data[i][5],
         address: data[i][6]
       },
       geometry: {
         lat: data[i][7],
         lng: data[i][8]
       }
     });
   }
 }
});

The new Data layer in the Maps JavaScript API


Now that I could pull the tech comm information from the spreadsheet into my web page, I needed a way to visualize the data on the map. The new Data layer in the Google Maps JavaScript API is designed for just such a purpose. Notice the method map.data.add() in the above code. This is an instruction to add a feature in the Data layer.

With the basic JavaScript API you can add separate objects to the map, such as a polygon, a marker, or a line. But by using the Data layer, you can define a collection of objects and then manipulate and style them as a group. (The Data layer is also designed to play well with GeoJSON, but we don't need that aspect of it for this project.)

The tech comm data is represented as a series of features in the Data layer, each with a set of properties (type, name, address, etc) and a geometry (latitude and longitude).

Style the markers on the map, with different colors depending on the data type (conference, society, group, etc):


function techCommItemStyle(feature) {

 var type = feature.getProperty('type');

 var style = {

   icon: {
     path: google.maps.SymbolPath.CIRCLE,
     fillOpacity: 1,
     strokeWeight: 3,
     scale: 10        
   },
   // Show the markers for this type if
   // the user has selected the corresponding checkbox.
   visible: (checkboxes[type] != false)
 };

 // Set the marker colour based on type of tech comm item.
 switch (type) {
   case 'Conference':
     style.icon.fillColor = '#c077f1';
     style.icon.strokeColor = '#a347e1';
     break;
   case 'Society':
     style.icon.fillColor = '#f6bb2e';
     style.icon.strokeColor = '#ee7b0c';
     break;
. . . SNIPPED SOME DATA TYPES FOR BREVITY
   default:
     style.icon.fillColor = '#017cff';
     style.icon.strokeColor = '#0000ff';
 }
 return style;
}

Set listeners to respond when the user hovers over or clicks a marker. For example, this listener opens an info window on hover, showing information about the relevant data item:

 map.data.addListener('mouseover', function(event) {
   createInfoWindow(event.feature);
   infoWindow.open(map);
 });

The Place Autocomplete search


The last piece of the puzzle is to let users search for a specific location on the map, so that they can zoom in and see the events in that location. The location search box on the map is provided by the Place Autocomplete widget from the Google Places API.

What's next?


Tech Comm on a Map is an ongoing project. We technical communicators are using a map to document our presence in the world!

Would you like to contribute? The code is on GitHub.

Posted by Louis Gray, Googler

Posted:
Author PhotoBy Paul Kinlan, Staff Developer Advocate and tinkerer

Good News Everybody! DevArt has officially opened at the Barbican’s Digital Revolution Exhibition, the biggest exploration of digital creativity ever staged in the UK.

(Images - Andrew Meredith)

Technology has long gone hand in hand with art and with DevArt we’re showcasing the developers who use technology as their canvas and code as their raw material to create innovative, interactive digital art installations. Karsten Schmidt, Zach Lieberman, and duo Varvara Guljajeva and Mar Canet, have been commissioned by Google and the Barbican for Digital Revolution. Alongside these three commissions, a fourth - Cyril Diagne and Beatrice Lartigue - were handpicked as a result of DevArt’s global initiative to discover the interactive artists of tomorrow. You can also see their incredible art online and through our exhibition launch film here:


Play the World, 2014. Zach Lieberman [View on Github]
Using Google Compute Engine, Google Maps Geolocation API and openFrameworks, Zach has been able to find musical notes from hundreds of live radio stations around the world, resulting in a unique geo-orientated piece of music every time a visitor plays the piano at the centre of the piece.


Image by Andrew Meredith

Wishing Wall, 2014, Varvara Guljajeva & Mar Canet [View on Github]
Taking advantage of Google Compute Engine, Web Speech API, Chrome Apps, openFrameworks and node.js, Varvara and Mar are able to capture a whispered wish, and let you watch it transform before your eyes, allowing you to reach out and let it land on your hand.

Image by Andrew Meredith

Co(de) Factory, 2014, Karsten Schmidt [View on Github]
Android, Google Cloud Platform, Google Closure Compiler, WebGL, WebSockets, and YouTube have been combined by Karsten to allow anybody to create art and become an artist. It empowers people by giving them the tools to create, and offers them the chance to have their digital piece fabricated in 3D and showcased in the exhibition.

Image by Andrew Meredith

Les Métamorphoses de Mr. Kalia, 2014, Béatrice Lartigue and Cyril Diagne [View on Github]
Android, Chrome Apps, Google App Engine, node.js, openFrameworks have enabled Béatrice and Cyril to create tracking technology that transforms movement into a visual performance where visitors take on the persona of Mr. Kalia, a larger-than-life animated character, that undergoes a series of surreal changes while following your every movement.

Image by Andrew Meredith

DevArt will tour the world with the Digital Revolution Exhibition for up to five years following the Barbican show in London.

Soon we’re also starting our DevArt Young Creators program — an education component of DevArt designed to inspire a new generation of coders — each led by the DevArt interactive artists. Developed alongside the UK’s new computing curriculum, the workshops have been designed especially for students aged 9-13 years who have never tried coding before. Each workshop will be developed into lesson plans in-line with the UK’s new national computing curriculum, and distributed to educators by arts and technology organisations.

Paul Kinlan is a Developer Advocate in the UK on the Chrome team specialising on mobile. He lives in Liverpool and loves trying to progress the city's tech community from places like DoES Liverpool hack-space.

Posted by Louis Gray, Googler

Posted:
By Jason Polites, Cloud Platform Team

Many mobile apps today suffer from “app-nesia” — the affliction that causes an app to forget who you are. Have you ever re-installed an app only to discover you have to re-create all your carefully crafted preferences? This is typically because the user’s app data lives only on the device.

By connecting your apps to a backend platform, you can solve this issue, but it can be challenging. Whether it’s building basic plumbing, or just trying to load and save data in a network & battery-efficient way, spending time dealing with the backend can take precious time away from building an awesome app. So, we’re introducing two new features to help make your life easier.

Google Cloud Save
Google Cloud Save allows you to easily load and save user data to the cloud without needing to code up the backend. This is handy for situations where you want to save user state and have that state synchronized to multiple devices, or survive an app reinstall.

We handle all the backend logic as well as the synchronization services on the client. The synchronization services work in the background, providing offline support for the data, and minimizing impact on the battery. All you need to do is tell us when and what to save, and you do this with just 4 simple methods:
  • .save(client, List<Entity>)
  • .delete(client, Query)
  • .query(client, Query)
  • .requestSync(client)
All data is written locally first, then automatically synchronized in the background. The save, delete and query methods provide your basic CRUD operations while the requestSync method allows you to force a synchronization at any time. On the backend the data is stored in Google Cloud Datastore which means you can access the raw data directly from a Google App Engine or Google Compute Engine instance using the existing Datastore API. Changes on the server will even be automatically synced back to client devices. Importantly, this per-user data belongs to you, the developer, and stored in your own Google Cloud Datastore database. Cloud Save (3).png Google Cloud Save is currently in private beta and will be available for general use soon. If you’re interested in participating in the private beta, you can sign up here!

Cloud Tools for Android Studio
To simplify the process of adding an App Engine backend to your app, Android Studio now provides three App Engine backend module templates which you can add to your app:
  • App Engine Java Servlet Module - Minimal Backend
  • App Engine Java Endpoints Module - Basic Endpoint scaffolding 
  • App Engine with Google Cloud Messaging - Push notification wireup 
When you choose one of these template types your project is updated with a new Gradle module containing your new App Engine backend. All of the required dependencies/permissions will be automatically set up for you. Built-in rich editing support for Google Cloud Endpoints
Once you have added the backend module to your Android application, you can use Google Cloud Endpoints to streamline the communication between your backend and your Android app. Cloud Endpoints automatically generates strongly-typed, mobile optimized client libraries from simple Java server-side API annotations, automates Java object marshalling to and from JSON, and provides built-in OAuth 2.0 support.
On deployment, this annotated Endpoints API definition class generates a RESTful API. You can explore this generated API (and even make calls to it) by navigating to Endpoints API explorer as shown in the image below: api-explorer.png

To simplify calling this generated API from your Android app, Android Studio will automatically set up your project to include all compile dependencies and permissions required to consume Cloud Endpoints, and will re-generate strongly-typed client libraries if your backend changes. This means that you can start calling the client libraries from your Android app immediately after defining the server-side Endpoints API.
The underlying work-horses: Gradle, and Gradle plug-in for App Engine Under the hood, Gradle is used to build both your app and your App Engine backend. In fact, when you add an App Engine backend to your Android app, the open-source App Engine plug-in for Gradle is automatically downloaded by Android Studio, and common App Engine tasks become available as Gradle targets. This allows you to use the same build system across your IDE, command-line or continuous integration environments. Checkout more details on the new Cloud Endpoints features in Android Studio on the Android Developer Blog.

Posted by Louis Gray, Googler