Разделение кода и текста: первая рабочая версия
Продолжая тему, которую я начал в предыдущих постах #1 и #2, хотел бы ознакомить всех желающих с прогрессом по своей идее-технологии. У технологии появилось рабочее название — Pushkin, в честь понятно кого.
Основной тезис
Идея о полезности этой технологии отталкивается от предположений, что:
Разработчики не обязаны быть ответственны за все тексты в продукте (UX, коммуникации). Разработчики пишут код, они не копирайтеры
Коллеги разработчиков из других отделов хотят и должны полноценно участвовать в управлении текстами продукта. При этом они не умеют работать с кодом и хотят современную среду для работы
Правильность, соответствие текстов в продукте напрямую влияют на уровень счастья пользователей и на нагрузку на службу поддержки
Предполагается, что технология может быть очень полезна для всех проектов от среднего до крупного размера вне зависимости от наличия переводов на другие языки. Pushkin — не средство для локализации. Pushkin — намного больше, Pushkin — это средство для управления всеми текстами продукта. Это контроль диалога продукта с пользователями.
Проблема
Я сам разработчик и очень уважаю нашу профессию, но регулярно сталкиваюсь с подобными сообщениями на сайтах, которые, очевидно, писали разработчики:
Текст ошибки на сайте недвижимости. Стоимость компании 22 миллиарда долларовОшибка на государственном сайте в Австралии
Далеко не все разработчики умеют красиво выражать свои мысли письменно, но даже если в вашей команде все «Шекспиры», есть и другие проблемы — тексты быстро устаревают, выводятся при наличии каких-то редких условий, плохо выглядят на настоящей странице и так далее.
И тут многие скажут, да в чем проблема? Есть же gettext, есть разные реализации i18n?
Да, есть. Но это, во-первых, замедляет разработчика — разработчику надо выбрать новый уникальный ключ для куска текста каждый раз, а коллегам и переводчикам предлагается работать не со страницами продукта, а с тысячами ключей, с тысячами фрагментов текста, вырванными из контекста.
Пример решения для работы с i18n-файлами от латвийского стартапа Lokalise
Разработчик в какой-то момент точно знал, где он использовал этот ключ. Скажем, «registration.form.ssn» — это поле, которое запрашивает SSN при регистрации, но только у пользователей из США. Переводчик же этого не знает, и чтобы взглянуть на страницу в действии — ему надо воссоздать правильные условия, допустим зайти на американскую версию сайта с американского IP.
Во-вторых, тяжело в целом контролировать точность всех текстов и их соответствие, так как практически полностью отсутствует контекст. Ну, скажем, я хочу посмотреть как происходит процесс регистрации нового пользователя у нас в продукте, если пользователь пришел из Испании. Шаг за шагом, включая посланные имейлы. Как это сделать, когда передо мной 10 тысяч ключей и их значений?
Кончается всё тем, что переводчики машинально переводят всё, что поступило, и как результат, даже у гигантских компаний появляются глупые ошибки в продукте.
Установка
Предлагается оборачивать все тексты в продукте в специальную функцию или директиву. За пару месяцев я сделал рабочий прототип плагина для Laravel (PHP) и админку. Вот так выглядит шаблон с текстами, это то, что предлагается сделать разработчику, чтобы начать пользоваться Pushkin:
Привет использования специальной директивы
При вызове этой специальной функции, Pushkin через debug_backtrace () определит текущий контекст — какой это маршрут, какой файл шаблона, класс Mailable и так далее. Вместо примитивных текстовых ключей (идентификаторов), Pushkin использует настоящий контекст в продукте.
После синхронизации через API с Pushkin, эти тексты появятся в админке:
Редактирование текста в админке Pushkin
Начиная с этого момента, разработчики и их коллеги могут не трогать тексты в шаблоне, а управлять ими через такие вот редакторы, которые:
Позволяют редактировать прямо поверх рендера — мы видим, как это будет смотреться на телефонах, на компьютерах в реальности
Позволяют работать со страницами продукта, а не с шаблонами или отдельными текстами. Концепция страниц интуитивней, это то, как люди в реальности говорят о своем опыте с продуктом. У страниц человеческие, а не технические названия.
Все найденные страницы продукта с человеческими названиями и настоящим дизайном
Очень удобная абстракция для работы над текстами — сценарии поведения. Допустим, определяем такой сценарий как «Пользователь создает учетную запись», состоящий из трех шагов, включая имейл с подтверждением:
Поддержка всяких особенных условий (состояний) через дропдаун на каждой странице. То есть одна и та же страница, скажем Welcome, может иметь любое количество состояний, допустим: «Для анонимных пользователей», «Для вошедших пользователей» и так далее:
Переводить еще никогда не было так просто. Поменяли язык в дропдауне и начали редактировать поверх настоящего рендера. Прогресс оценивается по настоящим страницам, а не по вырванным из контекста тысячам кусочков текста:
Тем не менее, если по каким-то причинам есть желание работать на низком уровне, вроде уровне шаблонов или отдельных текстов, такая возможность всегда есть:
Это полезно если, скажем, у нас передается какая-то строка через сессию, и в рендере страницы её просто так не видно.
Сценарии и состояния
Чтобы хорошо описать разные сценарии поведения в продукте и разные состояния страниц, предлагается делать очень простые псевдо-тесты — используя стандартные средства (factories) фреймворка создавать нужные конкретные состояния и открывать страницы:
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 минут) видео на английском, которое пытается доказать полезность моей идеи, начиная с самых азов. Первая половина видео будет понятная любому зрителю, вторая для разработчиков:
Я работал в нескольких стартапах, и такая технология была бы полезна во всех. Я также провёл видео-созвоны с друзьями-разработчиками и предпринимателями, и в целом я слышу очень хорошую обратную связь — все говорят, что боль реальна и такое решение могло бы сработать.
Заключение
Что вы думаете по этому поводу? Считаете ли, что проблема действительно существует? Стали ли пользоваться чем-то подобным тому, что представлено выше?
Если кому-то идея кажется перспективной, а себя Вы считаете достойным разработчиком, имейте, пожалуйста, ввиду, что я ищу себе в проект партнера-кофаундера, и тут на Хабре запостил на днях объявление
Если не нравится, кажется глупой затеей, то прошу конструктивной критики :)