В прошлый четверг Вова Фельдман опубликовал статью, в которой просил нас перестать обвинять авторов плагинов в изобилии уведомлений администраторов, которые ежедневно бомбардируют пользователей. Настоящий виновник? Отсутствие механизма уведомлений в ядре WordPress.
Сообщение Фельдмана было вызвано твитом, в котором Скотт Болинджер призвал авторов плагинов выйти из-под контроля.
Фельдман утверждает, что возлагать вину на авторов плагинов – неправильный взгляд на проблему. Хотя я согласен с тем, что основная проблема заключается в WordPress, авторы плагинов сыграли свою роль в создании атмосферы, в которой они стали козлами отпущения за все, что не так с системой.
Я разрабатывал плагины с рокового дня в апреле 2007 года, когда я выпустил плагин, который просто перечислял подстраницы текущей страницы. С тех пор я работал над сотнями плагинов для клиентов и публичных релизов. За это время я, возможно, дважды добавлял настраиваемое уведомление администратора, и только тогда, когда в плагине были серьезные изменения, такие как обновление базы данных. Я зарезервировал такие уведомления для OMGBBQ-очень-очень-важно-вам-нужно-прочитать-такого типа. Я считал своим долгом создать опыт, в котором пользователю не нужно было отклонять уведомление каждый раз, когда один из моих плагинов получал обновление.
Это произошло не потому, что я был осведомлен о растущем количестве десятков уведомлений на некоторых сайтах или о том, как часто пользователи были перегружены ими. В течение многих лет я работал в пузыре, где я просто сосредоточился на создании того, что я считал идеальным для моих пользователей. Я всегда думал, что система уведомлений администратора создает ужасный опыт. Не имело смысла использовать больше, чем нужно.
С другой стороны, вероятно, несколько раз за эти годы мне следовало добавить какие-то уведомления об изменениях. Вместо этого я вообще избегал этого, потому что в WordPress не было системы уведомлений. Я упустил несколько хороших возможностей для общения.
В значительной степени проблема связана с отсутствием надлежащей системы уведомлений. Однако авторы плагинов увековечили эту сломанную систему, продолжая использовать ее, когда в ней нет необходимости. Они использовали его как рекламный щит для размещения своей праздничной рекламы. Они использовали его для перепродажи коммерческих версий своих продуктов и услуг, одновременно предлагая пользователям пятизвездочный рейтинг. Есть много виноватых.
Вместо того, чтобы обвинять, мы должны начать спрашивать, какие инструменты решат проблемы для разработчиков.
Потребность в лучшей системе
Технически WordPress просто имеет ловушку и набор общих классов, которые разработчики могут использовать в своем HTML, чтобы указать разные цвета для уведомлений. Нет API, а без API даже сторонние разработчики плагинов не могут даже попробовать свои силы в создании различных решений.
Самое близкое к API WordPress – это малоизвестный проект от Themes Team, который предоставляет авторам тем стандартизированный метод добавления уведомлений. Однако проект охватывает только один аспект уведомлений администратора, а именно создание согласованного пользовательского интерфейса.
Проблема с уведомлением администратора не может быть решена должным образом без определения проблем, которые авторы плагинов пытались решить в системе, которые, по крайней мере, включают следующее:
Уведомления, ориентированные на пользователя, обычно появляются после действия пользователя.
Реклама коммерческих товаров и услуг.
Призывает отзывы о плагине или звездные рейтинги.
Одна из основных проблем с текущей системой уведомлений заключается в том, что она была создана для первого элемента в этом списке. Два других предмета не обязательно плохие. Это просто неправильное использование существующей системы. Однако другого стандартного метода для обработки этих сценариев не существует.
Реклама – это то, с чем мы все должны иметь дело в той или иной форме. Я не уверен, может или даже должен быть стандартный API для рекламы. Полный запрет рекламы в области уведомлений администратора может создать собственного зверя, заставляя авторов плагинов придумывать более навязчивые формы рекламы в других областях администрирования. Я хочу поддерживать рекламу, но не тогда, когда она продвигается вверх на каждом экране администратора.
WordPress не предоставляет конечным пользователям простой способ оценивать или проверять плагины из своих интерфейсов администратора. Наличие простого способа прямой обратной связи было бы чрезвычайно полезно как для пользователей, так и для разработчиков. Хотя я уверен, что многие люди будут возражать против такой интеграции с сайтом WordPress.org (есть аргументы против любой внешней интеграции из коробки), рейтинги и обзоры потребуют явного согласия со стороны конечных пользователей, потому что им потребуется аккаунт на WordPress.org.
Реклама и отзывы о плагинах не должны быть частью обсуждения уведомлений администратора. Однако реальность подсказывает, что они являются неотъемлемой частью разговора.
Первым делом должно быть создание новой системы уведомлений с нуля. Он должен предоставлять стандартный API для авторов плагинов, передавая при этом все возможности управления владельцам сайтов. Пользователи должны иметь возможность полностью отключать уведомления или даже включать / отключать уведомления для каждого плагина. Заметили, что конкретный автор плагина предоставляет бесполезные уведомления? Ну, просто отключите уведомления от этого плагина. Автор лишился своих привилегий.
С этого момента мы можем позволить прогрессу вести обсуждение того, что делать с рекламой, и призывы к обратной связи. Новая система может переключить их на новый экран – вне поля зрения, – но не избавить от этих проблем.
Сейчас настало время для чемпиона. Проект не обойдется без того, кто проложит путь вперед и получит зеленый свет для новой системы уведомлений в WordPress.
