툴팁 첫 호버는 200ms 지연하고, 닫은 뒤 300ms 안의 다음 호버는 즉시 표시하는 패턴

20년 전 호버 드롭다운 메뉴 만들 때 똑같은 문제를 겪었음. JS 10줄과 전역 변수 몇 개면 됐지만 나만 이해해서, 지금이라면 주석을 더 달았을 듯. 당시에도 CSS 전용 메뉴 폴백은 넣었음.

CSS만으로도 메뉴가 되는데 JS는 정확히 뭘 해결한 건지 궁금함.

이런 세부 조정이 더 많아졌으면 함. Visual Studio는 호버 팝업이 너무 빨리 떠서 텍스트를 고르려다 팝업을 클릭하게 될 때가 있음.

Opus Magnum도 이 문제를 겪음. 커서를 목적지로 가장 짧게 움직였다는 이유로 방해받는 느낌임.

주 UI 요소를 향해 마우스를 움직이는 중 보조 UI가 뜬다면 수정 키를 눌렀을 때만 떠야 한다고 봄. 중요한 정보면 처음부터 화면에 보여줘야지, 작업 중인 커서 앞에 튀어나오면 안 됨.

호버하면 설명을 보여주는 정보 아이콘도 싫음. 클릭하면 이미 떠 있던 설명은 사라지고, 아직 안 떴으면 끝까지 안 뜨는 경우가 많더라.

나는 이 패턴을 히스테리시스 사례라고 부르겠음. UI에서도 쓸 곳이 더 있고, Windows의 중첩 메뉴에도 유명하게 쓰였음.

마우스 속도를 보면 되지 않나 싶음. 일정 속도 이상으로 이동 중이면 툴팁을 띄우지 않는 식으로.

나는 커서가 요소 위에서 살짝 흔들릴 때만 툴팁을 보이게 함.

오히려 예시의 무지연 버전이 더 좋음. 예측 가능하고 일관되고 빠른 쪽을 선호함.

나도 지연 버전은 짜증남. 동작 규칙이 눈에 안 보이면 버그처럼 느껴짐.

이건 Emil Kowalski의 'You don't need animations' 글 마지막 예시와 같은 기법 같음. 작은 차이라 평소엔 못 알아차렸는데, 알고 나니 계속 보이더라.

Apple은 Jef Raskin 시절 이런 상호작용 문제를 System 6에서 이미 관찰하고 고쳤다고 들었음. 수십 년 뒤에 다시 발견하는 게 신기함.

터치 인터페이스에서 탭으로 툴팁을 띄울 때도 이 지연을 넣으면 오류일 가능성이 큼.

Windows 작업 표시줄은 이걸 오래전부터 해왔는데 의식해 본 적은 없었음.

전역적인 온도값으로 생각하면 됨. 포인터가 툴팁 요소 안에 있으면 온도가 오르고, 밖에 있으면 식으며, 임계값을 넘었을 때만 툴팁을 보이는 방식임.