Windows 스크롤 막대 단축 동작의 짧은 역사

AI 요약

Windows 기본 스크롤 막대는 화살표로 한 줄씩, 썸 주변 영역으로 한 페이지씩 이동하고, 썸을 끌어 원하는 위치로 갑니다. Windows 2000에서는 기존 마우스·키보드 동작을 모은 우클릭 메뉴가 추가됐습니다. 이 메뉴의 ‘Scroll Here’는 클릭한 위치로 바로 이동하는 기능입니다. 같은 시기에 스크롤 막대를 Shift+클릭해도 해당 위치로 이동하는 단축 동작이 들어갔습니다.

프레임워크마다 달라진 동작

Win32 스크롤 막대를 쓰는 앱이 줄면서 이런 동작을 모든 앱에서 기대하기 어려워졌습니다. Chromium 스크롤 막대는 우클릭 메뉴를 제공하지 않지만 Shift+클릭은 지원합니다. WPF XAML은 두 동작을 모두 구현한 것으로 보이며, WinUI XAML에는 둘 다 없습니다. Qt는 설정 지점이 여럿이라 앱 개발자가 우클릭 메뉴, 좌클릭 점프, 가운데 클릭 점프 등을 선택합니다. 글쓴이는 뒤늦게 알게 된 단축 동작조차 앱마다 지원 여부가 달라진 현실을 짚습니다.

Hacker News 반응

• @charcircuit — 스크롤 막대를 좌클릭해도 원하는 위치로 이동할 수 있습니다.
  • @cosmotic — 무슨 뜻인가요? 제 경험과 글 내용으로는 썸 주변 영역을 좌클릭하면 한 페이지씩 이동합니다.
  • @layer8 — 드래그를 말한다면 단순 클릭보다 동작이 더 필요합니다. 주변 영역 클릭이라면 자동 반복을 써야 합니다. 위치 간 페이지 수를 n이라 할 때 O(n) 시간이 걸립니다. Shift+클릭은 O(1)로 즉시 이동합니다.
  • @autoexec — 한 번에 한 페이지씩 이동합니다. 결국 도착하긴 하지만 보기 좋지 않습니다.
• @chrismorgan — Linux/GTK에서는 주변 영역을 클릭하면 해당 위치로 이동합니다. Shift+클릭은 PageUp/PageDown과 같고, 우클릭은 Firefox에서 PageUp/PageDown처럼 동작하는 듯합니다. LibreOffice와 Inkscape에서는 버튼을 누르는 동안 느린 속도로 스크롤합니다. 앱과 플랫폼마다 동작이 다릅니다. 웹 페이지에서 스크롤 막대를 직접 만들지 말아야 하는 이유 중 하나입니다.
  • @applfanboysbgon — 모든 플랫폼의 동작을 똑같이 맞춰야 하는 이유가 있나요? 어디서나 스크롤되고 앱의 시각적 스타일에도 맞는 막대면 충분하지 않나요? Shift+클릭을 자주 쓰는 사람은 얼마나 되겠습니까?
  • @wtallis — 시스템 설정에 지정한 스크롤 막대 동작을 무시하는 앱은 피합니다. 상호작용 감각을 중요하게 여기는 사람도 있습니다. 스크롤 동작이 어색하면 앱에 대한 평가가 크게 낮아집니다.
• @bartread — 프레임워크마다 구현이 부실하거나 동작이 다릅니다. Windows 앱 사이에서 일관된 사용 경험을 누리던 시절이 그립습니다. 사용자 정의 모양은 괜찮지만 같은 종류의 위젯이라면 동작도 같아야 합니다. 직접 만든 위젯이 운영체제 기능을 충분히 구현하지 못하는 점도 문제입니다.
• @mrob — ‘Scroll Here’를 스크롤 막대 클릭의 기본 동작으로 삼아야 합니다. PageUp과 PageDown에는 이미 키보드 단축키가 있지만, 특정 위치로 이동하는 키보드 단축키는 없습니다. 마우스만의 기능을 키보드 동작과 중복시키는 셈입니다.
  • @layer8 — 마우스와 키보드는 가능한 한 동등한 대안이어야 합니다. 주변 영역 클릭은 같은 페이지를 오갈 때나 위치를 조금씩 조절할 때 편리합니다. 긴 문서에서 절대 위치로 이동할 때는 드래그, 메뉴, Shift 키를 쓰면 됩니다.
  • @userbinator — ‘Scroll Here’를 기본값으로 삼는 건 좋지 않습니다. 실수로 클릭해 긴 문서에서 수천 줄을 이동하면 원래 위치로 돌아가기 어렵습니다.
• @modeless — 표준 UI 컨트롤의 숨은 동작을 정리해 두면 좋겠습니다. 같은 구현을 재사용해 일관성을 보장할 수는 없어도, 컨트롤을 다시 만드는 개발자가 참고할 문서는 필요합니다.

원문: Microsoft DevBlogs / 번역·요약: Trawling