YouTube показывает горячие точки в видео при прокрутке временной шкалы:
Как видите, есть пики и спады количества просмотров, к которым мы всегда стремились, @sam @eviltrout.
Интересно представить эксперимент с переносом нашей существующей функции «краткое содержание темы» на видео: «У меня нет времени смотреть 30-минутное видео, покажи мне только лучшие моменты» 
Это применимо к темам с большим количеством просмотров и комментариев. Недавно опубликованный текст не может быть автоматически разделён на логические части.
Самое простое — работать с постами. Возможно, стоит учитывать реакции пользователей. Тогда наименее полезные посты можно затемнять или полностью скрывать, тем самым сжимая ветку. Те же правила можно применить к абзацам первого сообщения.
Самые популярные места в первом посте — это абзацы, цитаты из которых использовались в ветке.
Затем стоит учитывать теги и подписи к изображениям, использованные автором темы, чтобы случайно не скрыть важную информацию.
Нам нужно больше активного взаимодействия пользователей. Вовлекайте их, сообщая, что содержание темы формируется ими. «Эй, ваше мнение учитывается, посмотрите, как это здорово!»
Да, именно поэтому кнопка «Создать резюме темы» появляется только тогда, когда в теме есть 50 или больше ответов… так было всегда.
Обсудив с пользователями на другом форуме пагинацию и бесконечную прокрутку и поскольку я подозреваю, что то, чего пользователям действительно не хватает при бесконечной прокрутке, — это не строго пагинация, а своего рода точки останова, я задаюсь вопросом, добился ли прогресса в разработке этих точек останова команда разработчиков Discourse.
Удивительно, насколько на практике полезна эта функция «популярность в таймлайне». Честно говоря, она отлично подходит для подкастов, длинных статей, протяжённых чатов… в общем, везде. Покажите, какие именно части люди на самом деле читают, слушают и рассматривают.
Элемент Свести тему к краткому содержанию расположен в верхней части темы. Таким образом, когда вы заходите в тему сверху и прокручиваете вниз, у вас есть возможность увидеть «только самое главное». Идея о том, что вы в основном будете заходить в верхнюю часть темы, является своего рода допущением — довольно безопасным, полагаю, но…
Не могу не задуматься: не имеет ли смысл рекламировать функцию «Краткое содержание» (и предлагать её включить), когда вы (так или иначе) попадаете по глубокой ссылке в длинную тему, оказываясь в самом низу или где-то посередине длинного разговора?
Думаю, есть небольшая проблема с поощрением пользователей переходить к «точкам разрыва» (если под этим подразумевается, например, пост, который особенно понравился многим, или пост с большим количеством ответов).
Это может заставить людей упускать другой интересный контент. Они будут стремиться к «лучшему» отобранному обсуждению, и возникнет эффект снежного кома. Они будут видеть и лайкать отобранные посты, которые им показывают, а другие посты останутся без внимания, поскольку не отображаются.
На вашем скриншоте большинство «наиболее просматриваемых частей» привязаны к главам, но на видео с небольшим количеством глав или без них «наиболее просматриваемая часть» существует и вне рамок глав:
И я тоже использую их, полагая, что это естественным образом приведёт меня к тому, что я хочу увидеть. Конечно. В большинстве случаев так и бывает. Но как узнать это, не просмотрев всё видео (даже с использованием перемотки)?
Невозможно об этом подумать, не вспомнив систему голосований «за» на Reddit, где посты с наибольшим количеством голосов «за» с наибольшей вероятностью получают их именно потому, что по умолчанию находятся вверху комментариев. Эффект снежного кома. И я видел ОЧЕНЬ много топовых комментариев на Reddit, содержащих ошибочную информацию.
Как пользователь, если вы хотите их исправить, вы пишете сообщение… Но его никто никогда не прочитает, потому что ваше сообщение с 0 голосов «за» окажется внизу среди XX или XXX комментариев. Со мной такое случалось слишком много раз, и я больше не пытаюсь это исправлять.
Мне очень нравится эта тема. Это очень, очень интересный предмет.
Эта тема возникла у меня при размышлениях о потенциальной интеграции ИИ с Discourse, поэтому я быстро попробовал:
Can Discourse ship frequent Docker images that do not need to be bootstrapped?
Заголовок: Первоначальный ответ Сэма о Docker-образах
Начало: 1
Заголовок: Обсуждение Docker Compose и проектирования контейнеров
Начало: 18
Заголовок: Команда Discourse объясняет свой подход
Начало: 23
Заголовок: Участники сообщества предлагают альтернативы
Начало: 49
Заголовок: Продолжение обсуждения компромиссов в проектировании контейнеров
Начало: 136
Заголовок: Обновления и размышления в последние годы
Начало: 165
Why isn't Discourse more frequently recommended as a "community platform"?
Заголовок: Первоначальный вопрос и контекст
Начало: 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?
Заголовок: Первоначальное сравнение и опасения
Начало: 1
Заголовок: Преимущества Discourse
Начало: 2
Заголовок: Функциональность чата против форума
Начало: 6
Заголовок: SEO и обнаруживаемость
Начало: 8
Заголовок: Мобильный опыт и уведомления
Начало: 40
Заголовок: Открытый исходный код и владение данными
Начало: 78
Заголовок: Новые функции форумов в Discord
Начало: 101
Заголовок: Интеграция между платформами
Начало: 110
Заголовок: Будущие перспективы обеих платформ
Начало: 133
Federation support for Discourse
Заголовок: Первоначальное предложение и преимущества
Начало: 1
Заголовок: Ранние трудности и существующие примеры
Начало: 3
Заголовок: Идеи реализации ActivityPub
Начало: 14
Заголовок: Возобновившийся интерес и планы разработки
Начало: 76
Заголовок: Спецификация и разработка плагина
Начало: 87
Заголовок: Релиз плагина и следующие шаги
Начало: 120
The State of JavaScript on Android in 2015 is... poor
Заголовок: Производительность JavaScript на Android значительно уступает iOS
Начало: 1
Заголовок: Анализ причин низкой производительности на Android
Начало: 39
Заголовок: Изучение альтернатив для улучшения опыта на Android
Начало: 18
Заголовок: Действительно ли это серьезная проблема для пользователей?
Начало: 84
Заголовок: Прогресс в производительности JavaScript на Android со временем
Начало: 246
Заголовок: Разрыв в производительности сохраняется в последние годы
Начало: 261
Это требует некоторой итерации промптов, чтобы добавить немного стиля к этим заголовкам, но основная идея, похоже, реализуема.
Я наткнулся на эту ветку, исследуя ту же проблему, и был искренне удивлён, увидев, что здесь идея «популярности» («Hotness») уже была сформулирована ещё в 2014 году.
Сейчас 2026 год, а этой функции до сих пор нет. Однако сама проблема остаётся очень актуальной. Я регулярно сталкиваюсь с темами, где более 1000 сообщений, и поиск содержательного контента в них похож на поиск иголки в стоге сена. Кнопка «Суммировать» помогает, но показывает лишь то, что люди написали, а не то, где именно во временной шкале находятся интересные моменты.
Я потратил некоторое время на написание скрипта для визуализации этой концепции непосредственно на временной шкале. Он пока сырой, но демонстрирует мою идею: горизонтальные полосы, исходящие от трека временной шкалы, где длина полосы соответствует количеству реакций на сообщение. Клик по полосе сразу переносит вас к соответствующему сообщению.
В ходе этого эксперимента я столкнулся с несколькими практическими аспектами, которые стоит обсудить.
Порог и фильтрация: Не каждое сообщение с двумя реакциями заслуживает отдельной полосы. Я считаю полезным установить минимальный порог: либо как абсолютное число (например, не менее 10 реакций), либо как относительный процент (например, не менее 30% от максимального количества реакций в теме). Без фильтрации временная шкала становится зашумлённой. Кроме того, создание тепловой карты для тем с всего 10 сообщениями кажется излишним, поэтому логично добавить настройку минимального размера темы.
Перекрывающиеся полосы: Когда несколько сообщений с высокой вовлечённостью расположены близко друг к другу, их полосы перекрываются, и их становится трудно выбрать. Одно из решений, которое я придумал: при наведении на полосу пользователь может нажимать клавиши «Вверх»/«Вниз», чтобы перебирать перекрывающиеся полосы в этой позиции. Выбранная полоса будет подсвечиваться, а её всплывающая подсказка будет обновляться соответствующим образом.
В исходном обсуждении упоминались лайки, ответы, время чтения, закладки и внутренние/внешние ссылки. Мой скрипт использует только количество реакций, так как эти данные легко доступны. Однако взвешенный интегральный показатель мог бы дать лучшие результаты. Мне интересно, что команда исследовала с 2014 года в отношении внутреннего алгоритма определения «популярности».
Я искренне жду, когда эта концепция будет пересмотрена. Временная шкала уже является отличным инструментом навигации — добавление слоя «популярности» сделало бы её ещё более мощной для тех из нас, кто углубляется в долговременные темы.
На самом деле я уже пробовал реализовать это в TC, и хотя это работает достаточно хорошо (для версии V1), сам механизм работы таймлайна вызывает проблему.
Особенно в длинных постах удалённые темы приводят к рассинхронизации между тем, что показывает таймлайн, и реальным postID.
Как видно здесь, postID равен 425 (как в URL), но таймлайн отфильтровал удалённые посты и показывает, что мы находимся на посте 405.
В результате индикатор для этого поста с 39 лайками (который следует той же структуре, что и таймлайн), не соответствует правильной позиции.
Когда я прокручиваю вниз до таймлайн-postID 425, он (более или менее) верен, но, конечно, пост с 39 лайками уже не виден.
Так что, по сути, нужно было бы сделать сами столбики кликабельными, но это а) совершенно другая задача, и б) как уже говорилось выше, тогда у вас всё равно возникнет проблема перекрывающихся столбиков.
Для мега-тем плотность становится настолько высокой, что невозможно реалистично выделить горячие зоны, так как они оказываются зажаты между обычными постами. На этом этапе это скорее декоративный элемент, чем что-то другое 
Привет! Я бы хотел добавить здесь конкретный пример использования, который может помочь в проектировании.
Когда я имею дело с длинной веткой, я обычно не отвечаю на комментарии сразу, как их вижу, потому что часто на них уже ответили позже в этой же ветке.
Поэтому обычно я делаю первый проход, читая всё, и делаю мысленные заметки о том, на что хочу ответить.
Затем я делаю второй проход, пытаясь вернуться к тому, что запомнил, и комментирую это.
В настоящее время ползунок временной шкалы не очень помогает в этом, так как он позволяет переходить только к номеру поста. Пока я читаю, номера постов не очень заметны и определённо их трудно запомнить.
Поэтому для меня было бы очень полезно иметь возможность добавлять закладки «пост для ответа» во время первого чтения, а затем возвращаться к ним.
Также было бы полезно возвращаться к реакциям, а не только к закладкам. Тогда я могу использовать разные метки для разных постов и отвечать партиями: на втором проходе ответить на все позитивные комментарии «спасибо», на третьем — на одну проблему, упомянутую несколькими людьми, на четвёртом — на другую и так далее.
Итак, подводя итог: это в основном подчёркивает необходимость перехода между постами на основе моих собственных реакций и закладок, а не на основе общей тепловой карты ветки.
Один из приёмов, который я иногда использую в таких ситуациях, — это выделение и цитирование небольших фрагментов по ходу чтения, на которые я возможно захочу ответить.
Это сохраняет их в редакторе по мере чтения, а затем, читая дальше, я могу решить, какие фрагменты всё ещё актуальны, а какие нет. После этого я просто удаляю те, которые не важно включать. Иногда это вообще все фрагменты!
Так что это немного костыль, но всё же полезный совет.
