드래그 앤 드롭

화면 위의 물건을 옮기려면 예전에는 그 일을 말로 바꿔야 했습니다. 파일을 다른 폴더에 넣으려면 옮기라는 명령과 함께 출발지와 도착지를 글자로 적었습니다. 목록의 순서를 바꾸는 일도 마찬가지여서, 항목마다 붙은 번호를 고치거나 위로 올리는 버튼을 눌렀습니다.

열두 번째 항목을 두 번째 자리로 올리려는 사람을 보면 문제가 분명해집니다. 버튼을 열 번 누르는 동안 화면은 계속 다시 그려지고, 몇 번째까지 왔는지 세는 일은 사람 몫입니다. 한 번 더 눌렀다가 다시 내려야 하는 일도 잦습니다. 머릿속에서는 이미 끝난 동작인데 손은 같은 자리를 열 번 두드리고 있었습니다.

끌어다 놓는 조작은 그 간격을 없애려고 만들어졌습니다. 책상 위의 서류를 다른 자리로 옮길 때 사람은 집어서 옮겨 놓지, 옮기라고 말하지 않습니다. 화면 안의 요소를 실제 물건처럼 다루게 해서 하려는 일과 하는 동작을 같은 모양으로 맞춘 겁니다. 어포던스, 즉 생김새만으로 무엇을 할 수 있는지 짐작하게 하는 성질을 화면에서 처음으로 제대로 활용한 사례이기도 합니다.

잡고, 끌고, 놓는 세 동작으로 이뤄지고 각 동작마다 화면이 반응을 돌려줘야 완성됩니다.

1. 잡기. 누르는 것만으로는 시작되지 않고, 누른 채 일정 거리를 움직여야 시작됩니다. 마우스에서는 서너 픽셀을 기준으로 두고, 손가락으로 쓰는 화면에서는 거리 대신 0.3초쯤 길게 누르는 것을 조건으로 겁니다. 이 기준이 없으면 목록을 위아래로 넘기려던 손짓이 매번 항목을 집는 동작으로 잡힙니다. 시작되는 순간 잡힌 요소가 살짝 떠오르거나 기울어지면서 지금 들려 있다는 것을 알립니다.
2. 끌기. 잡힌 요소를 따라다니는 반투명한 사본이 손끝에 붙고, 놓을 수 있는 자리에는 선이나 빈칸이 생깁니다. 이 표시가 없으면 손을 떼기 전까지 어디에 들어갈지 알 수 없어서 놓고 나서야 결과를 확인하게 됩니다. 목록이 화면보다 길면 위아래 끝에 닿았을 때 저절로 스크롤되는 동작도 여기에 붙습니다. 이 동작이 없으면 보이는 범위 밖으로는 옮길 수 없어서, 스무 번째 항목을 맨 위로 보내는 일이 아예 불가능해집니다.
3. 놓기. 놓을 수 있는 자리에서 손을 떼면 그 자리에 들어가고, 그렇지 않은 자리에서 떼면 원래 있던 곳으로 되돌아갑니다. 되돌아가는 움직임을 0.2초쯤 보여 주는 이유는 사라졌다고 오해하지 않게 하려는 것입니다.
4. 확정. 화면에서 자리가 바뀐 것과 그 변경이 저장된 것은 다른 일입니다. 저장이 실패하면 화면도 원래대로 돌려놓고 실패했다고 알려야 합니다. 여기서 피드백을 빼먹으면 사용자는 바뀐 줄 알고 창을 닫습니다.

같은 조작이지만 무엇을 바꾸느냐에 따라 네 갈래로 나뉩니다.

1. 순서 바꾸기. 목록 안에서 위아래로 옮겨 우선순위를 정합니다. 할 일 목록, 재생 목록, 메뉴 편집 화면이 여기 해당합니다.
2. 소속 바꾸기. 다른 묶음으로 옮겨 상태나 분류를 바꿉니다. 칸반 보드에서 카드를 진행 중 열에서 완료 열로 옮기는 것이 대표적입니다. 이때 옮기는 동작 자체가 상태를 바꾸는 명령이 됩니다.
3. 파일 넣기. 브라우저 밖의 파일을 창 안으로 끌어다 놓아 올립니다. 파일 선택 창을 여는 것보다 단계가 적어서 업로드가 잦은 제품은 대부분 둘 다 제공합니다.
4. 배치. 편집 도구에서 요소를 원하는 좌표에 두는 일입니다. 순서를 바꾸는 쪽과 달리 정해진 칸이 없어서, 격자에 맞춰 붙는 보조 기능이 없으면 몇 픽셀씩 어긋난 결과가 쌓입니다. 나란히 놓인 카드 네 장의 왼쪽 끝이 2픽셀씩 다른 화면은 어디가 잘못됐는지 짚기 어려운 채로 어색하게만 보입니다.

"이 목록 드래그 앤 드롭으로 순서 바꾸게 해 주세요. 지금은 위로 버튼밖에 없어요."

버튼을 반복해서 누르는 방식을 끌어다 놓는 방식으로 바꾸자는 요청입니다.

"모바일에서는 스크롤이랑 충돌해서 길게 누른 다음에 끌리게 했어요."

같은 손짓이 두 가지로 해석되는 문제를 눌러서 구분하기로 풀었다는 설명입니다.

"드래그만 되면 키보드로는 순서를 못 바꿔요."

이 조작만 두면 쓸 수 없는 사람이 생긴다는 지적입니다.

페이지덱에서는 문서함의 정렬 방식을 두고 이 이야기가 나왔습니다. 민서가 폴더 안 문서를 끌어다 순서를 바꾸는 안을 냈고, 태오가 그 자리에서 되묻습니다. 목록이 이백 개일 때 스무 번째 문서를 맨 위로 올리려면 화면이 몇 번이나 자동으로 스크롤돼야 하는지, 그동안 손을 떼면 어떻게 되는지였습니다.

둘이 정한 답은 끌어다 놓는 방식을 두되 맨 위로 보내기 항목을 오른쪽 메뉴에 함께 두는 것이었습니다. 지현은 여기에 조건을 하나 더 붙였습니다. 순서를 바꾼 결과가 나에게만 보이는지 팀 전체에 보이는지를 화면에 적어 두자는 것이었는데, 공유 문서함에서는 이 질문이 순서 자체보다 자주 나옵니다.

직관적인 조작이니 설명이 필요 없다고 보는 경우가 많습니다. 실제로 한 번 해 본 사람에게는 쉬우니 그렇게 느껴집니다. 문제는 해 보기 전까지 이 기능이 있다는 사실을 알 방법이 없다는 점입니다. 버튼은 화면에 보이지만 끌 수 있다는 사실은 보이지 않습니다. 그래서 시그니파이어, 즉 조작할 수 있다고 알려 주려고 일부러 붙인 단서가 필요합니다. 항목 왼쪽의 손잡이 모양 점 여섯 개, 올려놓으면 바뀌는 커서 모양이 그 역할을 합니다. 단서 없이 만들어 두면 사용성 테스트에서 그 기능을 찾아내는 사람이 열 명 중 두세 명에 그칩니다.

이 조작 하나로 충분하다고 보는 것도 흔합니다. 마우스로 해 보면 잘 되니 다른 길을 만들 이유가 없어 보입니다. 그런데 손이 떨리는 사람, 마우스 대신 키보드만 쓰는 사람, 화면을 소리로 듣는 사람에게 누른 채 정확한 거리를 이동하는 동작은 어렵거나 아예 불가능합니다. 접근성 기준이 같은 일을 하는 다른 경로를 함께 두라고 요구하는 이유가 여기 있습니다. 키보드 내비게이션으로 항목을 고른 뒤 방향키로 자리를 옮기게 하거나, 맨 위로 보내기 같은 메뉴 항목을 하나 두면 해결됩니다. 둘 다 처음 설계할 때 넣으면 화면 구조가 달라지지 않지만, 나중에 붙이려면 목록을 통째로 다시 그려야 합니다.