Posted by Wesley Chun (@wescpy), Developer Advocate, G Suite
It's common knowledge that presentations utilize a set of images to impart ideas to the audience. As a result, one of the best practices for creating great slide decks is to minimize the overall amount of text. It means that if you do have text in a presentation, the (few) words you use must have higher impact and be visually appealing. This is even more true when the slides are generated by a software application, say using the Google Slides API, rather than being crafted by hand.
The G Suite team recently launched the first Slides API, opening up a whole new category of applications. Since then, we've published several videos to help you realize some of those possibilities, showing you how to replace text and images in slides as well as how to generate slides from spreadsheet data. To round out this trifecta of key API use cases, we're adding text formatting to the conversation.
Developers manipulate text in Google Slides by sending API requests. Similar to the Google Sheets API, these requests come in the form of JSON payloads sent to the API's batchUpdate() method. Here's the JavaScript for inserting text in some shape (shapeID) on a slide:
batchUpdate()
shapeID
{ "insertText": { "objectId": shapeID, "text": "Hello World!\n" }
In the video, developers learn that writing text, such as the request above, is less complex than reading or formatting because both the latter require developers to know how text on a slide is structured. Notice for writing that just the copy, and optionally an index, are all that's required. (That index defaults to zero if not provided.)
Assuming "Hello World!" has been successfully inserted in a shape on a slide, a request to bold just the "Hello" looks like this:
{ "updateTextStyle": { "objectId": shapeID, "style": { "bold": true }, "textRange": { "type": "FIXED_RANGE", "startIndex": 0, "endIndex": 5 }, "fields": "bold" }
requests
SLIDES
deckID)
SLIDES.presentations().batchUpdate(presentationId=deckID, body=requests).execute()
To better understand text structure & styling in Google Slides, check out the text concepts guide in the documentation. For a detailed look at the complete code sample featured in the DevByte, check out the deep dive post. To see more samples for common API operations, take a look at this page. We hope the videos and all these developer resources help you create that next great app that automates producing highly impactful presentations for your users!
Posted by Wayne Piekarski, Developer Advocate for IoT
The Internet of Things (IoT) will bring computing to a whole new range of devices. Today we're announcing two important updates to our IoT developer platform to make it faster and easier for you to create these smart, connected products.
We're releasing a Developer Preview of Android Things, a comprehensive way to build IoT products with the power of Android, one of the world's most supported operating systems. Now any Android developer can quickly build a smart device using Android APIs and Google services, while staying highly secure with updates direct from Google. We incorporated the feedback from Project Brillo to include familiar tools such as Android Studio, the Android Software Development Kit (SDK), Google Play Services, and Google Cloud Platform. And in the coming months, we will provide Developer Preview updates to bring you the infrastructure for securely pushing regular OS patches, security fixes, and your own updates, as well as built-in Weave connectivity and more.
There are several turnkey hardware solutions available for you to get started building real products with Android Things today, including Intel Edison, NXP Pico, and Raspberry Pi 3. You can easily scale to large production runs with custom designs of these solutions, while continuing to use the same Board Support Package (BSP) from Google.
We are also updating the Weave platform to make it easier for all types of devices to connect to the cloud and interact with services like the Google Assistant. Device makers like Philips Hue and Samsung SmartThings already use Weave, and several others like Belkin WeMo, LiFX, Honeywell, Wink, TP-Link, and First Alert are implementing it. Weave provides all the cloud infrastructure, so that developers can focus on building their products without investing in cloud services. Weave also includes a Device SDK for supported microcontrollers and a management console. The Weave Device SDK currently supports schemas for light bulbs, smart plugs and switches, and thermostats. In the coming months we will be adding support for additional device types, custom schemas/traits, and a mobile application API for Android and iOS. Finally, we're also working towards merging Weave and Nest Weave to enable all classes of devices to connect with each other in a secure and reliable way. So whether you started with Google Weave or Nest Weave, there is a path forward in the ecosystem. This is just the beginning of the IoT ecosystem we want to build with you. To get started, check out Google's IoT developer site, or go directly to the Android Things, Weave, and Google Cloud Platform sites for documentation and code samples. You can also join Google's IoT Developers Community on Google+ to get the latest updates and share and discuss ideas with other developers.
Posted by Jason Douglas, PM Director for Actions on Google
The Google Assistant brings together all of the technology and smarts we've been building for years, from the Knowledge Graph to Natural Language Processing. To be a truly successful Assistant, it should be able to connect users across the apps and services in their lives. This makes enabling an ecosystem where developers can bring diverse and unique services to users through the Google Assistant really important.
In October, we previewed Actions on Google, the developer platform for the Google Assistant. Actions on Google further enhances the Assistant user experience by enabling you to bring your services to the Assistant. Starting today, you can build Conversation Actions for Google Home and request to become an early access partner for upcoming platform features.
Conversation Actions for Google Home
Conversation Actions let you engage your users to deliver information, services, and assistance. And the best part? It really is a conversation -- users won't need to enable a skill or install an app, they can just ask to talk to your action. For now, we've provided two developer samples of what's possible, just say "Ok Google, talk to Number Genie " or try "Ok Google, talk to Eliza' for the classic 1960s AI exercise.
You can get started today by visiting the Actions on Google website for developers. To help create a smooth, straightforward development experience, we worked with a number of development partners, including conversational interaction development tools API.AI and Gupshup, analytics tools DashBot and VoiceLabs and consulting companies such as Assist, Notify.IO, Witlingo and Spoken Layer. We also created a collection of samples and voice user interface (VUI) resources or you can check out the integrations from our early access partners as they roll out over the coming weeks.
Coming soon: Actions for Pixel and Allo + Support for Purchases and Bookings
Today is just the start, and we're excited to see what you build for the Google Assistant. We'll continue to add more platform capabilities over time, including the ability to make your integrations available across the various Assistant surfaces like Pixel phones and Google Allo. We'll also enable support for purchases and bookings as well as deeper Assistant integrations across verticals. Developers who are interested in creating actions using these upcoming features should register for our early access partner program and help shape the future of the platform.
Posted by John Coiner, Software Engineer
Today we are announcing a change to the domain scheme of the Google AMP Cache. Beginning soon, the Google AMP Cache will serve each site from its own subdomain of https://cdn.ampproject.org. This change will allow content served from the Google AMP Cache to be protected by the fundamental security model of the web: the HTML5 origin.
https://cdn.ampproject.org
No immediate changes are required for most publishers of AMP documents. However, to benefit from the additional security, it is recommended that all AMP publishers update their CORS implementation in preparation for the new Google AMP Cache URL scheme. The Google AMP Cache will continue to support existing URLs, but those URLs will eventually redirect to the new URL scheme.
The subdomains created by the Google AMP Cache will be human-readable when character limits and technical specs allow, and will closely resemble the publisher's own domain.
When possible, the Google AMP Cache will create each subdomain by first converting the AMP document domain from IDN (punycode) to UTF-8. Every "-" (dash) will be replaced with "--"(2 dashes) and every "." (dot) will be replaced with a "-" (dash). For example, pub.com will map to pub-com.cdn.ampproject.org. Where technical limitations prevent a human readable subdomain, a one-way hash will be used instead.
pub.com
pub-com.cdn.ampproject.org
Due to the changes described above, CORS endpoints will begin seeing requests with new origins. The following updates will be required:
https://[pub-com].cdn.ampproject.org
https://*.ampproject.org
https://ampbyexample-com.cdn.ampproject.org
For platforms that display AMP documents and serve from the Google AMP Cache, the best way to retrieve Google AMP Cache URLs is to continue using the Google AMP Cache URL API. The Google AMP Cache URL API will be updated in Q1 2017 to return the new cache URL scheme that includes the subdomain.
You can use an interactive tool to find the Google AMP Cache subdomain generated for each site over at ampbyexample.com.
Google Search is planning to begin using the new URL scheme as soon as possible and is monitoring sites' compatibility.
In addition, a developer testing sandbox is available at g.co/ampdemo/cache to help ensure a smooth transition. After making the updates described above, please use the sandbox to test accessing your site via Google Search. The sandbox loads AMP pages using the new domain scheme, so if you spot CORS-related errors in this configuration, these issues should be addressed to avoid errors when the domain scheme change is fully rolled out.
The G Suite team recently launched the very first Google Slides API, opening up a whole new set of possibilities, including leveraging data already sitting in a spreadsheet or database, and programmatically generating slide decks or slide content based on that data. Why is this a big deal? One of the key advantages of slide decks is that they can take database or spreadsheet data and make it more presentable for human consumption. This is useful when the need arises to communicate the information reflected by that data to management or potential customers.
Walking developers through a short application demonstrating both the Sheets and Slides APIs to make this happen is the topic of today's DevByte video. The sample app starts by reading all the necessary data from the spreadsheet using the Sheets API. The Slides API takes over from there, creating new slides for the data, then populating those slides with the Sheets data.
Developers interact with Slides by sending API requests. Similar to the Google Sheets API, these requests come in the form of JSON payloads. You create an array like in the JavaScript pseudocode below featuring requests to create a cell table on a slide and import a chart from a Sheet:
sheetID
chartID
slideID
presentations().batchUpdate()
Creating tables is fairly straightforward. Creating charts has some magical features, one of those being the linkingMode. A value of "LINKED" means that if the Sheet data changes (altering the chart in the Sheet), the same chart in a slide presentation can be refreshed to match the latest image, either by the API or in the Slides user interface! You can also request a plain old static image that doesn't change with the data by selecting a value of "NOT_LINKED_IMAGE" for linkingMode. More on this can be found in the documentation on creating charts, and check out the video where you'll see both those API requests in action.
linkingMode
For a detailed look at the complete code sample featured in the video, check out the deep dive post. We look forward to seeing the interesting integrations you build with the power of both APIs!
Native support for TensorFlow on Windows was one of the first requests we received after open-sourcing TensorFlow. Although some Windows users have managed to run TensorFlow in a Docker container, we wanted to provide a more complete experience including GPU support.
With the release of TensorFlow r0.12, we now provide a native TensorFlow package for Windows 7, 10, and Server 2016. This release enables you to speed up your TensorFlow training with any GPU that runs CUDA 8.
We have published the latest release as a pip package in PyPI, so now you can install TensorFlow with a single command:
And for GPU support:
More details about Windows support and all of the other new features in r0.12 are included in the release notes.
We're excited to offer more people the opportunity to use TF at maximum speed. Follow us on Twitter to be the first to hear about future releases – we're @tensorflow.
Acknowledgements
Many people have contributed to making this release possible. In particular, we'd like to thank Guenther Schmuelling and Vit Stepanovs from Microsoft for their significant contributions to Windows support.
Posted by Paul Kinlan, Chrome Developer Relations
Chrome Dev Summit is almost here! We'll kick off live from San Francisco at the SFJAZZ Center, at 10:00 AM PT this coming Thursday, Nov 10th. This year's summit will focus on key themes that matter to you: Progressive, to build high quality web apps; Performance, to increase user engagement; and What's Next, a look at how the Chrome team is thinking about the future of the web.
While we're putting the finishing touches on the keynote, sessions, and code labs, we wanted to provide you with some tips to get ready to experience Chrome Dev Summit, either in-person or via the livestream.
Navigate the summit with notifications
To get the most out of Chrome Dev Summit, make sure to check out the schedule and set up notifications for the sessions you don't want to miss. These will help you plan your schedule whether you're in person or tuning in via the livestream.
Can't join us in person?
Don't worry, we've got you covered! Here are some ways you can connect with Chrome Dev Summit in real-time:
We're looking forward to having you with us you for 2 days of web fun, soon!
Don't forget to join the social conversation at #ChromeDevSummit.
Posted by Adrienne Porter Felt and Emily Schechter, Chrome Security Team
Security has always been critical to the web, but challenges involved in site migration have inhibited HTTPS adoption for several years. In the interest of a safer web for all, at Google we've worked alongside many others across the online ecosystem to better understand and address these challenges, resulting in real change. A web with ubiquitous HTTPS is not the distant future. It's happening now, with secure browsing becoming standard for users of Chrome.
Today, we're adding a new section to the HTTPS Report Card in our Transparency Report that includes data on how HTTPS usage has been increasing over time. More than half of pages loaded and two-thirds of total time spent by Chrome desktop users occur via HTTPS, and we expect these metrics to continue their strong upward trajectory.
Percentage pages loaded over HTTPS in Chrome
As the remainder of the web transitions to HTTPS, we'll continue working to ensure that migrating to HTTPS is a no-brainer, providing business benefit beyond increased security. HTTPS currently enables the best performance the web offers and powerful features that benefit site conversions, including both new features such as service workers for offline support and web push notifications, and existing features such as credit card autofill and the HTML5 geolocation API that are too powerful to be used over non-secure HTTP.
As with all major site migrations, there are certain steps webmasters should take to ensure that search ranking transitions are smooth when moving to HTTPS. To help with this, we've posted two FAQs to help sites transition correctly, and will continue to improve our web fundamentals guidance.
We've seen many sites successfully transition with negligible effect on their search ranking and traffic. Brian Wood, Director of Marketing SEO at Wayfair, a large retail site, commented "we were able to migrate Wayfair.com to HTTPS with no meaningful impact to Google rankings or Google organic search traffic. We are very pleased to say that all Wayfair sites are now fully HTTPS." CNET, a large tech news site, had a similar experience. "We successfully completed our move of CNET.com to HTTPS last month," said John Sherwood, Vice President of Engineering & Technology at CNET. "Since then, there has been no change in our Google rankings or Google organic search traffic."
Webmasters that include ads on their sites also carefully monitor ad performance and revenue during large site migrations. The portion of Google ad traffic served over HTTPS has increased dramatically over the past 3 years. All ads that come from any Google source always support HTTPS, including AdWords, AdSense or DoubleClick Ad Exchange; ads sold directly, such as those through DoubleClick for Publishers, still need to be designed to be HTTPS-friendly. This means there will be no change to the Google-sourced ads that appear on a site after migrating to HTTPS. Many publishing partners have seen this in practice after a successful HTTPS transition. Jason Tollestrup, Director of Programmatic Advertising for the Washington Post, "saw no material impact to AdX revenue with the transition to SSL."
As migrating to HTTPS becomes even easier, we'll continue working towards a web that's secure by default. Don't hesitate to start planning your HTTPS migration today!
Originally posted on Google Analytics blog
In the digital world, whether you’re writing stories for your loyal readers, creating creative content that your fans love, helping the digital community, or providing items and services for your customer, understanding your audience is at the heart of it all. Key to unlocking that information is access to tools for measuring your audience and understanding their behavior. In addition to making your page load faster, Accelerated Mobile Pages (AMP) provides multiple analytics options without compromising on performance.
You can choose to use a solution like amp-pixel that behaves like a simple tracking pixel. It uses a single URL that allows variable substitutions, so it’s very customizable. See the amp-pixel documentation for more detail.
The amp-analytics component, on the other hand, is a powerful solution that recognizes many types of event triggers to help you collect specific metrics. Since amp-analytics is supported by multiple analytics providers, this means you can use amp-analytics to configure multiple endpoints and data sets. AMP then manages all of the instrumentation to come up with the data specified and shares it with these analytics solution providers.
To use amp-analytics, include the component library in your document's <head>:
<head>
<script async custom-element="amp-analytics" src="https://cdn.ampproject.org/v0/amp-analytics-0.1.js"></script>
And then include the component as follows (for these examples, make sure to specify your own account number instead of the placeholder):
<amp-analytics type="googleanalytics"> <script type="application/json"> { "vars": { "account": "UA-YYYY-Y" }, "triggers": { "defaultPageview": { "on": "visible", "request": "pageview", "vars": { "title": "Name of the Article" } } } } </script> </amp-analytics>
The JSON format is super flexible for describing several different types of events and it does not include any JavaScript code which could potentially lead to mistakes.
Expanding the above example, we can add another trigger, clickOnHeader:
clickOnHeader
<amp-analytics type="googleanalytics"> <script type="application/json"> { "vars": { "account": "UA-YYYY-Y" }, "triggers": { "defaultPageview": { "on": "visible", "request": "pageview", "vars": { "title": "Name of the Article" } }, "clickOnHeader": { "on": "click", "selector": "#header", "request": "event", "vars": { "eventCategory": "examples", "eventAction": "clicked-header" } } } } </script> </amp-analytics>
For a detailed description of data sets you can request, as well as the complete list of analytics providers supporting amp-analytics, check out the amp-analytics documentation. You can also see more implementation examples in the Amp By Example site.
If you want to conduct a user experience experiment on your AMP pages, such as an A/B test, you can use the amp-experiment element. Any configurations done in this element will also be exposed to amp-analytics and amp-pixel, so you can easily do a statistical analysis of your experiment.
There are still plenty of ongoing developments for AMP analytics to help you gain insights as you AMPlify the user experience on your site. Visit the AMP Project roadmap to see a summary of what the team is cooking up. If you see some features missing, please file a request on GitHub.
