Блог Игоря Шевченко

Гиперобщительный магазин 3 декабря 2017

Недавно я сделал заказ в местном интернет-магазине. Через три часа заехал к ним на склад и забрал его. За эти три часа магазин прислал мне 9 электронных писем и 8 смс.

Вот эти сообщения. Смс нужно читать сверху вниз, а письма снизу вверх.

Я не стал убирать название магазина и другие подробности, но это не реклама и не критика конкретного магазина. Как писал Антон Жиянов, магазин вообще не виноват, они просто поставили движок, который из коробки работает таким образом. Тем не менее, я предлагаю подумать, сколько из этих сообщений можно было бы убрать или сделать необязательными в хорошем движке.

Кассовый чек и письма от платежного шлюза. Закон об онлайн-кассах, который начал действовать эти летом, требует обеспечить возможность отправки кассового чека на покупки в интернете по электронной почте. Только обеспечить возможность — они не обязаны отправлять чек, если покупателю он не нужен. Некоторые сервисы это учитывают, а некоторые, как в этом случае, требуют обязательно указать адрес для чека. А потом пользуются этим адресом, чтобы отправить еще пару писем от себя. Если сделать ввод почты опциональным, то это уже −3 письма.

Регистрация. При заказе я дважды вводил код из смс — первый раз для регистрации на сайте, второй раз для подтверждения заказа. Сейчас в хороших интернет-магазинах уже не требуют зарегистрироваться перед заказом, регистрация происходит по ходу его оформления. Если бы в этом магазине было так же, то достаточно было бы одного подтверждения. −1 смс.

Пароль. В уведомлениях о регистрации пришли пароли в открытом виде. Это не означает, что они так и хранят их, но всё равно это плохая практика. Отправлять пароли небезопасно, потому что письма и смс могут быть прочитаны человеком посередине или, что немного более вероятно, любым, кто получит доступ к почтовому ящику или телефону. Больше в этих сообщениях ничего полезного нет, убираем их: −1 письмо, −1 смс.

Ненужные этапы. Заказ на сайте разбит на две части. Сперва я оформляю заказ и резервирую товар, а потом мне предлагают его оплатить. Я оплачиваю сразу, поэтому для меня смысла в этом промежуточном этапе нет: −1 письмо, −1 смс. Еще один ненужный этап — «заказ скомплектован», когда его весь собрали в одном месте, но забрать пока что нельзя. Непонятно, что я должен делать с этой информацией. −1 письмо.

Очевидные этапы. Я сам оплачиваю заказ на сайте и забираю его в магазине, поэтому я и так знаю о том, что эти события произошли. Убираем избыточные уведомления: −2 письма, −2 смс.

Дублирование. В почте осталось последнее письмо — о том, что заказ доставлен. Вот это очень полезная информация, но я и так об этом узнал из смс. Давайте уберем и это письмо, тогда можно будет даже не запрашивать у пользователей почту. −1 письмо.

Код подтверждения. Когда я забираю покупку, мне отправляют смс с кодом подтверждения. Молодцы, проверяют, чтобы какие-нибудь жулики не пришли и не взяли мой оплаченный заказ. Но этот код можно было сразу вставить в смс о том, что заказ доставлен. Плюсов у этого варианта куча: не нужно ждать смс на кассе, можно попросить кого-то другого забрать заказ и сказать ему код, можно записать куда-нибудь код, когда садится телефон. −1 смс. А если я это сообщение всё-таки как-то потеряю, то тогда уже можно по запросу прислать новое.

В итоге осталось два нужных сообщения: подтверждение телефона при заказе и сообщение о том, что заказ доставлен. Если бы мне прислали только их, я бы вообще сразу же забыл, что были какие-то смс. Но когда сайт бомбардирует уведомлениями по двум каналам, это сложно не заметить, и это немного напрягает. 

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

Нет комментариев

Неверное имя пользователя или пароль 26 ноября 2017

Практически любой сайт, если попытаться авторизоваться с неверными данными, выдаст стандартное сообщение: «Неправильное имя пользователя или пароль». Если вы разрабатываете какой-то сайт, то скорее всего, он говорит то же. Считается, что такой расплывчатый текст усложняет работу хакерам, которые взламывают аккаунты на сайте. Взломщики будут тратить много времени на попытки подобрать пароль к пользователям, которые даже не зарегистрированы. Простым людям от этого менее удобно, но это обычный компромисс между удобством и безопасностью.

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

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

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

Но если бы я был плохим парнем (или если бы хотел получать в два раза больше маркетинговых писем), то просто пошел бы на страницу регистрации. Когда вводишь там занятый почтовый адрес, сайт честно сообщает об этом.

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

Если вы хотите сделать авторизацию на сайте безопаснее, есть более эффективные способы:

  1. Ограничивайте количество попыток ввода неправильного пароля, а потом показывайте капчу или блокируйте.
  2. Помогайте пользователю выбрать надежный пароль с помощью индикаторов сложности пароля.
  3. Добавьте двухфакторную аутентификацию.
  4. Зарегистрируйте логины-ханипоты (вроде admin@yoursite.com) и блокируйте тех, кто пытается в них войти.

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

4 комментария

Как писать интерфейсные надписи 10 сентября 2017

Представьте себе разработчика Петра, который с утра пришел на работу и увидел в Джире такую задачу:

Добавить на страницу с отчетом возможность отправить csv-версию отчета на почту текущему пользователю

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

Вопросы, о которых думает Петр во время работы над задачей, — как написать оптимальный SQL-запрос, как разрешить конфликт версий между библиотеками, как правильно настроить кодировку файла... Тексты только отвлекают от реальных задач Петра, поэтому он на них особо не останавливается. Если вы когда-нибудь видели в программах или на сайтах странные и непонятные надписи, то скорее всего, они появились в подобной ситуации.

В крупных компаниях вроде Фейсбука и Дропбокса в последние годы стали появляться специальные люди в роли UX-копирайтеров, которые пишут тексты для интерфейса. Но большинство программистов работает не в таких компаниях. Хорошо, если есть хотя бы дизайнер, но даже ходить к дизайнеру за каждым сообщением об ошибке слишком накладно. В итоге надписи приходится писать самим программистам.

Этот пост — конспект внутреннего доклада, в котором я собрал советы для себя и других разработчиков нашей компании о том, какими должны быть надписи. Эти принципы предназначены для тех текстов, которые обычно пишут программисты. У маркетологов, сеошников и авторов корпоративных блогов наверняка есть какие-то свои правила.

Надписи должны быть точными

Иногда тянет написать какой-то обобщенный текст и использовать его во всех возможных ситуациях. Например, для всех ошибок выводить сообщение «Что-то пошло не так».


Это скриншот интерфейса электронной регистрации на авиарейс из блога Артемия Лебедева. Если бы разработчики указали, в каком виде они хотят получить номер телефона, Артемий и другие пассажиры тратили бы намного меньше времени на попытки угадать формат.


Это пример из гугловских гайдлайнов. Точное сообщение помогает людям быстрее увидеть ошибку во введенных данных.


Посмотрите, как Трелло обрабатывает невалидные почтовые адреса. Они не поленились вместо простого сообщения «Введите правильный емейл» разобрать случаи и указать, в какой части адреса проблемы. Давайте быть как Трелло и разбирать случаи, чтобы пользователям меньше приходилось разбираться самим.

Надписи должны быть полезными

Все тексты должны вести пользователя напрямую к решению его задачи. Увидев надпись, он должен сразу понять, что ему делать дальше.

Есть история об устройстве, которое при отсутствии электричества показывало сообщение: «Ошибка пониженного напряжения». В какой-то момент сообщение заменили другим: «Проверьте электрический кабель». Количество звонков в техподдержку уменьшилось, потому что теперь владельцы прибора сами понимали, что им нужно включить его в розетку.


Это сообщение появлялось при отправке твита через клиент для Мака. Программа говорит, что дело в приложенной картинке, но не дает никакого решения. Если не знать, что эта надпись выводится, когда картинка превышает ограничение по размеру, то невозможно догадаться сжать ее.


Ошибка авторизации в Мейлчимпе. Сайт точно указывает, в чем проблема — в несуществующем юзернейме или неправильном пароле. Но помимо этого, он сразу же предлагает пользователю следующее логичное действие и показывает прямо в сообщении ссылку на восстановление юзернейма или пароля.


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

Надписи должны быть человечными

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


Это канадский транспортный терминал. С точки зрения обычного человека, терминал нужен, чтобы класть деньги на карточку, а потом расплачиваться ею в автобусе. С точки зрения программистов, этот терминал делает запросы к биллинговому серверу, которые могут иметь статусы «Выполнен» и «Ошибка». Программисты понимают, что значит «Запрос выполнен», а для нормальных людей это сообщение не несет никакого смысла.


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


Удивительный факт: пользователи никогда не считают себя или других людей «пользователями». На сайте с митапами это понимают, поэтому пишут не просто «10 пользователей идут на это событие», а указывают, что это за люди. Например, на встречу клуба читателей собирается 21 книжный червь.


Ну и совсем плохо, если пользователь видит техническое сообщение вроде NullReferenceException was thrown. Такие сообщения помогают при отладке, но на продакшне их нужно отключать.

Надписи должны быть короткими

Стив Круг в книге «Не заставляйте меня думать» пишет, что пользователи обычно ведут себя очень хаотично. Они быстро и сфокусированно делают какие-то вещи, направленные на решение их задачи, и почти ничего не читают. Короткие надписи увеличивают вероятность, что пользователь всё-таки зацепит их взглядом и что-то поймет. Поэтому надписи должны быть максимально короткими — не для того, чтобы сэкономить время на чтение, а потому, что длинную надпись просто проигнорируют.


Это два варианта одного сообщения от Дропбокса. Посмотрите на них и попробуйте представить, что они появились у вас во время работы. Первое сообщение мне хочется быстро окинуть взглядом и сразу нажать на кнопку. Второе прочитать полностью намного легче.

Надписи должны быть самодостаточными

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

В бюро Горбунова это называют «взглядом новичка». Каждое возможное состояние должно иметь смысл с точки зрения человека, который забыл всё, что видел до этого. Если какая-то надпись непонятна сама по себе, нужно добавить в нее больше контекста и информации.


Еще лучше, когда самодостаточны даже отдельные элементы на экране. Например, маковские гайдлайны требуют не писать на кнопках просто «Да», «Нет», «Ок», а указывать совершаемое действие: «Сохранить» или «Удалить». Тогда решение получится принять быстрее, а вероятность нажать не на ту кнопку будет меньше.

Надписи должны быть уместными

Об этой проблеме хорошо написано в статье «Опаньки! Я сломал вам жизнь :)» (цитата из перевода с Хабра):

Ещё не угасла надежда на слабый сигнал Wi-Fi в аэропорту, на заряд батареи, который вот-вот заставит ноутбук вырубиться — а розетку здесь найти та ещё задача — и на то, что письмо клиенту на миллион долларов вроде ушло. И в этот момент «пожалуйста, заработай» вылезает приводящее в шок сообщение: «Упс». Как в некоторые бросающие в дрожь моменты фильма «Американский психопат» это не очень различимое, бесстрастное сообщение от почты Gmail вонзает кинжал точно в моё сердце, мгновенно порождая отчаяние — что же пошло не так?

Сейчас модно вставлять в тексты микрокопию — небольшие забавные тексты, которые по задумке должны приятно удивить или повеселить пользователя. Например, сервис почтовых рассылок Мейлчимп хвалит пользователя, дописавшего письмо, говоря ему «High Fives!» и показывая гифку с обезьяньей рукой. А если попытаться зарегистрироваться в Тумблере под уже занятым именем, появится сообщение «That's a good one, but it's taken».

Мне нравятся такие штуки, но с ними нужно быть очень аккуратными. Текст должен соответствовать тому, что чувствует пользователь. Слишком веселое сообщение об ошибке будет восприниматься как издевательство. У Мейлчимпа есть справочник по тональности для разных случаев. Пользуйтесь им.

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

Надписи должны быть целостными


Это скриншоты из старого Дропбокса. История версий файла в трех местах называется по-разному, и это будет путать пользователя. Если он запомнил заголовок «Version History», то он будет искать его в меню, где вместо этого написано «Previous versions». Будьте в курсе терминологии вашей системы и везде используйте единые понятия.

Целостность важна не только в терминологии, но и в деталях. Если все валидационные сообщения заканчиваются точкой, не забудьте поставить ее в очередном валидационном сообщении. Лично я не люблю писать «Вы» с большой буквы, но если так пишут на всем остальном сайте, то я не буду поднимать бунт и писать свой отдельный текст по-другому.


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

Надписи должны быть грамотными

Это очевидно, но ошибки и опечатки встречаются у всех. Проверяйтесь. Хорошо, если ваши IDE или линтер умеют находить ошибки в текстах.

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

Отдельная проблема есть с динамическими сообщениями вроде «22 файлов отправлено». Чтобы они были формально корректными, в них часто меняют формулировку на что-нибудь вроде «Файлов отправлено: 22». Это звучит очень неестественно, лучше написать по-человечески, разобрав возможные случаи (это легко).

Надписи должны быть необходимыми

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

Делайте работу за пользователя. В примере с Артемием Лебедевым и форматом телефона на сайте авиакомпании можно было просто приводить номер к нужному виду внутри системы.

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

Домашнее задание

Повторю список правил еще раз, надписи должны быть:

  1. Точными
  2. Полезными
  3. Человечными
  4. Короткими
  5. Самодостаточными
  6. Уместными
  7. Целостными
  8. Грамотными
  9. Необходимыми

Чтобы они лучше запомнились, у меня есть для вас небольшое домашнее задание. Ниже я привел несколько надписей. Попробуйте улучшить их. Если нужен какой-то дополнительный контекст, можете придумать его самостоятельно.

  • Эта возможность доступна только платным подписчикам.
  • (при сбросе пароля) Ваш временный код уже использован или истек!
  • Duplicate entry "ivan@gmail.com" for key "ixemail"
  • Пост не может быть удален.
  • Ошибка авторизации: вы уже авторизованы.
9 комментариев

Быстрые напоминания в Слаке 15 марта 2017

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

В Слаке много удобных фишек, но самыми недооцененными мне кажутся быстрые напоминалки.  В списках советов для пользователей Слака им уделяется столько же внимания, сколько команде /shrug ¯\_(ツ)_/¯

Напоминалки прячутся под кнопкой Remind me about this возле каждого сообщения.

Слак предлагает готовые временные интервалы Слак предлагает готовые временные интервалы

Слакбот подтверждает установку напоминалки Слакбот подтверждает установку напоминалки

Время пришло, и слакбот прислал сообщение в личку Время пришло, и слакбот прислал сообщение в личку. Иногда я слишком занят в этот момент, и тогда прошу слакбота написать еще раз попозже

На мобильниках это тоже есть.

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

/remind [@имя или #канал или me] [о чем напомнить] [когда напомнить]

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

/remind me to fix the bug tomorrow at 10:00

Слакбот подтверждает установку напоминалки из консоли

Слакбот понимает все формулировки даты напоминания, которые я пробовал — in 1 hour, at 12:00, on Tuesday, next week, mar 28, every day at 4:20pm. На русском не понимает, но это не страшно.

Типичные сценарии использования:

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

Можно ставить напоминалки для других пользователей, но я этим не пользуюсь. По-моему, слишком агрессивно, лучше написать самому.

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

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

Нет комментариев

NaNoGenMo: как компьютеры пишут новеллы 4 ноября 2016

Ноябрь считается месяцем литературного творчества. Каждый год в интернете проходит мероприятие NaNoWriMo (National Novel Writing Month). Участники должны до конца месяца написать новеллу длиной не менее 50000 слов. За 17 лет в нем поучаствовали больше 20000 человек.

В 2013 году у программистов появилось аналогичное соревнование — NaNoGenMo (National Novel Generation Month). Задача NaNoGenMo — написать программу, которая сгенерирует новеллу длиной 50000 слов или больше. При этом требования к новелле довольно слабые — подойдет любой текст достаточной длины. Как вы увидите, это может быть сборник рассказов, пьеса, кулинарная книга, словарь или туристический путеводитель. На самом деле, произведение не обязано даже быть текстовым.

Графическая новелла «Сгенерированный детектив»

Сама по себе задача написать программу, которая сгенерирует текст из 50000 слов, проста. Для этого достаточно вот такого кода:

print 'мяу ' * 50000

С другой стороны, читать такую новеллу будет скучно уже начиная с третьего слова. Участники NaNoGenMo пытаются решить эту проблему. Они придумывают литературные и технические ходы, которые позволили бы удержать внимание читателя. Это уже гораздо сложнее. На практике, если можно с интересом прочитать хотя бы несколько страниц новеллы — это можно считать успехом.

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

Марковские цепи

Цепи Маркова — классический способ генерации текста. Он хорошо описан здесь. У цепей Маркова есть проблема: если выбрать для N-грамм большое значение N (обычно 5 и больше), то в тексте проявляются большие куски исходного корпуса, если взять N меньше, то он получается откровенно бессмысленным.

Но эта проблема решаема: некоторые жанры произведений могут успешно скрывать от читателя свою бессмысленность. Например, реплики из диалогов Сократа и Аристотеля от yourpalal с первого взгляда трудно отличить от философских размышлений. Точно так же я бы не раздумывая принял сгенерированное лицензионное соглашение от greg-kennedy, если бы увидел его в установщике нужной мне программы.

Другие произведения, основанные на цепях Маркова: эротические рассказы от Agrajag-Petunia, речи Рейгана (с примесью работ Шопенгауэра) от VincentToups, автобиографии на английском 19 века от lizrush.

Расширение шаблонов

Чаще всего осмысленные фрагменты текста генерируют с помощью шаблонов. Представим, что у нас есть такая грамматика:

sentence = '<greeting>, <world_phrase>!'
greeting = ['Привет', 'Приветик', 'Здравствуй', 'Добрый день']
world_phrase = ['<happy_adj> мир', '<sad_adj> мир', 'мир']
happy_adj = ['прекрасный', 'светлый', 'добрый']
sad_adj = ['унылый', 'жестокий', 'мрачный']

На основе нее мы можем сгенерировать много разных предложений — «Привет, унылый мир!» или «Добрый день, прекрасный мир!». Чем богаче грамматика, тем более интересные тексты она выдает.

В «The Gamebook of Dungeon Tropes» от maetl с помощью шаблонов генерируются описания подземелий.

В «Атеистах, которые верят в Бога» от tra38 используются данные какой-то переписи населения США. Герои новеллы — люди, которые сказали, что они атеисты, но верят в Бога. Они один за другим читают шаблонные лекции, в которые подставлены ответы на вопросы из переписи.

Шаблоны используются в новелле «Где-то что-то» от BenKybartas, сборнике «5000 рассказов» от tinyworlds, эротической новелле «Оргазмотрон» от enkiv2 (простите, больше эротики не будет) и спортивном комментарии «Федерация лжеамериканского футбола» от creade.

Рекурсия

Шаблоны позволяют получить небольшой фрагмент читабельного текста. Но по правилам соревнования новелла должна быть не короче 50000 символов. Изящно нарастить объем помогает рекурсия.

Простой вариант: в «The transorbital anaphase provine biforn the pure-bred synostosis» от samcoppini берется одно предложение (оно вынесено в заголовок). А затем с помощью словаря дается определение некоторых слов. Для слов из определений тоже даются определения. И так пока не наберется пятьдесят тысяч.

«Гигант без сердца» от MichaelPaulukonis рассказывает вариации норвежской сказки о принце, который спас своих братьев от злого гиганта. Но в конце этот принц сам становится гигантом и похищает детей другого короля. И вся история повторяется, но уже немного по-другому.

Новелла «Надежды и воспоминания» от cpressey состоит из нескольких событий и диалога двух персонажей. По ходу новеллы они встречают вампира, зомби, дракона и других чудовищ. А всё остальное время они вспоминают свои встречи и предполагают, кого они увидят в будущем. А потом вспоминают, как вспоминали какую-то встречу, предполагают, будут ли они вспоминать, как предполагали другую встречу и так далее.

Похожа по структуре «Redwreath and Goldstar Have Traveled to Deathsgate» от erkyrath. Там тоже два персонажа ведут разговор. Они очень вежливые — спрашивают: «Могу ли я задать вопрос?» и «Правильно ли я понимаю, что...». И так пока в какой-то момент не доходит до такой реплики:

"You want to know whether I am asking whether you are asking whether you shall tell me whether you want to know whether I believe I can answer that?"

«Сто шестьдесят пять дней Рождества» от hugovk — это продолжение английской народной песни «Двенадцать дней Рождества», где продолжают дарить новые и новые подарки (и их количество тоже растет).

Переработка существующих произведений

Если литературное произведение находится в публичном достоянии, его можно использовать любым способом. В том числе и для генерации нового произведения на его основе. Самые интересные примеры:

Моби Дик на кошачьем языке от hugovk. Это одна из самых известных работ NaNoGenMo про которую писали The Guardian, Vox и The Atlanctic. Просто приведу цитату:

Meow me Meeeeow. Meow meeow mew--meoow meow mew meow meeeeooow--meeeow meeeow me me meeow me me meoow, mew meeeoow meeeooooow me meooooow me me meeow, M meeooow M meoow meow meoow m meooow mew mew mew meooow meow me mew meeow.

Сравните с оригиналом:

Call me Ishmael. Some years ago--never mind how long precisely--having little or no money in my purse, and nothing particular to interest me on shore, I thought I would sail about a little and see the watery part of the world.

«Приключения Шарлотты Холмс» от emdaniels. Автор поменяла пол всех персонажей в рассказах о Шерлоке Холмсе. Звучит не очень серьезно, но на самом деле это непростая лингвистическая задача. C которой автор справилась не до конца (поэтому пришлось придумать местоимение herr).

To Charlotte Holmes he is always THE man. I have seldom heard her mention him under any other name. In herr eyes he eclipses and predominates the whole of him sex. It was not that she felt any emotion akin to love for Ivan Adler.

«Гомерическое ультранасилие» от lilinx. Из текста Илиады выбрали все предложения, в которых есть слово «ударить» в одной из форм. Получилось описание длинной и жестокой бойни, в которой уже даже непонятно, кто с кем сражается.

«Моби Дик, или :whale:» от pteichman — еще один вариант Моби Дика, в котором некоторые слова заменили соответствующими эмодзи.

Другие произведения: «Приключениях Тома Сойера» с героями из романа про Конана от MrDrews, «Гамлет» от dkurth, пропущенный через несколько этапов машинного перевода, «Гордость и предубеждение» с лексикой из Твиттера от michelleful, «Превращение» Кафки, в котором каждое слово заменено более абстрактным, от jonkagstrom.

Не обязательно использовать только одно произведение. Например, сборник коротких рассказов, состоящих из шести слов, от hugovk.

А в «Нашем прибытии» (PDF) от aparrish из корпуса «Проекта Гутенберг» выбраны предложения, в которых описываются какие-то природные объекты или явления. Собранные вместе, они составляют дневник некой экспедиции. Получилось очень красиво, эта новелла занимает одно из мест в моем личном топе новелл с NaNoGenMo.

Переработка других данных

Не обязательно брать в качестве основы литературное произведение. moonmilk составил новеллу из твитов участников NaNoWriMo (PDF) (это то соревнование, где люди сами пишут новеллы), а jimkinsey — из вопросов, которые ученые задают в аннотациях статей (PDF):

In what sense is this a novel situation? Should conflicts in the private domain be exempted from public scrutiny in cases where individual are being deprived of their basic legal rights? How many students study abroad and where do they go? Furthermore if the existing policies are found to be ineffective, what all policy measures can be suggested to the Government to put an end to this evil practice? Who are user entrepreneurs?

Сгенерированные новостные отчеты о NaNoGenMo от enkiv2 трудно отличить от настоящих статей.

В «Словаре языка D'skuban» от samcoppini словам из выдуманного компьютером языка даны определения терминов из реального словаря.

Новелла «Искатель» (PDF) от thricedotted рассказывает о том, как компьютер учится делать всё, что делают люди, с помощью сайта wikiHow.

Симуляция

Хорошей новелле нужны сюжет и развитие событий. Один из способов добиться этого — симуляция. Автор программы создает некоторый мир и описывает правила, по которым он функционирует. А потом просто перечисляет события, которые в этом мире происходят. Если эти события интересные, сюжет тоже получается интересным. Похоже на компьютерную игру, но вы не играете в нее, а читаете лог.

Герои серии фэнтези-новелл от mattfister ходят по разным местам. Если у них кончается еда, они идут охотиться или рыбачить, а устав, они разбивают лагерь. Иногда им встречаются враги, с которыми приходится сражаться.

Похожим образом герои новеллы flexo бродят по арене и дерутся при встрече.

Кроме сражений, есть и другие симуляции. В «Вечере дождливого дня» от cpressey Алиса и Боб играют в карты. В новелле nothings Ханна решает задачу о Ханойской башне (для 50000 слов хватило двенадцати дисков). Во «Флоре и фауне» от amarriner ботаник ищет выход из лабиринта, встречая по пути животных и растения.

Иногда авторы симулируют перемещения по реальному миру. В «Вокруг света за X статей Википедии» от kevandotorg Филеас Фогг и Паспарту совершают кругосветное путешествие, рассказывая факты о местах, которые они посещают. «Книга Элизы» от greg-kennedy приводит подробный маршрут сорокалетнего путешествия Моисея по пустыне (даже есть карта!).

Высокоуровневая генерация сюжета

Другой подход к построению сюжета — сформировать основные сюжетные точки, а потом уже развернуть их в подробный текст. cpressey реализовал это во «Времени судьбы» и описал в посте, как работает его построение сюжета. Компилятор истории начинает с простой последовательности:

[ПредставлениеГероев, *, Развязка]

Вместо звездочки компилятор может вставлять любые события со своим началом и концом:

[ПредставлениеГероев, [СокровищаУкрадены, *, СокровищаНайдены, *], Развязка]

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

ПредставлениеГероев = [ПредставлениеДетектива, ПредставлениеГрабителя]
СокровищаУкрадены = [ГрабительБеретСокровища, ГрабительСбегает]
СокровищаНайдены = [ДетективЛовитГрабителя, ДетективЗабираетСокровища]
Развязка = [ДетективИдетДомой, ГрабительСбегает]

После этого остается превратить каждое событие в его итоговое описание в новелле.

Другие форматы

Иногда авторы отходят от формата новеллы. Я уже упоминал несколько подобных, но вот еще:

  • «Пустыни Запада» (PDF) от mewo2 — путеводитель по выдуманному миру, для которого специально генерируются карта и язык. И для карты, и для языка подробно описано, как именно они генерируются.
  • «Великая книга трансмутаций» (PDF) от TobiasWehrum — сборник алхимических рецептов. Чтобы подбирать ингридиенты, используется какой-то корпус связанных понятий.
  • Для «Обложки „И восходит солнце“» adregan взял изображение, а потом написал название цвета для каждого пикселя. Кстати, картинку потом смогли восстановить обратно.
  • В «Отправьте по телефону» от hugovk приведен диалог двух человек, один из которых диктует другому программу. «Эс как доллар», только еще хуже. Немного красивой рекурсии: программа, которую диктуют, и сгенерировала этот диалог.

Графические произведения

Не всегда авторы ограничиваются текстовыми новеллами. doldrumorchids для «Людей нет» берет картинки с гугл-панорам, распознает объекты на них, а потом вставляет описания подобных объектов из произведений с «Проекта Гутенберг».

«Серафимы» от lizadaly — это загадочный манускрипт с картинками, написанный на неизвестном языке (с символами из рукописи Войнича).

«Что-то, благодарение и ничего» от zachwhalen и «Сгенерированный детектив» от atduskgreg — графические новеллы (комиксы). В первой текста нет, во второй он есть. Но оба автора постарались над стилизацией картинок, и получилось атмосферно.

Нейронные сети

Немного о плохом. Нейронные сети за последнее время научились многому: побеждать в го, накладывать фильтры на фотографии и сортировать огурцы. Но с генерацией текстов у них, похоже, как-то не клеится. В 2015 было несколько произведений, написанных нейронками (переосмысление Лавкрафта от R-Gerard, переосмысление Жюля Верна от estayton и что-то графическое от spikelynch). Все они меня не впечатлили. Думаю, это значит, что у нейронных сетей всё впереди, и в будущем мы еще увидим что-то более осмысленное от них.

Что дальше

Новый NaNoGenMo начался несколько дней назад. Вот репозиторий для него. Если вы хотите в нем поучаствовать — создайте в нем issue с заголовком вроде «intent to participate». В самом issue вы сможете обсудить свои идеи с другими участниками, а после завершения работы туда надо будет выложить ссылку на код и сгенерированную новеллу. Желаю успеха всем, кто решится!

Ссылки

  1. Репозитории прошлых лет: 2013, 2014, 2015.
  2. Серия статей, из которой я узнал про NaNoGenMo: 1, 2, 3, 4. В этом посте я использовал некоторые примеры оттуда.
  3. Оригинал этого поста на Хабре
Нет комментариев
← Раньше