Мини-экскурс по основным ошибкам копирайтеров от Ярослава Старченко, Senior Full-Stack девелопера в SAAS проектах, главного IT-эксперта редакции Контентим.
Привет, Яр! Расскажи, какую основную проблему ты замечаешь в текстах от авторов по IT?
Главная проблема новых IT авторов – отсутствие контекста, разумеется. Она прослеживается через множество аспектов – непонятные объяснения, плохие примеры, неверно использованные термины, неполные определения и откровенные фактические ошибки. Читательские оценки на такой текст будут от “Они вообще ничего не понимают в теме” до “Ну так себе, слабовато” в лучшем случае.
IT копирайтинг отличает прежде всего сложная терминология. Где в ней авторы могут ошибаться чаще всего?
Даже в относительно поверхностных IT темах есть очень много ловушек для начинающего. Похожие по использованию, но разные по смыслу термины — authentication, authorization, verification, identification. Легко заблудиться в семействах программных продуктов от больших компаний – Amazon Web Services и их тысячи сокращений, продукты Microsoft и Oracle. Какой сервис для чего и для кого, какой платный и по какой подписке, какой облачный и какой можно развернуть на своих серверах…и десятки подобных вопросов. Сокращения, сокращения, сокращения! CMS, ERP, VM, AWS, MS, SaaS, IaaS, PaaS!
Есть какой-нибудь занятный пример ошибки автора, который тебя удивил?
На той неделе читал текст, в котором автор заявлял, что разблокировка смартфона с отпечатка пальца это, мол, очень дорого по железу и софту, а вот распознавание лица — это легко и просто, достаточно только фронтальную камеру иметь. Хотя в реальности бюджетные телефоны ещё пятилетней давности могут предложить быстрый сканер отпечатков пальца, в то время когда быстрое и надежное распознавание лица до сих пор не найти в Сяоми за 300 баксов.
А как тогда можно быстро отличить начинающего IT писателя от классного и опытного?
Редко начинающий IT автор интересуется новостями индустрии на постоянной основе. Из этого рождаются слабые тестовые примеры: в статье по кибербезопасности автор пишет про какой-то безобидный вирус столетней давности про который едва кто-то слышал (и подает это как свежайшую сенсацию). И в то же время в последних новостях рассказывают о том, как в десятый раз за год хакеры сломали отлично известный фейсбук и нашли там очередные миллионы пользовательских данных в незашифрованном виде в текстовом файле.
А как ты дорабатываешь тексты по IT? В чем основная задача эксперта?
Конечно встречаются случаи, когда нужно просто брать и делать часть работы самому. Наделать скриншотов какой-то программы под особую ОС, сделать вставки кода, написать сложный абзац. С течением времени, мы приходим к тому, что хороший автор не мнит, что знает топик на уровне эксперта, а чувствует свои слабые места и начинает вовремя задать вопросы.
Я подбираю сильные источники, объясняю тему, составляю план статьи, дописываю некоторые абзацы, если это выходит быстрее редактуры, выделяю повторяющиеся ошибки и говорю про них всем авторам. Если автор грамотный – он всегда сможет воспользоваться моей помощью так, чтобы потом за ним не нужно было переписывать.
Подводя итоги, выделим четыре основных шага, как можно быстро проверить IT текст на качество и адекватность:
- Проверяем терминологию, употребленную в тексте. Ищем грубые ошибки в расшифровке сокращений. Например, HTML — это не код, это язык разметки и CSS — тоже не код.
- Проводим фактчек. Ссылки не должны вести на новости годичной давности. IT материалы супер-быстро теряют актуальность, автор должен об этом помнить.
- Не забываем проверить актуальность приведенной информации по пользовательским сервисам: платная/бесплатная подписка, срок пробного периода, список опций в тарифных планах, на каких языках доступен интерфейс, и так далее.
- Качественный текст должен быть легким для восприятия, в нем нельзя допускать резких логических скачков и непонятных выводов. Чем уже тематика статьи, тем сложнее её сделать приятной глазу и слуху. Сложный IT материал — это всегда большая нагрузка для неподготовленного автора, нужно всегда помнить, что результат может получиться хуже работ того же автора по более простым темам и потребовать дополнительной редактуры.