안녕하세요, 저는 Discourse의 팬이며, vBulletin5에서 이전하는 것에 대해 논의 중인 작은 커뮤니티에 속해 있습니다. 한 사용자가 “Ctrl+f 을 해킹하는 것은 _악”_이라고 하며 Discourse에 반대했는데, 그 의미를 보고 나니 저도 동의하게 되었습니다. Discourse가 현재 Ctrl+f를 처리하는 방식에는 심각한 사용성 문제가 있습니다. Ctrl+f는 브라우저에서 "이 페이지 내에서 텍스트 찾기"를 위한 단축키입니다.
문제점
- 때로는 Ctrl+f가 정상적으로 작동하며, Discourse가 브라우저의 내장 찾기 기능을 사용하여 사용자가 입력하는 즉시 페이지가 첫 번째 검색 결과로 스크롤됩니다. Ctrl+G를 누르면 다음 결과로 이동합니다.
- 이런 때는 좋습니다.
- 때로는 Ctrl+f가 작동하지 않고, 대신 데이터베이스 검색 결과가 목록으로 표시됩니다.
- 사용자가 입력하는 동안 페이지가 첫 번째 결과로 스크롤되지 않습니다.
- 검색어가 이미 화면에 있는 경우에만 하이라이트됩니다.
- "UX"와 같이 너무 짧은 용어는 검색할 수 없습니다.
- Ctrl+g를 눌러 다음 결과로 이동할 수 없습니다.
- 페이지에서 해당 용어를 찾지 못했을 경우 Ctrl+f가 표시하지 않았을 무관한 토픽의 결과까지 표시합니다.
- 이 문제가 발생하는 이유는 사용자에게 전혀 보이지 않지만, 사용자에게는 매우 짜증스럽습니다. 아무 설명 없이 페이지 내 검색 기능이 사라진 것 같다고 느낍니다.
- 실제로 존재하는 게시글을 찾지 못할 수 있으므로, Ctrl+f를 두 번 누르면 브라우저 검색이 실행된다고 안내하는 것도 도움이 되지 않습니다.
근본 원인
이것은 미관상의 문제가 아니라, Discourse가 근본적으로 해결해야 하는 심각한 사용성 문제입니다. 전체 대화가 실제로 브라우저의 DOM에 존재하는 것처럼 보이는 환상이 그것인데, 실제로는 동적으로 로드됩니다.
토픽에 게시글이 20개를 초과하면, Discourse는 필요한 경우에만 게시글을 브라우저로 전송합니다. 대부분의 DOM이 비어 있는 스텁에 불과하므로, 서버에 거의 부하를 주지 않고 1,000개 이상의 게시글이 있는 스레드를 볼 수 있습니다. 이는 훌륭한 아이디어이지만, 동시에 Ctrl+f가 신비롭게 깨지는 원인이기도 합니다.
저는 이 환상을 없애자는 제안을 하지 않습니다. Discourse가 대상을 임의의 페이지로 나누어 각 페이지에 약 40개의 게시글씩 표시하던 기존 방식을 폐기한 것은 옳았다고 생각하기 때문입니다.
Discourse는 그저 이 환상을 더 완벽하게 만들어야 합니다.
해결책
솔직히 말해, 제가 이 문제의 최선의 해결책을 알고 있지는 않지만, 도움이 될 수 있기를 바라는 몇 가지 생각이 있습니다.
환상을 의도적으로 깨기
먼저, Discourse가 데이터베이스 검색으로 전환하여 환상을 깨기로 한다면 합리적인 몇 가지 간단한 아이디어가 있습니다.
- 사용자에게 무슨 일이 일어나고 있는지 알려주세요. 브라우저의 찾기 상자가 보통 나타나는 위치에 사과와 설명이 담긴 작은 메모를 두세요.
- “죄송합니다. 이 토픽에는 1002개의 게시글이 있지만, 브라우저에는 그중 7개만 로드되어 있으므로 페이지 내 찾기 기능이 작동하지 않을 수 있습니다. 그래도 시도해 보시려면 Ctrl+f를 다시 누르세요.”
- 사용자에게 일부 제어권을 주세요. 사용자가 Ctrl+f를 누르면, 사용자가 토픽의 모든 게시글 텍스트를 DOM에 수동으로 로드할 수 있는 버튼을 표시하세요.
- 만약 브라우저에 한 번에 캐시되는 100개 게시글 제한으로 인해 이것이 불가능하다고 판단되면, 사용자가 토픽을 페이지 단위로 나누어 보는 기존 방식으로 되돌아갈 수 있는 버튼을 표시하세요.
- “여기를 클릭하여 Ctrl+f와 호환되는 방식으로 이 토픽을 보기: [1 페이지] [2] [3] [4] [5] [6] [7] [8] [9] […] [>>]”
- 기본 절단점을 20개 게시글에서 100개 게시글로 늘리세요. Discourse가 이미 DOM에 그 정도 양의 게시글을 캐시할 수 있으므로 변경하기가 너무 어렵지 않을 수 있습니다.
환상 수리
물론, 이러한 아이디어들은 추상적이며, 저는 이것들을 임시 조치로 생각합니다. 궁극적으로 최선의 해결책은 Discourse가 사람들이 기대하는 방식으로 작동하는 Ctrl+f를 구현하는 것입니다. 브라우저가 인터랙티브 검색을 위해 하는 것을 Discourse에서 재현하는 것은 매우 가치가 있을 것이라 생각하지만, 어렵지 않을까 싶습니다.
그러나 (상대적으로) 간단한 해결책이 있을 수 있습니다.
DOM에서 텍스트를 제거하지 않기
Discourse에 대한 최선의 해결책은 게시글에서 미디어 객체만 제거하고 텍스트는 제거하지 않는 것이라고 생각합니다. 그러면 "Ctrl+f를 해킹"하여 데이터베이스 검색으로 대체할 필요가 없어집니다.
페이지 내 찾기는 텍스트만 검색하므로, 검색을 위해 브라우저가 전체 DOM을 로드할 필요가 없습니다. 텍스트는 전송하기에 매우 가볍습니다. 특히 HTTP 서버에 gzip 압축이 켜져 있다면 더욱 그렇습니다. 텍스트는 웹 브라우저에서 많은 메모리도 차지하지 않습니다.
여러분이 저보다 더 잘 아시겠지만, 몇 가지 추측을 해 보겠습니다:
- 평균 게시글 크기: 텍스트 5 KiB
- 평균 토픽 길이: 50개의 답변.
- 전송할 평균 텍스트: 250 KiB로, 이는 합리적입니다.
물론 반응성 측면에서 모든 바이트가 중요합니다. 만약 제 추정치가 틀리고 텍스트 크기가 문제가 된다면, 페이지의 중요한 부분이 전송된 후에 배경 프로세스로 DOM에 텍스트를 채우는 방식을 사용할 수 있습니다. 사용자가 Ctrl+f를 누르는 시점에 DOM이 텍스트로 완전히 채워지지 않았다면, 사용자가 대기해야 한다는 것을 알리고 텍스트가 들어오는 진행 상황을 보여주는 미터가 나타날 수 있습니다.
감사드립니다
Ctrl+f가 Discourse가 만든 환상을 깨뜨리는 것은 심각한 문제이지만, Discourse 개발자들이 처음부터 그 환상을 만들어낸 놀라운 작업에 깊은 인상을 받았습니다. 그들은 결국 이 문제의 올바른 해결책도 찾을 것이라고 확신합니다.
제안 사항을 검토해 주셔서 감사합니다.
존경하여,
Mx. F.N.