Смысл общения раскрывается, когда каждый в комнате слышит мысли друг друга, и плоская линейная временная шкала всегда была лучшим способом обеспечить это на Discourse. Однако плоский формат подходит не каждому сообществу. В крупных быстро развивающихся форумах тысячи ответов на одной временной шкале делают невозможным для кого-либо уследить за всем. Именно поэтому мы осторожно экспериментируем в этом году с полностью вложенным видом ответов и считаем, что он отлично подходит для сообществ, переросших плоский формат.
То, что начиналось как экспериментальный плагин, превратилось в проект, который теперь внедряется непосредственно в Discourse. Вот пример того, как выглядит вложенная тема на данный момент:
Настройки сайта для включения этой функции доступны в интерфейсе администратора. Перейдите в раздел «Вложенные ответы», чтобы управлять функцией, режимами сортировки по умолчанию, максимальной глубиной и другими параметрами.
Дорожная карта
На момент написания этого текста вложенные ответы находятся на ранней стадии. Дорожная карта ещё не полностью проработана. Вот несколько вещей, которые мы точно планируем сделать:
Улучшение мобильного опыта
Переосмысление временной шкалы темы для вложенного вида. В настоящее время в режиме вложенных ответов на темах нет временной шкалы
Добавление как минимум одного нового режима сортировки постов с учётом старения, аналогичного нашему режиму «Горячее» для списков тем.
Ограничения
Когда вложение включено для категории, существующие темы остаются в плоском режиме. Каждую тему можно индивидуально переключить через гаечный ключ администратора, но в настоящее время нет способа перевести существующую категорию в режим вложенных ответов.
Мы будем рады вашим отзывам
Нам нужны ваши отзывы и опыт использования этой функции, чтобы помочь в её развитии. Если это решение подходит для вашего сообщества, попробуйте его и расскажите нам, что думаете вы и ваши пользователи!
О да! Отличное время. Я сегодня вечером мигрирую форум на новый сервер с двумя контейнерами и не могу дождаться, когда переключусь на новую версию, когда через пару недель начнётся регулярный сезон и наши спортивные пулы. Это тоже станет хорошим тестовым случаем.
Будет здорово иметь возможность выбора между плоской и встроенной дискуссией — спасибо за это @markvanlan и команде.
Просто для информации: когда появляются новые ответы в нескольких ветках дерева, похоже, что одноветочный вид показывал мне только один за раз. Мне приходилось возвращаться несколько раз, при этом счетчик непрочитанных сообщений уменьшался на единицу каждый раз.
Хм, не уверен, насколько будет работоспособна массовая переключательная функция для категорий с десятками тысяч тем. Возможно, стоит рассмотреть вариант с использованием фоновых задач Rails для массовой или пакетной конвертации?
И обратима ли эта операция? Можно ли преобразованную в ветку тему обратно в плоскую?
Да, я согласен с вами. Это ограничение на данный момент, и мы обязательно будем это учитывать.
Основная причина, по которой я решил не преобразовывать исторические темы в категории, когда эта функция включена, заключается в том, что пользователи, скорее всего, будут взаимодействовать с ними по-другому. В плоском режиме различные кнопки Ответить не так важны. Сообщение будет добавлено в конец темы. Я не уверен, что пользователи всегда намеренно нажимают на «правильную» кнопку, которая соответствовала бы вложенному виду.
В целом я беспокоюсь, что администраторы включат эту функцию для исторических тем, и тогда обсуждение станет нечитаемым. Мы продолжим обдумывать этот вопрос. Самое простое изменение, которое я могу придумать: при переключении настройки категории будет появляться модальное окно с вопросом: «Хотите применить это к существующим темам?»
Мне всегда казалось, что метки «Ответить» могли бы быть более конкретными — поэтому некоторое время назад я использовал пользовательский CSS, чтобы добавить контекст:
/* добавить текст к кнопке Ответить для исходного сообщения (также известного как Тема) */
#post_1 nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Добавляем этот текст после Ответить
content: " к этой теме";
}
}
}
}
/* добавить текст к кнопке Ответить для всех последующих сообщений (я называю их комментариями) */
nav.post-controls {
.actions {
button.reply {
span.d-button-label:after {
// Добавляем этот текст после Ответить
content: " к этому комментарию";
}
}
}
}
/* добавить текст к синей кнопке Ответить (к теме), появляющейся в конце страницы */
#topic-footer-buttons {
.topic-footer-main-buttons {
button.btn-primary.create {
span.d-button-label:after {
// Добавляем этот текст после Ответить
content: " к основной теме";
}
}
}
}
Проблема с этим решением заключается в том, что оно не будет переведено в интерфейсе для участников, у которых в настройках предпочтений указан язык, отличный от английского
Не означает ли это, что сначала следует протестировать эту функцию в наших сообществах изолированно, прежде чем всем нам решиться на конвертацию всех существующих тем?
Это сработало бы, если бы функция поддерживала десятки тысяч тем.
Но при этом должно быть очень четко указано, что откат назад невозможен
Будет ли эта функция реализована сначала здесь, на meta, или на https://try.discourse.org, чтобы мы могли протестировать её вне наших производственных сред?
Если бы это было моё сообщество, я бы сначала протестировал в изоляции. С другой стороны, если вы включите это для всего своего сообщества, вы получите более ценную обратную связь быстрее . Шутки в сторону, я считаю, что тестирование в изоляции — разумный шаг, но здесь нет разрушительных миграций данных. Функцию можно безопасно включать и выключать. Ваше решение не закрепит вас ни в одном из направлений.
Кажется, я уже случайно ответил на эту часть! Включение вложенности просто создаёт запись nested_topic для каждой темы в базе данных и запускает задачу по подсчёту количества ответов по всей ветви предков. Отключение вложенности удаляет эту запись nested_topic, и вы возвращаетесь к плоской структуре — никаких проблем.
Есть ли причина, по которой эту функцию могут включать только сотрудники, а не обычные пользователи? Когда я узнал, что она появится в Meta, я подумал, что её добавят в меню типов сообщений, но переключатель скрыт за иконкой гаечного ключа сотрудников.
Мы не хотим, чтобы это было решением или предпочтением пользователя. Решать, как должен функционировать их сайт, — это задача администраторов. Эти две парадигмы сильно различаются, и пользователям не следует так по-разному взаимодействовать с одним и тем же контентом. По крайней мере, таково наше текущее мнение.
Блоки объявлений не работают должным образом в этой структуре, а конвертация тем часто вызывает ошибку, при которой элементы на экране исчезают, и можно редактировать только заголовок.
Отличная функция! Однако меня интересует больше сортировка «Лучшие / Новые / Старые», чем сама вложенная структура. Я уже реализовывал похожие элементы управления сортировкой в своём мобильном приложении (клиент для Discourse) и с радостью поддержал бы это нативно, вместо моего текущего метода, который, как я покажу ниже, тоже работает.
Изучив исходный код, я вижу, что запрос GET /n/{slug}/{topic_id}.json?sort={top|new|old}&page={n} возвращает тему во вложенном виде, отсортированную по выбранному режиму. Мой вопрос: есть ли интерес к тому, чтобы через существующую конечную точку /t/{slug}/{topic_id}.json (например, ?sort=top) экспонировать только сортировку, чтобы клиенты с плоским видом тоже могли этим воспользоваться?
Если сортировка будет доступна для плоского вида, сторонние клиенты смогут подключиться к ней, не переходя на модель рендеринга вложенного вида.
Я понимаю, что именно структура данных вложенного вида (корневые сообщения + ленивые дочерние элементы) делает сортировку на стороне сервера выполнимой, а плоский вид использует другую логику пагинации. Если полноценная сортировка плоского вида нереалистична по соображениям производительности, даже опциональный параметр ?sort=top&limit=N был бы достаточен для реализации представления «Лучшее».
. Шутки в сторону, я считаю, что тестирование в изоляции — разумный шаг, но здесь нет разрушительных миграций данных. Функцию можно безопасно включать и выключать. Ваше решение не закрепит вас ни в одном из направлений.
