По непонятной причине Гугл.Фонтс плохо обновляет шрифты и раздает какие-то устаревшие версии. Шрифты, у которых давно есть кириллица, в Гугле без кириллицы. Например, вот:

Лато

Лато использует в своем интерфейсе Слак. Версия Гугла — без кириллицы:

На самом деле кириллица вышла в 2015 году:

Даже авторы Лато не знают, почему Гугл так себя ведет:

The older version (1.0) of the Lato font family is available on Google Fonts. We have no information when Lato 2.0 will be available on Google Fonts.

Эдоби Сериф Про

Версия Гугла — без кириллицы:

На самом деле кириллица есть (с начала 2017):

Эдоби Сорс Код

Версия Гугла (ну вы поняли):

Версия Эдоби:

Это я уже писал в фейсбуке, переношу сюда, чтобы не потерялось.

Придумал закон и коэффициент, которым надо мерить коммуникации. Встречайте:

Закон и коэффициент СУД (Скорости упоминания договора)

Закон Годвина гласит, что любая достаточно продолжительная дискуссия в интернете приведет к упоминанию Гитлера.

Закон СУД гласит, что любая достаточно продолжительная дискуссия внутри компании приведет к упоминанию трудового договора. Коэффициент СУД — число переговорных итераций, за которое договор вспоминается. Чем он выше — тем лучше и дружелюбней коммуникации.

— Можно отгул взять?
— Нет, трудовой договор не позволяет

Этот диалог — СУД = 2, на второй реплике — договор.

А вот так выглядит, например СУД = 1:

— Мой трудовой договор позволяет брать мне отгулы?

Хорошо, когда СУД в компании не удаётся посчитать.

Я делал коллеге подборку ссылок как по-человески писать то, что по-человечески быть ну никак не может. Решил дооформить в пост, пусть для всех будет.

Юридические документы: переписать и сократить

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

Попытайте вспомнить на скольких страницах ваш трудовой договор? Вот весь трудовой договор Вилли:

Трудовой договор Вилли

Юрист Владимир Беляев рассказывает, как добиться таких договоров:

• Часть первая
• Часть вторая
• Часть третья
• Часть четвертая
• Часть пятая
• Часть шестая

Вот ещё пример Ильяхова: instagram.com/p/BZQslBsA1ej/

Юридические документы: написать рядом по-человечески

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

Бюрошный договор

Соглашение 500 пикселей

Объявления: для учреждений культуры Москвы

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

Московский институт социально-культурных программ подготовил рекомендации по написанию текстов для учреждений культуры Москвы. Вот несколько разворотов:

Скачать:

Объявления: для госуслуг

Максим Ильяхов с командой готовил правила написания текстов для госуслуг. Например:

Руководство общедоступно:

• 0. Платформа бренда
• 2. Электронные письма
• 4. Объясняющие (учебные) статьи
• 6. Руководство по использованию формата и структуры новостных блоков

Все материалы перенесли в сайт рассказа о проекте: https://rocketmind.ru/cases/gosuslugi-promotion

Лекарства

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

Смотрите, так тоже можно: аккуратно, просто и понятно.

Картинка промелькивала в канале Ильи Бирмана

Объявления: для всех

Вот подборка бюрошных советов про объявления. Они универсальны, подойдут и для соседа и для коллеги.

• Как убеждать людей, что что-то делать нельзя?
• Как сделать более клиентоориентированное объявление вместо «Посторонним вход воспрещён!»?
• Как составить объявление для неплательщиков за ЖКХ?
• Насколько корректный текст? Как можно делать лучше?

Максим Ильяхов даже как-то делал сайт с шаблонами объявлений, но кажется временно его подзабросил, там тоже можно что-то подглядеть.

Если будете извиняться в объявлениях: Искренность в извинениях.

Напишите что-нибудь крутое, что я пропустил? В телеграм @mikeozornin или на почту mike.ozornin@gmail.com

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

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

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

Общие правила

Про оформление подписей есть бюрошный совет: bureau.ru/bb/soviet/20140728. В нем Артём рассказывает о роли подписей, о том, как их ставить и как рисовать выноски. Подписчики учебника «Типографика и верстка» могут дополнительно посмотреть разворот 71.

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

Прием 1: УВЛ (убрать все лишнее)

Самое простое, с чего можно начать улучшение этой картинки — убрать очевидные сущности. Текста станет меньше, свободного места — больше, подписи станут компактней и аккуратней.

Слово button встречается 12 раз и все они используются, чтобы сказать «это — кнопка». Вообщем почти все элементы на этом скриншоте — кнопки, поэтому button безболезненно убирается:

Прием 2: вынести общее за скобки

Иногда от повторений нельзя избавиться совсем. В примере ниже повторяется не просто button, а filter button.

Убрать button можно, а вот от filter избавиться нельзя. Если убрать слово filter, то потеряется важный смысл. При этом filter button относится ко всем четырем действиям, все они — действия над сохраненными фильтрами. Нет необходимости писать про сохраненные фильтры 4 раза, можно написать один раз и больше не повторяться.

Например, так:

Фактически мы вынесли filter button за скобки, как в математическом выражении.

Прием 3: соблюдать теории близости

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

Прием 4: использовать естественное соответствие

Известный инженерный психолог Дональд Норман в своей книге «Дизайн привычных вещей» сформулировал принцип «естественного соответствия». Проще всего объяснить картинкой. Слева просто так, справа — естественное соответствие:

На этом куске скриншота все 4 иконки стоят ровно в ряд с одинаковыми отступами:

По возможности лучше не подписывать что-то сбоку, что-то снизу, а расположить подписи в ряд, с одинаковыми интервалами, — это усилит взаимосвязь:

Прием 5: выравнивать текст осмысленно

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

Подпись периода расположение по центру и похожа на форме на отображаемый период: невысокая и широкая. Иконка Expand timeline расположена в правой части поля, поэтому выноску располагается с правой стороны текста. Дополнительно можно было бы использовать выравнивание текста Expand timeline по правому краю, а Apply filter по центру, но это не обязательно в данном случае.

За выравниваем всегда следят на транспортных схемах: правильное расположение названия станции помогает понять, где какая станция. Посмотрите, например, линейные схемы Московского метро: artlebedev.ru/metro/line-map.

Прием 6: убрать «почти, но не совсем»

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

Посмотрим на картинку:

Здесь много почти, но не совсем, всего 6 видов разного выравнивания:

Подписи будут аккуратней, если их выровнять друг относительно друга так:

Ещё примеры «почти, но не совсем» в посте Ильи Бирмана.

Прием 7: следить за типографикой

Подписи — неблагодарный для верстки формат: колонка узкая, а тут ещё могут появиться эти длинные русские слова. В узких колонках особенно важно следить за интерлиньяжем (межстрочным интервалом), лучше уменьшить его относительно базового. Filter и panel расположены так далеко друг относительно друга, что может показаться, что это две подписи. Если уменьшить интерлиньяж будет лучше:

Ещё для подписей обычно применяют кегль, уменьшенный на пару пунктов относительно основного текста.

Про интерлиньяж:
bureau.ru/bb/soviet/20140310/
bureau.ru/bb/soviet/20140310/

Прием 8: редактировать текст

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

Прием 9: рассказывать по частям

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

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

Про подписи есть ещё два поста Сергея Стеблины, он шарит сильно лучше меня, поэтому если дочитали досюда, то прочитайте и его, вам уже нечего терять:

• Размеры и линейки
• Коротко о выносках и подписях — на самом деле не коротко

Таблица по-моему — самый недооцененный формат представления информации. Я очень часто слышу «давай сделаем таблицу, а потом сделаем полноценную визуализацию». Почти всегда это полный бред.

На самом деле таблица достаточно удачный формат:

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

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

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

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

Расскраска по процентилям: 0,95 · 0,9 · 0,75 · 0,4 · 0,1

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

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

Такой способ часто называется скользящим окном:

Получилась такая таблица:

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

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

От раскрашенной таблицы остается всего один шаг до теплокарты (heatmap) — графика, в котором области красятся в разные цвета. Вместо прямоугольных ячеек прямоугольной таблицы берутся ячейки другой формы и располагаются в каком-то естественном порядке: время, география, физическое положение.

Вот несколько примеров:

Даже график ниже — тоже таблица, хотя и не очень похоже, просто ячеек очень много и они очень мелкие:

Не стесняйтесь таблиц, это нормальный формат. Вот два совета бюро как сделать таблицы лучше:

• Как улучшить таблицу в угоду удобочитаемости и экономии места
• Расскажите про вёрстку больших таблиц

Посмотрите ещё визуализацию прогресса студентов у Михаила Капанаги: http://burostat.ru

«Критика — это комплимент» написал в 2011 году Илья Бирман.

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

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

Да ничего подобного!

Моя проблема: критика бесит

Каждый раз, когда мне сообщают об ошибке, я внутри почти вскипаю. Глаза наливаются кровью, я зеленею и превращаюсь в Халка. Вот что успевать пробежать в моей голове за первые 1,5 секунды:

• Да блин, опять комментарии, сколько можно!
• Ну куда ты лезешь? Тебя спросили?
• А сам-то умеешь верстать?
• Сам такой!
• Тоже мне в дизайне он понимает, Лебедевы вы все стали!

Даже когда разработчик пишет невинное «Привет, у меня тут вопрос по макету, давай созвонимся?» я внутренне сжимаюсь и думаю «Вот ведь, сейчас покажет дыру в макете, придется переделывать, черт-черт-черт».

Решение: что я делаю, чтобы «бесит» не мешало

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

Вот мантра:

1. Раз критикуют — хотят помочь и значит не все равно. Если бы было все равно, не написали бы. Не написать проще, чем написать.
2. Критикуют не меня, а работу: это в тексте ошибка или макет кривой. Нет, если в макет ошибка, это не значит, что я фиговый дизайнер.
3. В следующий раз будет лучше, главное не тупить и сделать выводы.
4. Потерпи, если будешь думать и делать, делать и думать, то результат будет лучше, увидишь.
   Особенно этот пункт помогал в Школе стажеров, когда арт-директор разносил в клочья мой диплом. Но без боли на первую итерацию не глянешь.

Иногда по формату и тексту критики понятно, что не хотят помочь, а критикуют для самоутверждения или по какой-то другой причине. На этот случай тоже есть мантра: Ну ладно, ну не пытаются помочь, мне-то что?

Чтобы критика не прошла впустую я действую в два этапа:

1. Исправляю
2. Делаю выводы, чтобы такое повторялось как можно меньше:

• Какой вывод я могу сделать? Из-за чего так вышло?
• Как снизить число таких ошибок в будущем?
• Как решить вопрос системно, чтобы ошибка больше не могла появиться в принципе: изменить процесс, записать в чеклист, автоматизировать?
• Какие сходные ошибки могут быть, чтобы убирать их наперед?

Как критиковать

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

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

Как быть — почитайте вот умных людей:

• Три закона критики · Максим Ильяхов
• Feedback sandwich · Илья Синельников
• Борьба с пассивно-агрессивным поведением · Максим Ильяхов
• Кнут и пряник · Максим Ильяхов

P. S. После публикации поста получил критику на пост. И ведь все было по делу: дописал краткое содержание поста Ильи Бирмана (чтобы не вынуждать открывать ссылку всех подряд), переписал заголовки и написал важный P. S.

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

Что вообще происходит

У дизайнера есть несколько разных способов передать иконки разработчику:

• отдельными файлами или спрайтом в ПНГ,
• отдельными файлами или спрайтом в СВГ,
• иконочным шрифтом.

Разработчики фронтенда все чаще привыкли использовать иконки в виде шрифта. Этим же способом распространяются популярные иконочные наборы (например, Font Awesome). У нас в компании разработчики тоже просят «дай шрифт». Мы некоторое время отлаживали схему сборки шрифта: как из файла Скетча автоматически получить файл, пригодный для фронтенда, не замучив дизайнера.

Рассказ может быть полезен разработчикам фронтенда и дизайнерам интерфейсов. В меньшей степени он будет полезен бекендным разработчикам интерфейсов (классический ASP.NET MVC или что-то подобное): схема будет та же, но не будет готовых файлов конфигураций и скриптов. Если кто-то расскажет как прикрутить к этому NuGet, напишите, я добавлю.

Зачем это делать, есть же фонтелло

Есть много готовых сервисов, которые собирают шрифт по загруженным СВГ-файлам, например fontello. Мы не стали использовать ни один из них, потому что с ними могут быть сложности:

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

Хорошее решение — простое, в нем минимум ручных действий.

Нескольким дизайнерам работать непросто. Если несколько дизайнеров поддерживают один шрифт, то возникает много вопросов синхронизации: где хранить исходники, файлы СВГ и файлы шрифта, кто собирает и кому передает, как не забыть иконку.

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

Cложно интегрировать в общий процесс сборки продукта. Отдельно стоящий сервис тяжело встроить в общий процесс разработки и сборки, а у кого-то есть еще и процесс CI. Придется вручную собирать сервисом файл, куда-то его загружать и как-то версионировать.

Хорошее решение встраивается в процесс разработки.

Не всех устраивает внешний сервис. Многие компании не верят во внешние сервисы: они могут изменить набор функций, упасть во время подготовки релиза, стать платными или закрыться. В конце концов, их могут хакнуть. Мы — ИБ-компания, и каждый раз раздражать профессионально деформированных безопасников и разработчиков наличием внешнего сервиса не хочется.

Хорошее решение работает внутри компании.

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

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

Хорошее решение дает разработчикам все что нужно. Иконка кодируется понятным названием, коды символов и размер подставляются автоматически.

Новое в этой версии  

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

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

Поставка иконок в виде библиотеки Скетча

С момента написания того поста вышла новая версия Скетча — 47, в ней появились библиотеки символов. Иконки стало удобно вставлять в макеты именно с помощью библиотеки.

Чтобы сделать один символ на одну иконку и не плодить их для каждого цвета, нужно сделать так:

1. Сделайте по символу для каждого цвета, в которые у вас можно красить иконки.

2. Нарисуйте иконку и наложите её маской на символ цвета:

После этого вы сможете менять цвет иконок через оверрайды:

Образец файла: iconset.sketch

К сожалению такой скетч-файл плохо собирался в шрифт. Это происходит из-за маски.

Маска правильно экспортируется в СВГ-файл, но в шрифте нет понятия маски, в итоге иконки ломались. Долгое время я вел скетч-файл в двух вариантах: простые артборды для шрифта и такие же с маской для библиотеки. Но это плохой способ: нужно добавлять и изменять пары одинаковых иконкок. Из-за этого иногда были ошибки — я что-то где-то забывал.

Неожиданно Акронис написал пост на Хабре про свою дизайн-систему. С помощью их поста удалось сделать правильно. Сейчас наш сборщик регулярными выражениями вырезает лишнее из СВГ-файла и превращает файл с маской в обычный файл.

Для вырезания лишнего я подключил grunt-text-replace, вот его конфиг:

replace: {
  remove_mask: {
    src: [PATH_BUILD_ICONS + '/*.svg'],
     overwrite: true,  // overwrite matched source files
     replacements: [
      {from : / fill="(.*?)"/m,             to : ''},
      {from : /(\s*)<\/defs[\s\S]*<\/g>/m,  to : ''},
      {from : /(\s*)<defs>/m,               to : ''},
      {from : / id="(.*?)"/m,               to : ''},
      {from : /xmlns:xlink="(.*?)"/m,       to : ''},
      {from : /(\s*)<g[\s\S]*?>/m,          to : ''},
      {from : /(\s*)<\/g>/m,                to : ''},
      {from : /<svg/m,                      to : '<svg fill="#000"'},
      {from : / transform="(.*?)"/m,        to : ''},
      {from : / fill-rule="(.*?)"/m,        to : ''},]            
    }
  }

Поставка иконок в виде ТТФ-файла

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

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

Редактор документации поддерживает вставку через СВГ, она решила бы почти часть этих проблем, но СВГ легко не перекрасить, и СВГ-картинки плохо выглядит при редактировании.

Идеальным вариантом для них было бы использовать ТТФ-шрифт: он отлично рендерится на экране и при печати, хорошо автоматизируется и удобно перекрашивается.

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

В новой версии вместо автоматического выбора кодов символов я задаю их руками. Меинтейнер шрифтового репозитория (это я) выдает каждой новой иконке новый код и следит за тем, чтобы коды не менялись. Для этого используется секция codepoints в grunt-webfont. Каждой иконке нужно задать номер символа. У нас используется последовательная нумерация начиная с 0xF501.

codepoints : {
   'upload-to-cloud_24' : 0xF501,
   'upload-to-cloud_64' : 0xF502,
},
startCodepoint: 0xF701,

Иконкам, которым номер не выставлен вручную, код выберется автоматически. Вообще это неправильно и лучше следить, чтобы таких иконок не было. Чтобы найти такие иконки их пространство имен отличается, им выдается номер из пространства 0xF701+, поэтому они всегда будут в конце шрифта и их легко найти.

Посмотреть коды символов можно с помощью http://opentype.js.org. Выбираете Glyph Inspector, загружаете шрифт и смотрите:

Наши писатели перешли на ТТФ-файл и довольны.

Что дальше

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

С вопросами, багрепортами или советами — в телеграм @mikeozornin или на почту mike.ozornin@gmail.com.

Я очень часто встречаю неправильно написанное слово приоритизация. С ним не всё просто, я расскажу почему правильно через „и“.

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

Приоритизация образована по привычному паттерну основа + изация. Так образуются очень многие существительные, которые обозначают процесс по созданию или распространению чего-то: автоматизация, автомобилизация, каталогизация. Если делать все по-честному, то слово было бы приоритетизация.

Если образовывать слово по-честному: приоритетизация

Но тут в написание слова вмешивается гаплология. Гаплология — это эффект выпадения в слове одного из двух идущих друг за другом одинаковых или близких по звучанию слогов (википедия).

Мы часто с ней сталкиваемся, привыкли и не замечаем:

Именно из-за гаплологии в слове приоритет выпадает конец основы „те“. Оставшийся в слове слог „ти“ — часть суффикса, а суффикса -езация не бывает.

Схема образования слова:

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

В таких ситуациях, пишите «расстановка приоритетов», не ошибетесь: