가운데 버튼과 자바스크립트
나는 웹에서 자바스크립트로 구현된 기능들을 꽤 싫어했다. 언어나 구현에 대한 호오라기보단 그렇게 만들어진 기능엔 마우스 가운데 버튼이 동작하지 않기 때문이었다. 마우스 가운데 버튼 혹은 휠 클릭(Wheel Click)이나 휠 버튼(Wheel Button).
아마 대다수의 사람에겐 스크롤 락(Scroll Lock)이나 파즈/브레이크(Pause/Break)만큼 존재 의의가 미미하겠지만 내겐 하드웨어 사용 키 TOP 10 안에 들어갈 정도로 매우 중요한 키다. 그 기능이 바로 무엇인고 하니 활성 탭을 전환하지 않으면서 새 탭으로 링크 열기다. 그러니까 ctrl+클릭과 같은 효과다. 어떤 분은 ctrl+클릭은 쓰면서도 가운데 버튼은 안 쓰더라. 같은 방법으로 탭을 닫을 수도 있다.
심지어 윈도의 표준 설정이자 공식 기능이다. 왼쪽 버튼이 기본 클릭, 오른쪽 버튼이 보조 클릭인 것과 마찬가지로 운영체제 단에서 지원하고 설정하는 공식 기능이란 것이다. 시험해보려는 분을 위해 여기 링크를 준비했다. 참고로 브라우저나 탐색기 같이 여러 개를 띄울 수 있는 프로그램들은 가운데 클릭으로 실행 시 새로운 창으로 하나 더 열린다.
기본적으로 어떤 작업을 할 때 최대한의 많은 정보를 끌어모으고 시작한다. 논문이든 이미지든 최초 검색 후 적당한 후보들을 가운데 클릭으로 모두 새 탭으로 띄워놓는다. 검색과 검토는 완전히 다른 작업이기 때문이다. 그래서 가운데 버튼이 작동하지 않는 사이트는 나로선 기존 작업 체계의 흐름을 끊는, 미운 사이트일 수밖에 없었다.
그런데 얼마 전 새로운 정보를 알게 되었다. 자바스크립트로도 가운데 클릭을 구현할 수 있다는 거다. 코드 몇 줄이면 되는데 보통 귀찮아서 안 하거나 몰라서 안 하는 것이라고. 놀라서 찾아보니 정말로 그랬다. 심지어는 개발자들 사이에서도 논란이었다. 스택 오버플로를 좀 뒤져보니 “아니 그걸 누가 쓴다고 구현해?”라거나, “헐 그런 기능이 있었어?”라고 하는 경우도 상당히 많았다.
원 버튼 마우스와 투 버튼 마우스의 경쟁이 투 버튼 마우스의 승리로 끝난 이후 마우스 역할은 급격히 표준화되었다. 휠 클릭도 마찬가지다. 윈도와 맥을 포함한 대부분의 운영체제가 가운데 버튼으로 새 탭을 호출하고 이를 표준 기능으로 삼았다. 그러니까 가운데 버튼으로 새 탭을 호출하는 건 마우스 제스처처럼 응용 프로그램이 따로 지원하는 기능이 아니다. 탭이라는 개념이 만들어진 이후 마우스라는 하드웨어와 연동되는 표준이라는 뜻이다.
논쟁이 붙은 스레드에서 본 “아무리 사람들이 안 쓰고 모르는 기능이라도 표준은 원천적으로 구현이 되어 있는 게 옳다”는 말이 참 인상적이었다. 물론 그 아래엔 존재 자체를 몰라서 구현한다 안 한다 생각조차 못 했다는 글이 달렸지만 말이다… 사실 직관적으로만 생각해 보자면 휠은 당연히 굴리는 용도지, 클릭도 된다는 사실은 모르는 게 당연한 거 같기도 하다.
여하튼 첫 번째 결론은 여러분 가운데 버튼 많이 씁시다. 특히 서핑 자주 하고 조사 자주 하는 분들은 써보면 중독됩니다. 단순 반복 작업에서 클릭 한 번, 이동 한 번 줄어드는 게 얼마나 효율적인진 잘 아시죠?
UX의 핵심은 통일성
사용자 입장에서 내가 느끼는 UX의 핵심은 통일성이다. 같은 곳에서 같은 행위가 같은 기능을 할 것. 왜 같은 브라우저 같은 사이트에서 가운데 클릭이라는 같은 행위를 했는데 어떤 건 새 탭으로 잘 뜨고 또 어떤 건 아무 반응도 없는가? 표준을 운운하기 전에 무척이나 불편하다. 그런데 심지어 그 기능이 표준이었네? 이 통일성에 관련해서 매우 심각한 한 언론사가 있다.
알다시피 맥과 iOS에선 가장자리 스와이프를 통해 “이전 페이지로” “다음 페이지로” 기능을 구현하고 있다. 그런데 이 언론사 사이트는 가장자리를 포함한 화면 전체에서 스와이프를 “이전 기사로” “다음 기사로” 기능으로 사용한다. 검색을 통해 들어왔다가 스와이프를 통해 이전 페이지로 나가려는데, 어, 또 얘네 사이트가 뜨네? 여기가 말로만 듣던 개미지옥인가? 혹은 2000년대 초에 유행하던 폭탄태그라도 걸렸나?
심각하다. iOS의 기본 인터페이스 하나를 마비시킨다. 어쩌다 뒤로 가는 것과 이전 기사로 가는 게 겹치기라도 하면 히스토리가 꼬여 뒤로 가기의 의의가 무색해지기 일쑤다. 소설처럼 쭉 연결되는 기사도 아니고, 마찬가지로 검색과 SNS 기반 트래픽이 중심인 곳에서 이런 기능은 그 자체로 무의미해 보인다는 건 일단 넘어가자(물론 그렇게 가둬서 PV 1 더 올리려는 큰 그림이었다면… 존경합니다).
사실 해당 사이트만 사용하면 이 자체는 크게 문제가 되지 않을지도 모른다. 그런데 또 별도의 스와이프 기능을 구현하고 있는 브라우저(특히 페이스북 내장)와 만나면… 진짜 개미지옥이 열린다. 사용자의 의도는 온데간데없고 뒤로 가기인지 이전 기사 보기인지 도무지 알 수 없는 기능이 몇 번이고 반복된다.
사실 이건 어느 한 언론사만의 문제는 아니다. 분야를 막론하고 들어올 땐 마음대로지만 나갈 땐 아닌 사이트가 늘어나고 있다. 같은 운영체제에서 같은 브라우저를 통해 같은 행위를 하는데도 다른 결과가 나온다. 아마 이 현상에 짜증을 느끼는 iOS 사용자가 나만은 아닐 듯하다. 그래서 그 언론사임을 인지하면 자연스럽게 잘 안 들어가게 된다.
해당 기능을 굳이 만들고 싶었다면 웹 단위에서 구현해 자신들의 사이트를 기능적으로 고립시킬 게 아니라 전용 앱에서 구현하면 된다. 실제로 다수의 서비스가 이쪽을 택하고, 나머지는 브라우저 차원에서 사용자가 직접 애드온을 설치하거나 하는 형식으로 선택권을 주는 형식이다. 같은 맥락에서 스크롤 옵션 건드는 페이지도… 제발 그러지 맙시다. 이런 건 좀 OS와 브라우저가 구현되도록 놔두자.
스마트폰의 등장 이후 웹 환경은 한 해가 다르게 급격히 변해왔다. 그 속에서 웹과 앱은 기묘한 줄다리기를 하고 있다. 모바일 웹이 제대로 정착되지 않았던 시기 앱은 모바일 최적화를 앞세워 급격히 성장했는데, 뒤이어 성장한 웹 중에선 굳이 기존 브라우저와 반하는 앱의 인터페이스를 구현한 것들이 많다. 아마 모바일 웹이 완전히 체계화되기 전까지 이런 현상은 좀 더 이어질 듯하다.
무엇보다 웹과 앱의 경계가 점점 사라지는 게 최근의 추세다. 통합 과정에서 이러한 UI·UX 문제가 한번 크게 불거지지 않을까 싶다. 물론 진짜 현실은 윗분들의 “이보게 하청 양반. 이런 기능이 있다는데 한번 넣어보면 좋지 않을까? 이것도 넣자. 이건 보고서에 쓰기 좋겠군. 추가해(물론 개발비 추가는 없어).”겠지만.
원문: 김고기의 전공 노트
