Tag Archives: developers

Using field masks with update requests to Google APIs



We recently demonstrated how to use field masks to limit the amount of data that comes back via response payloads from read (GET) calls to Google APIs. Today, we’ll focus on a different use case for field masks: update requests.

In this scenario, field masks serve a different, but similar purpose—they still filter, but function more like bitmasks by controlling which API fields to update. The following video walks through several examples of update field mask usage with both the Google Sheets and Slides APIs. Check it out.
2
In the sample JSON payload below, note the request to set the cells' bold attribute to true (per the cell directive below), then notice that the field mask (fields) practically mirrors the request:
{
"repeatCell": {
"range": {
"endRowIndex": 1
},
"cell": {
"userEnteredFormat": {
"textFormat": {
"bold": true
}
}
},
"fields": "userEnteredFormat/textFormat/bold",
}
}
Now, you might think, “is that redundant?” Above, we highlighted that it takes two parts: 1) the request provides the data for the desired changes, and 2) the field mask states what should be updated, such as the userEnteredFormat/textFormat/bold attribute for all the cells in the first row. To more clearly illustrate this, let’s add something else to the mask like italics. Here, the updated field mask now has both bold and italic fields:
"fields": "userEnteredFormat/textFormat(bold,italic)"

However, while both elements are in the field mask, we’ve only provided the update data for bold. There’s no data for italic setting specified in the request body. In this case, for all cells will be reset, meaning if the cells were originally italicized, those italics will be removed after this API request completes. And vice versa, if the cells were not italicized to begin with, they’ll stay that way. This feature gives developers the ability to undo or reset any prior settings on affected range of cells. Check out the video for more examples and tips for using field masks for update requests.

To learn more about using field masks for partial response in API payloads, check out this video and the first post in this two-part series. For one of the most comprehensive write-ups on both (read and update) use cases, see the guide in the Google Slides API documentation.  Happy field-masking!

App onboarding for kids: how Budge Studios creates a more engaging experience for families

Posted by Josh Solt (Partner Developer Manager, Kids Apps at Google Play) and Noemie Dupuy (Founder & Co-CEO at Budge Studios)

Developers spend a considerable amount of resources driving users to download their apps, but what happens next is often the most critical part of the user journey. User onboarding is especially nuanced in the kids space since developers must consider two audiences: parents and children. When done correctly, a compelling onboarding experience will meet the needs of both parents and kids while also accounting for unique considerations, such as a child's attention span.

Budge Studios has successfully grown their catalog of children's titles by making onboarding a focal point of their business. Their target demographic is three to eight-year olds, and their portfolio of games include top titles featuring Strawberry Shortcake, Hello Kitty, Crayola, Caillou and The Smurfs.

"First impressions matter, as do users' first experience with your app. In fact, 70%1 of users who delete an app will do so within a day of having downloaded it, leaving little time for second chances. As an expert in kids' content, Budge tapped into our knowledge of kids to improve and optimize the onboarding experience, leading to increased initial game-loop completion and retention." - Noemie, Founder & Co-CEO at Budge Studios

Three key ways Budge Studios designs better onboarding experiences:


1. Make sure your game is tailor-made for kids

When Budge released their app Crayola Colorful Creatures, they looked at data to identify opportunities to create a smoother onboarding flow for kids. At launch, only 25% of first-time users were completing the initial game loop. Budge analyzed data against gameplay and realized the last activity was causing a drastic drop-off. It required kids to use the device's microphone, and that proved too challenging for very young kids. Budge was able to adjust the initial game loop so that all the activities were accessible to the youngest players. These adjustments almost tripled the initial loop completion, resulting in 74% of first-time users progressing to see additional activities.

2. Earn parents trust by providing real value upfront

Budge has a large of portfolio of apps. Earning parents' trust by providing valuable and engaging experiences for kids is important for retaining users in their ecosystem and achieving long term success.

With every new app, Budge identifies what content is playable for free, and what content must be purchased. Early on, Budge greatly limited the amount of free content they offered, but over time has realized providing high quality free content enhances the first-time user experience. Parents are more willing to spend on an app if their child has shown a real interest in a title.

Working with top kids' brands means that Budge can tap into brand loyalty of popular kids characters to provide value. To launch Strawberry Shortcake Dreams, Budge decided to offer Strawberry Shortcake, the most popular character in the series, as a free character. Dress Up Dreams is among the highest converting apps in the Budge portfolio, indicating that giving away the most popular character for free helped conversions rather than hurting it.

3. Test with real users

Budge knows there is no substitute for direct feedback from its end-users, so Budge involves kids every step of the way. Budge Playgroup is a playtesting program that invites families to try out apps at the alpha, beta and first-playable development stages.

The benefits from early testing can be as basic as understanding how the size and coordination of kids' hands affect their ability to complete certain actions or even hold the device, and as specific as pinpointing a less-than-effective button.

In the testing stages of Strawberry Shortcake Holiday Hair, Budge caught an issue with the main menu of the app, which would not have been evident without observing kids using the app.

Prior to Playtesting:

After Playtesting:

In the original design, users were prompted to start gameplay by audio cues. During testing, it was clear that the voiceover was not sufficient in guiding kids to initiate play, and that additional visual clues would significantly improve the experience. A simple design change resulted in a greatly enhanced user experience.

The onboarding experience is just one component of an app, but just like first impressions, it has a disproportionate impact on your users' perception of your app. As Budge has experienced, involving users in testing your app, using data to flag issues and providing real value to your users upfront, creates a smoother, more accessible onboarding experience and leads to better results.

For more best practices on developing family apps and games, please check out The Family Playbook for developers. And visit the Android Developers website to stay up-to-date with features and best practices that will help you grow a successful business on Google Play.

1.http://www.cmswire.com/customer-experience/mobile-app-retention-5-key-strategies-to-keep-your-customers/

How useful did you find this blogpost?

Using Google Sheets filters in Add-ons with Google Apps Script



Developers using Google Apps Script can now access the richer feature set of the updated Google Sheets API with the recent launch of the Advanced Sheets Service. One key benefit of using an advanced service vs. native Apps Script objects, is that developers can access current API features (without having to wait for native support to come along). For example, the advanced service allows developers to access Sheets filters which make Add-ons more engaging.

Filter functionality 

With the Sheets API, developers can already get filtered rows or set new filters on Sheets data. With the Advanced Sheet Service, developers can now have their Add-ons respect those filters and apply new filters to modify what data is visible in the Sheets UI. Plus, with any of the Apps Script advanced services, you can easily access the Sheets and other Google APIs without using the UrlFetch service nor managing the authorization flow that you’d otherwise have to perform if using the REST API directly. The snippet below will return the indexes of the filtered rows in a given Sheet. Note that it is also possible to retrieve the list of rows hidden manually, using the "hide row" menu item in Google Sheets, as indicated in the API documentation. In the code sample here, we’re only exposing rows hidden by filter.

 function getIndexesOfFilteredRows(ssId, sheetId) {
var hiddenRows = [];

// limit what's returned from the API
var fields = "sheets(data(rowMetadata(hiddenByFilter)),properties/sheetId)";
var sheets = Sheets.Spreadsheets.get(ssId, {fields: fields}).sheets;

for (var i = 0; i < sheets.length; i++) {
if (sheets[i].properties.sheetId == sheetId) {
var data = sheets[i].data;
var rows = data[0].rowMetadata;
for (var j = 0; j < rows.length; j++) {
if (rows[j].hiddenByFilter) hiddenRows.push(j);
}
}
}
return hiddenRows;
The fields parameter in the code snippet limits what's returned in the Sheets API response, requesting only the values that matter to your app. For more information, check out this page in the Sheets API doc or this recent video on field masks.

See how some Add-ons use filtering 

There are a number of Add-ons that use advanced filtering in Sheets. Here are some good examples:
  • Yet Another Mail Merge: this Add-on helps users send email campaigns from a spreadsheet and is built to process only the filtered rows of a Sheet. Let's say you have a list of people who are registered for an event, but you've only accepted some of these registrants and need to send an email confirmation. With Yet Another Mail Merge and the updated API, you can filter out people you don't approve to attend and the Add-ons skips them without sending confirmations.
  • Sankey Snip and Chord Snip: these Add-ons helps users create special chart types that aren't available in the Google Sheets UI. When respecting filters is enabled with these Add-ons, the charts will dynamically visualize filtered data. Check out the example below from the Chord Snip Add-on.
Of course the API also provides the ability to add, update or delete filters on a Sheet. This is useful if you want to quickly display rows with a specific status to your users. One example would be if you built a workflow approval Add-on. You can show the user rows that are waiting for approval. The snippet below applies the requested filter on a given Sheet—the API documentation describes a standard basic filter object:

function setSheetBasicFilter(ssId, BasicFilterSettings) {
//requests is an array of batchrequests, here we only use setBasicFilter
var requests = [
{
"setBasicFilter": {
"filter": BasicFilterSettings
}
}
];
Sheets.Spreadsheets.batchUpdate({'requests': requests}, ssId);
}

Yet Another Mail Merge, as many mass-mailing tools do, keeps track of all emails sent, opened and clicked. A tracking report is available in the spreadsheet sidebar, and clicking on the number of emails opened will automatically apply a filter to display only the matching rows—all rows with the status “opened.”

Now, you can determine filters applied in a Sheet directly through the Sheets API or through Apps Script apps and Add-ons using the Advanced Sheets Service, and continue to build the best experience for your users.

About the Authors 

Romain Vialard is a Google Developer Expert. After some years spent as a G Suite consultant, he is now focused on products for G Suite and Google Apps users, including add-ons such as Yet Another Mail Merge and Form Publisher.

Bruce Mcpherson is a Google Developer Expert, an independent consultant, blogger and author of Going GAS, Google Apps Script for Beginners, and Google Apps Script for Developers.

New Google Drive metrics now accessible from Reports API



You might have read that we launched new metrics in the Admin SDK Reports API to help you gain reliable, easily-validated perspectives about users within your domain. Today, we're building on these features by giving administrators and developers even greater visibility into how files are shared both inside and outside of domain. These changes include:
  1. New metrics to supplement the set of metrics we launched last year 
  2. New visibility information for audit events 
  3. Deprecation of existing metrics from the Reports API

New Metrics

We’ve created a new set of metrics to complete the set we launched last year. With these new metrics you can:
  • Gain insight into the visibility of files and their sharing state, which is useful for security and reporting. This will replace these older metrics:
    num_docs_internally_visible, num_docs_externally_visible, num_docs_shared_outside_domain.
  • Report on product adoption within your domain with summary statistics about groups of users (collaborators, viewers, creators and sharers). Take advantage of key adoption metrics such as 1-, 7-, and 30-day active users for Google Drive, Docs, Sheets, Slides, Forms, Drawings and more. 
  • Simplify your calculation of “what has changed” in your domain using delta metrics which pre-calculate changes in visibility and items owned.

New Visibility Information 

Now, new visibility information is attached to every audit event which helps you quickly identify the permission change events that lead to files being shared differently both within and outside your domain. Learn more.

Deprecating Existing Metrics 

While we’re aware of the need to have reliable and timely data about your domain’s users and files on Google Drive, Drive’s data and infrastructure has grown considerably, requiring us to make some difficult technical tradeoffs regarding metrics. As a result, today marks the beginning of a 12-month deprecation timeline that will retire these existing metrics from the Reports API and eventually the Admin Console. These metrics will no longer be available starting May 14, 2018.

To get started using the Reports API and see all the different types of metrics you can report on for your domain, check out the official documentation. We hope you find these features useful in your reporting.

Santa Tracker, open-sourced and delivered

Posted by Sam Thorogood, Developer Programs Engineer

Santa Tracker is a holiday tradition here at Google. Every year, you can celebrate the season with games, holiday experiences and educational content throughout December: not to mention watching Santa deliver presents on 24th.

Today, we're continuing the season of giving by delivering the updated open-source versions of both the Web and Android versions that ran in December 2016. These are large, real-world apps that show off the latest and greatest from Google—using APIs and frameworks like Firebase and Polymer.



This year, Santa's elves added even more engaging, fun and educational experiences to Santa Tracker: all while making Santa and his reindeer leaner than ever before—across both Web and Android.

On the Web, we built a reliable, offline-capable PWA-ified version of Santa Tracker that saved bandwidth and worked in environments with poor connectivity. For Android, we worked hard to save every precious byte by closely examining our visual assets and other libraries.

To get started, you can check out the code on GitHub at google/santa-tracker-weband google/santa-tracker-android. Both Web and Android versions include detailed build instructions.

On the Web

If you'd like to read about how the elves build Santa Tracker as an offline Progressive Web App, check out our Case Study on Google Developers. To download the source, head over to GitHub. Here are some highlights of the release-
  • Santa is a Progressive Web App, sporting a responsive design for mobile, desktop and tablet, supporting Add to Home Screen and offline.
    • Rather than saving the entire site offline (about 100mb, including resources needed for different browsers), Santa's Service Worker only saves the scenes you've visited at least once—icing over houses that aren't available offline.

  • Santa Tracker used Polymer 1.7+, packing code into reusable components. Every housein Santa's Village is a custom element, only loaded when needed, minimizing the startup cost of Santa Tracker.
  • The Web Share API allowed users on mobile to quickly and natively showcase their creativity—it's a modern API for interfacing with a platform's native share intent, replacing the sea of share buttons normally presented to users.
  • Santa sported a new and improved Chromecast experience that scaled well across all Cast devices—from the original Chromecast device through to the high-end Chromecast Ultra and supported TVs.

  • Users were delighted by showing some great video content from around Santa's Village, especially during Santa's long travel legs.
  • The Android client also used this Chromecast experience, so Android users joined the fun watching Santa deliver presents on the 24th on their big screen TVs.

On Android

In 2016, Santa went on a diet, and reduced his APK download size by over 10mb—while adding four new games and a visual refresh. To learn more about our work, check out the in-depth analysis on Android Developers—or to try it yourself, head over to GitHub. Here are some highlights of this year's app-
  • Present Quest, a new AR game where players are encouraged to explore their real-world environment to collect presents and level up!

  • Santa is smaller and faster than ever before. The download size is down 10mb from the previous release, despite including multiple new games, Santa works better on memory-constrained devices, and various sources of jank have been found and removed.
  • The app is built using split APKs - one per architecture (armv5, armv7, and x86), reducing download size. Each APK supports phones, tablets, Android TVs and provide custom watch faces on Android Wear.

Ho Ho Ho!

We hope you enjoy exploring Santa Tracker and its source code, and it inspires you to leverage the same approaches to make your own magical experiences!


Noto Serif CJK is here!


Posted by Xiangye Xiao and Jungshik Shin, Internationalization Engineering team

Today, in collaboration with Adobe, we are responding to the call for Serif! We are pleased to announce Noto Serif CJK, the long-awaited companion to Noto Sans CJK released in 2014. Like Noto Sans CJK, Noto Serif CJK supports Simplified Chinese, Traditional Chinese, Japanese, and Korean, all in one font.

A serif-style CJK font goes by many names: Song (宋体) in Mainland China, Ming (明體) in Hong Kong, Macao and Taiwan, Minchō (明朝) in Japan, and Myeongjo (명조) or Batang (바탕) in Korea. The names and writing styles originated during the Song and Ming dynasties in China, when China's wood-block printing technique became popular. Characters were carved along the grain of the wood block. Horizontal strokes were easy to carve and vertical strokes were difficult; this resulted in thinner horizontal strokes and wider vertical ones. In addition, subtle triangular ornaments were added to the end of horizontal strokes to simulate Chinese Kai (楷体) calligraphy. This style continues today and has become a popular typeface style.

Serif fonts, which are considered more traditional with calligraphic aesthetics, are often used for long paragraphs of text such as body text of web pages or ebooks. Sans-serif fonts are often used for user interfaces of websites/apps and headings because of their simplicity and modern feeling.

Design of '永' ('eternity') in Noto Serif and Sans CJK. This ideograph is famous for having the most important elements of calligraphic strokes. It is often used to evaluate calligraphy or typeface design.

The Noto Serif CJK package offers the same features as Noto Sans CJK:

  • It has comprehensive character coverage for the four languages. This includes the full coverage of CJK Ideographs with variation support for four regions, Kangxi radicals, Japanese Kana, Korean Hangul and other CJK symbols and letters in the Unicode Basic Multilingual Plane of Unicode. It also provides a limited coverage of CJK Ideographs in Plane 2 of Unicode, as necessary to support standards from China and Japan.


Simplified Chinese
Supports GB 18030 and China’s latest standard Table of General Chinese Characters (通用规范汉字表) published in 2013.
Traditional Chinese
Supports BIG5, and Traditional Chinese glyphs are compliant to glyph standard of Taiwan Ministry of Education (教育部國字標準字體).
Japanese
Supports all of the kanji in  JIS X 0208, JIS X 0213, and JIS X 0212 to include all kanji in Adobe-Japan1-6.
Korean
The best font for typesetting classic Korean documents in Hangul and Hanja such as Humninjeongeum manuscript, a UNESCO World Heritage.
Supports over 1.5 million archaic Hangul syllables and 11,172 modern syllables as well as all CJK ideographs in KS X 1001 and KS X 1002
Noto Serif CJK’s support of character and glyph set standards for the four languages
  • It respects diversity of regional writing conventions for the same character. The example below shows the four glyphs of '述' (describe) in four languages that have subtle differences.
From left to right are glyphs of '述' in S. Chinese, T. Chinese, Japanese and Korean. This character means "describe".
  • It is offered in seven weights: ExtraLight, Light, Regular, Medium, SemiBold, Bold, and Black. Noto Serif CJK supports 43,027 encoded characters and includes 65,535 glyphs (the maximum number of glyphs that can be included in a single font). The seven weights, when put together, have almost a half-million glyphs. The weights are compatible with Google's Material Design standard fonts, Roboto, Noto Sans and Noto Serif(Latin-Greek-Cyrillic fonts in the Noto family).
Seven weights of Noto Serif CJK
    • It supports vertical text layout and is compliant with the Unicode vertical text layout standard. The shape, orientation, and position of particular characters (e.g., brackets and hiragkana letters) are changed when the writing direction of the text is vertical.



    The sheer size of this project also required regional expertise! Glyph design would not have been possible without leading East Asian type foundries Changzhou SinoType Technology, Iwata Corporation, and Sandoll Communications.

    Noto Serif CJK is open source under the SIL Open Font License, Version 1.1. We invite individual users to install and use these fonts in their favorite authoring apps; developers to bundle these fonts with your apps, and OEMs to embed them into their devices. The fonts are free for everyone to use!

    Noto Serif CJK font download:https://www.google.com/get/noto
    Noto Serif CJK on GitHub:https://github.com/googlei18n/noto-cjk
    Adobe's landing page for this release: http://adobe.ly/SourceHanSerif
    Source Han Serif on GitHub: https://github.com/adobe-fonts/source-han-serif/tree/release/

    Updates to end user consent for 3rd-party apps and Single Sign-on providers



    At Google, we're mindful of keeping our users’ data and account information secure. So whether you're writing an app that requires access to user data or helping your users change their passwords, we’ll keep you up-to-date on policy changes, and now today, when it comes to consent and 3rd-party applications. Starting April 5, 2017, if you’re an application developer or a 3rd-party Single Sign-On (SSO) provider, your G Suite users may encounter a redirect when they authenticate with your identity service to make it clear to users which account they’re authenticating as well as the permissions they’re granting to applications.

    These changes will occur on these platforms:
    • Google and 3rd-party applications on iOS
    • Mobile browsers on iOS and Android
    • Web browsers (Chrome, Firefox and other modern browsers)
    Note that Android applications that use the standard authentication libraries are already prompting users to select appropriate account information, so they’re not impacted by these changes.

    More visibility with new permission requests for your application

    It’s important that your users are presented with account information and credential consent, and apps should make this process easy and clear. One new change that you may now see is that only non-standard permission requests will be presented in the secondary consent screen in your application. 

    Currently when an application requests permissions, all of them are displayed together. However, users should have greater visibility into permissions being requested beyond the standard “email address” and “profile” consent. By clicking to select their account, a user consents to these core permissions. The secondary consent screen will appear only if additional permissions are requested by the application.

    Only non-standard permissions will be presented in the secondary consent screen that the user must approve. 
    Along with these changes, your application name will be more visible to users, and they can click-through to get your contact information. We recommend application developers use a public-facing email address so that users can quickly contact you for support or assistance. For more details, check out this developer guide.

    If your application may also be used by G Suite customers that employ a 3rd-party Single Sign-On (SSO) service, we recommend that you utilize the hd and/or login_hint parameters, if applicable. Even with the changes to the 3rd-party SSO auth flow, these parameters will be respected if provided. You can review the OpenID Connect page in the documentation for more information.

    Changes coming for 3rd-party SSO redirection

    G Suite users may also notice redirection when signing into 3rd-party SSO providers. If no accounts are signed in, the user must confirm the account after signing in to the 3rd-party SSO provider to ensure that they’re signed in with the correct G Suite account:
    The end user who has just signed in with one Google account should select that account as confirmation. 
    As mentioned, by clicking to the select their account, a user is opting into “email address” and “profile” consent. Once the user consents to any additional non-standard permissions that may be requested, they will be redirected back to your application.

    If the user is already signed in to one or more accounts that match the hd hint, the Account Chooser will display all of the accounts and require the user to select the appropriate G Suite account before being redirected to the 3rd-party SSO provider then back to your application:
    A user who is signed into several Google accounts will be required to choose the appropriate account.

    See updates starting April 2017

    These changes will help your users understand their permissions more clearly across all platforms, whether they’re using Google or a 3rd-party SSO provider for authentication. We’ve started to roll out the new interstitial page on iOS devices, and changes for browsers will begin to roll out starting April 5, 2017.

    Using field masks with Google APIs for partial response



    When you write applications using Google APIs (not just G Suite ones, but most Google APIs including YouTube or Google Cloud Platform APIs), it's important to be mindful of the data that’s returned in the response payloads from API calls. If you're not, your apps are likely getting back much more data than they need which can affect the performance of your apps whether on mobile or a server backend.

    That's why most Google APIs allow you to only filter the data you need from response payloads with field masks. To get you comfortable with field masks, we’ve put together a video to demonstrate their use with various Google APIs: With field masks, you can specify exactly what fields an API should return in its response payload by providing a fields or part parameter in your calls. And once the API knows what you want, it will likely spend less time assembling your response too. Here’s an example Python call to fetch your sender addresses using the Gmail API (if GMAIL is your service endpoint):
         addresses = GMAIL.users().settings().sendAs().list(
    userId='me'
    ).execute().get('sendAs')

    Whether you’re using a Client Library (as our Python call) or using HTTP directly with GET https://www.googleapis.com/gmail/v1/users/userId/settings/sendAs, this is the payload you get back from the API:
         {
    "sendAs": [{
    "sendAsEmail": string,
    "displayName": string,
    "replyToAddress": string,
    "signature": string,
    "isPrimary": boolean,
    "isDefault": boolean,
    "treatAsAlias": boolean,
    "smtpMsa": {
    "host": string,
    "port": integer,
    "username": string,
    "password": string,
    "securityMode": string
    },
    "verificationStatus": string
    }, ...]
    }

    The sendAs array gives you everything you need to know about each of your sender addresses. Did you know you can change a user’s email signature using the Gmail API without all of the data from above? You only need one field, or at most two: sendAsEmail and perhaps the isPrimary flag. By specifying a field mask with just those names from the sendAs attribute, you can cut out all those unneeded fields. Check it out here in Python with the field mask bolded for emphasis (versus the sample code above that doesn’t filter):
         addresses = GMAIL.users().settings().sendAs().list(
    userId='me', fields='sendAs(sendAsEmail,isPrimary)'
    ).execute().get('sendAs')
    Field masks filter our unnecessary data from Google API call responses.

    In part two of this video series (coming soon), we’ll show you a different use case for field masks...for update API calls. We’ll also provide some usage tips and demonstrate how field masks can be used in both read and update calls, how both types of calls are discrete, and how in some cases, you may use both as part of a single API call. Stay tuned!

    To learn more about using field masks for partial response in API payloads, check out this section of the Client Library docs. For one of the most comprehensive write-ups on both (read and update) use cases, see the guide in the Google Slides API documentation.

    5 tips for indie game success, from indie game developers

    Posted by Sarah Thomson, BD Partnerships Lead, Indies, Google Play Games

    Mobile gaming is a fun place to be right now. It's a landscape seeing tremendous success year after year with great potential for additional growth and innovation. It's also a space where developers can express themselves with creative game styles, mechanics, design and more. This is what the indie community does best.

    Here are 5 tips for indies by indies, shared by our gaming partners at 505 Games, About Fun, Disruptor Beam, Klei Entertainment, and Schell Games.


    1. Embrace being indie


    Indies are inherently smaller operations and should embrace their agility and ability to take risks. Petr Vodak, CEO at About Fun, recommends getting your product out there so you can start taking feedback and apply your learnings to future projects. Don't be afraid to fail! Remaining flexible and building in modularity so you can evolve with the business needs is a strategy embraced by Pete Arden, CMO at Disruptor Beam. For instance, with their game Star Trek Timelines, the initial user experience was tailored to avid Star Trek fans. Over time, as user acquisition costs increased, they've changed the new player experience to appeal to their evolving user base of gamers looking for a fun entertainment experience and less the specific Star Trek IP.

    2. Find a way to stand out


    To help stand out in the ultra competitive mobile space, Jesse Schell, CEO of Schell Games, recommends doing something clever or very different. This strategy has led them to explore the growth areas of new platforms such as AR & VR. While new platforms present a field for opportunity and creativity, they're best to be approached with the long term in mind allowing you to sustain the business until critical mass is reached.

    3. Build a community


    There are many ways to build communities. If you have an existing fan base on other platforms, cross-promote to drive awareness of your mobile offerings. You can also look at porting titles over, but be aware of the differences in mobile gaming habits and ensure you adapt your game accordingly.

    4. Engage after install


    Both 505 Games and Klei Entertainment recommend running your premium titles as a service. Through monitoring user reviews you can gain invaluable feedback and trends helping you better understand user pain points and desires. In addition, by releasing regular content updates and in-game events you create reason for users to get back in the game. This not only drives reengagement, but 505 Games also sees strong spikes in new installs aligned with major game updates.

    5. Monetize in different ways


    Similar strategy to above, dropping regular content refreshes and game updates while offering a variety of monetization options gives users more ways to engage with your game. Keeping your games fresh gives users reason to come back and builds loyalty so you can cross-promote to your users with future game launches.

    If you're looking for a fun new game to play, check out the great selection on Indie Corner on Google Play. And if you're working on a new indie game of your own, nominate your title for inclusion.

    Watch more sessions from Google Developer Day at GDC17 on the Android Developers YouTube channel to learn tips for success. Visit the Android Developers website to stay up-to-date with features and best practices that will help you grow a successful business on Google Play.


    How useful did you find this blogpost?


    A new issue tracker for G Suite developers

    , Developer Advocate, G Suite
    You may have read recently that the Google Cloud Platform team upgraded to Issue Tracker, the same system that Google uses internally. This allows for improved collaboration between all of us and all of you. Issues you file will have better exposure internally, and you get improved transparency in terms of seeing the issues we’re actively working on. Starting today, G Suite developers will also have a new issue tracker to which we’ve already migrated existing issues from previous systems. Whether it’s a bug that you’ve found, or if you wish to submit a favorite feature request, the new issue tracker is here for you. Heads up, you need to be logged in with your Google credentials to view or update issues in the tracker.
    The new issue tracker for G Suite developers. 

    Each G Suite API and developer tool has its own “component” number that you can search. For your convenience, below is the entire list. You may browse for issues relevant to the Google APIs that you’re using, or click on the convenience links to report an issue or request a new/missing feature:
    To get started, take a look at the documentation pages, as well as the FAQ. For more details, be sure to check out the Google Cloud Platform announcement, too. We look forward to working more closely with all of you soon!