Posted by Sam Tolomei, Business Development Manager, Google Play
In these unprecedented times, Google Play's mission to support you, ensure your businesses continue to operate well, and help users get the content they need is more important than ever. With a surge in need for information, communications tools, entertainment, and more, we are striving to ensure our operations run smoothly, and we need your support.
Below, we’ve pulled together some important information to help you maintain business continuity, as well as best practices to help you stay nimble in the changing landscape.
Extended app review times
Like many of you, we've had to manage work disruptions as a result of changing business conditions. This has led to a temporary slowing down of the app review process, which now may take 7 days or longer. As the situation evolves, we will continue to make sure that the most important updates reach users quickly, which may result in fluctuating review times. Certain critical apps may receive prioritized review and may not experience an extended delay in review time. Please check the Google Play Console for the most up-to-date information and guidance.
At the same time, in order to help ensure we are providing users with accurate and timely information relating to COVID-19, we also are prioritizing the review of apps published, commissioned, or authorized by official government entities and public health organizations.
If you want to control when your app goes live, we recommend timed publishing. Just submit your app for review, and once it’s approved, click “Go live” in the Play Console to instantly publish your app. Note: If you already have a release submitted to the production track that is under review, you will not see the “timed publishing” option.
Store listing guidelines
At Google Play we take our responsibility to provide accurate and relevant information for our users very seriously. For that reason, we are currently only approving apps that reference COVID-19 or related terms in their store listing if the app is published, commissioned, or authorized by an official government entity or public health organization, and the app does not contain any monetization mechanisms such as ads, in-app products, or in-app donations. This includes references in places such as the app title, description, release notes, or screenshots.
Removing inappropriate reviews
With the recent increase in traffic, some apps are seeing a spike in inappropriate one-star reviews from users. If you are receiving reviews that are not related to your app experience, you can flag the review in the Play Console. We’ve expanded our ability to assess and remove inappropriate reviews so we can handle your request as quickly as possible.
While subscriptions are a large part of many app business models, two groups are currently seeing the largest impact: 1) those whose core businesses have been adversely affected by COVID-19 (such as live event ticketing), and 2) those who provide a public service with their content or services.
For developers whose business value proposition has been affected, features like deferred billing and subscription pauses can help retain users until after the crisis has passed. For developers who want to offer their content or services like medical, online learning, and wellbeing apps at reduced or no cost, features like price changes and refunds through Google Play Billing are available to help.
Google is also committed to helping our community at large. To help small businesses reconnect with their customers, Google is granting $340 million in ad credits to be used across our Google Ads platforms — learn more here.
We've extended Play Pass free trials for new users to 3 months so more people can enjoy your apps and games.
We’ve launched a $10 million Distance Learning Fund to support organizations that provide high-quality learning opportunities to children. Developers who are non-profit, education-related enterprises are eligible for this program. Stay tuned for more details from Google.org.
As the situation progresses, we will continue to gather more resources to help you. We’re also taking steps to limit changes and barriers because we know you have enough on your plate right now. Please stay tuned for more information, and thank you for being a part of the Google Play community. If you have any other suggestions about how we can support you during this time, please let us know by tweeting at us at @GooglePlayDev with #AskGooglePlay.
Focusing on web interfaces that are beautiful, functional, accessible, and usable. Martine Dowden approaches User Experience from both Art and Science, drawing from her degrees in Psychology and Visual Communications. Martine has worked as an artist, educator, and consultant since 2005. She stays active in the industry, teaching developers at a coding academy, attending and speaking at conferences and meetups. In 2015 Martine published a children's book "Programming Languages ABC++", and in 2016 the Workbook Edition sold over 20,000 copies. She then went on to write "Approachable Accessibility: Planning for Success" which was released in June 2019 and "Architecting CSS: The Programmer’s Guide to Effective Stylesheets" to be released in 2020.
*Prior to the COVID-19 outbreak and our current shelter in place orders in San Francisco.
I’m definitely not a morning person, so when my alarm goes off, I can’t help but stay in bed a little while longer. I have two cats, Stella and Orion, who are especially cuddly in the mornings, so it’s hard to leave them and get out of bed. My cats are well known by my teammates as well as they make guest appearances in meetings whenever I’m dialed in and working from home. Because some of my teammates are much earlier risers than I am (or are in different timezones) I’ll hop on Slack as I’m getting ready to catch up with them as I start planning out what I’ll tackle at work today. I also take this time to catch up on any big releases going out or any interesting developments over the evening that might inform my work — there’s always lots going on in the Engineering org at Slack!
I’m finally out the door! I told you I’m not a morning person. I live in Bernal Heights, so I catch a bus down the hill in the mornings to the 24th & Mission BART station. I live near a fantastic shop, Black Jet Bakery, and if I’m running a little early, I’ll stop there for a pastry before hopping on the bus. It’s so peaceful in the mornings.
Made it into the office! My first stop is the barista station on the 5th floor. Ah! It’s such a wonderful way to start a workday. I get a latte in a big mug and settle into my desk, dig into Slack for real now and plan out my work for the day in my notebook — I really like writing to-dos down physically. I’ll typically review any outstanding pull requests from my teammates during this time or answer questions that have come up in my team channels — some shorter tasks that I can complete during this window of time.
Standup time! I’m on the Messaging team and we’re responsible for the core part of the product — everything from the user experience to the infrastructure about how messages are stored and formatted. We have team members in Vancouver and New York (and soon Toronto), as well as our headquarters in SF, so standup is a chance for us to all sync up on what we’ll be working on for the day and resolve any questions that arose the previous day. Our standups can be particularly silly, which I think is delightful. We often close our standups with a fun fact. Did you know that most of the things we call berries, like strawberries, are not actually botanical berries, but “accessory fruits”? Or what do you think the Japanese name for the seven sisters Pleiades constellation is? It’s Subaru! Look at the car logo the next time you’re driving around and you’ll see, although the logo only has six stars since the 7th star in the constellation isn’t visible to the naked eye.
This is the first time today I’ve gotten to tuck in and plug into coding. I was a Sublime lover when I first joined Slack, but I’m a full VS Code convert now. At Slack I mostly write in Hacklang (which was new to me prior to joining) and the tooling with VS Code is :chef’s kiss emoji:! That and the awesome support from our Internal Tools team make it so easy to get up and running in a new language. My newest favorite plugin I’ve discovered is the Bracket Colorizer 2. It’s a super simple concept — it just colorizes the brackets so each pair is the same color, but in a complex codebase it helps simplify what you’re looking at so, so much.
One of the projects I’m currently leading is a very exciting, cross-functional project to migrate the messages table to our Vitess cluster. Slack has been in the process of migrating some of our most important tables to Vitess to increase our ability to scale with our largest customers (more information about how we chose Vitess and it’s impact here). As a product engineer it’s so different to have the goal of a project be, “Users notice nothing”! Because of the sensitivity and importance of the data we’re migrating, and what a big undertaking this is, we have worked as a team to make very calculated decisions, building theories about any unexpected things we see and using our different domain knowledge to bridge the gaps and cover the entire message sending, persisting, and rendering stack. I am really enjoying getting to learn more about our infrastructure at Slack, and getting to go into the weeds while still working out of a core product team. It has been extremely rewarding to partner with our Infrastructure team and create a group that can bring both the Vitess expertise and the product knowledge to this migration. While we still have some of the final climbs to go, it has been gratifying to look back and see how far we’ve come since we set off on this project together.
Lunchtime! The Composition team is part of the larger Messaging engineering pillar — we have a great group of backend engineers and it’s wonderful to feel their solidarity and support. A rotating subset of us will often get lunch together, which is a nice way to connect outside of a code review and pair programming context. Any interesting topics that warrant source materials or further discussion get posted to #lunch-action-items. The last post was Blair Braverman’s twitter thread describing her sled dogs!
The Messaging backend team is actively hiring! Some afternoons I’ll serve on an interview panel, helping our recruiting team interview potential new teammates. I’m particularly proud of the continuous work the backend engineers across Slack put into trying to make our interview process the most representational and least stressful it can be. Interviewing also reminds me how many people are excited about the product we get to work on every day. It’s sometimes easy to get focused on the minutia when you work so closely to something and to lose sight of your own appreciation for it — being asked questions about Slack by our candidates helps me zoom back out and remember the positive and widespread impact it has.
Back at my desk! And back to proselytizing VSCode! One of the biggest contributors to me switching over was the debugger, which my teammates at Slack have hooked up to our development boxes . It’s crucial to the way we add to — and debug — our codebase, and has made figuring out and fixing bugs in our system much easier. As the Messaging pillar, we own so much of what makes Slack Slack — messages, file uploads, custom emojis, emoji reactions, threads, and the list goes on! This is incredibly exciting because our product development in these areas affects the core of the application. But it can also be a double-edged sword — since this is the very heart of the application — it’s not terribly uncommon to come across pieces of code that were originally written 4 or 5 years ago.
My afternoons are my main heads-down, glasses-on, headphones-on time to code. The product teams at Slack work hard to balance our technical time spent between new feature development and maintaining technical health and quality. One of the features the Messaging team just released is WYSIWYG, or “what you see is what you get”. This feature allows you to format your message as you type it — if you bold, it’ll be bold in the input before sending the message! Previously we stored messages as simple strings using markdown format. But for WYSIWYG we wanted to give the user much more control over the message formatting, including formatting that cannot be represented by markdown, such as intraword formatting. While this feature at face value seems like it could be only client work (and don’t get me wrong, it has involved a heroic amount of client work — shoutout to the incredible frontend, Android and iOS engineers I work with everyday!) — it involved a good amount of backend work as well, as we changed the format of how messages at Slack are stored.
Two other interesting pieces of this project that we considered as we were designing were maintaining backwards compatibility and thinking forward to simplifying the code in the future. When designing for a mature application which already has hundreds of billions of messages and millions of users, there are a number of inherent constraints. To continue to support those billions of older messages, we designed the WYSIWYG format to be backwards compatible for devices which don’t yet have our new code. Older applications must still be able to receive, read, and best-effort render the newly formatted messages, as well as still be able to send the old format of messages. On the other hand, we also don’t want to support two different message formats across all clients in perpetuity. For the efficiency and sanity of the engineers across all the codebases, we wanted to design and think through how to get back to only supporting one message format by building a translation layer on the backend, and a plan to migrate all older messages through it. I am so, so proud of this team and all the hard work that went into this feature!
Time to head home! There was probably a Susie Cakes appearance during the day that I’ve left out (my team has such a ridiculous sweet tooth and I am here for it!) and perhaps someone dressed in a T. Rex costume. Most likely a few informal in-person discussions about a product question, a PR comment, or a new Hacklang discovery. Something I reflect on while writing this is that: while I love problem solving and writing elegant and high quality code, it’s really the people I work with and the team collaboration that makes me excited to come back every day. That isn’t to say that there aren’t super exciting technical challenges that we’re solving, but to me it’s about how the team together has an impact.
And with that I head home to recharge, watch some Queer Eye and get ready to come back tomorrow for another day.
Madeline Shortt is currently a Senior Software Engineer at Slack on the Composition team within the Messaging engineering pillar. The Composition team works on the experience of composing a message, from formatting to uploading files to custom emoji. Before coming to Slack, she was at Ripple leading a team building payment APIs for financial institutions. She double majored in Physics and Computer Science at Mount Holyoke College in Massachusetts. She currently lives in Bernal Heights in San Francisco with her two cats, Stella and Orion and rides ponies when she finds the time.
When dealing with changes to a database schema, it's important to manage those changes in a way that is repeatable across your team and various environments. Watch as Simon and James us DbUp to add database migrations to an existing database and immediately level up on DevOps for that project.