Google is certainly at one end of the spectrum in its approach to developing applications. If another software company is careful and attentive to the features it adds to its applications and when, you could say that Google is … the opposite. It has long been established that A / B testing is an integral part of the company's culture and its consumer applications are no exception.
You are probably familiar with this concept at the macro level, for example. "If we try five approaches to messaging applications, at least one of them should work long-term, is not it?" (I hope Google, in this particular case , admits that the answer is usually "not really".)
But this also applies at the micro level. Google could for example wish to have a well-established peer-to-peer payment service. So they could try to put this feature in the Messages app, in a stand-alone Google Pay app, and maybe even in a strange place you would not expect, like in Google Maps (no, it's not a feature). They did strange things.
"Who knows?", Google request. "Maybe people want to send money to friends in Gmail?" Or maybe if the option was offered to them, people will learn that it is an absolutely essential part of their daily workflow (flow of life?) Without which they can not live. Yes you can In fact, send money to people via Google Pay in Gmail in the United States. I do not use it and I have never used it. Have you got?
The Google services they want you to use are usually very numerous. Google can then measure the channels being converted to actual users of that feature or feature. In the meantime, a number of users have become dependent on certain paths in their workflow and have generally ignored others. For example, someone can use Google Pay Send in Gmail every day, but ignore Google Pay in Messages.
A natural consequence of this A / B development approach is that when the data shows that A has been much more successful than B, no choice but to cut ties with B. Many people think about how they use their phone in a vacuum, so they do not understand it. From their point of view, the question is: what is the point of removing this feature?
it really annoys me every time google removes something and people are wondering "what is the benefit of removing it?"
With this logic, every Google application would have all the features.
whoops, impossible to remove the peer-to-peer payment feature of Google Keep because a person uses it
– Stephen Hall (@hallstephenj) July 11, 2019
The problem: If you apply this question and logic to every object removal – given Google's A / B development paradigm, necessarily introduced features that are supposed to, or probably, be removed later – you would be left with dozens of apps with overlapping features and features. Many non-maintainable, messy, inflated and very user-friendly applications. This is not the Google app experience that you want. I promise.
It is true that suppressing the removal of a particular feature for a given person is often both boring and impractical. I do not deny it. By the time Google realizes that it needs to reduce the weight of an app, it tends to have a certain subset of users who absolutely adore the "B". And at the Google scale, 1% of users are many people. So, we see these tweets …
Why is Google deleting the GIF Camera feature in GBoard in future releases? I only discovered it recently and it's pretty cool!
– Paul (@ paul2dart) June 20, 2019
The Gboard rids the creator of gif. It's blowing. @Google
– O (@ Grumpy0tis) June 20, 2019
Listen, I sympathize. To a certain extent, I really do it. I have been the recipient of it. In fact, I am now. Abner and I are broadcasting the Alphabet Scoop podcast on Google Hangouts on Air every week. It's part of our workflow. It's literally our job. And Google has decided that Hangouts On Air is an unnecessary burden, the maintenance of which is probably more than worth it.
Some things to note here. First, Google has important data that can remove the features they destroy. It is common for applications and features that go away are those that 1) have no benefit in terms of Google's financial performance (read: advertising), 2) will soon be replaced by something better, or 3) do not do it. nothing. Do not have enough adoption to warrant ongoing maintenance. As a mobile developer who follows me on Twitter m said"Every little foreign feature is something that can break when you make architectural changes." (As always, there is also a relevant xkcd.)
Make changes openly hostile to users, because they do not directly contribute to Google's advertising revenue, is a difficult thing to defend. I will not really try. Killing features that (relatively) nobody uses makes no sense, and no matter which platform you use, you should always pay attention to creating workflows around objects that may simply be deprecated . (There are flagrant, almost unjustifiable exceptions to this … I'm looking at you, Reader.)
But let's move on to the second point. Google very often intends to replace the features that they "kill". Or, in some cases, they are already redundant and a minor workflow change lets you do almost the same thing using another Google app. Google has just killed the GIF camera in Gboard (why was there a camera in a keyboard, hmm?). Here is an alternative (albeit imperfect): take an animated photo, open Google Photos and download it in GIF format.
This is another example that I have in front of me. With the release of the second beta of Android Q on Google I / O this year, it became clear that Google would depreciate Android Beam. It is easy to advocate for the removal of this feature solely on the basis that only a minority of Android users even knew that it existedbut there was something else going on behind the scenes. Google was working on what appears to be a much more robust and useful alternative, called Fast Share. I would say that is the case most often.
Google has the reputation of trying out new technologies in a new app or service, "killing" them and resurrecting them later than they've ever been. Think about stickers or Google Assistant, from Allo, resurrected in Messages, Google to Google Lens, or Repeat from Inbox, now in Gmail format itself. We have even heard a rumor that Google is working on a new video chat platform based on Duo technology.
On average, the features do not really disappear.
In the end, Google apps tend to improve. On average, the features do not really disappear. Our phones, over the long term, are becoming more and more useful – even when Google sometimes "kills" the features we love. I would say that useful features and new use cases are evolving much faster on Android than on competing platforms, and that's something people have always liked about this platform. It just comes with compromises.
Now, I can not say that the paradigm of (throughout the strategic plan) to throw everything to the wall to see what's left (what I've called Google's "test culture A / B" in this piece) is objectively the best way to approach things. For some reason, however, Google has clearly decided that this approach is better than the relatively methodical, conservative and intentional approach taken by others (Apple is a good example).
It does not seem like this approach to application development is changing anytime, so here's what I'm telling you, Google and Android users: by buying a Google or Android compatible product, you've subscribed to this purchase. It's an essential reality of Google's approach. This approach has in part made Android the most widely used mobile operating system in the world. And while it certainly has drawbacks, it is never as bad as it seems, and it can also have benefits.