Продолжая тему, которую я начал в предыдущих постах #1 и #2, хотел бы ознакомить всех желающих с прогрессом по своей идее-технологии. У технологии появилось рабочее название – Pushkin, в честь понятно кого.

Основной тезис

Идея о полезности этой технологии отталкивается от предположений, что:

• Разработчики не обязаны быть ответственны за все тексты в продукте (UX, коммуникации). Разработчики пишут код, они не копирайтеры

• Коллеги разработчиков из других отделов хотят и должны полноценно участвовать в управлении текстами продукта. При этом они не умеют работать с кодом и хотят современную среду для работы

• Правильность, соответствие текстов в продукте напрямую влияют на уровень счастья пользователей и на нагрузку на службу поддержки

Предполагается, что технология может быть очень полезна для всех проектов от среднего до крупного размера вне зависимости от наличия переводов на другие языки. Pushkin – не средство для локализации. Pushkin – намного больше, Pushkin – это средство для управления всеми текстами продукта. Это контроль диалога продукта с пользователями.

Проблема

Я сам разработчик и очень уважаю нашу профессию, но регулярно сталкиваюсь с подобными сообщениями на сайтах, которые, очевидно, писали разработчики:

Далеко не все разработчики умеют красиво выражать свои мысли письменно, но даже если в вашей команде все "Шекспиры", есть и другие проблемы – тексты быстро устаревают, выводятся при наличии каких-то редких условий, плохо выглядят на настоящей странице и так далее.

И тут многие скажут, да в чем проблема? Есть же gettext, есть разные реализации i18n?

Да, есть. Но это, во-первых, замедляет разработчика – разработчику надо выбрать новый уникальный ключ для куска текста каждый раз, а коллегам и переводчикам предлагается работать не со страницами продукта, а с тысячами ключей, с тысячами фрагментов текста, вырванными из контекста.

Разработчик в какой-то момент точно знал, где он использовал этот ключ. Скажем, "registration.form.ssn" – это поле, которое запрашивает SSN при регистрации, но только у пользователей из США. Переводчик же этого не знает, и чтобы взглянуть на страницу в действии – ему надо воссоздать правильные условия, допустим зайти на американскую версию сайта с американского IP.

Во-вторых, тяжело в целом контролировать точность всех текстов и их соответствие, так как практически полностью отсутствует контекст. Ну, скажем, я хочу посмотреть как происходит процесс регистрации нового пользователя у нас в продукте, если пользователь пришел из Испании. Шаг за шагом, включая посланные имейлы. Как это сделать, когда передо мной 10 тысяч ключей и их значений?

Кончается всё тем, что переводчики машинально переводят всё, что поступило, и как результат, даже у гигантских компаний появляются глупые ошибки в продукте.

Установка

Предлагается оборачивать все тексты в продукте в специальную функцию или директиву. За пару месяцев я сделал рабочий прототип плагина для Laravel (PHP) и админку. Вот так выглядит шаблон с текстами, это то, что предлагается сделать разработчику, чтобы начать пользоваться Pushkin:

При вызове этой специальной функции, Pushkin через debug_backtrace() определит текущий контекст – какой это маршрут, какой файл шаблона, класс Mailable и так далее. Вместо примитивных текстовых ключей (идентификаторов), Pushkin использует настоящий контекст в продукте.

После синхронизации через API с Pushkin, эти тексты появятся в админке:

Начиная с этого момента, разработчики и их коллеги могут не трогать тексты в шаблоне, а управлять ими через такие вот редакторы, которые:

• Позволяют редактировать прямо поверх рендера – мы видим, как это будет смотреться на телефонах, на компьютерах в реальности

• Позволяют работать со страницами продукта, а не с шаблонами или отдельными текстами. Концепция страниц интуитивней, это то, как люди в реальности говорят о своем опыте с продуктом. У страниц человеческие, а не технические названия.

Очень удобная абстракция для работы над текстами – сценарии поведения. Допустим, определяем такой сценарий как "Пользователь создает учетную запись", состоящий из трех шагов, включая имейл с подтверждением:

Поддержка всяких особенных условий (состояний) через дропдаун на каждой странице. То есть одна и та же страница, скажем Welcome, может иметь любое количество состояний, допустим: "Для анонимных пользователей", "Для вошедших пользователей" и так далее:

Переводить еще никогда не было так просто. Поменяли язык в дропдауне и начали редактировать поверх настоящего рендера. Прогресс оценивается по настоящим страницам, а не по вырванным из контекста тысячам кусочков текста:

Тем не менее, если по каким-то причинам есть желание работать на низком уровне, вроде уровне шаблонов или отдельных текстов, такая возможность всегда есть:

Это полезно если, скажем, у нас передается какая-то строка через сессию, и в рендере страницы её просто так не видно.

Сценарии и состояния

Чтобы хорошо описать разные сценарии поведения в продукте и разные состояния страниц, предлагается делать очень простые псевдо-тесты – используя стандартные средства (factories) фреймворка создавать нужные конкретные состояния и открывать страницы:

<?php

class PagesTest extends TestCase
{
    use RefreshDatabase, WithFaker, WithPushkin;

    /**
     * @test
     */
    public function journey()
    {
        $this->sequence('User creates account', function () {
            $this->name('About page')->get('/en/about');
            $this->name('Sign up page')->get('/sign-up');
            $this->post('/sign-up', ['email' => $this->faker->email]);
        });
    }
}

Мой trait WithPushkin будет автоматически отправлять всё, что удалось найти во время HTTP-запросов в тесте в Pushkin, используя описания отсюда вроде "User creates account" – будет автоматически создан такой сценарий. Если во время тесты были посланы какие-то письма или сообщения, они будут автоматически пойманы, так как Pushkin подменил почтовый драйвер внутри этого класса тестов.

Я также смонтировал среднее по длине (9 минут) видео на английском, которое пытается доказать полезность моей идеи, начиная с самых азов. Первая половина видео будет понятная любому зрителю, вторая для разработчиков:

Я работал в нескольких стартапах, и такая технология была бы полезна во всех. Я также провёл видео-созвоны с друзьями-разработчиками и предпринимателями, и в целом я слышу очень хорошую обратную связь – все говорят, что боль реальна и такое решение могло бы сработать.

Заключение

Что вы думаете по этому поводу? Считаете ли, что проблема действительно существует? Стали ли пользоваться чем-то подобным тому, что представлено выше?

Если кому-то идея кажется перспективной, а себя Вы считаете достойным разработчиком, имейте, пожалуйста, ввиду, что я ищу себе в проект партнера-кофаундера, и тут на Хабре запостил на днях объявление

Если не нравится, кажется глупой затеей, то прошу конструктивной критики :)