Google, безусловно, находится на одном конце спектра в своем подходе к разработке приложений. Если другой производитель программного обеспечения консервативен и осторожен в отношении функций, которые он добавляет в свои приложения и когда, то Google можно назвать… противоположностью. Давно установлено, что A/B-тестирование является неотъемлемой частью корпоративной культуры, и потребительские приложения не являются исключением.
Вы, скорее всего, знакомы с этой концепцией на макроуровне — например, «Если мы попробуем пять подходов к приложениям для обмена сообщениями, по крайней мере, один должен сработать в долгосрочной перспективе, верно?» (Надеюсь, в данном конкретном случае Google признает, что ответ в основном «не совсем».)
Но это применимо и на микроуровне. У Google может быть желание, например, иметь устоявшийся сервис peer-to-peer платежей. Поэтому они могут попытаться интегрировать эту функциональность в приложение Messages, в отдельное приложение Google Pay и, возможно, даже куда-нибудь еще, куда вы не ожидаете, например, в Google Maps (нет, это не функция). Они делали странные вещи.
«Кто знает?», — спрашивает Google. «Может быть, люди хотят отправлять деньги друзьям через Gmail?» Или, возможно, получив такую возможность, люди поймут, что это абсолютно критически важная часть их повседневного рабочего процесса (жизнепотока?), без которой они не могут жить. Да, вы *действительно* можете отправлять деньги людям через Google Pay в Gmail в США. Я им не пользуюсь и никогда не пользовался. А вы?
Существует тенденция к большому количеству «входных точек» в сервисы Google, которыми они хотят, чтобы вы пользовались. Затем Google может измерить, какие пути конвертируются в реальных пользователей этой функции или функциональности. Тем временем, определенный процент пользователей привык полагаться на определенные пути как на часть своего рабочего процесса и обычно игнорирует другие. Один человек может, например, ежедневно использовать Google Pay Send в Gmail, но игнорировать Google Pay в Messages.
Естественным следствием такого A/B-подхода к разработке является то, что в конечном итоге, когда данные показывают, что А был намного успешнее В, у вас *нет другого выбора, кроме как разорвать связи с В*. Многие люди думают о том, как они используют свой телефон, в вакууме, поэтому они этого не понимают. С их точки зрения, вопрос заключается в том, «Какую пользу приносит удаление этой функции?»
https://twitter.com/hallstephenj/status/1149328042180993024
Проблема: если применить этот вопрос и логику к каждому отдельному удалению функции — учитывая парадигму A/B-разработки Google, которая *неизбежно* вводит функции, которые, как предполагается, будут удалены позже, или даже, скорее всего, — вы останетесь с десятками приложений с дублирующимися функциями и возможностями. Многие неуправляемые, беспорядочные, раздутые и совершенно недружелюбные к пользователю приложения. Это не тот пользовательский опыт Google, который вы хотите. Обещаю.
Правда в том, что удаление конкретной функции для конкретного человека часто бывает как раздражающим, так и неудобным. Я этого не отрицаю. К тому времени, когда Google понимает, что им нужно «подрезать жир» в приложении, у Google обычно появляется определенный набор пользователей, которые абсолютно обожают «B». А в масштабах Google 1% людей — это *очень много людей*. Поэтому мы видим эти твиты…
Почему Google удаляет функцию GIF Camera в GBoard в будущих версиях? Я только недавно ее обнаружил, и она довольно крутая!
— Paul (@paul2dart) 20 июня 2019 г.
Gboard избавляется от создателя GIF. Это отстой. @Google
— O (@OldeDetroiter) 20 июня 2019 г.
Послушайте, я сочувствую. До некоторой степени, правда. Я сам испытал это. На самом деле, я испытываю это *прямо сейчас*. Мы с Эбнером каждую неделю транслируем подкаст Alphabet Scoop на Google Hangouts on Air. Это часть нашего рабочего процесса. Это буквально наша работа. И Google решил, что Hangouts on Air — это ненужный балласт, содержание которого, вероятно, обходится дороже, чем он стоит.
Стоит отметить несколько моментов. Во-первых, у Google есть значительные данные, подтверждающие удаление тех функций, которые они удаляют. Есть тенденция, что приложения и функции, которые удаляются, это те, которые 1) не приносят никакой выгоды чистой прибыли Google (читай: рекламе), 2) скоро будут заменены чем-то лучшим, или 3) просто не имеют достаточного охвата, чтобы оправдать текущее обслуживание. Как сказал один мобильный разработчик, который следит за мной в Twitter сказал: «каждая мелкая дополнительная функция — это то, что может сломаться при внесении архитектурных изменений». (Как всегда, есть также соответствующий xkcd.)
Принятие откровенно враждебных к пользователю изменений, поскольку они напрямую не способствуют доходу Google от рекламы, трудно защитить, поэтому я не буду особо пытаться. Удаление функций, которыми пользуются (относительно) никто, имеет простой смысл, и независимо от того, какой платформой вы пользуетесь, вы всегда должны быть осторожны при построении своих рабочих процессов вокруг вещей, которые могут быть просто устаревшими из-за недостаточного использования. (Существуют вопиющие, почти неоправданные исключения из этого… Я смотрю на тебя, Reader.)
Но давайте остановимся подробнее на втором пункте. Google очень часто планирует заменить функции, которые они «убивают». Или в некоторых случаях они уже избыточны, и небольшая корректировка рабочего процесса позволит сделать то же самое, используя другое приложение Google. Google только что удалил GIF-камеру из Gboard (почему вообще была камера в клавиатуре, хм?). Вот (признаться, несовершенная) альтернатива: сделайте Motion Photo, откройте Google Photos и скачайте его как GIF.
У меня есть еще один пример, который приходит на ум. С выпуском второй бета-версии Android Q на Google I/O в этом году стало очевидно, что Google выведет из эксплуатации Android Beam. Легко аргументировать в пользу удаления этой функции, основываясь только на том факте, что лишь меньшинство пользователей Android *даже знали о ее существовании*, но за кулисами происходило что-то еще. Google работал над тем, что похоже, является гораздо более надежной и полезной альтернативой под названием Fast Share. Я бы сказал, что это происходит чаще, чем нет.
Google печально известен тем, что пробует новые технологии в новом приложении или сервисе, «убивает» их и воскрешает позже, лучше, чем они когда-либо были. Например: Stickers или Google Assistant из Allo, воскрешенные в Messages; Goggles в Google Lens; или Snoozing из Inbox, теперь в Gmail. Мы даже слышали слух, что Google работает над новой платформой видеосвязи на основе технологий Duo.
В конечном итоге, приложения Google становятся лучше. В среднем, функции на самом деле не исчезают. Наши телефоны в долгосрочной перспективе становятся все более и более полезными — даже несмотря на то, что Google иногда «убивает» функции, которые мы любим. Я бы сказал, что полезная функциональность и новые сценарии использования развиваются на Android гораздо быстрее, чем на конкурирующих платформах, и это то, что люди всегда любили в платформе. Просто это сопряжено с компромиссами.
Теперь я не могу сказать, что парадигма (стратегического, а не случайного) выбрасывания всего на стену, чтобы увидеть, что прилипнет (то, что я назвал «культурой A/B-тестирования Google» в этой статье), объективно лучший способ подходить к вещам. Однако по какой-то причине Google явно решил, что этот подход лучше, чем относительно методичный, консервативный и целенаправленный подход, который применяют другие (Apple — один из хороших примеров).
Похоже, что этот подход к разработке приложений в ближайшее время не изменится, поэтому я говорю вам, пользователю Google и Android: покупая продукт под управлением Google или Android, вы согласились на это. Это неизбежная реальность подхода Google — подхода, который частично сделал Android доминирующей мобильной операционной системой в мире. И хотя у него, безусловно, есть свои недостатки, он никогда не бывает таким ужасным, как кажется, и у него могут быть и свои преимущества.