Всего пару дней назад я был на одной BBS и обыскал всё вверх и вниз,
но так и не нашёл кнопки «Помощь по Markdown», которая объясняла бы правила форматирования.
Нет, я не спрашиваю, каковы эти правила.
И я не прошу ссылку.
Я говорю, что вам нужно предоставить ссылку людям, создающим пост,
прямо рядом с полем ввода текста, пока они его редактируют.
Ну ладно, возможно, любая документация ещё не готова для обычных пользователей:
Панель редактора содержит встроенные опции, которые автоматически форматируют текст и показывают, как он будет выглядеть, если вы захотите добавить разметку Markdown [1] вручную. Разве это не более полезно, чем ссылка, ведущая к документации вне окна написания сообщения?
и, в зависимости от того, что вы добавляете, некоторые теги BBCode ↩︎
Да. Возьмём пользователя, который хочет написать «
не
». В конце концов он обнаруживает правильный способ сделать это так: « https://www.openstreetmap.org/, не https://www.openstreetmap.org/edit
». Но абсолютно невозможно было бы догадаться об этом, если бы ему не пришлось разбираться во всём самостоятельно, потому что в редакторе это большая загадка, при полном отсутствии документации. Полном.
У вас довольно интересный способ обращения к пользователю: то «он», то «вы», хотя всегда имеется в виду «я». Просто констатирую.
В интернете существуют три основных типа редакторов для создания контента внутри сервиса:
В стиле CMS, как WordPress, Drupal и т. д., где кнопок огромное множество (хотя WordPress делает всё возможное, чтобы сломать свой собственный редактор, но это уже другая история);
Минималистичные, как в социальных сетях Facebook, Twitter и т. д., где кнопок нет или их очень мало;
Устаревшие подходы из мира разработки, в основном статические генераторы сайтов и Discourse.
Первая группа пытается использовать ту же логику, что и офисные пакеты, ещё до появления веба. Там нет реальной кнопки «Помощь», потому что считается, что каждый должен знать, что делает та или иная кнопка. Или какие существуют горячие клавиши. И если пользователь не знает, он/она/оно должно найти эту информацию самостоятельно.
Социальные сети поняли, что обычным людям не нужны эти кнопки, поскольку они ими не пользуются — а на мобильных устройствах для них просто нет места. И кнопки «Помощь» там тоже нет, потому что в ней нет необходимости.
Разработанные для программистов решения ориентированы на тех, кто умеет размечать контент, не видя результата в реальном времени, помнит множество кодов и не хочет убирать руки с клавиатуры. И кнопки «Помощь» там тоже нет, потому что все должны прочитать документацию и запомнить, например, как создавать таблицы.
Но существуют и другие пользователи. На моём форуме обычные люди обсуждают обычные темы, и у них в основном низкий уровень технических навыков. Здесь, в канале Development или на GitHub, потребности совершенно другие, и предполагается, что у всех очень высокий уровень навыков. Кроме того, создаваемый контент совершенно иной. Я являюсь участником одного сайта, где сам процесс письма находится в центре внимания. Там, опять же, совершенно иные потребности.
Вопрос UX заключается не в кнопке «Помощь» в наборе инструментов. Её никто не использует, потому что её невозможно создать и эффективно применять. Даже ссылка в стиле GitHub — это уже слишком. Это абсолютно нерелевантный компонент, который редко используется, и все знают, что документация и руководства существуют.
Настоящее решение в области UX/UI — предоставить возможность:
администраторам устанавливать значения по умолчанию для пользователей;
пользователям изменять эти значения по умолчанию.
И то, что действительно нужно большинству пользователей и чего сейчас не хватает, — это возможность скрыть эту панель инструментов. Это было бы важнее, чем возможность её редактировать.
Вопрос редактора здесь почти стал темой для часто задаваемых вопросов (FAQ), и кнопка «Помощь» — лишь часть этого. Давайте будем честны: у Дэна есть своя повестка, и кнопка «Помощь» — лишь ещё один признак этого, а не сама цель. Я надеюсь, что Дэну на самом деле просто не удалось разобраться, как сделать что-то, и он не смог найти помощь. Это должна быть проблема конкретного сайта, а не платформы Discourse как таковой.
Да, я говорил о реальном случае, когда я публиковал
и оба превью ссылок были одинаковыми, из-за чего мой пост выглядел глупо.
Поэтому я боролся с интерфейсом (Discourse), пытаясь найти способ отключить
всю эту магию — без какой-либо документации о том, как это сделать.
Так что всё пришлось решать методом проб и ошибок…
Ну, я вспомнил, что вы используете «Markdown», и помню, что в Markdown есть такой синтаксис,
и это сработало.
Всё,
что
я
хочу
сказать,
это то, что где-то должен быть официальный документ, который объясняет пользователям, что произойдёт, когда они вводят тот или иной символ.
Им не нужно читать исходный код, чтобы это узнать. Спасибо.
Хорошо, поместите это в FAQ, а затем добавьте ссылку на FAQ где-нибудь в интерфейсе.
Хорошо, допустим, вы разместили будущий FAQ по форматированию на сайте Discourse. Проблема решена…
кроме того, как пользователь вообще узнает, что он использует Discourse? Да, я говорю о пользователях, а не об администраторах. Спасибо ещё раз.
Это подмена тезиса. Возможно, есть несколько опытных разработчиков, которые выучили правила форматирования наизусть и не нуждаются в документации, но не все не-новички помнят все правила форматирования.
С учетом различных вариантов Markdown, BBCode и HTML, поддерживаемых разными инстанциями Discourse, в документации нет единого руководства.
Если кто-то создаст руководство для конкретного набора допустимых кодов разметки на сайте и захочет добавить ссылку на помощь в стиле GitHub на странице редактора, как показано ниже, как это можно реализовать?