현재 이러한 이유는 대부분 언어화되지 않은 패러다임에 기반하고 있습니다. 이는 직관과 고객과의 대화의 결과물입니다. 이러한 전략은 대부분 회귀(regression)나 고객 이탈과 같은 재앙을 피할 수 있게 해줍니다. 하지만 한계가 있습니다. 진전을 측정할 수 있는 명확한 척도가 없습니다. 따라서 "이 변경 사항에 대해 사용자가 몇 명 불만을 제기했거나 칭찬했는가?"와 "성능 향상과 같은 2차 목표를 달성했는가?"와 같은 실용적인 KPI가 변경 사항의 성패를 결정하게 됩니다.
문제는 잠재적 사용자와 잠재적 고객은 불만을 제기할 수 없다는 점입니다.
사용자 인터페이스는 언어와 같습니다. 이 언어를 이해하는 우리의 능력은 우리가 사회화된 문화에 영향을 받습니다. 사용자 인터페이스를 만드는 동안 우리가 사용하는 근본적인 패러다임을 언어화하지 않으면, 우리의 문화를 이러한 시스템에 내재화하게 됩니다. 이는 우리와 같은 사람들에게는 사용하기 쉽지만, 일반적으로는 그렇지 않을 수 있음을 의미합니다.
추상적인 관점에서 디자인 시스템이 가져올 수 있는 이점:
일관된 외관과 상호작용은 사용자에게 친숙함을 유지하여 학습 난이도, 인지 및 운영 비용을 줄이고 업무 효율성을 향상시킬 수 있습니다. source
사용자 인터페이스 컴포넌트의 명확하게 정의된 범주가 있었다면, “데이터 표시” 컴포넌트와 사용자 동작(예: 버튼 사용) 사이의 혼동은 발생하지 않았을 것입니다. 모든 다른 UI 컴포넌트와 그 용도가 나열된 이와 같은 페이지가 있었다면 합리적인 논의가 가능했을 것입니다. 또한 이러한 논의가 공개적으로 이루어지고 git 커밋 메시지로만 전달되지 않는 것이 좋을 것입니다.
비슷한 힌트를 추가했지만, 플레이스홀더에는 넣지 않았습니다. Discourse가 번역된 모든 언어를 고려할 때, 플레이스홀더에 긴 문자열을 넣으면 잘릴 위험이 있습니다. 게다가 사용자가 입력을 시작하면 플레이스홀더는 사라지죠. 대신 모든 주제/게시물 검색 행에 우측 정렬된 힌트를 사용했습니다:
요즘 메타에서 주제 내 검색 기능을 사용해 본 결과, 뭔가 이상하게 깨져 있는 것 같습니다.
웹 페이지 내에서 검색을 하려면 저는 Ctrl+F를 누르고, 검색어를 입력한 뒤 Enter를 누르는 방식으로 훈련되어 있습니다. 긴 주제에서 Discourse가 이 기능을 가로채거나 강화해야 하는 이유는 이해합니다.
하지만 현재 메타에서 Ctrl+F를 누르고 검색창에 'theme’를 입력하면 다음과 같은 일이 발생합니다:
사용자 목록이 표시됩니다(무슨 일이죠?) 또는 태그가 표시됩니다(이건 유용하긴 하네요)
Enter를 누르면 다른 주제 목록이 표시됩니다(무슨 일이죠? 저는 주제 내에서 검색하려고 하는 건데요)
"더 보기"를 누르면 주제 컨텍스트를 완전히 잃어버립니다
제 결론은 이렇습니다: 웹에서 페이지 내 검색이 작동하는 방식에 대해 사용자가 훈련된 기대를 완전히 무시하고 있습니다.
제안 사항:
(1) 사용자가 Ctrl+F로 검색을 트리거했다면, 기본적으로 주제 내 검색으로 설정하십시오. 반면, 다른 글로벌 내비게이션과 동일한 방식으로 검색이 트리거된 경우(예: 검색창 클릭 등)에는 전체 주제 검색을 기본값으로 유지하십시오.
(2) 기본적으로 사용자를 표시하지 마십시오. 대부분의 사용자는 주제를 검색하기 때문입니다.
솔직히 이 작은 문제를 해결하려고 망치(과도한 조치)를 사용한 이유가 궁금합니다. 문자별 검색의 성능 영향은 검색 트리거 전에 500ms의 지연 시간을 두면 처리할 수 있을 거라고 생각했습니다.
저도 같은 느낌을 받습니다. 다만 팀이 이 변경 사항에 대해 제시한 이유와 논리를 이해하고 있으며, 이 변경이 다른 중요한 이점도 가지고 있다는 점도 인지하고 있습니다. 따라서 결국 올바르게 구현하는 문제인 것 같고,hopefully 새로운 디자인에 대한 추가적인 개선이 이루어지기를 바랍니다. 안타깝게도 현재로서는 구체적인 개선 아이디어가 없어서 주제를 열지 않았습니다…
그럼에도 불구하고, 저는 같은 생각을 했습니다:
팀이 반드시 답변할 의무는 없지만, 그럼에도 불구하고 답변해 주기를 바랍니다. 다만, 이 주제를 따로 열 필요까지는 없어 보입니다.