План статті
- Мотивації
- Вибір теми
- План
- Що таке Markdown
- Написання
- Перевірка
- Чого варто уникати
- Корисні посилання
Мотивації
Чи варто технічному спеціалісту писати статті?
Відповідь однозначна - варто, адже це дозволяє написати експертний матеріал з глибоким сенсом та дійсно корисний для інших користувачів
Для самих авторів є також чимало мотивацій
Розповсюдження знань, допомога іншим швидше оволодіти певними знаннями у масштабі пришвидшує усю галузь. Тобто, описавши якийсь процес, не доведеться повторювати цей матеріал знову, коли инший користувач стикнеться з такою ж проблемою
Можливість передати своє бачення роботи з продуктом та отримати відгуки від інших користувачів, таким чином буде відбуватися процес самовдосконалення спеціаліста
Швидше згадувати пройдений матеріал, ця навичка особливо корисна авторам які стикаються зі складними задачами, а потім тривалий час не повторюють ці навички в повсякденних задачах.
Стимул вивчити щось нове. Можна обирати для статті певну тему, яку ще не досліджена автором.
Тема
Обрати тему для статті досить просто — подумайте, які знання ви можете передати іншим. Це може бути щось, що ви вивчили нещодавно, або ж навпаки, щось, що є базою для вашої професії.
На цьому етапі мусите чітко сформувати портрет читача, тобто людину, для якої пишете матеріал. Якщо це початківець, то не варто використовувати складну термінологію у тексті. Якщо ж це людина приблизно вашого рівня експертності, тут можна інкорпорувати складніші поняття.
План статті
План — це один з найважливіших етапів створення великого текстового контенту. Він допомагає зробити статтю цілісною, не загубити важливі деталі, не відхилитись від основного топіку та чітко бачити обсяг роботи.
Раджу усе записувати. До записів ви відразу можете додавати свої ідеї щодо прикладів коду, ілюстрацій або відео, якщо таке планується.
Що таке Markdown
Всі, мабуть, чули про Mаrkdown, можливо навіть бачили його на власні очі. Вам не обов’язково бути гуру Markdown, щоб розпочати творити якісний контент!
Ви можете ознайомитися з базовим синтаксисом у ціих статтях.
Для початку: https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet
Детальніше: https://daringfireball.net/projects/markdown
Ви можете використовувати IDE, наприклад VScode, тому що він має функцію запису/попереднього перегляду, і ви можете бачити результат статті під час її написання! Або зберігши статтю без публікації ви зможете переглянути як вона виглядатиме також
Текст статті
Сприймайте ваш план як дорожню карту та почніть писати текст. Якщо не знаєте, з чого саме почати, уявіть, що розмовляєте з другом, який цікавиться темою але не надто занурений в контекст.
Коли працюєте, не перечитуйте та не виправляйте кожне речення після його написання. Відкладіть редагування на потім. Зараз просто записуйте власні думки потоком
- Додавайте приклади з власного життя. Саме персональний досвід робить вашу статтю унікальною
- Ілюструйте важку для сприйняття інформацію, якщо це можливо. Будь-яку діаграму або схему легше зрозуміти у вигляді картинки, ніж текстового опису.
- Додавайте ілюстрації, схеми, відео, анімацію, аудіо до вашого тексту.
- Використовуйте онлайн-інструменти для перевірки тексту на унікальність та помилки.
Перевірка тексту
Після написання, перечитайте текст та подивіться на нього в цілому. Чого не вистачає? Може, забули додати якийсь приклад чи пояснити новий термін? Допишіть текст, що заповнити пробіли у розумінні матеріалу.
Настав час позбутися зайвого. Можливо, якісь абзаци насправді недотичні до теми і лише роздувають об’єм матеріалу? Видаляємо.
Перечитайте кожен абзац окремо та подивіться, які речення не несуть нової інформації. Можете залити це речення червоним кольором та прочитайте абзац без нього. Якщо ідея все ще зрозуміла, сміливо видаляйте зайве.
Коли зупинитися? На це питання відповісти можете лише ви. Напевно тоді, коли вам сподобається результат.
Порада - не перечитувати 200 разів одне і те саме. Так ви лише заплутаєтесь ще більше.
Поверніться до візуальної складової вашої статті. Перед публікацією перевірте, щоб у вас усе було готово.
Чого варто уникати
- Не намагайтесь відповісти на всі питання в одній статті
- Не починайте писати пост, не підготувавши план
- Не пояснюйте усе кодом та не робіть приклади великими. Не описуйте того, що не стосується вашої теми
- Не робіть приклади коду у вигляді ілюстрацій. Ваші читачі скоріше за все захочуть скопіювати код
Корисні посилання
Дізнатися більше про написанням технічних статей ви можете з наведених нижче матеріалів:
Як створювати та оформлювати технічну документацію в IT
An article ... to help your first dev.to article
Technical Blogging Basics – How to Write Articles as a Developer
Technical Writing дайджест
Discussion (0)