YouTube는 비디오 타임라인을 스크럽할 때 동영상 내의 핫스팟을 표시합니다:
보시는 것처럼, 조회수에는 고점과 저점이 있는데, @sam @eviltrout 님과 함께 이 부분을 반드시 달성하고 싶었습니다.
기존의 “이 주제 요약하기” 기능을 비디오로 이식해 보는 것도 흥미로운 사고 실험입니다. “30분짜리 영상을 볼 시간이 없으니, 그냥 가장 좋은 부분만 보여줘” 
5개의 좋아요
이 규칙은 조회수와 댓글 수가 많은 주제에 적용됩니다. 방금 게시된 텍스트를 자동으로 논리적인 부분으로 나누는 것은 불가능합니다.
게시물에 적용하는 것이 가장 쉽습니다. 사용자의 반응을 고려해 볼 가치가 있을 것입니다. 그러면 가장 유용하지 않은 게시글을 흐리게 표시하거나 완전히 숨겨서 스레드를 압축할 수 있습니다. 동일한 규칙을 첫 번째 메시지의 단락에도 적용할 수 있습니다.
첫 번째 게시물에서 가장 인기 있는 부분은 스레드에서 인용으로 사용된 단락입니다.
그 다음으로, 중요한 내용을 우연히 숨기지 않도록 주제 작성자가 사용한 태그와 이미지 캡션을 고려해 볼 가치가 있습니다.
더 적극적인 사용자 상호작용이 필요합니다. 주제의 내용이 사용자들에 의해 형성된다는 점을 알려 참여를 유도하세요. “자, 여러분의 의견이 반영되고 있으니 얼마나 멋진지 보세요!”
1개의 좋아요
네, 그래서 “이 주제 요약” 버튼은 주제가 50개 이상의 답변을 가진 경우에만 표시되는 것입니다… 그것은 항상 그렇게 작동해 왔습니다.
1개의 좋아요
다른 포럼에서 사용자들과 페이지네이션과 무한 스크롤에 대해 논의해 본 결과, 무한 스크롤에서 사용자가 실제로 그리워하는 것은 엄밀히 말해 페이지네이션이 아니라 일종의 브레이크포인트(중단점)라고 추측됩니다. 이에 대해 디스코urs 개발팀이 이러한 브레이크포인트 아이디어에 대해 진전을 이뤘는지 궁금합니다.
4개의 좋아요
이 “타임라인 인기” 기능이 실제로 얼마나 유용한지 정말 인상적입니다. 솔직히 팟캐스트, 긴 글, 긴 대화 등 거의 모든 상황에서 훌륭합니다. 사람들이 실제로 읽고, 듣고, 보고 있는 _구체적인 부분_을 보여주세요.
이 주제 요약은 토픽의 맨 위에 있습니다. 따라서 토픽의 맨 위에서 진입하여 아래로 스크롤할 때, “핵심 내용만” 볼 수 있는 옵션이 제공됩니다. 사용자가 주로 토픽의 맨 위에서 진입할 것이라는 가정은 다소 전제에 가깝지만, 꽤 안전한 추측이라고 생각합니다. 하지만..
긴 토픽의 깊은 곳으로 딥링크되어 맨 아래, 또는 긴 대화의 중간 어딘가에 도착할 때(어떤 방식으로든) “요약” 기능을 홍보하고(켜도록 제안하고) 이를 제공하는 것이 합리적이지 않을까 궁금합니다.
4개의 좋아요
브레이크포인트(특히 특정 게시물이 특히 인기 있는 게시물이거나, 많은 답글이 달린 게시물인 경우)로 사용자를 유도하거나 집중하도록 장려하는 데에는 작은 문제가 있다고 생각합니다.
이로 인해 다른 흥미로운 콘텐츠를 놓칠 수 있습니다. 사람들은 '최고’로 선정된 토론 콘텐츠로만 향하게 되고, 이는 눈덩이 효과를 일으킵니다. 사용자에게 표시되는 선정된 게시물들을 보고 좋아요를 누르게 되며, 표시되지 않은 다른 게시물들은 무시됩니다.
스크린샷에서 볼 수 있듯이, '가장 많이 본 부분’의 대부분은 챕터와 연결되어 있습니다. 그러나 챕터가 없거나 적은 동영상의 경우에도 챕터 마커 밖에서 '가장 많이 본 부분’이 존재합니다:
저도 이 기능을 사용하여 제가 보고 싶은 부분으로 자연스럽게 이동할 수 있다고 생각합니다. 대부분의 경우 그럴 수 있겠죠. 하지만 실제 동영상을 전부(빠른 재생을 사용하더라도) 보지 않고서는 어떻게 알 수 있을까요?
이것을 생각하면 리디트의 업보트 시스템이 떠오릅니다. 가장 많은 업보트를 받은 게시물은 기본적으로 답글 목록 상단에 위치하기 때문에 가장 많은 업보트를 받을 가능성이 높습니다. 역시 눈덩이 효과입니다. 리디트에서 잘못된 정보를 담고 있는 상위 댓글을 정말 많이 봤습니다.
사용자로써, 만약 그걸 정정하고 싶다면 메시지를 작성합니다… 하지만 업보트 0개의 메시지는 XX개나 XXX개의 댓글 아래 바닥에 놓이게 되어 아무도 읽지 않을 것입니다. 저에게도 이런 일이 너무 자주 일어나서 더 이상 시도하지 않습니다.
이 주제에 정말 관심이 많습니다. 매우, 매우 흥미로운 주제입니다.
3개의 좋아요
Discourse와의 잠재적인 AI 통합에 대해 생각하다가 이 주제가 떠올라서, 간단히 시도해 보았습니다:
Can Discourse ship frequent Docker images that do not need to be bootstrapped?
제목: Sam의 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
제목: 채팅 vs 포럼 기능
시작: 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
제목: Android의 JavaScript 성능이 iOS에 비해 크게 뒤처짐
시작: 1
제목: Android 성능이 저조한 이유 살펴보기
시작: 39
제목: Android 경험 개선을 위한 대안 탐색
시작: 18
제목: 이것이 사용자에게 정말로 큰 문제인가?
시작: 84
제목: 시간에 따른 Android JavaScript 성능의 발전
시작: 246
제목: 최근 몇 년간 여전히 존재하는 성능 격차
시작: 261
제목에 좀 더 맛을 부여하려면 프롬프트 반복이 필요하지만, 아이디어의 핵심은 작동 가능해 보입니다.
9개의 좋아요
같은 문제를 조사하다가 이 스레드를 우연히 발견했는데, 2014년에 이미 here가 “Hotness(인기도)” 개념을 언급하고 있었다는 사실에 정말 놀랐습니다.
지금은 2026년인데도 이 기능이 여전히 존재하지 않습니다. 하지만 그 문제 자체는 여전히 매우 큽니다. 1000개 이상의 게시글이 있는 토픽에서 의미 있는 콘텐츠를 찾는 것은 바늘을 찾듯 어렵습니다. “요약” 버튼은 도움이 되지만, 사람들이 무엇을 말했는지만 보여줄 뿐, 흥미로운 순간들이 타임라인에서 어디에 위치해 있는지까지는 알려주지 않습니다.
이 개념을 타임라인에 직접 시각화하기 위해 스크립트를 만들어 보았습니다. 아직 거칠지만, 제 아이디어를 보여줍니다. 타임라인 트랙에서 수평으로 뻗어나가는 막대 그래프의 길이는 각 게시글의 반응 수를 나타냅니다. 막대를 클릭하면 해당 게시글로 바로 이동합니다.
이 실험을 통해 논의할 가치가 있는 몇 가지 실무적인 고려 사항을 발견했습니다.
임계값 및 필터링: 반응이 2개 있는 모든 게시글에 막대를 표시할 필요는 없습니다. 최소 임계값을 설정하는 것이 유용하다고 생각합니다. 절대 숫자(예: 최소 10개 반응)나 상대적 백분율(예: 해당 토픽에서 가장 많은 반응을 받은 게시글의 최소 30%)로 설정할 수 있습니다. 필터링이 없으면 타임라인이 노이즈로 가득 차게 됩니다. 또한 게시글이 단 10개뿐인 토픽에 히트맵을 생성하는 것은 불필요해 보이므로, 최소 토픽 크기 설정이 의미 있을 것입니다.
겹치는 막대: 여러 개의 높은 참여도 게시글이 한곳에 몰려 있으면 막대들이 겹쳐서 선택하기가 어려워집니다. 제가 생각한 해결책 중 하나는 다음과 같습니다. 막대에 마우스를 올리면 사용자가 위/아래 화살표 키를 눌러 해당 위치의 겹친 막대 사이를 순환할 수 있게 하는 것입니다. 현재 포커스가 맞춰진 막대는 강조 표시되고, 그 툴팁도 그에 따라 업데이트됩니다.
원래 토론에서는 좋아요, 답글, 읽는 시간, 북마크, 내부/외부 링크가 언급되었습니다. 제 스크립트는 데이터 접근이 용이하기 때문에 반응 수만 사용하고 있습니다. 하지만 가중 합성 점수를 사용하면 더 나은 결과를 얻을 수 있을 것입니다. 2014년 이후 팀이 내부 인기도 알고리즘에 대해 어떤 것을 탐구해 왔는지 궁금합니다.
이 개념이 다시 다뤄지는 것을 진심으로 기대하고 있습니다. 타임라인은 이미 훌륭한 탐색 도구입니다. 인기도 계층을 추가하면 긴 기간 동안 이어지는 토픽에 깊이 파고드는 우리에게 더 강력한 도구가 될 것입니다.
6개의 좋아요
사실 TC에서 직접 시도해 봤는데, 잘 동작하긴 합니다(버전 1 수준으로는 충분히). 하지만 타임라인 자체의 작동 방식 때문에 문제가 발생합니다.
특히 긴 게시물에서 삭제된 주제는 타임라인에 표시되는 것과 실제 postID 사이의 불일치를 유발합니다.
여기서 보시다시피 postID는 425입니다(URL에 표시된 것과 동일) 하지만, 타임라인은 삭제된 게시물을 필터링하여 현재 405번째 게시물에 있다고 표시하고 있습니다.
그 결과, 39개의 좋아요를 받은 이 게시물(타임라인과 동일한 구조를 따름)의 지표가 올바른 위치와 일치하지 않습니다.
타임라인-postid 425까지 아래로 스크롤하면 (대략) 정확하지만, 당연히 39개의 좋아요를 받은 게시물은 화면에서 벗어나 있습니다.
따라서 거의 막대 자체를 클릭 가능하게 만들어야 하는데, 이는 a) 완전히 별개의 작업이고, b) 위에서 언급했듯이 어쨌든 막대가 겹치는 문제가 발생하기 때문입니다.
메가토픽(megatopic)의 경우, 밀도가 너무 높아 일반 게시물 사이에 끼인 상태의 열기 영역을 현실적으로 타겟팅할 수 없습니다. 그 시점에는 장식적인 역할에 그칩니다 
5개의 좋아요
안녕하세요, 디자인에 도움이 될 수 있도록 구체적인 사용 사례를 하나 추가하고 싶습니다.
긴 스레드를 다룰 때, 댓글을 보았을 때 바로 답글을 남기지 않는 편입니다. 나중에 스레드 후반부에서 이미 답변이 달렸을 가능성이 크기 때문입니다.
보통 처음에는 전체를 훑어보면서 답글을 달고 싶은 내용에 대해 머릿속으로 메모를 합니다.
그 다음 두 번째로 읽을 때, 기억한 내용으로 돌아가서 답글을 달려고 합니다.
현재 타임라인 슬라이더는 이 작업을 돕지 못합니다. 게시글 번호로만 이동할 수 있기 때문입니다. 글을 읽는 동안 게시글 번호는 잘 보이지 않고, 기억하기도 어렵습니다.
따라서 저에게는 첫 번째로 읽을 때 "답글을 달 게시글"을 북마크하고, 나중에 그곳으로 바로 돌아갈 수 있으면 매우 유용할 것입니다.
북마크뿐만 아니라 내 반응(리액션)으로 돌아가는 기능도 유용할 것입니다. 이렇게 하면 다른 게시글에 대해 다른 표시를 할 수 있고, 배치별로 답글을 달 수 있습니다. 두 번째로 읽을 때 모든 긍정적 댓글에 "감사합니다"라고 답하고, 세 번째로 여러 사람이 언급한 한 가지 문제에 답하고, 네 번째로 다른 문제에 답하는 식으로 진행할 수 있습니다.
요약하자면, 이는 스레드의 일반적인 히트맵이 아닌, 제 자신의 반응과 북마크를 기준으로 게시글 사이를 이동할 필요가 있음을 강조합니다.
1개의 좋아요
저는 이런 상황에서 때때로, 나중에 답장하고 싶을 수도 있는 작은 부분을 강조하고 인용합니다.
이렇게 하면 작성 창에 내용이 저장되어 두고, 더 읽어가면서 어떤 부분이 여전히 관련이 있는지 판단할 수 있습니다. 그리고 포함할 필요가 없는 부분은 그냥 삭제하면 됩니다. 때로는 모든 부분이 해당될 수도 있습니다!
그러니 이건 약간 해킹적인 방법이지만, 여전히 유용한 팁일 수 있습니다.
2개의 좋아요