eliace
На дворе октябрь, в npm залита новая версия фреймворка Chorda 3.0. Можно, наконец, устроиться поудобнее за чашечкой кофе и подвести некоторые итоги
Про сам фреймворк можно почитать здесь, посмотреть тут и пощупать там
В прошлый раз я рассказывал о дизайн-функции, чертежах и построении API компонентов, а в этот раз попробую заинтересовать вас некоторыми очевидными решениями и не очень очевидными следствиями, которые появились во время работы с Chorda
Очевидные решения
Когда я использую другие библиотеки, есть ряд вещей, которые меня не устраивают. Всегда казалось, что можно сделать лучше.
Расширение библиотечных компонентов
Начну с декларативного подхода и примесей — краеугольного камня Chorda. Для наглядности нам понадобится немного кода.
Создадим простой компонент на JSX (React) с кнопкой и текстом. Задача: при клике по кнопке меняется текст
const MyComponent = () => {
const [data, changeData] = useState('')
const hahdleClick = (e) => {
changeData('Hello')
}
return <div>
<button onClick={handleClick}>Click me</button>
<p>{data}</p>
</div>
}
// вот так выглядит применение компонента
<MyComponent/>Сделаем похожий функционал, используя чертеж Chorda
// вырожденная дизайн-функция
const MyComponent = () => {
return {
templates: {
button: {
tag: 'button',
text: 'Click me',
events: {
// обработка событий VDOM
$dom: {
click: (evt, {data}) => {
data.$value = 'Hello'
}
}
}
},
text: {
tag: 'p',
reactions: {
// реакции компонента на изменение переменной скоупа
data: v => patch({text: v})
}
}
},
initials: {
// инициализация переменной в скоупе
data: () => observable('')
}
}
}
// создаем чертеж
MyComponent()Ну, все. Расходимся, ребята. Очевидно же, что шаблонный синтаксис намного проще и понятнее.
Но
Давайте посмотрим, что происходит с нашим JSX компонентом дальше. Итак, мы выполнили задачу, и теперь передаем наши наработки коллеге, скажем, в составе корпоративной или публичной библиотеки. Через некоторое время от коллеги приходит просьба: хочу, чтобы компонент можно было стилизовать. Не вопрос. Самый простой и быстрый способ это сделать — дать возможность управлять классом корневого компонента через пропсы.
Поехали
// Придется залезть в библиотеку (!) и сделать пару правок
const MyComponent = (props) => {
const {rootClassName} = props
/* Тут ничего не меняется. Пропускаем */
return <div className={rootClassName}>
<button onClick={handleClick}>Click me</button>
<p>{data}</p>
</div>
}
// рендерим
<MyComponent rootClassName="custom" />Отлично!
Тем временем в Chorda
// Менять оригинальный чертеж необходимости нет
// В месте применения создадим примесь
mix(MyComponent(), {
css: 'custom',
})Естественно, стилизацией обычно дело не заканчивается. Чем дальше, тем больше хотелок и тем больше пропсов нам понадобится добавить.
На самом деле подобные извращения следует пресекать в зародыше, и сразу предоставлять возможность потребителю «слотировать» вложенные компоненты. Однако, в нашем примере компоненты оказались жестко связаны state-параметром data. Просто так вытащить их не получится, поэтому посмотрим, во что может превратиться реализация с пропсами
const MyComponent = (props) => {
const {rootProps, buttonProps, text: MyText} = props
/* тут ничего не меняется */
return <div {...rootProps} >
<button onClick={handleClick} {...buttonProps} >Click me</button>
<MyText>{data}</MyText>
</div>
}
<MyComponent
rootProps={{className: 'custom'}}
buttonProps={{className: 'custom-button'}}
text={props => <p className="custom-text">{props.children}</p>}
/>
В ситуации с чертежом без особых именений
// Расширяем примесь
mix(MyComponent(), {
css: 'custom',
templates: {
button: {
css: 'custom-button'
},
text: {
css: 'custom-text'
}
}
})Для React типовое решение проблемы это вынесение состояния из компонента. Получившийся «глупый» компонент уже не будет иметь внутри сильной связи и позволит легко «слотировать» вложения. Но здесь есть подводный камень. Архитектура такая штука, что если где-то убыло, то где-то прибыло. Выбрасывая сложность из наших компонентов мы ее копим в другом месте, а именно там, где компонент будет применяться
Стоит признать, с примесями тоже не все так гладко. Чтобы сделать хорошо расширяемый компонент, его необходимо сильно декомпозировать, а это напрямую влияет на производительность и восприятие кода в целом (по второму пункту полезно почитать о причинах появления setup во Vue 3)
Так к чему все это сравнение? Тот же React может предложить много вариантов и подходов для расширения функционала, один экзотичнее другого. Chorda же предлагает один путь (на самом деле нет), что на мой взгляд экономит на выборе уйму времени
Этот компонент мне не подходит
Идем дальше. Мы рассмотрели как именно выполняются изменения отдельного компонента, но что если вы являетесь не автором библиотеки, а ее потребителем, и столкнулись с проблемой нехватки функционала или дефектом?
Тогда на выбор:
1. Делаем форк, вносим в него правки. Делаем PR в репо библиотеки. Пока ждем влития, пользуемся форком
2. Делаем свой компонент. Используем его вместо библиотечного. Ждем новой версии библиотеки
3. (для обладателей особого дара убеждения) Объясняем автору библиотеки в чем он не прав и почему он должен внести нужные вам правки как можно скорее. Профит!
4. Забиваем
Если вы используете Chorda, то у вас появляется еще один вариант: подмешать свой функционал к чужому компоненту. В этом случае компонент как-бы продолжает оставаться частью оригинальной библиотеки, но в то же время содержит нужные вам изменения
Mount или не Mount?
Наверно, правильнее этот вопрос надо задать так: в какой момент должна начинаться обработка бизнес задач?
Хорошо проиллюстрирует мою мысль пример с загрузкой данных в store приложении при открытии страницы. Как правило, загрузка выполняется по событию монтирования узла виртуального DOM, что есть странно — зачем что-то добавлять в DOM, если данных еще нет? Почему бы нам сначала не загрузить данные, а потом решать — рендерить что-то или нет. Тут ситуацию немного спасает Suspense и понятие асинхронных компонентов, когда у каждого из них есть своя отложенная задача и, соответственно, отложенная отрисовка
Мне же больше нравится вариант, когда загрузка вообще никак не связана с рендерингом. В Chorda бизнес-логика находится на уровне дерева компонентов, а результаты выполнения бизнес-задач влияют только на store/state, не касаясь отрисовки напрямую
Все мы вместе и каждый сам по себе
В Chorda состояние компонента определяется скоупом (что-то вроде локального store). Компонент видит только свой скоуп и работает только с ним, считая, что вокруг никого нет. Это позволяет спокойно выполнять смешивание, не опасаясь сломать жесткие связи между компонентами
По умолчанию, скоуп делит свое содержимое с другими связанными скоупами, таким образом позволяя компонентам иметь доступ, например, к общему роуту. Но в то же время любой компонент может локально изменить состав своего скоупа так, как ему нужно.
Здесь мы подходим к такой штуке, как конвейер обработки (вычисление-патч-отрисовка). Он, как и любое другое значение, попадает к компонентам через скоуп, и его, так же как и любое другое значение, можно настроить локально. К примеру, стратегия базового конвейера дает построение дерева компонентов в ширину с удержанием задач отрисовки до окончания обработки всех патчей. Если для вашего компонента или блока компонентов такое решение не подходит, вы можете подключить к ним свой кастомный конвейер
Неочевидные следствия
А вот некоторые моменты не являлись изначальной целью, но проявились по мере развития фреймворка
Встраивание в существующие проекты
Реализация виртуального DOM не входит в состав Chorda, т.к. разработка еще одного нового отрисовщика не решала моих проблем. Поэтому я собирался использовать какой-нибудь из уже существующих. Для того, чтобы попробовать Chorda в деле, я собрался переписать с нуля пару домашних React-проектов. Но приступив, почти сразу понял, что это совсем не обязательно. Можно постепенно заменять отдельные компоненты, подключив правильный рендерер, и так потихоньку съесть всего слона целиком.
Интересный вопрос: если фреймворк использует React, то можно ли сказать, что приложение, которое использует данный фреймворк, написано на React?
Загружаем и работаем
Сомнительное следствие конечно, но для некоторых может оказаться чрезвычайно важным. Создание компонентов и отрисовка присходят в runtime, без этапа транспиляции. Подключив ядро Chorda и рендерер, можно сразу писать код, который тут же будет исполняться в браузере.
Правда вот, SSR превратился в нетривиальную задачу
Поведенческие компоненты
Тут скорее интересное наблюдение. Раньше я сталкивался только с таким подходом к «глупым» компонентам: есть простой компонент без логики работы, который знает как ему рисоваться, затем поверх него создается «умный» компонент, который включает в себя «глупый», добавляя некоторое поведение.
Так вот в Chorda (из-за того, что можно легко менять порядок смешивания) у меня появился набор компонентов, в которых есть только поведение без правил отрисовки (обычно это набор стандартных реакций). И получилось, что, наоборот, уже к поведению начинает примешиваться способ отображения
Как это может выглядеть:
export default () => {
// поведенческий компонент Text
return Text({
as: Paragraph, // "глупый" компонент Paragraph
text$: $ => $.user.name
})
}
Что в итоге?
Естественно, это не все, о чем хотелось рассказать. Но к этому времени кофе уже закончился, а статья на две чашки это уже лонгрид. Смотрите примеры, читайте доки, оставляйте отзывы.
Если фреймворк вас заинтересовал, или у вас есть предложения по его развитию — всегда пожалуйста.
Текущая страница: 4 (всего у книги 14 страниц) [доступный отрывок для чтения: 5 страниц]
Составляем контент-план
Работа над блогом – это все еще работа. Она требует времени и дисциплины.
Чем чаще и регулярнее вы будете публиковать материалы, тем быстрее будет развиваться ваш канал и тем стабильнее будут показатели публикаций. Каждая новая статья – это возможность зацепить внимание новых читателей и «пища для ума» алгоритма – чем больше у него информации о том, кто читает ваши статьи, тем легче ему подобрать новую аудиторию для канала.
Есть еще интересный психологический аспект – во время долгих перерывов у авторов возникает ощущение потери связи с аудиторией. Начать снова писать после длительной паузы очень сложно.
Как часто надо публиковать материалы?
Идеально, если вы сможете первое время делать публикации каждый день – так вы ускорите развитие канала и научитесь постоянно работать над блогом. Ученикам в своей школе я советую запастись терпением на три месяца, если они твердо нацелены сделать блог популярным.
Но в конечном счете каждый автор определяет регулярность сам. Ведь у каждого человека свои цели и разные приоритеты. Для меня личный блог – один из множества проектов, и сейчас я уделяю ему не более 10 % своего рабочего времени, выпуская всего 1–3 публикации в неделю. А для моего друга Влада Горбачева (канал «Книга животных») блог – основная работа. Он делает 2–3 публикации в день. Результаты его канала гораздо более впечатляющие, чем мои, – и это справедливо.
С блогерством как со спортом – можно заниматься этим профессионально и добиваться больших успехов, а можно время от времени, но смирившись, что и результаты будут не такими значимыми. Но важно все-таки найти и определить время, которое вы сможете регулярно посвящать блогу. Будь то один час в день или один час в неделю – решайте сами, главное – выделите время на блог.
Поддерживать регулярность помогает функция отложенного постинга, когда, написав сегодня статью, вы можете опубликовать ее в любое выставленное время. Поэтому можно выделить в один день несколько часов для Дзена и создать статьи на всю неделю вперед.
План публикаций
Многие авторы составляют план: когда и что они будут публиковать. Это помогает распределить время, которое нужно выделить на написание статей, и держать ведение блога под контролем.
Контент-план особенно необходим, когда вы ведете корпоративный канал: вам нужно придумать и согласовать его с заказчиком прежде, чем что-то публиковать. И зачастую над ним работает целая команда, поэтому нужно делать план таким, чтобы у всех был к нему доступ.
Для личного планирования я использую обычные «Заметки» в телефоне – для записи спонтанных мыслей, а также планировщик задач «Todoist»: там я сделала список задач «Дзен-канал Анна Денисова» и ставлю себе задачи по публикации нужных статей на конкретные даты. Они висят в моем ежедневном списке дел, напоминая, что надо выделить время на блог.
Многие авторы составляют план в самом обычном блокноте. Кто-то работает прямо в редакторе Дзена: можно сделать черновик статьи с идеей, а когда будет время – доработать его до публикации.
Для командной работы удобно использовать сервис Trello, это такая система управления задачами. Наверняка вы встречали людей, которые вешают перед собой доску, разделенную на несколько колонок, например: «идея», «в процессе», «готово». И клеят желтенькую бумажку с задачей то в одну, то в другую колонку.
Trello – виртуальная альтернатива такому типу планирования. Там можно создавать сколько угодно досок и колонок, подходящих под ваши задачи. Например, вот так выглядела доска для работы по одному из проектов нашего агентства:
Каждая публикация – это отдельная карточка, которую мы перемещали из колонки в колонку. В итоге все карточки оказались в колонке «Опубликовано», когда мы закончили работу над проектом
Сервис работает как в приложении на телефоне, так и в браузере на компьютере, базовые функции бесплатны. Можно работать командой и добавлять ответственного к конкретной карточке-задаче: дизайнера, менеджера или заказчика, например.
Trello часто используют в редакциях СМИ, рекламных агентствах, издательствах. Но многие мои ученики любят использовать его и для личных задач.
Как придумать статей на целый план
Придумывать темы для блога проще, если на канале сформированы рубрики – направления, на которые автор пишет с какой-то регулярностью.
Например, если у вас будет канал про путешествия, рубрики могут быть такими:
• отели;
• еда;
• маршруты;
• достопримечательности;
• рассказы путешественников.
Отталкиваясь от этих рубрик, можно быстренько придумать темы для конкретных статей. Например, в рубрике «Отели» можно сделать подборку самых красивых отелей, обзор необычного отеля на райском острове, интервью с владельцем бутик-отеля в Сергиевом Посаде и так далее.
Иногда в блоге нет сформированных рубрик, при планировании автор отталкивается от ситуации. Темы для статей приходят к автору сами по себе, например:
• вопросы от подписчиков и комментаторов;
• прямые просьбы читателей рассказать о конкретной теме;
• опыт, который автор приобрел и которым хочет поделиться;
• интересная вещь, о которой прочитал автор.
В таких случаях очень важно сразу же записывать темы, которые пришли в голову: в телефон, заметки, блокнотик, отправлять смс самому себе. Каждый раз вечером у меня в голове рождается миллиард интересных идей, и я уверена, что их невозможно забыть. Но утром меня ждет жестокое разочарование и пустой лист.
Я не определяла для себя рубрик, всегда пишу ситуативно. Но если посмотреть на все мои статьи, то можно проследить направления: бизнес, дети, отношения, истории из жизни, лайфхаки. Если мне будет не о чем писать, я могу рассмотреть под прицелом каждое из этих направлений, и тема для статьи быстро придумается. «Давненько я не писала про детей! О, а ведь Коля вчера такое устроил, можно рассказать».
Задание
1. Составьте рубрики, которые будут на вашем канале.
2. Скачайте Trello и попробуйте сделать в нем контент-план на ближайшие две недели.
• Создайте колонки: идея, черновик, в работе, готово к публикации, опубликовано.
• Сделайте карточки с названиями статей.
• Добавьте расширение «календарь», чтобы назначать сроки для карточек.
• Создайте метки с рубриками и расставьте их на карточки.
Пишем статью
В Дзене вам придется конкурировать за внимание читателей с популярными блогерами, писателями и даже СМИ. Над статьями там работают целые редакции, а вам надо в одиночку делать контент на столь же высоком уровне.
Когда я писала свою первую статью в СМИ (Тинькофф-журнал), то работала над ней целых три месяца, представляете? Три месяца на одну статью! Получив самые первые правки черновика от редактора, чуть не заплакала – так много там было замечаний, а ведь я считала, что я вообще-то молодец и пишу очень здорово. Но зато тогда я получила такой опыт, какой самостоятельно обретала бы годами. Когда мою статью опубликовали, я даже отправила редактору цветы, а всей редакции журнала – пончики, до такой степени мне хотелось отблагодарить их за все, чему я у них научилась.
Сейчас я просматриваю десятки каналов в день. Общаясь с другими авторами, часто слышу претензии в адрес платформы: почему их статьи непопулярны? Ответ прост: не все, что написано, достойно быть прочитанным. И алгоритм Дзена лишь доказывает это.
Прежде чем мы начнем работать над статьей, поделюсь главными выводами, к которым пришла за время своей «блогерской карьеры».
Умение писать – это навык, который тренируется. Любой может научиться хорошо писать, если будет уделять тренировкам время.
Исходные данные у всех разные – кто-то умеет писать на интуитивном уровне (тогда говорят, что у человека талант), а кто-то нет. Но тренировки нужны всем – просто кому-то больше, а кому-то меньше. Тут опять приходит на ум метафора со спортом: некоторым достаточно делать зарядку, чтобы быть в форме, а другим нужно тренироваться по пять раз в неделю.
Самый простой способ начать тренировки с текстом – завести дневник и ежедневно писать письма самому себе. Можно никому не показывать написанное, ваша задача здесь не впечатлить кого-то своими мыслями, а расшевелить те «мышцы» мозга, которые отвечают за письменные навыки.
Нельзя научиться писать, всего лишь посетив какой-то вебинар, прочитав одну книгу или просто написав текст, как нельзя обрести фигуру мечты, единожды сделав зарядку.
Я до сих пор не считаю себя экспертом в текстах, хотя пишу с того момента, как научилась складывать слова в предложения, – первые дневники и рассказы начала писать во втором классе, в старшей школе уже подрабатывала журналистом в молодежной газете. А последние пять лет я ежедневно читаю новости из мира копирайтинга, журналистики и блогинга, прохожу курсы, веду блоги, пишу статьи для разных СМИ, редактирую тексты учеников и рекламные тексты, которые создает мое агентство.
Тем не менее, мне до сих пор очевидны некоторые мои писательские провалы, которые еще предстоит отработать. Я вижу свои слабые статьи, которые были написаны «левой пяткой» и не стали популярными. До сих пор нахожу для себя что-то новое в рассылках, курсах и вебинарах по редактуре и письму. Мне еще предстоит научиться различным приемам, на отработку которых пока не хватает времени.
И вы тоже приготовьтесь к долгому пути: сейчас мы изучим все, что надо для создания статьи в Дзене, но ваша погоня за своей идеальной формулой текста на этом не прекратится.
Хороший текст – это на 90 % интересная мысль в голове автора. И лишь на 10 % слова, которыми он эти мысли опишет.
Хороший текст начинается с умения замечать то, что происходит вокруг, видеть проблемы, с которыми сталкиваются люди, запоминать и анализировать факты, обдумывать все события, делать интересные выводы и фиксировать их у себя в голове (или сразу в контент-плане).
Представьте, что вам надо сделать глиняный горшок для цветов. Глина – материал, без которого нельзя слепить горшок, даже если вы прекрасно умеете это делать. Вы можете заменить глину песком, который находится под рукой, но лепить из него будет очень сложно и горшок выйдет плохим. И наоборот, если у вас есть глина, но нет навыков лепки, ваш первый горшок получится неказистым и, может, не самым красивым в мире. Но в него все равно можно будет поставить цветы – свою функцию он выполнит.
Также со статьей – если в голове нет интересных мыслей, то не получится написать хороший текст. Поэтому работа над расширением своего кругозора, общение с разными людьми, развитие навыков мышления, чтение книг, причем не только профессиональных, но и художественных – все это важная часть работы блогера.
Писательский талант заключается не столько в умении писать, сколько в умении подмечать в жизни интересные моменты и вопросы, ловить впечатления и перерабатывать их.
Теперь давайте разберем по шагам все, что нужно для написания хорошей статьи в Дзене: сначала прочитайте эту главу, а в конце я все обобщу в чек-листе и дам вам задание.
Тема: польза + интерес
Первое правило написания любого текста: прежде чем что-то писать, поймите, зачем кому-то это читать.
Мы уже не в школе – нет ни одного человека, который обязан был бы изучать наши тексты. Чтобы люди захотели читать – мы должны дать им полезный материал, вызвать интерес.
На протяжении всей работы над текстом задавайтесь вопросами. Кому это может быть интересно? Какой он, ваш читатель? Какие вопросы есть у этого человека, которые вы можете осветить с высоты своего личного опыта? Что должен понять и почувствовать человек, прочитав ваш текст?
Пишите не для себя, а для людей. Польза может быть разной. Иногда в блоге я пишу конкретные прикладные инструкции, помогая читателю, делая что-то за него. Например, создаю обзоры, сравнения, полезные списки. С такими статьями все ясно. Но часто я делюсь и банальными ситуациями: разговор с незнакомцем, ссора с мужем, встреча с кем-то… И вот тут возникает вопрос: «А какая людям польза от таких рассказов?»
Даже когда я пишу истории из жизни, все равно задумываюсь о пользе: люди могут читать мои истории для развлечения, как художественные романы. Но чтобы их хотелось читать, в них должно быть что-то цепляющее: сюжет, эмоция, стиль повествования.
Еще, рассказывая читателям, как веду себя в конкретной ситуации, я показываю альтернативный взгляд на произошедшее.
Вы спросите: «А как же все бесполезные блоги, в которых авторы просто выкладывают свои фотографии и рассказывают, что сегодня покушали? Почему такие блоги тоже бывают популярными?»
Все люди разные – и нормально, что кто-то из читателей находит для себя пользу и вдохновляется контентом блогера, который не создает ничего полезного (на ваш субъективный взгляд). Читателей может привлекать яркая личность автора, его стиль повествования, фотографии, образ жизни. Возможно, вы не видите в этом контенте ничего интересного лишь потому, что вы не целевая аудитория.
Например, всегда найдется мужчина, готовый облить презрением маму-блогера, потому что ему кажется, что та не создает ничего полезного: показывает свое тело, печет сырники и снимает видео с детьми. Подумаешь, ерунда какая!
Нет, не ерунда – просто этот мужчина – не целевая аудитория такого блогера, в отличие от девушки, которая сидит с ребенком в декрете, с удовольствием готовит сырники по рецепту любимого блогера, качает пресс в свободные минутки, вдохновляясь ее фигурой, и хохочет над забавными выходками детишек блогера.
Придумывая тему для статьи, оценивайте, что изменится в жизни вашего читателя после ее прочтения? Тема должна быть интересна не всем, а вашей целевой аудитории.
Небанальность
Тема статьи не должна быть избитой, нужна «изюминка». Например, каждый год в феврале вся лента буквально завалена статьями: «Что подарить мужчине на 23 февраля?» Это и правда актуальная тема, которая волнует многих, но об этом написаны уже сотни текстов, поэтому, если вы берете тему подарков, надо копать глубже.
Напомню: ориентируйтесь на то, каким вы видите своего читателя, подумайте, какая у него есть проблема, которую вы можете решить своей статьей? Например, можно сделать такую подборку: «Список самых глупых подарков по мнению мужчин», если вы хотите развлечь аудиторию. А может, вашим читателям будет полезнее статья: «10 подарков, которые понравятся рыбаку».
Однажды под Новый год мне надо было сделать нативную рекламу с подборкой подарков для детей. Боже, как это банально! Но у меня самой есть боль: выбрать подарок моему сыну очень сложно, потому что у него и так все есть. Тогда я решила работать на такую же аудиторию мам, как я, и назвала статью: «5 идей подарка ребенку, которого сложно удивить». А в подписи добавила: «Дорогие подарки для избалованных детей». Такая тема отлично сработала на нужную целевую аудиторию, статья выполнила гарантию по дочитываниям, а рекламодатель получил с нее заказы.
Чтобы проверить, сколько уже написано на вашу тему, просто поищите по статьям в Дзене, обратите внимание, сколько дочитываний собирают такие статьи, какую «изюминку» добавляют другие авторы. Возможно, это натолкнет вас на идею о том, как иначе сформулировать тему.
Бесчисленное количество статей про способы изучения английского
И всего три статьи про жизнь в доме бизнес-класса, из которых две написаны мной и одна – автором, который нагло своровал мою тему и структуру:)
Структура
Прежде чем чего-то добиться, мы составляем план. Для меня структура текста – это тоже план по достижению какой-то цели с помощью статьи. А мой любимый редактор Максим Ильяхов сравнивает структуру текста со скелетом, на котором все держится.
Если текст не структурирован, статья превращается в набор бессвязных мыслей и оставляет читателя в замешательстве и недоумении.
Чтобы понять, как делать хорошую структуру, вспомним метафору с целью. Когда у нас есть цель – мы разбиваем ее на несколько отдельных задач, решаем их и достигаем поставленной цели. С текстом то же самое: сформулировали его цель, разделили на задачи – получили структуру.
Допустим, я хочу написать статью про то, как автору опубликовать свои тексты в СМИ. Она будет рассчитана на начинающих авторов и блогеров, которые еще никогда не публиковались в журналах. Структурой этой статьи должен стать план, который доведет читателя до цели – он сможет отправить заявку на публикацию в СМИ. Я разбиваю свою цель на задачи, мне надо пошагово объяснить:
• проблему, которую решит моя статья;
• кого опубликуют с большей вероятностью, чтобы читатель оценил, готов ли он стать автором;
• как выбрать издание;
• как оценить выбранное издание;
• кому и как написать с просьбой о статье;
• что делать, если редакция не ответила или сказала: «Нет».
В конце статьи я могу сделать краткий чек-лист, в котором обобщу все написанное выше. У меня уже почти готова структура, я могу дополнить каждый пункт и получить расширенный «план» статьи:
1. Введение. Обозначаю проблему, которую решит моя статья.
2. Кого публикуют в первую очередь:
• наличие портфолио;
• наличие читателей;
• если ничего нет.
3. Выбор издания:
• как выбирать;
• где искать.
4. Анализ СМИ:
• требования к авторам;
• кто принимает решение о публикации статьи;
• есть ли уже статьи на определенную тему?
5. Заявка на статью:
• кому написать;
• что написать в заявке.
6. Ответ редакции:
• что делать, если «Да»;
• что делать, если «Нет»;
• почему ответ мог не прийти?
7. Заключение: чек-лист и призыв к действию.
Мне кажется интересным, что у каждого человека – своя логика. И поэтому одну и ту же цель с помощью текста авторы решают по-разному. Это и делает статьи на одну тему совершенно разными. Как с музыкой – всего семь нот, но сколько мелодий!
Когда мы пишем художественный рассказ, тоже важно придерживаться структуры. Наверняка вы встречали истории, в которых автор хотел рассказать про что-то одно, но потом мысли увели его в другую сторону, и основная идея была потеряна.
Приведу пример. Допустим, я хочу рассказать историю своего знакомства с мужем. Изначально, в моей голове формируется такой план статьи:
• какое было тогда время, где была я (например, в 2008 году я училась на третьем курсе университета);
• какое-то событие, вытекающее из того, что я рассказала выше (однажды мне позвонил знакомый и предложил такую-то работу, я поехала к нему в офис);
• момент встречи с будущим мужем (в офисе был парень. Он выглядел так-то, и я подумала про него то-то, а он сказал то-то);
• почему мы тогда не могли быть вместе (у меня был парень, у него девушка, никаких мыслей не возникало, и мы стали дружить);
• как складывались потом наши отношения (много лет мы работали бок о бок и вместе пережили такие-то события, а спустя __ лет оказались свободны и стали встречаться);
• заключение (мысль о том, что наша семья – классический пример того, как дружба иногда перерастает в любовь).
Когда я начну писать статью по этому плану, очень важно дополнять ее лишь теми деталями, которые имеют прямое отношение к нашему знакомству и не добавлять больших кусков, которые могут выделиться в отдельный пункт и нарушить общую структуру.
Например, можно рассказать о том, что в 2008 году мне приходилось совмещать учебу с работой, чтобы оплачивать съемную квартиру и жизнь, я бралась за любые подработки и поэтому быстро отозвалась на предложение. Но не стоит писать три абзаца о том, как сложно мне тогда жилось или откуда я знала того знакомого, где находился офис и какие цветы там стояли.
Понять, что вас занесло в сторону, можно, спросив себя: «Эта информация влияет на общий ход событий? Нужна ли она читателю в контексте данной истории, зачем?» Если ответ – нет, смело переносите эту часть в новый черновик, скорее всего, вы позже сможете сделать из нее другую статью.
Меня часто заносит: начав писать по плану, я вспоминаю кучу деталей, и о них тоже хочется рассказать. Если у меня есть время, я не останавливаю себя и тут же накидываю план для отдельной статьи на эту тему, а потом возвращаюсь к текущему рассказу и дописываю его.
Дзен – очень хороший тренажер для отработки структурности текста, в статистике редактора вы будете видеть карту дочитываний ваших статей и понимать, на каком моменте люди уходили, сколько процентов текста они осилили.
Если люди читают текст до конца – это один из сигналов для алгоритма, что статья интересная, нужно показывать ее больше.
Люди уходят из статьи, когда потеряли нить повествования, перегрузились ненужными деталями – и это лечится правильной структурой.