x
 
Александр Колодько
21 января 2021
Советы почтой каждую неделю
Пожалуйста, получите наше письмо, чтобы подтвердить свой адрес:
Вы подписаны на «Советы за неделю»:

Как вы оцените с технической точки зрения новый редактор публикаций в «Деле Модульбанка» — https://intuition.team/delo-control-panel? Какие технологии и фреймворки вы бы порекомендовали, чтобы сделать что-то подобное у себя на сайте?


Сразу пре­ду­прежу, что я не запу­стил ни одного успеш­ного медиа, поэтому порас­суж­даю как раз­ра­бот­чик. Опре­де­лённо, у команды «Дела» были серьёз­ные при­чины не брать гото­вые инстру­менты вроде GraphCMS или хотя бы редак­торы вроде Quill, Vev или оте­че­ствен­ной Сетки.

Мне нра­вится идея с биб­лио­те­кой гото­вых ком­по­нен­тов: редак­торы не изоб­ре­тают фор­маты, а поль­зу­ются гото­выми ком­по­нен­тами, кото­рые точно выгля­дят хорошо. При этом в исклю­чи­тель­ных слу­чаях фор­мат можно и изоб­ре­сти — к про­грам­ми­стам идти не при­дётся. Похо­жая биб­лио­тека исполь­зу­ется и в сове­тах бюро.

С точки зре­ния удоб­ства меня сму­щает Паг. По срав­не­нию с обыч­ным тек­стом, под­дер­жи­вать длин­ные доку­менты на Паге — муче­ние. На нём, как и на любом языке про­грам­ми­ро­ва­ния, легко оши­биться — не закрыть ско­бочку, поста­вить непра­виль­ный отступ или пере­пу­тать ( и ]. Но, в отли­чие от ХТМЛ или того же Питона, у Пага нет онлайн‑под­светки, кото­рая пока­жет ошибку во время редак­ти­ро­ва­ния: вы не узна­ете, что ошиб­лись, пока не запу­стите ком­пи­ля­цию. Наде­юсь, раз­ра­бот­чики «Дела» нашли обход­ной путь, к при­меру рен­де­рят текст прямо в про­цессе редак­ти­ро­ва­ния и пока­зы­вают ошибки где‑нибудь рядом с окном редактирования.

Паг — это целый язык про­грам­ми­ро­ва­ния: с пере­мен­ными, функ­ци­ями, опе­ра­то­рами ветв­ле­ния, ите­ра­то­рами, снип­пе­тами и филь­трами. Вряд ли редак­торы исполь­зуют хоть что‑то из этого — ско­рее всего они про­сто пишут тек­сты с вкрап­ле­ни­ями раз­метки. А зна­чит, вме­сто Пага гораздо лучше подо­шёл бы обыч­ный Марк­даун: текст из тек­сто­вого редак­тора в нём выгля­дит хорошо, но при жела­нии в него так же легко вста­вить любой ХТМЛ. В отли­чие от Пага, Марк­даун тер­пим к чело­ве­че­ским ошиб­кам, да и порог входа у него ниже. Срав­ните, как выгля­дит текст на Марк­дауне и на Паге:

Маркдаун
Редак­торы пишут как при­выкли:
  * Не думают про HTML
  * В люби­мом при­ло­же­нии типа _IA Writer_
  * Текст легко **выде­лять**
  * Но можно вста­вить <strong>HTML</strong>, если вдруг забыл син­так­сис
Паг
p Редак­торы пишут как при­выкли:
ul
  li Не думают про HTML
  li В люби­мом при­ло­же­нии типа #[i IA Writer] писать уже не полу­ча­ется
  li Выде­лять текст #[b сложно, но можно]
  li Вста­вить <strong>HTML</strong>, если вдруг забыл син­так­сис, тоже можно

Кроме ЦСС в ито­го­вой раз­метке, для рас­ши­ре­ния Марк­дауна есть инте­рес­ные задумки вроде mdx, кото­рые поз­во­ляют исполь­зо­вать в тек­сте ком­по­ненты Реакта.

Зна­ете, чем Паг удоб­нее Марк­дауна? Напи­шите в комментариях!

P. S. Это был совет об управлении разработкой. Хотите больше знать о планировании спринтов, управлении продуктом или о настройке инфраструктуры? Присылайте вопросы.

Поделиться
Отправить

Комментарии

Люда Сарычева
24 января 2021

Прокомментирую как главный редактор, основатель и руководитель Дела Модульбанка. Ненавижу маркдаун!

Фёдор Борщёв
25 января 2021

Людмила, не расскажете подробнее, чем вам неприятен маркдаун?

Николай Волынкин
10 февраля 2021

Я пишу техническую документацию, используя разметку reStructuredText. Она чуть посложнее маркдауна, но богаче по возможностям. Главное — есть семантическая разметка. Можно обозначить, что вот это — термин, это — название элемента интерфейса, а то — блок кода. А то, как будет выглядеть термин, название кнопки или пример кода, задаётся, например, в CSS-стилях для сайта. Если захотим отображать термины другим стилем, сможем поменять отображение, не редактируя тексты. Markdown и Pug позволяют только выделить текст заранее заданным стилем, вроде полужирного или курсива, либо повесить на текст конкретный класс. В обоих случаях автор текста вручную задаёт отображение элементов текста, и это хуже, чем задавать их семантику и делегировать отображение.

Ещё reStructuredText строже, и ошибки обнаруживаются сразу (fail-fast). Например, когда мы указали несуществующий адрес в ссылке, или когда открыли и не закрыли внутристрочную разметку. Markdown или HTML, наоборот, позволяют ошибаться сколько угодно. Это приемлемо, когда пользователи сайта пишут комментарии и мы хотим показать их хоть как-нибудь, даже с ошибками. Но ошибки в профессиональных текстах лучше находить и исправлять сразу, до публикации.

Кроме reStructuredText есть ещё язык разметки AsciiDoc. Он столь же хорош и семантичен. Выбор между двумя этими языками — дело вкуса и заточки под конкретные задачи.


Цель рубрики — обсуждение вопросов дизайна всех видов, текста в дизайне и взаимоотношений дизайнеров с клиентами.

Мы публикуем комментарии, которые добавляют к уже сказанному новые мысли и хорошие примеры. Мы ожидаем, что такие комментарии составят около 20% от общего числа.

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

Вот такой веб 2.0.

Сколько времени тратите на планирование реализации «фичи» и сколько времени на написание самого кода? Какие технологии вы бы порекомендовали для создания статичных и не самых сложных сайтов 2 Как объяснить значимость фичи разработчику? 1 Расскажите об обязанностях технического директора в бюро. Вторая часть: встречи один на один




Недавно всплыло

Насколько правильным будет делать цвет ошибок почти таким же, как цвет кнопок? 2 Без стоп-слов текст мне кажется сухим, чёрствым, грубым и резким 26 Когда иконки незаменимы? 5 9