Get your ads ready for iPhone X

Every interaction a user has with your app matters. That’s why we’re constantly evolving our advertising recommendations and policies to ensure that no matter where and on what device users are engaging with your apps, they have good experiences.

With the launch of the iPhone X, app developers now need to plan for new design considerations as the rounded corners, notch, and home screen indicator on the extended screen can obscure content and lead to poor ad experiences for users when ads are placed in these areas.

Example of ad appearing outside of “safe area” on iPhone X
That’s why we’ve put together a guide to help you adapt your ad strategy for iPhone X. This includes guidance for how you can shift placement of banner or native ads to designated “safe areas” for this new device.

We’ve also updated our policies to indicate that ads must not be placed where objects may interfere with the user's typical interaction with the ad or app, such as under the home screen indicator on the iPhone X.

Please review these policy updates and our suggested implementation guide to ensure you’re compliant by November 20th.

If you have any questions, visit the AdMob Help Center or contact your Google account team.

Posted by Pablo Alvarez, Product Manager, AdMob

Source: Inside AdMob


Code Health: IdentifierNamingPostForWorldWideWebBlog


This is another post in our Code Health series. A version of this post originally appeared in Google bathrooms worldwide as a Google Testing on the Toilet episode. You can download a printer-friendly version to display in your office.

By Chris Lewis and Bob Nystrom


It's easy to get carried away creating long identifiers. Longer names often make things more readable. But names that are too long can decrease readability. There are many examples of variable names longer than 60 characters on GitHub and elsewhere. In 58 characters, we managed this haiku for you to consider:

Name variables
Using these simple guidelines
Beautiful source code

Names should be two things: clear (know what it refers to) and precise (know what it does not refer to). Here are some guidelines to help:

• Omit words that are obvious given a variable's type declaration.
// Bad, the type tells us what these variables are:
String nameString; List<datetime> holidayDateList;
// Better:
String name; List<datetime> holidays;

• Omit irrelevant details.
// Overly specific names are hard to read:
Monster finalBattleMostDangerousBossMonster; Payments nonTypicalMonthlyPayments;
// Better, if there's no other monsters or payments that need disambiguation:
Monster boss; Payments payments;


• Omit words that are clear from the surrounding context.
// Bad, repeating the context:
class AnnualHolidaySale {int annualSaleRebate; boolean promoteHolidaySale() {...}}
// Better:
class AnnualHolidaySale {int rebate; boolean promote() {...}}

• Omit words that could apply to any identifier.
You know the usual suspects: data, state, amount, number, value, manager, engine, object, entity, instance, helper, util, broker, metadata, process, handle, context. Cut them out.

There are some exceptions to these rules; use your judgment. Names that are too long are still better than names that are too short. However, following these guidelines, your code will remain unambiguous and be much easier to read. Readers, including "future you,” will appreciate how clear your code is!

Announcing OpenFermion: The Open Source Chemistry Package for Quantum Computers



“The underlying physical laws necessary for the mathematical theory of a large part of physics and the whole of chemistry are thus completely known, and the difficulty is only that the exact application of these laws leads to equations much too complicated to be soluble.”
-Paul Dirac, Quantum Mechanics of Many-Electron Systems (1929)

In this passage, physicist Paul Dirac laments that while quantum mechanics accurately models all of chemistry, exactly simulating the associated equations appears intractably complicated. Not until 1982 would Richard Feynman suggest that instead of surrendering to the complexity of quantum mechanics, we might harness it as a computational resource. Hence, the original motivation for quantum computing: by operating a computer according to the laws of quantum mechanics, one could efficiently unravel exact simulations of nature. Such simulations could lead to breakthroughs in areas such as photovoltaics, batteries, new materials, pharmaceuticals and superconductivity. And while we do not yet have a quantum computer large enough to solve classically intractable problems in these areas, rapid progress is being made. Last year, Google published this paper detailing the first quantum computation of a molecule using a superconducting qubit quantum computer. Building on that work, the quantum computing group at IBM scaled the experiment to larger molecules, which made the cover of Nature last month.

Today, we announce the release of OpenFermion, the first open source platform for translating problems in chemistry and materials science into quantum circuits that can be executed on existing platforms. OpenFermion is a library for simulating the systems of interacting electrons (fermions) which give rise to the properties of matter. Prior to OpenFermion, quantum algorithm developers would need to learn a significant amount of chemistry and write a large amount of code hacking apart other codes to put together even the most basic quantum simulations. While the project began at Google, collaborators at ETH Zurich, Lawrence Berkeley National Labs, University of Michigan, Harvard University, Oxford University, Dartmouth University, Rigetti Computing and NASA all contributed to alpha releases. You can learn more details about this release in our paper, OpenFermion: The Electronic Structure Package for Quantum Computers.

One way to think of OpenFermion is as a tool for generating and compiling physics equations which describe chemical and material systems into representations which can be interpreted by a quantum computer1. The most effective quantum algorithms for these problems build upon and extend the power of classical quantum chemistry packages used and developed by research chemists across government, industry and academia. Accordingly, we are also releasing OpenFermion-Psi4 and OpenFermion-PySCF which are plugins for using OpenFermion in conjunction with the classical electronic structure packages Psi4 and PySCF.

The core OpenFermion library is designed in a quantum programming framework agnostic way to ensure compatibility with various platforms being developed by the community. This allows OpenFermion to support external packages which compile quantum assembly language specifications for diverse hardware platforms. We hope this decision will help establish OpenFermion as a community standard for putting quantum chemistry on quantum computers. To see how OpenFermion is used with diverse quantum programming frameworks, take a look at OpenFermion-ProjectQ and Forest-OpenFermion - plugins which link OpenFermion to the externally developed circuit simulation and compilation platforms known as ProjectQ and Forest.

The following workflow describes how a quantum chemist might use OpenFermion in order to simulate the energy surface of a molecule (for instance, by preparing the sort of quantum computation we described in our past blog post):
  1. The researcher initializes an OpenFermion calculation with specification of:
    • An input file specifying the coordinates of the nuclei in the molecule.
    • The basis set (e.g. cc-pVTZ) that should be used to discretize the molecule.
    • The charge and spin multiplicity (if known) of the system.
  1. The researcher uses the OpenFermion-Psi4 plugin or the OpenFermion-PySCF plugin to perform scalable classical computations which are used to optimally stage the quantum computation. For instance, one might perform a classical Hartree-Fock calculation to choose a good initial state for the quantum simulation.
  2. The researcher then specifies which electrons are most interesting to study on a quantum computer (known as an active space) and asks OpenFermion to map the equations for those electrons to a representation suitable for quantum bits, using one of the available procedures in OpenFermion, e.g. the Bravyi-Kitaev transformation.
  3. The researcher selects a quantum algorithm to solve for the properties of interest and uses a quantum compilation framework such as OpenFermion-ProjectQ to output the quantum circuit in assembly language which can be run on a quantum computer. If the researcher has access to a quantum computer, they then execute the experiment.
A few examples of what one might do with OpenFermion are demonstrated in ipython notebooks here, here and here. While quantum simulation is widely recognized as one of the most important applications of quantum computing in the near term, very few quantum computer scientists know quantum chemistry and even fewer chemists know quantum computing. Our hope is that OpenFermion will help to close the gap between these communities and bring the power of quantum computing to chemists and material scientists. If you’re interested, please checkout our GitHub repository - pull requests welcome!


1 If we may be allowed one sentence for the experts: the primary function of OpenFermion is to encode the electronic structure problem in second quantization defined by various basis sets and active spaces and then to transform those operators into spin Hamiltonians using various isomorphisms between qubit and fermion algebras.

Introducing the Mobile Excellence Award to celebrate great work on Mobile Web

Posted by Shane Cassells, mSite Product Lead, EMEA

We recently partnered with Awwwards, an awards platform for web development and web design, to launch a Mobile Excellence Badge on awwwards.comand a Mobile Excellence Award to recognize great mobile web experiences.

Starting this month, every agency and digital professional that submits their website to Awwwards can be eligible for a Mobile Excellence Badge, a guarantee of the performance of their mobile version. The mobile website's performance will be evaluated by a group of experts and measured against specific criteria based on Google's mobile principles on speed and usability. When a site achieves a minimum score, it will be recognized with the new Mobile Excellence Badge. All criteria are listed at the Mobile Guidelines.

The highest scoring sites with the Mobile Excellence Badge will be nominated for Mobile Site of the Week. One of them will then go on to win Mobile Site of the Month.

All Mobile Sites of the Month will be candidate for Mobile Site of the Year, with the winner receiving a physical award at the Awwwards Conference in Berlin, 8-9 February 2018.

In a time where mobile is playing a dominant role in how people access the web, it is necessary that web developers and web designers build websites that meet users' expectations. Today, 53% of mobile site visits are abandoned if pages take longer than 3 seconds to load1 and despite the explosion of mobile usage, performance and usability of existing mobile sites remain poor and are far from meeting those expectations. At the moment, the average page load time is 22s globally2, which represents a massive missed opportunity for many companies knowing the impact of speed on conversion and bounce rates3.

If you created a great mobile web experience and want it to receive a Mobile Excellence Badge and compete for the Mobile Excellence Award submit your request here.

Notes


  1. Google Data, Aggregated, anonymized Google Analytics data from a sample of mWeb sites opted into sharing benchmark data, n=3.7K, Global, March 2016 

  2. Google Research, Webpagetest.org, Global, sample of more than 900,000 mWeb sites across Fortune 1000 and Small Medium Businesses. Testing was performed using Chrome and emulating a Nexus 5 device on a globally representative 3G connection. 1.6Mbps download speed, 300ms Round-Trip Time (RTT). Tested on EC2 on m3.medium instances, similar in performance to high-end smartphones, Jan. 2017. 

  3. Akamai.com, Online Retail Experience Report 2017 

Building good SLOs – CRE life lessons



In a previous episode of CRE Life Lessons, we discussed how choosing good service level indicators (SLIs) and service level objectives (SLOs) is critical for defining and measuring the reliability of your service. There’s also a whole chapter in the SRE book about this topic. In this episode, we’re going to get meta and go into more detail about some best practices we use at Google to formulate good SLOs for our SLIs.

SLO musings


SLOs are objectives that your business aspires to meet and intends to take action to defend; just remember, your SLOs are not your SLAs (service level agreements)! You should pick SLOs that represent the most critical aspects of the user experience. If you meet an SLO, your users and your business should be happy. Conversely, if the system does not meet the SLO, that implies there are users who are being made unhappy!

Your business needs to be able to defend an endangered SLO by reducing the frequency of outages, or reducing the impact of outages when they occur. Some ways to do this might include: slowing down the rate at which you release new versions, or by implementing reliability improvements instead of features. All parts of your business need to acknowledge that these SLOs are valuable and should be defended through trade-offs.

Here are some important things to keep in mind when designing your SLOs:
  • An SLO can be a useful tool for resolving meaningful uncertainty about what a team should be doing. The objective is a line in the sand between "we definitely need to work on this issue" and "we might not need to work on this issue." Therefore, don’t pick SLO targets that are higher than what you actually need, even if you happen to be meeting them now, as that reduces your flexibility to change things in the future, including trade offs against reliability, like development velocity.
  • Group queries into SLOs by user experience, rather than by specific product elements or internal implementation details. For example, direct responses to user action should be grouped into a different SLO than background or ancillary responses (e.g., thumbnails). Similarly, “read” operations (e.g., view product) should be grouped into a different SLO than lower volume but more important “write” ones (e.g., check out). Each SLO will likely have different availability and latency targets.
  • Be explicit about the scope of your SLOs and what they cover (which queries, which data objects) and under what conditions they are offered. Be sure to consider questions like whether or not to count invalid user requests as errors, or happens when a single client spams you with lots of requests.
  • Finally, though somewhat in tension with the above, keep your SLOs simple and specific. It’s better not to cover non-critical operations with an SLO than to dilute what you really care about. Gain experience with a small set of SLOs; launch and iterate!

Example SLOs


Availability

Here we're trying to answer the question "Was the service available to our user?" Our approach is to count the failures and known missed requests, and report the measurement as a percentage. Record errors from the first point that is in your control (e.g., data from your Load Balancer, not from the browser’s HTTP requests). For requests between microservices, record data from the client side, not the server side.

That leaves us with an SLO of the form:

Availability: <service> will <respond successfully> for <a customer scope> for at least <percentage> of requests in the <SLO period>

For example . . .

Availability: Node.js will respond with a non-503 within 30 seconds for browser pageviews for at least 99.95% of requests in the month.

. . . and . . .

Availability: Node.js will respond with a non-503 within 60 seconds for mobile API calls for at least 99.9% of requests in the month.

For requests that took longer than 30 seconds (60 second for mobile), the service might as well have been down, so they count against our availability SLO.

Latency

Latency is a measure of how well a service performed for our users. We count the number of queries that are slower than a threshold, and report them as a percentage of total queries. The best measurements are done as close to the client as possible, so measure latency at the Load Balancer for incoming web requests, and from the client not the server for requests between microservices.

Latency: <service> will respond within <time limit> for at least <percentage> of requests in the <SLO period>.

For example . . .

Latency: Node.js will respond within 250ms for at least 50% of requests in the month, and within 3000ms for at least 99% of requests in the month.


Percentages are your friend . . .

Note that we expressed our latency SLI as a percentage: “percentage of requests with latency < 3000ms” with target of 99%, not “99th percentile latency in ms” with target “< 3000ms”. This keeps SLOs consistent and easy to understand, because they all have the same unit and the same range. Also, accurately computing percentiles across large data sets is hard, while counting the number of requests below a threshold is easy. You’ll likely want to monitor multiple thresholds (e.g., percentage of requests < 50ms, < 250ms, . . .), but having SLO targets of 99% for one threshold, and possibly 50% for another, is generally sufficient.

Avoid targeting average (mean) latency  it's almost never what you want. Averages can hide outliers, and sufficiently small values are indistinguishable from zero; users will not notice a difference between 50 ms and 250 ms for a full page response time, and thus they should be comparably good. There’s a big difference between an average of 250ms because all requests are taking 250ms, and an average of 250ms because 95% of requests are taking 1ms and 5% of requests are taking 5s.

. . . except 100%

A target of 100% is impossible over any meaningful length of time. It’s also likely not necessary. SREs use SLOs to embrace risk; the inverse of your SLO target is your error budget, and if your SLO target is 100% that means you have no error budget! In addition, SLOs are a tool for establishing team priorities dividing top-priority work from work that's prioritized on a case-by-case basis. SLOs tend to lose their credibility if every individual failure is treated as a top priority.

Regardless of the SLO target that you eventually choose, the discussion is likely to be very interesting; be sure to capture the rationale for your chosen target for posterity.

Reporting

Report on your SLOs quarterly, and use quarterly aggregates to guide policies, particularly pager thresholds. Using shorter periods tends to shift focus to smaller, day-to-day issues, and away from the larger, infrequent issues that are more damaging. Any live reporting should use the same sliding window as the quarterly report, to avoid confusion; the published quarterly report is merely a snapshot of the live report.

Example quarterly SLO summary

This is how you might present the historical performance of your service against SLO, e.g., for a semi-annual service report, where the SLO period is one quarter:

SLO
Target
Q2
Q3
Web Availability
99.95%
99.92%
99.96%
Mobile Availability
99.9%
99.91%
99.97%
Latency ≤ 250ms
50%
74%
70%
Latency ≤ 3000ms
99%
99.4%
98.9%

For SLO-dependent policies such as paging alerts or freezing of releases when you’ve spent the error budget, use a sliding window shorter than a quarter. For example, you might trigger a page if you spent ≥1% of the quarterly error budget over the last four hours, or you might freeze releases if you spent ≥ ⅓ of the quarterly budget in the last 30 days.

Breakdowns of SLI performance (by region, by zone, by customer, by specific RPC, etc.) are useful for debugging and possibly for alerting, but aren’t usually necessary in the SLO definition or quarterly summary.

Finally, be mindful about with whom you share your SLOs, especially early on. They can be a very useful tool for communicating expectations about your service, but the more broadly they are exposed the harder it is to change them.

Conclusion


SLOs are a deep topic, but we’re often asked about handy rules of thumb people can use to start reasoning about them. The SRE book has more on the topic, but if you start with these basic guidelines, you’ll be well on your way to avoiding the most common mistakes people make when starting with SLOs. Thanks for reading, we hope this post has been helpful. And as we say here at Google, may the queries flow, your SLOs be met and the pager stay silent!

An easy booking button for businesses on Google

Since the introduction of Reserve with Google, fitness, wellness and beauty businesses in the U.S. have been able to let customers book their services through their listing on Google. Customers simply click the blue booking button to set up an appointment, schedule a massage, or reserve a spot in a spin class—all right when they find your business online.


Now, we're adding a way for business owners to sign up with one of our scheduling partners directly from their Google My Business account and add a booking button to their listing.


How bookings can help your business

When potential customers search online for the ideal salon or the perfect gym class, they’re trying to decide which one is best for them. Booking buttons can help your business stand out from the crowd. People can book an appointment in under a minute directly through your listing—and you make it easy for them to become customers. And you can quickly track how many bookings you get from your Google My Business dashboard.

Turners Barber Shop 2.png

Businesses across the U.S. have already told us they’re excited about the booking button. For Glow Yoga & Spa in San Francisco, CA, a simple booking process has enhanced the upbeat, customer-focused studio vibe that has kept people coming back. The owners of  Turner’s Barber Shop in Columbus, OH, have been hearing that their customers loved seeing available slots and booking their hair appointments right from Google search. And Body Works NW in Lewiston, WA, has an easier time managing their calendar when customers can schedule the exact time they want and see which massage therapists are available.

How it works

1. Sign up: First, log in to Google My Business. If you have an account with one of our supported scheduling providers, your booking button has been automatically added to your Google listing. You can check it out and start tracking your bookings now. If you don’t have an account with a supported provider, you’ll see a button on the main screen asking you to sign up.
bookings-blogpost-dashboard-card (2).jpg

2. Choose your booking provider: Enroll with a scheduling provider from our list. Once you've enrolled, your account will be eligible to accept bookings through Google. Check back to see the new booking button on your listing within a few days.

bk_partners.png

3. Track your bookings: When you check back in with Google My Business, you’ll be able to track all of your bookings coming from Google.

bk_dash.png

These new features will be rolling out over the next few days in the U.S.—sign in to your account at google.com/business to give them a try. We’ll be adding the booking option in other countries and business categories soon, so stay tuned.

Pay with Google and speed through checkout

If you’ve ever paid for something on your phone or tablet, you know just how frustrating checkout can be. Maybe you had to fill in a bunch of forms. Maybe your session timed out. Maybe you encountered an error and had to start all over again. Back in May, we shared a sneak peek of how paying with Google would help you skip all that. And starting today you can now speed through online checkout on many of your favorite apps and websites with a few quick clicks.

Check out quickly with any card in your Google Account

When you pay with Google, you can use any of the credit or debit cards you’ve added to your Google Account from products like Google Play, YouTube, Chrome or Android Pay. Google sends the merchant your payment info and shipping address using the information from your account—no typing required. Then, the merchant will handle all the details just like any other purchase.

Here’s a look at just how easy it is in the Instacart app.

pwg_instacart

Pay for takeout, trips, or that new pair of shoes

You’ll be able to speed through checkout on your Android device whether you’re shopping in apps like iFood in Brazil, Dice in the U.K., or Kayak in the U.S.—or on the web with Chrome.

Here’s a look at the some of the popular places you can pay now, with more coming soon:

pwg_partners

Calling all developers: Make buying a breeze

Got an app or website? Head to our developer docs to to learn how to get started with the Google Payment API. You can implement it with just a few lines of code, and it’s free—we don’t charge any transaction fees.

We’ve also partnered with an array of payment providers to make integration even simpler. They’ll continue to process all your transactions, so you can keep everything moving smoothly. Don’t see your payment provider on the list yet? We’re adding more partners all the time, so stay tuned.

pwg_processors

Paying with Google makes checkout so fast and easy, you can make the most of every moment—whether you’re grabbing a dinner spot or a parking spot. Give it a go!

Pay with Google and speed through checkout

If you’ve ever paid for something on your phone or tablet, you know just how frustrating checkout can be. Maybe you had to fill in a bunch of forms. Maybe your session timed out. Maybe you encountered an error and had to start all over again. Back in May, we shared a sneak peek of how paying with Google would help you skip all that. And starting today you can now speed through online checkout on many of your favorite apps and websites with a few quick clicks.

Check out quickly with any card in your Google Account

When you pay with Google, you can use any of the credit or debit cards you’ve added to your Google Account from products like Google Play, YouTube, Chrome or Android Pay. Google sends the merchant your payment info and shipping address using the information from your account—no typing required. Then, the merchant will handle all the details just like any other purchase.

Here’s a look at just how easy it is in the Instacart app.

pwg_instacart

Pay for takeout, trips, or that new pair of shoes

You’ll be able to speed through checkout on your Android device whether you’re shopping in apps like iFood in Brazil, Dice in the U.K., or Kayak in the U.S.—or on the web with Chrome.

Here’s a look at the some of the popular places you can pay now, with more coming soon:

pwg_partners

Calling all developers: Make buying a breeze

Got an app or website? Head to our developer docs to to learn how to get started with the Google Payment API. You can implement it with just a few lines of code, and it’s free—we don’t charge any transaction fees.

We’ve also partnered with an array of payment providers to make integration even simpler. They’ll continue to process all your transactions, so you can keep everything moving smoothly. Don’t see your payment provider on the list yet? We’re adding more partners all the time, so stay tuned.

pwg_processors

Paying with Google makes checkout so fast and easy, you can make the most of every moment—whether you’re grabbing a dinner spot or a parking spot. Give it a go!

Searching for news innovators

At Google News Lab, we believe technology can and should support the creation of quality journalism.
We know that the best journalistic innovations come from within the newsroom, when journalists and technologists work together at the centre of the action.
That's why we are thrilled to expand the Australia Google News Lab Fellowship in its second year, in partnership with the Australian Broadcasting Corporation and the Walkley Foundation. Applications are now open.
We’re seeking Fellows to spend the 2017/18 summer embedded in the ABC newsroom, working on data journalism and product development projects that will help one of Australia’s largest newsrooms experiment and innovate with the latest storytelling technologies.
Google News Lab works with newsrooms, startups and journalism organisations around the world.
The Fellowship is open to anyone with technology skills that they’d like to apply to create new innovative forms of journalism, under the guidance of some of Australia’s most experienced journalists. Over the past two years we’ve steadily expanded the Google News Lab Fellowship program to help build the next generation of digital journalists across the world.
Last year we launched the program in Australia in partnership with Fairfax Media, placing Matthew Baker from the University of New South Wales inside the Sydney Morning Herald’s newsroom.
Australian News Lab Fellow Matt Baker (second from right) with other Fellows at Google headquarters last year.
Matthew worked on two main projects - a data-driven analysis of the late-night lockout laws in Sydney, and a recommendation tool designed to increase audience engagement.
We look forward to welcoming a new cohort of passionate Australian journalism innovators this year to expand and broaden the impact of the Fellowship program.
You can learn more about the fellowship program and our participating media organisations at the Walkley Foundation’s website. Applications are open until October 29.

Fall into autumn with #teampixel

With autumn in full swing, we’re taking note of the warmer colors being whisked into our feeds. This week, #teampixel wonderfully captures fall’s color palette, from burnt siennas to bright oranges. So grab a cup of tea, cozy up to the fire and flip through our favorite fall finds.

You can also join @verizon and #teampixel as we pass along a Google Pixel 2 from coast to coast on Instagram. Check out some of the stunning photos from the trip—in scenic Athens, NY, historic Paris, TX, and delicious Venice, CA.

Want to get featured on The Keyword and @google? Make sure to tag your photos with #teampixel and you might be next.