# Natural breakpoints or "chapters" for long topics?

**URL:** https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461
**Category:** Feature
**Created:** [12.Июнь.2014 00:08:49 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461 "2014-06-12T00:08:49Z")
**Posts on this page:** 11
**Page:** 4

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [24.Декабрь.2021 06:59:38 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/62 "2021-12-24T06:59:38Z")

</div>

YouTube показывает горячие точки в видео при прокрутке временной шкалы:

Как видите, есть пики и спады количества просмотров, к которым мы всегда стремились, @sam @eviltrout.

 ![image](https://global.discourse-cdn.com/meta/original/3X/e/f/ef9bfbd52cbc67cff0231e9540f2deb860a85ceb.jpeg)

Интересно представить эксперимент с переносом нашей существующей функции «краткое содержание темы» на видео: «У меня нет времени смотреть 30-минутное видео, покажи мне только лучшие моменты» 🤔

---

<div class="post-metadata">

### Author: ![Ivan\_Rapekas](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ivan_rapekas/32/248924_2.png) [@Ivan\_Rapekas](https://meta.discourse.org/u/Ivan_Rapekas)
#### Post date: [24.Декабрь.2021 07:46:47 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/63 "2021-12-24T07:46:47Z")

</div>

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

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

Самые популярные места в первом посте — это абзацы, цитаты из которых использовались в ветке.

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

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

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [26.Декабрь.2021 19:32:48 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/64 "2021-12-26T19:32:48Z")

</div>

> [@Ivan\_Rapekas](#):
>
> Это относится к темам с большим количеством просмотров и комментариев. Текст, который был только что опубликован, не может быть автоматически разделён на логические части.

Да, именно поэтому кнопка «Создать резюме темы» появляется только тогда, когда в теме есть 50 или больше ответов… так было всегда.

---

<div class="post-metadata">

### Author: ![Canapin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/canapin/32/119591_2.png) [@Canapin](https://meta.discourse.org/u/Canapin)
#### Post date: [05.Июль.2022 00:31:44 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/65 "2022-07-05T00:31:44Z")

</div>

Обсудив с пользователями на другом форуме пагинацию и бесконечную прокрутку и поскольку я подозреваю, что то, чего пользователям действительно не хватает при бесконечной прокрутке, — это не строго _пагинация_, а своего рода точки останова, я задаюсь вопросом, добился ли прогресса в разработке этих точек останова команда разработчиков Discourse.

---

<div class="post-metadata">

### Author: ![codinghorror](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/codinghorror/32/110067_2.png) [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [02.Ноябрь.2022 22:58:10 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/67 "2022-11-02T22:58:10Z")

</div>

Удивительно, насколько на практике полезна эта функция «популярность в таймлайне». Честно говоря, она отлично подходит для подкастов, длинных статей, протяжённых чатов… в общем, везде. **Покажите, какие именно части люди на самом деле читают, слушают и рассматривают.**

 ![image](https://global.discourse-cdn.com/meta/original/4X/5/8/9/58922251c4cf264d44f460e79f49526d7acd874c.jpeg)

Элемент Свести тему к краткому содержанию расположен в верхней части темы. Таким образом, когда вы **заходите в тему сверху и прокручиваете вниз** , у вас есть возможность увидеть «только самое главное». Идея о том, что вы в основном будете заходить в **верхнюю** часть темы, является своего рода допущением — довольно безопасным, полагаю, но…

Не могу не задуматься: не имеет ли смысл рекламировать функцию «Краткое содержание» (и предлагать её включить), когда вы (так или иначе) попадаете по глубокой ссылке в длинную тему, оказываясь в самом низу или где-то посередине длинного разговора? 🤔

---

<div class="post-metadata">

### Author: ![Canapin](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/canapin/32/119591_2.png) [@Canapin](https://meta.discourse.org/u/Canapin)
#### Post date: [05.Ноябрь.2022 21:56:35 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/68 "2022-11-05T21:56:35Z")

</div>

Думаю, есть небольшая проблема с поощрением пользователей переходить к «точкам разрыва» ( **если** под этим подразумевается, например, пост, который особенно понравился многим, или пост с большим количеством ответов).

Это может заставить людей упускать другой интересный контент. Они будут стремиться к «лучшему» отобранному обсуждению, и возникнет эффект снежного кома. Они будут видеть и лайкать отобранные посты, которые им показывают, а другие посты останутся без внимания, поскольку не отображаются.

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

 ![image](https://global.discourse-cdn.com/meta/original/4X/b/7/5/b758937ca66816b7c8139f574c62dcbf35a3b259.jpeg)

И я тоже использую их, полагая, что это естественным образом приведёт меня к тому, что я хочу увидеть. Конечно. В большинстве случаев так и бывает. Но как узнать это, не просмотрев всё видео (даже с использованием перемотки)?

Невозможно об этом подумать, не вспомнив систему голосований «за» на Reddit, где посты с наибольшим количеством голосов «за» с наибольшей вероятностью получают их именно потому, что по умолчанию находятся вверху комментариев. Эффект снежного кома. И я видел ОЧЕНЬ много топовых комментариев на Reddit, содержащих ошибочную информацию.  
Как пользователь, если вы хотите их исправить, вы пишете сообщение… Но его никто никогда не прочитает, потому что ваше сообщение с 0 голосов «за» окажется внизу среди XX или XXX комментариев. Со мной такое случалось слишком много раз, и я больше не пытаюсь это исправлять.

* * *

Мне очень нравится эта тема. Это очень, очень интересный предмет.

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [09.Август.2024 19:47:40 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/69 "2024-08-09T19:47:40Z")

</div>

Эта тема возникла у меня при размышлениях о потенциальной интеграции ИИ с Discourse, поэтому я быстро попробовал:

> [Can Discourse ship frequent Docker images that do not need to be bootstrapped?](https://meta.discourse.org/t/can-discourse-ship-frequent-docker-images-that-do-not-need-to-be-bootstrapped/33205)  
> Заголовок: Первоначальный ответ Сэма о Docker-образах  
> Начало: 1  
> Заголовок: Обсуждение Docker Compose и проектирования контейнеров  
> Начало: 18  
> Заголовок: Команда Discourse объясняет свой подход  
> Начало: 23  
> Заголовок: Участники сообщества предлагают альтернативы  
> Начало: 49  
> Заголовок: Продолжение обсуждения компромиссов в проектировании контейнеров  
> Начало: 136  
> Заголовок: Обновления и размышления в последние годы  
> Начало: 165

> [Why isn't Discourse more frequently recommended as a "community platform"?](https://meta.discourse.org/t/why-isnt-discourse-more-frequently-recommended-as-a-community-platform/221040)  
> Заголовок: Первоначальный вопрос и контекст  
> Начало: 4  
> Заголовок: Ответы и уточнения команды CDCK  
> Начало: 6  
> Заголовок: Позиционирование и маркетинг Discourse  
> Начало: 27  
> Заголовок: Опыт пользователей и обратная связь  
> Начало: 125  
> Заголовок: Проблемы и предложения по UI/UX  
> Начало: 60  
> Заголовок: Открытый исходный код и особенности самостоятельного хостинга  
> Начало: 97  
> Заголовок: Сравнение с другими платформами  
> Начало: 155  
> Заголовок: Будущее направление и развитие  
> Начало: 151

> [Discord is taking aim at Discourse. How does Discourse remain unique and stand out from the crowd?](https://meta.discourse.org/t/discord-is-taking-aim-at-discourse-how-does-discourse-remain-unique-and-stand-out-from-the-crowd/227765)  
> Заголовок: Первоначальное сравнение и опасения  
> Начало: 1  
> Заголовок: Преимущества Discourse  
> Начало: 2  
> Заголовок: Функциональность чата против форума  
> Начало: 6  
> Заголовок: SEO и обнаруживаемость  
> Начало: 8  
> Заголовок: Мобильный опыт и уведомления  
> Начало: 40  
> Заголовок: Открытый исходный код и владение данными  
> Начало: 78  
> Заголовок: Новые функции форумов в Discord  
> Начало: 101  
> Заголовок: Интеграция между платформами  
> Начало: 110  
> Заголовок: Будущие перспективы обеих платформ  
> Начало: 133

> [Federation support for Discourse](https://meta.discourse.org/t/federation-support-for-discourse/90921)  
> Заголовок: Первоначальное предложение и преимущества  
> Начало: 1  
> Заголовок: Ранние трудности и существующие примеры  
> Начало: 3  
> Заголовок: Идеи реализации ActivityPub  
> Начало: 14  
> Заголовок: Возобновившийся интерес и планы разработки  
> Начало: 76  
> Заголовок: Спецификация и разработка плагина  
> Начало: 87  
> Заголовок: Релиз плагина и следующие шаги  
> Начало: 120

> [The State of JavaScript on Android in 2015 is... poor](https://meta.discourse.org/t/the-state-of-javascript-on-android-in-2015-is-poor/33889)  
> Заголовок: Производительность JavaScript на Android значительно уступает iOS  
> Начало: 1  
> Заголовок: Анализ причин низкой производительности на Android  
> Начало: 39  
> Заголовок: Изучение альтернатив для улучшения опыта на Android  
> Начало: 18  
> Заголовок: Действительно ли это серьезная проблема для пользователей?  
> Начало: 84  
> Заголовок: Прогресс в производительности JavaScript на Android со временем  
> Начало: 246  
> Заголовок: Разрыв в производительности сохраняется в последние годы  
> Начало: 261

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

---

<div class="post-metadata">

### Author: ![TooAme](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/tooame/32/539060_2.png) [@TooAme](https://meta.discourse.org/u/TooAme)
#### Post date: [15.Январь.2026 09:34:19 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/70 "2026-01-15T09:34:19Z")

</div>

Я наткнулся на эту ветку, исследуя ту же проблему, и был искренне удивлён, увидев, что здесь идея «популярности» («Hotness») уже была сформулирована ещё в 2014 году.

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

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

 ![image](https://global.discourse-cdn.com/meta/original/4X/9/7/f/97fcb774fe20592ac11c503e8e03f6f6ef889b77.png) ![image](https://global.discourse-cdn.com/meta/original/4X/8/8/4/884b75c6cae946558691b8d1cda00b72a02ad08c.png)

В ходе этого эксперимента я столкнулся с несколькими практическими аспектами, которые стоит обсудить.

**Порог и фильтрация:** Не каждое сообщение с двумя реакциями заслуживает отдельной полосы. Я считаю полезным установить минимальный порог: либо как абсолютное число (например, не менее 10 реакций), либо как относительный процент (например, не менее 30% от максимального количества реакций в теме). Без фильтрации временная шкала становится зашумлённой. Кроме того, создание тепловой карты для тем с всего 10 сообщениями кажется излишним, поэтому логично добавить настройку минимального размера темы.

**Перекрывающиеся полосы:** Когда несколько сообщений с высокой вовлечённостью расположены близко друг к другу, их полосы перекрываются, и их становится трудно выбрать. Одно из решений, которое я придумал: при наведении на полосу пользователь может нажимать клавиши «Вверх»/«Вниз», чтобы перебирать перекрывающиеся полосы в этой позиции. Выбранная полоса будет подсвечиваться, а её всплывающая подсказка будет обновляться соответствующим образом.

В исходном обсуждении упоминались лайки, ответы, время чтения, закладки и внутренние/внешние ссылки. Мой скрипт использует только количество реакций, так как эти данные легко доступны. Однако взвешенный интегральный показатель мог бы дать лучшие результаты. Мне интересно, что команда исследовала с 2014 года в отношении внутреннего алгоритма определения «популярности».

Я искренне жду, когда эта концепция будет пересмотрена. Временная шкала уже является отличным инструментом навигации — добавление слоя «популярности» сделало бы её ещё более мощной для тех из нас, кто углубляется в долговременные темы.

---

<div class="post-metadata">

### Author: ![chapoi](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/chapoi/32/537252_2.png) [@chapoi](https://meta.discourse.org/u/chapoi)
#### Post date: [25.Февраль.2026 06:13:30 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/71 "2026-02-25T06:13:30Z")

</div>

> [@TooAme](#):
>
> Я действительно с нетерпением жду повторного рассмотрения этой идеи. Таймлайн уже является отличным инструментом навигации — добавление слоя «популярности» сделало бы его ещё более мощным для тех из нас, кто углубляется в долгоживущие темы.

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

Особенно в длинных постах удалённые темы приводят к рассинхронизации между тем, что показывает таймлайн, и реальным postID.

Как видно здесь, postID равен 425 (как в URL), но таймлайн отфильтровал удалённые посты и показывает, что мы находимся на посте 405.

 ![CleanShot 2026-02-25 at 10.01.56@2x](https://global.discourse-cdn.com/meta/original/4X/e/a/9/ea97ae7585a7680fd6c18369d25c20507d66a4f7.jpeg)

В результате индикатор для этого поста с 39 лайками (который следует той же структуре, что и таймлайн), не соответствует правильной позиции.

Когда я прокручиваю вниз до таймлайн-postID 425, он (более или менее) верен, но, конечно, пост с 39 лайками уже не виден.

 ![CleanShot 2026-02-25 at 10.01.09@2x](https://global.discourse-cdn.com/meta/original/4X/f/9/2/f92c7f94cbc0712d9ea239d82fc86cc9d0680a71.png)

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

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

 ![CleanShot 2026-02-25 at 10.12.20@2x](https://global.discourse-cdn.com/meta/original/4X/0/6/3/063c5dde4ed3767473a0f2c33d85ae7505ddaa56.png)

---

<div class="post-metadata">

### Author: ![bookwar](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/bookwar/32/552266_2.png) [@bookwar](https://meta.discourse.org/u/bookwar)
#### Post date: [24.Апрель.2026 20:44:53 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/72 "2026-04-24T20:44:53Z")

</div>

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

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

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

Затем я делаю второй проход, пытаясь вернуться к тому, что запомнил, и комментирую это.

В настоящее время ползунок временной шкалы не очень помогает в этом, так как он позволяет переходить только к номеру поста. Пока я читаю, номера постов не очень заметны и определённо их трудно запомнить.

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

Также было бы полезно возвращаться к реакциям, а не только к закладкам. Тогда я могу использовать разные метки для разных постов и отвечать партиями: на втором проходе ответить на все позитивные комментарии «спасибо», на третьем — на одну проблему, упомянутую несколькими людьми, на четвёртом — на другую и так далее.

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

---

<div class="post-metadata">

### Author: ![mcwumbly](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/mcwumbly/32/103861_2.png) [@mcwumbly](https://meta.discourse.org/u/mcwumbly)
#### Post date: [24.Апрель.2026 20:49:41 UTC](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461/73 "2026-04-24T20:49:41Z")

</div>

> [@bookwar](#):
>
> Когда я имею дело с длинной веткой, я обычно не отвечаю на комментарии сразу, как их вижу, потому что на них часто уже ответили позже в этой же ветке.
> 
> Поэтому я обычно сначала читаю всё целиком, делая мысленные заметки о том, на что хочу ответить.

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

Это сохраняет их в редакторе по мере чтения, а затем, читая дальше, я могу решить, какие фрагменты всё ещё актуальны, а какие нет. После этого я просто удаляю те, которые не важно включать. Иногда это вообще все фрагменты!

Так что это немного костыль, но всё же полезный совет.

[Предыдущая страница](https://meta.discourse.org/t/natural-breakpoints-or-chapters-for-long-topics/16461.md?page=3)
