Ctrl + Alt + F(또는 /, 효과는 동일합니다.)를 사용하셨기 때문에, 이를 대체할 기본 브라우저 키 바인딩이 없습니다. 이와 같은 더 큰 주제에서 일반적인 Ctrl + F를 사용해 보세요.
2개의 좋아요
감사합니다. 그게 원인이었던 것 같습니다. Chromebook에서 왜 ctrl-alt-f인지 아시는 분 계신가요? 그게 표준 키 조합인가요, 아니면 그 플랫폼에서 오버라이드가 불가능한 건가요?
가능하다면 Discourse가 모든 플랫폼에서 일관성을 갖도록 하는 게 좋을 것 같은데, 왜 그렇지 않은지 궁금합니다.
보통은 alt 키도 함께 눌려요. 예를 들어 저는 윈도우를 사용하거든요. 여기 어딘가에 호환성 관련해서 뭔가가 있는 것 같습니다.
해당 사용자들도 control-f를 사용하여 현재 URL에서 검색하기를 기대합니다. 하지만 브라우저는 현재 로드된 게시물이 20개뿐이므로 이를 수행할 수 없습니다. 그리고 팝업은 브라우저 기능을 사용하려면 control-f를 다시 입력하면 된다고 설명합니다.
현재 주제 내의 모든 게시물을 검색할 수 있도록 하는 더 직관적인 방법이 있을까요?
2개의 좋아요
이 사건의 놀라운 아이러니.
- 이 게시글에 대한 이메일 업데이트를 확인함.
- 링크를 클릭하고 읽기 시작함. 다음 문구를 보게 됨:
당신이 기대하는 것은 해당 주제에서 원하는 게시글을 찾기 위해 Ctrl-F를 사용하는 것일 것 같지만, 그것이 당신이 원하는 것은 아닙니다. '브라우저가 찾지 못해도 이 주제에서 게시글을 찾으라'는 키는 무엇입니까? 현재 주제에서 게시글을 찾지 못하는 것이 기대에 어긋나는 것 아닙니까? - 답글을 쓰려다 로그인되어 있지 않다는 것을 깨닫고, 텍스트를 선택하여 복사함 (로그인 후 검색/찾기하기 위해)
- 화면 오른쪽 상단의 로그인을 클릭하고 로그인 절차를 완료함
- 게시글로 리다이렉트되었지만, 스레드의 맨 위에 위치해 있었음.
- Cmd-F를 누름
- Cmd-V를 누름
- Enter를 누름
- 아무것도 찾지 못함
솔직히, 이건 만들어낸 이야기처럼 들립니다. 이 기능의 본질은 '아직 페이지에 없는 것’을 찾는 것인데, 그게 작동하지 않는다고요?
그리고 실제 댓글에 대한 답변:
아니요, 기대에 어긋나는 것이 아닙니다. Cmd-F의 기대치는 페이지에 없으면 아무것도 찾지 않는다는 것입니다. Cmd-F는 인터넷 전체에서 '이 게시글’을 검색하는 것이 아닙니다. 그것은 당신이 무중생적으로 만들어낸 것입니다. 해당 항목이 페이지에 없으면 아무것도 찾지 않는 것입니다. 그것이 정상입니다.
부록 #1:
무언가를 찾았을 때조차, 완전히 새로운 패러다임을 배우지 않고는 결과를 탐색할 수 없습니다. (아니요, 위/아래/Enter가 그렇게 어려운 것은 아닙니다 - 하지만 그것은 다르며 discourse 사이트에만 독특한 것입니다.) 또한 인터넷의 다른 곳에서는 여러 번 Cmd-F를 눌러 찾은 결과를 순환할 수 있지만, 여기서는 그렇게 할 수 없습니다.
부록 #2:
구축하신 Cmd-F 기능에는 네이티브 기능이 가지고 있지 않는 다양한 제한 사항이 있습니다. '검색어가 너무 짧습니다.'가 그중 하나입니다. 관련이 있으므로 /로 이 게시글을 검색해 보려 했지만, 그렇게 할 수 없었습니다.
부록 #3:
이 모든 것의 이유가 일부 게시글이 정말로, 정말로, 정말로 커서 페이지에 로드할 수 없다는 것이라고 보는 것은 큰 무리인 것 같습니다. 스택의 모든 레이어에서 캐싱을 위한 다양한 옵션이 있는 오늘날의 인터넷 환경에서는 이를 받아들이기 어렵습니다. 어쩌면 해결할 가치가 있는 '버그’는 그것일까요?
1개의 좋아요
제가 100% 이해한 것 같지는 않은데요? 두 번 누르는 것에는 어떤 문제가 있나요? 그렇게 하면 원하시는 대로 작동하지 않나요?
1개의 좋아요
cmd-f를 두 번 누르는 동안 링크를 세 번 클릭하는 것도 시작해야 하나요? 그걸 구현해야 하나요?
여기서 핵심을 얼마나 엉망으로 놓치고 있는지 꽤나 충격적입니다. 브라우저의 기본 동작 방식을 변경한 것입니다. 이건 완전히 예상 밖의 일입니다.
3개의 좋아요
동의합니다. 제 기대는 페이지 내에서 찾는 것입니다. 이 하이재킹은 ctrl-g ctrl-shift-g 동작도 깨뜨립니다.
Discourse가 모든 게시물이 로드된다는 사용자 기대를 깨뜨리기 때문에 이를 오버라이드하고 싶을 수 있다는 점은 이해할 수 있습니다. 그러나 이는 정확히 어떤 게시물이 로드되었는지 또는 그렇지 않은지를 표시함으로써 해결할 수 있을 것입니다. 기존의 페이지네이션 방식은 이 점에서 투명합니다.
게시물 스레드 검색 도구가 유용한 것은 물론입니다. 페이지네이션 방식이든 무한 스크롤 방식이든 마찬가지입니다. 문제는 하나의 검색 방식을 다른 검색 방식으로 하이재킹하는 것이, 예를 들어 ‘스레드 검색’ 버튼이나 표준 동작과 충돌하지 않는 핫키를 통해 다른 방식으로 노출하는 것보다 어색하고 혼란스럽다는 점입니다.
설계 결정은 이해할 수 있고 저도 이에 익숙해졌기 때문에 너무 불평하고 싶지는 않습니다. 다만 '기대 위반’이라는 전제가 올바르지 않다고 생각한다는 점을 지적하고 싶었을 뿐입니다.
검색하는 사용자를 위해 균형을 맞춰야 하는 예상치 못한 요소들이 복합적으로 작용합니다… 일종의 '어느 쪽을 선택하느냐’의 문제입니다.
-
성능상의 이유로 스크롤할 때 모든 콘텐츠가 로드되지 않습니다. Discourse는 GIF, 동영상, 투표, 캘린더, iframe, 차트 등 다양한 콘텐츠를 지원하며, 하나의 주제에 이러한 요소가 1,000개 이상 있을 수 있습니다. 이 모든 것을 DOM에 유지하면 페이지를 사용할 수 없게 만들 수 있습니다.
-
사용자가 현재 어떤 콘텐츠가 로드되어 있는지 알 수 없어
ctrl + f의 효율성이 떨어집니다. 이 기대는 모든 콘텐츠가 같은 "페이지"에 있으므로 검색할 수 있다는 전제를 깔고 있습니다.
ctrl + f가 전체 페이지를 검색한다는 기대와 달리, 전체 페이지가 이용 가능하지 않은 상황… 그래서 일종의 절충안이 시도되고 있습니다.
이미 이 문제를 해결하기 위해 몇 가지 주장을 제기하셨습니다:
-
게시물의 동적 콘텐츠(이미지 포함)를 비활성화합니다.
이는 불가능합니다 — 동적 콘텐츠를 허용하는 경쟁사(Facebook, Discord, NodeBB, Khoros, Higher Logic 등, 경쟁사는 얼마든지 있습니다) 중 하나를 선택하는 순간, 우리는 하룻밤 사이에 모든 고객을 잃게 될 것입니다.
-
무한 스크롤을 비활성화하고 전통적인 페이지네이션을 사용합니다.
더 가능성이 높아 보이지만, 이것이 정말 이 문제를 해결합니까? 페이지당 로드되는 게시물의 수를 제한하여 브라우저 부하를 줄이고, 사용자는 계속 읽으려면 수동으로 페이지를 넘겨야 합니다.
이제
ctrl + f가 예상대로 작동하지만, 실제로는 기억력만큼만 잘 작동합니다.10페이지에 걸쳐 100개의 게시물을 읽은 후 방금 읽은 내용을 찾으려 할 때… 2페이지인가요? 3페이지인가요? 제 기억력은 그렇게까지 좋지 않습니다.
결국 다음과 같은 행동을 하게 될 가능성이 높습니다…
ctrl + f… 뒤로ctrl + f… 뒤로ctrl + f…?
제 생각에는 브라우저 기본 설정을 따르더라도, 여기서 완벽한 단일 사용자 경험은 존재하지 않는 것 같습니다. Discourse에서 브라우저 기본 설정의 부재가 마음에 들지 않는다면, 알아야 할 것은 딱 하나입니다.
8개의 좋아요
친근한 알림입니다. 모든 게시물과 토론은 문명적이고 생산적으로 유지되도록 노력해 주십시오. 논쟁이 너무 격해지거나 단순화되는 경우 이 주제를 닫을 예정입니다. 
7개의 좋아요
이 점에 대해 누구도 부정하지 않습니다. 다만 cmd-f를 억지로 가져다 쓰지는 마세요. 다른 키 조합을 선택할 수 있는 옵션이 셀 수 없이 많습니다. 그중 아무거나 골라 쓰면 됩니다.
3개의 좋아요
맞아요, 다만 핵심은 자동 페이지 전환 때문에 ctrl + f이 의도대로 작동하지 않는다는 점입니다. 그래서 대안으로 제안된 방식이 먼저 언급되는 이유는 실제로 주제 내의 모든 내용을 검색할 수 있기 때문이죠.
그러므로 모든 트레이드오프를 고려할 때, 다음 중 하나를 설명하는 것이 될 것입니다:
- 스크롤하던 중 페이지가 자동으로 전환되었기 때문에 검색이 작동하지 않았습니다. 따라서
버튼을 클릭하세요 (또는 대안 단축키인 /를 사용하세요) - 내장 검색을 사용하는 것이 더 나을 수 있습니다. 그렇지 않으면 다시 단축키를 사용하세요
만약 ctrl + f를 가로채지 않아 스크롤 중에 일부 콘텐츠가 로드/해제되면서 작동하지 않았다면, 여러분도 똑같이 짜증이 날까요? 그런 경우 해결책으로 앱 내 검색을 시도할까요? 위로 스크롤한 뒤 다시 시도할까요? 아니면 다른 방법을 시도할까요?
“기본값이니까 하지 마라”(기대치 때문에 유효한 논거) 외에도, 이를 반대하는 추가 논거들을 고려해 볼 가치가 있을 수 있습니다:
-
대부분의 사람들은 아마도
ctrl + f를 사용하지 않을 것입니다: Crazy: 90 Percent of People Don't Know How to Use CTRL+F - The Atlantic
(아마도 80% 정도일 수도 있습니다 Do 90% of People Not Use CTRL+F? | Blog of Metrics) -
ctrl + f로 20개 이상의 이전 게시물을 검색하는 경우는 꽤 드물지 않을까요? 그렇다면 현재 "페이지"에 대해ctrl + f를 사용하는 것만으로도 충분할 수 있습니다? (완전한 추측이며, 관련 데이터를 찾지 못했습니다)
7개의 좋아요
- 이 오버라이딩은 Discourse에만 해당되는 문제가 아닙니다. 언급된 다른 곳들 중에서도 Microsoft Office 도구 역시 Ctrl+F를 오버라이딩합니다. 그리고 그 이유는 비슷합니다(즉, 모든 텍스트가 Ctrl+F에서 사용할 수 있는 것이 아니기 때문이죠).
- 실제 기능/의도가 덮어쓰기(overwrite)되는 것은 아닙니다. 이는 “서브스트링 찾기” 기능입니다. 만약 Ctrl+F가 북마크 명령으로 오버라이딩되었다면, 저는 그 입장에 공감했을 것입니다.
- 브라우저의 단순한 Ctrl+F 기능은 왜 실패했는지에 대한 표시 없이 자주 실패합니다. 텍스트가 검색되지 않으면 그 텍스트가 주제에 존재하지 않는다고 쉽게 추론할 수 있지만, 이는 반드시 사실일 guarantee가 없습니다. 매우 짧은 주제가 아니라면, 대부분의 검색은 오탐(false negative)이 될 것입니다. 사용자가 Ctrl+F를 효과적으로 사용하려면 Discourse의 인피니트 스크롤 구현 세부 사항에 대한 이해를 요구하게 됩니다.
- 이 오버라이딩을 싫어하고 게시물의 페이지네이션이 어떻게 작동하는지 이해하는 사람들을 위해, 단순히 한 번 더 누르면 됩니다.
여기서 주된 문제가 사용자의 기대를 깨고 싶지 않다는 것이라면, 궁극적으로 저는 암호화된 방식으로 기대를 깨는 것(즉, 텍스트가 실제로 주제에 나타나는데도 Ctrl+F가 "일치 없음"을 표시하는 경우)이 투명하게 기대를 깨는 것(네이티브가 아닌 검색 바를 여는 경우)보다 더 큰 악이라고 말하겠습니다.
현재와 같은 방식을 유지하세요.
8개의 좋아요
여기 문화를 문명적으로 유지하려는 의도는 이해합니다. 저도 그것을 지지하지만, 대신 사용자를 조정해 주시기를 부탁드립니다. 주제를 닫으면 커뮤니티 전체에 영향을 미칩니다. 우리는 분명히 이 주제에 대해 논의하고 싶어 합니다.
말씀하신 내용을 이해했습니다. 검색 기능은 두 가지 목적을 수행해야 합니다. 토픽이나 스레드를 검색하는 것과, 특정 토픽이나 스레드 내부에서 키워드를 검색하는 것입니다.
저는 '토픽’과 '스레드’를 혼용해서 사용하고 있지만, 의미는 명확히 전달되고 있기를 바랍니다.