Открою вам один секрет: все лучшие авторы, будь то ваш любимый писатель или журналисты Smashing Magazine, не работают в одиночку. Зачастую над их текстами корпят один или два редактора, которые помогают им переводить слова в более интересную или понятную читателям форму.
Поработав с несколькими редакторами — и будучи сам техническим редактором — я высоко ценю эту сторону писательского дела. Доводка — необходимый этап любого творческого процесса. Подобно тому, как рефакторинг кода делает программу более логичной и улучшает её работу, редактирование помогает подчеркнуть основную мысль текста или сделать чтение более занимательным.
Я стараюсь быть в курсе всех новинок, которые могли бы сделать мою работу лучше. Узнав об Editorially — инструменте для коллективного написания текстов, созданном специально для веб-авторов, я поспешил зарегистрироваться в сервисе, и скоро без него я стал как без рук. Каждый раз, когда я писал пост для блога или план выступления, я просил друзей прочитать написанное и выразить своё мнение — надо сказать, что в Editorially это делается элементарно.
Разумеется, у сервиса были свои недостатки: например, двое людей не могли редактировать один документ одновременно, хотя приложение разрабатывалось исключительно для веб-среды; «естественный» функционал сервиса не предусматривал технического редактирования книги из нескольких глав. Объявление о том, что в конце мая сервис закроется, заставило меня искать альтернативы. Сможет ли другое приложение заполнить пустоту, образовавшуюся в результате безвременной кончины Editorially?
Перед тем, как перейти к обсуждению альтернатив, давайте посмотрим, из чего складывается хорошее веб-приложение для коллективной работы с текстом.
Ничего, что может отвлечь от работы
Работа с текстом — дело непростое, к тому же, писатели склонны к долгой прокрастинации. Пока писалась эта статья, я убрал квартиру, помыл посуду и погладил одежду, которую даже не ношу! Короче говоря — чем меньше в приложении того, что может отвлечь внимание от работы, тем лучше.
Поддержка языка Markdown
Markdown очень популярен в писательской среде: он позволяет свести к минимуму взаимодействие с интерфейсом и сосредоточиться на словах. Поэтому любая программа-редактор, использующая Markdown, должна содержать горячие клавиши для жирного и курсивного текста, заголовков и прочие элементы и соответствующим образом отображать выделенный текст. Если автор заключил текст в звёздочки, он должен выделиться курсивом. Кроме того, текст должен быть удобочитаем. Гарнитура и размер шрифта, интерлиньяж, ширина колонки — всё это надо тщательно продумать.
Функции комментирования и рецензирования
Написать текст — только полдела. Инструмент для командной работы с текстом должен поддерживать такие действия, как размещение документа в публичный доступ, редактирование, обсуждение, рецензирование. Нужно, чтобы редакторы, соавторы и другие члены команды могли выделить или удалить часть текста, а при необходимости прокомментировать свои действия. При этом примечания одного участника должны отличаться от остальных. Иногда может возникнуть необходимость обсудить весь текст целиком.
Управление различными версиями документа
За время работы документ претерпевает множество изменений, поэтому так важна возможность сохранения нескольких версий. Эта функция позволяет вернуться к прежним записям и при необходимости восстановить их. Как правило, авторы и редакторы работают над несколькими проектами одновременно, поэтому инструмент должен допускать организацию файлов и отображать их статус (набросок, исправленная или финальная версия и т.д.)
Импорт и экспорт
Наконец, инструмент должен уметь настраиваться под разный порядок работы. Это значит, что в нём должны присутствовать различные функции, связанные с импортом файлов.(через email,, загрузку, копирование из Word) и массу возможностей для экспорта (обычный текст, PDF, HTML и т.д.)
С учётом перечисленных требований сравним доступные на рынке инструменты. Услышав о том, что Editorially закрывают, я написал в Twitter — попросил порекомендовать мне альтернативные инструменты. Вот что мне посоветовали.
Одним из первых мне предложили попробовать GitHub. Бесспорно, он предназначен для написания текстов, однако большинство авторов не сможет использовать созданные здесь документы где-либо ещё. Сайт GitHub позволяет редактировать любой текстовый файл, хотя интерфейс в большей степени ориентирован на программистов, чем на писателей. Работать с разными версиями документа здесь удобно, но управление ветками и запросами на внесение изменений (pull requests) несколько затруднено.
Если вам нравится работать с файлами в репозитории GitHub, то все неудобства, касающиеся самого текста, можно компенсировать при помощи приложения Prose — прекрасного с точки зрения дизайна opensource-редактора, разработанного Development Seed. После подключения к GitHub его интерфейс располагается поверх репозитория, и у вас появляется возможность работать с текстами в более удобной среде. Её можно настроить в соответсвтии с любыми параметрами, установленными вами в Jekyll или GitHub. Да, возможности для коллективной работы здесь ограничены тем, что предлагает GitHub, но небольшим командам, привыкшим к такому порядку работы, Prose может подойти как нельзя лучше.
Развив модель GitHub, Лорен Бёртон (Loren Burton) создал Penflip, который он сам назвал «GitHub для писателей». Если вам случалось пользоваться последним, разобраться с этим инструментом не составит труда. Подобно гитхабовскому репозиторию, документы, или как их здесь называют — проекты, по умолчанию открыты. Чтобы скрыть их от посторонних глаз, необходимо заплатить (стартовый тариф — 8$ в месяц). Интерфейс для обработки текста использует тот же opensource-редактор, что и Prose. Это оличное решение: Development Seed удалось разработать великолепный редактор с полным набором горячих клавиш и стилей для Markdown , который необходим в инструментах такого рода.
Редактировать текст в Penflip несколько сложнее. Как только документ становится доступен другим пользователям сервиса, они получают свои копии, в которые могут вносить изменения. Затем их поправки направляются в оригинальную версию, автор которой может их принять, прокомментировать или отклонить. Как бы то ни было, подобное навязывание гитхабовского порядка работы не даёт разбить взаимодействие на части — напротив, выстраивается очень чёткая система.
Что ж, на этом мы закончим изучение сервисов с гитхабовским подходом к организации рабочего процесса и попробуем нечно совершенно иное. Сейчас на стадии бета-тестирования избранными участниками находится Poetica — сервис с поистине инновационным (и, не побоюсь этого слва, скеоморфичным) интерфейсом, в котором используются знакомые всем редакторам корректурные знаки.
С технической точки зрения, это пир для глаз, однако практической работе в приложении мешает перегруженность деталями. Что касается изложенных в начале статьи требований, то Poetica нарушает многие из них. Сервис не поддерживает Markdown, не позволяет обсуждать вносимые изменения, а множество правок способно сделать текст нечитаемым (иногда они накладываются друг на друга).
Бесспорно, Poetica сделана с умом, но, как мне кажется, область её применения намного уже, чем у других описанных инструментов. Сервис может быть очень полезен для корректоров, но при работе с более комплексными проектами и длинными текстами сразу же обнаруживаются его рамки.
Очень многие посоветовали мне попробовать Draft Натана Контни (Nathan Kontny). И это неудивительно: у него просторный интерфейс согромным количеством функций, включая «режим Хемингуэя» (Hemingway mode), возможность отсылать текст в сервис для его упрощения или на редактуру «профессионалам с высшим образованием» ( эта услуга стоит 8$ за 15 минут).
Как бы то ни было, хорошим писательский сервис делают детали, и здесь я не могу похвалить Draft. Чтобы избавиться от всего, что может отвлечь автора от работы, им пришлось сделать длинные меню и модальные окна, и в этом разработчикам не хватило последовательности. В Draft можно изменять гарнитуру и размер шрифта во всем редакторе, и хотя раньше я никогда не испытывал потребности в этой функции, здесь я её использовал.
Что касается редактирования, то изменения отображаются в режиме сравнения, и мне он показался неудобным. Здесь мы вновь сталкиваемся с паттернами из мира программирования, которые совершенно не подходят для взаимодействия между писателем и редактором.
Typewrite заявлен как «один из лучших инструментов для работы с текстом, который вы когда-либо использовали». Это действительно один из красивейших сервисов с чистым интерфейсом, который мог бы многому научить своих конкурентов. Его Markdown-редактор не уступает редакторам Prose и Penflip, хотя я наблюдал множество ошибок в его работе ( текст выделялся неверно, были проблемы с отменой действий), но на это можно спокойно закрыть глаза. Кроме того, мне показалось странным, что в интерфейсе отсутствует название документа, оно оказалось спрятанным за меню. Но это мелочи.
Вероятно, самая интересная функция Typewrite — это возможность одновременного редактирования текста несколькими людьми, знакомая всем пользователям Google Docs (последний не попал в наш обзор, так как не поддерживает Markdown). Но, в отличие от него, в Typewrite нельзя определить, кому принадлежат те или иные правки. Более того, ради этого преимущества пользователям сервиса приходится мириться с отсутствием стандартного редакторского функционала, например, возможности выделить отрывок текста или оставить примечание.
На данный момент этот инструмент больше подходит для работы коллектива авторов, чем для сотрудничества автора с редактором или рецензентом.
Ещё один инструмент, который стоит упомянуть — Onword — стройный лаконичный редактор, разработанный Дэном Иденом (Dan Eden). Он не позволяет работать над текстом вместе с коллегами и не содержит функций редактирования, а его Markdown-редактор довольно примитивен. Тем не менее, мне импонирует его простота.
Если бы Дэн решил расширить функционал сервиса и подключить возможности для коллективной работы с документами, я был бы счастлив!
Перед тем, как сесть за эту статью, я лишь мельком глянул на то, как выглядят главные страницы сервисов, которые мне посоветовали. На первый взгляд все они были прекрасны и сулили массу интересных возможностей — но не стоит судить о книге по её обложке.
Только изучив все детали, понимаешь, каких титанических усилий требует разработка подобного приложения и как трудно угодить аудитории с устоявшимися привычками. Протестировав все альтернативы, я понял, что многое в Editorially я принимал как должное, в то время как надо было признать: этот сервис был особенным.
С Editorially у нас был продукт, созданный редакторами для редакторов. На рынке существует немало предложений с прекрасными, простыми в использовании и лаконичными интерфейсами, но ни в одном из них не реализован удобный для редакторов процесс работы. Использование метафор из мира программирования, таких как ветки или режим сравнения, только поначалу кажется отличной идеей — процесс взаимодействия автора и редактора менее стандартизирован, чем работа команды программистов, и эти метафоры здесь только мешают.
Нельзя забывать, что многие из описанных инструментов начинались как «побочные» проекты, в то время как за Editorially был закреплён постоянный штат, который занимался проектом в течение года. Все приложения подают большие надежды, и, возможно, со временем мы сможем увидеть заслуженного победителя. А пока, думаю, нам предстоит вернуться к старым добрым настольным программам, почтовикам, распечаткам и маркерам.
Проведите конкурс среди участников CMS Magazine
Узнайте цены и сроки уже завтра. Это бесплатно и займет ≈5 минут.